Adam Roach has entered the following ballot position for
draft-ietf-ace-cbor-web-token-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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".


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Reply via email to