Closed bellebaum closed 1 year ago
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 typ
JWT requirement.
In a separate PR I think we might want to add a guiding text saying typing is up to the use-case, and potentially define couple such as "jwt+vc"; "sd-jwt+vc"?
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:
application/jose+vc
application/jwt+vc
application/jwt-sd+vc
For example:
application/jwt (exists today)
application/jose (exists today)
application/jose+json (exists today)
IMO, it would be acceptable for any web server to describe the current VC-JWT format using either:
But not application/jose+json
.
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 typ
in a previous PR.
if we add it back, I don't think it should be JWT
... I think it should be less ambiguous :)
typ
header should be added and it should express that it is a JWS following rules defined in VC-JWS spec, and must not be confused with cty
header which expresses whether what is signed using JWS does or does not use JSON-LD (putting CBOR aside for now)
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 ofat+jwt
SHOULD be used for OAuth2.0 Access Tokens following the JWT Profile given there. This continues the pattern of using thetyp
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.