Fwd: [Rats] [Anima] [COSE] cose+cbor vs cwt in MIME types

This thread has a lot of commentary on the multiple suffixes draft.

I think some CBOR examples would be good to add, especially because CBOR
has the 3 suffix interaction between +cwt+cose+cbor.

+jwt examples would also be good. Since there are several registry entries
that use +jwt and perhaps if multiple suffixes were an RFC, they would have
used it.

OS



---------- Forwarded message ---------
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
Date: Tue, Apr 4, 2023, 2:27 AM
Subject: Re: [Rats] [Anima] [COSE] cose+cbor vs cwt in MIME types
To: Michael Richardson <mcr+ietf@sandelman.ca>, cose@ietf.org <cose@ietf.org>,
rats@ietf.org <rats@ietf.org>, anima@ietf.org <anima@ietf.org>


> I don't understand why it's not application/voucher+cose+cbor.
> The outer encoding is cbor, the next layer is cose.

Well, the reason is clearly that the draft-ietf-mediaman-suffixes is just a
draft at the moment. Things may change there. We don't want to overhaul our
draft in this stage or wait until mediaman-suffixes is done, presumably?
So we have to assume for the near future only one suffix has a clearly
defined semantics.

So it's either

     application/voucher+cbor
     application/voucher+cose    (if we register 'cose' in the IANA
registry as well)

Note that '+cbor' only refers to the outer CBOR encoding, that is, the fact
that the COSE data is CBOR itself. It doesn't refer to the fact that
'voucher' itself is also (again) encoded in a particular form of CBOR.

If mediaman-suffixes in current state would be accepted and become RFC,
then it could optionally also be:

    application/voucher+cose+cbor

(Note: this wouldn't be mandatory, though. All forms are still valid.)

If we want it could be extended to

    application/voucher+ysid+cose+cbor

where '+ysid' would indicate it using the CBOR-YANG-SID encoding. This has
the benefit that a decoder that doesn't know about 'vouchers' but does know
about CBOR YANG/SID encoding and about COSE, can still represent the
information to a user in a readable form.

That said, for the constrained bootstrap procedure we are considering
there's no benefit as such in adding suffixes to the name. And especially
not given the draft status of multiple suffixes.

As you said also the following would be possible today:

    application/voucher+ysid

if we register 'ysid' as being CBOR-YANG-SID that's included in a COSE
wrapper. I find this less useful than the first options of '+cbor' or
'+cose' , it seems too specific.

Esko

-----Original Message-----
From: Anima <anima-bounces@ietf.org> On Behalf Of Michael Richardson
Sent: Monday, April 3, 2023 21:10
To: cose@ietf.org; rats@ietf.org; anima@ietf.org
Subject: Re: [Anima] [COSE] [Rats] cose+cbor vs cwt in MIME types


Orie Steele <orie@transmute.industries> wrote:
    > At IETF 116 this draft was discussed:

    > - https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes -
    > https://youtu.be/BrP1upACJ0c?t=1744

    > TLDR; there is work in progress to define multiple suffixes, and how
    > they are interpreted.

Right, I read through mediaman-suffixes.
I got the feedback that we should use the most specific type available.

    >> Luckily because COSE is just "plain CBOR" itself , we can use the
    >> subtype '+cbor'. So having "voucher-cose+cbor" would be fine. Also

I don't understand why it's not application/voucher+cose+cbor.
The outer encoding is cbor, the next layer is cose.

There is the a third layer which is `yang-core`.
(It seems that we ought to call this "ysid"?  or maybe +cst. )


+cwt is also three layers: CBOR, COSE, and then CWT claims inside the signed
part.  So, if we'd call it application/eat+cwt, then we ought also call it
application/voucher+ysid

It seems that we ought to have registered +ysid in RFC9254.
Can we do it in draft-ietf-core-sid-20?





--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




_______________________________________________
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats