draft-ietf-oauth-jwt-bearer-10.txt		draft-ietf-oauth-jwt-bearer-11.txt
	OAuth Working Group M. Jones		OAuth Working Group M. Jones
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track B. Campbell		Intended status: Standards Track B. Campbell
	Expires: January 24, 2015 Ping Identity		Expires: April 24, 2015 Ping Identity
	C. Mortimore		C. Mortimore
	Salesforce		Salesforce
	July 23, 2014		October 21, 2014
	JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and		JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and
	Authorization Grants		Authorization Grants
	draft-ietf-oauth-jwt-bearer-10		draft-ietf-oauth-jwt-bearer-11
	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
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	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 24, 2015.		This Internet-Draft will expire on April 24, 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 23		skipping to change at page 3, line 23
	the use of Assertions (a.k.a. Security Tokens) as client credentials		the use of Assertions (a.k.a. Security Tokens) as client credentials
	and/or authorization grants with OAuth 2.0. This specification		and/or authorization grants with OAuth 2.0. This specification
	profiles the Assertion Framework for OAuth 2.0 Client Authentication		profiles the Assertion Framework for OAuth 2.0 Client Authentication
	and Authorization Grants [I-D.ietf-oauth-assertions] specification to		and Authorization Grants [I-D.ietf-oauth-assertions] specification to
	define an extension grant type that uses a JSON Web Token (JWT)		define an extension grant type that uses a JSON Web Token (JWT)
	Bearer Token to request an OAuth 2.0 access token as well as for use		Bearer Token to request an OAuth 2.0 access token as well as for use
	as client credentials. The format and processing rules for the JWT		as client credentials. The format and processing rules for the JWT
	defined in this specification are intentionally similar, though not		defined in this specification are intentionally similar, though not
	identical, to those in the closely related SAML 2.0 Profile for OAuth		identical, to those in the closely related SAML 2.0 Profile for OAuth
	2.0 Client Authentication and Authorization Grants		2.0 Client Authentication and Authorization Grants
	[I-D.ietf-oauth-saml2-bearer] specification.		[I-D.ietf-oauth-saml2-bearer] specification. The differences arise
			where the structure and semantics of JWTs differ from SAML
			assertions. JWTs, for example, have no direct equivalent to the
			<SubjectConfirmation> or <AuthnStatement> elements of SAML
			assertions.
	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 or keyed message digest calculated over) the JWT,		digital signature or Message Authentication Code calculated over) the
	without a direct user approval step at the authorization server. It		JWT, without a direct user approval step at the authorization server.
	also defines how a JWT can be used as a client authentication		It also defines how a JWT can be used as a client authentication
	mechanism. The use of a security token for client authentication is		mechanism. The use of a security token for client authentication is
	orthogonal to and separable from using a security token as an		orthogonal to and separable from using a security token as an
	authorization grant. They can be used either in combination or		authorization grant. They can be used either in combination or
	separately. Client authentication using a JWT is nothing more than		separately. Client authentication using a JWT is nothing more than
	an alternative way for a client to authenticate to the token endpoint		an alternative way for a client to authenticate to the token endpoint
	and must be used in conjunction with some grant type to form a		and must be used in conjunction with some grant type to form a
	complete and meaningful protocol request. JWT authorization grants		complete and meaningful protocol request. JWT authorization grants
	may be used with or without client authentication or identification.		may be used with or without client authentication or identification.
	Whether or not client authentication is needed in conjunction with a		Whether or not client authentication is needed in conjunction with a
	JWT authorization grant, as well as the supported types of client		JWT authorization grant, as well as the supported types of client
	skipping to change at page 4, line 32		skipping to change at page 4, line 32
	The Assertion Framework for OAuth 2.0 Client Authentication and		The Assertion Framework for OAuth 2.0 Client Authentication and
	Authorization Grants [I-D.ietf-oauth-assertions] specification		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 specific parameters and treatments of those		section defines specific parameters and treatments of those
	parameters for use with JWT 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 Bearer JWT as an authorization grant, use an access token		To use a Bearer JWT as an authorization grant, the client uses an
	request as defined in Section 4 of the Assertion Framework for OAuth		access token request as defined in Section 4 of the Assertion
	2.0 Client Authentication and Authorization Grants		Framework for OAuth 2.0 Client Authentication and Authorization
	[I-D.ietf-oauth-assertions] specification with the following specific		Grants [I-D.ietf-oauth-assertions] specification with the following
	parameter values and encodings.		specific parameter values and encodings.
	The value of the "grant_type" parameter MUST be		The value of the "grant_type" is "urn:ietf:params:oauth:grant-
	"urn:ietf:params:oauth:grant-type:jwt-bearer".		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		The "scope" parameter may be used, as defined in the Assertion
	Framework for OAuth 2.0 Client Authentication and Authorization		Framework for OAuth 2.0 Client Authentication and Authorization
	Grants [I-D.ietf-oauth-assertions] specification, to indicate the		Grants [I-D.ietf-oauth-assertions] specification, to indicate the
	requested scope.		requested scope.
	Authentication of the client is optional, as described in		Authentication of the client is optional, as described in
	Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the		Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the
	"client_id" is only needed when a form of client authentication that		"client_id" is only needed when a form of client authentication that
	relies on the parameter is used.		relies on the parameter is used.
	The following non-normative example demonstrates an Access Token		The following example demonstrates an Access Token Request with a JWT
	Request with a JWT as an authorization grant (with extra line breaks		as an authorization grant (with extra line breaks for display
	for display purposes only):		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.
	eyJpc3Mi[...omitted for brevity...].		eyJpc3Mi[...omitted for brevity...].
	J9l-ZhwP[...omitted for brevity...]		J9l-ZhwP[...omitted for brevity...]
	2.2. Using JWTs for Client Authentication		2.2. Using JWTs for Client Authentication
	To use a JWT Bearer Token for client authentication, use the		To use a JWT Bearer Token for client authentication, the client uses
	following parameter values and encodings.		the following parameter values and encodings.
	The value of the "client_assertion_type" parameter MUST be		The value of the "client_assertion_type" is
	"urn:ietf:params:oauth:client-assertion-type:jwt-bearer".		"urn:ietf:params:oauth:client-assertion-type:jwt-bearer".
	The value of the "client_assertion" parameter MUST contain a single		The value of the "client_assertion" parameter contains a single JWT.
	JWT.		It MUST NOT contain more than one JWT.
	The following non-normative example demonstrates client		The following example demonstrates client authentication using a JWT
	authentication using a JWT during the presentation of an		during the presentation of an authorization code grant in an Access
	authorization code grant in an Access Token Request (with extra line		Token Request (with extra line breaks for display purposes only):
	breaks 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=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.
	skipping to change at page 6, line 30		skipping to change at page 6, line 30
	pseudonymous identifier or other value denoting an anonymous		pseudonymous identifier or other value denoting an anonymous
	user.		user.
	B. For client authentication, the subject MUST be the		B. For client authentication, the subject MUST be the
	"client_id" of the OAuth client.		"client_id" of the OAuth client.
	3. The JWT MUST contain an "aud" (audience) claim containing a		3. The JWT MUST contain an "aud" (audience) claim containing a
	value that identifies the authorization server as an intended		value that identifies the authorization server as an intended
	audience. The token endpoint URL of the authorization server		audience. The token endpoint URL of the authorization server
	MAY be used as a value for an "aud" element to identify the		MAY be used as a value for an "aud" element to identify the
	authorization server as an intended audience of the JWT. JWTs		authorization server as an intended audience of the JWT. The
	that do not identify the authorization server as an intended		Authorization Server MUST reject any JWT that does not contain
	audience MUST be rejected. In the absence of an application		its own identity as the intended audience In the absence of an
	profile specifying otherwise, compliant applications MUST		application profile specifying otherwise, compliant applications
	compare the audience values using the Simple String Comparison		MUST compare the audience values using the Simple String
	method defined in Section 6.2.1 of RFC 3986 [RFC3986].		Comparison method defined in Section 6.2.1 of RFC 3986
			[RFC3986]. As noted in Section 5, the precise strings to be
			used as the audience for a given Authorization Server must be
			configured out-of-band by the Authorization Server and the
			Issuer of the JWT.
	4. The JWT MUST contain an "exp" (expiration) claim that limits the		4. The JWT MUST contain an "exp" (expiration) claim that limits the
	time window during which the JWT can be used. The authorization		time window during which the JWT can be used. The authorization
	server MUST verify that the expiration time has not passed,		server MUST reject any JWT with an expiration time that has
	subject to allowable clock skew between systems, and reject		passed, subject to allowable clock skew between systems. Note
	expired JWTs. The authorization server MAY reject JWTs with an		that the authorization server may reject JWTs with an "exp"
	"exp" claim value that is unreasonably far in the future.		claim value that is unreasonably far in the future.
	5. The JWT MAY contain an "nbf" (not before) claim that identifies		5. The JWT MAY contain an "nbf" (not before) claim that identifies
	the time before which the token MUST NOT be accepted for		the time before which the token MUST NOT be accepted for
	processing.		processing.
	6. The JWT MAY contain an "iat" (issued at) claim that identifies		6. The JWT MAY contain an "iat" (issued at) claim that identifies
	the time at which the JWT was issued. The authorization server		the time at which the JWT was issued. Note that the
	MAY reject JWTs with an "iat" claim value that is unreasonably		authorization server may reject JWTs with an "iat" claim value
	far in the past.		that is unreasonably far in the past.
	7. The JWT MAY contain a "jti" (JWT ID) claim that provides a		7. The JWT MAY contain a "jti" (JWT ID) claim that provides a
	unique identifier for the token. The authorization server MAY		unique identifier for the token. The authorization server MAY
	ensure that JWTs are not replayed by maintaining the set of used		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		"jti" values for the length of time for which the JWT would be
	considered valid based on the applicable "exp" instant.		considered valid based on the applicable "exp" instant.
	8. The JWT MAY contain other claims.		8. The JWT MAY contain other claims.
	9. The JWT MUST be digitally signed or have a keyed message digest		9. The JWT MUST be digitally signed or have a Message
	applied by the issuer. The authorization server MUST reject		Authentication Code applied by the issuer. The authorization
	JWTs with an invalid signature or keyed message digest.		server MUST reject JWTs with an invalid signature or Message
			Authentication Code.
	10. The authorization server MUST verify that the JWT is valid in		10. The authorization server MUST reject a JWT that is not valid in
	all other respects per JSON Web Token (JWT) [JWT].		all other respects per JSON Web Token (JWT) [JWT].
	3.1. Authorization Grant Processing		3.1. Authorization Grant Processing
	JWT authorization grants may be used with or without client		JWT authorization grants may be used with or without client
	authentication or identification. Whether or not client		authentication or identification. Whether or not client
	authentication is needed in conjunction with a JWT authorization		authentication is needed in conjunction with a JWT authorization
	grant, as well as the supported types of client authentication, are		grant, as well as the supported types of client authentication, are
	policy decisions at the discretion of the authorization server.		policy decisions at the discretion of the authorization server.
	However, if client credentials are present in the request, the		However, if client credentials are present in the request, the
	authorization server MUST validate them.		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
	construct an error response as defined in OAuth 2.0 [RFC6749]. The		constructs 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:
	HTTP/1.1 400 Bad Request		HTTP/1.1 400 Bad Request
	Content-Type: application/json		Content-Type: application/json
	Cache-Control: no-store		Cache-Control: no-store
	{		{
	"error":"invalid_grant",		"error":"invalid_grant",
	"error_description":"Audience validation failed"		"error_description":"Audience validation failed"
	}		}
	3.2. Client Authentication Processing		3.2. Client Authentication Processing
	If the client JWT is not valid, the authorization server MUST		If the client JWT is not valid, the authorization server constructs
	construct an error response as defined in OAuth 2.0 [RFC6749]. The		an error response as defined in OAuth 2.0 [RFC6749]. The value of
	value of the "error" parameter MUST be the "invalid_client" error		the "error" parameter MUST be the "invalid_client" error code. The
	code. The authorization server MAY include additional information		authorization server MAY include additional information regarding the
	regarding the reasons the JWT was considered invalid using the		reasons the JWT was considered invalid using the "error_description"
	"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		The following examples illustrate what a conforming JWT and an access
	conforming JWT and access token request would look like.		token request would look like.
	The example shows a JWT issued and signed by the system entity		The example shows a JWT issued and signed by the system entity
	identified as "https://jwt-idp.example.com". The subject of the JWT		identified as "https://jwt-idp.example.com". The subject of the JWT
	is identified by email address as "mike@example.com". The intended		is identified by email address as "mike@example.com". The intended
	audience of the JWT is "https://jwt-rp.example.net", which is an		audience of the JWT is "https://jwt-rp.example.net", which is an
	identifier with which the authorization server identifies itself.		identifier with which the authorization server identifies itself.
	The JWT is sent as part of an access token request to the		The JWT is sent as part of an access token request to the
	authorization server's token endpoint at "https://authz.example.net/		authorization server's token endpoint at "https://authz.example.net/
	token.oauth2".		token.oauth2".
	skipping to change at page 9, line 26		skipping to change at page 9, line 32
	eyJpc3Mi[...omitted for brevity...].		eyJpc3Mi[...omitted for brevity...].
	J9l-ZhwP[...omitted for brevity...]		J9l-ZhwP[...omitted for brevity...]
	5. Interoperability Considerations		5. Interoperability Considerations
	Agreement between system entities regarding identifiers, keys, and		Agreement between system entities regarding identifiers, keys, and
	endpoints is required in order to achieve interoperable deployments		endpoints is required in order to achieve interoperable deployments
	of this profile. Specific items that require agreement are as		of this profile. Specific items that require agreement are as
	follows: values for the issuer and audience identifiers, the location		follows: values for the issuer and audience identifiers, the location
	of the token endpoint, the key used to apply and verify the digital		of the token endpoint, the key used to apply and verify the digital
	signature or keyed message digest over the JWT, one-time use		signature or Message Authentication Code over the JWT, one-time use
	restrictions on JWT, maximum JWT lifetime allowed, and the specific		restrictions on the JWT, maximum JWT lifetime allowed, and the
	subject and claim requirements of the JWT. The exchange of such		specific subject and claim requirements of the JWT. The exchange of
	information is explicitly out of scope for this specification. In		such information is explicitly out of scope for this specification.
	some cases, additional profiles may be created that constrain or		In some cases, additional profiles may be created that constrain or
	prescribe these values or specify how they are to be exchanged.		prescribe these values or specify how they are to be exchanged.
	Examples of such profiles include the OAuth 2.0 Dynamic Client		Examples of such profiles include the OAuth 2.0 Dynamic Client
	Registration Core Protocol [I-D.ietf-oauth-dyn-reg], OpenID Connect		Registration Core Protocol [I-D.ietf-oauth-dyn-reg], OpenID Connect
	Dynamic Client Registration 1.0 [OpenID.Registration], and OpenID		Dynamic Client Registration 1.0 [OpenID.Registration], and OpenID
	Connect Discovery 1.0 [OpenID.Discovery].		Connect Discovery 1.0 [OpenID.Discovery].
			The "RS256" algorithm, from [I-D.ietf-jose-json-web-algorithms], is a
			mandatory to implement JSON Web Signature algorithm for this profile.
	6. Security Considerations		6. Security Considerations
	The security considerations described within the Assertion Framework		The security considerations described within the Assertion Framework
	for OAuth 2.0 Client Authentication and Authorization Grants		for OAuth 2.0 Client Authentication and Authorization Grants
	[I-D.ietf-oauth-assertions], The OAuth 2.0 Authorization Framework		[I-D.ietf-oauth-assertions], The OAuth 2.0 Authorization Framework
	[RFC6749], and the JSON Web Token (JWT) [JWT] specifications are all		[RFC6749], and the JSON Web Token (JWT) [JWT] specifications are all
	applicable to this document.		applicable to this document.
	The specification does not mandate replay protection for the JWT		The specification does not mandate replay protection for the JWT
	usage for either the authorization grant or for client		usage for either the authorization grant or for client
	skipping to change at page 10, line 33		skipping to change at page 10, line 38
	type:jwt-bearer		type: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: IESG
	o Specification Document: [[this document]]		o Specification Document: [[this document]]
	8.2. Sub-Namespace Registration of urn:ietf:params:oauth:client-		8.2. Sub-Namespace Registration of urn:ietf:params:oauth:client-
	assertion-type:jwt-bearer		assertion-type:jwt-bearer
	This specification registers the value "client-assertion-type:jwt-		This specification registers the value "client-assertion-type:jwt-
	bearer" in the IANA urn:ietf:params:oauth registry established in An		bearer" in the IANA urn:ietf:params:oauth registry established in An
	IETF URN Sub-Namespace for OAuth [RFC6755].		IETF URN Sub-Namespace for OAuth [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: IESG
	o Specification Document: [[this document]]		o Specification Document: [[this document]]
	9. References		9. References
	9.1. Normative References		9.1. Normative References
			[I-D.ietf-jose-json-web-algorithms]
			Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose-
			json-web-algorithms-35 (work in progress), October 2014.
	[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 Client Authentication		"Assertion Framework for OAuth 2.0 Client Authentication
	and Authorization Grants", draft-ietf-oauth-assertions		and Authorization Grants", draft-ietf-oauth-assertions
	(work in progress), July 2014.		(work in progress), October 2014.
	[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[JWT] Jones, M., 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), July 2014.		progress), October 2014.
	[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, RFC		Resource Identifier (URI): Generic Syntax", STD 66, RFC
	3986, January 2005.		3986, January 2005.
	[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC		[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
	6749, October 2012.		6749, October 2012.
	[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
	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.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-oauth-dyn-reg]		[I-D.ietf-oauth-dyn-reg]
	Richer, J., Jones, M., Bradley, J., Machulak, M., and P.		Richer, J., Jones, M., Bradley, J., Machulak, M., and P.
	Hunt, "OAuth 2.0 Dynamic Client Registration Core		Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
	Protocol", draft-ietf-oauth-dyn-reg-16 (work in progress),		draft-ietf-oauth-dyn-reg-20 (work in progress), August
	February 2014.		2014.
	[I-D.ietf-oauth-saml2-bearer]		[I-D.ietf-oauth-saml2-bearer]
	Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0		Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0
	Profile for OAuth 2.0 Client Authentication and		Profile for OAuth 2.0 Client Authentication and
	Authorization Grants", draft-ietf-oauth-saml2-bearer (work		Authorization Grants", draft-ietf-oauth-saml2-bearer (work
	in progress), July 2014.		in progress), October 2014.
	[OpenID.Discovery]		[OpenID.Discovery]
	Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID		Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
	Connect Discovery 1.0", February 2014.		Connect Discovery 1.0", February 2014.
	[OpenID.Registration]		[OpenID.Registration]
	Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect		Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
	Dynamic Client Registration 1.0", February 2014.		Dynamic Client Registration 1.0", February 2014.
			[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
			for OAuth", RFC 6755, October 2012.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	This profile was derived from SAML 2.0 Profile for OAuth 2.0 Client		This profile was derived from SAML 2.0 Profile for OAuth 2.0 Client
	Authentication and Authorization Grants [I-D.ietf-oauth-saml2-bearer]		Authentication and Authorization Grants [I-D.ietf-oauth-saml2-bearer]
	by Brian Campbell and Chuck 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 ]]
			draft-ietf-oauth-jwt-bearer-11
			o Changes/suggestions from IESG reviews.
	draft-ietf-oauth-jwt-bearer-10		draft-ietf-oauth-jwt-bearer-10
	o Added Privacy Considerations section per AD review discussion		o Added Privacy Considerations section per AD review discussion
	http://www.ietf.org/mail-archive/web/oauth/current/msg13148.html		http://www.ietf.org/mail-archive/web/oauth/current/msg13148.html
	and http://www.ietf.org/mail-archive/web/oauth/current/		and http://www.ietf.org/mail-archive/web/oauth/current/
	msg13144.html		msg13144.html
	draft-ietf-oauth-jwt-bearer-09		draft-ietf-oauth-jwt-bearer-09
	o Clarified some text around the treatment of subject based on the		o Clarified some text around the treatment of subject based on the
End of changes. 33 change blocks.
	70 lines changed or deleted		89 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/