< draft-ietf-oauth-json-web-token-26.txt		draft-ietf-oauth-json-web-token-27.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: March 27, 2015 Ping Identity		Expires: March 29, 2015 Ping Identity
	N. Sakimura		N. Sakimura
	NRI		NRI
	September 23, 2014		September 25, 2014
	JSON Web Token (JWT)		JSON Web Token (JWT)
	draft-ietf-oauth-json-web-token-26		draft-ietf-oauth-json-web-token-27
	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 March 27, 2015.		This Internet-Draft will expire on March 29, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 16, line 22 ¶		skipping to change at page 16, line 22 ¶
	10. IANA Considerations		10. IANA Considerations
	10.1. JSON Web Token Claims Registry		10.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 JWT Claim Names. The registry records the Claim Name		registry for JWT Claim Names. The registry records the Claim Name
	and a reference to the specification that defines it. This		and a reference to the specification that defines it. This
	specification registers the Claim Names defined in Section 4.1.		specification registers the Claim Names defined in Section 4.1.
	Values are registered on a Specification Required [RFC5226] basis		Values are registered on a Specification Required [RFC5226] basis
	after a two-week review period on the [TBD]@ietf.org mailing list, on		after a three-week review period on the [TBD]@ietf.org mailing list,
	the advice of one or more Designated Experts. However, to allow for		on the advice of one or more Designated Experts. However, to allow
	the allocation of values prior to publication, the Designated		for the allocation of values prior to publication, the Designated
	Expert(s) may approve registration once they are satisfied that such		Expert(s) may approve registration once they are satisfied that such
	a specification will be published.		a 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 the RFC Editor: The name		for access token type: example"). [[ Note to the RFC Editor: The name
	of the mailing list should be determined in consultation with the		of the mailing list should be determined in consultation with the
	IESG and IANA. Suggested name: jwt-reg-review. ]]		IESG and IANA. Suggested name: jwt-reg-review. ]]
	Within the review period, the Designated Expert(s) will either		Within the review period, the Designated Expert(s) will either
	skipping to change at page 21, line 45 ¶		skipping to change at page 21, line 45 ¶
	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.
	[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.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, October 2006.
	[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.
	[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data		[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 7159, March 2014.		Interchange Format", RFC 7159, March 2014.
	13.2. Informative References		13.2. Informative References
	[CanvasApp]		[CanvasApp]
	Facebook, "Canvas Applications", 2010.		Facebook, "Canvas Applications", 2010.
	skipping to change at page 23, line 24 ¶		skipping to change at page 23, line 21 ¶
	A.1. Example Encrypted JWT		A.1. Example Encrypted JWT
	This example encrypts the same claims as used in Section 3.1 to the		This example encrypts the same claims as used in Section 3.1 to the
	recipient using RSAES-PKCS1-V1_5 and AES_128_CBC_HMAC_SHA_256.		recipient using RSAES-PKCS1-V1_5 and AES_128_CBC_HMAC_SHA_256.
	The following example JOSE Header declares that:		The following example JOSE Header 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 authenticated encryption is performed on the Plaintext using the
	algorithm to produce the JWE Ciphertext.		AES_128_CBC_HMAC_SHA_256 algorithm to produce the JWE Ciphertext
			and the JWE Authentication Tag.
	{"alg":"RSA1_5","enc":"A128CBC-HS256"}		{"alg":"RSA1_5","enc":"A128CBC-HS256"}
	Other than using the octets of the UTF-8 representation of the JWT		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:
	skipping to change at page 24, line 21 ¶		skipping to change at page 24, line 21 ¶
	The inner signed JWT is identical to the example in Appendix A.2 of		The inner signed JWT is identical to the example in Appendix A.2 of
	[JWS]. Therefore, its computation is not repeated here. This		[JWS]. Therefore, its computation is not repeated here. This
	example then encrypts this inner JWT to the recipient using RSAES-		example then encrypts this inner JWT to the recipient using RSAES-
	PKCS1-V1_5 and AES_128_CBC_HMAC_SHA_256.		PKCS1-V1_5 and AES_128_CBC_HMAC_SHA_256.
	The following example JOSE Header declares that:		The following example JOSE Header 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,		RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key,
	o the Plaintext is encrypted using the AES_128_CBC_HMAC_SHA_256		o authenticated encryption is performed on the Plaintext using the
	algorithm to produce the JWE Ciphertext, and		AES_128_CBC_HMAC_SHA_256 algorithm to produce the JWE Ciphertext
			and the JWE Authentication Tag, and
	o the Plaintext is itself a JWT.		o the Plaintext is itself a JWT.
	{"alg":"RSA1_5","enc":"A128CBC-HS256","cty":"JWT"}		{"alg":"RSA1_5","enc":"A128CBC-HS256","cty":"JWT"}
	Base64url encoding the octets of the UTF-8 representation of the JOSE		Base64url encoding the octets of the UTF-8 representation of the JOSE
	Header yields this encoded JOSE Header value:		Header yields this encoded JOSE Header value:
	eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0		eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0
	skipping to change at page 26, line 39 ¶		skipping to change at page 26, line 40 ¶
	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.		Applications [CanvasApp], all of which influenced this draft.
	This specification is the work of the OAuth Working Group, which		This specification is the work of the OAuth Working Group, which
	includes dozens of active and dedicated participants. In particular,		includes dozens of active and dedicated participants. In particular,
	the following individuals contributed ideas, feedback, and wording		the following individuals contributed ideas, feedback, and wording
	that influenced this specification:		that influenced this specification:
	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,
	Laurie, James Manger, Prateek Mishra, Kathleen Moriarty, Tony		Warren Kumari, Ben Laurie, James Manger, Prateek Mishra, Kathleen
	Nadalin, Axel Nennker, John Panzer, Emmanuel Raviart, David Recordon,		Moriarty, Tony Nadalin, Axel Nennker, John Panzer, Emmanuel Raviart,
	Eric Rescorla, Jim Schaad, Paul Tarjan, Hannes Tschofenig, and Sean		David Recordon, Eric Rescorla, Jim Schaad, Paul Tarjan, Hannes
	Turner.		Tschofenig, Sean Turner, and Tom Yu.
	Hannes Tschofenig and Derek Atkins chaired the OAuth working group		Hannes Tschofenig and Derek Atkins chaired the OAuth working group
	and Sean Turner, Stephen Farrell, and Kathleen Moriarty served as		and Sean Turner, Stephen Farrell, and Kathleen Moriarty served as
	Security area directors during the creation of this specification.		Security area directors 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 ]]
			-27
			o Removed unused reference to RFC 4648.
			o Changed to use the term "authenticated encryption" instead of
			"encryption", where appropriate.
			o Changed the registration review period to three weeks.
			o Acknowledged additional contributors.
	-26		-26
	o Removed an ambiguity in numeric date representations by specifying		o Removed an ambiguity in numeric date representations by specifying
	that leap seconds are handled in the manner specified by POSIX.1.		that leap seconds are handled in the manner specified by POSIX.1.
	o Addressed Gen-ART review comments by Russ Housley.		o Addressed Gen-ART review comments by Russ Housley.
	o Addressed secdir review comments by Warren Kumari and Stephen		o Addressed secdir review comments by Warren Kumari and Stephen
	Kent.		Kent.
End of changes. 10 change blocks.
	19 lines changed or deleted		29 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/