Re: [Ace] Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)
It might make more sense to prefix the JWT versions as not being what is here. Jim > -Original Message- > From: Mike Jones [mailto:michael.jo...@microsoft.com] > Sent: Wednesday, March 7, 2018 9:47 PM > To: Benjamin Kaduk <ka...@mit.edu>; Adam Roach <a...@nostrum.com> > Cc: The IESG <i...@ietf.org>; draft-ietf-ace-cbor-web-to...@ietf.org; ace- > cha...@ietf.org; ace@ietf.org > 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 <ka...@mit.edu> > Sent: Wednesday, March 7, 2018 8:24 PM > To: Adam Roach <a...@nostrum.com> > Cc: The IESG <i...@ietf.org>; draft-ietf-ace-cbor-web-to...@ietf.org; ace- > cha...@ietf.org; ace@ietf.org > 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 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)
Fair enough. I'll work on alternate exposition for these types to avoid any potential confusion. Thanks again, -- Mike -Original Message- From: Adam Roach <a...@nostrum.com> Sent: Wednesday, March 7, 2018 10:28 PM To: Mike Jones <michael.jo...@microsoft.com>; Benjamin Kaduk <ka...@mit.edu> Cc: The IESG <i...@ietf.org>; draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org; ace@ietf.org Subject: Re: Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT) On 3/7/18 11:47 PM, Mike Jones wrote: > 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. Given that the current formulation confused both Benjamin and me, I think this assertion doesn't hold up to scrutiny. /a ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)
On 3/7/18 11:47 PM, Mike Jones wrote: 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. Given that the current formulation confused both Benjamin and me, I think this assertion doesn't hold up to scrutiny. /a ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] 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 <ka...@mit.edu> Sent: Wednesday, March 7, 2018 8:24 PM To: Adam Roach <a...@nostrum.com> Cc: The IESG <i...@ietf.org>; draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org; ace@ietf.org 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 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
