CBOR Web Token (CWT)
RFC 8392
Yes
No Objection
Note: This ballot was opened for revision 12 and is now closed.
Alvaro Retana No Objection
Warren Kumari No Objection
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...
(Kathleen Moriarty; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
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".
(Alexey Melnikov; former steering group member) No Objection
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.
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
Thanks for engaging with the Gen-ART review.
(Ben Campbell; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Eric Rescorla; former steering group member) No Objection
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?
(Mirja Kühlewind; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection
(Terry Manderson; former steering group member) No Objection