draft-ietf-oauth-jwt-bearer-04.txt		draft-ietf-oauth-jwt-bearer-05.txt
	OAuth Working Group M. Jones		OAuth Working Group M.B. Jones
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track B. Campbell		Intended status: Standards Track B. Campbell
	Expires: June 30, 2013 Ping Identity		Expires: September 30, 2013 Ping Identity
	C. Mortimore		C. Mortimore
	Salesforce		Salesforce
	December 27, 2012		March 29, 2013
	JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0		JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and
	draft-ietf-oauth-jwt-bearer-04		Authorization Grants
			draft-ietf-oauth-jwt-bearer-05
	Abstract		Abstract
	This specification defines the use of a JSON Web Token (JWT) Bearer		This specification defines the use of a JSON Web Token (JWT) Bearer
	Token as a means for requesting an OAuth 2.0 access token as well as		Token as a means for requesting an OAuth 2.0 access token as well as
	for use as a means of client authentication.		for use as a means of client authentication.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 June 30, 2013.		This Internet-Draft will expire on September 30, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. HTTP Parameter Bindings for Transporting Assertions . . . . . 4		2. HTTP Parameter Bindings for Transporting Assertions . . . . . 4
	2.1. Using JWTs as Authorization Grants . . . . . . . . . . . . 4		2.1. Using JWTs as Authorization Grants . . . . . . . . . . . 4
	2.2. Using JWTs for Client Authentication . . . . . . . . . . . 5		2.2. Using JWTs for Client Authentication . . . . . . . . . . 5
	3. JWT Format and Processing Requirements . . . . . . . . . . . . 5		3. JWT Format and Processing Requirements . . . . . . . . . . . 6
	3.1. Authorization Grant Processing . . . . . . . . . . . . . . 7		3.1. Authorization Grant Processing . . . . . . . . . . . . . 7
	3.2. Client Authentication Processing . . . . . . . . . . . . . 7		3.2. Client Authentication Processing . . . . . . . . . . . . 7
	4. Authorization Grant Example . . . . . . . . . . . . . . . . . 7		4. Authorization Grant Example . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Interoperability Considerations . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6.1. Sub-Namespace Registration of		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	urn:ietf:params:oauth:grant-type:jwt-bearer . . . . . . . 8		7.1. Sub-Namespace Registration of urn:ietf:params:oauth
	6.2. Sub-Namespace Registration of		:grant-type:jwt-bearer . . . . . . . . . . . . . . . . . 9
	urn:ietf:params:oauth:client-assertion-type:jwt-bearer . . 9		7.2. Sub-Namespace Registration of urn:ietf:params:oauth
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		:client-assertion-type:jwt-bearer . . . . . . . . . . . . 10
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.2. Informative References . . . . . . . . . . . . . . . . . . 10		8.1. Normative References . . . . . . . . . . . . . . . . . . 10
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10		8.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 10		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Appendix B. Document History . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	JSON Web Token (JWT) [JWT] is a JavaScript Object Notation (JSON)		JSON Web Token (JWT) [JWT] is a JavaScript Object Notation (JSON)
	[RFC4627] based security token encoding that enables identity and		[RFC4627] based security token encoding that enables identity and
	security information to be shared across security domains. A		security information to be shared across security domains. A
	security token is generally issued by an identity provider and		security token is generally issued by an identity provider and
	consumed by a relying party that relies on its content to identify		consumed by a relying party that relies on its content to identify
	the token's subject for security related purposes.		the token's subject for security related purposes.
	skipping to change at page 3, line 29		skipping to change at page 3, line 9
	term used to describe intermediate credentials that represent the		term used to describe intermediate credentials that represent the
	resource owner authorization. An authorization grant is used by the		resource owner authorization. An authorization grant is used by the
	client to obtain an access token. Several authorization grant types		client to obtain an access token. Several authorization grant types
	are defined to support a wide range of client types and user		are defined to support a wide range of client types and user
	experiences. OAuth also allows for the definition of new extension		experiences. OAuth also allows for the definition of new extension
	grant types to support additional clients or to provide a bridge		grant types to support additional clients or to provide a bridge
	between OAuth and other trust frameworks. Finally, OAuth allows the		between OAuth and other trust frameworks. Finally, OAuth allows the
	definition of additional authentication mechanisms to be used by		definition of additional authentication mechanisms to be used by
	clients when interacting with the authorization server.		clients when interacting with the authorization server.
	The Assertion Framework for OAuth 2.0 [I-D.ietf-oauth-assertions] is		The Assertion Framework for OAuth 2.0 Client Authentication and
	an abstract extension to OAuth 2.0 that provides a general framework		Authorization Grants [I-D.ietf-oauth-assertions] specification is an
	for the use of Assertions (a.k.a. Security Tokens) as client		abstract extension to OAuth 2.0 that provides a general framework for
	credentials and/or authorization grants with OAuth 2.0. This		the use of Assertions (a.k.a. Security Tokens) as client credentials
	specification profiles the Assertion Framework for OAuth 2.0		and/or authorization grants with OAuth 2.0. This specification
	[I-D.ietf-oauth-assertions] to define an extension grant type that		profiles the Assertion Framework for OAuth 2.0 Client Authentication
	uses a JSON Web Token (JWT) Bearer Token to request an OAuth 2.0		and Authorization Grants [I-D.ietf-oauth-assertions] specification to
	access token as well as for use as client credentials. The format		define an extension grant type that uses a JSON Web Token (JWT)
	and processing rules for the JWT defined in this specification are		Bearer Token to request an OAuth 2.0 access token as well as for use
	intentionally similar, though not identical, to those in the closely		as client credentials. The format and processing rules for the JWT
	related SAML 2.0 Bearer Assertion Profiles for OAuth 2.0		defined in this specification are intentionally similar, though not
	[I-D.ietf-oauth-saml2-bearer].		identical, to those in the closely related SAML 2.0 Profile for OAuth
			2.0 Client Authentication and Authorization Grants
			[I-D.ietf-oauth-saml2-bearer] specification.
	This document defines how a JSON Web Token (JWT) Bearer Token can be		This document defines how a JSON Web Token (JWT) Bearer Token can be
	used to request an access token when a client wishes to utilize an		used to request an access token when a client wishes to utilize an
	existing trust relationship, expressed through the semantics of (and		existing trust relationship, expressed through the semantics of (and
	digital signature calculated over) the JWT, without a direct user		digital signature or keyed message digest calculated over) the JWT,
	approval step at the authorization server. It also defines how a JWT		without a direct user approval step at the authorization server. It
	can be used as a client authentication mechanism. The use of a		also defines how a JWT can be used as a client authentication
	security token for client authentication is orthogonal to and		mechanism. The use of a security token for client authentication is
	separable from using a security token as an authorization grant.		orthogonal to and separable from using a security token as an
	They can be used either in combination or separately. Client		authorization grant. They can be used either in combination or
	authentication using a JWT is nothing more than an alternative way		separately. Client authentication using a JWT is nothing more than
	for a client to authenticate to the token endpoint and must be used		an alternative way for a client to authenticate to the token endpoint
	in conjunction with some grant type to form a complete and meaningful		and must be used in conjunction with some grant type to form a
	protocol request. JWT authorization grants may be used with or		complete and meaningful protocol request. JWT authorization grants
	without client authentication or identification. Whether or not		may be used with or without client authentication or identification.
	client authentication is needed in conjunction with a JWT		Whether or not client authentication is needed in conjunction with a
	authorization grant, as well as the supported types of client		JWT authorization grant, as well as the supported types of client
	authentication, are policy decisions at the discretion of the		authentication, are policy decisions at the discretion of the
	authorization server.		authorization server.
	The process by which the client obtains the JWT, prior to exchanging		The process by which the client obtains the JWT, prior to exchanging
	it with the authorization server or using it for client		it with the authorization server or using it for client
	authentication, is out of scope.		authentication, is out of scope.
	1.1. Notational Conventions		1.1. Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Unless otherwise noted, all the protocol parameter names and values		Unless otherwise noted, all the protocol parameter names and values
	are case sensitive.		are case sensitive.
	1.2. Terminology		1.2. Terminology
	All terms are as defined in The OAuth 2.0 Authorization Framework		All terms are as defined in The OAuth 2.0 Authorization Framework
	[RFC6749], Assertion Framework for OAuth 2.0		[RFC6749], the Assertion Framework for OAuth 2.0 Client
	[I-D.ietf-oauth-assertions], and JSON Web Token (JWT) [JWT].		Authentication and Authorization Grants [I-D.ietf-oauth-assertions],
			and the JSON Web Token (JWT) [JWT] specifications.
	2. HTTP Parameter Bindings for Transporting Assertions		2. HTTP Parameter Bindings for Transporting Assertions
	The Assertion Framework for OAuth 2.0 [I-D.ietf-oauth-assertions]		The Assertion Framework for OAuth 2.0 Client Authentication and
			Authorization Grants [I-D.ietf-oauth-assertions] specification
	defines generic HTTP parameters for transporting Assertions (a.k.a.		defines generic HTTP parameters for transporting Assertions (a.k.a.
	Security Tokens) during interactions with a token endpoint. This		Security Tokens) during interactions with a token endpoint. This
	section defines the values of those parameters for use with JWT		section defines specific parameters and treatments of those
	Bearer Tokens.		parameters for use with JWT bearer tokens.
	2.1. Using JWTs as Authorization Grants		2.1. Using JWTs as Authorization Grants
	To use a JWT Bearer Token as an authorization grant, use the		To use a Bearer JWT as an authorization grant, use an access token
	following parameter values and encodings.		request as defined in Section 4 of the Assertion Framework for OAuth
			2.0 Client Authentication and Authorization Grants
			[I-D.ietf-oauth-assertions] specification with the following specific
			parameter values and encodings.
	The value of the "grant_type" parameter MUST be		The value of the "grant_type" parameter MUST be
	"urn:ietf:params:oauth:grant-type:jwt-bearer".		"urn:ietf:params:oauth:grant-type:jwt-bearer".
	The value of the "assertion" parameter MUST contain a single JWT.		The value of the "assertion" parameter MUST contain a single JWT.
			The "scope" parameter may be used, as defined in the Assertion
			Framework for OAuth 2.0 Client Authentication and Authorization
			Grants [I-D.ietf-oauth-assertions] specification, to indicate the
			requested scope.
			Authentication of the client is optional, as described in
			Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the
			"client_id" is only needed when a form of client authentication that
			relies on the parameter is used.
	The following non-normative example demonstrates an Access Token		The following non-normative example demonstrates an Access Token
	Request with a JWT as an authorization grant (with extra line breaks		Request with a JWT as an authorization grant (with extra line breaks
	for display purposes only):		for display purposes only):
	POST /token.oauth2 HTTP/1.1		POST /token.oauth2 HTTP/1.1
	Host: as.example.com		Host: as.example.com
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer		grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
	&assertion=eyJhbGciOiJFUzI1NiJ9.		&assertion=eyJhbGciOiJFUzI1NiJ9.
	skipping to change at page 5, line 45		skipping to change at page 6, line 7
	grant_type=authorization_code&		grant_type=authorization_code&
	code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo&		code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo&
	client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A		client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
	client-assertion-type%3Ajwt-bearer&		client-assertion-type%3Ajwt-bearer&
	client_assertion=eyJhbGciOiJSUzI1NiJ9.		client_assertion=eyJhbGciOiJSUzI1NiJ9.
	eyJpc3Mi[...omitted for brevity...].		eyJpc3Mi[...omitted for brevity...].
	cC4hiUPo[...omitted for brevity...]		cC4hiUPo[...omitted for brevity...]
	3. JWT Format and Processing Requirements		3. JWT Format and Processing Requirements
	In order to issue an access token response as described in The OAuth		In order to issue an access token response as described in OAuth 2.0
	2.0 Authorization Framework [RFC6749] or to rely on a JWT for client		[RFC6749] or to rely on a JWT for client authentication, the
	authentication, the authorization server MUST validate the JWT		authorization server MUST validate the JWT according to the criteria
	according to the criteria below. Application of additional		below. Application of additional restrictions and policy are at the
	restrictions and policy are at the discretion of the authorization		discretion of the authorization server.
	server.
	o The JWT MUST contain an "iss" (issuer) claim that contains a		1. The JWT MUST contain an "iss" (issuer) claim that contains a
	unique identifier for the entity that issued the JWT.		unique identifier for the entity that issued the JWT.
	o The JWT MUST contain a "sub" (subject) claim identifying the		2. The JWT MUST contain a "sub" (subject) claim identifying the
	subject of the transaction. The subject MAY identify the resource		subject of the transaction. The subject MAY identify the
	owner for whom the access token is being requested. For client		resource owner for whom the access token is being requested.
	authentication, the subject MUST be the "client_id" of the OAuth
	client. When using a JWT as an authorization grant, the subject
	SHOULD identify an authorized accessor for whom the access token
	is being requested (typically the resource owner, or an authorized
	delegate).
	o The JWT MUST contain an "aud" (audience) claim containing an		a. When using a JWT as an authorization grant, the subject
	audience value that identifies the authorization server, or the		SHOULD identify an authorized accessor for whom the access
	service provider principal entity of its controlling domain, as an		token is being requested (typically the resource owner, or
	intended audience. The token endpoint URL of the authorization		an authorized delegate).
	server MAY be used as an acceptable value for an "aud" element.
	The authorization server MUST verify that it is an intended
	audience for the JWT.
	o The JWT MUST contain an "exp" (expiration) claim that limits the		b. For client authentication, the subject MUST be the
	time window during which the JWT can be used. The authorization		"client_id" of the OAuth client.
	server MUST verify that the expiration time has not passed,
	subject to allowable clock skew between systems. The
	authorization server MAY reject JWTs with an "exp" claim value
	that is unreasonably far in the future.
	o The JWT MAY contain an "nbf" (not before) claim that identifies		3. The JWT MUST contain an "aud" (audience) claim containing a
	the time before which the token MUST NOT be accepted for		value that identifies the authorization server as an intended
	processing.		audience. The token endpoint URL of the authorization server
			MAY be used as a value for an "aud" element to identify the
			authorization server as an intended audience of the JWT. JWTs
			that do not identify the authorization server as an intended
			audience MUST be rejected.
	o The JWT MAY contain an "iat" (issued at) claim that identifies the		4. The JWT MUST contain an "exp" (expiration) claim that limits the
	time at which the JWT was issued. The authorization server MAY		time window during which the JWT can be used. The authorization
	reject JWTs with an "iat" claim value that is unreasonably far in		server MUST verify that the expiration time has not passed,
	the past.		subject to allowable clock skew between systems, and reject
			expired JWTs. The authorization server MAY reject JWTs with an
			"exp" claim value that is unreasonably far in the future.
	o The JWT MAY contain a "jti" (JWT ID) claim that provides a unique		5. The JWT MAY contain an "nbf" (not before) claim that identifies
	identifier for the token. The authorization server MAY ensure		the time before which the token MUST NOT be accepted for
	that JWTs are not replayed by maintaining the set of used "jti"		processing.
	values for the length of time for which the JWT would be
	considered valid based on the applicable "exp" instant.
	o The JWT MAY contain other claims.		6. The JWT MAY contain an "iat" (issued at) claim that identifies
			the time at which the JWT was issued. The authorization server
			MAY reject JWTs with an "iat" claim value that is unreasonably
			far in the past.
	o The JWT MUST be digitally signed by the issuer and the		7. The JWT MAY contain a "jti" (JWT ID) claim that provides a
	authorization server MUST verify the signature.		unique identifier for the token. The authorization server MAY
			ensure that JWTs are not replayed by maintaining the set of used
			"jti" values for the length of time for which the JWT would be
			considered valid based on the applicable "exp" instant.
	o The authorization server MUST verify that the JWT is valid in all		8. The JWT MAY contain other claims.
	other respects per JSON Web Token (JWT) [JWT].
			9. The JWT MUST be digitally signed or have a keyed message digest
			applied by the issuer. The authorization server MUST reject
			JWTs with an invalid signature or keyed message digest.
			10. The authorization server MUST verify that the JWT is valid in
			all other respects per JSON Web Token (JWT) [JWT].
	3.1. Authorization Grant Processing		3.1. Authorization Grant Processing
	If present, the authorization server MUST also validate the client		JWT authorization grants may be used with or without client
	credentials.		authentication or identification. Whether or not client
			authentication is needed in conjunction with a JWT authorization
			grant, as well as the supported types of client authentication, are
			policy decisions at the discretion of the authorization server.
			However, if client credentials are present in the request, the
			authorization server MUST validate them.
	If the JWT is not valid, or the current time is not within the		If the JWT is not valid, or the current time is not within the
	token's valid time window for use, the authorization server MUST		token's valid time window for use, the authorization server MUST
	construct an error response as defined in OAuth 2.0 [RFC6749]. The		construct an error response as defined in OAuth 2.0 [RFC6749]. The
	value of the "error" parameter MUST be the "invalid_grant" error		value of the "error" parameter MUST be the "invalid_grant" error
	code. The authorization server MAY include additional information		code. The authorization server MAY include additional information
	regarding the reasons the JWT was considered invalid using the		regarding the reasons the JWT was considered invalid using the
	"error_description" or "error_uri" parameters.		"error_description" or "error_uri" parameters.
	For example:		For example:
	skipping to change at page 8, line 5		skipping to change at page 8, line 17
	the "error" parameter MUST be the "invalid_client" error code. The		the "error" parameter MUST be the "invalid_client" error code. The
	authorization server MAY include additional information regarding the		authorization server MAY include additional information regarding the
	reasons the JWT was considered invalid using the "error_description"		reasons the JWT was considered invalid using the "error_description"
	or "error_uri" parameters.		or "error_uri" parameters.
	4. Authorization Grant Example		4. Authorization Grant Example
	Though non-normative, the following examples illustrate what a		Though non-normative, the following examples illustrate what a
	conforming JWT and access token request would look like.		conforming JWT and access token request would look like.
			The example shows a JWT issued and signed by the system entity
			identified as "https://jwt-idp.example.com". The subject of the JWT
			is identified by email address as "mike@example.com". The intended
			audience of the JWT is "https://jwt-rp.example.net", which is an
			identifier with which the authorization server identifies itself.
			The JWT is sent as part of an access token request to the
			authorization server's token endpoint at "https://authz.example.net/
			token.oauth2".
	Below is an example JSON object that could be encoded to produce the		Below is an example JSON object that could be encoded to produce the
	JWT Claims Object for a JWT:		JWT Claims Object for a JWT:
	{"iss":"https://jwt-idp.example.com",		{"iss":"https://jwt-idp.example.com",
	"sub":"mailto:mike@example.com",		"sub":"mailto:mike@example.com",
	"aud":"https://jwt-rp.example.net",		"aud":"https://jwt-rp.example.net",
	"nbf":1300815780,		"nbf":1300815780,
	"exp":1300819380,		"exp":1300819380,
	"http://claims.example.com/member":true}		"http://claims.example.com/member":true}
	The following example JSON object, used as the header of a JWT,		The following example JSON object, used as the header of a JWT,
	declares that the JWT is signed with the ECDSA P-256 SHA-256		declares that the JWT is signed with the ECDSA P-256 SHA-256
	algorithm.		algorithm.
	{"alg":"ES256"}		{"alg":"ES256"}
	To present the JWT with the claims and header shown in the previous		To present the JWT with the claims and header shown in the previous
	example as part of an access token request, for example, the client		example as part of an access token request, for example, the client
	might make the following HTTPS request (with extra line breaks for		might make the following HTTPS request (with extra line breaks for
	display purposes only):		display purposes only):
	POST /token.oauth2 HTTP/1.1		POST /token.oauth2 HTTP/1.1
	Host: authz.example.net		Host: authz.example.net
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer		grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
	&assertion=eyJhbGciOiJFUzI1NiJ9.		&assertion=eyJhbGciOiJFUzI1NiJ9.
	eyJpc3Mi[...omitted for brevity...].		eyJpc3Mi[...omitted for brevity...].
	J9l-ZhwP[...omitted for brevity...]		J9l-ZhwP[...omitted for brevity...]
	5. Security Considerations		5. Interoperability Considerations
			Agreement between system entities regarding identifiers, keys, and
			endpoints is required in order to achieve interoperable deployments
			of this profile. Specific items that require agreement are as
			follows: values for the issuer and audience identifiers, the location
			of the token endpoint, and the key used to apply and verify the
			digital signature or keyed message digest over the JWT. The exchange
			of such information is explicitly out of scope for this
			specification. In some cases, additional profiles may be created
			that constrain or prescribe these values or specify how they are to
			be exchanged. Examples of such profiles include the OAuth 2.0
			Dynamic Client Registration Protocol [I-D.ietf-oauth-dyn-reg], OpenID
			Connect Dynamic Client Registration 1.0 [OpenID.Registration], and
			OpenID Connect Discovery 1.0 [OpenID.Discovery].
			6. Security Considerations
	No additional security considerations apply beyond those described		No additional security considerations apply beyond those described
	within The OAuth 2.0 Authorization Framework [RFC6749], the Assertion		within The OAuth 2.0 Authorization Framework [RFC6749], the Assertion
	Framework for OAuth 2.0 [I-D.ietf-oauth-assertions], and the JSON Web		Framework for OAuth 2.0 Client Authentication and Authorization
	Token (JWT) [JWT] specification.		Grants [I-D.ietf-oauth-assertions], and the JSON Web Token (JWT)
			[JWT] specifications.
	6. IANA Considerations		7. IANA Considerations
	6.1. Sub-Namespace Registration of		7.1. Sub-Namespace Registration of urn:ietf:params:oauth:grant-type
	urn:ietf:params:oauth:grant-type:jwt-bearer		:jwt-bearer
	This specification registers the value "grant-type:jwt-bearer" in the		This specification registers the value "grant-type:jwt-bearer" in the
	IANA urn:ietf:params:oauth registry established in An IETF URN Sub-		IANA urn:ietf:params:oauth registry established in An IETF URN Sub-
	Namespace for OAuth [RFC6755].		Namespace for OAuth [RFC6755].
	o URN: urn:ietf:params:oauth:grant-type:jwt-bearer		o URN: urn:ietf:params:oauth:grant-type:jwt-bearer
	o Common Name: JWT Bearer Token Grant Type Profile for OAuth 2.0		o Common Name: JWT Bearer Token Grant Type Profile for OAuth 2.0
	o Change controller: IETF		o Change controller: IETF
	skipping to change at page 9, line 10		skipping to change at page 10, line 4
	This specification registers the value "grant-type:jwt-bearer" in the		This specification registers the value "grant-type:jwt-bearer" in the
	IANA urn:ietf:params:oauth registry established in An IETF URN Sub-		IANA urn:ietf:params:oauth registry established in An IETF URN Sub-
	Namespace for OAuth [RFC6755].		Namespace for OAuth [RFC6755].
	o URN: urn:ietf:params:oauth:grant-type:jwt-bearer		o URN: urn:ietf:params:oauth:grant-type:jwt-bearer
	o Common Name: JWT Bearer Token Grant Type Profile for OAuth 2.0		o Common Name: JWT Bearer Token Grant Type Profile for OAuth 2.0
	o Change controller: IETF		o Change controller: IETF
	o Specification Document: [[this document]]		o Specification Document: [[this document]]
	6.2. Sub-Namespace Registration of		7.2. Sub-Namespace Registration of urn:ietf:params:oauth:client-
	urn:ietf:params:oauth:client-assertion-type:jwt-bearer		assertion-type:jwt-bearer
	This specification registers the value		This specification registers the value "client-assertion-type:jwt-
	"client-assertion-type:jwt-bearer" in the IANA urn:ietf:params:oauth		bearer" in the IANA urn:ietf:params:oauth registry established in An
	registry established in An IETF URN Sub-Namespace for OAuth		IETF URN Sub-Namespace for OAuth [RFC6755].
	[RFC6755].
	o URN: urn:ietf:params:oauth:client-assertion-type:jwt-bearer		o URN: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
	o Common Name: JWT Bearer Token Profile for OAuth 2.0 Client		o Common Name: JWT Bearer Token Profile for OAuth 2.0 Client
	Authentication		Authentication
	o Change controller: IETF		o Change controller: IETF
	o Specification Document: [[this document]]		o Specification Document: [[this document]]
	7. References		8. References
	7.1. Normative References		8.1. Normative References
	[I-D.ietf-oauth-assertions]		[I-D.ietf-oauth-assertions]
	Campbell, B., Mortimore, C., Jones, M., and Y. Goland,		Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
	"Assertion Framework for OAuth 2.0",		"Assertion Framework for OAuth 2.0", draft-ietf-oauth-
	draft-ietf-oauth-assertions-08 (work in progress),		assertions-10 (work in progress), January 2013.
	November 2012.
	[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[JWT] Jones, M.B., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", draft-ietf-oauth-json-web-token (work in		(JWT)", draft-ietf-oauth-json-web-token (work in
	progress), December 2012.		progress), December 2012.
	[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.
	[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.
	[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",		[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
	RFC 6749, October 2012.		6749, October 2012.
	[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.
	7.2. Informative References		8.2. Informative References
			[I-D.ietf-oauth-dyn-reg]
			Richer, J., Bradley, J., Jones, M., and M. Machulak,
			"OAuth 2.0 Dynamic Client Registration Protocol", draft-
			ietf-oauth-dyn-reg-08 (work in progress), March 2013.
	[I-D.ietf-oauth-saml2-bearer]		[I-D.ietf-oauth-saml2-bearer]
	Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion		Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion
	Profiles for OAuth 2.0", draft-ietf-oauth-saml2-bearer-15		Profiles for OAuth 2.0", draft-ietf-oauth-saml2-bearer-15
	(work in progress), November 2012.		(work in progress), November 2012.
			[OpenID.Discovery]
			Sakimura, N., Bradley, J., Jones, M.B., and E. Jay,
			"OpenID Connect Discovery 1.0", March 2013.
			[OpenID.Registration]
			Sakimura, N., Bradley, J., and M.B. Jones, "OpenID Connect
			Dynamic Client Registration 1.0", March 2013.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	This profile was derived from SAML 2.0 Bearer Assertion Profiles for		This profile was derived from SAML 2.0 Profile for OAuth 2.0 Client
	OAuth 2.0 [I-D.ietf-oauth-saml2-bearer] by Brian Campbell and Chuck		Authentication and Authorization Grants [I-D.ietf-oauth-saml2-bearer]
	Mortimore.		by Brian Campbell and Chuck Mortimore.
	Appendix B. Document History		Appendix B. 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 ]]
			-05
			o Changed title from "JSON Web Token (JWT) Bearer Token Profiles for
			OAuth 2.0" to "JSON Web Token (JWT) Profile for OAuth 2.0 Client
			Authentication and Authorization Grants" to be more explicit about
			the scope of the document per http://www.ietf.org/mail-archive/web
			/oauth/current/msg11063.html.
			o Numbered the list of processing rules.
			o Smallish editorial cleanups to try and improve readability and
			comprehensibility.
			o Cleaner split out of the processing rules in cases where they
			differ for client authentication and authorization grants.
			o Clarified the parameters that are used/available for authorization
			grants.
			o Added Interoperability Considerations section.
			o Added more explanatory context to the example in Section 4.
	-04		-04
	o Changed the name of the "prn" claim to "sub" (subject) both to		o Changed the name of the "prn" claim to "sub" (subject) both to
	more closely align with SAML name usage and to use a more		more closely align with SAML name usage and to use a more
	intuitive name.		intuitive name.
	o Added seriesInfo information to Internet Draft references.		o Added seriesInfo information to Internet Draft references.
	-03		-03
	skipping to change at page 11, line 14		skipping to change at page 12, line 45
	o Tracked specification name changes: "The OAuth 2.0 Authorization		o Tracked specification name changes: "The OAuth 2.0 Authorization
	Protocol" to "The OAuth 2.0 Authorization Framework" and "OAuth		Protocol" to "The OAuth 2.0 Authorization Framework" and "OAuth
	2.0 Assertion Profile" to "Assertion Framework for OAuth 2.0".		2.0 Assertion Profile" to "Assertion Framework for OAuth 2.0".
	o Merged in changes between draft-ietf-oauth-saml2-bearer-11 and		o Merged in changes between draft-ietf-oauth-saml2-bearer-11 and
	draft-ietf-oauth-saml2-bearer-13. All changes were strictly		draft-ietf-oauth-saml2-bearer-13. All changes were strictly
	editorial.		editorial.
	-00		-00
	o Created the initial IETF draft based upon		o Created the initial IETF draft based upon draft-jones-oauth-jwt-
	draft-jones-oauth-jwt-bearer-04 with no normative changes.		bearer-04 with no normative changes.
	Authors' Addresses		Authors' Addresses
	Michael B. Jones		Michael B. Jones
	Microsoft		Microsoft
	Email: mbj@microsoft.com		Email: mbj@microsoft.com
	URI: http://self-issued.info/		URI: http://self-issued.info/
	Brian Campbell		Brian Campbell
End of changes. 47 change blocks.
	144 lines changed or deleted		230 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/