< draft-ietf-oauth-json-web-token-06.txt		draft-ietf-oauth-json-web-token-07.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: June 30, 2013 Ping Identity		Expires: October 25, 2013 Ping Identity
	N. Sakimura		N. Sakimura
	NRI		NRI
	December 27, 2012		April 23, 2013
	JSON Web Token (JWT)		JSON Web Token (JWT)
	draft-ietf-oauth-json-web-token-06		draft-ietf-oauth-json-web-token-07
	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 June 30, 2013.		This Internet-Draft will expire on October 25, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4		1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. JSON Web Token (JWT) Overview . . . . . . . . . . . . . . . . 6		3. JSON Web Token (JWT) Overview . . . . . . . . . . . . . . . . 7
	3.1. Example JWT . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Example JWT . . . . . . . . . . . . . . . . . . . . . . . 7
	4. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Reserved Claim Names . . . . . . . . . . . . . . . . . . . 7		4.1. Reserved Claim Names . . . . . . . . . . . . . . . . . . . 8
	4.1.1. "iss" (Issuer) Claim . . . . . . . . . . . . . . . . . 8		4.1.1. "iss" (Issuer) Claim . . . . . . . . . . . . . . . . . 9
	4.1.2. "sub" (Subject) Claim . . . . . . . . . . . . . . . . 8		4.1.2. "sub" (Subject) Claim . . . . . . . . . . . . . . . . 9
	4.1.3. "aud" (Audience) Claim . . . . . . . . . . . . . . . . 8		4.1.3. "aud" (Audience) Claim . . . . . . . . . . . . . . . . 9
	4.1.4. "exp" (Expiration Time) Claim . . . . . . . . . . . . 8		4.1.4. "exp" (Expiration Time) Claim . . . . . . . . . . . . 9
	4.1.5. "nbf" (Not Before) Claim . . . . . . . . . . . . . . . 8		4.1.5. "nbf" (Not Before) Claim . . . . . . . . . . . . . . . 9
	4.1.6. "iat" (Issued At) Claim . . . . . . . . . . . . . . . 9		4.1.6. "iat" (Issued At) Claim . . . . . . . . . . . . . . . 10
	4.1.7. "jti" (JWT ID) Claim . . . . . . . . . . . . . . . . . 9		4.1.7. "jti" (JWT ID) Claim . . . . . . . . . . . . . . . . . 10
	4.1.8. "typ" (Type) Claim . . . . . . . . . . . . . . . . . . 9		4.1.8. "typ" (Type) Claim . . . . . . . . . . . . . . . . . . 10
	4.2. Public Claim Names . . . . . . . . . . . . . . . . . . . . 9		4.2. Public Claim Names . . . . . . . . . . . . . . . . . . . . 10
	4.3. Private Claim Names . . . . . . . . . . . . . . . . . . . 9		4.3. Private Claim Names . . . . . . . . . . . . . . . . . . . 10
	5. JWT Header . . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. JWT Header . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.1. "typ" (Type) Header Parameter . . . . . . . . . . . . . . 10		5.1. "typ" (Type) Header Parameter . . . . . . . . . . . . . . 11
	5.2. "cty" (Content Type) Header Parameter . . . . . . . . . . 10		5.2. "cty" (Content Type) Header Parameter . . . . . . . . . . 11
	6. Plaintext JWTs . . . . . . . . . . . . . . . . . . . . . . . . 10		6. Plaintext JWTs . . . . . . . . . . . . . . . . . . . . . . . . 11
	6.1. Example Plaintext JWT . . . . . . . . . . . . . . . . . . 11		6.1. Example Plaintext JWT . . . . . . . . . . . . . . . . . . 12
	7. Rules for Creating and Validating a JWT . . . . . . . . . . . 11		7. Rules for Creating and Validating a JWT . . . . . . . . . . . 12
	7.1. String Comparison Rules . . . . . . . . . . . . . . . . . 13		7.1. String Comparison Rules . . . . . . . . . . . . . . . . . 14
	8. Cryptographic Algorithms . . . . . . . . . . . . . . . . . . . 14		8. Cryptographic Algorithms . . . . . . . . . . . . . . . . . . . 14
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	9.1. JSON Web Token Claims Registry . . . . . . . . . . . . . . 14		9.1. JSON Web Token Claims Registry . . . . . . . . . . . . . . 15
	9.1.1. Registration Template . . . . . . . . . . . . . . . . 15		9.1.1. Registration Template . . . . . . . . . . . . . . . . 16
	9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 15		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 . . . . . . . . . . . 16		urn:ietf:params:oauth:token-type:jwt . . . . . . . . . . . 17
	9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 16		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 . . . . . . . . . . . . . . . . . . . . . . . 16		Registration . . . . . . . . . . . . . . . . . . . . . . . 17
	9.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 16		9.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 17
	9.4. Media Type Registration . . . . . . . . . . . . . . . . . 16		9.4. Media Type Registration . . . . . . . . . . . . . . . . . 17
	9.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 16		9.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 17
			10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 17		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 18		11.2. Informative References . . . . . . . . . . . . . . . . . . 20
	11.2. Informative References . . . . . . . . . . . . . . . . . . 19		Appendix A. Example Encrypted JWT . . . . . . . . . . . . . . . . 20
	Appendix A. Example Encrypted JWT . . . . . . . . . . . . . . . . 19		Appendix B. Relationship of JWTs to SAML Assertions . . . . . . . 21
	Appendix B. Relationship of JWTs to SAML Assertions . . . . . . . 20		Appendix C. Relationship of JWTs to Simple Web Tokens (SWTs) . . 22
	Appendix C. Relationship of JWTs to Simple Web Tokens (SWTs) . . 21		Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 22
	Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 21		Appendix E. Document History . . . . . . . . . . . . . . . . . . 23
	Appendix E. Open Issues . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
	Appendix F. Document History . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
	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
	and/or encrypted.		and/or encrypted. JWTs are always represented using the JWS Compact
			Serialization or the JWE Compact Serialization.
	The suggested pronunciation of JWT is the same as the English word		The suggested pronunciation of JWT is the same as the English word
	"jot".		"jot".
	1.1. Notational Conventions		1.1. Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in Key words for use in		document are to be interpreted as described in Key words for use in
	RFCs to Indicate Requirement Levels [RFC2119].		RFCs to Indicate Requirement Levels [RFC2119].
	skipping to change at page 4, line 38 ¶		skipping to change at page 5, line 39 ¶
	JSON Web Token (JWT) A string representing a set of claims as a JSON		JSON Web Token (JWT) A string representing a set of claims as a JSON
	object that is encoded in a JWS or JWE, enabling the claims to be		object that is encoded in a JWS or JWE, enabling the claims to be
	digitally signed or MACed and/or encrypted.		digitally signed or MACed and/or encrypted.
	Base64url Encoding The URL- and filename-safe Base64 encoding		Base64url Encoding The URL- and filename-safe Base64 encoding
	described in RFC 4648 [RFC4648], Section 5, with the (non URL-		described in RFC 4648 [RFC4648], Section 5, with the (non URL-
	safe) '=' padding characters omitted, as permitted by Section 3.2.		safe) '=' padding characters omitted, as permitted by Section 3.2.
	(See Appendix C of [JWS] for notes on implementing base64url		(See Appendix C of [JWS] for notes on implementing base64url
	encoding without padding.)		encoding without padding.)
	JSON Text Object A UTF-8 encoded text string representing a JSON		JSON Text Object A UTF-8 [RFC3629] encoded text string representing
	object; the syntax of JSON objects is defined in Section 2.2 of		a JSON object; the syntax of JSON objects is defined in Section
	[RFC4627].		2.2 of [RFC4627].
	JWT Header A JSON Text Object that describes the cryptographic		JWT Header A JSON Text Object that describes the cryptographic
	operations applied to the JWT. When the JWT is digitally signed		operations applied to the JWT. When the JWT is digitally signed
	or MACed, the JWT Header is a JWS Header. When the JWT is		or MACed, the JWT Header is a JWS Header. When the JWT is
	encrypted, the JWT Header is a JWE Header.		encrypted, the JWT Header is a JWE Header.
	Header Parameter Name The name of a member of the JWT Header.		Header Parameter Name The name of a member of the JWT Header.
	Header Parameter Value The value of a member of the JWT Header.		Header Parameter Value The value of a member of the JWT Header.
	JWT Claims Set A JSON Text Object that contains the Claims conveyed		JWT Claims Set A JSON Text Object that contains the Claims conveyed
	by the JWT, where each claim is represented as a name/value pair		by the JWT.
	of a Claim Name and a Claim Value.
	Claim A piece of information asserted about a subject. Here, Claims		Claim A piece of information asserted about a subject. A Claim is
	are represented name/value pairs, consisting of a Claim Name and a		represented as a name/value pair consisting of a Claim Name and a
	Claim Value.		Claim Value.
	Claim Name The name portion of a Claim representation. A Claim Name		Claim Name The name portion of a Claim representation. A Claim Name
	is always a string.		is always a string.
	Claim Value The value portion of a Claim representation. A Claim		Claim Value The value portion of a Claim representation. A Claim
	Value can be any JSON value.		Value can be any JSON value.
	Encoded JWT Header Base64url encoding of the JWT Header.		Encoded JWT Header Base64url encoding of the JWT Header.
	Nested JWT A JWT in which nested signing or encryption are employed.		Nested JWT A JWT in which nested signing and/or encryption are
	In nested JWTs, a JWT is used as the payload or plaintext value of		employed. In nested JWTs, a JWT is used as the payload or
	an enclosing JWS or JWE structure, respectively.		plaintext value of an enclosing JWS or JWE structure,
			respectively.
	Plaintext JWT A JWT whose Claims are not integrity protected or		Plaintext JWT A JWT whose Claims are not integrity protected or
	encrypted.		encrypted.
	Collision Resistant Namespace A namespace that allows names to be		Collision Resistant Namespace A namespace that allows names to be
	allocated in a manner such that they are highly unlikely to		allocated in a manner such that they are highly unlikely to
	collide with other names. For instance, collision resistance can		collide with other names. For instance, collision resistance can
	be achieved through administrative delegation of portions of the		be achieved through administrative delegation of portions of the
	namespace or through use of collision-resistant name allocation		namespace or through use of collision-resistant name allocation
	functions. Examples of Collision Resistant Namespaces include:		functions. Examples of Collision Resistant Namespaces include:
	skipping to change at page 6, line 30 ¶		skipping to change at page 7, line 30 ¶
	MACed, with the JWT Claims Set being the JWS Payload. If the JWT		MACed, with the JWT Claims Set being the JWS Payload. If the JWT
	Header is a JWE Header, the JWT is represented as a JWE, and the		Header is a JWE Header, the JWT is represented as a JWE, and the
	claims are encrypted, with the JWT Claims Set being the input		claims are encrypted, with the JWT Claims Set being the input
	Plaintext. A JWT may be enclosed in another JWE or JWS structure to		Plaintext. A JWT may be enclosed in another JWE or JWS structure to
	create a Nested JWT, enabling nested signing and encryption to be		create a Nested JWT, enabling nested signing and encryption to be
	performed.		performed.
	A JWT is represented as a sequence of URL-safe parts separated by		A JWT is represented as a sequence of URL-safe parts separated by
	period ('.') characters. Each part contains a base64url encoded		period ('.') characters. Each part contains a base64url encoded
	value. The number of parts in the JWT is dependent upon the		value. The number of parts in the JWT is dependent upon the
	representation of the resulting JWS or JWE.		representation of the resulting JWS or JWE object using the JWS
			Compact Serialization or the JWE Compact Serialization.
	3.1. Example JWT		3.1. Example JWT
	The following example JWT Header declares that the encoded object is		The following example JWT Header declares that the encoded object is
	a JSON Web Token (JWT) and the JWT is MACed using the HMAC SHA-256		a JSON Web Token (JWT) and the JWT is MACed using the HMAC SHA-256
	algorithm:		algorithm:
	{"typ":"JWT",		{"typ":"JWT",
	"alg":"HS256"}		"alg":"HS256"}
	Base64url encoding the bytes of the UTF-8 representation of the JWT		Base64url encoding the octets of the UTF-8 representation of the JWT
	Header yields this Encoded JWS Header value, which is used as the		Header yields this Encoded JWS Header value, which is used as the
	Encoded JWT Header:		Encoded JWT Header:
	eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9		eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
	The following is an example of a JWT Claims Set:		The following is an example of a JWT Claims Set:
	{"iss":"joe",		{"iss":"joe",
	"exp":1300819380,		"exp":1300819380,
	"http://example.com/is_root":true}		"http://example.com/is_root":true}
	Base64url encoding the bytes of the UTF-8 representation of the JSON		Base64url encoding the octets 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):
	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:
	skipping to change at page 7, line 37 ¶		skipping to change at page 8, line 37 ¶
	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 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; JWTs with duplicate Claim Names MUST be rejected.		MUST be unique; JWTs with duplicate Claim Names MUST be rejected.
	Note however, that the set of claims that a JWT must contain to be
	considered valid is context-dependent and is outside the scope of		The set of claims that a JWT must contain to be considered valid is
	this specification. When used in a security-related context,		context-dependent and is outside the scope of this specification.
	implementations MUST understand and support all of the claims		Specific applications of JWTs will require implementations to
	present; otherwise, the JWT MUST be rejected for processing.		understand and process some claims in particular ways. However, in
			the absence of such requirements, all claims that are not understood
			by implementations SHOULD be ignored.
	There are three classes of JWT Claim Names: Reserved Claim Names,		There are three classes of JWT Claim Names: Reserved Claim Names,
	Public Claim Names, and Private Claim Names.		Public Claim Names, and Private Claim Names.
	4.1. Reserved Claim Names		4.1. Reserved Claim Names
	The following Claim Names are reserved. None of the claims defined		The following Claim Names are reserved. None of the claims defined
	below are intended to be mandatory to use, but rather, provide a		below are intended to be mandatory to use, but rather, provide a
	starting point for a set of useful, interoperable claims. All the		starting point for a set of useful, interoperable claims. All the
	names are short because a core goal of JWTs is for the representation		names are short because a core goal of JWTs is for the representation
	skipping to change at page 10, line 15 ¶		skipping to change at page 11, line 15 ¶
	5. JWT Header		5. JWT Header
	The members of the JSON object represented by the JWT Header describe		The members of the JSON object represented by the JWT Header describe
	the cryptographic operations applied to the JWT and optionally,		the cryptographic operations applied to the JWT and optionally,
	additional properties of the JWT. The member names within the JWT		additional properties of the JWT. The member names within the JWT
	Header are referred to as Header Parameter Names. These names MUST		Header are referred to as Header Parameter Names. These names MUST
	be unique; JWTs with duplicate Header Parameter Names MUST be		be unique; JWTs with duplicate Header Parameter Names MUST be
	rejected. The corresponding values are referred to as Header		rejected. The corresponding values are referred to as Header
	Parameter Values.		Parameter Values.
	Implementations MUST understand the entire contents of the header;
	otherwise, the JWT MUST be rejected for processing.
	JWS Header Parameters are defined by [JWS]. JWE Header Parameters		JWS Header Parameters are defined by [JWS]. JWE Header Parameters
	are defined by [JWE]. This specification further specifies the use		are defined by [JWE]. This specification further specifies the use
	of the following header parameter in both the cases where the JWT is		of the following header parameter in both the cases where the JWT is
	a JWS and where it is a JWE.		a JWS and where it is a JWE.
	5.1. "typ" (Type) Header Parameter		5.1. "typ" (Type) Header Parameter
	The "typ" (type) header parameter is used to declare the type of this		The "typ" (type) header parameter is used to declare the type of this
	object. If present, it is RECOMMENDED that its value be either "JWT"		object. If present, it is RECOMMENDED that its value be either "JWT"
	or "urn:ietf:params:oauth:token-type:jwt" to indicate that this		or "urn:ietf:params:oauth:token-type:jwt" to indicate that this
	skipping to change at page 11, line 15 ¶		skipping to change at page 12, line 12 ¶
	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.
	6.1. Example Plaintext JWT		6.1. Example Plaintext JWT
	The following example JWT Header declares that the encoded object is		The following example JWT Header declares that the encoded object is
	a Plaintext JWT:		a Plaintext JWT:
	{"alg":"none"}		{"alg":"none"}
	Base64url encoding the bytes of the UTF-8 representation of the JWT		Base64url encoding the octets of the UTF-8 representation of the JWT
	Header yields this Encoded JWT Header:		Header yields this Encoded JWT Header:
	eyJhbGciOiJub25lIn0		eyJhbGciOiJub25lIn0
	The following is an example of a JWT Claims Set:		The following is an example of a JWT Claims Set:
	{"iss":"joe",		{"iss":"joe",
	"exp":1300819380,		"exp":1300819380,
	"http://example.com/is_root":true}		"http://example.com/is_root":true}
	Base64url encoding the bytes of the UTF-8 representation of the JSON		Base64url encoding the octets 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
	skipping to change at page 12, line 9 ¶		skipping to change at page 13, line 5 ¶
	7. Rules for Creating and Validating a JWT		7. Rules for Creating and Validating a JWT
	To create a JWT, one MUST perform these steps. The order of the		To create a JWT, one MUST perform these steps. The order of the
	steps is not significant in cases where there are no dependencies		steps is not significant in cases where there are no dependencies
	between the inputs and outputs of the steps.		between the inputs and outputs of the steps.
	1. Create a JWT Claims Set containing the desired claims. Note that		1. Create a JWT Claims Set containing the desired claims. Note that
	white space is explicitly allowed in the representation and no		white space is explicitly allowed in the representation and no
	canonicalization is performed before encoding.		canonicalization is performed before encoding.
	2. Let the Message be the bytes of the UTF-8 representation of the		2. Let the Message be the octets of the UTF-8 representation of the
	JWT Claims Set.		JWT Claims Set.
	3. Create a JWT Header containing the desired set of header		3. Create a JWT Header containing the desired set of header
	parameters. The JWT MUST conform to either the [JWS] or [JWE]		parameters. The JWT MUST conform to either the [JWS] or [JWE]
	specifications. Note that white space is explicitly allowed in		specifications. Note that white space is explicitly allowed in
	the representation and no canonicalization is performed before		the representation and no canonicalization is performed before
	encoding.		encoding.
	4. Base64url encode the bytes of the UTF-8 representation of the JWT		4. Base64url encode the octets of the UTF-8 representation of the
	Header. Let this be the Encoded JWT Header.		JWT Header. Let this be the Encoded JWT Header.
	5. Depending upon whether the JWT is a JWS or JWE, there are two		5. Depending upon whether the JWT is a JWS or JWE, there are two
	cases:		cases:
	* If the JWT is a JWS, create a JWS using the JWT Header as the		* If the JWT is a JWS, create a JWS using the JWT Header as the
	JWS Header and the Message as the JWS Payload; all steps		JWS Header and the Message as the JWS Payload; all steps
	specified in [JWS] for creating a JWS MUST be followed.		specified in [JWS] for creating a JWS MUST be followed.
	* Else, if the JWT is a JWE, create a JWE using the JWT Header		* Else, if the JWT is a JWE, create a JWE using the JWT Header
	as the JWE Header and the Message as the JWE Plaintext; all		as the JWE Header and the Message as the JWE Plaintext; all
	skipping to change at page 13, line 10 ¶		skipping to change at page 14, line 7 ¶
	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
	understood and supported.		understood and supported or that are specified as being ignored
			when not understood.
	6. Determine whether the JWT is a JWS or a JWE by examining the		6. Determine whether the JWT is a JWS or a JWE by examining the
	"alg" (algorithm) header value and optionally, the "enc"		"alg" (algorithm) header value and optionally, the "enc"
	(encryption method) header value, if present.		(encryption method) header value, if present.
	7. Depending upon whether the JWT is a JWS or JWE, there are two		7. Depending upon whether the JWT is a JWS or JWE, there are two
	cases:		cases:
	* If the JWT is a JWS, all steps specified in [JWS] for		* If the JWT is a JWS, all steps specified in [JWS] for
	validating a JWS MUST be followed. Let the Message be the		validating a JWS MUST be followed. Let the Message be the
	result of base64url decoding the JWS Payload.		result of base64url decoding the JWS Payload.
	* Else, if the JWT is a JWE, all steps specified in [JWE] for		* Else, if the JWT is a JWE, all steps specified in [JWE] for
	validating a JWE MUST be followed. Let the Message be the		validating a JWE MUST be followed. Let the Message be the
	JWE Plaintext.		JWE Plaintext.
	8. If the JWT Header contains a "cty" (content type) value of		8. If the JWT Header contains a "cty" (content type) value of
	"JWT", then the Message contains a JWT that was the subject of		"JWT", then the Message is a JWT that was the subject of nested
	nested signing or encryption operations. In this case, return		signing or encryption operations. In this case, return to Step
	to Step 1, using the Message as the JWT.		1, using the Message as the JWT.
	9. Otherwise, let the JWT Claims Set be the Message.		9. Otherwise, let the JWT Claims Set be the Message.
	10. The JWT Claims Set MUST be completely valid JSON syntax		10. The JWT Claims Set MUST be completely valid JSON syntax
	conforming to RFC 4627 [RFC4627].		conforming to RFC 4627 [RFC4627].
	11. When used in a security-related context, the JWT Claims Set MUST
	be validated to only include claims whose syntax and semantics
	are both understood and supported.
	7.1. String Comparison Rules		7.1. String Comparison Rules
	Processing a JWT inevitably requires comparing known strings to		Processing a JWT inevitably requires comparing known strings to
	values in JSON objects. For example, in checking what the algorithm		values in JSON objects. For example, in checking what the algorithm
	is, the Unicode string encoding "alg" will be checked against the		is, the Unicode string encoding "alg" will be checked against the
	member names in the JWT Header to see if there is a matching Header		member names in the JWT Header to see if there is a matching Header
	Parameter Name.		Parameter Name.
	Comparisons between JSON strings and other Unicode strings MUST be		Comparisons between JSON strings and other Unicode strings MUST be
	performed by comparing Unicode code points without normalization as		performed by comparing Unicode code points without normalization as
	specified in the String Comparison Rules in Section 5.3 of [JWS].		specified in the String Comparison Rules in Section 5.3 of [JWS].
	8. Cryptographic Algorithms		8. Cryptographic Algorithms
	JWTs use JSON Web Signature (JWS) [JWS] and JSON Web Encryption (JWE)		JWTs use JSON Web Signature (JWS) [JWS] and JSON Web Encryption (JWE)
	[JWE] to sign and/or encrypt the contents of the JWT.		[JWE] to sign and/or encrypt the contents of the JWT.
	Of the JWS signing algorithms, only HMAC SHA-256 and "none" MUST be		Of the JWA signing algorithms, only HMAC SHA-256 ("HS256") and "none"
	implemented by conforming JWT implementations. It is RECOMMENDED		MUST be implemented by conforming JWT implementations. It is
	that implementations also support the RSA SHA-256 and ECDSA P-256		RECOMMENDED that implementations also support RSASSA-PKCS1-V1_5 with
	SHA-256 algorithms. Support for other algorithms and key sizes is		the SHA-256 hash algorithm ("RS256") and ECDSA using the P-256 curve
	OPTIONAL.		and the SHA-256 hash algorithm ("ES256"). Support for other
			algorithms and key sizes is OPTIONAL.
	If an implementation provides encryption capabilities, of the JWE		If an implementation provides encryption capabilities, of the JWA
	encryption algorithms, only RSA-PKCS1-1.5 with 2048 bit keys, AES-		encryption algorithms, only RSAES-PKCS1-V1_5 with 2048 bit keys
	128-KW, AES-256-KW, AES-128-CBC, and AES-256-CBC MUST be implemented		("RSA1_5"), AES Key Wrap with 128 and 256 bit keys ("A128KW" and
	by conforming implementations. It is RECOMMENDED that		"A256KW"), and the composite authenticated encryption algorithm using
	implementations also support ECDH-ES with 256 bit keys, AES-128-GCM,		AES CBC and HMAC SHA-2 ("A128CBC-HS256" and "A256CBC-HS512") MUST be
	and AES-256-GCM. Support for other algorithms and key sizes is		implemented by conforming implementations. It is RECOMMENDED that
	OPTIONAL.		implementations also support using ECDH-ES to agree upon a key used
			to wrap the Content Encryption Key ("ECDH-ES+A128KW" and
			"ECDH-ES+A256KW") and AES in Galois/Counter Mode (GCM) with 128 bit
			and 256 bit keys ("A128GCM" and "A256GCM"). Support for other
			algorithms and key sizes is OPTIONAL.
	9. IANA Considerations		9. IANA Considerations
	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.
	skipping to change at page 17, line 9 ¶		skipping to change at page 18, line 9 ¶
	the content is a JWT.		the content is a JWT.
	o Type Name: application		o Type Name: application
	o Subtype Name: jwt		o Subtype Name: jwt
	o Required Parameters: n/a		o Required Parameters: n/a
	o Optional Parameters: n/a		o Optional Parameters: n/a
	o Encoding considerations: JWT values are encoded as a series of		o Encoding considerations: JWT values are encoded as a series of
	base64url encoded values (some of which may be the empty string)		base64url encoded values (some of which may be the empty string)
	separated by period ('.') characters		separated by period ('.') characters
	o Security Considerations: See the Security Considerations section		o Security Considerations: See the Security Considerations section
	of this document		of [[ this document ]]
	o Interoperability Considerations: n/a		o Interoperability Considerations: n/a
	o Published Specification: [[ this document ]]		o Published Specification: [[ this document ]]
	o Applications that use this media type: OpenID Connect, Mozilla		o Applications that use this media type: OpenID Connect, Mozilla
	Browser ID, Salesforce, Google, numerous others		Persona, Salesforce, Google, numerous others
	o Additional Information: Magic number(s): n/a, File extension(s):		o Additional Information: Magic number(s): n/a, File extension(s):
	n/a, Macintosh file type code(s): n/a		n/a, Macintosh file type code(s): n/a
	o Person & email address to contact for further information: Michael		o Person & email address to contact for further information: Michael
	B. Jones, mbj@microsoft.com		B. Jones, mbj@microsoft.com
	o Intended Usage: COMMON		o Intended Usage: COMMON
	o Restrictions on Usage: none		o Restrictions on Usage: none
	o Author: Michael B. Jones, mbj@microsoft.com		o Author: Michael B. Jones, mbj@microsoft.com
	o Change Controller: IETF		o Change Controller: IETF
	10. Security Considerations		10. Security Considerations
	skipping to change at page 17, line 46 ¶		skipping to change at page 18, line 46 ¶
	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.
	While syntactically, the signing and encryption operations for Nested		While syntactically, the signing and encryption operations for Nested
	JWTs may be applied in any order, normally senders should sign the		JWTs may be applied in any order, normally senders should sign the
	message and then encrypt the result (thus encrypting the signature).		message and then encrypt the result (thus encrypting the signature).
	This prevents attacks in which the signature is stripped, leaving		This prevents attacks in which the signature is stripped, leaving
	just an encrypted message, as well as providing privacy for the		just an encrypted message, as well as providing privacy for the
	signer. Furthermore, signatures over encrypted text are not		signer. Furthermore, signatures over encrypted text are not
	considered valid in many jurisdictions.		considered valid in many jurisdictions.
			Note that potential concerns about security issues related to the
			order of signing and encryption operations are already addressed by
			the underlying JWS and JWE specifications; in particular, because JWE
			only supports the use of authenticated encryption algorithms,
			cryptographic concerns about the potential need to sign after
			encryption that apply in many contexts do not apply to this
			specification.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[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),
	December 2012.		April 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), December 2012.		(work in progress), April 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), December 2012.		in progress), April 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.
	[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.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003.		10646", STD 63, RFC 3629, November 2003.
	[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.
	[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and		[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
	Registration Procedures", BCP 13, RFC 4288, December 2005.		Registration Procedures", RFC 4288, December 2005.
	[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		[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
	for OAuth", RFC 6755, October 2012.		for OAuth", RFC 6755, October 2012.
	[USA15] Davis, M., Whistler, K., and M. Duerst, "Unicode
	Normalization Forms", Unicode Standard Annex 15, 09 2009.
	11.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
	skipping to change at page 19, line 48 ¶		skipping to change at page 21, line 4 ¶
	[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. 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 CBC. AES CBC does not have		recipient using RSAES-PKCS1-V1_5 and AES_128_CBC_HMAC_SHA_256.
	an integrated integrity check, so a separate integrity check
	calculation is performed using HMAC SHA-256, with separate encryption
	and integrity keys being derived from a master key using the Concat
	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 Encryption Key is encrypted to the recipient using the
	RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key and		RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key and
	o the Plaintext is encrypted using the AES CBC algorithm with a 128		o the Plaintext is encrypted using the AES_128_CBC_HMAC_SHA_256
	bit key to produce the Ciphertext, with the integrity of the		algorithm to produce the Ciphertext.
	Ciphertext and the parameters used to create it being secured
	using the HMAC SHA-256 algorithm.
	{"alg":"RSA1_5","enc":"A128CBC+HS256"}		{"alg":"RSA1_5","enc":"A128CBC-HS256"}
	Other than using the bytes of the UTF-8 representation of the JSON		Other than using the octets 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:
	eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDK0hTMjU2In0.		eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
	pwaFh7yJPivLjjPkzC-GeAyHuy7AinGcS51AZ7TXnwkC80Ow1aW47kcT_UV54ubo		EcA0HJqCj8MhE2Gu-d-wrNgxBabw3eQg7feWIelT_k0g_MOf7imKPsFqtiy3k08u
	nONbeArwOVuR7shveXnwPmucwrk_3OCcHrCbE1HR-Jfme2mF_WR3zUMcwqmU0RlH		8ynLJ-f9FaPXJZxk0y9JQm5nM-CQchlwb_R-vxA3QO-MuUgqDxhFSWhcmIfvUdme
	kwx9txo_sKRasjlXc8RYP-evLCmT1XRXKjtY5l44Gnh0A84hGvVfMxMfCWXh38hi		ezpuGpcEBv_Z9P-RiliSGqnveR_FW8HabEbypZa6lOkkSPYOc_qVm3FV6bdRlVT3
	2h8JMjQHGQ3mivVui5lbf-zzb3qXXxNO1ZYoWgs5tP1-T54QYc9Bi9wodFPWNPKB		wQblSnRaGtNNad5ITsZgjdIdTUu4h6ljGXrZNaXMgGLQtwbHzr07I2qxLyaX0zIE
	kY-BgewG-Vmc59JqFeprk1O08qhKQeOGCWc0WPC_n_LIpGWH6spRm7KGuYdgDMkQ		tiLOZTEs3Z-a5P3s0wLkhRuFbM3nd-WXJcrPGDOPNzvGt_Qz4bOz5vB9c1UzMaZZ
	bd4uuB0uPPLx_euVCdrVrA.		RVVqVa0mi-Orar8uOW_wGQ.
	AxY8DCtDaGlsbGljb3RoZQ.		AxY8DCtDaGlsbGljb3RoZQ.
	7MI2lRCaoyYx1HclVXkr8DhmDoikTmOp3IdEmm4qgBThFkqFqOs3ivXLJTku4M0f		MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeWnDYvpIAeZ72deHxz3roJDXQyhxx0wKaM
	laMAbGG_X6K8_B-0E-7ak-Olm_-_V03oBUUGTAc-F0A.		HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7sln1Eu9g3J8.
	OwWNxnC-BMEie-GkFHzVWiNiaV3zUHf6fCOGTwbRckU		_k19B2pzd5OvZ-ngGi8cZw
	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
	skipping to change at page 22, line 13 ¶		skipping to change at page 23, line 11 ¶
	Dirk Balfanz, Richard Barnes, Brian Campbell, Breno de Medeiros, Dick		Dirk Balfanz, Richard Barnes, Brian Campbell, Breno de Medeiros, Dick
	Hardt, Joe Hildebrand, Jeff Hodges, Edmund Jay, Yaron Y. Goland, Ben		Hardt, Joe Hildebrand, Jeff Hodges, Edmund Jay, Yaron Y. Goland, Ben
	Laurie, James Manger, Prateek Mishra, Tony Nadalin, Axel Nennker,		Laurie, James Manger, Prateek Mishra, Tony Nadalin, Axel Nennker,
	John Panzer, Emmanuel Raviart, David Recordon, Eric Rescorla, Jim		John Panzer, Emmanuel Raviart, David Recordon, Eric Rescorla, Jim
	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. Open Issues		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 ]]
	The following items remain to be considered or done in this draft:		-07
	o Track changes to the underlying JOSE specifications.
	o Should all claims continue to be required to be understood by		o Defined that the default action for claims that are not understood
	implementations using them when used in a security-related context		is to ignore them unless otherwise specified by applications.
	or should a means of declaring that specific claims may be safely
	ignored if not understood should be defined? This is related to
	the similar JOSE issue about whether all header fields must
	continue to be understood.
	Appendix F. Document History		o Changed from using the term "byte" to "octet" when referring to 8
			bit values.
	[[ to be removed by the RFC editor before publication as an RFC ]]		o Tracked encryption computation changes in the JWE specification.
	-06		-06
	o Changed the name of the "prn" claim to "sub" (subject) both to		o Changed the name of the "prn" claim to "sub" (subject) both to
	more closely align with SAML name usage and to use a more		more closely align with SAML name usage and to use a more
	intuitive name.		intuitive name.
	o Allow JWTs to have multiple audiences.		o Allow JWTs to have multiple audiences.
	o Applied editorial improvements suggested by Jeff Hodges, Prateek		o Applied editorial improvements suggested by Jeff Hodges, Prateek
End of changes. 48 change blocks.
	142 lines changed or deleted		138 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/