JWT - securing mechanism or not?

[alenhorvat]

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

[OR13]

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.

[alenhorvat]

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

• JWT payload claim are describing the signer and are set by the signer
• other payload claims (non-JWT) are defined and set by the issuer

We may have a scenario where

• iss = global.signer.com (iss as per JWT)
• issuer = drivers.licence.authority.com (issuer as per W3C VC)

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?

[TallTed]

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).

[alenhorvat]

Note that JWS supports 3 different ways to secure the payload

• jose (compact serialised JWS without JWT claims)
• jose+json (JSON serialised JWS without JWT claims)
• jwt (compact serialised JWS with JWT claims)

[OR13]

https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml

only +jwt is a registered structured suffix.

[OR13]

• https://www.iana.org/assignments/media-types/application/jose+json
• https://www.iana.org/assignments/media-types/application/jose

^ these are media types.

[OR13]

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.

[TallTed]

Restructuring what @OR13 said, hopefully more clearly:

When securing application/vc+ld+json using a structured suffix and a typ 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

[alenhorvat]

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?

[OR13]

@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:

1. register +jose+json as a structured suffix (but this does not help you if you are using sd-jwt... or does it... cc @Sakurann ).
2. register +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.

[alenhorvat]

Let me try to present the whole set of options:

1. JWS compact serialised (payload doesn't contain any JWT claim)
2. JWS JSON serialised (payload doesn't contain any JWT claim)
3. JWT - JWS compact serialised + JWT securing claims in the payload
4. SD-JWT - new serialisation (IMO could be fixed to fall under 1 or 2, but that's out of scope of this issue)

--

1. is a string base64url.base64url.base64url (not all 3 elements are optional); structured suffix could be: +jws or +jose
2. is a JSON with well defined claims (general or flat serialisation, depending on the number of signatures); IMO the suffix should signal that it is jws and that it is a json; structured suffix could be +jws+json or +jose+json
3. as 1. except that securing claims appear also in the payload, so a separate structure suffix is a good approach; +jwt; IMO this could be covered also with 1. + signature profile within the typ header. Why? JWT is not defining any specific signature profile but it is leaving it open to applications
4. Let's hope it can fall under 1 and 2. (if the tilde is removed, we can have a nice signature processing structure)

So proposal would be to have 2 structured suffixes:

1. +jws or +jose
2. +jws+json or +jose+json

signature profile would be expressed via the 'typ' JOSE header property. This way, processing of the signature is as follows:

• media type tells you about the signature serialisation - compact or JSON JWS
• typ tells you about the signature profile (required/optional JOSE header params and required/optional JWT securing params)

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)

[OR13]

@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

[OR13]

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

[selfissued]

I suspect that merging PR #149 would resolve most of these comments in practice.

[selfissued]

@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.

[alenhorvat]

Remote e-sealing/e-signing is such an example.

• issuer constructs the payload and computes the digest (local operation)
• digest is sent to a remote e-sealing service that constructs everything needed to verify the signature (x509 chains, timestamps, revocation data (or rather non-revocation proof) - CRL or OCSP statements, etc., and that information is embedded or referenced in the signed or unsigned part of the signature)

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.

[selfissued]

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.

[OR13]

Specifically this spec secures JSON-LD media types registered via the core core data model.

[alenhorvat]

@selfissued @OR13, thank you.

Remote e-sealing -> will address it elsewhere.

This issue can be closed. No action is required.

[selfissued]

Closing issue upon @alenhorvat 's recommendation.