Re: [Ace] Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)

[Mike Jones <[e-mail]>]

Thanks, Ben and Adam.  I've recoded a note to address the improvements below one the submission tool reopens.

For what it's worth, I independently noticed the unintended overlap between the Standards Action and Specification Required number ranges in a conversation today with IANA.

The point of including new CWT definitions for "StringOrURI" and "NumericDate" was so that we could use them directly.  Prefixing them with "CWT" isn't necessary for the meaning to be clear in context.

Thanks both for the attention to detail.

				-- Mike

-----Original Message-----
From: Benjamin Kaduk <[e-mail]> 
Sent: Wednesday, March 7, 2018 8:24 PM
To: Adam Roach <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)

Hi Adam,

With my shepherd hat...

On Wed, Mar 07, 2018 at 04:05:32PM -0800, Adam Roach wrote:
> 
> 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.

I had to ask about this as well -- the crux is that the "StringOrURI" JWT type is different from the CWT "StringOrURI"
type.  IIRC there used to be an extra descriptor in here but it was removed as redundant.

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

In combination with the above, maybe we want "the value is a CWT StringOrURI value".  Authors?

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

(Right.)

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

Agreed, it should be qualified as 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".

Good catch!

Thanks,

Ben