Xmldsig Laravel Package

Product Decisions This Supports

• Unlocking regulated/XML-based integrations. XML Digital Signature (XMLDSig, W3C) is the trust primitive behind several market segments: SAML 2.0 SSO assertions, SOAP/WSDL + WS-Security enterprise and banking APIs, government e-filing portals, and e-invoicing regimes (Brazil NF-e/NFS-e, Mexico CFDI, Spain Facturae, EU UBL/PEPPOL, eIDAS-style signed documents). If any roadmap item depends on signing or verifying XML — not JSON — this is the capability layer that decides whether that item is a one-sprint feature or a multi-quarter compliance project.
• Build vs. buy vs. adopt for signing. Three viable paths: (a) adopt a library like this, (b) implement signing/verification directly on top of openssl_* + canonicalization (C14N) handling, or (c) outsource to a commercial signing service or national e-invoicing provider. This package anchors the "adopt" option and should be evaluated head-to-head against robrichards/xmlseclibs and a managed provider before committing engineering time.
• Market/segment prioritization. Whether we can serve a regulated vertical (public sector, banking, LATAM e-invoicing) is gated on standards coverage, not UI. A working XMLDSig implementation changes which segments are addressable in the next 2–3 quarters and should be reflected in the roadmap and pricing/packaging discussions.
• Compliance and audit posture. Signature verification (not just creation) is a product decision: do we validate inbound signed XML from partners, log tamper-evident evidence, and support certificate rotation? That determines security review scope and whether we need an audited, maintained dependency.
• Dependency risk decisions. Last release 2018, 65 stars, zero Packagist dependents, NOASSERTION license. These are inputs to a risk acceptance decision, not just an engineering one — a crypto-adjacent dependency that nobody else uses and nobody maintains is a long-term liability with no upstream safety net.

When to Consider This Package

Consider it when:

• You need to prove the capability quickly — a timeboxed spike to generate and validate an enveloped/detached XML signature against a real partner or regulator sample, before committing to a library choice.
• You are on a legacy PHP/Laravel codebase with existing XML workflows (SOAP clients, SAML IdP/SP, invoice XML generation) and want a drop-in reference implementation rather than writing canonicalization by hand.
• You want reference code to inform an internal signer — the algorithm selection, digest handling, and canonicalization flow are instructive even if you don't ship the package.
• Volume and criticality are low (internal tooling, one partner integration, batch jobs where a failure is recoverable and not customer-visible).

Look elsewhere when:

• Security or compliance is customer-facing or audited (payments, identity, tax filings). Crypto dependencies need an active maintainer, CVE responsiveness, and a clear license. A 2018 release with no downstream dependents gives you no signal that it works on your PHP version, and no community to catch regressions.
• License clarity matters. NOASSERTION means GitHub could not identify a recognized license. Do not ship it into a commercial or redistributed product until legal confirms terms in writing — this alone can veto adoption.
• You need modern profiles: XAdES/CAdES/ASiC extensions, XMLDSig 1.1 specifics, ECDSA/RSA-PSS variants, inclusive/exclusive canonicalization edge cases, or streaming signatures over large documents. Verify profile coverage explicitly; don't assume.
• You need operational guarantees — SLA, support contract, security advisories, PHP 8.x+ guarantees, or a vendor to escalate to.
• A maintained alternative already fits: robrichards/xmlseclibs (widely used, actively maintained, clear BSD license) covers the common enveloped/enveloping/detached cases; a managed signing provider removes the whole class of problems for regulated flows.

Decision rule for the PM: treat this as a prototype and reference dependency, not a production platform dependency, unless legal clears the license and engineering confirms it runs on our PHP runtime with the exact signature profile our partner requires.

How to Pitch It (Stakeholders)

To executives: We have roadmap items — and potentially entire market segments — that require signing and verifying XML documents (partner APIs, government portals, e-invoicing, SSO assertions). This library is a small, free, low-adoption PHP implementation of that standard. It is a useful, cheap way to de-risk and estimate the work in days rather than weeks, but it was last released in 2018, has essentially no downstream users, and carries an unclear license. Recommendation: fund a short technical spike using it as a reference, evaluate it against the established alternative, and only then decide whether to build in-house, adopt an open-source dependency, or buy a managed signing service. Do not position it as a strategic dependency.

To engineering: This is a candidate for a 1–2 day spike: run it against our PHP version and the exact XML sample our partner/regulator accepts, confirm which signature types (enveloped/enveloping/detached) and canonicalization modes are supported, and confirm license terms. Benchmark it against robrichards/xmlseclibs on the same sample. Output: a recommendation memo with effort estimate for build vs. adopt vs. buy, plus the security review items (key handling, certificate storage, clock skew, verification of untrusted input). Assume we will own this code if we adopt it — there is no meaningful upstream community.