Spid Laravel Laravel Package

Product Decisions This Supports

• Market entry into Italy / regulated e-services. SPID (Sistema Pubblico di Identità Digitale) is the default citizen login for Italian public administration and for many private services with a public-interest obligation. Choosing this package is a "can we legally and credibly serve Italian users" decision, not a UX-polish decision.
• Tender and procurement eligibility. Public-sector and concession tenders in Italy routinely make SPID (and CIE) acceptance a mandatory requirement. This package is an enabler for satisfying that line item without a multi-week protocol implementation.
• Build vs. buy. The alternative is implementing the SPID SAML2 profile in-house (signed assertions, metadata exchange, key/certificate rotation, attribute mapping, IdP registry handling) or buying a commercial connector. A ~52-star BSD-3 package is the "buy cheap / adopt-and-own" branch of that tree: low license cost, low commitment, high portability.
• Roadmap sequencing. Treat SPID as table stakes infrastructure, not a differentiator (the low opportunity score reflects this). It belongs in the compliance/enablement bucket of the roadmap, sized in engineering days, and should not compete for innovation budget.
• Adjacent roadmap decisions it informs: adding CIE (Carta d'Identità Elettronica), future eIDAS/EUDI Wallet acceptance, and whether identity becomes a shared platform capability (one integration reused across products) or a per-app integration.
• Prioritisation inputs it does not solve. The package gives you code, not agreement with identity providers, not AgID/onboarding validation, not certificate operations, not SLAs. PMs should size those separately — they routinely dominate the critical path more than the integration itself.

When to Consider This Package

Consider it when all or most of these hold:

• The product is a Laravel application (confirm the supported Laravel/PHP versions against your stack before committing; a small package ages faster than your framework upgrade cadence).
• You need SPID as a login option for Italian users, either because of a legal obligation or because a meaningful share of your target users expect it.
• Your team has no deep SAML/SPID expertise and you want to compress a multi-week protocol effort into days.
• You are comfortable vendoring/forking a low-traffic dependency (BSD-3-Clause permits this) and assigning an internal owner for it.
• You need test-environment and pre-production flows quickly (e.g. SPID test IdP) to validate the end-to-end journey before the slower organisational onboarding.
• You can absorb the real workstreams separately: identity-provider agreements/aggregator choice, metadata and certificate lifecycle, attribute mapping, logging/audit requirements, and AgID-conformant user-facing flows.

Look elsewhere when:

• Your stack is not Laravel (there is an upstream PHP-level SPID library; a framework adapter adds little).
• You need CIE or eIDAS/EUDI Wallet first — the SPID-specific wrapper may not be the right abstraction, and you should evaluate a broader identity broker instead.
• You need multi-country or multi-protocol identity orchestration (OIDC, SAML, social, enterprise SSO) — adopt a maintained identity abstraction rather than several narrow packages.
• You require commercial SLAs, support contracts, or vendor accountability — a single-maintainer community package will not satisfy procurement or a security review that demands named support.
• You need capabilities beyond authentication itself (fine-grained authorisation, consent management, step-up authentication, self-service SP metadata management), which will live in your code either way.
• Bus factor is a blocker. With ~52 stars, assume low contributor depth: budget for an internal fork, pinned versions, and a documented exit plan.

How to Pitch It (Stakeholders)

For executives (one paragraph): Supporting SPID is a licence to operate in the Italian market and a recurring line in public-sector tenders. This package is a low-cost, permissively licensed Laravel adapter that lets us ship SPID login in days rather than weeks, and it carries no vendor lock-in because we can fork it if it stalls. The engineering savings are real but modest; the decisive costs and lead times sit with identity-provider agreements, certificate operations, and compliance validation, which we must fund regardless of package choice. Recommendation: adopt it as commodity infrastructure, budget it as a compliance line, and do not treat it as a competitive differentiator.

For engineering (the ask): Spike the integration in a timeboxed window against the SPID test environment; confirm supported Laravel/PHP versions; document the certificate/metadata rotation runbook; vendor the dependency (or maintain a thin internal fork) with a named owner; and list what we are explicitly not getting from the package (IdP agreements, production onboarding, monitoring, guarantees). Flag now if an existing identity abstraction in our stack makes a package-level adapter redundant.

Decision framing: low cost, low lock-in, low strategic upside — approve as a buy-and-own compliance enabler, and revisit if our identity needs broaden to CIE, eIDAS, or multi-protocol SSO.