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