Laravel Swiss Eid Laravel Package

Product Decisions This Supports

• Swiss market entry / expansion. schaefersoft/laravel-swiss-eid is a Laravel integration for Swiss electronic identity (eID). If you're shipping to Switzerland, this informs whether you can offer identity-backed onboarding without building protocol handling from scratch. It's a lever for the "do we launch in CH next quarter?" decision.
• Build vs. buy for identity. Native eID integration is protocol-specialist work: certificate handling, redirect/callback flows, assertion validation, and compliance traceability. A package like this converts a multi-week scoped engineering project into a dependency decision — that's a roadmap compression argument.
• Compliance-gated features. eID is the enabler for KYC/AML onboarding, strong authentication, age-gating, and qualified e-signature flows. This directly unblocks feature sets that regulated Swiss buyers (fintech, insurance, healthcare, public-sector) will ask for in RFPs.
• Prioritization of the identity workstream. Because the package is pre-1.0 (0.7.1), the PM decision isn't "adopt or skip" but "spike now / commit later" — which affects sequencing against other roadmap items more than it affects a single sprint.
• Platform/runtime baseline planning. v0.7.1 raises the floor to PHP 8.2+. This is a hard prerequisite for adoption and should feed into your platform-upgrade roadmap rather than be discovered mid-integration.

When to Consider This Package

Consider it when all of the following hold:

• You are building a Laravel/PHP service and need Swiss eID as an authentication or identity-proofing mechanism.
• Your stack is on PHP 8.2+ (matches Laravel 11/12 defaults, and Laravel 10.43+). If you're pinned to PHP 8.0/8.1, this release explicitly excludes you — you'd need a runtime upgrade or a fork.
• You can absorb pre-1.0 API instability. At 0.x, minor releases may carry breaking changes; plan for version pinning, a changelog review at each bump, and a migration budget before you commit to 1.0.
• You want a thin, framework-native integration and are willing to own the surrounding product logic (onboarding UX, consent, data retention, fallback identity paths).

Look elsewhere or defer when:

• You have no Swiss market requirement — this is a narrowly-scoped package and adds maintenance surface for nothing.
• You need multi-country identity aggregation, document verification, or liveness checks — an identity vendor/aggregator is the better fit than a single-country eID wrapper.
• You need a supported 1.x API with an SLA or vendor contract. This is a community package; if procurement requires a vendor MSA, plan to wrap or replace it.
• Basic social/OIDC login is all you need — eID is overkill.
• You cannot yet meet the PHP 8.2+ floor or cannot tolerate a dependency that moves its minimum runtime on patch releases.

Note on v0.7.1: it is a compatibility/packaging fix only (twice-set PHP 8.2+ requirement) — no new features, no deprecations, no API changes. Treat it as evidence of active maintenance and as a prerequisite check, not as a signal to accelerate adoption.

How to Pitch It (Stakeholders)

To executives: This is a small, focused Laravel package that lets us plug into Swiss electronic identity instead of building it. For a Swiss launch it's the difference between offering verified onboarding and offering a form. Cost is a dependency plus our own integration work, not a vendor contract — but it's an early-stage (0.7.x) community package, so we should treat it as a timeboxed spike with a go/no-go at the end, not a committed architecture bet. Upside: unblocks regulated Swiss buyers and compresses an identity workstream from weeks to days. Downside: no support contract, and it now requires PHP 8.2+.

To engineering: Evaluate a 1–2 week spike against our real eID flow (redirect/callback, assertion validation, error and fallback paths). Pin the version, read the diff at every bump, and assume we own the seam — wrap the package behind our own interface so a 1.0 migration or a swap to a vendor aggregator doesn't touch product code. Confirm our runtime is on PHP 8.2+ before starting; v0.7.1 makes that explicit. Budget ongoing maintenance for a pre-1.0 dependency, and flag any gaps in consent, audit logging, or data retention as our work, not the package's.