1. Summary
Benjamin Kaduk is the document shepherd; Kathleen Moriarty is the
responsible Area Director.
draft-ietf-ace-cbor-web-token is intended to provide a compact way
of representing web tokens (including claims about subject, scope,
audience, etc.) for use in constrained environments where reducing
payload size is important. It is essentially a direct translation of
the JSON Web Token (JWT) to use CBOR and COSE instead of JSON and JOSE.
JWT has been highly successful in the web world, and it is pretty
natural to condense it down and reuse the same core technology in more
constrained environments.
Since JWT (RFC 7519) is a Proposed Standard, it is natural for CWT to
seek the same Proposed Standard status, as the technology is essentially
identical.
2. Review and Consensus
The document was not controversial, and received a great deal of
review from many participants. A first WGLC revealed a few issues
that required enough changes that a second WGLC was made. The second
WGLC attracted fewer comments, but the document is largely unchanged
from the first WGLC, and we believe it to be in good shape.
There are multiple implementations of this document, and the examples
have been validated by at least two implementations. This document
is an important part of the ecosystem, with several specifications
both inside and outside the IETF already referring to it.
3. Intellectual Property
There are no IPR declarations against the document, and the authors have
confirmed their compliance with BCPs 78 and 79.
4. Other Points
The general rule for this document has been to change as little as
possible from JWT, so there is some risk that some lessons from JWT
deployment experience have not been adopted in favor of minimizing
changes. One specific area in which the precedent of JWT is adhered to
is in the "contextualness" of CWTs, namely that it is assumed that two
parties exchanging CWTs have some external context to indicate the
expected nature of the content, what specific CWT profile is in use,
etc.; there is not an explicit field to indicate what profile is in use
or the "type" of this CWT. Since unrecognized fields are ignored, there
could be case where a CWT might be misinterpreted if transmitted by
accident or attacker in the "wrong context".
This document requests a new media type assignment from IANA that
requires expert review; this request has already been sent to
media-types@iana.org.
This document requests a new CoAP Content-Formats assignment from IANA
with a suggested value in the "Expert Review" space; this request has
not yet been sent to IANA for review.
This document requests a new CBOR Tag assignment from IANA; this value
has already been assigned with this document as the reference.
This document establishes a new IANA registry, for CWT Claims. The
contents of this registry will largely correspond to that for JWT
Claims, but divergence is possible and the need to include CBOR-specific
information necessitates a new registry. The guidance to IANA for this
registry largely matches that from RFC 8152 for the various COSE
registries, so it should be acceptable to IANA. The Expert Review
policy (with subranges requiring Standards Track document and
Specification Required, respectively) was chosen because CWT is expected
to be use in a large variety of protocols, both IETF and non-IETF, and
it will be most useful if the various consumers have the flexibility to
specify the claims needed for their applications. The Experts can
provide some sanity checking and avoid duplication without providing too
great of a process barrier. The specified review list,
cwt-reg-review@ietf.org, has not yet been created. Since CWT is
expected to be used in the world of IoT, most designated Experts should
be selected to have IoT experience. However, there are also expected
non-IoT uses, and the pool of Experts should be balanced to include
reviewers with a broader set of knowledge so as to evaluate these
non-IoT requests. Since near-total overlap is expected between the CWT
and JWT registry contents, overlap in the corresponding pools of Experts would
be useful, to help ensure that the appropriate amount of overlap between the
registries is maintained.