I have created a PR <https://github.com/ietf-rats-wg/eat/pull/62> against the EAT draft for UCCS and UJCS. I’m not sure this really belongs in the EAT draft, but I thought I’d start by putting it there.
LL P.S. If we were do an update to CWT to accommodate this, it would also be good to add CDDL describing CWT. That is another thing I’ve got in the EAT draft, that probably belongs elsewhere. > On Mar 6, 2020, at 6:27 PM, Laurence Lundblade <l...@island-resort.com> wrote: > > Pretty sure UCCS as Carsten describes below works for me provided: > > - All the rules and requirements from CWT explicilty apply except > signing/encryption > - It uses the same registry > - There is a tag defined for it > - You get an (untagged) UCCS when you remove all signing and encryption layers > > LL > > >> On Mar 6, 2020, at 12:04 PM, Carsten Bormann <c...@tzi.org> wrote: >> >> Hi Ned, >> >> What I was trying to say is that the Unprotected CWT Claims Set (UCCS) is >> not a CWT, but an UCCS. So I wouldn’t call it a token (which implies some >> form of protection to me). But it is still a useful data structure to carry >> around. >> >>> On 2020-03-06, at 20:59, Smith, Ned <ned.sm...@intel.com> wrote: >>> >>> The earlier thread suggested that a naked token could be given to a parser >>> that was programmed correctly and it would 'just work'. But if the >>> definition of a CWT/JWT is that it must have bounding signature, mac, >>> encryption enveloping, then the parser should reject naked tokens (tagged >>> as such or not). >> >> A CWT decoder would diagnose an UCCS as “not a CWT”. >> A CWT/UCCS decoder would diagnose it as “UCCS”. >> >>> If the naked token is defined and the map has a tag that indicates it was >>> formed without secure enveloping then the parser should accept it, but the >>> code using the parser needs to find some other way to ensure security. >> >> Right. An UCCS is only a useful assertion if received over a secure channel >> with the right properties to make it a useful assertion. >> >>> If a parser receives a map with both security enveloping and the naked >>> token tag, then it should return both the map and the security envelope >>> context and let the code using the parser decide if the security context >>> satisfies the security requirement. >> >> Well, it should diagnose this as “not a CWT” (and not an UCCS either). >> >> Grüße, Carsten >> >> _______________________________________________ >> RATS mailing list >> r...@ietf.org >> https://www.ietf.org/mailman/listinfo/rats > > _______________________________________________ > CBOR mailing list > c...@ietf.org > https://www.ietf.org/mailman/listinfo/cbor
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
