As mentioned in the meeting: If an object with a "typ" element gains a countersignature, semantically speaking, the aggregate type is now changed. Is the typ element now wrong?
This is complex, because it means that a countersignature effectively makes the type incorrect. To resolve this, you are required to either: verify countersignatures first or disregard everything in the unprotected headers when interpreting the typ header parameter. Both of these introduce the same semantic paradox: If the counter-signature(s) are excluded from the type, then the typ element doesn't actually tell me what the aggregate type is. In a naive interpretation, I don't know how to interpret the countersignatures because the typ doesn't include them. Obviously, I don't think we'll be looking at naive interpretations, but I find it disconcerting that the element being introduced to represent aggregate types will be incapable of representing aggregate types that include countersignatures. Clearly, this is not solvable in the way that it is presented. There are a few ways we could approach it. Counter-signatures could add their own extensions to the header, for example. This still has the disadvantage that the "real" type is nested down in a header of a header. Arguably, the "typ" can never be trusted to represent the full content of a COSE object because the unprotected header can change without representation, leaving the designated type always semantically incomplete. I think, at the least, this needs some explanatory text in the draft. Best Regards, Brendan On Fri, Jul 21, 2023 at 12:42 AM Orie Steele <[email protected]> wrote: > > 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 > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
