draft-ietf-oauth-json-web-token-26.txt   draft-ietf-oauth-json-web-token-27.txt 
OAuth Working Group M. Jones OAuth Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: March 27, 2015 Ping Identity Expires: March 29, 2015 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
September 23, 2014 September 25, 2014
JSON Web Token (JWT) JSON Web Token (JWT)
draft-ietf-oauth-json-web-token-26 draft-ietf-oauth-json-web-token-27
Abstract Abstract
JSON Web Token (JWT) is a compact, URL-safe means of representing JSON Web Token (JWT) is a compact, URL-safe means of representing
claims to be transferred between two parties. The claims in a JWT claims to be transferred between two parties. The claims in a JWT
are encoded as a JavaScript Object Notation (JSON) object that is are encoded as a JavaScript Object Notation (JSON) object that is
used as the payload of a JSON Web Signature (JWS) structure or as the used as the payload of a JSON Web Signature (JWS) structure or as the
plaintext of a JSON Web Encryption (JWE) structure, enabling the plaintext of a JSON Web Encryption (JWE) structure, enabling the
claims to be digitally signed or MACed and/or encrypted. claims to be digitally signed or MACed and/or encrypted.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 March 27, 2015. This Internet-Draft will expire on March 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 16, line 22 skipping to change at page 16, line 22
10. IANA Considerations 10. IANA Considerations
10.1. JSON Web Token Claims Registry 10.1. JSON Web Token Claims Registry
This specification establishes the IANA JSON Web Token Claims This specification establishes the IANA JSON Web Token Claims
registry for JWT Claim Names. The registry records the Claim Name registry for JWT Claim Names. The registry records the Claim Name
and a reference to the specification that defines it. This and a reference to the specification that defines it. This
specification registers the Claim Names defined in Section 4.1. specification registers the Claim Names defined in Section 4.1.
Values are registered on a Specification Required [RFC5226] basis Values are registered on a Specification Required [RFC5226] basis
after a two-week review period on the [TBD]@ietf.org mailing list, on after a three-week review period on the [TBD]@ietf.org mailing list,
the advice of one or more Designated Experts. However, to allow for on the advice of one or more Designated Experts. However, to allow
the allocation of values prior to publication, the Designated for the allocation of values prior to publication, the Designated
Expert(s) may approve registration once they are satisfied that such Expert(s) may approve registration once they are satisfied that such
a specification will be published. a specification will be published.
Registration requests must be sent to the [TBD]@ietf.org mailing list Registration requests must be sent to the [TBD]@ietf.org mailing list
for review and comment, with an appropriate subject (e.g., "Request for review and comment, with an appropriate subject (e.g., "Request
for access token type: example"). [[ Note to the RFC Editor: The name for access token type: example"). [[ Note to the RFC Editor: The name
of the mailing list should be determined in consultation with the of the mailing list should be determined in consultation with the
IESG and IANA. Suggested name: jwt-reg-review. ]] IESG and IANA. Suggested name: jwt-reg-review. ]]
Within the review period, the Designated Expert(s) will either Within the review period, the Designated Expert(s) will either
skipping to change at page 21, line 45 skipping to change at page 21, line 45
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", RFC 6755, October 2012. for OAuth", RFC 6755, October 2012.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
13.2. Informative References 13.2. Informative References
[CanvasApp] [CanvasApp]
Facebook, "Canvas Applications", 2010. Facebook, "Canvas Applications", 2010.
skipping to change at page 23, line 24 skipping to change at page 23, line 21
A.1. Example Encrypted JWT A.1. Example Encrypted JWT
This example encrypts the same claims as used in Section 3.1 to the This example encrypts the same claims as used in Section 3.1 to the
recipient using RSAES-PKCS1-V1_5 and AES_128_CBC_HMAC_SHA_256. recipient using RSAES-PKCS1-V1_5 and AES_128_CBC_HMAC_SHA_256.
The following example JOSE Header declares that: The following example JOSE Header declares that:
o the Content Encryption Key is encrypted to the recipient using the o the Content Encryption Key is encrypted to the recipient using the
RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key and RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key and
o the Plaintext is encrypted using the AES_128_CBC_HMAC_SHA_256 o authenticated encryption is performed on the Plaintext using the
algorithm to produce the JWE Ciphertext. AES_128_CBC_HMAC_SHA_256 algorithm to produce the JWE Ciphertext
and the JWE Authentication Tag.
{"alg":"RSA1_5","enc":"A128CBC-HS256"} {"alg":"RSA1_5","enc":"A128CBC-HS256"}
Other than using the octets of the UTF-8 representation of the JWT Other than using the octets of the UTF-8 representation of the JWT
Claims Set from Section 3.1 as the plaintext value, the computation Claims Set from Section 3.1 as the plaintext value, the computation
of this JWT is identical to the computation of the JWE in Appendix of this JWT is identical to the computation of the JWE in Appendix
A.2 of [JWE], including the keys used. A.2 of [JWE], including the keys used.
The final result in this example (with line breaks for display The final result in this example (with line breaks for display
purposes only) is: purposes only) is:
skipping to change at page 24, line 21 skipping to change at page 24, line 21
The inner signed JWT is identical to the example in Appendix A.2 of The inner signed JWT is identical to the example in Appendix A.2 of
[JWS]. Therefore, its computation is not repeated here. This [JWS]. Therefore, its computation is not repeated here. This
example then encrypts this inner JWT to the recipient using RSAES- example then encrypts this inner JWT to the recipient using RSAES-
PKCS1-V1_5 and AES_128_CBC_HMAC_SHA_256. PKCS1-V1_5 and AES_128_CBC_HMAC_SHA_256.
The following example JOSE Header declares that: The following example JOSE Header declares that:
o the Content Encryption Key is encrypted to the recipient using the o the Content Encryption Key is encrypted to the recipient using the
RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key, RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key,
o the Plaintext is encrypted using the AES_128_CBC_HMAC_SHA_256 o authenticated encryption is performed on the Plaintext using the
algorithm to produce the JWE Ciphertext, and AES_128_CBC_HMAC_SHA_256 algorithm to produce the JWE Ciphertext
and the JWE Authentication Tag, and
o the Plaintext is itself a JWT. o the Plaintext is itself a JWT.
{"alg":"RSA1_5","enc":"A128CBC-HS256","cty":"JWT"} {"alg":"RSA1_5","enc":"A128CBC-HS256","cty":"JWT"}
Base64url encoding the octets of the UTF-8 representation of the JOSE Base64url encoding the octets of the UTF-8 representation of the JOSE
Header yields this encoded JOSE Header value: Header yields this encoded JOSE Header value:
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0 eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0
skipping to change at page 26, line 39 skipping to change at page 26, line 40
Solutions for signing JSON content were previously explored by Magic Solutions for signing JSON content were previously explored by Magic
Signatures [MagicSignatures], JSON Simple Sign [JSS], and Canvas Signatures [MagicSignatures], JSON Simple Sign [JSS], and Canvas
Applications [CanvasApp], all of which influenced this draft. Applications [CanvasApp], all of which influenced this draft.
This specification is the work of the OAuth Working Group, which This specification is the work of the OAuth Working Group, which
includes dozens of active and dedicated participants. In particular, includes dozens of active and dedicated participants. In particular,
the following individuals contributed ideas, feedback, and wording the following individuals contributed ideas, feedback, and wording
that influenced this specification: that influenced this specification:
Dirk Balfanz, Richard Barnes, Brian Campbell, Breno de Medeiros, Dick Dirk Balfanz, Richard Barnes, Brian Campbell, Breno de Medeiros, Dick
Hardt, Joe Hildebrand, Jeff Hodges, Edmund Jay, Yaron Y. Goland, Ben Hardt, Joe Hildebrand, Jeff Hodges, Edmund Jay, Yaron Y. Goland,
Laurie, James Manger, Prateek Mishra, Kathleen Moriarty, Tony Warren Kumari, Ben Laurie, James Manger, Prateek Mishra, Kathleen
Nadalin, Axel Nennker, John Panzer, Emmanuel Raviart, David Recordon, Moriarty, Tony Nadalin, Axel Nennker, John Panzer, Emmanuel Raviart,
Eric Rescorla, Jim Schaad, Paul Tarjan, Hannes Tschofenig, and Sean David Recordon, Eric Rescorla, Jim Schaad, Paul Tarjan, Hannes
Turner. Tschofenig, Sean Turner, and Tom Yu.
Hannes Tschofenig and Derek Atkins chaired the OAuth working group Hannes Tschofenig and Derek Atkins chaired the OAuth working group
and Sean Turner, Stephen Farrell, and Kathleen Moriarty served as and Sean Turner, Stephen Farrell, and Kathleen Moriarty served as
Security area directors during the creation of this specification. Security area directors during the creation of this specification.
Appendix E. Document History Appendix E. 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 ]]
-27
o Removed unused reference to RFC 4648.
o Changed to use the term "authenticated encryption" instead of
"encryption", where appropriate.
o Changed the registration review period to three weeks.
o Acknowledged additional contributors.
-26 -26
o Removed an ambiguity in numeric date representations by specifying o Removed an ambiguity in numeric date representations by specifying
that leap seconds are handled in the manner specified by POSIX.1. that leap seconds are handled in the manner specified by POSIX.1.
o Addressed Gen-ART review comments by Russ Housley. o Addressed Gen-ART review comments by Russ Housley.
o Addressed secdir review comments by Warren Kumari and Stephen o Addressed secdir review comments by Warren Kumari and Stephen
Kent. Kent.
 End of changes. 10 change blocks. 
19 lines changed or deleted 29 lines changed or added

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