< draft-ietf-oauth-assertions-12.txt		draft-ietf-oauth-assertions-13.txt >
	OAuth Working Group B. Campbell		OAuth Working Group B. Campbell
	Internet-Draft Ping Identity		Internet-Draft Ping Identity
	Intended status: Standards Track C. Mortimore		Intended status: Standards Track C. Mortimore
	Expires: January 15, 2014 Salesforce		Expires: June 12, 2014 Salesforce
	M. Jones		M. Jones
	Y. Goland		Y. Goland
	Microsoft		Microsoft
	July 14, 2013		December 9, 2013
	Assertion Framework for OAuth 2.0 Client Authentication and		Assertion Framework for OAuth 2.0 Client Authentication and
	Authorization Grants		Authorization Grants
	draft-ietf-oauth-assertions-12		draft-ietf-oauth-assertions-13
	Abstract		Abstract
	This specification provides a framework for the use of assertions		This specification provides a framework for the use of assertions
	with OAuth 2.0 in the form of a new client authentication mechanism		with OAuth 2.0 in the form of a new client authentication mechanism
	and a new authorization grant type. Mechanisms are specified for		and a new authorization grant type. Mechanisms are specified for
	transporting assertions during interactions with a token endpoint, as		transporting assertions during interactions with a token endpoint, as
	well as general processing rules.		well as general processing rules.
	The intent of this specification is to provide a common framework for		The intent of this specification is to provide a common framework for
	OAuth 2.0 to interwork with other identity systems using assertions,		OAuth 2.0 to interwork with other identity systems using assertions,
	and to provide alternative client authentication mechanisms.		and to provide alternative client authentication mechanisms.
	Note that this specification only defines abstract message flows and		Note that this specification only defines abstract message flows and
	processing rules. In order to be implementable, companion		processing rules. In order to be implementable, companion
	specifications are necessary to provide the corresponding concrete		specifications are necessary to provide the corresponding concrete
	instantiations.		instantiations.
	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 January 15, 2014.		This Internet-Draft will expire on June 12, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Transporting Assertions . . . . . . . . . . . . . . . . . . . 8		4. Transporting Assertions . . . . . . . . . . . . . . . . . . . 7
	4.1. Using Assertions as Authorization Grants . . . . . . . . . 8		4.1. Using Assertions as Authorization Grants . . . . . . . . 7
	4.1.1. Error Responses . . . . . . . . . . . . . . . . . . . 9		4.1.1. Error Responses . . . . . . . . . . . . . . . . . . . 8
	4.2. Using Assertions for Client Authentication . . . . . . . . 9		4.2. Using Assertions for Client Authentication . . . . . . . 8
	4.2.1. Error Responses . . . . . . . . . . . . . . . . . . . 10		4.2.1. Error Responses . . . . . . . . . . . . . . . . . . . 9
	5. Assertion Content and Processing . . . . . . . . . . . . . . . 11		5. Assertion Content and Processing . . . . . . . . . . . . . . 10
	5.1. Assertion Metamodel . . . . . . . . . . . . . . . . . . . 11		5.1. Assertion Metamodel . . . . . . . . . . . . . . . . . . . 10
	5.2. General Assertion Format and Processing Rules . . . . . . 12		5.2. General Assertion Format and Processing Rules . . . . . . 11
	6. Common Scenarios . . . . . . . . . . . . . . . . . . . . . . . 13		6. Common Scenarios . . . . . . . . . . . . . . . . . . . . . . 12
	6.1. Client Authentication . . . . . . . . . . . . . . . . . . 13		6.1. Client Authentication . . . . . . . . . . . . . . . . . . 12
	6.2. Client Acting on Behalf of Itself . . . . . . . . . . . . 13		6.2. Client Acting on Behalf of Itself . . . . . . . . . . . . 12
	6.3. Client Acting on Behalf of a User . . . . . . . . . . . . 14		6.3. Client Acting on Behalf of a User . . . . . . . . . . . . 13
	6.3.1. Client Acting on Behalf of an Anonymous User . . . . . 14		6.3.1. Client Acting on Behalf of an Anonymous User . . . . 13
	7. Interoperability Considerations . . . . . . . . . . . . . . . 14		7. Interoperability Considerations . . . . . . . . . . . . . . . 14
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 15		8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	8.1. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 15		8.1. Forged Assertion . . . . . . . . . . . . . . . . . . . . 15
	8.2. Stolen Assertion . . . . . . . . . . . . . . . . . . . . . 16		8.2. Stolen Assertion . . . . . . . . . . . . . . . . . . . . 15
	8.3. Unauthorized Disclosure of Personal Information . . . . . 16		8.3. Unauthorized Disclosure of Personal Information . . . . . 15
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	9.1. assertion Parameter Registration . . . . . . . . . . . . . 17		9.1. assertion Parameter Registration . . . . . . . . . . . . 16
	9.2. client_assertion Parameter Registration . . . . . . . . . 18		9.2. client_assertion Parameter Registration . . . . . . . . . 17
	9.3. client_assertion_type Parameter Registration . . . . . . . 18		9.3. client_assertion_type Parameter Registration . . . . . . 17
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 18		10.1. Normative References . . . . . . . . . . . . . . . . . . 17
	10.2. Informative References . . . . . . . . . . . . . . . . . . 18		10.2. Informative References . . . . . . . . . . . . . . . . . 17
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 19		Appendix B. Document History . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	An assertion is a package of information that facilitates the sharing		An assertion is a package of information that facilitates the sharing
	of identity and security information across security domains.		of identity and security information across security domains.
	Section 3 provides a more detailed description of the concept of an		Section 3 provides a more detailed description of the concept of an
	assertion for the purpose of this specification.		assertion for the purpose of this specification.
	OAuth 2.0 [RFC6749] is an authorization framework that enables a		OAuth 2.0 [RFC6749] is an authorization framework that enables a
	third-party application to obtain limited access to a protected HTTP		third-party application to obtain limited access to a protected HTTP
	skipping to change at page 6, line 14 ¶		skipping to change at page 5, line 12 ¶
	entity is known as a "Security Token Service" (STS) or just "Token		entity is known as a "Security Token Service" (STS) or just "Token
	Service" and a trust relationship (usually manifested in the exchange		Service" and a trust relationship (usually manifested in the exchange
	of some kind of key material) exists between the token service and		of some kind of key material) exists between the token service and
	the relying party. The token service is the assertion issuer; its		the relying party. The token service is the assertion issuer; its
	role is to fulfill requests from clients, which present various		role is to fulfill requests from clients, which present various
	credentials, and mint assertions as requested, fill them with		credentials, and mint assertions as requested, fill them with
	appropriate information, and integrity protect them with a signature		appropriate information, and integrity protect them with a signature
	or message authentication code. WS-Trust [OASIS.WS-Trust] is one		or message authentication code. WS-Trust [OASIS.WS-Trust] is one
	available standard for requesting security tokens (assertions).		available standard for requesting security tokens (assertions).
	Relying		Relying
	Party Client Token Service		Party Client Token Service
	| | |		| | |
	| | 1) Request Assertion |		| | 1) Request Assertion |
	| |------------------------>|		| |------------------------>|
	| | |		| | |
	| | 2) Assertion |		| | 2) Assertion |
	| |<------------------------|		| |<------------------------|
	| 3) Assertion | |		| 3) Assertion | |
	|<-------------------------| |		|<-------------------------| |
	| | |		| | |
	| 4) OK or Failure | |		| 4) OK or Failure | |
	|------------------------->| |		|------------------------->| |
	| | |		| | |
	| | |		| | |
	Figure 1: Third Party Created Assertion		Figure 1: Third Party Created Assertion
	In the second pattern, depicted in Figure 2, the client creates		In the second pattern, depicted in Figure 2, the client creates
	assertions locally. To apply the signatures or message		assertions locally. To apply the signatures or message
	authentication codes to assertions, it has to obtain key material:		authentication codes to assertions, it has to obtain key material:
	either symmetric keys or asymmetric key pairs. The mechanisms for		either symmetric keys or asymmetric key pairs. The mechanisms for
	obtaining this key material are beyond the scope of this		obtaining this key material are beyond the scope of this
	specification.		specification.
	Although assertions are usually used to convey identity and security		Although assertions are usually used to convey identity and security
	information, self-issued assertions can also serve a different		information, self-issued assertions can also serve a different
	purpose. They can be used to demonstrate knowledge of some secret,		purpose. They can be used to demonstrate knowledge of some secret,
	such as a client secret, without actually communicating the secret		such as a client secret, without actually communicating the secret
	directly in the transaction. In that case, additional information		directly in the transaction. In that case, additional information
	included in the assertion by the client itself will be of limited		included in the assertion by the client itself will be of limited
	value to the relying party and, for this reason, only a bare minimum		value to the relying party and, for this reason, only a bare minimum
	of information is typically included in such an assertion, such as		of information is typically included in such an assertion, such as
	information about issuing and usage conditions.		information about issuing and usage conditions.
	Relying		Relying
	Party Client		Party Client
	| |		| |
	| | 1) Create		| | 1) Create
	| | Assertion		| | Assertion
	| |--------------+		| |--------------+
	| | |		| | |
	| | 2) Assertion |		| | 2) Assertion |
	| |<-------------+		| |<-------------+
	| 3) Assertion |		| 3) Assertion |
	|<-------------------------|		|<-------------------------|
	| |		| |
	| 4) OK or Failure |		| 4) OK or Failure |
	|------------------------->|		|------------------------->|
	| |		| |
	| |		| |
	Figure 2: Self-Issued Assertion		Figure 2: Self-Issued Assertion
	Deployments need to determine the appropriate variant to use based on		Deployments need to determine the appropriate variant to use based on
	the required level of security, the trust relationship between the		the required level of security, the trust relationship between the
	entities, and other factors.		entities, and other factors.
	From the perspective of what must be done by the entity presenting		From the perspective of what must be done by the entity presenting
	the assertion, there are two general types of assertions:		the assertion, there are two general types of assertions:
	skipping to change at page 8, line 43 ¶		skipping to change at page 7, line 43 ¶
	tokens, the authorization for the token has been previously		tokens, the authorization for the token has been previously
	granted through some out-of-band mechanism. As such, the		granted through some out-of-band mechanism. As such, the
	requested scope MUST be equal or lesser than the scope originally		requested scope MUST be equal or lesser than the scope originally
	granted to the authorized accessor. If the scope parameter and/or		granted to the authorized accessor. If the scope parameter and/or
	value are omitted, the scope MUST be treated as equal to the scope		value are omitted, the scope MUST be treated as equal to the scope
	originally granted to the authorized accessor. The Authorization		originally granted to the authorized accessor. The Authorization
	Server MUST limit the scope of the issued access token to be equal		Server MUST limit the scope of the issued access token to be equal
	or lesser than the scope originally granted to the authorized		or lesser than the scope originally granted to the authorized
	accessor.		accessor.
	Authentication of the client is optional, as described in Section		Authentication of the client is optional, as described in
	3.2.1 of OAuth 2.0 [RFC6749] and consequently, the "client_id" is		Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the
	only needed when a form of client authentication that relies on the		"client_id" is only needed when a form of client authentication that
	parameter is used.		relies on the parameter is used.
	The following non-normative example demonstrates an assertion being		The following non-normative example demonstrates an assertion being
	used as an authorization grant (with extra line breaks for display		used as an authorization grant (with extra line breaks for display
	purposes only):		purposes only):
	POST /token HTTP/1.1		POST /token HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer&		grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer&
	skipping to change at page 9, line 23 ¶		skipping to change at page 8, line 23 ¶
	representation of the authorization grant and authorization servers		representation of the authorization grant and authorization servers
	SHOULD NOT issue access tokens with a lifetime that exceeds the		SHOULD NOT issue access tokens with a lifetime that exceeds the
	validity period of the assertion by a significant period. In		validity period of the assertion by a significant period. In
	practice, that will usually mean that refresh tokens are not issued		practice, that will usually mean that refresh tokens are not issued
	in response to assertion grant requests and access tokens will be		in response to assertion grant requests and access tokens will be
	issued with a reasonably short lifetime. Clients can refresh an		issued with a reasonably short lifetime. Clients can refresh an
	expired access token by requesting a new one using the same		expired access token by requesting a new one using the same
	assertion, if it is still valid, or with a new assertion.		assertion, if it is still valid, or with a new assertion.
	An IETF URN for use as the "grant_type" value can be requested using		An IETF URN for use as the "grant_type" value can be requested using
	the template in [RFC6755]. A URN of the form		the template in [RFC6755]. A URN of the form urn:ietf:params:oauth
	urn:ietf:params:oauth:grant-type:* is suggested.		:grant-type:* is suggested.
	4.1.1. Error Responses		4.1.1. Error Responses
	If an assertion is not valid or has expired, the Authorization Server		If an assertion is not valid or has expired, the Authorization Server
	MUST construct an error response as defined in OAuth 2.0 [RFC6749].		MUST construct an error response as defined in OAuth 2.0 [RFC6749].
	The value of the "error" parameter MUST be the "invalid_grant" error		The 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 assertion was considered invalid using the		regarding the reasons the assertion was considered invalid using the
	"error_description" or "error_uri" parameters.		"error_description" or "error_uri" parameters.
	skipping to change at page 10, line 15 ¶		skipping to change at page 9, line 15 ¶
	client_assertion_type REQUIRED. The format of the assertion as		client_assertion_type REQUIRED. The format of the assertion as
	defined by the authorization server. The value MUST be an		defined by the authorization server. The value MUST be an
	absolute URI.		absolute URI.
	client_assertion REQUIRED. The assertion being used to authenticate		client_assertion REQUIRED. The assertion being used to authenticate
	the client. Specific serialization of the assertion is defined by		the client. Specific serialization of the assertion is defined by
	profile documents. The serialization MUST be encoded for		profile documents. The serialization MUST be encoded for
	transport within HTTP forms. It is RECOMMENDED that base64url be		transport within HTTP forms. It is RECOMMENDED that base64url be
	used.		used.
	client_id OPTIONAL. The client identifier as described in Section		client_id OPTIONAL. The client identifier as described in
	2.2 of OAuth 2.0 [RFC6749]. The "client_id" is unnecessary for		Section 2.2 of OAuth 2.0 [RFC6749]. The "client_id" is
	client assertion authentication because the client is identified		unnecessary for client assertion authentication because the client
	by the subject of the assertion. If present, the value of the		is identified by the subject of the assertion. If present, the
	"client_id" parameter MUST identify the same client as is		value of the "client_id" parameter MUST identify the same client
	identified by the client assertion.		as is identified by the client assertion.
	The following non-normative example demonstrates a client		The following non-normative example demonstrates a client
	authenticating using an assertion during an Access Token Request, as		authenticating using an assertion during an Access Token Request, as
	defined in Section 4.1.3 of OAuth 2.0 [RFC6749] (with extra line		defined in Section 4.1.3 of OAuth 2.0 [RFC6749] (with extra line
	breaks for display purposes only):		breaks for display purposes only):
	POST /token HTTP/1.1		POST /token HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	skipping to change at page 11, line 39 ¶		skipping to change at page 10, line 39 ¶
	profiles of this specification.		profiles of this specification.
	Issuer A unique identifier for the entity that issued the assertion.		Issuer A unique identifier for the entity that issued the assertion.
	Generally this is the entity that holds the key material used to		Generally this is the entity that holds the key material used to
	sign or integrity protect the assertion. Examples of issuers are		sign or integrity protect the assertion. Examples of issuers are
	OAuth clients (when assertions are self-issued) and third party		OAuth clients (when assertions are self-issued) and third party
	security token services. If the assertion is self-issued, the		security token services. If the assertion is self-issued, the
	Issuer value is the client identifier. If the assertion was		Issuer value is the client identifier. If the assertion was
	issued by a Security Token Service (STS), the Issuer should		issued by a Security Token Service (STS), the Issuer should
	identify the STS in a manner recognized by the Authorization		identify the STS in a manner recognized by the Authorization
	Server. Issuer values SHOULD be compared using the Simple String		Server. In the absence of an application profile specifying
	Comparison method defined in Section 6.2.1 of RFC 3986 [RFC3986],		otherwise, compliant applications MUST compare Issuer values using
	unless otherwise specified by the application.		the Simple String Comparison method defined in Section 6.2.1 of
			RFC 3986 [RFC3986].
	Subject A unique identifier for the subject of the assertion.		Subject A unique identifier for the principal that is the subject of
			the assertion.
	* When using assertions for client authentication, the Subject		* When using assertions for client authentication, the Subject
	MUST identify the client to the authorization server, typically		identifies the client to the authorization server using the
	by using the value of the "client_id" of the OAuth client.		value of the "client_id" of the OAuth client.
	* When using assertions as an authorization grant, the Subject		* When using assertions as an authorization grant, the Subject
	MUST identify an authorized accessor for which the access token		identifies an authorized accessor for which the access token is
	is being requested (typically the resource owner, or an		being requested (typically the resource owner, or an authorized
	authorized delegate).		delegate).
	Audience A value that identifies the party or parties intended to		Audience A value that identifies the party or parties intended to
	process the assertion. The URL of the Token Endpoint, as defined		process the assertion. The URL of the Token Endpoint, as defined
	in Section 3.2 of OAuth 2.0 [RFC6749], can be used to indicate		in Section 3.2 of OAuth 2.0 [RFC6749], can be used to indicate
	that the authorization server as a valid intended audience of the		that the authorization server as a valid intended audience of the
	assertion. Audience values SHOULD be compared using the Simple		assertion. In the absence of an application profile specifying
	String Comparison method defined in Section 6.2.1 of RFC 3986		otherwise, compliant applications MUST compare the audience values
	[RFC3986], unless otherwise specified by the application.		using the Simple String Comparison method defined in Section 6.2.1
			of RFC 3986 [RFC3986].
	Issued At The time at which the assertion was issued. While the		Issued At The time at which the assertion was issued. While the
	serialization may differ by assertion format, it is REQUIRED that		serialization may differ by assertion format, it is REQUIRED that
	the time be expressed in UTC with no time zone component.		the time be expressed in UTC with no time zone component.
	Expires At The time at which the assertion expires. While the		Expires At The time at which the assertion expires. While the
	serialization may differ by assertion format, it is REQUIRED that		serialization may differ by assertion format, it is REQUIRED that
	the time be expressed in UTC with no time zone component.		the time be expressed in UTC with no time zone component.
	Assertion ID A nonce or unique identifier for the assertion. The		Assertion ID A nonce or unique identifier for the assertion. The
	skipping to change at page 12, line 40 ¶		skipping to change at page 11, line 44 ¶
	5.2. General Assertion Format and Processing Rules		5.2. General Assertion Format and Processing Rules
	The following are general format and processing rules for the use of		The following are general format and processing rules for the use of
	assertions in OAuth:		assertions in OAuth:
	o The assertion MUST contain an Issuer. The Issuer MUST identify		o The assertion MUST contain an Issuer. The Issuer MUST identify
	the entity that issued the assertion as recognized by the		the entity that issued the assertion as recognized by the
	Authorization Server. If an assertion is self-issued, the Issuer		Authorization Server. If an assertion is self-issued, the Issuer
	MUST be the value of the client's "client_id".		MUST be the value of the client's "client_id".
	o The assertion SHOULD contain a Subject. The Subject MUST identify		o The assertion MUST contain a Subject. The Subject identifies an
	an authorized accessor for which the access token is being		authorized accessor for which the access token is being requested
	requested (typically the resource owner, or an authorized		(typically the resource owner, or an authorized delegate). When
	delegate). When the client is acting on behalf of itself, the		the client is acting on behalf of itself, the Subject MUST be the
	Subject SHOULD be the value of the client's "client_id".		value of the client's "client_id".
	o The assertion MUST contain an Audience that identifies the		o The assertion MUST contain an Audience that identifies the
	Authorization Server as the intended audience. Assertions that do		Authorization Server as the intended audience. Assertions that do
	not identify the Authorization Server as an intended audience MUST		not identify the Authorization Server as an intended audience MUST
	be rejected.		be rejected.
	o The assertion MUST contain an Expires At entity that limits the		o The assertion MUST contain an Expires At entity that limits the
	time window during which the assertion can be used. The		time window during which the assertion can be used. The
	authorization server MUST reject assertions that have expired		authorization server MUST reject assertions that have expired
	(subject to allowable clock skew between systems). The		(subject to allowable clock skew between systems). The
	skipping to change at page 13, line 43 ¶		skipping to change at page 12, line 48 ¶
	of the assertion identifies the client. If the assertion is self-		of the assertion identifies the client. If the assertion is self-
	issued by the client, the Issuer of the assertion also identifies the		issued by the client, the Issuer of the assertion also identifies the
	client.		client.
	The example in Section 4.2 that shows a client authenticating using		The example in Section 4.2 that shows a client authenticating using
	an assertion during an Access Token Request.		an assertion during an Access Token Request.
	6.2. Client Acting on Behalf of Itself		6.2. Client Acting on Behalf of Itself
	When a client is accessing resources on behalf of itself, it does so		When a client is accessing resources on behalf of itself, it does so
	in a manner analogous to the Client Credentials flow defined in		in a manner analogous to the Client Credentials Grant defined in
	Section 4.4 of OAuth 2.0 [RFC6749]. This is a special case that		Section 4.4 of OAuth 2.0 [RFC6749]. This is a special case that
	combines both the authentication and authorization grant usage		combines both the authentication and authorization grant usage
	patterns. In this case, the interactions with the authorization		patterns. In this case, the interactions with the authorization
	server should be treated as using an assertion for Client		server should be treated as using an assertion for Client
	Authentication according to Section 4.2, while using the grant_type		Authentication according to Section 4.2, while using the grant_type
	parameter with the value "client_credentials" to indicate that the		parameter with the value "client_credentials" to indicate that the
	client is requesting an access token using only its client		client is requesting an access token using only its client
	credentials.		credentials.
	The following non-normative example demonstrates an assertion being		The following non-normative example demonstrates an assertion being
	skipping to change at page 15, line 15 ¶		skipping to change at page 14, line 25 ¶
	SAML 2.0-based assertions and the other [I-D.ietf-oauth-jwt-bearer]		SAML 2.0-based assertions and the other [I-D.ietf-oauth-jwt-bearer]
	uses JSON Web Tokens (JWTs). These two instantiations of this		uses JSON Web Tokens (JWTs). These two instantiations of this
	framework specify additional details about the assertion encoding and		framework specify additional details about the assertion encoding and
	processing rules for using those kinds of assertions with OAuth 2.0.		processing rules for using those kinds of assertions with OAuth 2.0.
	However, even when profiled for specific assertion types, agreements		However, even when profiled for specific assertion types, agreements
	between system entities regarding identifiers, keys, and endpoints		between system entities regarding identifiers, keys, and endpoints
	are required in order to achieve interoperable deployments. Specific		are required in order to achieve interoperable deployments. Specific
	items that require agreement are as follows: values for the issuer		items that require agreement are as follows: values for the issuer
	and audience identifiers, supported assertion and client		and audience identifiers, supported assertion and client
	authentication types, the location of the token endpoint, and the key		authentication types, the location of the token endpoint, the key
	used to apply and verify the digital signature or keyed message		used to apply and verify the digital signature or keyed message
	digest over the assertion. The exchange of such information is		digest over the assertion, one-time use restrictions on assertions,
	explicitly out of scope for this specification. Deployments for		maximum assertion lifetime allowed, and the specific subject and
	particular trust frameworks, circles of trust, or other uses cases		attribute requirements of the assertion. The exchange of such
	will need to agree among the participants on the kinds of values to		information is explicitly out of scope for this specification.
	be used for some abstract fields defined by this specification. In		Deployments for particular trust frameworks, circles of trust, or
	some cases, additional profiles may be created that constrain or		other uses cases will need to agree among the participants on the
	prescribe these values or specify how they are to be exchanged. The		kinds of values to be used for some abstract fields defined by this
	OAuth 2.0 Dynamic Client Registration Protocol		specification. In some cases, additional profiles may be created
			that constrain or prescribe these values or specify how they are to
			be exchanged. The OAuth 2.0 Dynamic Client Registration Protocol
	[I-D.ietf-oauth-dyn-reg] is one such profile that enables OAuth		[I-D.ietf-oauth-dyn-reg] is one such profile that enables OAuth
	Clients to register metadata about themselves at an Authorization		Clients to register metadata about themselves at an Authorization
	Server.		Server.
	8. Security Considerations		8. Security Considerations
	This section discusses security considerations that apply when using		This section discusses security considerations that apply when using
	assertions with OAuth 2.0 as described in this document. As		assertions with OAuth 2.0 as described in this document. As
	discussed in Section 3, there are two different ways to obtain		discussed in Section 3, there are two different ways to obtain
	assertions: either as self-issued or obtained from a third party		assertions: either as self-issued or obtained from a third party
	skipping to change at page 18, line 36 ¶		skipping to change at page 17, line 40 ¶
	o Specification document(s): [[this document]]		o Specification document(s): [[this document]]
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[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
	RFC 3986, January 2005.		3986, January 2005.
	[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.
	10.2. Informative References		10.2. Informative References
	[I-D.iab-privacy-considerations]		[I-D.iab-privacy-considerations]
	Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,		Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
	Morris, J., Hansen, M., and R. Smith, "Privacy		Morris, J., Hansen, M., and R. Smith, "Privacy
	Considerations for Internet Protocols",		Considerations for Internet Protocols", draft-iab-privacy-
	draft-iab-privacy-considerations-03 (work in progress),		considerations-09 (work in progress), May 2013.
	July 2012.
	[I-D.ietf-oauth-dyn-reg]		[I-D.ietf-oauth-dyn-reg]
	Richer, J., Bradley, J., Jones, M., and M. Machulak,		Richer, J., Bradley, J., Jones, M., and M. Machulak,
	"OAuth 2.0 Dynamic Client Registration Protocol",		"OAuth 2.0 Dynamic Client Registration Protocol", draft-
	draft-ietf-oauth-dyn-reg-13 (work in progress), July 2013.		ietf-oauth-dyn-reg-13 (work in progress), July 2013.
	[I-D.ietf-oauth-jwt-bearer]		[I-D.ietf-oauth-jwt-bearer]
	Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token		Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
	(JWT) Profile for OAuth 2.0 Client Authentication and		(JWT) Profile for OAuth 2.0 Client Authentication and
	Authorization Grants", draft-ietf-oauth-jwt-bearer (work		Authorization Grants", draft-ietf-oauth-jwt-bearer (work
	in progress), July 2013.		in progress), December 2013.
	[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 2013.		in progress), December 2013.
	[OASIS.WS-Trust]		[OASIS.WS-Trust]
	Nadalin, A., Ed., Goodner, M., Ed., Gudgin, M., Ed.,		Nadalin, A., Ed., Goodner, M., Ed., Gudgin, M., Ed.,
	Barbir, A., Ed., and H. Granqvist, Ed., "WS-Trust",		Barbir, A., Ed., and H. Granqvist, Ed., "WS-Trust", Feb
	Feb 2009.		2009.
	[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.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	The authors wish to thank the following people that have influenced		The authors wish to thank the following people that have influenced
	or contributed this specification: Paul Madsen, Eric Sachs, Jian Cai,		or contributed this specification: Paul Madsen, Eric Sachs, Jian Cai,
	Tony Nadalin, Hannes Tschofenig, the authors of the OAuth WRAP		Tony Nadalin, Hannes Tschofenig, the authors of the OAuth WRAP
	specification, and the members of the OAuth working group.		specification, and the members of the OAuth working group.
	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-assertions-13
			o Clean up language around subject per the subject part of http://
			www.ietf.org/mail-archive/web/oauth/current/msg12155.html
			o Replace "Client Credentials flow" by "Client Credentials _Grant_"
			as suggested in http://www.ietf.org/mail-archive/web/oauth/current
			/msg12155.html
			o For consistency with SAML and JWT per http://www.ietf.org/mail-
			archive/web/oauth/current/msg12251.html and http://www.ietf.org/
			mail-archive/web/oauth/current/msg12253.html Stated that "In the
			absence of an application profile specifying otherwise, compliant
			applications MUST compare the audience values using the Simple
			String Comparison method defined in Section 6.2.1 of RFC 3986."
			o Added one-time use, maximum lifetime, and specific subject and
			attribute requirements to Interoperability Considerations.
	draft-ietf-oauth-assertions-12		draft-ietf-oauth-assertions-12
	o Stated that issuer and audience values SHOULD be compared using		o Stated that issuer and audience values SHOULD be compared using
	the Simple String Comparison method defined in Section 6.2.1 of		the Simple String Comparison method defined in Section 6.2.1 of
	RFC 3986 unless otherwise specified by the application.		RFC 3986 unless otherwise specified by the application.
	draft-ietf-oauth-assertions-11		draft-ietf-oauth-assertions-11
	o Addressed comments from IESG evaluation https://		o Addressed comments from IESG evaluation https://
	datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/.		datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/.
	o Reworded Interoperability Considerations to state what		o Reworded Interoperability Considerations to state what
	identifiers, keys, endpoints, etc. need to be exchanged/agreed		identifiers, keys, endpoints, etc. need to be exchanged/agreed
	upon.		upon.
	o Added brief description of assertion to the into and included a		o Added brief description of assertion to the into and included a
	reference to Section 3 (Framework) where it's described more.		reference to Section 3 (Framework) where it's described more.
	o Changed such that a self-issued assertion must (was should) have		o Changed such that a self-issued assertion must (was should) have
	the client id as the issuer.		the client id as the issuer.
	o Changed "Specific Assertion Format and Processing Rules" to		o Changed "Specific Assertion Format and Processing Rules" to
	"Common Scenarios" and reworded to be more suggestive of common		"Common Scenarios" and reworded to be more suggestive of common
	practices, rather than trying to be normative. Also removed lots		practices, rather than trying to be normative. Also removed lots
	of repetitive text in that section.		of repetitive text in that section.
	o Refined language around audience, subject, client identifiers,		o Refined language around audience, subject, client identifiers,
	etc. to hopefully be clearer and less redundant.		etc. to hopefully be clearer and less redundant.
	o Changed title from "Assertion Framework for OAuth 2.0" to		o Changed title from "Assertion Framework for OAuth 2.0" to
	"Assertion Framework for OAuth 2.0 Client Authentication and		"Assertion Framework for OAuth 2.0 Client Authentication and
	Authorization Grants" to be more explicit about the scope of the		Authorization Grants" to be more explicit about the scope of the
	document per		document per http://www.ietf.org/mail-archive/web/oauth/current/
	http://www.ietf.org/mail-archive/web/oauth/current/msg11063.html.		msg11063.html.
	o Noted that authentication of the client per Section 3.2.1 of OAuth		o Noted that authentication of the client per Section 3.2.1 of OAuth
	is optional for an access token request with an assertion as an		is optional for an access token request with an assertion as an
	authorization grant and removed client_id from the associated		authorization grant and removed client_id from the associated
	example.		example.
	draft-ietf-oauth-assertions-10		draft-ietf-oauth-assertions-10
	o Changed term "Principal" to "Subject".		o Changed term "Principal" to "Subject".
	skipping to change at page 21, line 5 ¶		skipping to change at page 20, line 30 ¶
	draft-ietf-oauth-assertions-09		draft-ietf-oauth-assertions-09
	o Allow audience values to not be URIs.		o Allow audience values to not be URIs.
	o Added informative references to draft-ietf-oauth-saml2-bearer and		o Added informative references to draft-ietf-oauth-saml2-bearer and
	draft-ietf-oauth-jwt-bearer.		draft-ietf-oauth-jwt-bearer.
	o Clarified that the statements about possible issuers are non-		o Clarified that the statements about possible issuers are non-
	normative by using the language "Examples of issuers".		normative by using the language "Examples of issuers".
			draft-ietf-oauth-assertions-08
	o Update reference to RFC 6755 from draft-ietf-oauth-urn-sub-ns		o Update reference to RFC 6755 from draft-ietf-oauth-urn-sub-ns
	o Tidy up IANA consideration section		o Tidy up IANA consideration section
	draft-ietf-oauth-assertions-07		draft-ietf-oauth-assertions-07
	o Reference RFC 6749.		o Reference RFC 6749.
	o Remove extraneous word per		o Remove extraneous word per http://www.ietf.org/mail-archive/web/
	http://www.ietf.org/mail-archive/web/oauth/current/msg10029.html		oauth/current/msg10029.html
	draft-ietf-oauth-assertions-06		draft-ietf-oauth-assertions-06
	o Add more text to intro explaining that an assertion grant type can		o Add more text to intro explaining that an assertion grant type can
	be used with or without client authentication/identification and		be used with or without client authentication/identification and
	that client assertion authentication is nothing more than an		that client assertion authentication is nothing more than an
	alternative way for a client to authenticate to the token endpoint		alternative way for a client to authenticate to the token endpoint
	draft-ietf-oauth-assertions-05		draft-ietf-oauth-assertions-05
	o Non-normative editorial cleanups		o Non-normative editorial cleanups
	draft-ietf-oauth-assertions-04
	o Updated document to incorporate the review comments from the		o Updated document to incorporate the review comments from the
	shepherd - thread and alternative draft at		shepherd - thread and alternative draft at http://www.ietf.org/
	http://www.ietf.org/mail-archive/web/oauth/current/msg09437.html		mail-archive/web/oauth/current/msg09437.html
	o Added reference to draft-ietf-oauth-urn-sub-ns and include		o Added reference to draft-ietf-oauth-urn-sub-ns and include
	suggestions on		suggestions on urn:ietf:params:oauth:[grant-type|client-assertion-
	urn:ietf:params:oauth:[grant-type|client-assertion-type]:* URNs		type]:* URNs
	draft-ietf-oauth-assertions-03		draft-ietf-oauth-assertions-03
	o updated reference to draft-ietf-oauth-v2 from -25 to -26		o updated reference to draft-ietf-oauth-v2 from -25 to -26
	draft-ietf-oauth-assertions-02		draft-ietf-oauth-assertions-02
	o Added text about limited lifetime ATs and RTs per		o Added text about limited lifetime ATs and RTs per http://
	http://www.ietf.org/mail-archive/web/oauth/current/msg08298.html.		www.ietf.org/mail-archive/web/oauth/current/msg08298.html.
	o Changed the line breaks in some examples to avoid awkward		o Changed the line breaks in some examples to avoid awkward
	rendering to text format. Also removed encoded '=' padding from a		rendering to text format. Also removed encoded '=' padding from a
	few examples because both known derivative specs, SAML and JWT,		few examples because both known derivative specs, SAML and JWT,
	omit the padding char in serialization/encoding.		omit the padding char in serialization/encoding.
	o Remove section 7 on error responses and move that (somewhat		o Remove section 7 on error responses and move that (somewhat
	modified) content into subsections of section 4 broken up by		modified) content into subsections of section 4 broken up by authn
	authn/authz per		/authz per http://www.ietf.org/mail-archive/web/oauth/current/
	http://www.ietf.org/mail-archive/web/oauth/current/msg08735.html.		msg08735.html.
	o Rework the text about "MUST validate ... in order to establish a		o Rework the text about "MUST validate ... in order to establish a
	mapping between ..." per		mapping between ..." per http://www.ietf.org/mail-archive/web/
	http://www.ietf.org/mail-archive/web/oauth/current/msg08872.html		oauth/current/msg08872.html and http://www.ietf.org/mail-archive/
	and		web/oauth/current/msg08749.html.
	http://www.ietf.org/mail-archive/web/oauth/current/msg08749.html.
	o Change "The Principal MUST identify an authorized accessor. If		o Change "The Principal MUST identify an authorized accessor. If
	the assertion is self-issued, the Principal SHOULD be the		the assertion is self-issued, the Principal SHOULD be the
	client_id" in 6.1 per		client_id" in 6.1 per http://www.ietf.org/mail-archive/web/oauth/
	http://www.ietf.org/mail-archive/web/oauth/current/msg08873.html.		current/msg08873.html.
	o Update reference in 4.1 to point to 2.3 (rather than 3.2) of		o Update reference in 4.1 to point to 2.3 (rather than 3.2) of
	oauth-v2 (rather than self)		oauth-v2 (rather than self) http://www.ietf.org/mail-archive/web/
	http://www.ietf.org/mail-archive/web/oauth/current/msg08874.html.		oauth/current/msg08874.html.
	o Move the "Section 3 of" out of the xref to hopefully fix the link		o Move the "Section 3 of" out of the xref to hopefully fix the link
	in 4.1 and remove the client_id bullet from 4.2 per		in 4.1 and remove the client_id bullet from 4.2 per http://
	http://www.ietf.org/mail-archive/web/oauth/current/msg08875.html.		www.ietf.org/mail-archive/web/oauth/current/msg08875.html.
	o Add ref to Section 3.3 of oauth-v2 for scope definition and remove		o Add ref to Section 3.3 of oauth-v2 for scope definition and remove
	some then redundant text per		some then redundant text per http://www.ietf.org/mail-archive/web/
	http://www.ietf.org/mail-archive/web/oauth/current/msg08890.html.		oauth/current/msg08890.html.
	o Change "The following format and processing rules SHOULD be		o Change "The following format and processing rules SHOULD be
	applied" to "The following format and processing rules apply" in		applied" to "The following format and processing rules apply" in
	sections 6.x to remove conflicting normative qualification of		sections 6.x to remove conflicting normative qualification of
	other normative statements per		other normative statements per http://www.ietf.org/mail-archive/
	http://www.ietf.org/mail-archive/web/oauth/current/msg08892.html.		web/oauth/current/msg08892.html.
	o Add text the client_id must id the client to 4.1 and remove		o Add text the client_id must id the client to 4.1 and remove
	similar text from other places per		similar text from other places per http://www.ietf.org/mail-
	http://www.ietf.org/mail-archive/web/oauth/current/msg08893.html.		archive/web/oauth/current/msg08893.html.
	o Remove the MUST from the text prior to the HTTP parameter		o Remove the MUST from the text prior to the HTTP parameter
	definitions per		definitions per http://www.ietf.org/mail-archive/web/oauth/current
	http://www.ietf.org/mail-archive/web/oauth/current/msg08920.html.		/msg08920.html.
	o Updated examples to use grant_type and client_assertion_type		o Updated examples to use grant_type and client_assertion_type
	values from the OAuth SAML Assertion Profiles spec.		values from the OAuth SAML Assertion Profiles spec.
	Authors' Addresses		Authors' Addresses
	Brian Campbell		Brian Campbell
	Ping Identity		Ping Identity
	Email: brian.d.campbell@gmail.com		Email: brian.d.campbell@gmail.com
End of changes. 46 change blocks.
	155 lines changed or deleted		176 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/