< draft-ietf-oauth-json-web-token-08.txt		draft-ietf-oauth-json-web-token-09.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: November 29, 2013 Ping Identity		Expires: January 12, 2014 Ping Identity
	N. Sakimura		N. Sakimura
	NRI		NRI
	May 28, 2013		July 11, 2013
	JSON Web Token (JWT)		JSON Web Token (JWT)
	draft-ietf-oauth-json-web-token-08		draft-ietf-oauth-json-web-token-09
	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 November 29, 2013.		This Internet-Draft will expire on January 12, 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 13 ¶		skipping to change at page 3, line 13 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 5		1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. JSON Web Token (JWT) Overview . . . . . . . . . . . . . . . . 7		3. JSON Web Token (JWT) Overview . . . . . . . . . . . . . . . . 7
	3.1. Example JWT . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. Example JWT . . . . . . . . . . . . . . . . . . . . . . . 7
	4. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Reserved Claim Names . . . . . . . . . . . . . . . . . . . 8		4.1. Reserved Claim Names . . . . . . . . . . . . . . . . . . . 9
	4.1.1. "iss" (Issuer) Claim . . . . . . . . . . . . . . . . . 9		4.1.1. "iss" (Issuer) Claim . . . . . . . . . . . . . . . . . 9
	4.1.2. "sub" (Subject) Claim . . . . . . . . . . . . . . . . 9		4.1.2. "sub" (Subject) Claim . . . . . . . . . . . . . . . . 9
	4.1.3. "aud" (Audience) Claim . . . . . . . . . . . . . . . . 9		4.1.3. "aud" (Audience) Claim . . . . . . . . . . . . . . . . 9
	4.1.4. "exp" (Expiration Time) Claim . . . . . . . . . . . . 9		4.1.4. "exp" (Expiration Time) Claim . . . . . . . . . . . . 10
	4.1.5. "nbf" (Not Before) Claim . . . . . . . . . . . . . . . 9		4.1.5. "nbf" (Not Before) Claim . . . . . . . . . . . . . . . 10
	4.1.6. "iat" (Issued At) Claim . . . . . . . . . . . . . . . 10		4.1.6. "iat" (Issued At) Claim . . . . . . . . . . . . . . . 10
	4.1.7. "jti" (JWT ID) Claim . . . . . . . . . . . . . . . . . 10		4.1.7. "jti" (JWT ID) Claim . . . . . . . . . . . . . . . . . 10
	4.1.8. "typ" (Type) Claim . . . . . . . . . . . . . . . . . . 10		4.1.8. "typ" (Type) Claim . . . . . . . . . . . . . . . . . . 10
	4.2. Public Claim Names . . . . . . . . . . . . . . . . . . . . 10		4.2. Public Claim Names . . . . . . . . . . . . . . . . . . . . 11
	4.3. Private Claim Names . . . . . . . . . . . . . . . . . . . 10		4.3. Private Claim Names . . . . . . . . . . . . . . . . . . . 11
	5. JWT Header . . . . . . . . . . . . . . . . . . . . . . . . . . 11		5. JWT Header . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.1. "typ" (Type) Header Parameter . . . . . . . . . . . . . . 11		5.1. "typ" (Type) Header Parameter . . . . . . . . . . . . . . 11
	5.2. "cty" (Content Type) Header Parameter . . . . . . . . . . 11		5.2. "cty" (Content Type) Header Parameter . . . . . . . . . . 12
	6. Plaintext JWTs . . . . . . . . . . . . . . . . . . . . . . . . 11		6. Plaintext JWTs . . . . . . . . . . . . . . . . . . . . . . . . 12
	6.1. Example Plaintext JWT . . . . . . . . . . . . . . . . . . 12		6.1. Example Plaintext JWT . . . . . . . . . . . . . . . . . . 12
	7. Rules for Creating and Validating a JWT . . . . . . . . . . . 12		7. Rules for Creating and Validating a JWT . . . . . . . . . . . 13
	7.1. String Comparison Rules . . . . . . . . . . . . . . . . . 14		7.1. String Comparison Rules . . . . . . . . . . . . . . . . . 15
	8. Cryptographic Algorithms . . . . . . . . . . . . . . . . . . . 14		8. Cryptographic Algorithms . . . . . . . . . . . . . . . . . . . 15
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	9.1. JSON Web Token Claims Registry . . . . . . . . . . . . . . 15		9.1. JSON Web Token Claims Registry . . . . . . . . . . . . . . 16
	9.1.1. Registration Template . . . . . . . . . . . . . . . . 16		9.1.1. Registration Template . . . . . . . . . . . . . . . . 16
	9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 16		9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 17
	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 . . . . . . . . . . . . . . . . . . . . . . . 18
	9.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 17		9.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 18
	9.4. Media Type Registration . . . . . . . . . . . . . . . . . 17		9.4. Media Type Registration . . . . . . . . . . . . . . . . . 18
	9.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 17		9.4.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 . . . . . . . . . . . . . . . . 20		Appendix A. Example Encrypted JWT . . . . . . . . . . . . . . . . 21
	Appendix B. Relationship of JWTs to SAML Assertions . . . . . . . 21		Appendix B. Relationship of JWTs to SAML Assertions . . . . . . . 22
	Appendix C. Relationship of JWTs to Simple Web Tokens (SWTs) . . 22		Appendix C. Relationship of JWTs to Simple Web Tokens (SWTs) . . 23
	Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 22		Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 23
	Appendix E. Document History . . . . . . . . . . . . . . . . . . 23		Appendix E. Document History . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
	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 8, line 5 ¶		skipping to change at page 8, line 5 ¶
	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 octets of the UTF-8 representation of the JSON		The following octet sequence, which is the UTF-8 representation of
	Claims Set yields this Encoded JWS Payload (with line breaks for		the JWT Claims Set above, is the JWS Payload:
	display purposes only):
			[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10,
			32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56,
			48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97,
			109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111,
			111, 116, 34, 58, 116, 114, 117, 101, 125]
			Base64url encoding the JWS Payload yields this Encoded JWS Payload
			(with line breaks for 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:
	dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk		dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
	skipping to change at page 8, line 36 ¶		skipping to change at page 8, line 44 ¶
	.		.
	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; receipients MUST either reject JWTs with duplicate
			Claim Names or use a JSON parser that returns only the lexically last
			duplicate member name, as specified in Section 15.12 (The JSON
			Object) of ECMAScript 5.1 [ECMAScript].
	The set of claims that a JWT must contain to be considered valid is		The set of claims that a JWT must contain to be considered valid is
	context-dependent and is outside the scope of this specification.		context-dependent and is outside the scope of this specification.
	Specific applications of JWTs will require implementations to		Specific applications of JWTs will require implementations to
	understand and process some claims in particular ways. However, in		understand and process some claims in particular ways. However, in
	the absence of such requirements, all claims that are not understood		the absence of such requirements, all claims that are not understood
	by implementations SHOULD be ignored.		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.
	skipping to change at page 10, line 28 ¶		skipping to change at page 10, line 43 ¶
	The "jti" (JWT ID) claim provides a unique identifier for the JWT.		The "jti" (JWT ID) claim provides a unique identifier for the JWT.
	The identifier value MUST be assigned in a manner that ensures that		The identifier value MUST be assigned in a manner that ensures that
	there is a negligible probability that the same value will be		there is a negligible probability that the same value will be
	accidentally assigned to a different data object. The "jti" claim		accidentally assigned to a different data object. The "jti" claim
	can be used to prevent the JWT from being replayed. The "jti" value		can be used to prevent the JWT from being replayed. The "jti" value
	is a case sensitive string. Use of this claim is OPTIONAL.		is a case sensitive string. Use of this claim is OPTIONAL.
	4.1.8. "typ" (Type) Claim		4.1.8. "typ" (Type) Claim
	The "typ" (type) claim is used to declare a type for the contents of		The "typ" (type) claim MAY be used to declare a type for the contents
	this JWT Claims Set. The "typ" value is a case sensitive string. Use		of this JWT Claims Set in an application-specific manner in contexts
	of this claim is OPTIONAL.		where this is useful to the application. The "typ" value is a case
			sensitive string. Use of this claim is OPTIONAL.
	The values used for the "typ" claim come from the same value space as		The values used for the "typ" claim come from the same value space as
	the "typ" header parameter, with the same rules applying.		the "typ" header parameter, with the same rules applying.
	4.2. Public Claim Names		4.2. Public Claim Names
	Claim Names can be defined at will by those using JWTs. However, in		Claim Names can be defined at will by those using JWTs. However, in
	order to prevent collisions, any new Claim Name SHOULD either be		order to prevent collisions, any new Claim Name SHOULD either be
	registered in the IANA JSON Web Token Claims registry Section 9.1 or		registered in the IANA JSON Web Token Claims registry Section 9.1 or
	be a Public Name: a value that contains a Collision Resistant		be a Public Name: a value that contains a Collision Resistant
	Namespace. In each case, the definer of the name or value needs to		Namespace. In each case, the definer of the name or value needs to
	take reasonable precautions to make sure they are in control of the		take reasonable precautions to make sure they are in control of the
	part of the namespace they use to define the Claim Name.		part of the namespace they use to define the Claim Name.
	4.3. Private Claim Names		4.3. Private Claim Names
	A producer and consumer of a JWT may agree to use Claim Names that		A producer and consumer of a JWT MAY agree to use Claim Names that
	are Private Names: names that are not Reserved Names Section 4.1 or		are Private Names: names that are not Reserved Names Section 4.1 or
	Public Names Section 4.2. Unlike Public Names, Private Names are		Public Names Section 4.2. Unlike Public Names, Private Names are
	subject to collision and should be used with caution.		subject to collision and should be used with caution.
	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; receipients MUST either reject JWTs with duplicate Header
	rejected. The corresponding values are referred to as Header		Parameter Names or use a JSON parser that returns only the lexically
	Parameter Values.		last duplicate member name, as specified in Section 15.12 (The JSON
			Object) of ECMAScript 5.1 [ECMAScript]. The corresponding values are
			referred to as Header Parameter Values.
	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 MAY be used to declare the type of
	object. If present, it is RECOMMENDED that its value be either "JWT"		this JWT in an application-specific manner in contexts where this is
	or "urn:ietf:params:oauth:token-type:jwt" to indicate that this		useful to the application. This parameter has no effect upon the JWT
			processing. If present, it is RECOMMENDED that its value be either
			"JWT" or "urn:ietf:params:oauth:token-type:jwt" to indicate that this
	object is a JWT. The "typ" value is a case sensitive string. Use of		object is a JWT. The "typ" value is a case sensitive string. Use of
	this header parameter is OPTIONAL.		this header parameter is OPTIONAL.
	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.
	skipping to change at page 12, line 23 ¶		skipping to change at page 12, line 48 ¶
	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 octets of the UTF-8 representation of the JSON		Base64url encoding the octets of the UTF-8 representation of the JWT
	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 17, line 20 ¶		skipping to change at page 17, line 45 ¶
	o Claim Name: "typ"		o Claim Name: "typ"
	o Change Controller: IETF		o Change Controller: IETF
	o Specification Document(s): Section 4.1.8 of [[ this document ]]		o Specification Document(s): Section 4.1.8 of [[ this document ]]
	9.2. Sub-Namespace Registration of urn:ietf:params:oauth:token-type:jwt		9.2. Sub-Namespace Registration of urn:ietf:params:oauth:token-type:jwt
	9.2.1. Registry Contents		9.2.1. Registry Contents
	This specification registers the value "token-type:jwt" in the IANA		This specification registers the value "token-type:jwt" in the IANA
	urn:ietf:params:oauth registry established in An IETF URN Sub-		urn:ietf:params:oauth registry established in An IETF URN Sub-
	Namespace for OAuth [RFC6755].		Namespace for OAuth [RFC6755], which can be used to indicate that the
			content is a JWT.
	o URN: urn:ietf:params:oauth:token-type:jwt		o URN: urn:ietf:params:oauth:token-type:jwt
	o Common Name: JSON Web Token (JWT) Token Type		o Common Name: JSON Web Token (JWT) Token Type
	o Change Controller: IETF		o Change Controller: IETF
	o Specification Document(s): [[this document]]		o Specification Document(s): [[this document]]
	9.3. JSON Web Signature and Encryption Type Values Registration		9.3. JSON Web Signature and Encryption Type Values Registration
	9.3.1. Registry Contents		9.3.1. Registry Contents
	This specification registers the "JWT" type value in the IANA JSON		This specification registers the "JWT" type value in the IANA JSON
	Web Signature and Encryption Type Values registry [JWS]:		Web Signature and Encryption Type Values registry [JWS], which can be
			used to indicate that the content is a JWT.
	o "typ" Header Parameter Value: "JWT"		o "typ" Header Parameter Value: "JWT"
	o Abbreviation for MIME Type: application/jwt		o Abbreviation for MIME Type: application/jwt
	o Change Controller: IETF		o Change Controller: IETF
	o Specification Document(s): Section 5.1 of [[ this document ]]		o Specification Document(s): Section 5.1 of [[ this document ]]
	9.4. Media Type Registration		9.4. Media Type Registration
	9.4.1. Registry Contents		9.4.1. Registry Contents
	This specification registers the "application/jwt" Media Type		This specification registers the "application/jwt" Media Type
	[RFC2046] in the MIME Media Type registry [RFC4288] to indicate that		[RFC2046] in the MIME Media Type registry [RFC4288], which can be
	the content is a JWT.		used to indicate that 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 ]]
	skipping to change at page 19, line 11 ¶		skipping to change at page 19, line 40 ¶
	the underlying JWS and JWE specifications; in particular, because JWE		the underlying JWS and JWE specifications; in particular, because JWE
	only supports the use of authenticated encryption algorithms,		only supports the use of authenticated encryption algorithms,
	cryptographic concerns about the potential need to sign after		cryptographic concerns about the potential need to sign after
	encryption that apply in many contexts do not apply to this		encryption that apply in many contexts do not apply to this
	specification.		specification.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
			[ECMAScript]
			Ecma International, "ECMAScript Language Specification,
			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),
	May 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), May 2013.		(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), May 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.
	[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the		[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
	Internet: Timestamps", RFC 3339, July 2002.		Internet: Timestamps", RFC 3339, July 2002.
	skipping to change at page 21, line 17 ¶		skipping to change at page 21, line 48 ¶
	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
	o the Plaintext is encrypted using the AES_128_CBC_HMAC_SHA_256		o the Plaintext is encrypted using the AES_128_CBC_HMAC_SHA_256
	algorithm to produce the Ciphertext.		algorithm to produce the Ciphertext.
	{"alg":"RSA1_5","enc":"A128CBC-HS256"}		{"alg":"RSA1_5","enc":"A128CBC-HS256"}
	Other than using the octets of the UTF-8 representation of the JSON		Other than using the octets of the UTF-8 representation of the JWT
	Claims Set from Section 3.1 as the plaintext value, the computation		Claims Set from Section 3.1 as the plaintext value, the computation
	of this JWT is identical to the computation of the JWE in Appendix		of this JWT is identical to the computation of the JWE in Appendix
	A.2 of [JWE], including the keys used.		A.2 of [JWE], including the keys used.
	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:
	eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.		eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
	QR1Owv2ug2WyPBnbQrRARTeEk9kDO2w8qDcjiHnSJflSdv1iNqhWXaKH4MqAkQtM		QR1Owv2ug2WyPBnbQrRARTeEk9kDO2w8qDcjiHnSJflSdv1iNqhWXaKH4MqAkQtM
	oNfABIPJaZm0HaA415sv3aeuBWnD8J-Ui7Ah6cWafs3ZwwFKDFUUsWHSK-IPKxLG		oNfABIPJaZm0HaA415sv3aeuBWnD8J-Ui7Ah6cWafs3ZwwFKDFUUsWHSK-IPKxLG
	skipping to change at page 23, line 15 ¶		skipping to change at page 23, line 45 ¶
	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 ]]
			-09
			o Clarified that the "typ" header parameter is used in an
			application-specific manner and has no effect upon the JWT
			processing.
			o Stated that receipients MUST either reject JWTs with duplicate
			Header Parameter Names or with duplicate Claim Names or use a JSON
			parser that returns only the lexically last duplicate member name.
	-08		-08
	o Tracked a change to how JWEs are computed (which only affected the		o Tracked a change to how JWEs are computed (which only affected the
	example encrypted JWT value).		example encrypted JWT value).
	-07		-07
	o Defined that the default action for claims that are not understood		o Defined that the default action for claims that are not understood
	is to ignore them unless otherwise specified by applications.		is to ignore them unless otherwise specified by applications.
End of changes. 30 change blocks.
	49 lines changed or deleted		81 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/