CBOR Web Token (CWT)
draft-ietf-ace-cbor-web-token-15

Tiny nit:

Section 8, Security Considerations
"While syntactically, the signing and encryption operations"  -> "While syntactically the signing and encryption operations" (superfluous comma) 

Also, I second Carlos Martinez's comment - the examples are helpful for those not steeped in the art...

Thanks to the WG, chairs, and 

§3.1.1:

>  The "iss" (issuer) claim has the same meaning and processing rules as
>  the "iss" claim defined in Section 4.1.1 of [RFC7519], except that
>  the value is of type StringOrURI.  The Claim Key 1 is used to
>  identify this claim.


1) Given that RFC 7159 defines "iss" to contain a "StringOrURI" value, it's
   not clear what the "except" clause is attempting to convey.

2) Given the many uses of the word "type" in this context (including CBOR
   types and the JWT 'typ' field), and given that RFC 7519 never refers to
   "StringOrURI" as a "type," I think that the use of the word "type" here
   is likely to lead to reader confusion.

This comment -- or a congruent form of it involving "NumericDate" rather than
"StringOrURI" -- applies to §3.1.2 through §3.1.6.

---------------------------------------------------------------------------

§9.1:

>  Criteria that should be applied by the Designated Experts includes
>  determining whether the proposed registration duplicates existing
>  functionality, whether it is likely to be of general applicability or
>  whether it is useful only for a single application, and whether the
>  registration description is clear.  Registrations for the limited set
>  of values between -256 and 255 and strings of length 1 are to be
>  restricted to claims with general applicability.

Use of the word "between" without qualifying it as inclusive or exclusive of the
endpoints is ambiguous. Suggest either "values from -256 to 255" or "values
between -256 and 255 inclusive".

---------------------------------------------------------------------------

§9.1.1:

>     CBOR map key for the claim.  Different ranges of values use
>     different registration policies [RFC8126].  Integer values between
>     -256 and 255 and strings of length 1 are designated as Standards
>     Action.  Integer values from -65536 to 65535 and strings of length
>     2 are designated as Specification Required

Same comment as above.

Also, please replace "from -65536 to 65535" with "from -65536 to -257 and from
256 to 65535".

Just to double check: a CWT claim registration from a Proposed Standard still needs to be submitted to the review mailing list, but it is not really subject to Expert Review, correct? You might want to make it clearer.

Thanks for engaging with the Gen-ART review.

   The claim values defined in this specification MUST NOT be prefixed
   with any CBOR tag.  For instance, while CBOR tag 1 (epoch-based date/
   time) could logically be prefixed to values of the "exp", "nbf", and
   "iat" claims, this is unnecessary, since the representation of the
   claim values is already specified by the claim definitions.  Tagging
   claim values would only take up extra space without adding
   information.  However, this does not prohibit future claim
   definitions from requiring the use of CBOR tags for those specific
   claims.
   
Why do you need a MUST NOT here? This seems like not really an interop requirement


  4.  Verify that the resulting COSE Header includes only parameters
       and values whose syntax and semantics are both understood and
       supported or that are specified as being ignored when not
       understood.
       
I'm surprised to find that this is not a generic 8152 processing rule.
Can you explain why this is necessary here?