Re: [jose] [EXT] Re: [COSE] Multiple Suffixes with JOSE and COSE media types

Inline:

On Thu, Jul 20, 2023, 5:51 PM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Orie Steele <orie@transmute.industries> 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   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>