Re: [Rats] Vetting claim definitions

So in conclusion, all claims for JWT are:

Specification Required

and CWT claims are in 4 categories:

Standards Action
Specification Required
Expert Review
Private Use

Rather than trying to further refine or control or restrict or manage what claims can be registered, I propose a different approach. We do the two following work:

1) Do the work here and up front to define lots of good claims in a standards-track RFCs. Maybe over time it is several RFCs. When we do this work we should consider previous work on JWT, CWT, YANG, ASN.1 and such claims and try to avoid duplication.

2) We create profiles that list recommended claims for different use cases (router, small IoT consumer IoT device, mobile phone…). Maybe some are standard track RFCs or maybe some are just informational. Also we know other organizations will do some of this work (GlobalPlatform, FIDO). 

So registration of new claims related to attestation is just the same as it is for CWT and JWT claims today.

LL

> On Jun 5, 2019, at 10:30 AM, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:
> 
> Actually, normal (non-collision-resistant) JWT claims *are* allocated on a specification required basis with expert review.  See this text at https://tools.ietf.org/html/rfc7519#section-10.1 <https://tools.ietf.org/html/rfc7519#section-10.1>:
>  
>    Values are registered on a Specification Required [RFC5226 <https://tools.ietf.org/html/rfc5226>] basis
>    after a three-week review period on the jwt-reg-review@ietf.org
>    mailing list, on the advice of one or more Designated Experts.
>    However, to allow for the allocation of values prior to publication,
>    the Designated Experts may approve registration once they are
>    satisfied that such a specification will be published.
>  
> So a specification can easily register both JWT and CWT claims.
>  
>                                                        -- Mike
>  
> From: Laurence Lundblade <lgl@island-resort.com> 
> Sent: Wednesday, June 5, 2019 8:46 AM
> To: Michael Richardson <mcr+ietf@sandelman.ca>
> Cc: rats@ietf.org; Mike Jones <Michael.Jones@microsoft.com>
> Subject: Re: [Rats] Vetting claim definitions
>  
> Below…
> + Mike Jones, co-author of CWT
> 
> 
> On Jun 5, 2019, at 6:05 AM, Michael Richardson <mcr+ietf@sandelman.ca <mailto:mcr+ietf@sandelman.ca>> wrote:
>  
> 
> Laurence Lundblade <lgl@island-resort.com <mailto:lgl@island-resort.com>> wrote:
> 
> — Today CWT allocates millions of slots for expert review. No
> specification is required, but some information should be provided.
> 
> 
> JWT doesn’t seem to have this, which is maybe why it is messier. It
> kind of seems bad and wrong that it doesn’t to me.
> 
> JWT doesn't have this because the claims are "unlimited" length strings, so
> one can always make up a unique string in lieu of registration.
>  org.island-resort.lgl.whateverstringyouwant
> 
> is probably completely yours :-)
> Of course, if you want to interoperate you need to agree about how, so there
> are some advantages of a forcing function that demands you write things down
> first :-)
>  
> Unlimited length string claim names are fully part of CWT. Also, COSE allows them for headers, algorithm names and such too. So from a syntax view CWT and COSE are the same as JWT in allowing long string names.
>  
> However, COSE and CWT are different in the management of the string name space:
>  
> Strings of length 1            Standards Action
> Strings of length 2            Specification Required
> Strings of length greater than 2    Expert Review
>  
> These, along with the integer names space rules, then imply:
>  
> Integer values less than -65536 are the only ones free for use with no review or processing by IANA and experts.
>  
> JWT also has this notion of Collision-Resistant Name based on OIDs or UUIDs, which is essentially some rules to make up names that don’t go into an IANA registry and are still unique and won’t collide.
>  
> JWT could have done what CWT does. Seems to me that CWT has taken a radically more managed approach to the super-open JWT approach. Maybe the CWT folks realized the JWT design was poor.
>  
>  
> At any rate, there seems to be some consensus here that the CWT approach is what we want for attestation. It is also the more recent and thus maybe more advanced thinking.
>  
> I’m hoping we can find our way to just accept the CWT claim naming management scheme as is for attestation. If other CWT-based efforts did the same (draft-birkholz-core-coid) did the same then the world would be much simpler. 
>  
> However that still leaves open some issue with JWT namespace management. (We do want JSON based attestation to be JWT’s, right? Just the same as CBOR-based attestation are CWT’s).
>  
> LL
>  
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats