Closed alenhorvat closed 1 year ago
Multiple suffixes isn't yet a standard and the application of it to +jwt is being discussed at IETF.
The question you are asking seems to be:
Can I secure a Verifiable Credential with multiple serialization? (Compact and Flat, for example)
I don't see why not, as along as you have a way to secure json (+ld+json)... You are not required to use media types to secure the data model, but that seems advisable based on relevant BCPs from IETF.
Personally I'm not a fan of multiple suffixes; for example, JWS defines jose and jose+json (JSON serialised JWS). VC would then look like: vc+ld+json+jose+json
I'm more in favor of: using media type for the whole payload (jwt, jose, jose+json) typ for signature type (there can be multiple signature profiles; e.g,. jades defines 4 of them) cty for the payload type
My question is actually about the JWT. Let's assume issuer != signer. When JWS+x509 are used, solution is simple: information about the signer is in the header (JWS header claim + x* - identity of the signer, key of the signer, policies, cert revocation, ...)
Issuer defines the payload (e.g., Alice has a right to drive a car in Wonderland until 2027) In this case the vc issuer (identifier and identity) can be different from the signer.
In the case of JWT, can we assume the same? So
We may have a scenario where
since in JWT (when x509 is not used) not sure there's a way to express the signer's identifier/identity. Or?
Hence the question: Is JWT is seen as a securing mechanism that uses/adds additional JWT claims to the payload to protect the content?
The media type associated with a document should be for that document, not for anything it might or does contain.
To be more explicit — if it's an envelope with one or more enclosures (payload, cty
), the media type should be for the envelope, not for any of the enclosure(s).
Most conversation here and elsewhere has been focused on single-enclosure envelopes, where talking about payload, cty
makes some sense — but it's important to also consider scenarios with multi-enclosure envelopes, where those enclosures might have different media types (e.g., a ZIP archive containing some text/plain
, text/html
, image/jpeg
, image/png
, and/or other documents).
If the envelope type (e.g., gzip) can only have a single enclosure, it may be reasonable to have a +
media type, a la application/gif+gz
. However, handling can be complicated in cases such as this example, where unzipping that gzip should result in an image/gif
(which would be the cty
, if gzip had such a thing), rather than an application/gif
as would be suggested by some discussion above (and elsewhere).
Starting the "multiple-suffix media type" conversation with archives as discussed above would hopefully prevent the worst misunderstandings and misdirections currently being contemplated regarding superclass media types, such as application/json
which today has a subclass of application/ld+json
, and proposed subclasses such as application/vc+ld+json
, application/vp+ld+json
, any of which might be secured by JWS as application/json+jwt
, application/ld+json+jwt
, application/vc+ld+json+jwt
, or application/vp+ld+json+jwt
(or, conceivably but confusingly for mechanical processors, as application/jwt
, application/ld+jwt
, application/vc+ld+jwt
, application/vp+ld+jwt
, respectively).
Note that JWS supports 3 different ways to secure the payload
https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml
only +jwt is a registered structured suffix.
So when securing vc+ld+json
using a structured suffix and a typ
value... I would expect the following:
typ: vc+ld+json+jwt
typ: vc+ld+json+sd-jwt
Because +jwt
is registered already and +sd-jwt
will be registered by https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/
I would not expect to see:
typ: vc+ld+json+jose
typ: vc+ld+json+jose+json
Since neither is a registered structured suffix.
Restructuring what @OR13 said, hopefully more clearly:
When securing
application/vc+ld+json
using a structured suffix and atyp
value...Since
+jwt
is already a registered structured suffix, and+sd-jwt
will be registered by Selective Disclosure for JWTs (SD-JWT), I would expect the following:
typ
:vc+ld+json+jwt
typ
:vc+ld+json+sd-jwt
However, since neither
+jose
nor+jose+json
is a registered structured suffix, I would not expect the following:
typ
:vc+ld+json+jose
typ
:vc+ld+json+jose+json
I understand. However, my point is that: +jwt is only for compact serialised JWS. sd-jwt is introducing a new jwt encoding (jwt + tilde, essentially; JSON encoding requires a bit more attention).
JSON encoded JWS should then have a structured suffix +json? or would require a new +jws-json registration?
In other words: If one wants to use JWS (compact/serialised, not +jwt) as defined today, I guess structured suffixes are not registered.
How do you see this?
@alenhorvat If you want to communicate that some media is json
, it would be best to use the +json
suffix, when registering that media type, search for +json
here for examples: https://www.iana.org/assignments/media-types/media-types.xhtml
2 paths forward:
+jose+json
as a structured suffix (but this does not help you if you are using sd-jwt... or does it... cc @Sakurann ).+sd-jwt+json
as a structured suffix so that application/vc+sd-jwt+json
can be used to communicate JADES vc's that don't use JSON-LD and application/vc+ld+json+sd-jwt+json
can be used to communicates JADES VCs that do use JSON-LD.Let me try to present the whole set of options:
--
So proposal would be to have 2 structured suffixes:
signature profile would be expressed via the 'typ' JOSE header property. This way, processing of the signature is as follows:
What do you think? (I'm aware that some of the proposals might violate some practices, but let's not be constrained by those and let's try to see if we can come up with a simple and clear structure for expressing information)
@alenhorvat please comment on your use case for JSON Serialization of sd-jwt
here... https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/327
We can define media types for securing JSON-LD with +jose
and +jose+json
however we would still need +sd-jwt
and +sd-jwt+json
because sd jwt uses the ~
character.... I guess technically +jose+json
could work instead of +sd-jwt+json
... Cc @Sakurann
I suspect that merging PR #149 would resolve most of these comments in practice.
@alenhorvat wrote:
In a conceptual model we should be able to distinguish between an issuer and a signer. In most cases issuer == signer.
For what it's worth, I know of no practical circumstances in which one would trust a token not signed by its issuer. Indeed, one retrieves the signing keys based on the issuer. There's no provision for retrieving keys other than the issuer's.
Remote e-sealing/e-signing is such an example.
I fully agree that only the issuer should have access to its e-sealing service/keys. Still, the content to be signed is not sent to the service for various reasons (confidentiality, privacy, etc.), hence the conceptual distinction. In the same way, only digests are sent to timestamping services.
Remote e-sealing/e-signing is such an example.
That's a valid use case but it's out of scope for this specification. This spec defines how to secure payloads with JOSE and COSE and intentionally stops there.
Specifically this spec secures JSON-LD media types registered via the core core data model.
@selfissued @OR13, thank you.
Remote e-sealing -> will address it elsewhere.
This issue can be closed. No action is required.
Closing issue upon @alenhorvat 's recommendation.
I'm moving the discussion from the thread https://github.com/w3c/vc-data-model/pull/1203#discussion_r1264468601
_Main question is actually about JWT (not JWS, usage and role of JWS are clear).
This is my view and I might be wrong (but this is how I understand the JWT RFC - JWT is a profile for JWS: compact serialised + JWT claims that need to be defined by the use case):
If JWT is seen as a securing mechanism that uses/adds additional JWT claims to the payload to protect the content, then all the issues and conflicts can easily be resolved. In a conceptual model we should be able to distinguish between an issuer and a signer. In most cases issuer == signer.
If my understanding of the JWT is wrong (if so, let me know) it would be good to clarify the position and usage of JWT.
@selfissued @OR13 can you help with this one or if there's anyone else in the group who can help. Thank you!_
vc+jwt -> requires data model definition vc+ld+json+jwt -> VCDMv2 as is, secured with JWT