draft-ietf-oauth-json-web-token-28.txt   draft-ietf-oauth-json-web-token-29.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: April 17, 2015 Ping Identity Expires: April 20, 2015 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
October 14, 2014 October 17, 2014
JSON Web Token (JWT) JSON Web Token (JWT)
draft-ietf-oauth-json-web-token-28 draft-ietf-oauth-json-web-token-29
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 38 skipping to change at page 1, line 38
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 April 17, 2015. This Internet-Draft will expire on April 20, 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 4, line 44 skipping to change at page 4, line 44
Header", "JWS Compact Serialization", "JWS Payload", "JWS Signature", Header", "JWS Compact Serialization", "JWS Payload", "JWS Signature",
and "Unsecured JWS". and "Unsecured JWS".
These terms defined by the JSON Web Encryption (JWE) [JWE] These terms defined by the JSON Web Encryption (JWE) [JWE]
specification are incorporated into this specification: "JSON Web specification are incorporated into this specification: "JSON Web
Encryption (JWE)", "Content Encryption Key (CEK)", "JWE Compact Encryption (JWE)", "Content Encryption Key (CEK)", "JWE Compact
Serialization", "JWE Encrypted Key", "JWE Initialization Vector", and Serialization", "JWE Encrypted Key", "JWE Initialization Vector", and
"JWE Plaintext". "JWE Plaintext".
These terms defined by the Internet Security Glossary, Version 2 These terms defined by the Internet Security Glossary, Version 2
[RFC4949] are incorporated into this specification: "Ciphertext" and [RFC4949] are incorporated into this specification: "Ciphertext",
"Digital Signature" "Message Authentication Code (MAC)", and
"Plaintext". "Plaintext".
These terms are defined by this specification: These terms are defined by this specification:
JSON Web Token (JWT) JSON Web Token (JWT)
A string representing a set of claims as a JSON object that is A string representing a set of claims as a JSON object that is
encoded in a JWS or JWE, enabling the claims to be digitally encoded in a JWS or JWE, enabling the claims to be digitally
signed or MACed and/or encrypted. signed or MACed and/or encrypted.
JWT Claims Set JWT Claims Set
skipping to change at page 18, line 15 skipping to change at page 18, line 15
o Webpage Title: (same as the protocol category) o Webpage Title: (same as the protocol category)
o Registry Name: JSON Web Token Claims o Registry Name: JSON Web Token Claims
]] ]]
10.1.1. Registration Template 10.1.1. Registration Template
Claim Name: Claim Name:
The name requested (e.g., "example"). Because a core goal of this The name requested (e.g., "iss"). Because a core goal of this
specification is for the resulting representations to be compact, specification is for the resulting representations to be compact,
it is RECOMMENDED that the name be short -- not to exceed 8 it is RECOMMENDED that the name be short -- not to exceed 8
characters without a compelling reason to do so. This name is characters without a compelling reason to do so. This name is
case-sensitive. Names may not match other registered names in a case-sensitive. Names may not match other registered names in a
case-insensitive manner unless the Designated Expert(s) state that case-insensitive manner unless the Designated Expert(s) state that
there is a compelling reason to allow an exception in this there is a compelling reason to allow an exception in this
particular case. particular case.
Claim Description: Claim Description:
Brief description of the Claim (e.g., "Example description"). Brief description of the Claim (e.g., "Issuer").
Change Controller: Change Controller:
For Standards Track RFCs, state "IESG". For others, give the name For Standards Track RFCs, state "IESG". For others, give the name
of the responsible party. Other details (e.g., postal address, of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included. email address, home page URI) may also be included.
Specification Document(s): Specification Document(s):
Reference to the document(s) that specify the parameter, Reference to the document(s) that specify the parameter,
preferably including URI(s) that can be used to retrieve copies of preferably including URI(s) that can be used to retrieve copies of
the document(s). An indication of the relevant sections may also the document(s). An indication of the relevant sections may also
skipping to change at page 22, line 41 skipping to change at page 22, line 41
October 2014. October 2014.
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
draft-ietf-jose-json-web-encryption (work in progress), draft-ietf-jose-json-web-encryption (work in progress),
October 2014. October 2014.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature (work Signature (JWS)", draft-ietf-jose-json-web-signature (work
in progress), October 2014. in progress), October 2014.
[RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20,
October 1969.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
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.
skipping to change at page 24, line 31 skipping to change at page 24, line 34
This section contains examples of JWTs. For other example JWTs, see This section contains examples of JWTs. For other example JWTs, see
Section 6.1 and Appendices A.1, A.2, and A.3 of [JWS]. Section 6.1 and Appendices A.1, A.2, and A.3 of [JWS].
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.
o authenticated encryption is performed on the Plaintext using the o Authenticated encryption is performed on the Plaintext using the
AES_128_CBC_HMAC_SHA_256 algorithm to produce the JWE Ciphertext AES_128_CBC_HMAC_SHA_256 algorithm to produce the JWE Ciphertext
and the JWE Authentication Tag. 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.
skipping to change at page 25, line 30 skipping to change at page 25, line 30
JWS to create a Nested JWT. In this case, the JWT Claims Set is JWS to create a Nested JWT. In this case, the JWT Claims Set is
first signed, and then encrypted. first signed, and then encrypted.
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 authenticated encryption is performed on the Plaintext using the o Authenticated encryption is performed on the Plaintext using the
AES_128_CBC_HMAC_SHA_256 algorithm to produce the JWE Ciphertext AES_128_CBC_HMAC_SHA_256 algorithm to produce the JWE Ciphertext
and the JWE Authentication Tag, and and the JWE Authentication Tag.
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
The computation of this JWT is identical to the computation of the The computation of this JWT is identical to the computation of the
JWE in Appendix A.2 of [JWE], other than that different JOSE Header, JWE in Appendix A.2 of [JWE], other than that different JOSE Header,
Plaintext, JWE Initialization Vector, and Content Encryption Key Plaintext, JWE Initialization Vector, and Content Encryption Key
values are used. (The RSA key used is the same.) values are used. (The RSA key used is the same.)
The Payload used is the octets of the ASCII representation of the JWT The Payload used is the octets of the ASCII [RFC20] representation of
at the end of Appendix A.2.1 of [JWS] (with all whitespace and line the JWT at the end of Appendix A.2.1 of [JWS] (with all whitespace
breaks removed), which is a sequence of 458 octets. and line breaks removed), which is a sequence of 458 octets.
The JWE Initialization Vector value used (using JSON array notation) The JWE Initialization Vector value used (using JSON array notation)
is: is:
[82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53, [82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53,
50] 50]
This example uses the Content Encryption Key represented by the This example uses the Content Encryption Key represented by the
base64url encoded value below: base64url encoded value below:
skipping to change at page 28, line 21 skipping to change at page 28, line 21
Turner, and Tom Yu. 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 ]]
-29
o Used real values for examples in the IANA Registration Template.
-28 -28
o Addressed IESG review comments by Alissa Cooper, Barry Leiba, o Addressed IESG review comments by Alissa Cooper, Barry Leiba,
Stephen Farrell, Ted Lemon, and Richard Barnes. Stephen Farrell, Ted Lemon, and Richard Barnes.
o Changed the RFC 6755 reference to be informative, based upon o Changed the RFC 6755 reference to be informative, based upon
related IESG review feedback on draft-ietf-oauth-saml2-bearer. related IESG review feedback on draft-ietf-oauth-saml2-bearer.
-27 -27
 End of changes. 16 change blocks. 
18 lines changed or deleted 26 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/