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

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Reply via email to