CBOR Web Token (CWT)
draft-ietf-ace-cbor-web-token-15

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

[Ballot comment]
  The claim values defined in this specification MUST NOT be prefixed
  with any CBOR tag.  For instance, while CBOR tag 1 (epoch-based date/
  time) could logically be prefixed to values of the "exp", "nbf", and
  "iat" claims, this is unnecessary, since the representation of the
  claim values is already specified by the claim definitions.  Tagging
  claim values would only take up extra space without adding
  information.  However, this does not prohibit future claim
  definitions from requiring the use of CBOR tags for those specific
  claims.
 
Why do you need a MUST NOT here? This seems like not really an interop requirement


  4.  Verify that the resulting COSE Header includes only parameters
      and values whose syntax and semantics are both understood and
      supported or that are specified as being ignored when not
      understood.
     
I'm surprised to find that this is not a generic 8152 processing rule.
Can you explain why this is necessary here?

[Ballot comment]
Tiny nit:

Section 8, Security Considerations
"While syntactically, the signing and encryption operations"  -> "While syntactically the signing and encryption operations" (superfluous comma)

Also, I second Carlos Martinez's comment - the examples are helpful for those not steeped in the art...

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-ace-cbor-web-token-12. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are four actions which we must complete.

First, a new registry is to be created called the CBOR Web Token (CWT) Claims registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The registration procedure for the new registry depends upon the CWT Claim Key and can be summarized as follows:

Where the CWT Claim Key is an integer:

CWT Claim Key Registration Procedure
---------------------+------------------------
< -65536 Private Use
-65536 to 65535 Specification Required
Hide quoted text
> 65535 Expert Review

Where the CWT Clain Key is a string:

CWT Claim Key Registration Procedure
---------------------+------------------------
string, length =1 Standards Track Required
string, length =2 Specification Required
string, length >2 Expert Review

Depending upon the values being requested, registration requests are evaluated on a Standards Track Required, Specification Required, Expert Review, or Private Use basis [see RFC 8126] after a three-week review period on the cwt-reg-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published.

IANA Question --> Will requestors send templates to the list, or will requestors send templates to IANA to send to the list?
The reference for the new registry is [ RFC-to-be ]. In the former case, we understand that experts would send approved requests directly to IANA. If the latter is true, would experts send approved requests to IANA, or would IANA need to check in after three weeks?

Claim Claim JWT Claim Claim Reference
Name Description Claim Name Key Type
----------+-------------------------+----------+------+-------+-------------
(reserved) This reservation reserves N/A 0 N/A [ RFC-to-be ]
the Key value 1
iss Issuer iss 1 text [ RFC-to-be ]
string
sub Subject sub 2 text [ RFC-to-be ]
string
aud Audience aud 3 text [ RFC-to-be ]
string
exp Expiration Time exp 4 integer [ RFC-to-be ]
or
floating
point
number
nbf Not Before nbf 5 integer [ RFC-to-be ]
or
floating
point
number
iat Issued At iat 6 integer [ RFC-to-be ]
or
floating
point
number
cti CWT ID jti 7 byte [ RFC-to-be ]
string

In addition for the new registry, another column will be added titled: Change Controller. For all the initial entries in the new registry, the change controller will be the IESG.

Second, in the application space of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a new media type will be registered as follows:

Name: cwt
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Third, in the CoAP Content-Formats regsitry on the Constrained RESTful Environments (CoRE) Parameters regsitry page located at:

https://www.iana.org/assignments/core-parameters/

a new registration will be made as follows:

Media Type: application/cwt
Encoding:
ID [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested a value of 61 for this registration.

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fourth, in the CBOR Tags registry on the Concise Binary Object Representation (CBOR) Tags registry page located at:

https://www.iana.org/assignments/cbor-tags/

the existing registration for the following CBOR Tag

CBOR Web Token (CWT)

will be updated to have its reference changed to [ RFC-to-be ].

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.
Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

[Ballot comment]
Just to double check: a CWT claim registration from a Proposed Standard still needs to be submitted to the review mailing list, but it is not really subject to Expert Review, correct? You might want to make it clearer.

The following Last Call announcement was sent out (ends 2018-03-06):

From: The IESG
To: IETF-Announce
CC: Kathleen.Moriarty.ietf@gmail.com, ace-chairs@ietf.org, kaduk@mit.edu, draft-ietf-ace-cbor-web-token@ietf.org, ace@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (CBOR Web Token (CWT)) to Proposed Standard


The IESG has received a request from the Authentication and Authorization for
Constrained Environments WG (ace) to consider the following document: - 'CBOR
Web Token (CWT)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  CBOR Web Token (CWT) is a compact means of representing claims to be
  transferred between two parties.  The claims in a CWT are encoded in
  the Concise Binary Object Representation (CBOR) and CBOR Object
  Signing and Encryption (COSE) is used for added application layer
  security protection.  A claim is a piece of information asserted
  about a subject and is represented as a name/value pair consisting of
  a claim name and a claim value.  CWT is derived from JSON Web Token
  (JWT) but uses CBOR rather than JSON.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ballot/


No IPR declarations have been submitted directly on this I-D.