Signet Pdf Laravel Package

Product Decisions This Supports

• Self-hosting vs. per-envelope e-signature vendors. With ICP-Brasil conformance and a Verificador-accepted output, this moves "build our own signing service" from a compliance risk to a credible option for Brazilian documents. That is a build-vs-buy decision with a direct unit-economics impact: vendor pricing is usually per envelope/document, while this is infrastructure cost plus PKI operations.
• Large-document workflows as a viable feature. Signing a 300 MB file in ~310 MB rather than ~602 MB changes the ceiling from "a multiple of document size" to "document size." This unlocks product scope that was previously blocked by memory: contracts with extensive annexes, engineering drawings, court filings, medical/imaging records, real-estate deeds, and long-lived archives. It also changes deployment sizing and container memory limits, which is a roadmap and infra decision, not just an engineering one.
• Key custody and security architecture. Producing a signature without the private key entering the process enables HSM / external-signer / customer-managed-key models. This supports decisions around SOC 2 / ISO 27001 alignment and enterprise security questionnaires, and it enables a "bring your own key" or on-prem signer offering without forking the package.
• Brazilian legal validity as a product gate. The ICP-Brasil work — policy declaration, security store, and the PBAD_ archival entries PAdES does not define — means the package can target regulated Brazilian signing use cases rather than generic PDF signing. This is the difference between a nice utility and a product feature that legal/compliance will approve.
• Auditability and dispute handling. $signed->receipt() reporting what was signed supports customer-facing evidence and internal audit requirements. It is not a full audit trail, but it is a useful primitive for support and dispute workflows.
• Profile roadmap correctness. SignaturePolicy::forProfile(PadesBLT) now returns null because ITI publishes no policy a B-LT signature satisfies. That is a compliance correction, not a regression to work around: any roadmap item that assumed B-LT should be re-scoped to B-T or B-LTA.
• Migration cost as a roadmap input. The three breaking changes are bounded, but the DocumentBuffer change touches any code that treated PreparedSignature::$document as a string — streaming to disk, hashing, storage adapters, queued jobs. Teams should budget a migration ticket, not assume a drop-in upgrade.

When to Consider This Package

Consider it when:

• You need PAdES-style PDF signing inside a PHP/Laravel application, especially with ICP-Brasil profiles and archival policy requirements.
• You are signing at volume and per-envelope vendor pricing is becoming a material cost line.
• You have, or are willing to build, PKI operational competence: certificate lifecycle, A1/A3 handling, HSM or remote signer integration, revocation checking, and long-term archival validation.
• You need documents signed without private keys entering the application process — for example, an HSM-backed or externally hosted signer.
• Your documents are large enough that naive in-memory signing is a deployment constraint.
• You need a verifiable, inspectable record of what was signed at the time of signing.

Look elsewhere when:

• You need the full e-signature product surface: signer UX, email delivery, identity verification, knowledge-based authentication, in-person capture, notarization workflows, and vendor-backed SLAs. This is a signing library, not DocuSign.
• You need qualified signatures under eIDAS or other non-Brazilian trust frameworks; the release’s conformance story is specifically ICP-Brasil.
• Your team cannot own PKI operations, certificate custody, and archival validation. The package reduces implementation effort but does not remove the operational obligation.
• You need PDF form filling, rendering, generation, or non-PDF document signing as the primary requirement.
• You are not on PHP/Laravel and would be introducing a runtime solely for this.
• You require vendor indemnification or a contractual guarantee that a signature will be accepted by a third party.

How to Pitch It (Stakeholders)

For executives: This release turns a PDF signing library into something we can credibly use for Brazilian documents at production scale. Three things changed. First, large documents no longer require memory proportional to a multiple of the file — a 300 MB document now signs in roughly 310 MB instead of 602 MB, which removes a hard ceiling on the document types we can support. Second, signatures can be produced without the private key entering our application process, which aligns with enterprise security expectations and enables HSM or customer-managed-key offerings. Third, the ICP-Brasil output is accepted by the country’s own Verificador, including the archival policy declarations and PBAD_ entries that generic PAdES does not cover. Commercially, this is a credible path to reducing per-envelope vendor spend and differentiating on Brazilian compliance. The cost is that we take on PKI operations — certificate lifecycle, key custody, and archival validation — which is real but bounded and can be staffed.

For engineering: The upgrade is a contained 3.0.0 migration with a published upgrade guide. The main work is the DocumentBuffer change: any code that assumed PreparedSignature::$document was a string needs to move to the buffer API. intervention/image moves to 4.x. SignaturePolicy::forProfile(PadesBLT) now correctly returns null because ITI publishes no policy that a B-LT signature satisfies — do not treat that as a bug; re-scope any B-LT work to B-T or B-LTA. The payoff is streaming signing, remote/HSM signing, a receipt primitive, and a documentation site published for this line, with 1.x and 2.x archived separately.