Standards update · Sources checked November 7, 2026
The IESG approved the JOSE deprecation document on November 6. As of this check, it is in the RFC Editor Queue, with author input requested. It has not yet been published as an RFC. The approval is a useful trigger to review token-handling code, rather than wait for a library upgrade to change behavior unexpectedly. See the dated approval history.
Which algorithms are affected?
The approved draft targets none for JWS and RSA1_5 for JWE. The former provides no signature protection; the latter is RSA encryption with PKCS#1 v1.5 padding. RSA signatures RS256, RS384 and RS512 are unchanged by this draft.
The draft removes the JWT requirement to implement the two deprecated algorithms. Applications are to disable them by default; a specific legacy need may be enabled narrowly, rather than globally. The proposed registry status is Deprecated, not Prohibited. A narrow exception does not remove the security risks. Read the current draft and status.
Start with the receiver
A token producer and a token receiver can be maintained by different teams. For a practical review, name the owner of each receiving service first. Ask that owner to identify the library version, effective configuration and the test that proves which tokens it accepts. A setting in a shared configuration template is less useful than evidence from the service that actually processes the request.
Existing JWT security guidance in RFC 8725 calls for an application-defined algorithm set, validation of all cryptographic operations, and appropriate issuer and audience checks. Turning off two algorithms does not replace those controls.
A compact acceptance-test plan
The following is a suggested engineering worksheet, not a test we have run against a particular product. Use synthetic tokens and a non-production environment. Do not paste live tokens, signing keys or customer claims into a public decoder.
- Record one expected success. Start with a synthetic token that the service should accept. Record the issuer, audience, token purpose and expected result alongside the configuration version.
- Add explicit rejection cases. Include an unsigned token where a signature is required, a disallowed algorithm, a modified signature, the wrong issuer and the wrong audience. If the application receives encrypted tokens, include the deprecated encryption mode in the rejection set. Verify rejection at the application boundary, not merely a warning in a library log.
- Separate legacy exceptions. For any claimed dependency, record the exact receiving operation, the integration owner and the planned replacement. Test that its exception cannot affect another endpoint. Treat an undocumented global compatibility switch as unfinished work.
- Exercise the upgrade before release. Run the same worksheet against the current and proposed library versions. Investigate changed outcomes and give the dependent team time to test the replacement. Keep rollback instructions tied to the specific change rather than a broad instruction to relax token validation.
What a completed review looks like
The useful deliverable is a short record: receiving service, owner, tested version, approved token profile, positive and negative results, and any narrowly scoped exception with a review date. Put the tests in the release process so the next dependency update repeats them.
A passing worksheet is evidence about those cases only. It does not certify an entire identity system. The immediate next step is to identify one exposed receiving service and make its acceptance rules reproducible.