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

From: Adam Roach <[email-masked]>
Date: Wed, 07 Mar 2018 16:05:32 -0800

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 7 Mar 2018 22:24:15 -0600

Hi Adam,

With my shepherd hat...

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

>    is likely to lead to reader confusion.

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

> "StringOrURI" -- applies to §3.1.2 through §3.1.6.

(Right.)

Agreed, it should be qualified as inclusive.

Good catch!

Thanks,

Ben

---

From: Mike Jones <[email-masked]>
Date: Thu, 8 Mar 2018 05:47:13 +0000

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 <[email-masked]> 
Sent: Wednesday, March 7, 2018 8:24 PM
To: Adam Roach <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
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:
> >  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.
> 
> 

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.

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

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

> -----

Good catch!

Thanks,

Ben

---

From: Adam Roach <[email-masked]>
Date: Thu, 8 Mar 2018 00:27:51 -0600

> 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 cont…

Given that the current formulation confused both Benjamin and me, I 
think this assertion doesn't hold up to scrutiny.

/a

---

From: Mike Jones <[email-masked]>
Date: Thu, 8 Mar 2018 06:58:32 +0000

Fair enough.  I'll work on alternate exposition for these types to avoid any potential confusion.

				Thanks again,
				-- Mike

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

> 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 cont…

Given that the current formulation confused both Benjamin and me, I think this assertion doesn't hold up to scrutiny.

/a

---

From: Jim Schaad <[email-masked]>
Date: Thu, 8 Mar 2018 08:19:07 -0800

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

Jim

> From: Mike Jones [mailto:[email-masked]]
> Sent: Wednesday, March 7, 2018 9:47 PM
> To: Benjamin Kaduk <[email-masked]>; Adam Roach <[email-masked]>
> Subject: RE: Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-
> 13: (with COMMENT)
> 
> 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.
> 
> I had to ask about this as well -- the crux is that the "StringOrURI" JWT
type is
> different from the CWT "StringOrURI"
removed as
> redundant.