Skip to content

Describe relationship between explicit typing and JWTs not already employing it #32

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
yaronf merged 3 commits into from
Dec 15, 2025
Merged

Describe relationship between explicit typing and JWTs not already employing it #32

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
3785502
Describe relationship between explicit typing and JWTs not already em…
selfissued Dec 15, 2025
9145238
Apply suggestion from @yaronf
selfissued Dec 15, 2025
aeec605
Apply suggestion from @selfissued
selfissued Dec 15, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 22 additions & 2 deletions draft-ietf-oauth-rfc8725bis.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -690,10 +690,24 @@ to explicitly type the entire Nested JWT.

Note that the use of explicit typing may not achieve disambiguation
from existing kinds of JWTs,
as the validation rules for existing kinds of JWTs often do not use the "typ" Header Parameter value.
Explicit typing is RECOMMENDED for new uses of JWTs.
as the validation rules for kinds of JWTs defined before
the guidance on explicit typing in {{RFC8725}} was available
often do not use the "typ" Header Parameter value.

Also, note that attempting to retrofit mandatory explicit typing
into the validation rules for existing kinds of JWTs not already using it
would be a breaking change;
if a legacy implementation creates a JWT without the explicit type and
an updated implementation receiving it requires the explicit type,
the JWT will be rejected. The implementations will not interoperate.
However, retrofitting a rule that if the JWT contains a "typ" value,
then it MUST be expected explicit type, is not a breaking change.
Comment thread
selfissued marked this conversation as resolved.
Outdated

Another consideration for existing kinds of JWTs is that the use of
a "typ" value of "JWT", as originally recommended in {{Section 5.1 of RFC7519}},
does not constitute effective explicit typing.

Explicit typing is RECOMMENDED for new uses of JWTs.


## Use Mutually Exclusive Validation Rules for Different Kinds of JWTs {#preventing-confusion}
Expand Down Expand Up @@ -838,10 +852,16 @@ This document obsoletes RFC 8725 and provides several significant improvements a

5. Compression DoS: Added mitigation for DoS attacks resulting from abuse of compression in JWE ({{limit-decompression}}).

6. Described relationship between explicit typing and kinds of JWTs not already employing it.

# Document History

[[Note to RFC Editor: please remove before publication.]]

## draft-ietf-oauth-rfc8725bis-03

* Described relationship between explicit typing and kinds of JWTs not already employing it.

## draft-ietf-oauth-rfc8725bis-02

* Incorporated Aaron Parecki's review suggestions.
Expand Down