Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Dan Romascanu [mailto:[e-mail]]
> Sent: Monday, February 26, 2018 11:03 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Genart telechat review of draft-ietf-ace-cbor-web-token-12
> 
> Reviewer: Dan Romascanu
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair. Please wait for direction from your document shepherd or AD
> before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-ace-cbor-web-token-12
> Reviewer: Dan Romascanu
> Review Date: 2018-02-26
> IETF LC End Date: 2018-03-06
> IESG Telechat date: 2018-03-08
> 
> Summary:
> 
> This is a clear and detailed specification, which is almost ready for
> publications. There are however a couple of issues that I recommend to be
> discussed and addressed before the document is approved.
> 
> Major issues:
> 
> 1. CWT is derived from JWT (RFC 7519) using CBOR rather than JSON for
> encoding.
> The rationale as explained in the document is related to efficiency for some
> IoT systems. The initial claims registry defined in Section 9.1 is identical
> (semantically) with the initial claims registry defined in Section 10.1 of RFC
> 7519. Is this parallelism supposed to continue? If the two registries will
> continue to evolve in parallel, maybe there should be a mechanism at IANA to
> make this happen. Was this discussed by the WG? Maybe there is a need to
> include some text about the relationship between the two registries.

This is probably a YMMV answer.   Personally, I expect that there is going to be divergence between the two registries but I currently do not have any examples to support this answer.  The main reason for my supposition that I am guessing that CWT may be used in a wider set of situations, but again I cannot support this.

> 
> 2. I am a little confused by the definition of policies in Section 9.1:
> 
>    Depending upon the values being requested, registration requests are
>    evaluated on a Standards Track Required, Specification Required,
>    Expert Review, or Private Use basis [RFC8126] after a three-week
>    review period on the [e-mail] mailing list, on the
>    advice of one or more Designated Experts.
> 
> How does this work? The request is forwarded to the designated expert,
> he/she make a recommendation concerning the policy on the mail list, and
> depending on the feedback received a policy is selected? Who establishes
> consensus?
> 
> Frankly, I wonder if this can work at all. Are there other examples of four
> different policies for the same registry, applied on a case-to-case basis?

This is the same approach that is being used for the COSE registries.  As an example, you can look at https://www.iana.org/assignments/cose/cose.xhtml#algorithms.

Part of the issue about this is that the JOSE/JWT registries do have the same different policies, but that differences are hidden from the IANA registry.  Since they allow for a URI to be used as the identifier of a field, only the plain text versions are registered.  Thus I can use "http://augustcellars.com/JWT/My_Tag" as an identifier.  Since for CBOR the set of tag values is closed and does not have this escape (nor would one want the length of the tag) it is necessary to have this break down of tag fields.

Jim


> 
> I would also observe that this is different from the policy defined for the
> parallel registry for JWT (Section 10.1 in RFC 7519) which is Specification
> Required.
> 
> Minor issues:
> 
> Nits/editorial comments:
>