draft-ietf-oauth-json-web-token-10.txt   draft-ietf-oauth-json-web-token-11.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 15, 2014 Ping Identity Expires: January 30, 2014 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
July 14, 2013 July 29, 2013
JSON Web Token (JWT) JSON Web Token (JWT)
draft-ietf-oauth-json-web-token-10 draft-ietf-oauth-json-web-token-11
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 January 15, 2014. This Internet-Draft will expire on January 30, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 7 skipping to change at page 3, line 7
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 . . . . . . . . . . . . . . . . . 17 9.4. Media Type Registration . . . . . . . . . . . . . . . . . 17
9.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 17 9.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 17
9.5. Registration of JWE Header Parameter Names . . . . . . . . 18 9.5. Registration of JWE Header Parameter Names . . . . . . . . 18
9.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 18 9.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Example Encrypted JWT . . . . . . . . . . . . . . . . 21 Appendix A. JWT Examples . . . . . . . . . . . . . . . . . . . . 21
Appendix B. Relationship of JWTs to SAML Assertions . . . . . . . 22 A.1. Example Encrypted JWT . . . . . . . . . . . . . . . . . . 21
Appendix C. Relationship of JWTs to Simple Web Tokens (SWTs) . . 22 A.2. Example Nested JWT . . . . . . . . . . . . . . . . . . . . 22
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 23 Appendix B. Relationship of JWTs to SAML Assertions . . . . . . . 24
Appendix E. Document History . . . . . . . . . . . . . . . . . . 23 Appendix C. Relationship of JWTs to Simple Web Tokens (SWTs) . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Appendix E. Document History . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
JSON Web Token (JWT) is a compact claims representation format JSON Web Token (JWT) is a compact claims representation format
intended for space constrained environments such as HTTP intended for space constrained environments such as HTTP
Authorization headers and URI query parameters. JWTs encode claims Authorization headers and URI query parameters. JWTs encode claims
to be transmitted as a JavaScript Object Notation (JSON) [RFC4627] to be transmitted as a JavaScript Object Notation (JSON) [RFC4627]
object that is used as the payload of a JSON Web Signature (JWS) object that is used as the payload of a JSON Web Signature (JWS)
[JWS] structure or as the plaintext of a JSON Web Encryption (JWE) [JWS] structure or as the plaintext of a JSON Web Encryption (JWE)
[JWE] structure, enabling the claims to be digitally signed or MACed [JWE] structure, enabling the claims to be digitally signed or MACed
skipping to change at page 7, line 38 skipping to change at page 7, line 38
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 Appendix A.1 of This computation is illustrated in more detail in Appendix A.1 of
[JWS]. See Appendix A for an example of an encrypted JWT. [JWS]. See Appendix A.1 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 a JWT Claims Set claims conveyed by the JWT. The Claim Names within a JWT Claims Set
MUST be unique; recipients MUST either reject JWTs with duplicate MUST be unique; recipients MUST either reject JWTs with duplicate
Claim Names or use a JSON parser that returns only the lexically last Claim Names or use a JSON parser that returns only the lexically last
duplicate member name, as specified in Section 15.12 (The JSON duplicate member name, as specified in Section 15.12 (The JSON
Object) of ECMAScript 5.1 [ECMAScript]. Object) of ECMAScript 5.1 [ECMAScript].
skipping to change at page 11, line 14 skipping to change at page 11, line 14
5.2. "cty" (Content Type) Header Parameter 5.2. "cty" (Content Type) Header Parameter
The "cty" (content type) header parameter is used to declare The "cty" (content type) header parameter is used to declare
structural information about the JWT. Its value MUST be a string. structural information about the JWT. Its value MUST be a string.
In the normal case where nested signing or encryption operations are In the normal case where nested signing or encryption operations are
not employed, the use of this header parameter is NOT RECOMMENDED. not employed, the use of this header parameter is NOT RECOMMENDED.
In the case that nested signing or encryption is employed, the use of In the case that nested signing or encryption is employed, the use of
this header parameter is REQUIRED; in this case, the value MUST be this header parameter is REQUIRED; in this case, the value MUST be
"JWT", to indicate that a Nested JWT is carried in this JWT. "JWT", to indicate that a Nested JWT is carried in this JWT. See
Appendix A.2 for an example of a Nested JWT.
The values used for the "cty" header parameter come from the same The values used for the "cty" header parameter come from the same
value space as the "typ" header parameter, with the same rules value space as the "typ" header parameter, with the same rules
applying. applying.
5.3. Replicating Claims as Header Parameters 5.3. Replicating Claims as Header Parameters
In some applications using encrypted JWTs, it is useful to have an In some applications using encrypted JWTs, it is useful to have an
unencrypted representation of some Claims. This might be used, for unencrypted representation of some Claims. This might be used, for
instance, in application processing rules to determine whether and instance, in application processing rules to determine whether and
how to process the JWT before it is decrypted. how to process the JWT before it is decrypted.
This specification allows Claims present in the JWT Claims Set to be This specification allows Claims present in the JWT Claims Set to be
replicated as Header Parameters in a JWT that is a JWE, as needed by replicated as Header Parameters in a JWT that is a JWE, as needed by
the application. If such replicated Claims are present, the the application. If such replicated Claims are present, the
application receiving them SHOULD verify that their values are application receiving them SHOULD verify that their values are
identical. It is the responsibility of the application to ensure identical. It is the responsibility of the application to ensure
that only claims that are safe to be transmitted in an unencrypted that only claims that are safe to be transmitted in an unencrypted
manner are replicated as Header Parameter values in the JWT. manner are replicated as Header Parameter values in the JWT.
This specification reserves the "iss" (issuer) and "aud" (audience) This specification reserves the "iss" (issuer), "sub" (subject), and
Header Parameter Names for the purpose of providing unencrypted "aud" (audience) Header Parameter Names for the purpose of providing
replicas of these Claims in encrypted JWTs for applications that need unencrypted replicas of these Claims in encrypted JWTs for
them. Other specifications MAY similarly reserve other names that applications that need them. Other specifications MAY similarly
are reserved Claim Names as Header Parameter Names, as needed. reserve other names that are reserved Claim Names as Header Parameter
Names, as needed.
6. Plaintext JWTs 6. Plaintext JWTs
To support use cases where the JWT content is secured by a means To support use cases where the JWT content is secured by a means
other than a signature and/or encryption contained within the JWT other than a signature and/or encryption contained within the JWT
(such as a signature on a data structure containing the JWT), JWTs (such as a signature on a data structure containing the JWT), JWTs
MAY also be created without a signature or encryption. A plaintext MAY also be created without a signature or encryption. A plaintext
JWT is a JWS using the "none" JWS "alg" header parameter value JWT is a JWS using the "none" JWS "alg" header parameter value
defined in JSON Web Algorithms (JWA) [JWA]; it is a JWS with the defined in JSON Web Algorithms (JWA) [JWA]; it is a JWS with the
empty string for its JWS Signature value. empty string for its JWS Signature value.
skipping to change at page 18, line 39 skipping to change at page 18, line 39
Parameters registry [JWS] for use by Claims replicated as Header Parameters registry [JWS] for use by Claims replicated as Header
Parameters, per Section 5.3. Parameters, per Section 5.3.
9.5.1. Registry Contents 9.5.1. Registry Contents
o Header Parameter Name: "iss" o Header Parameter Name: "iss"
o Header Parameter Usage Location(s): JWE o Header Parameter Usage Location(s): JWE
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 Header Parameter Name: "sub"
o Header Parameter Usage Location(s): JWE
o Change Controller: IETF
o Specification Document(s): Section 4.1.2 of [[ this document ]]
o Header Parameter Name: "aud" o Header Parameter Name: "aud"
o Header Parameter Usage Location(s): JWE o Header Parameter Usage Location(s): JWE
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 ]]
10. Security Considerations 10. Security Considerations
All of the security issues faced by any cryptographic application All of the security issues faced by any cryptographic application
must be faced by a JWT/JWS/JWE/JWK agent. Among these issues are must be faced by a JWT/JWS/JWE/JWK agent. Among these issues are
protecting the user's private and symmetric keys, preventing various protecting the user's private and symmetric keys, preventing various
skipping to change at page 19, line 44 skipping to change at page 20, line 5
5.1 Edition", ECMA 262, June 2011. 5.1 Edition", ECMA 262, June 2011.
[JWA] Jones, M., "JSON Web Algorithms (JWA)", [JWA] Jones, M., "JSON Web Algorithms (JWA)",
draft-ietf-jose-json-web-algorithms (work in progress), draft-ietf-jose-json-web-algorithms (work in progress),
July 2013. July 2013.
[JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web [JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web
Encryption (JWE)", draft-ietf-jose-json-web-encryption Encryption (JWE)", draft-ietf-jose-json-web-encryption
(work in progress), July 2013. (work in progress), July 2013.
[JWK] Jones, M., "JSON Web Key (JWK)",
draft-ietf-jose-json-web-key (work in progress),
July 2013.
[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), July 2013. in progress), July 2013.
[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.
skipping to change at page 21, line 24 skipping to change at page 21, line 36
[W3C.CR-xml11-20021015] [W3C.CR-xml11-20021015]
Cowan, J., "Extensible Markup Language (XML) 1.1", W3C Cowan, J., "Extensible Markup Language (XML) 1.1", W3C
CR CR-xml11-20021015, October 2002. CR CR-xml11-20021015, October 2002.
[W3C.REC-xml-c14n-20010315] [W3C.REC-xml-c14n-20010315]
Boyer, J., "Canonical XML Version 1.0", World Wide Web Boyer, J., "Canonical XML Version 1.0", World Wide Web
Consortium Recommendation REC-xml-c14n-20010315, Consortium Recommendation REC-xml-c14n-20010315,
March 2001, March 2001,
<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>. <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
Appendix A. Example Encrypted JWT Appendix A. JWT Examples
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].
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 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 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
skipping to change at page 22, line 17 skipping to change at page 22, line 30
oNfABIPJaZm0HaA415sv3aeuBWnD8J-Ui7Ah6cWafs3ZwwFKDFUUsWHSK-IPKxLG oNfABIPJaZm0HaA415sv3aeuBWnD8J-Ui7Ah6cWafs3ZwwFKDFUUsWHSK-IPKxLG
TkND09XyjORj_CHAgOPJ-Sd8ONQRnJvWn_hXV1BNMHzUjPyYwEsRhDhzjAD26ima TkND09XyjORj_CHAgOPJ-Sd8ONQRnJvWn_hXV1BNMHzUjPyYwEsRhDhzjAD26ima
sOTsgruobpYGoQcXUwFDn7moXPRfDE8-NoQX7N7ZYMmpUDkR-Cx9obNGwJQ3nM52 sOTsgruobpYGoQcXUwFDn7moXPRfDE8-NoQX7N7ZYMmpUDkR-Cx9obNGwJQ3nM52
YCitxoQVPzjbl7WBuB7AohdBoZOdZ24WlN1lVIeh8v1K4krB8xgKvRU8kgFrEn_a YCitxoQVPzjbl7WBuB7AohdBoZOdZ24WlN1lVIeh8v1K4krB8xgKvRU8kgFrEn_a
1rZgN5TiysnmzTROF869lQ. 1rZgN5TiysnmzTROF869lQ.
AxY8DCtDaGlsbGljb3RoZQ. AxY8DCtDaGlsbGljb3RoZQ.
MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeWnDYvpIAeZ72deHxz3roJDXQyhxx0wKaM MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeWnDYvpIAeZ72deHxz3roJDXQyhxx0wKaM
HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7sln1Eu9g3J8. HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7sln1Eu9g3J8.
fiK51VwhsxJ-siBMR-YFiA fiK51VwhsxJ-siBMR-YFiA
A.2. Example Nested JWT
This example shows how a JWT can be used as the payload of a JWE or
JWS to create a Nested JWT. In this case, the JWT Claims Set is
first signed, and then encrypted.
The inner signed JWT is identical to the example in Appendix A.2 of
[JWS]. Therefore, its computation is not repeated here. This
example then encrypts this inner JWT to the recipient using RSAES-
PKCS1-V1_5 and AES_128_CBC_HMAC_SHA_256.
The following example JWE Header (with line breaks for display
purposes only) declares that:
o the Content Encryption Key is encrypted to the recipient using the
RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key,
o the Plaintext is encrypted using the AES_128_CBC_HMAC_SHA_256
algorithm to produce the Ciphertext, and
o the Plaintext is itself a JWT.
{"alg":"RSA1_5","enc":"A128CBC-HS256","cty":"JWT"}
Base64url encoding the octets of the UTF-8 representation of the JWE
Header yields this Encoded JWE Header value:
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0
The computation of this JWT is identical to the computation of the
JWE in Appendix A.2 of [JWE], other than that different JWE Header,
Plaintext, Initialization Vector, and Content Encryption Key values
are used. (The RSA key used is the same.)
The Payload used is the octets of the ASCII representation of the JWT
at the end of Appendix Section A.2.1 of [JWS] (with all whitespace
and line breaks removed), which is a sequence of 458 octets.
The Initialization Vector value used is:
[82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53,
50]
This example uses the Content Encryption Key represented in JSON Web
Key [JWK] format below:
{"kty":"oct",
"k":"GawgguFyGrWKav7AX4VKUg"
}
The final result for this Nested JWT (with line breaks for display
purposes only) is:
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldU
In0.
g_hEwksO1Ax8Qn7HoN-BVeBoa8FXe0kpyk_XdcSmxvcM5_P296JXXtoHISr_DD_M
qewaQSH4dZOQHoUgKLeFly-9RI11TG-_Ge1bZFazBPwKC5lJ6OLANLMd0QSL4fYE
b9ERe-epKYE3xb2jfY1AltHqBO-PM6j23Guj2yDKnFv6WO72tteVzm_2n17SBFvh
DuR9a2nHTE67pe0XGBUS_TK7ecA-iVq5COeVdJR4U4VZGGlxRGPLRHvolVLEHx6D
YyLpw30Ay9R6d68YCLi9FYTq3hIXPK_-dmPlOUlKvPr1GgJzRoeC9G5qCvdcHWsq
JGTO_z3Wfo5zsqwkxruxwA.
UmVkbW9uZCBXQSA5ODA1Mg.
VwHERHPvCNcHHpTjkoigx3_ExK0Qc71RMEParpatm0X_qpg-w8kozSjfNIPPXiTB
BLXR65CIPkFqz4l1Ae9w_uowKiwyi9acgVztAi-pSL8GQSXnaamh9kX1mdh3M_TT
-FZGQFQsFhu0Z72gJKGdfGE-OE7hS1zuBD5oEUfk0Dmb0VzWEzpxxiSSBbBAzP10
l56pPfAtrjEYw-7ygeMkwBl6Z_mLS6w6xUgKlvW6ULmkV-uLC4FUiyKECK4e3WZY
Kw1bpgIqGYsw2v_grHjszJZ-_I5uM-9RA8ycX9KqPRp9gc6pXmoU_-27ATs9XCvr
ZXUtK2902AUzqpeEUJYjWWxSNsS-r1TJ1I-FMJ4XyAiGrfmo9hQPcNBYxPz3GQb2
8Y5CLSQfNgKSGt0A4isp1hBUXBHAndgtcslt7ZoQJaKe_nNJgNliWtWpJ_ebuOpE
l8jdhehdccnRMIwAmU1n7SPkmhIl1HlSOpvcvDfhUN5wuqU955vOBvfkBOh5A11U
zBuo2WlgZ6hYi9-e3w29bR0C2-pp3jbqxEDw3iWaf2dc5b-LnR0FEYXvI_tYk5rd
_J9N0mg0tQ6RbpxNEMNoA9QWk5lgdPvbh9BaO195abQ.
AVO9iT5AV4CzvDJCdhSFlQ
Appendix B. Relationship of JWTs to SAML Assertions Appendix B. Relationship of JWTs to SAML Assertions
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
security tokens with greater expressivity and more security options security tokens with greater expressivity and more security options
than supported by JWTs. However, the cost of this flexibility and than supported by JWTs. However, the cost of this flexibility and
expressiveness is both size and complexity. SAML's use of XML expressiveness is both size and complexity. SAML's use of XML
[W3C.CR-xml11-20021015] and XML DSIG [RFC3275] contributes to the [W3C.CR-xml11-20021015] and XML DSIG [RFC3275] contributes to the
size of SAML assertions; its use of XML and especially XML size of SAML assertions; its use of XML and especially XML
Canonicalization [W3C.REC-xml-c14n-20010315] contributes to their Canonicalization [W3C.REC-xml-c14n-20010315] contributes to their
complexity. complexity.
skipping to change at page 23, line 40 skipping to change at page 25, line 48
Schaad, Paul Tarjan, Hannes Tschofenig, and Sean Turner. Schaad, Paul Tarjan, Hannes Tschofenig, and Sean Turner.
Hannes Tschofenig and Derek Atkins chaired the OAuth working group Hannes Tschofenig and Derek Atkins chaired the OAuth working group
and Sean Turner and Stephen Farrell served as Security area directors and Sean Turner and Stephen Farrell served as Security area directors
during the creation of this specification. 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 ]]
-11
o Added a Nested JWT example.
o Added "sub" to the list of Claims registered for use as Header
Parameter values when an unencrypted representation is required in
an encrypted JWT.
-10 -10
o Allowed Claims to be replicated as Header Parameters in encrypted o Allowed Claims to be replicated as Header Parameters in encrypted
JWTs as needed by applications that require an unencrypted JWTs as needed by applications that require an unencrypted
representation of specific Claims. representation of specific Claims.
-09 -09
o Clarified that the "typ" header parameter is used in an o Clarified that the "typ" header parameter is used in an
application-specific manner and has no effect upon the JWT application-specific manner and has no effect upon the JWT
 End of changes. 14 change blocks. 
19 lines changed or deleted 118 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/