< draft-ietf-oauth-resource-indicators-05.txt		draft-ietf-oauth-resource-indicators-06.txt >
	OAuth Working Group B. Campbell		OAuth Working Group B. Campbell
	Internet-Draft Ping Identity		Internet-Draft Ping Identity
	Intended status: Standards Track J. Bradley		Intended status: Standards Track J. Bradley
	Expires: January 24, 2020 Yubico		Expires: March 8, 2020 Yubico
	H. Tschofenig		H. Tschofenig
	Arm Limited		Arm Limited
	July 23, 2019		September 5, 2019
	Resource Indicators for OAuth 2.0		Resource Indicators for OAuth 2.0
	draft-ietf-oauth-resource-indicators-05		draft-ietf-oauth-resource-indicators-06
	Abstract		Abstract
	An extension to the OAuth 2.0 Authorization Framework defining		This document specifies an extension to the OAuth 2.0 Authorization
	request parameters that enable a client to explicitly signal to an		Framework defining request parameters that enable a client to
	authorization server about the identity of the protected resource(s)		explicitly signal to an authorization server about the identity of
	to which it is requesting access.		the protected resource(s) to which it is requesting access.
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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, 2020.		This Internet-Draft will expire on March 8, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 2, line 16 ¶		skipping to change at page 2, line 16 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Notation and Conventions . . . . . . . . . . 3		1.1. Requirements Notation and Conventions . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Resource Parameter . . . . . . . . . . . . . . . . . . . . . 3		2. Resource Parameter . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Authorization Request . . . . . . . . . . . . . . . . . . 5		2.1. Authorization Request . . . . . . . . . . . . . . . . . . 5
	2.2. Access Token Request . . . . . . . . . . . . . . . . . . 6		2.2. Access Token Request . . . . . . . . . . . . . . . . . . 6
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 9		3. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
	4.1. OAuth Parameters Registration . . . . . . . . . . . . . . 10		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	4.2. OAuth Extensions Error Registration . . . . . . . . . . . 10		5.1. OAuth Parameters Registration . . . . . . . . . . . . . . 10
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		5.2. OAuth Extensions Error Registration . . . . . . . . . . . 10
	5.1. Normative References . . . . . . . . . . . . . . . . . . 10		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.2. Informative References . . . . . . . . . . . . . . . . . 11		6.1. Normative References . . . . . . . . . . . . . . . . . . 11
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11		6.2. Informative References . . . . . . . . . . . . . . . . . 11
			Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 12		Appendix B. Document History . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	Several years of deployment and implementation experience with the		Several years of deployment and implementation experience with the
	OAuth 2.0 Authorization Framework [RFC6749] has uncovered a need, in		OAuth 2.0 Authorization Framework [RFC6749] has uncovered a need, in
	some circumstances, for the client to explicitly signal to the		some circumstances such as an authorization server servicing a
	authorization server where it intends to use the access token it is		significant number of diverse resources, for the client to explicitly
	requesting.		signal to the authorization server where it intends to use the access
			token it is requesting.
	Knowing the protected resource (a.k.a. resource server, application,		Knowing the protected resource (a.k.a. resource server, application,
	API, etc.) that will process the access token enables the		API, etc.) that will process the access token enables the
	authorization server to construct the token as necessary for that		authorization server to construct the token as necessary for that
	entity. Properly encrypting the token (or content within the token)		entity. Properly encrypting the token (or content within the token)
	to a particular resource, for example, requires knowing which		to a particular resource, for example, requires knowing which
	resource will receive and decrypt the token. Furthermore, various		resource will receive and decrypt the token. Furthermore, various
	resources oftentimes have different requirements with respect to the		resources oftentimes have different requirements with respect to the
	data contained in, or referenced by, the token and knowing the		data contained in, or referenced by, the token and knowing the
	resource where the client intends to use the token allows the		resource where the client intends to use the token allows the
	skipping to change at page 3, line 16 ¶		skipping to change at page 3, line 18 ¶
	recipients within the token to prevent token redirect. When the		recipients within the token to prevent token redirect. When the
	authorization server is informed of the resource that will process		authorization server is informed of the resource that will process
	the access token, it can restrict the intended audience of that token		the access token, it can restrict the intended audience of that token
	to the given resource such that the token cannot be used successfully		to the given resource such that the token cannot be used successfully
	at other resources.		at other resources.
	OAuth scope, from Section 3.3 of [RFC6749], is sometimes overloaded		OAuth scope, from Section 3.3 of [RFC6749], is sometimes overloaded
	to convey the location or identity of the protected resource,		to convey the location or identity of the protected resource,
	however, doing so isn't always feasible or desirable. Scope is		however, doing so isn't always feasible or desirable. Scope is
	typically about what access is being requested rather than where that		typically about what access is being requested rather than where that
	access will be redeemed (e.g. "email", "admin:org", "user_photos",		access will be redeemed (e.g., "email", "admin:org", "user_photos",
	"channels:read", and "channels:write" are a small sample of scope		"channels:read", and "channels:write" are a small sample of scope
	values in use in the wild that convey only the type of access and not		values in use in the wild that convey only the type of access and not
	the location or identity).		the location or identity).
	In some circumstances and for some deployments, a means for the		In some circumstances and for some deployments, a means for the
	client to signal to the authorization server where it intends to use		client to signal to the authorization server where it intends to use
	the access token it's requesting is important and useful. A number		the access token it's requesting is important and useful. A number
	of implementations and deployments of OAuth 2.0 have already employed		of implementations and deployments of OAuth 2.0 have already employed
	proprietary parameters toward that end. Going forward, this		proprietary parameters toward that end. Going forward, this
	specification aspires to provide a standardized and interoperable		specification aspires to provide a standardized and interoperable
	skipping to change at page 4, line 49 ¶		skipping to change at page 4, line 51 ¶
	"https://apps.example.com/scim/" as the resource so that the issued		"https://apps.example.com/scim/" as the resource so that the issued
	access token is valid for all the endpoints of the SCIM API.		access token is valid for all the endpoints of the SCIM API.
	The following error code is provided for an authorization server to		The following error code is provided for an authorization server to
	indicate problems with the requested resource(s) in response to an		indicate problems with the requested resource(s) in response to an
	authorization request or access token request. It can also be used		authorization request or access token request. It can also be used
	to inform the client that it has requested an invalid combination of		to inform the client that it has requested an invalid combination of
	resource and scope.		resource and scope.
	invalid_target		invalid_target
	The requested resource is invalid, unknown, or malformed.		The requested resource is invalid, missing, unknown, or malformed.
	The authorization server SHOULD audience restrict issued access		The authorization server SHOULD audience-restrict issued access
	tokens to the resource(s) indicated by the "resource" parameter.		tokens to the resource(s) indicated by the "resource" parameter.
	Audience restrictions can be communicated in JSON Web Tokens		Audience restrictions can be communicated in JSON Web Tokens
	[RFC7519] with the "aud" claim and the top-level member of the same		[RFC7519] with the "aud" claim and the top-level member of the same
	name provides the audience restriction information in a Token		name provides the audience restriction information in a Token
	Introspection [RFC7662] response. The authorization server may use		Introspection [RFC7662] response. The authorization server may use
	the exact "resource" value as the audience or it may map from that		the exact "resource" value as the audience or it may map from that
	value to a more general URI or abstract identifier for the given		value to a more general URI or abstract identifier for the given
	resource.		resource.
	2.1. Authorization Request		2.1. Authorization Request
	skipping to change at page 5, line 26 ¶		skipping to change at page 5, line 28 ¶
	the authorization endpoint, it indicates the identity of the		the authorization endpoint, it indicates the identity of the
	protected resource(s) to which access is being requested. When an		protected resource(s) to which access is being requested. When an
	access token will be returned directly from the authorization		access token will be returned directly from the authorization
	endpoint via the implicit flow (Section 4.2 of OAuth 2.0 [RFC6749]),		endpoint via the implicit flow (Section 4.2 of OAuth 2.0 [RFC6749]),
	the requested resource is applicable to that access token. In the		the requested resource is applicable to that access token. In the
	code flow (Section 4.1 of OAuth 2.0 [RFC6749]) where an intermediate		code flow (Section 4.1 of OAuth 2.0 [RFC6749]) where an intermediate
	representation of the authorization grant (the authorization code) is		representation of the authorization grant (the authorization code) is
	returned from the authorization endpoint, the requested resource is		returned from the authorization endpoint, the requested resource is
	applicable to the full authorization grant.		applicable to the full authorization grant.
	For authorization requests sent as a JWTs, such as when using JWT		For an authorization request sent as a JSON Web Token (JWT), such as
	Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single		when using JWT Secured Authorization Request [I-D.ietf-oauth-jwsreq],
	"resource" parameter value is represented as a JSON string while		a single "resource" parameter value is represented as a JSON string
	multiple values are represented as an array of strings.		while multiple values are represented as an array of strings.
	If the client omits the "resource" parameter when requesting		If the client omits the "resource" parameter when requesting
	authorization, the authorization server MAY process the request with		authorization, the authorization server MAY process the request with
	no specific resource or by using a pre-defined default resource		no specific resource or by using a pre-defined default resource
	value. Alternatively, the authorization server MAY require clients		value. Alternatively, the authorization server MAY require clients
	to specify the resource(s) they intend to access and MAY fail		to specify the resource(s) they intend to access and MAY fail
	requests that omit the parameter with an "invalid_target" error. The		requests that omit the parameter with an "invalid_target" error. The
	authorization server might use this data to inform the user about the		authorization server might use this data to inform the user about the
	resources the client is going to access on her behalf, to meet policy		resources the client is going to access on her behalf, to apply
	decision (e.g. refuse the request due to unknown resources), and		policy (e.g., refuse the request due to unknown resources), and to
	determine the set of resources that can be used in subsequent access		determine the set of resources that can be used in subsequent access
	token requests.		token requests.
	If the authorization server fails to parse the provided value(s) or		If the authorization server fails to parse the provided value(s) or
	does not consider the resource(s) acceptable, it should reject the		does not consider the resource(s) acceptable, it should reject the
	request with an error response using the error code "invalid_target"		request with an error response using the error code "invalid_target"
	as the value of the "error" parameter and can provide additional		as the value of the "error" parameter and can provide additional
	information regarding the reasons for the error using the		information regarding the reasons for the error using the
	"error_description".		"error_description".
	An example of an authorization request where the client tells the		An example of an authorization request where the client tells the
	authorization server that it wants an access token for use at		authorization server that it wants an access token for use at
	"https://api.example.com/app/" is shown in Figure 1 below (extra line		"https://api.example.com/app/" is shown in Figure 1 below (extra line
	breaks and indentation are for display purposes only).		breaks and indentation are for display purposes only).
	GET /as/authorization.oauth2?response_type=token		GET /as/authorization.oauth2?response_type=token
	&client_id=example-client		&client_id=example-client
	&state=XzZaJlcwYew1u0QBrRv_Gw		&state=XzZaJlcwYew1u0QBrRv_Gw
	&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Eorg%2Fcb		&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
	&resource=https%3A%2F%2Fapi.example.com%2Fapp%2F HTTP/1.1		&resource=https%3A%2F%2Fapi.example.com%2Fapp%2F HTTP/1.1
	Host: authorization-server.example.com		Host: authorization-server.example.com
	Figure 1: Implicit Flow Authorization Request		Figure 1: Implicit Flow Authorization Request
	Below in Figure 2 is an example of an authorization request using the		Below in Figure 2 is an example of an authorization request using the
	"code" response type where the client is requesting access to the		"code" response type where the client is requesting access to the
	resource owner's contacts and calendar data at		resource owner's contacts and calendar data at
	"https://cal.example.com/" and "https://contacts.example.com/" (extra		"https://cal.example.com/" and "https://contacts.example.com/" (extra
	line breaks and indentation are for display purposes only).		line breaks and indentation are for display purposes only).
	GET /as/authorization.oauth2?response_type=code		GET /as/authorization.oauth2?response_type=code
	&client_id=s6BhdRkqt3		&client_id=s6BhdRkqt3
	&state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI		&state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI
	&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Eorg%2Fcb		&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
	&scope=calendar%20contacts		&scope=calendar%20contacts
	&resource=https%3A%2F%2Fcal.example.com%2F		&resource=https%3A%2F%2Fcal.example.com%2F
	&resource=https%3A%2F%2Fcontacts.example.com%2F HTTP/1.1		&resource=https%3A%2F%2Fcontacts.example.com%2F HTTP/1.1
	Host: authorization-server.example.com		Host: authorization-server.example.com
	Figure 2: Code Flow Authorization Request		Figure 2: Code Flow Authorization Request
	2.2. Access Token Request		2.2. Access Token Request
	When the "resource" parameter is used on an access token request made		When the "resource" parameter is used on an access token request made
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 18 ¶
	service(s) where it intends to use that token by way of the		service(s) where it intends to use that token by way of the
	"resource" parameter and can indicate the desired scope of the		"resource" parameter and can indicate the desired scope of the
	requested token using the "scope" parameter. The semantics of such a		requested token using the "scope" parameter. The semantics of such a
	request are that the client is asking for a token with the requested		request are that the client is asking for a token with the requested
	scope that is usable at all the requested target services.		scope that is usable at all the requested target services.
	Effectively, the requested access rights of the token are the		Effectively, the requested access rights of the token are the
	cartesian product of all the scopes at all the target services. To		cartesian product of all the scopes at all the target services. To
	the extent possible, when issuing access tokens, the authorization		the extent possible, when issuing access tokens, the authorization
	server should downscope the scope value associated with an access		server should downscope the scope value associated with an access
	token to the value the respective resource is able to process and		token to the value the respective resource is able to process and
	needs to know. This further improves privacy as scope values give an		needs to know. This further improves privacy as a list of scope
	indication of what services the resource owner uses and downscoping a		values is an indication that the resource owner uses the multiple
	token to only that which is needed for a particular service can limit		various services listed; downscoping a token to only that which is
	the extent to which such information is revealed across different		needed for a particular service can limit the extent to which such
	services. As specified in Section 5.1 of [RFC6749], the		information is revealed across different services. As specified in
	authorization server must indicate the access token's effective scope		Section 5.1 of [RFC6749], the authorization server must indicate the
	to the client in the "scope" response parameter value when it differs		access token's effective scope to the client in the "scope" response
	from the scope requested by the client.		parameter value when it differs from the scope requested by the
			client.
	Following from the code flow authorization request shown in Figure 2,		Following from the code flow authorization request shown in Figure 2,
	the below examples show an "authorization_code" grant type access		the below examples show an "authorization_code" grant type access
	token request (Figure 3) and response (Figure 4) where the client		token request (Figure 3) and response (Figure 4) where the client
	tells the authorization server that it wants the access token for use		tells the authorization server that it wants the access token for use
	at "https://cal.example.com/" (extra line breaks and indentation are		at "https://cal.example.com/" (extra line breaks and indentation are
	for display purposes only).		for display purposes only).
	POST /as/token.oauth2 HTTP/1.1		POST /as/token.oauth2 HTTP/1.1
	Host: authorization-server.example.com		Host: authorization-server.example.com
	Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ		Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	grant_type=authorization_code		grant_type=authorization_code
	&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Eorg%2Fcb		&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
	&code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ		&code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ
	&resource=https%3A%2F%2Fcal.example.com%2F		&resource=https%3A%2F%2Fcal.example.com%2F
	Figure 3: Access Token Request		Figure 3: Access Token Request
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json		Content-Type: application/json
	Cache-Control: no-cache, no-store		Cache-Control: no-cache, no-store
	{		{
	skipping to change at page 8, line 37 ¶		skipping to change at page 8, line 37 ¶
	with the response shown in Figure 6 (extra line breaks and		with the response shown in Figure 6 (extra line breaks and
	indentation are for display purposes only).		indentation are for display purposes only).
	POST /as/token.oauth2 HTTP/1.1		POST /as/token.oauth2 HTTP/1.1
	Host: authorization-server.example.com		Host: authorization-server.example.com
	Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ		Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	grant_type=refresh_token		grant_type=refresh_token
	&refresh_token=4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2		&refresh_token=4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2
	&resource=https%3A%2F%2Fcontacts.example.com%2Fapp%2F		&resource=https%3A%2F%2Fcontacts.example.com%2F
	Figure 5: Access Token Request		Figure 5: Access Token Request
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json		Content-Type: application/json
	Cache-Control: no-cache, no-store		Cache-Control: no-cache, no-store
	{		{
	"access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi		"access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi
	JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI		JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI
	skipping to change at page 9, line 25 ¶		skipping to change at page 9, line 25 ¶
	UowfmtNaA5EikYAw",		UowfmtNaA5EikYAw",
	"token_type":"Bearer",		"token_type":"Bearer",
	"expires_in":3600,		"expires_in":3600,
	"scope":"contacts"		"scope":"contacts"
	}		}
	Figure 6: Access Token Response		Figure 6: Access Token Response
	3. Security Considerations		3. Security Considerations
	An access token that is audience restricted to a protected resource		An audience-restricted access token, legitimately presented to a
	that obtains that token legitimately cannot be used to access		resource, cannot then be taken by that resource and presented
	resources on behalf of the resource owner at other protected		elsewhere for illegitimate access to other resources. The "resource"
	resources. The "resource" parameter enables a client to indicate the		parameter enables a client to indicate the protected resources where
	protected resources where the requested access token will be used,		the requested access token will be used, which in turn enables the
	which in turn enables the authorization server to apply the		authorization server to apply the appropriate audience restrictions
	appropriate audience restrictions to the token.		to the token.
	Some servers may host user content or be multi-tenant. In order to		Some servers may host user content or be multi-tenant. In order to
	avoid attacks that might confuse a client into sending an access		avoid attacks where one tenant uses an access token to illegitimately
	token to a resource that is user controlled or is owned by a		access resources owned by a different tenant, it is important to use
	different tenant, it is important to use a specific resource URI		a specific resource URI including any portion of the URI that
	including a path component. This will cause any access token issued		identifies the tenant, such as a path component. This will allow
	for accessing the user controlled resource to have an invalid		access tokens to be audience-restricted in a way that identifies the
	audience if replayed against the legitimate resource API.		tenant and prevent their use, due to an invalid audience, at
			resources owned by a different tenant.
	Although multiple occurrences of the "resource" parameter may be		Although multiple occurrences of the "resource" parameter may be
	included in a request, using only a single "resource" parameter is		included in a token request, using only a single "resource" parameter
	encouraged. A bearer token that has multiple intended recipients		is encouraged. A bearer token that has multiple intended recipients
	(audiences) indicating that the token is valid at more than one		(audiences) indicating that the token is valid at more than one
	protected resource can be used by any one of those protected		protected resource can be used by any one of those protected
	resources to access any of the other protected resources. Thus, a		resources to access any of the other protected resources. Thus, a
	high degree of trust between the involved parties is needed when		high degree of trust between the involved parties is needed when
	using access tokens with multiple audiences. Furthermore an		using access tokens with multiple audiences. Furthermore an
	authorization server may be unwilling or unable to fulfill a token		authorization server may be unwilling or unable to fulfill a token
	request with multiple resources.		request with multiple resources.
	Whenever feasible, the "resource" parameter should correspond to the		Whenever feasible, the "resource" parameter should correspond to the
	network addressable location of the protected resource. This makes		network addressable location of the protected resource. This makes
	it possible for the client to validate that the resource being		it possible for the client to validate that the resource being
	requested controls the corresponding network location, reducing the		requested controls the corresponding network location, reducing the
	risk of malicious endpoints obtaining tokens meant for other		risk of malicious endpoints obtaining tokens meant for other
	resources. If the "resource" parameter contains an abstract		resources. If the "resource" parameter contains an abstract
	identifier, it is the client's responsibility to validate out of band		identifier, it is the client's responsibility to validate out of band
	that any network endpoint to which tokens are sent are the intended		that any network endpoint to which tokens are sent are the intended
	audience for that identifier.		audience for that identifier.
	4. IANA Considerations		4. Privacy Considerations
	4.1. OAuth Parameters Registration		In typical OAuth deployments the authorization sever is in a position
			to observe and track a significant amount of user and client
			behavior. It is largely just inherent to the nature of OAuth and
			this document does little to affect that. In some cases, however,
			such as when access token introspection is not being used, use of the
			resource parameter defined herein may allow for tracking behavior at
			a somewhat more granular and specific level than would otherwise be
			possible in its absence.
			5. IANA Considerations
			5.1. OAuth Parameters Registration
	This specification updates the following value in the IANA "OAuth		This specification updates the following value in the IANA "OAuth
	Parameters" registry [IANA.OAuth.Parameters] established by		Parameters" registry [IANA.OAuth.Parameters] established by
	[RFC6749].		[RFC6749].
	o Parameter name: resource		o Parameter name: resource
	o Parameter usage location: authorization request, token request		o Parameter usage location: authorization request, token request
	o Change controller: IESG		o Change controller: IESG
	o Specification document(s): [[ this specification ]]		o Specification document(s): [[ this specification ]]
	4.2. OAuth Extensions Error Registration		5.2. OAuth Extensions Error Registration
	This specification updates the following error in the IANA "OAuth		This specification updates the following error in the IANA "OAuth
	Extensions Error Registry" [IANA.OAuth.Parameters] established by		Extensions Error Registry" [IANA.OAuth.Parameters] established by
	[RFC6749].		[RFC6749].
	o Error name: invalid_target		o Error name: invalid_target
	o Error usage location: implicit grant error response, token error		o Error usage location: implicit grant error response, token error
	response		response
	o Related protocol extension: resource parameter		o Related protocol extension: resource parameter
	o Change controller: IESG		o Change controller: IESG
	o Specification document(s): [[ this specification ]]		o Specification document(s): [[ this specification ]]
	5. References		6. References
	5.1. Normative References		6.1. Normative References
	[IANA.OAuth.Parameters]		[IANA.OAuth.Parameters]
	IANA, "OAuth Parameters",		IANA, "OAuth Parameters",
	<http://www.iana.org/assignments/oauth-parameters>.		<http://www.iana.org/assignments/oauth-parameters>.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 11, line 18 ¶		skipping to change at page 11, line 31 ¶
	<https://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
	[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",		[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
	RFC 6749, DOI 10.17487/RFC6749, October 2012,		RFC 6749, DOI 10.17487/RFC6749, October 2012,
	<https://www.rfc-editor.org/info/rfc6749>.		<https://www.rfc-editor.org/info/rfc6749>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	5.2. Informative References		6.2. Informative References
	[I-D.ietf-oauth-jwsreq]		[I-D.ietf-oauth-jwsreq]
	Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization		Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization
	Framework: JWT Secured Authorization Request (JAR)",		Framework: JWT Secured Authorization Request (JAR)",
	draft-ietf-oauth-jwsreq-19 (work in progress), June 2019.		draft-ietf-oauth-jwsreq-19 (work in progress), June 2019.
	[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization		[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
	Framework: Bearer Token Usage", RFC 6750,		Framework: Bearer Token Usage", RFC 6750,
	DOI 10.17487/RFC6750, October 2012,		DOI 10.17487/RFC6750, October 2012,
	<https://www.rfc-editor.org/info/rfc6750>.		<https://www.rfc-editor.org/info/rfc6750>.
	skipping to change at page 12, line 4 ¶		skipping to change at page 12, line 19 ¶
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	This specification was developed within the OAuth Working Group under		This specification was developed within the OAuth Working Group under
	the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with		the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with
	Eric Rescorla, Benjamin Kaduk and Roman Danyliw serving as Security		Eric Rescorla, Benjamin Kaduk and Roman Danyliw serving as Security
	Area Directors. Additionally, the following individuals contributed		Area Directors. Additionally, the following individuals contributed
	ideas, feedback, and wording that helped shape this specification:		ideas, feedback, and wording that helped shape this specification:
	Vittorio Bertocci, Sergey Beryozkin, Roman Danyliw, William Denniss,		Vittorio Bertocci, Sergey Beryozkin, Roman Danyliw, William Denniss,
	Vladimir Dzhuvinov, George Fletcher, Dick Hardt, Phil Hunt, Michael		Vladimir Dzhuvinov, George Fletcher, Dick Hardt, Phil Hunt, Michael
	Jones, Torsten Lodderstedt, Anthony Nadalin, Justin Richer, Nat		Jones, Benjamin Kaduk, Barry Leiba, Torsten Lodderstedt, Anthony
	Sakimura, Rifaat Shekh-Yusef, Filip Skokan, and Hans Zandbelt.		Nadalin, Justin Richer, Adam Roach, Nat Sakimura, Rifaat Shekh-Yusef,
			Filip Skokan, Eric Vyncke, and Hans Zandbelt.
	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-resource-indicators-06
			o Expand JWT acronym on first use per Genart last call review.
			o Updates from IESG evaluation comments.
	draft-ietf-oauth-resource-indicators-05		draft-ietf-oauth-resource-indicators-05
	o Remove specific mention of error_uri, which is rarely (if ever)		o Remove specific mention of error_uri, which is rarely (if ever)
	used and seems to only confuse things for readers of extensions		used and seems to only confuse things for readers of extensions
	like this one.		like this one.
	draft-ietf-oauth-resource-indicators-04		draft-ietf-oauth-resource-indicators-04
	o Editorial updates from AD review that were overlooked in -03.		o Editorial updates from AD review that were overlooked in -03.
	skipping to change at page 12, line 33 ¶		skipping to change at page 13, line 5 ¶
	o Editorial updates from AD review.		o Editorial updates from AD review.
	o Update draft-ietf-oauth-jwsreq ref to -19.		o Update draft-ietf-oauth-jwsreq ref to -19.
	o Update the IANA requests to say they update the registries.		o Update the IANA requests to say they update the registries.
	draft-ietf-oauth-resource-indicators-02		draft-ietf-oauth-resource-indicators-02
	o Clarify that the value of the "resource" parameter is a URI which		o Clarify that the value of the "resource" parameter is a URI which
	can be an abstract identifier for the target resource and doesn't		can be an abstract identifier for the target resource and doesn't
	necessarily have to correspond to a network addressable location.		necessarily have to correspond to a network addressable location.
	draft-ietf-oauth-resource-indicators-01
	o Significant rework of the main section of the document attempting		o Significant rework of the main section of the document attempting
	to clarify a number of things that came up at, around and after		to clarify a number of things that came up at, around and after
	IETF 102 and the call for adoption.		IETF 102 and the call for adoption.
	o Change the "invalid_resource" error to "invalid_target" to align		o Change the "invalid_resource" error to "invalid_target" to align
	with draft-ietf-oauth-token-exchange, which has some overlap in		with draft-ietf-oauth-token-exchange, which has some overlap in
	functionality.		functionality.
	o Allow the "resource" parameter value to have a query component		o Allow the "resource" parameter value to have a query component
	(aligning with draft-ietf-oauth-token-exchange).		(aligning with draft-ietf-oauth-token-exchange).
	o Moved the Security Considerations section to before the IANA		o Moved the Security Considerations section to before the IANA
	Considerations.		Considerations.
End of changes. 30 change blocks.
	65 lines changed or deleted		83 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/