< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/