< draft-ietf-oauth-json-web-token-28.txt		draft-ietf-oauth-json-web-token-29.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: April 17, 2015 Ping Identity		Expires: April 20, 2015 Ping Identity
	N. Sakimura		N. Sakimura
	NRI		NRI
	October 14, 2014		October 17, 2014
	JSON Web Token (JWT)		JSON Web Token (JWT)
	draft-ietf-oauth-json-web-token-28		draft-ietf-oauth-json-web-token-29
	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 38 ¶		skipping to change at page 1, line 38 ¶
	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 April 17, 2015.		This Internet-Draft will expire on April 20, 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 4, line 44 ¶		skipping to change at page 4, line 44 ¶
	Header", "JWS Compact Serialization", "JWS Payload", "JWS Signature",		Header", "JWS Compact Serialization", "JWS Payload", "JWS Signature",
	and "Unsecured JWS".		and "Unsecured JWS".
	These terms defined by the JSON Web Encryption (JWE) [JWE]		These terms defined by the JSON Web Encryption (JWE) [JWE]
	specification are incorporated into this specification: "JSON Web		specification are incorporated into this specification: "JSON Web
	Encryption (JWE)", "Content Encryption Key (CEK)", "JWE Compact		Encryption (JWE)", "Content Encryption Key (CEK)", "JWE Compact
	Serialization", "JWE Encrypted Key", "JWE Initialization Vector", and		Serialization", "JWE Encrypted Key", "JWE Initialization Vector", and
	"JWE Plaintext".		"JWE Plaintext".
	These terms defined by the Internet Security Glossary, Version 2		These terms defined by the Internet Security Glossary, Version 2
	[RFC4949] are incorporated into this specification: "Ciphertext" and		[RFC4949] are incorporated into this specification: "Ciphertext",
			"Digital Signature" "Message Authentication Code (MAC)", and
	"Plaintext".		"Plaintext".
	These terms are defined by this specification:		These terms are defined by this specification:
	JSON Web Token (JWT)		JSON Web Token (JWT)
	A string representing a set of claims as a JSON object that is		A string representing a set of claims as a JSON object that is
	encoded in a JWS or JWE, enabling the claims to be digitally		encoded in a JWS or JWE, enabling the claims to be digitally
	signed or MACed and/or encrypted.		signed or MACed and/or encrypted.
	JWT Claims Set		JWT Claims Set
	skipping to change at page 18, line 15 ¶		skipping to change at page 18, line 15 ¶
	o Webpage Title: (same as the protocol category)		o Webpage Title: (same as the protocol category)
	o Registry Name: JSON Web Token Claims		o Registry Name: JSON Web Token Claims
	]]		]]
	10.1.1. Registration Template		10.1.1. Registration Template
	Claim Name:		Claim Name:
	The name requested (e.g., "example"). Because a core goal of this		The name requested (e.g., "iss"). Because a core goal of this
	specification is for the resulting representations to be compact,		specification is for the resulting representations to be compact,
	it is RECOMMENDED that the name be short -- not to exceed 8		it is RECOMMENDED that the name be short -- not to exceed 8
	characters without a compelling reason to do so. This name is		characters without a compelling reason to do so. This name is
	case-sensitive. Names may not match other registered names in a		case-sensitive. Names may not match other registered names in a
	case-insensitive manner unless the Designated Expert(s) state that		case-insensitive manner unless the Designated Expert(s) state that
	there is a compelling reason to allow an exception in this		there is a compelling reason to allow an exception in this
	particular case.		particular case.
	Claim Description:		Claim Description:
	Brief description of the Claim (e.g., "Example description").		Brief description of the Claim (e.g., "Issuer").
	Change Controller:		Change Controller:
	For Standards Track RFCs, state "IESG". For others, give the name		For Standards Track RFCs, state "IESG". 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,
	email 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(s) that specify the parameter,		Reference to the document(s) that specify the parameter,
	preferably including URI(s) that can be used to retrieve copies of		preferably including URI(s) that can be used to retrieve copies of
	the document(s). An indication of the relevant sections may also		the document(s). An indication of the relevant sections may also
	skipping to change at page 22, line 41 ¶		skipping to change at page 22, line 41 ¶
	October 2014.		October 2014.
	[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",		[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
	draft-ietf-jose-json-web-encryption (work in progress),		draft-ietf-jose-json-web-encryption (work in progress),
	October 2014.		October 2014.
	[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), October 2014.		in progress), October 2014.
			[RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20,
			October 1969.
	[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.
	[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.
	skipping to change at page 24, line 31 ¶		skipping to change at page 24, line 34 ¶
	This section contains examples of JWTs. For other example JWTs, see		This section contains examples of JWTs. For other example JWTs, see
	Section 6.1 and Appendices A.1, A.2, and A.3 of [JWS].		Section 6.1 and Appendices A.1, A.2, and A.3 of [JWS].
	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.
	o authenticated encryption is performed on the Plaintext using the		o Authenticated encryption is performed on the Plaintext using the
	AES_128_CBC_HMAC_SHA_256 algorithm to produce the JWE Ciphertext		AES_128_CBC_HMAC_SHA_256 algorithm to produce the JWE Ciphertext
	and the JWE Authentication Tag.		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.
	skipping to change at page 25, line 30 ¶		skipping to change at page 25, line 30 ¶
	JWS to create a Nested JWT. In this case, the JWT Claims Set is		JWS to create a Nested JWT. In this case, the JWT Claims Set is
	first signed, and then encrypted.		first signed, and then encrypted.
	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 authenticated encryption is performed on the Plaintext using the		o Authenticated encryption is performed on the Plaintext using the
	AES_128_CBC_HMAC_SHA_256 algorithm to produce the JWE Ciphertext		AES_128_CBC_HMAC_SHA_256 algorithm to produce the JWE Ciphertext
	and the JWE Authentication Tag, and		and the JWE Authentication Tag.
	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
	The computation of this JWT is identical to the computation of the		The computation of this JWT is identical to the computation of the
	JWE in Appendix A.2 of [JWE], other than that different JOSE Header,		JWE in Appendix A.2 of [JWE], other than that different JOSE Header,
	Plaintext, JWE Initialization Vector, and Content Encryption Key		Plaintext, JWE Initialization Vector, and Content Encryption Key
	values are used. (The RSA key used is the same.)		values are used. (The RSA key used is the same.)
	The Payload used is the octets of the ASCII representation of the JWT		The Payload used is the octets of the ASCII [RFC20] representation of
	at the end of Appendix A.2.1 of [JWS] (with all whitespace and line		the JWT at the end of Appendix A.2.1 of [JWS] (with all whitespace
	breaks removed), which is a sequence of 458 octets.		and line breaks removed), which is a sequence of 458 octets.
	The JWE Initialization Vector value used (using JSON array notation)		The JWE Initialization Vector value used (using JSON array notation)
	is:		is:
	[82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53,		[82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53,
	50]		50]
	This example uses the Content Encryption Key represented by the		This example uses the Content Encryption Key represented by the
	base64url encoded value below:		base64url encoded value below:
	skipping to change at page 28, line 21 ¶		skipping to change at page 28, line 21 ¶
	Turner, and Tom Yu.		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 ]]
			-29
			o Used real values for examples in the IANA Registration Template.
	-28		-28
	o Addressed IESG review comments by Alissa Cooper, Barry Leiba,		o Addressed IESG review comments by Alissa Cooper, Barry Leiba,
	Stephen Farrell, Ted Lemon, and Richard Barnes.		Stephen Farrell, Ted Lemon, and Richard Barnes.
	o Changed the RFC 6755 reference to be informative, based upon		o Changed the RFC 6755 reference to be informative, based upon
	related IESG review feedback on draft-ietf-oauth-saml2-bearer.		related IESG review feedback on draft-ietf-oauth-saml2-bearer.
	-27		-27
End of changes. 16 change blocks.
	18 lines changed or deleted		26 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/