-
Notifications
You must be signed in to change notification settings - Fork 9
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.
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
Looser restrictions on the JOSE header typ
#5
Comments
Opting to mark this as a V2.0 issue since it would be a normative change and we're past the window of making normative changes in the maintenance group. I'd expect this will still be addressed, but likely not right away and discussion can continue on it in the mean time. |
PR #10 removes |
Sounds like we might already want to be thinking about new content types... https://www.iana.org/assignments/media-types/media-types.xhtml Not yet registered or requested:
For example:
IMO, it would be acceptable for any web server to describe the current VC-JWT format using either:
But not If we want to move the media conversation to a separate issue, I am happy to do that. |
We should decide what media type value(s) to use for explicit typing via the "typ" header. Doing so is RECOMMENDED by https://www.rfc-editor.org/rfc/rfc8725.html. |
we removed the requirement for if we add it back, I don't think it should be |
|
I am closing this, since its stale / out of date.... more specific issues should be raised for the current draft text. |
Section 5.1 of RFC 7519 states that using a
typ
header claim with a value ofJWT
is RECOMMENDED.This has allowed other specifications to use other media types for JWTs fulfilling a more specific purpose.
For example, RFC 9068 defines a media type of
at+jwt
SHOULD be used for OAuth2.0 Access Tokens following the JWT Profile given there.This continues the pattern of using the
typ
claim as a hint, and allowing for more specialized media types to be defined later.The VC Data Model breaks with this tradition, instead stating that
I would like to know the background behind this decision and why it was made. To me, it feels unnecessarily restrictive and limits the possibility to make established structures having a different
typ
compatible with VCs, as well as to define more specialized forms of VC-JWTs in the future.The text was updated successfully, but these errors were encountered: