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).
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.
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.
-Ned
On 3/6/20, 11:24 AM, "RATS on behalf of Carsten Bormann"
<rats-boun...@ietf.org on behalf of c...@tzi.org> wrote:
Hi Jim,
> On 2020-03-06, at 20:13, Jim Schaad <i...@augustcellars.com> wrote:
>
> There is a very high chance that making this change is going to lead one
into a situation where they are going to need to change their because people
are going to start using this tag all of the time and not just when the claims
are bare.
So it should be made clear that this is not a valid CWT then.
> That is the "unsigned CWT Claims Set" could be passed into the a COSE
library to be signed and the tag would never be stripped.
It obviously could, but so could be many other things, which also wouldn’t
be a CWT.
Grüße, Carsten
_______________________________________________
RATS mailing list
r...@ietf.org
https://www.ietf.org/mailman/listinfo/rats
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
