draft-ietf-oauth-json-web-token-03.txt   draft-ietf-oauth-json-web-token-04.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: January 31, 2013 Ping Identity Expires: April 18, 2013 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
July 30, 2012 October 15, 2012
JSON Web Token (JWT) JSON Web Token (JWT)
draft-ietf-oauth-json-web-token-03 draft-ietf-oauth-json-web-token-04
Abstract Abstract
JSON Web Token (JWT) is a means of representing claims to be JSON Web Token (JWT) is a means of representing claims to be
transferred between two parties. The claims in a JWT are encoded as transferred between two parties. The claims in a JWT are encoded as
a JavaScript Object Notation (JSON) object that is digitally signed a JavaScript Object Notation (JSON) object that is digitally signed
or MACed using JSON Web Signature (JWS) and/or encrypted using JSON or MACed using JSON Web Signature (JWS) and/or encrypted using JSON
Web Encryption (JWE). Web Encryption (JWE).
The suggested pronunciation of JWT is the same as the English word The suggested pronunciation of JWT is the same as the English word
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 January 31, 2013. This Internet-Draft will expire on April 18, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 3, line 41 skipping to change at page 3, line 41
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. JSON Web Token Claims Registry . . . . . . . . . . . . . . 15 9.1. JSON Web Token Claims Registry . . . . . . . . . . . . . . 15
9.1.1. Registration Template . . . . . . . . . . . . . . . . 16 9.1.1. Registration Template . . . . . . . . . . . . . . . . 16
9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 16 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 16
9.2. Sub-Namespace Registration of 9.2. Sub-Namespace Registration of
urn:ietf:params:oauth:token-type:jwt . . . . . . . . . . . 17 urn:ietf:params:oauth:token-type:jwt . . . . . . . . . . . 17
9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 17 9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 17
9.3. JSON Web Signature and Encryption Type Values 9.3. JSON Web Signature and Encryption Type Values
Registration . . . . . . . . . . . . . . . . . . . . . . . 17 Registration . . . . . . . . . . . . . . . . . . . . . . . 17
9.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 17 9.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 17
9.4. Media Type Registration . . . . . . . . . . . . . . . . . 18 9.4. Media Type Registration . . . . . . . . . . . . . . . . . 17
9.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 18 9.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. Example Encrypted JWT . . . . . . . . . . . . . . . . 20
Appendix A. Example Encrypted JWT . . . . . . . . . . . . . . . . 21 Appendix B. Relationship of JWTs to SAML Tokens . . . . . . . . . 21
Appendix B. Relationship of JWTs to SAML Tokens . . . . . . . . . 22 Appendix C. Relationship of JWTs to Simple Web Tokens (SWTs) . . 21
Appendix C. Relationship of JWTs to Simple Web Tokens (SWTs) . . 22 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 21
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 23 Appendix E. Open Issues . . . . . . . . . . . . . . . . . . . . . 22
Appendix E. Document History . . . . . . . . . . . . . . . . . . 23 Appendix F. Document History . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
JSON Web Token (JWT) is a compact token format intended for space JSON Web Token (JWT) is a compact token format intended for space
constrained environments such as HTTP Authorization headers and URI constrained environments such as HTTP Authorization headers and URI
query parameters. JWTs encode claims to be transmitted as a query parameters. JWTs encode claims to be transmitted as a
JavaScript Object Notation (JSON) [RFC4627] object that is base64url JavaScript Object Notation (JSON) [RFC4627] object that is base64url
encoded and digitally signed or MACed and/or encrypted. Signing and encoded and digitally signed or MACed and/or encrypted. Signing and
MACing is performed using JSON Web Signature (JWS) [JWS]. Encryption MACing is performed using JSON Web Signature (JWS) [JWS]. Encryption
is performed using JSON Web Encryption (JWE) [JWE]. is performed using JSON Web Encryption (JWE) [JWE].
skipping to change at page 8, line 9 skipping to change at page 8, line 9
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly
9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ 9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Signing the Encoded JWS Header and Encoded JWS Payload with the HMAC Signing the Encoded JWS Header and Encoded JWS Payload with the HMAC
SHA-256 algorithm and base64url encoding the signature in the manner SHA-256 algorithm and base64url encoding the signature in the manner
specified in [JWS], yields this Encoded JWS Signature: specified in [JWS], yields this Encoded JWS Signature:
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
Concatenating these parts in this order with period characters Concatenating these parts in this order with period ('.') characters
between the parts yields this complete JWT (with line breaks for between the parts yields this complete JWT (with line breaks for
display purposes only): display purposes only):
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
. .
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
. .
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
This computation is illustrated in more detail in [JWS], Appendix This computation is illustrated in more detail in Appendix A.1 of
A.1. See Appendix A for an example of an encrypted JWT. [JWS]. See Appendix A for an example of an encrypted JWT.
4. JWT Claims 4. JWT Claims
The JWT Claims Set represents a JSON object whose members are the The JWT Claims Set represents a JSON object whose members are the
claims conveyed by the JWT. The Claim Names within this object MUST claims conveyed by the JWT. The Claim Names within this object MUST
be unique; JWTs with duplicate Claim Names MUST be rejected. Note be unique; JWTs with duplicate Claim Names MUST be rejected. Note
however, that the set of claims that a JWT must contain to be however, that the set of claims that a JWT must contain to be
considered valid is context-dependent and is outside the scope of considered valid is context-dependent and is outside the scope of
this specification. When used in a security-related context, this specification. When used in a security-related context,
implementations MUST understand and support all of the claims implementations MUST understand and support all of the claims
skipping to change at page 12, line 20 skipping to change at page 12, line 20
Base64url encoding the bytes of the UTF-8 representation of the JSON Base64url encoding the bytes of the UTF-8 representation of the JSON
Claims Set yields this Encoded JWS Payload (with line breaks for Claims Set yields this Encoded JWS Payload (with line breaks for
display purposes only): display purposes only):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
The Encoded JWS Signature is the empty string. The Encoded JWS Signature is the empty string.
Concatenating these parts in this order with period characters Concatenating these parts in this order with period ('.') characters
between the parts yields this complete JWT (with line breaks for between the parts yields this complete JWT (with line breaks for
display purposes only): display purposes only):
eyJhbGciOiJub25lIn0 eyJhbGciOiJub25lIn0
. .
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
. .
7. Rules for Creating and Validating a JWT 7. Rules for Creating and Validating a JWT
skipping to change at page 13, line 29 skipping to change at page 13, line 29
in that step. in that step.
7. Otherwise, let the resulting JWT be the JWS or JWE. 7. Otherwise, let the resulting JWT be the JWS or JWE.
When validating a JWT the following steps MUST be taken. The order When validating a JWT the following steps MUST be taken. The order
of the steps is not significant in cases where there are no of the steps is not significant in cases where there are no
dependencies between the inputs and outputs of the steps. If any of dependencies between the inputs and outputs of the steps. If any of
the listed steps fails then the token MUST be rejected for the listed steps fails then the token MUST be rejected for
processing. processing.
1. The JWT MUST contain at least one period character. 1. The JWT MUST contain at least one period ('.') character.
2. Let the Encoded JWT Header be the portion of the JWT before the 2. Let the Encoded JWT Header be the portion of the JWT before the
first period character. first period ('.') character.
3. The Encoded JWT Header MUST be successfully base64url decoded 3. The Encoded JWT Header MUST be successfully base64url decoded
following the restriction given in this specification that no following the restriction given in this specification that no
padding characters have been used. padding characters have been used.
4. The resulting JWT Header MUST be completely valid JSON syntax 4. The resulting JWT Header MUST be completely valid JSON syntax
conforming to RFC 4627 [RFC4627]. conforming to RFC 4627 [RFC4627].
5. The resulting JWT Header MUST be validated to only include 5. The resulting JWT Header MUST be validated to only include
parameters and values whose syntax and semantics are both parameters and values whose syntax and semantics are both
skipping to change at page 15, line 30 skipping to change at page 15, line 30
9.1. JSON Web Token Claims Registry 9.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 reserved JWT Claim Names. The registry records the registry for reserved JWT Claim Names. The registry records the
reserved Claim Name and a reference to the specification that defines reserved Claim Name and a reference to the specification that defines
it. This specification registers the Claim Names defined in it. This specification registers the Claim Names defined in
Section 4.1. Section 4.1.
Values are registered with a Specification Required [RFC5226] after a Values are registered with a Specification Required [RFC5226] after a
two week review period on the [TBD]@ietf.org mailing list, on the two-week review period on the [TBD]@ietf.org mailing list, on the
advice of one or more Designated Experts. However, to allow for the advice of one or more Designated Experts. However, to allow for the
allocation of values prior to publication, the Designated Expert(s) allocation of values prior to publication, the Designated Expert(s)
may approve registration once they are satisfied that such a may approve registration once they are satisfied that such a
specification will be published. 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 RFC-EDITOR: The name of for access token type: example"). [[ Note to RFC-EDITOR: The name of
the mailing list should be determined in consultation with the IESG the mailing list should be determined in consultation with the IESG
and IANA. Suggested name: claims-reg-review. ]] and IANA. Suggested name: claims-reg-review. ]]
Within the review period, the Designated Expert(s) will either Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation to the review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. successful.
IANA must only accept registry updates from the Designated Expert(s), IANA must only accept registry updates from the Designated Expert(s)
and should direct all requests for registration to the review mailing and should direct all requests for registration to the review mailing
list. list.
9.1.1. Registration Template 9.1.1. Registration Template
Claim Name: Claim Name:
The name requested (e.g., "example"). This name is case The name requested (e.g., "example"). This name is case
sensitive. Names that match other registered names in a case sensitive. Names that match other registered names in a case
insensitive manner SHOULD NOT be accepted. insensitive manner SHOULD NOT be accepted.
Change Controller: Change Controller:
For standards-track RFCs, state "IETF". For others, give the name For Standards Track RFCs, state "IETF". 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,
e-mail 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 that specifies the parameter, preferably Reference to the document(s) that specify the parameter,
including a URI that can be used to retrieve a copy of the preferably including URI(s) that can be used to retrieve copies of
document. An indication of the relevant sections may also be the document(s). An indication of the relevant sections may also
included, but is not required. be included but is not required.
9.1.2. Initial Registry Contents 9.1.2. Initial Registry Contents
o Claim Name: "exp" o Claim Name: "exp"
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1.1 of [[ this document ]] o Specification Document(s): Section 4.1.1 of [[ this document ]]
o Claim Name: "nbf" o Claim Name: "nbf"
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1.2 of [[ this document ]] o Specification Document(s): Section 4.1.2 of [[ this document ]]
o Claim Name: "iat" o Claim Name: "iat"
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1.3 of [[ this document ]] o Specification Document(s): Section 4.1.3 of [[ this document ]]
o Claim Name: "iss" o Claim Name: "iss"
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1.4 of [[ this document ]] o Specification Document(s): Section 4.1.4 of [[ this document ]]
o Claim Name: "aud" o Claim Name: "aud"
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1.5 of [[ this document ]] o Specification Document(s): Section 4.1.5 of [[ this document ]]
o Claim Name: "prn" o Claim Name: "prn"
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1.6 of [[ this document ]] o Specification Document(s): Section 4.1.6 of [[ this document ]]
o Claim Name: "jti" o Claim Name: "jti"
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1.7 of [[ this document ]] o Specification Document(s): Section 4.1.7 of [[ this document ]]
o Claim Name: "typ" o Claim Name: "typ"
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1.8 of [[ this document ]] o Specification Document(s): Section 4.1.8 of [[ this document ]]
9.2. Sub-Namespace Registration of urn:ietf:params:oauth:token-type:jwt 9.2. Sub-Namespace Registration of urn:ietf:params:oauth:token-type:jwt
9.2.1. Registry Contents 9.2.1. Registry Contents
This specification registers the value "token-type:jwt" in the IANA This specification registers the value "token-type:jwt" in the IANA
urn:ietf:params:oauth registry established in An IETF URN Sub- urn:ietf:params:oauth registry established in An IETF URN Sub-
Namespace for OAuth [I-D.ietf-oauth-urn-sub-ns]. Namespace for OAuth [RFC6755].
o URN: urn:ietf:params:oauth:token-type:jwt o URN: urn:ietf:params:oauth:token-type:jwt
o Common Name: JSON Web Token (JWT) Token Type o Common Name: JSON Web Token (JWT) Token Type
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): [[this document]] o Specification Document(s): [[this document]]
9.3. JSON Web Signature and Encryption Type Values Registration 9.3. JSON Web Signature and Encryption Type Values Registration
9.3.1. Registry Contents 9.3.1. Registry Contents
This specification registers the "JWT" type value in the IANA JSON This specification registers the "JWT" type value in the IANA JSON
Web Signature and Encryption Type Values registry [JWS]: Web Signature and Encryption Type Values registry [JWS]:
o "typ" Header Parameter Value: "JWT" o "typ" Header Parameter Value: "JWT"
skipping to change at page 19, line 21 skipping to change at page 18, line 36
message for the wrong recipient. The entire list of security message for the wrong recipient. The entire list of security
considerations is beyond the scope of this document, but some considerations is beyond the scope of this document, but some
significant concerns are listed here. significant concerns are listed here.
All the security considerations in the JWS specification also apply All the security considerations in the JWS specification also apply
to JWT, as do the JWE security considerations when encryption is to JWT, as do the JWE security considerations when encryption is
employed. In particular, the JWS JSON Security Considerations and employed. In particular, the JWS JSON Security Considerations and
Unicode Comparison Security Considerations apply equally to the JWT Unicode Comparison Security Considerations apply equally to the JWT
Claims Set in the same manner that they do to the JWS Header. Claims Set in the same manner that they do to the JWS Header.
11. Open Issues 11. References
[[ to be removed by the RFC editor before publication as an RFC ]]
The following items remain to be considered or done in this draft:
o Track changes to the underlying JOSE specifications.
12. References
12.1. Normative References
[I-D.ietf-oauth-urn-sub-ns] 11.1. Normative References
Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", draft-ietf-oauth-urn-sub-ns-06 (work in
progress), July 2012.
[JWA] Jones, M., "JSON Web Algorithms (JWA)", July 2012. [JWA] Jones, M., "JSON Web Algorithms (JWA)", October 2012.
[JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web [JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web
Encryption (JWE)", July 2012. Encryption (JWE)", October 2012.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", July 2012. Signature (JWS)", October 2012.
[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.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002. Internet: Timestamps", RFC 3339, July 2002.
skipping to change at page 20, line 29 skipping to change at page 19, line 31
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", RFC 6755, October 2012.
[USA15] Davis, M., Whistler, K., and M. Duerst, "Unicode [USA15] Davis, M., Whistler, K., and M. Duerst, "Unicode
Normalization Forms", Unicode Standard Annex 15, 09 2009. Normalization Forms", Unicode Standard Annex 15, 09 2009.
12.2. Informative References 11.2. Informative References
[CanvasApp] [CanvasApp]
Facebook, "Canvas Applications", 2010. Facebook, "Canvas Applications", 2010.
[JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign", [JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign",
September 2010. September 2010.
[MagicSignatures] [MagicSignatures]
Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic
Signatures", January 2011. Signatures", January 2011.
skipping to change at page 21, line 30 skipping to change at page 20, line 34
recipient using RSAES-PKCS1-V1_5 and AES CBC. AES CBC does not have recipient using RSAES-PKCS1-V1_5 and AES CBC. AES CBC does not have
an integrated integrity check, so a separate integrity check an integrated integrity check, so a separate integrity check
calculation is performed using HMAC SHA-256, with separate encryption calculation is performed using HMAC SHA-256, with separate encryption
and integrity keys being derived from a master key using the Concat and integrity keys being derived from a master key using the Concat
KDF with the SHA-256 digest function. KDF with the SHA-256 digest function.
The following example JWE Header (with line breaks for display The following example JWE Header (with line breaks for display
purposes only) declares that: purposes only) declares that:
o the Content Master Key is encrypted to the recipient using the o the Content Master 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 and
o the Plaintext is encrypted using the AES CBC algorithm with a 128 o the Plaintext is encrypted using the AES CBC algorithm with a 128
bit key to produce the Ciphertext, bit key to produce the Ciphertext, with the integrity of the
Ciphertext and the parameters used to create it being secured
o the JWE Integrity Value safeguarding the integrity of the using the HMAC SHA-256 algorithm.
Ciphertext and the parameters used to create it was computed with
the HMAC SHA-256 algorithm, and
o the 128 bit Initialization Vector (IV) with the base64url encoding
"AxY8DCtDaGlsbGljb3RoZQ" was used.
{"alg":"RSA1_5","enc":"A128CBC","int":"HS256","iv":"AxY8DCtDaGls {"alg":"RSA1_5","enc":"A128CBC+HS256"}
bGljb3RoZQ"}
Other than using the bytes of the UTF-8 representation of the JSON Other than using the bytes of the UTF-8 representation of the JSON
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:
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJp eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDK0hTMjU2In0.
diI6IkF4WThEQ3REYUdsc2JHbGpiM1JvWlEifQ. W_LXELSzOoofu8FGRt4WwXiTGfvC50hiiSV4DcgkUIY1nOnkJ4tHW4LiioZFvvLD
VjBkk22MjrFUMUl8ItbS8CjKjku4HQz4RiHD0eVG4dir-7XbDkPr1q6YtnN1X-av ohAnuHs1K_29TMx8VQl8kLCxFgn6xxg5q5-UZzbcASgJIAupo7r5mzENbIrjK3bx
1EKmEnsrbhSxTvqtY4oEbWKLoEQ7zVm_0BW-rnwxdwrj4QJrhXGnqIL6bC4waZVJ H8aXSKJQ0icN-sEC54M8rKz2VYdPjZTpGcTHCI2suobyhA0Jwr3OJ7JBZiDJ1GSN
qYhVQIahVWSQsCRcS1oYXA-2GhT6rk91y118DUkhGDsvdK2_hQsNGE6BQVN1i-Xw O310isBrQcZQXKsMC9ne8P5jJEZSD3IHcTag502P0Rp8BxFV0Ld5OdfU_NmS69RD
Uoz5sM6_0PRQ1FsYnJATMjVZfa4otHiooZ_KcOlSWIDxhMDqfPOu60--1ej0eZBy DxCZC6nV8Zz_n97nLE9vFrSOjXMyJoyqeORdvWGsiXPmD7fkE8a6BOw3-efYqeCj
O7Ar_IZvzPAWqJ9agGFQIVGRZviXhN0WeErq9fVTcgeSUPsmurRSTYhTrNFLojqP 5elo-kKrNcirBHxH96u-sw.
qqk8pI61kn8GmZxA80-RUQ. AxY8DCtDaGlsbGljb3RoZQ.
7kLQQst655TUxmDzysjRLXnD-nfLK5EQK7ODAUkwxc0aRb9NOgu0EMJgOR6Vz8eN Wcyp1X4AaobxcNcVOqmLftbfg-t6yIy6yvxi0dNoWLroCbgUowHs8WeLWNj_ktrT
baf8six_OP6BRyUTYrCkH73-inD6Rc-7vc9eC5fcfSM. lL3xL_cz3a2-DioHF5deqNmvyByjVR7Xc4QXBYcn0nE.
COyXNSm-CdfAL22WIKcoyCgQwb85aLW3ttDkzNj_1Wg tEkhyWYGI_VHL1WoDO23nPRC8w3LG53KaCm5HmavnA0
Appendix B. Relationship of JWTs to SAML Tokens Appendix B. Relationship of JWTs to SAML Tokens
SAML 2.0 [OASIS.saml-core-2.0-os] provides a standard for creating SAML 2.0 [OASIS.saml-core-2.0-os] provides a standard for creating
tokens with much greater expressivity and more security options than tokens with much greater expressivity and more security options than
supported by JWTs. However, the cost of this flexibility and supported by JWTs. However, the cost of this flexibility and
expressiveness is both size and complexity. In addition, SAML's use expressiveness is both size and complexity. In addition, SAML's use
of XML [W3C.CR-xml11-20021015] and XML DSIG [RFC3275] only of XML [W3C.CR-xml11-20021015] and XML DSIG [RFC3275] only
contributes to the size of SAML tokens. contributes to the size of SAML tokens.
skipping to change at page 23, line 18 skipping to change at page 22, line 14
influenced by the design and simplicity of Simple Web Tokens [SWT] influenced by the design and simplicity of Simple Web Tokens [SWT]
and ideas for JSON tokens that Dick Hardt discussed within the OpenID and ideas for JSON tokens that Dick Hardt discussed within the OpenID
community. community.
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. Dirk Applications [CanvasApp], all of which influenced this draft. Dirk
Balfanz, Yaron Y. Goland, John Panzer, and Paul Tarjan all made Balfanz, Yaron Y. Goland, John Panzer, and Paul Tarjan all made
significant contributions to the design of this specification. significant contributions to the design of this specification.
Appendix E. Document History Hannes Tschofenig and Derek Atkins chaired the OAuth working group
and Sean Turner and Stephen Farrell served as Security area directors
during the creation of this specification.
Appendix E. Open Issues
[[ to be removed by the RFC editor before publication as an RFC ]]
The following items remain to be considered or done in this draft:
o Track changes to the underlying JOSE specifications.
Appendix F. 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 ]]
-04
o Promoted Initialization Vector from being a header parameter to
being a top-level JWE element. This saves approximately 16 bytes
in the compact serialization, which is a significant savings for
some use cases. Promoting the Initialization Vector out of the
header also avoids repeating this shared value in the JSON
serialization.
o Applied changes made by the RFC Editor to RFC 6749's registry
language to this specification.
o Reference RFC 6755 -- An IETF URN Sub-Namespace for OAuth.
-03 -03
o Added statement that "StringOrURI values are compared as case- o Added statement that "StringOrURI values are compared as case-
sensitive strings with no transformations or canonicalizations sensitive strings with no transformations or canonicalizations
applied". applied".
o Indented artwork elements to better distinguish them from the body o Indented artwork elements to better distinguish them from the body
text. text.
-02 -02
 End of changes. 47 change blocks. 
92 lines changed or deleted 84 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/