IANA registration "application/voucher-jws+json"

[siethower]

Double check and do registration of "application/voucher-jws+json":
https://datatracker.ietf.org/doc/html/draft-ietf-anima-jws-voucher-04#section-6.1.1 "application/voucher-jws+json"
and do registration:
https://www.iana.org/assignments/media-types/media-types.xhtml
same as:
https://www.iana.org/assignments/media-types/application/voucher-cms+json

[mcr]

I did one of these last week for another WG: https://github.com/ietf-wg-cellar/matroska-specification/pull/649/files

[siethower]

Hello @mcr could you please double check and take care of the registration "application/voucher-jws+json", in case of no further issues.

[mcr]

looks good to me.

[siethower]

Question, is the IANA registration already done?

[siethower]

As discussed in design team call, registration will be done after the WGLC and will be done by the chair.

[mcr]

Probably this was wrong... application/voucher+jose is probably the correct answer, to be validated with media-types ML.

[EskoDijk]

"application/voucher-jws+json" is actually fine, just like "application/voucher+jws" would be fine too.
The latter requires the registration of "+jws" in the IANA structured syntax suffixes registry. The former uses +json which is already in there.
Arguably the "application/voucher+jws" name would be slightly more useful/precise.

[siethower]

This is in aligment with the current issue "IANA registration "application/voucher-jws+json" (see headline) and consistent with
https://www.iana.org/assignments/media-types/application/voucher-cms+json

Do we need any changes?

[mcr]

email sent: https://mailarchive.ietf.org/arch/msg/media-types/DgfRHG4bLeFnaAaK3riYoaeRLVQ/

[EskoDijk]

Note that application/voucher-cms+json actually made a naming mistake! Since the CMS outer container itself isn’t JSON, it shouldn’t use the +json suffix at all. So no need to be consistent with it ;-)

[EskoDijk]

Update to my previous comments: "voucher+jws" can't really work, I just learnt that "jws" isn't an existing media type so that can't be used.
JWS is encoded as either "application/jose" or "application/jose+json" I believe (RFC 7515)

So if the outer encoding of the voucher would be valid JSON (NOT base64) then it is:

• "application/voucher-jws+json"

And if the outer encoding of the voucher is JOSE as base64 (not native JSON) then either:

• "application/voucher-jws+jose"
• "application/voucher+jose"

Disclaimer: this opinion may change once I learn more about this topic.

[mcr]

While +jws is not registered, it could be easily registered if the media-types agree.

[EskoDijk]

While +jws is not registered, it could be easily registered if the media-types agree.

Ah, sorry - it could be registered. While most +suffix registrations are based on a media-type of the same name, this is not a requirement. I can even register a '+foo' without 'foo' being a media-type in principle (like +der has done).

Maybe some would argue it's confusing to have +jws denote an outer media-type encoding of "application/jose+json". Because the names aren't language-wise relatable. But it can work.

That said, both the options of +jws and +json seem to have their merits and there's not a clear winner for me.

[mcr]

Leave it as it is, as we have not gotten feedback from mediaman WG.

[msporny]

Hi, I'm the editor of the multiple suffixes draft in the media type WG at IETF.

This thread highlights the current confusion around media type suffixes (you're not alone). Some thoughts below:

Using "+json" as the suffix when the syntax of the message is clearly not JSON is just plain wrong.

Using "+jws" or "+jose" as the suffix if the syntax matches the "JWS Syntax" is problematic because it doesn't specify if "JWS Compact Serialization" or "JWS JSON Serialization" is used. If you're using the former, the pattern seems to be to use "+jwt" (JOSE experts will have to correct me if there is more nuance to this). If you're using the latter pattern, it's not clear what the suffix should be, though I know "+json+jwt" has not received unanimous support previously, and
that might signal that the JOSE community needs to register another suffix for "JWS JSON Serialization" form. You might try "+jws+json", but that would put you squarely into the "multiple suffixes" debate, which would further delay your registration.

The end goal of this work is to have one "Voucher" data model, that can be presented in both JSON and CBOR, and signed in multiple ways (e.g. CMS, COSE, JWT i.e. JOSE, ... )

Ah! This is interesting. That is the same model that the W3C Verifiable Credentials WG has adopted, which triggered the whole multiple suffixes discussion in that group. Are you saying that "application/voucher" could be thought of as a meta model (there is a set of information that you are encoding there), but the syntax isn't determined until you serialize it to JSON or CBOR, and then it's not secured until you use COSE, JWT, JOSE, etc?)

This is all useful information as it demonstrates that at least two groups came to the same sort of design through completely independent operation, and are now being hit by the "which suffix should we use?" discussion. If I had to guess, you're probably exploring something like the following:

• application/voucher+jwt
  • Base64 encoded JSON payload of voucher data model
• application/voucher+jose or application/voucher+jws
  • JWS JSON Serialization with base64-encoded JSON payload of voucher data model
• application/voucher+cose
  • COSE CBOR serialization with ??deterministic?? CBOR payload of voucher data model
• application/voucher+cms
  • I have no idea what this is right now, is this a DER-encoded thing that wraps the voucher data model?

What am I getting wrong wrt. the above?

[mcr]

Manu Sporny ***@***.***> wrote: > The end goal of this work is to have one "Voucher" data model, that > can be presented in both JSON and CBOR, and signed in multiple ways > (e.g. CMS, COSE, JWT i.e. JOSE, ... ) Ah! This is interesting. That is the same model that the W3C Verifiable Credentials WG has adopted, which triggered the whole multiple suffixes discussion in that group. Are you saying that "application/voucher" could be thought of as a meta model (there is a set of information that you are encoding there), but the syntax isn't determined until you serialize it to JSON or CBOR, and then it's not secured until you use COSE, JWT, JOSE, etc?) Yes, exactly. RFC8366's YANG (soon RFC8366bis) is the information model. This is all useful information as it demonstrates that at least two groups came to the same sort of design through completely independent operation, and are now being hit by the "which suffix should we use?" discussion. If I had to guess, you're probably exploring something like the following: :-) * application/voucher+jwt * Base64 encoded JSON payload of voucher data model * application/voucher+jose or application/voucher+jws * JWS JSON Serialization with base64-encoded JSON payload of voucher data model * application/voucher+cose * COSE CBOR serialization with ??deterministic?? CBOR payload of voucher data model * application/voucher+cms No need for any deterministic, but yes. * I have no idea what this is right now, is this a DER-encoded thing that wraps the voucher data model? It's CMS (from SMIME world) wrapping JSON. We are not serializing to DER ourselves (and don't want to). What am I getting wrong wrt. the above? You are bang on.

[EskoDijk]

Using "+json" as the suffix when the syntax of the message is clearly not JSON is just plain wrong.

@msporny Agreed! That was done by RFC 8366 but it's not the case for the present JWS-voucher draft. This actually has a JSON base format. (For the record: "General JWS JSON Serialization Syntax" - Section 3/3.1/Figure 1). This could still be changed to "+jws" or "+jws-json" but there wouldn't be much benefit to the core protocol operation. And going for multiple suffixes now seemed a bit risky/early; without much benefit to protocol operation.

application/voucher+cms

Historically, the other name with the +json was picked in RFC 8366 and so far we've not touched that. So this name with +cms is not something we're using/proposing now.

application/voucher+jwt

This is not currently in scope of the draft - just to avoid too many options, I guess.