Request a media type for JSON Serialization

[OR13]

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-05#section-12.1

Something like +sd-jwt+json, that supports the JSON serialization and in particular the unprotected header.

[alenhorvat]

After some reflection I realised that SD-JWT (compact/JSON) is not a new encoding for securing mechanism but it is a presentation since it only adds information to existing JWS (compact/JSON). In a sense it is an alternative to Verifiable Presentation.

I guess +sd-jwt +sd-jwt+json cover the two cases.

[Sakurann]

I do not see the need to request registration of a new media type. +sd-jwt and +json will both exist independently and if someone sees the need to combine they could but I do not feel comfortable advocating for the use of combining them. It does not have to be a media type that is used to differentiate JWS compact and JSON serializations.

[alenhorvat]

I'm just trying to follow the JWS RFC:

The "typ" value "JOSE" can be used by applications to indicate that this object is a JWS or JWE using the JWS Compact Serialization or the JWE Compact Serialization. The "typ" value "JOSE+JSON" can be used by applications to indicate that this object is a JWS or JWE using the JWS JSON Serialization or the JWE JSON Serialization. Other type values can also be used by applications.

Since the two encodings are completely different, we should be able to communicate the exact encoding, else devs need to try whether it is compact or JSON.

[OR13]

@Sakurann do you see a reason for +jwt to be here: https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml

but for +sd-jwt to not be?

won't that just lead to application/vc+sd-jwt using an "unregistered structured suffix" ?

application/sd-jwt+json would mirror application/jose+json

https://www.iana.org/assignments/media-types/media-types.xhtml

You should not create a JSON serialization but not document which media type expresses or distinguishes it from its compact cousin.

It does not have to be a media type that is used to differentiate JWS compact and JSON serializations.

Indeed, its current not possible to use media types like this with sd-jwt, thats not a feature when comparing sd-jwt to jwt or jose... its a bug.

[danielfett]

Why do we need a different media type for the JSON representation? In the moment somebody reads the typ value, they should have discovered the serialization format already.

[OR13]

I would not use +json in a typ value.

I would use it with http headers like accept and content type.

I might also use it when nesting a JSON serialized sd-jwt inside other json, and conveying the media type for the nested object... but that's not the primary example.

Primary example:

GET /identity-document accept application/jose accept application/jose+json

Could be replaced with:

GET /identity-document accept application/sd-jwt accept application/sd-jwt+json

Inside the header you might find typ: sd-jwt or vc+sd-jwt

... If you were signing a json serialized sd-jwt, you might see typ:jwt, cty: sd-jwt+json.

[OR13]

Of course you can use application/json instead of application/jose+json or application/sd-jwt+json... You just can't negotiate for what you want if it's not registered.

[bc-pi]

It's always struck me as rather awkward that JWS/JWE/JWT have a 'typ' header[1] inside the thing that's used to declare the media type of that thing and that thing has to have already been (at least partially) processed to get to the value of that typ header that will say how to process the thing that's already being processed. I mean, by the time you've read the typ value of a JWS you've already had to figure out that it's a JWS and whether it's compact serialization or one of the JSON serializations. And, of course, there's the fun fact that a JSON serialized JWS might have more than one 'typ' header and it can show show up in variety of places[2].

Preventing JWT confusion attacks with explicit typing is a worthwhile thing. Honestly though, in retrospect, I'm not sure typ and media types[3] were the best tool for it. But it's a "Best Current Practice" now with a registered +jwt structured syntax suffix[4] and several registered media types using it[5]. So it's out there and has some momentum in usage. The SD-JWT compact serialization is similar enough to JWT that it made sense to follow the same pattern/recommendation[6] with a structured syntax suffix registration request for +sd-jwt[7].

I'm becoming less and less convinced that adding the SD-JWT JWS JSON serialization[8] was necessary or a good idea. But it's there in -05 and that leads us here to this issue. Given that 0...n typ headers could appear in a JSON serialized SD-JWT, I don't think it's an appropriate construct to employ for preventing type confusion (if JSON serialized SD-JWTs even need such a construct). And (I think similar to @Sakurann) I am not comfortable advocating for the use of multiple structured suffixes and not at all interested in trying to register one with this draft. Which is to say that +sd-jwt+json is a pretty hard "no" from me.

For use with HTTP header fields like accept and content-type or other contexts where the media type might be used to say what the thing is or ask for a certain thing, the existing application/jose+json media type kinda feels like it'd be sufficient. But I can also see the potential usefulness of a more specific application/sd-jwt+json and could maybe be convinced that this draft should request registration of such.

[1] https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.9 JWS typ https://datatracker.ietf.org/doc/html/rfc7516#section-4.1.11 JWE typ https://www.rfc-editor.org/rfc/rfc7519#section-5.1 JWT typ

[2] lots of different places typ header(s) could show up https://datatracker.ietf.org/doc/html/rfc7515#section-7.2.1 General JWS JSON Serialization https://datatracker.ietf.org/doc/html/rfc7515#section-7.2.2 Flattened JWS JSON Serialization

[3] https://www.rfc-editor.org/rfc/rfc8725#name-use-explicit-typing JWT BCP explicit typing

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

[5] (somewhat rhetorical) does dpop+jwt really need to be an IANA registered media type? https://www.iana.org/assignments/media-types/media-types.xhtml

[6] https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt#name-explicit-typing

[7] https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt#name-structured-syntax-suffix-re

[8] https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt#name-jws-json-serialization

[bc-pi]

... If you were signing a json serialized sd-jwt, you might see typ:jwt, cty: sd-jwt+json.

Wait, what!? How would a json serialized sd-jwt be a jwt (per typ:jwt) or have a payload that is itself a json serialized sd-jwt (per cty:sd-jwt+json)? It doesn't make any sense to me. Was that a mistake made in haste? Or are we on really different pages with this stuff?

[OR13]

Lets forget about sd-jwt for a second, and just think in terms of:

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

You could have a JWT with the following header:

{ typ: application/foo+jwt, cty: application/jose+json

When you serve this token as the response body of a network request... you could return it as a compact jws with content type:

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

or as flat jws with content type:

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

SD-JWT has a JSON serialization:

• https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-05#name-jws-json-serialization

What is the media type that describes this JSON serialization? is it:

A. application/json B: application/jose+json C: application/sd-jwt+json

If you don't say, people will probably guess A or B.

Returning to the original comment, lets say you have an SD-JWT that is selectively disclosing an already JSON encoded SD-JWT... you would have the following header:

{ typ: application/foo+sd-jwt, cty: (A, B, C) }

I'm not suggesting this use case is critical, I am saying that its confusing, and media types could help clarify it... even if the recommendation is... don't do this... but there seem to be use cases for this sort of thing being discussing in WIMSE right now : )

[bc-pi]

Had a slack conversation with @OR13 and think it can be summarized as him being in favor of this draft requesting registration of application/sd-jwt+json for the SD-JWT JSON Serialization and me not being opposed to it.

[bc-pi]

PR #349 adds a registration request for a media type for the JSON Serialization