Xmldsig Laravel Package

Product Decisions This Supports

• Compliance with SUNAT e-Invoicing Regulations: Enables the team to meet Peru’s mandatory electronic invoicing standards (Factura Electrónica) without building a custom XML signing solution from scratch.
• Cost Efficiency: Avoids reinventing the wheel for XML-DSig compliance, reducing development time and maintenance overhead.
• Integration with Existing Workflows: Supports seamless signing of XML documents (e.g., invoices, credit notes) in PHP/Laravel-based systems, aligning with technical debt reduction goals.
• Roadmap for Latin American Markets: If expanding into Peru or other SUNAT-regulated regions, this package provides a foundation for future-proof compliance.
• Build vs. Buy Decision: Justifies a "buy" decision for XML signing, given the package’s specialization and low maintenance burden (vs. a generic crypto library like openssl).
• Algorithm Agility (new in v5.1.0): Signature and digest algorithms are now configurable, so the team can select SHA-256 (or other supported algorithms) rather than being locked into legacy defaults. This supports forward-looking security policy decisions and reduces the risk of a future forced migration.

When to Consider This Package

• Regulatory Requirement: Only adopt if SUNAT’s XML-DSig standards are mandatory for your product (e.g., e-commerce, ERP, or accounting software in Peru).
• PHP/Laravel Stack: Best suited for projects already using PHP/Laravel; not ideal for non-PHP ecosystems (e.g., Node.js, Python).
• Certificate Format: Requires .PEM certificates (supports conversion from .PFX via provided guide). Avoid if your workflow relies on other formats (e.g., .p12).
• Maintenance Risk (updated): The v5.1.0 release materially improves the maintenance picture: CI now runs via GitHub Actions, and the project accepted an outside contributor for the first time. The "stale since 2020" concern is no longer accurate. Residual risk remains—release cadence is still low and there is no formal support/SLA—so budget for forking or wrapping if you need guaranteed responsiveness.
• Algorithm Configuration: You can now configure signature and digest algorithms, which means you must explicitly pick and pin them. Treat this as a validation task, not a free win: confirm the chosen combination is accepted by SUNAT’s current resolution before shipping.
• Alternatives Exist: If SUNAT compliance isn’t urgent, evaluate whether commercial APIs or SUNAT-adjacent SDKs better fit your timeline; generic crypto libraries (e.g., openssl, PHP’s XML-DSig tooling) remain options if you want full control.
• Performance Needs: Benchmark if signing large XML files; the package’s simplicity may not optimize for high-throughput scenarios.

How to Pitch It (Stakeholders)

For Executives: "This PHP package lets us comply with Peru’s SUNAT e-invoicing rules—saving us 3–6 months of dev time by avoiding custom XML signing logic. The latest release directly de-risks the two concerns we had: it now has automated CI and the signing algorithms are configurable, which means we’re not stuck on outdated defaults if SUNAT tightens requirements. It remains a lightweight, low-cost ‘buy’ that de-risks compliance and accelerates time-to-market."

For Engineering: "The greenter/xmldsig package provides a battle-tested way to sign XML documents per SUNAT’s standards using RSA keys in .PEM format. v5.1.0 adds two things that matter to us: GitHub Actions CI (regression safety on upgrades) and configurable signature/digest algorithms (we can pin SHA-256 instead of relying on legacy defaults). It’s a thin wrapper around XMLSecLibs, so we’d still need to:

1. Validate it handles our XML schema (e.g., UBL 2.1).
2. Test edge cases (e.g., large files, malformed XML) and the explicit algorithm configuration path.
3. Keep a fork/wrap option open—cadence is still slow and there’s no SLA. Pros: no dependencies beyond OpenSSL; easy integration; now CI-backed and algorithm-configurable. Cons: still a low-activity project we’d largely own long-term. Recommend a POC with our sample invoices, including a SHA-256 configuration test."

For Compliance/Legal: "This package directly addresses SUNAT’s technical requirements for digital signatures in electronic invoices. With v5.1.0 we can explicitly configure the signature and digest algorithms rather than inheriting defaults, which makes it easier to evidence alignment with current SUNAT resolutions and to move off SHA-1 where required. We’ll need to confirm the exact algorithm combination against [current SUNAT resolution] and document that configuration choice for audit purposes."