Laravel Swiss Eid Laravel Package

Technical Evaluation

Package: schaefersoft/laravel-swiss-eid — Laravel integration for Swiss E-ID (federal eID / SwissID-style identity assertion) flows. Assessment based on v0.7.1 release metadata only; no source, docs, or runtime validation available yet.

Architecture fit

• Presumed shape: a standard Laravel package (service provider + publishable config + facade) wrapping an OIDC/OAuth2 relying-party flow against a Swiss E-ID provider, with assertion/token validation surfaced into Laravel's auth layer. This fits a Laravel monolith or modular monolith cleanly; it is a poor fit if our identity layer is already centralised in an external IdP/IdP-broker (Keycloak, Auth0, Entra) — in that case the package duplicates a responsibility we should keep at the broker.
• Pre-1.0 (0.x) means the public API is explicitly unstable. Treat this as a spike/POC dependency, not a production auth dependency, until 1.0 or a documented stability commitment.
• Authentication is a security-critical, hard-to-reverse integration. Coupling it to a low-maturity third-party package raises the cost of exit later (token formats, session shape, user mapping).

Integration feasibility

• Composer-installable, no infra footprint expected. Main effort is not installation but identity mapping (E-ID subject identifier → local users record), session lifecycle, and logout/single-logout semantics.
• Requires a reachable Swiss E-ID test environment and test identities; onboarding to the federal test IdP is typically the long pole, not the code.

Technical risk

• Semver hygiene signal (from this release): v0.7.1 is tagged Bug Fixes but its only content is raising the minimum PHP to 8.2. That is a compatibility-affecting change shipped as a patch. In a 0.x line this is defensible, but it tells us the maintainer does not treat the PHP floor as a contract — expect further floor bumps and dependency constraints to arrive without warning.
• Security-critical surface: token/assertion signature validation, nonce and state handling, replay protection, key/certificate rotation and clock skew. We must verify each of these ourselves; we cannot inherit the maintainer's assurance.
• Regulatory volatility: the Swiss E-ID trust framework and recognised-provider landscape are still maturing. Spec churn is a schedule risk we do not control.
• Data protection: identity attributes are sensitive personal data under the revised FADP (nFADP/revDSG). A DPIA and a data-residency review of any outbound calls are prerequisites, not follow-ups.

Key questions for the maintainer / spike

1. Which Swiss E-ID profiles and flows are supported (OIDC vs SAML; AGOV/ePortal vs private-sector relying party)?
2. How are trust-framework signature validation, key rotation, and revocation handled — and is that delegated to a vetted library?
3. Is there a reference/test IdP, and documented test credentials?
4. What is the tested Laravel/PHP support matrix, and is 8.2 the floor or a waypoint?
5. Who maintains this, what is the bus factor, and is there a stated path to 1.0?
6. Does it store or log identity attributes, and where?

Integration Approach

Stack fit

• PHP 8.2+ aligns with Laravel 11 and 12. This release narrows support: any service still on Laravel 9 / PHP 8.1 is now excluded. Confirm our fleet baseline before adopting; if we run mixed PHP versions, this package pins the whole application's floor.
• Fits naturally where Laravel already owns the session and user table. Does not fit where an external IdP broker is the system of record for authentication.

Migration path

1. Spike (timeboxed): install in a throwaway Laravel 12 app, wire the test IdP, complete one end-to-end login, and record what the package does not do (mapping, logout, error states).
2. Reference implementation: production-shaped app, our user model, our session/guard config. Validate failure paths: expired assertion, bad signature, replayed nonce, IdP unreachable.
3. Pilot behind a flag: single low-risk journey, dual-run alongside existing login so E-ID is additive and reversible by flag flip.
4. General availability only after a documented 1.0 or an accepted-risk sign-off.

Compatibility

• Pin exactly (0.7.1), commit the lockfile, and gate Renovate/Dependabot on manual review for this package. Given the patch-level PHP floor change, treat every release — including patches — as potentially breaking.
• Verify transitive crypto/JWT dependencies against our vulnerability scanning before pilot.

Sequencing

Identity-provider onboarding and DPIA run in parallel with the spike, not after it; both can invalidate the whole approach and are the slowest paths. Do not sequence legal/onboarding behind code completion.

Operational Impact

Maintenance

• Expect active churn pre-1.0. Budget recurring effort per upgrade rather than a one-off integration cost — a reasonable planning assumption is a re-validation pass on every minor release.
• Bus factor is the primary concern: a single-maintainer, single-purpose package on a security-critical path is a continuity risk. Mitigation: keep the integration behind our own thin adapter interface so we can swap to a direct OIDC client without touching product code.

Support

• Do not expect vendor SLAs. Internal ownership must be explicit — name a technical owner for the auth path. Escalation is "we fix it or we fork it"; plan for the fork scenario to be plausible.

Scaling

• Runtime load is negligible (auth happens once per session). Scaling concerns are operational, not throughput: certificate/key rotation windows, IdP availability, and clock synchronisation across nodes.
• Rotations are the realistic outage vector — they are calendar-driven, easy to miss, and fail closed at login for all users at once.

Failure modes

• Fail-closed login outage: expired client secret, rotated signing certificate, or clock skew → all E-ID logins fail simultaneously. Needs a pre-expiry alert (30/14/7 days) and a documented break-glass path back to the legacy login.
• Silent security regression: a permissive validation default after an upgrade could accept unverified assertions without any visible error. Requires a negative-path test suite in our CI, not the package's.
• Version drift: a transitive dependency bump breaking install on deploy day. Lockfile + staged rollouts mitigate.

Ramp-up

• Low for a Laravel developer to get a login working (~1–2 days with test credentials). High to operate safely: the team must understand OIDC assertion validation, key rotation, and the Swiss trust framework well enough to review the package rather than trust it. Budget a security review with someone outside the implementing pair.

Recommendation: proceed to a timeboxed spike only. Do not put this on a production authentication path until it reaches 1.0 or we complete an independent security review and accept the continuity risk in writing.