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

[Jim Schaad <[e-mail]>]

It might make more sense to prefix the JWT versions as not being what is
here.

Jim


> -----Original Message-----
> From: Mike Jones [mailto:[e-mail]]
> Sent: Wednesday, March 7, 2018 9:47 PM
> To: Benjamin Kaduk <[e-mail]>; Adam Roach <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; ace-
> [e-mail]; [e-mail]
> Subject: RE: Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-
> 13: (with COMMENT)
> 
> 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]; ace-
> [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