< draft-ietf-oauth-json-web-token-24.txt		draft-ietf-oauth-json-web-token-25.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 2, 2015 Ping Identity		Expires: January 5, 2015 Ping Identity
	N. Sakimura		N. Sakimura
	NRI		NRI
	July 1, 2014		July 4, 2014
	JSON Web Token (JWT)		JSON Web Token (JWT)
	draft-ietf-oauth-json-web-token-24		draft-ietf-oauth-json-web-token-25
	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 January 2, 2015.		This Internet-Draft will expire on January 5, 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 3, line 8 ¶		skipping to change at page 3, line 8 ¶
	urn:ietf:params:oauth:token-type:jwt . . . . . . . . . . . 18		urn:ietf:params:oauth:token-type:jwt . . . . . . . . . . . 18
	10.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 18		10.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 18
	10.3. Media Type Registration . . . . . . . . . . . . . . . . . 18		10.3. Media Type Registration . . . . . . . . . . . . . . . . . 18
	10.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 18		10.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 18
	10.4. Header Parameter Names Registration . . . . . . . . . . . 19		10.4. Header Parameter Names Registration . . . . . . . . . . . 19
	10.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 19		10.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 19
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 19		11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	11.1. Trust Decisions . . . . . . . . . . . . . . . . . . . . . 20		11.1. Trust Decisions . . . . . . . . . . . . . . . . . . . . . 20
	11.2. Signing and Encryption Order . . . . . . . . . . . . . . . 20		11.2. Signing and Encryption Order . . . . . . . . . . . . . . . 20
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20		12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 20
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 20		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	12.2. Informative References . . . . . . . . . . . . . . . . . . 21		13.1. Normative References . . . . . . . . . . . . . . . . . . . 21
			13.2. Informative References . . . . . . . . . . . . . . . . . . 21
	Appendix A. JWT Examples . . . . . . . . . . . . . . . . . . . . 22		Appendix A. JWT Examples . . . . . . . . . . . . . . . . . . . . 22
	A.1. Example Encrypted JWT . . . . . . . . . . . . . . . . . . 22		A.1. Example Encrypted JWT . . . . . . . . . . . . . . . . . . 23
	A.2. Example Nested JWT . . . . . . . . . . . . . . . . . . . . 23		A.2. Example Nested JWT . . . . . . . . . . . . . . . . . . . . 23
	Appendix B. Relationship of JWTs to SAML Assertions . . . . . . . 25		Appendix B. Relationship of JWTs to SAML Assertions . . . . . . . 25
	Appendix C. Relationship of JWTs to Simple Web Tokens (SWTs) . . 26		Appendix C. Relationship of JWTs to Simple Web Tokens (SWTs) . . 26
	Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 26		Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 26
	Appendix E. Document History . . . . . . . . . . . . . . . . . . 26		Appendix E. Document History . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
	1. Introduction		1. Introduction
	JSON Web Token (JWT) is a compact claims representation format		JSON Web Token (JWT) is a compact claims representation format
	skipping to change at page 11, line 9 ¶		skipping to change at page 11, line 9 ¶
	5.1. "typ" (Type) Header Parameter		5.1. "typ" (Type) Header Parameter
	The "typ" (type) Header Parameter defined by [JWS] and [JWE] is used		The "typ" (type) Header Parameter defined by [JWS] and [JWE] is used
	by JWT applications to declare the MIME Media Type [IANA.MediaTypes]		by JWT applications to declare the MIME Media Type [IANA.MediaTypes]
	of this complete JWT. This is intended for use by the JWT		of this complete JWT. This is intended for use by the JWT
	application when values that are not JWTs could also be present in an		application when values that are not JWTs could also be present in an
	application data structure that can contain a JWT object; the		application data structure that can contain a JWT object; the
	application can use this value to disambiguate among the different		application can use this value to disambiguate among the different
	kinds of objects that might be present. It will typically not be		kinds of objects that might be present. It will typically not be
	used by applications when it is already known that the object is a		used by applications when it is already known that the object is a
	JWT. This parameter has no effect upon the JWT processing. If		JWT. This parameter is ignored by JWT implementations; any
			processing of this parameter is performed by the JWT application. If
	present, it is RECOMMENDED that its value be "JWT" to indicate that		present, it is RECOMMENDED that its value be "JWT" to indicate that
	this object is a JWT. While media type names are not case-sensitive,		this object is a JWT. While media type names are not case-sensitive,
	it is RECOMMENDED that "JWT" always be spelled using uppercase		it is RECOMMENDED that "JWT" always be spelled using uppercase
	characters for compatibility with legacy implementations. Use of		characters for compatibility with legacy implementations. 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 defined by [JWS] and [JWE]		The "cty" (content type) Header Parameter defined by [JWS] and [JWE]
	is used by this specification to convey structural information about		is used by this specification to convey structural information about
	skipping to change at page 20, line 42 ¶		skipping to change at page 20, line 42 ¶
	considered valid in many jurisdictions.		considered valid in many jurisdictions.
	Note that potential concerns about security issues related to the		Note that potential concerns about security issues related to the
	order of signing and encryption operations are already addressed by		order of signing and encryption operations are already addressed by
	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.
	12. References		12. Privacy Considerations
	12.1. Normative References		A JWT may contain privacy-sensitive information. When this is the
			case, measures must be taken to prevent disclosure of this
			information to unintended parties. One way to achieve this is to use
			an encrypted JWT. Another way is to ensure that JWTs containing
			unencrypted privacy-sensitive information are only transmitted over
			encrypted channels or protocols, such as TLS.
			13. References
			13.1. Normative References
	[ECMAScript]		[ECMAScript]
	Ecma International, "ECMAScript Language Specification,		Ecma International, "ECMAScript Language Specification,
	5.1 Edition", ECMA 262, June 2011.		5.1 Edition", ECMA 262, June 2011.
	[IANA.MediaTypes]		[IANA.MediaTypes]
	Internet Assigned Numbers Authority (IANA), "MIME Media		Internet Assigned Numbers Authority (IANA), "MIME Media
	Types", 2005.		Types", 2005.
	[JWA] Jones, M., "JSON Web Algorithms (JWA)",		[JWA] Jones, M., "JSON Web Algorithms (JWA)",
	skipping to change at page 21, line 39 ¶		skipping to change at page 21, line 49 ¶
	[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.
	[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.
	12.2. Informative References		13.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 27, line 4 ¶		skipping to change at page 27, line 4 ¶
	Eric Rescorla, Jim Schaad, Paul Tarjan, Hannes Tschofenig, and Sean		Eric Rescorla, Jim Schaad, Paul Tarjan, Hannes Tschofenig, and Sean
	Turner.		Turner.
	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 ]]
			-25
			o Reworded the language about JWT implementations ignoring the "typ"
			parameter, explicitly saying that its processing is performed by
			JWT applications.
			o Added a Privacy Considerations section.
	-24		-24
	o Cleaned up the reference syntax in a few places.		o Cleaned up the reference syntax in a few places.
	o Applied minor wording changes to the Security Considerations		o Applied minor wording changes to the Security Considerations
	section.		section.
	-23		-23
	o Replaced the terms JWS Header, JWE Header, and JWT Header with a		o Replaced the terms JWS Header, JWE Header, and JWT Header with a
End of changes. 11 change blocks.
	12 lines changed or deleted		31 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/