Inline: On Thu, Jul 20, 2023, 5:51 PM Michael Richardson <[email protected]> wrote:
> > Orie Steele <[email protected]> wrote: > > `+jwt` secures `application/json` (already a registered structured > > suffix) > > Yesish... but: > > > `+cwt` secures `application/cbor` ( registration requests exist... > > > https://www.ietf.org/archive/id/draft-ietf-rats-eat-media-type-02.html#section-6.1 > > ) > > > `+cose` secures an envelope that is `application/cbor` and a payload > of > > type `content_type` ( > > https://github.com/anima-wg/constrained-voucher/issues/264 ) > > Here I had a bit of pause. > Eventually I understood/remembered that +cwt isn't secure application/cbor. > Rather, it's securing application/cbor with a payload consisting of claims > from the CWT registry. So while the underlying serialization is CBOR, it's > not securing arbitrary CBOR. > > (And that's why constrained-voucher does not use +cwt, because our claims > come from YANG, not from COSE) > A similar statement applies to +jwt, I think. > There was discussion related to this recently on the COSE list, related to the cwt claims in header draft, and the typ COSE header parameters draft. Summarizing, payload is JSON for jwt, payload is CBOR for cwt. Afaik, all members are optional, but when present certain members have specific meaning. Using +jwt, and +cwt signals you want that meaning. This is relevant to W3C Verifiable Credentials, which... Which uses those meanings. > > `+jose` secures an envelope that is `application/json` and a payload > of > > type `cty` (AFAIK, nobody is planning to register this as of right > > now). > > https://datatracker.ietf.org/doc/draft-ietf-anima-jws-voucher/ maybe. > Thanks for pointing this out. > > You might consider these last 2 special cases of multipart content > > types... when their headers include `content_type` or `cty`. > > I kinda get why you are saying multipart, but I don't really like it that > way. > I want to suggest that there are very few cases of real processing chains > in > my opinion. Except for debuggers. > +gz -type suffixes are the small exception to this. > I agree with this. With the exception of polyglot formats in general... Which invite leveraging processing chains... This was the original reason for the multiple suffixes draft... +ld+json was rejected because there was no defined behavior for processing multiple suffixes... It's probably too late now, but this could easily have been solved by just doing +json-ld instead. A lot of people who have worked with +ld+json would probably agree that while it is json, you spend most of your time looking at the RDF it produces, and cursing about how hard it is to make both the json and the rdf look nice as the same time. > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on > rails [ > > > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
