Telechat Review of draft-ietf-ace-cbor-web-token-12

Request Review of draft-ietf-ace-cbor-web-token
Requested rev. no specific revision (document currently at 15)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-03-06
Requested 2018-02-15
Authors Michael Jones, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig
Draft last updated 2018-02-26
Completed reviews Secdir Telechat review of -12 by Kyle Rose (diff)
Opsdir Telechat review of -12 by Carlos Martínez (diff)
Genart Telechat review of -12 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu
State Completed
Review review-ietf-ace-cbor-web-token-12-genart-telechat-romascanu-2018-02-26
Reviewed rev. 12 (document currently at 15)
Review result Almost Ready
Review completed: 2018-02-26


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


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


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. 

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 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? 

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: