draft-ietf-ace-cbor-web-token-11.txt   draft-ietf-ace-cbor-web-token-12.txt 
ACE Working Group M. Jones ACE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track E. Wahlstroem Intended status: Standards Track E. Wahlstroem
Expires: July 25, 2018 Expires: August 6, 2018
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
ARM Ltd. ARM Ltd.
January 21, 2018 February 2, 2018
CBOR Web Token (CWT) CBOR Web Token (CWT)
draft-ietf-ace-cbor-web-token-11 draft-ietf-ace-cbor-web-token-12
Abstract Abstract
CBOR Web Token (CWT) is a compact means of representing claims to be 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 transferred between two parties. The claims in a CWT are encoded in
the Concise Binary Object Representation (CBOR) and CBOR Object the Concise Binary Object Representation (CBOR) and CBOR Object
Signing and Encryption (COSE) is used for added application layer Signing and Encryption (COSE) is used for added application layer
security protection. A claim is a piece of information asserted security protection. A claim is a piece of information asserted
about a subject and is represented as a name/value pair consisting of 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 a claim name and a claim value. CWT is derived from JSON Web Token
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 25, 2018. This Internet-Draft will expire on August 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 13 skipping to change at page 3, line 13
A.2.1. 128-bit Symmetric Key . . . . . . . . . . . . . . . . 16 A.2.1. 128-bit Symmetric Key . . . . . . . . . . . . . . . . 16
A.2.2. 256-bit Symmetric Key . . . . . . . . . . . . . . . . 17 A.2.2. 256-bit Symmetric Key . . . . . . . . . . . . . . . . 17
A.2.3. ECDSA P-256 256-bit COSE Key . . . . . . . . . . . . 17 A.2.3. ECDSA P-256 256-bit COSE Key . . . . . . . . . . . . 17
A.3. Example Signed CWT . . . . . . . . . . . . . . . . . . . 17 A.3. Example Signed CWT . . . . . . . . . . . . . . . . . . . 17
A.4. Example MACed CWT . . . . . . . . . . . . . . . . . . . . 18 A.4. Example MACed CWT . . . . . . . . . . . . . . . . . . . . 18
A.5. Example Encrypted CWT . . . . . . . . . . . . . . . . . . 19 A.5. Example Encrypted CWT . . . . . . . . . . . . . . . . . . 19
A.6. Example Nested CWT . . . . . . . . . . . . . . . . . . . 20 A.6. Example Nested CWT . . . . . . . . . . . . . . . . . . . 20
A.7. Example MACed CWT with a floating-point value . . . . . . 21 A.7. Example MACed CWT with a floating-point value . . . . . . 21
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 22 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 22
Appendix C. Document History . . . . . . . . . . . . . . . . . . 22 Appendix C. Document History . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The JSON Web Token (JWT) [RFC7519] is a standardized security token The JSON Web Token (JWT) [RFC7519] is a standardized security token
format that has found use in OAuth 2.0 and OpenID Connect format that has found use in OAuth 2.0 and OpenID Connect
deployments, among other applications. JWT uses JSON Web Signature deployments, among other applications. JWT uses JSON Web Signature
(JWS) [RFC7515] and JSON Web Encryption (JWE) [RFC7516] to secure the (JWS) [RFC7515] and JSON Web Encryption (JWE) [RFC7516] to secure the
contents of the JWT, which is a set of claims represented in JSON. contents of the JWT, which is a set of claims represented in JSON.
The use of JSON for encoding information is popular for Web and The use of JSON for encoding information is popular for Web and
native applications, but it is considered inefficient for some native applications, but it is considered inefficient for some
skipping to change at page 10, line 12 skipping to change at page 10, line 12
signatures over encrypted text are not considered valid in many signatures over encrypted text are not considered valid in many
jurisdictions. jurisdictions.
9. IANA Considerations 9. IANA Considerations
9.1. CBOR Web Token (CWT) Claims Registry 9.1. CBOR Web Token (CWT) Claims Registry
This section establishes the IANA "CBOR Web Token (CWT) Claims" This section establishes the IANA "CBOR Web Token (CWT) Claims"
registry. registry.
Values are registered on a Specification Required [RFC5226] basis Depending upon the values being requested, registration requests are
after a three-week review period on the cwt-reg-review@ietf.org evaluated on a Standards Track Required, Specification Required,
mailing list, on the advice of one or more Designated Experts. Expert Review, or Private Use basis [RFC8126] after a three-week
However, to allow for the allocation of values prior to publication, review period on the cwt-reg-review@ietf.org mailing list, on the
the Designated Experts may approve registration once they are advice of one or more Designated Experts. However, to allow for the
satisfied that such a specification will be published. [[ Note to allocation of values prior to publication, the Designated Experts may
the RFC Editor: The name of the mailing list should be determined in approve registration once they are satisfied that such a
consultation with the IESG and IANA. Suggested name: cwt-reg- specification will be published. [[ Note to the RFC Editor: The name
review@ietf.org. ]] of the mailing list should be determined in consultation with the
IESG and IANA. Suggested name: cwt-reg-review@ietf.org. ]]
Registration requests sent to the mailing list for review should use Registration requests sent to the mailing list for review should use
an appropriate subject (e.g., "Request to register claim: example"). an appropriate subject (e.g., "Request to register claim: example").
Registration requests that are undetermined for a period longer than Registration requests that are undetermined for a period longer than
21 days can be brought to the IESG's attention (using the 21 days can be brought to the IESG's attention (using the
iesg@ietf.org mailing list) for resolution. iesg@ietf.org mailing list) for resolution.
Criteria that should be applied by the Designated Experts includes Criteria that should be applied by the Designated Experts includes
determining whether the proposed registration duplicates existing determining whether the proposed registration duplicates existing
functionality, whether it is likely to be of general applicability or functionality, whether it is likely to be of general applicability or
whether it is useful only for a single application, and whether the whether it is useful only for a single application, and whether the
registration description is clear. 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.
It is suggested that multiple Designated Experts be appointed who are It is suggested that multiple Designated Experts be appointed who are
able to represent the perspectives of different applications using able to represent the perspectives of different applications using
this specification in order to enable broadly informed review of this specification in order to enable broadly informed review of
registration decisions. In cases where a registration decision could registration decisions. In cases where a registration decision could
be perceived as creating a conflict of interest for a particular be perceived as creating a conflict of interest for a particular
Expert, that Expert should defer to the judgment of the other Expert, that Expert should defer to the judgment of the other
Experts. Experts.
9.1.1. Registration Template 9.1.1. Registration Template
skipping to change at page 11, line 10 skipping to change at page 11, line 14
JWT Claim Name: JWT Claim Name:
Claim Name of the equivalent JWT claim, as registered in Claim Name of the equivalent JWT claim, as registered in
[IANA.JWT.Claims]. CWT claims should normally have a [IANA.JWT.Claims]. CWT claims should normally have a
corresponding JWT claim. If a corresponding JWT claim would not corresponding JWT claim. If a corresponding JWT claim would not
make sense, the Designated Experts can choose to accept make sense, the Designated Experts can choose to accept
registrations for which the JWT Claim Name is listed as "N/A". registrations for which the JWT Claim Name is listed as "N/A".
Claim Key: Claim Key:
CBOR map key for the claim. Integer values between -256 and 255 CBOR map key for the claim. Integer values between -256 and 255
and strings of length 1 are designated as Standards Track Document and strings of length 1 are designated as Standards Track
required. Integer values from -65536 to 65535 and strings of Required. Integer values from -65536 to 65535 and strings of
length 2 are designated as Specification Required. Integer values length 2 are designated as Specification Required. Integer values
of greater than 65535 and strings of length greater than 2 are of greater than 65535 and strings of length greater than 2 are
designated as expert review. Integer values less than -65536 are designated as Expert Review. Integer values less than -65536 are
marked as private use. marked as Private Use.
Claim Value Type(s): Claim Value Type(s):
CBOR types that can be used for the claim value. CBOR types that can be used for the claim value.
Change Controller: Change Controller:
For Standards Track RFCs, list the "IESG". For others, give the For Standards Track RFCs, list the "IESG". For others, give the
name of the responsible party. Other details (e.g., postal name of the responsible party. Other details (e.g., postal
address, email address, home page URI) may also be included. address, email address, home page URI) may also be included.
Specification Document(s): Specification Document(s):
skipping to change at page 14, line 24 skipping to change at page 14, line 24
This section registers the CWT CBOR tag in the "CBOR Tags" registry This section registers the CWT CBOR tag in the "CBOR Tags" registry
[IANA.CBOR.Tags]. [IANA.CBOR.Tags].
9.4.1. Registry Contents 9.4.1. Registry Contents
o CBOR Tag: TBD (maybe 61 to use the same value as the Content- o CBOR Tag: TBD (maybe 61 to use the same value as the Content-
Format) Format)
o Data Item: CBOR Web Token (CWT) o Data Item: CBOR Web Token (CWT)
o Semantics: CBOR Web Token (CWT), as defined in [[ this o Semantics: CBOR Web Token (CWT), as defined in [[ this
specification ]] specification ]]
o Reference: [[ this specification ]] o Description of Semantics: [[ this specification ]]
o Point of Contact: Michael B. Jones, mbj@microsoft.com o Point of Contact: Michael B. Jones, mbj@microsoft.com
10. References 10. References
10.1. Normative References 10.1. Normative References
[IANA.CBOR.Tags] [IANA.CBOR.Tags]
IANA, "Concise Binary Object Representation (CBOR) Tags", IANA, "Concise Binary Object Representation (CBOR) Tags",
<http://www.iana.org/assignments/cbor-tags/ <http://www.iana.org/assignments/cbor-tags/
cbor-tags.xhtml>. cbor-tags.xhtml>.
skipping to change at page 15, line 23 skipping to change at page 15, line 23
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 10.2. Informative References
[IANA.JWT.Claims] [IANA.JWT.Claims]
IANA, "JSON Web Token Claims", IANA, "JSON Web Token Claims",
<http://www.iana.org/assignments/jwt>. <http://www.iana.org/assignments/jwt>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>. 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015, RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>. <https://www.rfc-editor.org/info/rfc7516>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Appendix A. Examples Appendix A. Examples
This appendix includes a set of CWT examples that show how the CWT This appendix includes a set of CWT examples that show how the CWT
Claims Set can be protected. There are examples that are signed, Claims Set can be protected. There are examples that are signed,
MACed, encrypted, and that use nested signing and encryption. To MACed, encrypted, and that use nested signing and encryption. To
make the examples easier to read, they are presented both as hex make the examples easier to read, they are presented both as hex
strings and in the extended CBOR diagnostic notation described in strings and in the extended CBOR diagnostic notation described in
Section 6 of [RFC7049]. Section 6 of [RFC7049].
Where a byte string is to carry an embedded CBOR-encoded item, the Where a byte string is to carry an embedded CBOR-encoded item, the
skipping to change at page 22, line 31 skipping to change at page 22, line 31
notation notation
Appendix B. Acknowledgements Appendix B. Acknowledgements
This specification is based on JSON Web Token (JWT) [RFC7519], the This specification is based on JSON Web Token (JWT) [RFC7519], the
authors of which also include Nat Sakimura and John Bradley. It also authors of which also include Nat Sakimura and John Bradley. It also
incorporates suggestions made by many people, including Carsten incorporates suggestions made by many people, including Carsten
Bormann, Esko Dijk, Benjamin Kaduk, Jim Schaad, Ludwig Seitz, and Bormann, Esko Dijk, Benjamin Kaduk, Jim Schaad, Ludwig Seitz, and
Goeran Selander. Goeran Selander.
[[ RFC Editor: Is it possible to preserve the non-ASCII spellings of
the names Erik Wahlstroem and Goeran Selander in the final
specification? ]]
Appendix C. Document History Appendix C. Document History
[[ to be removed by the RFC Editor before publication as an RFC ]] [[ to be removed by the RFC Editor before publication as an RFC ]]
-12
o Updated the RFC 5226 reference to RFC 8126.
o Made the IANA registration criteria consistent across sections.
o Stated that 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.
o Changed the "Reference" field name to "Description of Semantics"
in the CBOR Tag registration request.
o Asked the RFC Editor whether it is possible to preserve the non-
ASCII spellings of the names Erik Wahlstroem and Goeran Selander
in the final specification.
-11 -11
o Corrected the "iv" value in the signed and encrypted CWT example. o Corrected the "iv" value in the signed and encrypted CWT example.
o Mention CoAP in the "application/cwt" media type registration. o Mention CoAP in the "application/cwt" media type registration.
o Changed references of the form "Section 4.1.1 of JWT <xref o Changed references of the form "Section 4.1.1 of JWT <xref
target="RFC7519"/>" to "Section 4.1.1 of <xref target="RFC7519"/>" target="RFC7519"/>" to "Section 4.1.1 of <xref target="RFC7519"/>"
so that rfcmarkup will generate correct external section reference so that rfcmarkup will generate correct external section reference
links. links.
 End of changes. 14 change blocks. 
25 lines changed or deleted 49 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/