< draft-ietf-oauth-resource-indicators-02.txt		draft-ietf-oauth-resource-indicators-03.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: August 1, 2019 Yubico		Expires: January 21, 2020 Yubico
	H. Tschofenig		H. Tschofenig
	Arm Limited		Arm Limited
	January 28, 2019		July 20, 2019
	Resource Indicators for OAuth 2.0		Resource Indicators for OAuth 2.0
	draft-ietf-oauth-resource-indicators-02		draft-ietf-oauth-resource-indicators-03
	Abstract		Abstract
	An extension to the OAuth 2.0 Authorization Framework defining		An extension to the OAuth 2.0 Authorization Framework defining
	request parameters that enable a client to explicitly signal to an		request parameters that enable a client to explicitly signal to an
	authorization server about the identity of the protected resource(s)		authorization server about the identity of the protected resource(s)
	to which it is requesting access.		to which it is requesting access.
	Status of This Memo		Status of This Memo
	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 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 August 1, 2019.		This Internet-Draft will expire on January 21, 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 28 ¶		skipping to change at page 2, line 28 ¶
	4.2. OAuth Extensions Error Registration . . . . . . . . . . . 10		4.2. OAuth Extensions Error Registration . . . . . . . . . . . 10
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. Normative References . . . . . . . . . . . . . . . . . . 10		5.1. Normative References . . . . . . . . . . . . . . . . . . 10
	5.2. Informative References . . . . . . . . . . . . . . . . . 11		5.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
	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, for the client to explicitly signal to the
	authorization server where it intends to use the access token it is		authorization server where it intends to use the access token it is
	requesting.		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 the		resource where the client intends to use the token allows the
	authorization server to mint the token accordingly.		authorization server to mint the token accordingly.
	Specific knowledge of the intended recipient(s) of the access token		Specific knowledge of the intended recipient(s) of the access token
	also helps facilitate improved security characteristics of the token		also helps facilitate improved security characteristics of the token
	itself. Bearer tokens, currently the most commonly utilized type of		itself. Bearer tokens, currently the most commonly utilized type of
	OAuth access token, allow any party in possession of a token to get		OAuth access token, allow any party in possession of a token to get
	access to the associated resources. To prevent misuse, several		access to the associated resources. To prevent misuse, several
	important security assumptions must hold, one of which is that an		important security assumptions must hold, one of which is that an
	access token must only be valid for use at a specific protected		access token must only be valid for use at a specific protected
	resource and for a specific scope of access. Section 5.2 of		resource and for a specific scope of access. Section 5.2 of
	skipping to change at page 4, line 6 ¶		skipping to change at page 4, line 6 ¶
	"client" defined by The OAuth 2.0 Authorization Framework [RFC6749].		"client" defined by The OAuth 2.0 Authorization Framework [RFC6749].
	2. Resource Parameter		2. Resource Parameter
	In requests to the authorization server, a client MAY indicate the		In requests to the authorization server, a client MAY indicate the
	protected resource (a.k.a. resource server, application, API, etc.)		protected resource (a.k.a. resource server, application, API, etc.)
	to which it is requesting access by including the following parameter		to which it is requesting access by including the following parameter
	in the request.		in the request.
	resource		resource
	Indicates the target service or resource at which access is being		Indicates the target service or resource to which access is being
	requested. Its value MUST be an absolute URI, as specified by		requested. Its value MUST be an absolute URI, as specified by
	Section 4.3 of [RFC3986], which MAY include a query component but		Section 4.3 of [RFC3986], which MAY include a query component but
	MUST NOT include a fragment component. The "resource" parameter		MUST NOT include a fragment component. The "resource" parameter
	URI value is an identifier representing the identity of the		URI value is an identifier representing the identity of the
	resource, which MAY be a locator that corresponds to a network		resource, which MAY be a locator that corresponds to a network
	addressable location where the target resource is hosted.		addressable location where the target resource is hosted.
	Multiple "resource" parameters MAY be used to indicate that the		Multiple "resource" parameters MAY be used to indicate that the
	requested token is intended to be used at multiple resources.		requested token is intended to be used at multiple resources.
	The parameter value identifies a resource to which the client is		The parameter value identifies a resource to which the client is
	skipping to change at page 4, line 44 ¶		skipping to change at page 4, line 44 ¶
	"https://api.example.com/app/" would be used as a more specific		"https://api.example.com/app/" would be used as a more specific
	value. Another example, for an API like SCIM [RFC7644] that has		value. Another example, for an API like SCIM [RFC7644] that has
	multiple endpoints such as "https://apps.example.com/scim/Users",		multiple endpoints such as "https://apps.example.com/scim/Users",
	"https://apps.example.com/scim/Groups", and		"https://apps.example.com/scim/Groups", and
	"https://apps.example.com/scim/Schemas" The client would use		"https://apps.example.com/scim/Schemas" The client would use
	"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. And 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, 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
	skipping to change at page 5, line 21 ¶		skipping to change at page 5, line 21 ¶
	resource.		resource.
	2.1. Authorization Request		2.1. Authorization Request
	When the "resource" parameter is used in an authorization request to		When the "resource" parameter is used in an authorization request to
	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 an		code flow (Section 4.1 of OAuth 2.0 [RFC6749]) where an intermediate
	intermediate representation of the authorization grant (the		representation of the authorization grant (the authorization code) is
	authorization code) is returned from the authorization endpoint, the		returned from the authorization endpoint, the requested resource is
	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 authorization requests sent as a JWTs, such as when using JWT
	Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single		Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single
	"resource" parameter value is represented as a JSON string while		"resource" parameter value is represented as a JSON string while
	multiple values are represented as an array of strings.		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 meet policy
	decision (e.g. refuse the request due to unknown resources), and		decision (e.g. refuse the request due to unknown resources), and
	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 an error response using the error code		request with an error response using the error code "invalid_target"
	"invalid_target" as the value of the "error" parameter and can		as the value of the "error" parameter and can provide additional
	provide additional information regarding the reasons for the error		information regarding the reasons for the error using the
	using the "error_description" and/or "error_uri" parameters.		"error_description" and/or "error_uri" parameters.
	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%2Eexample%2Eorg%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 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%2Eexample%2Eorg%2Fcb
	&scope=calendar%20contacts		&scope=calendar%20contacts
	&resource=https%3A%2F%2Fcal.example.com%2F		&resource=https%3A%2F%2Fcal.example.com%2F
	skipping to change at page 7, line 26 ¶		skipping to change at page 7, line 26 ¶
	know. This further improves privacy as scope values give an		know. This further improves privacy as scope values give an
	indication of what services the resource owner uses and it improves		indication of what services the resource owner uses and it improves
	security as scope values may contain confidential data. As specified		security as scope values may contain confidential data. As specified
	in Section 5.1 of [RFC6749], the authorization server must indicate		in Section 5.1 of [RFC6749], the authorization server must indicate
	the access token's effective scope to the client in the "scope"		the access token's effective scope to the client in the "scope"
	response parameter value when it differs from the scope requested by		response parameter value when it differs from the scope requested by
	the client.		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 and response where the client tells the authorization		token request (Figure 3) and response (Figure 4) where the client
	server that it wants the access token for use at		tells the authorization server that it wants the access token for use
	"https://cal.example.com/" (extra line breaks and indentation are for		at "https://cal.example.com/" (extra line breaks and indentation are
	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%2Eexample%2Eorg%2Fcb
	&code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ		&code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ
	&resource=https%3A%2F%2Fcal.example.com%2F		&resource=https%3A%2F%2Fcal.example.com%2F
	skipping to change at page 9, line 38 ¶		skipping to change at page 9, line 38 ¶
	resources. The "resource" parameter enables a client to indicate the		resources. The "resource" parameter enables a client to indicate the
	protected resources where the requested access token will be used,		protected resources where the requested access token will be used,
	which in turn enables the authorization server to apply the		which in turn enables the authorization server to apply the
	appropriate audience restrictions to the token.		appropriate audience restrictions 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 that might confuse a client into sending an access
	token to a resource that is user controlled or is owned by a		token to a resource that is user controlled or is owned by a
	different tenant, it is important to use a specific resource URI		different tenant, it is important to use a specific resource URI
	including a path component. This will cause any access token issued		including a path component. This will cause any access token issued
	for accessing the user controlled resource to have a invalid audience		for accessing the user controlled resource to have an invalid
	if replayed against the legitimate resource API.		audience if replayed against the legitimate resource API.
	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 request, using only a single "resource" parameter is
	encouraged. A bearer token that has multiple intended recipients		encouraged. A bearer token that has multiple intended recipients
	(audiences) can be used by any one of those recipients at any other.		(audiences) indicating that the token is valid at more than one
	Thus, a high degree of trust between the involved parties is needed		protected resource can be used by any one of those protected
	when using access tokens with multiple audiences. Furthermore an		resources to access any of the other protected resources. Thus, a
			high degree of trust between the involved parties is needed when
			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. IANA Considerations
	4.1. OAuth Parameters Registration		4.1. OAuth Parameters Registration
	This specification registers 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
	[[TODO: draft-ietf-oauth-token-exchange will have already
	registered this for 'token request' and this draft has a more
	generalized usage and needs to somehow either update that
	registration or do a partial registration and reference]]
	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		4.2. OAuth Extensions Error Registration
	This specification registers 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 [[TODO: draft-ietf-oauth-token-exchange will have already		response
	registered this for 'token error response' and this draft has a
	more generalized usage and needs to somehow either update that
	registration or do a partial registration and reference]]
	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		5. References
	5.1. Normative References		5.1. Normative References
	[IANA.OAuth.Parameters]		[IANA.OAuth.Parameters]
	IANA, "OAuth Parameters",		IANA, "OAuth Parameters",
	skipping to change at page 11, line 28 ¶		skipping to change at page 11, line 23 ¶
	[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		5.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-16 (work in progress), April 2018.		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>.
	[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,		(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
	<https://www.rfc-editor.org/info/rfc7519>.		<https://www.rfc-editor.org/info/rfc7519>.
	skipping to change at page 11, line 52 ¶		skipping to change at page 11, line 47 ¶
	September 2015, <https://www.rfc-editor.org/info/rfc7644>.		September 2015, <https://www.rfc-editor.org/info/rfc7644>.
	[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",		[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
	RFC 7662, DOI 10.17487/RFC7662, October 2015,		RFC 7662, DOI 10.17487/RFC7662, October 2015,
	<https://www.rfc-editor.org/info/rfc7662>.		<https://www.rfc-editor.org/info/rfc7662>.
	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 and Benjamin Kaduk serving as Security Area Directors.		Eric Rescorla, Benjamin Kaduk and Roman Danyliw serving as Security
			Area Directors. Additionally, the following individuals contributed
	Additionally, the following individuals contributed ideas, feedback,		ideas, feedback, and wording that helped shape this specification:
	and wording that helped shape this specification:
	Vittorio Bertocci, Sergey Beryozkin, William Denniss, Vladimir		Vittorio Bertocci, Sergey Beryozkin, Roman Danyliw, William Denniss,
	Dzhuvinov, George Fletcher, Dick Hardt, Phil Hunt, Michael Jones,		Vladimir Dzhuvinov, George Fletcher, Dick Hardt, Phil Hunt, Michael
	Torsten Lodderstedt, Anthony Nadalin, Justin Richer, Nat Sakimura,		Jones, Torsten Lodderstedt, Anthony Nadalin, Justin Richer, Nat
	Filip Skokan, and Hans Zandbelt.		Sakimura, Rifaat Shekh-Yusef, Filip Skokan, 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-03
			o Editorial updates from AD review.
			o Update draft-ietf-oauth-jwsreq ref to -19.
			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		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
End of changes. 22 change blocks.
	45 lines changed or deleted		45 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/