Jose Bundle Laravel Package

Product Decisions This Supports

• Authentication architecture (session vs. stateless tokens). This package sits at the center of the "should our API issue JWTs?" decision. It provides standards-based JOSE handling (signing, and depending on configuration, encryption) rather than a bespoke token format — which determines whether we can support mobile clients, third-party service-to-service calls, and multi-region stateless auth without sticky sessions.
• Build vs. buy on security-critical code. Token signing/verification is exactly the kind of cryptography-adjacent logic we should not hand-roll. This release is evidence the package tracks upstream standards work (spomky-labs/jose 6.1/7.0, Symfony 4), which is the main thing we're "buying" — maintenance of a moving crypto surface.
• Platform support matrix / upgrade roadmap. v2.3.0 formalizes the supported baseline: Symfony 4 and PHP 7.2+, with HHVM and PHP 5.6 test coverage removed. That directly informs when we can retire legacy PHP runtimes in our own fleet and what our minimum-version policy should be for internal consumers of the package.
• Interoperability and integration scope. Whether to adopt this versus a first-party Laravel auth package hinges on whether we need real JOSE semantics (JWK sets, key rotation, encrypted claims) to talk to an external identity provider, or only need opaque bearer tokens for our own first-party clients.
• Dependency risk management. Pinning to spomky-labs/jose 6.1 or 7.0 is a roadmap constraint: it caps which PHP versions we can adopt and creates a transitive-maintenance dependency we must track on the security watchlist.

When to Consider This Package

Consider adoption when:

• You need standards-compliant JOSE/JWT handling — signed tokens (JWS), encrypted tokens (JWE), or JWK-based key management — and want to interoperate with an external IdP, API gateway, or partner service rather than invent a format.
• You're on PHP 7.2+ and Symfony 4 (or a Laravel version whose underlying Symfony components are compatible) and can consume the pinned spomky-labs/jose 6.1/7.0 line.
• Key rotation, multi-key verification, or claim encryption is a real product requirement — this is where a dedicated JOSE implementation earns its keep over a simple HMAC guard.
• You want a maintained implementation rather than in-house crypto, and you're prepared to own the upgrade cadence.

Look elsewhere when:

• You only need first-party API tokens for your own SPA/mobile clients. Laravel Sanctum (opaque tokens) or Passport (full OAuth2 server) cover that with less surface area and fewer crypto decisions.
• You need a full OAuth2/OIDC authorization server — this is a token-format library, not an authorization server; use laravel/passport or league/oauth2-server.
• You're still on PHP 5.6/HHVM or a pre-Symfony-4 stack. This release explicitly drops that test coverage, so legacy environments are unsupported going forward.
• You require a vendor SLA, long-term commercial support, or a documented security-response commitment — this is community-maintained OSS, and the underlying JOSE library's maintenance health should be verified before it becomes load-bearing.
• Your team has no appetite for owning key custody, rotation, and revocation operations. The library is the easy part; the key management process is the actual cost.

Migration note for this release: v2.3.0 is a compatibility/modernization release, not a feature release. No new product capabilities, but two things need verification before upgrade sign-off: (1) confirm our pinned spomky-labs/jose version resolves cleanly to 6.1 or 7.0 and that token round-trip tests pass, and (2) confirm no CI or deployment target still relies on PHP 5.6/HHVM, since that support is now untested rather than merely deprecated.

How to Pitch It (Stakeholders)

For executives: This is a security-relevant dependency for how our APIs prove identity. The choice is between a maintained, standards-based token implementation and either hand-written crypto (unacceptable risk) or a first-party framework default that may not cover our interoperability needs. The v2.3.0 release is a low-drama maintenance update: it modernizes the supported platform baseline to PHP 7.2+/Symfony 4 and pins the underlying JOSE library. Cost of upgrading is small; cost of not tracking it is accumulating security and platform debt on an auth-critical component. The decision I need is not "approve this release" — it's "endorse the platform baseline," which unblocks retiring legacy runtimes.

For engineering: No breaking API changes are indicated in the release notes, but treat it as a compatibility gate. Concrete asks: (1) verify our spomky-labs/jose constraint resolves to 6.1 or 7.0 and update the lockfile deliberately; (2) run signing and verification round-trip tests, including any encrypted-claim paths; (3) audit CI and any remaining deploy targets for PHP 5.6/HHVM — support is removed, so failures there will be silent rather than loud; (4) add spomky-labs/jose and this package to the dependency-watch list with an owner, since we're now exposed to its release cadence. Estimated effort is a dependency bump plus a regression pass; the real risk is transitive, not in this diff.

For product/roadmap: We gain a defensible answer to "can we support external identity providers and key rotation?" and a clear line on which PHP versions our auth stack supports. We do not gain new user-facing capability in this release — it should be scheduled as platform hygiene, not a feature milestone, and it should not block roadmap commitments.