rfc8707xml2.original.xml   rfc8707.xml 
<?xml version="1.0" encoding="us-ascii"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/r
fc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?> <rfc number="8707" xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
<?rfc tocindent="yes"?> docName="draft-ietf-oauth-resource-indicators-08" ipr="trust200902"
<?rfc symrefs="yes"?> consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en
<?rfc sortrefs="yes"?> "
<?rfc comments="yes"?> tocInclude="true" symRefs="true" sortRefs="true" version="3">
<?rfc inline="yes"?>
<?rfc compact="yes"?> <!-- xml2rfc v2v3 conversion 2.32.0 -->
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-oauth-resource-indicators-08" ipr="trust 200902">
<front> <front>
<title abbrev="OAuth Resource Indicators">Resource Indicators for OAuth 2.0< /title> <title abbrev="OAuth Resource Indicators">Resource Indicators for OAuth 2.0< /title>
<seriesInfo name="RFC" value="8707" />
<author fullname="Brian Campbell" initials="B." surname="Campbell"> <author fullname="Brian Campbell" initials="B." surname="Campbell">
<organization>Ping Identity</organization> <organization>Ping Identity</organization>
<address><email>brian.d.campbell@gmail.com</email></address> <address>
<email>brian.d.campbell@gmail.com</email>
</address>
</author> </author>
<author fullname="John Bradley" initials="J." surname="Bradley"> <author fullname="John Bradley" initials="J." surname="Bradley">
<organization>Yubico</organization> <organization>Yubico</organization>
<address><email>ve7jtb@ve7jtb.com</email></address> <address>
<email>ve7jtb@ve7jtb.com</email>
</address>
</author> </author>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig"> <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>Arm Limited</organization> <organization>Arm Limited</organization>
<address><email>hannes.tschofenig@gmx.net</email></address> <address>
<email>hannes.tschofenig@gmx.net</email>
</address>
</author> </author>
<date month="February" year="2020" />
<date />
<area>Security</area> <area>Security</area>
<workgroup>OAuth Working Group</workgroup>
<workgroup>OAuth Working Group</workgroup>
<keyword>OAuth</keyword> <keyword>OAuth</keyword>
<keyword>Resource</keyword> <keyword>Resource</keyword>
<keyword>Audience</keyword> <keyword>Audience</keyword>
<abstract> <abstract>
<t> <t>
This document specifies an extension to the OAuth 2.0 This document specifies an extension to the OAuth 2.0
Authorization Framework defining request parameters that enable a client Authorization Framework defining request parameters that enable a client
to explicitly signal to an authorization server about the identity of th e protected to explicitly signal to an authorization server about the identity of th e protected
resource(s) to which it is requesting access. resource(s) to which it is requesting access.
skipping to change at line 52 skipping to change at line 49
<keyword>Audience</keyword> <keyword>Audience</keyword>
<abstract> <abstract>
<t> <t>
This document specifies an extension to the OAuth 2.0 This document specifies an extension to the OAuth 2.0
Authorization Framework defining request parameters that enable a client Authorization Framework defining request parameters that enable a client
to explicitly signal to an authorization server about the identity of th e protected to explicitly signal to an authorization server about the identity of th e protected
resource(s) to which it is requesting access. resource(s) to which it is requesting access.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" title="Introduction"> <section anchor="Introduction" numbered="true" toc="default">
<t> <name>Introduction</name>
Several years of deployment and implementation experience with the <xref targe <t>
t="RFC6749">OAuth 2.0 Authorization Framework</xref> Several years of deployment and implementation experience with the OAuth 2.0
has uncovered a need, in some circumstances such as an authorization server se Authorization Framework <xref
rvicing a significant number of diverse resources, for the client to explicitly target="RFC6749" format="default"></xref>
signal to the authorization server where has uncovered a need (in some circumstances, such as an authorization server
it intends to use the access token it is requesting. servicing a significant number of diverse resources) for the client to
explicitly signal to the authorization server where it intends to use the
access token it is requesting.
</t> </t>
<t> <t>
Knowing the protected resource (a.k.a. resource server, application, API, etc. ) that will process the access token enables the authorization server to constru ct the token Knowing the protected resource (a.k.a. resource server, application, API, etc. ) that will process the access token enables the authorization server to constru ct the token
as necessary for that entity. Properly encrypting the token (or content within the token) to a particular resource, for example, as necessary for that entity. Properly encrypting the token (or content within the token) to a particular resource, for example,
requires knowing which resource will receive and decrypt the token. Furthermor e, various resources oftentimes have requires knowing which resource will receive and decrypt the token. Furthermor e, various resources oftentimes have
different requirements with respect to the data contained in, or referenced by , the token and knowing the resource different requirements with respect to the data contained in (or referenced by ) the token, and knowing the resource
where the client intends to use the where the client intends to use the
token allows the authorization server to mint the token accordingly. token allows the authorization server to mint the token accordingly.
</t> </t>
<t> <t>
Specific knowledge of the intended recipient(s) of the access token also helps facilitate improved Specific knowledge of the intended recipient(s) of the access token also helps facilitate improved
security characteristics of the token itself. security characteristics of the token itself.
Bearer tokens, currently the most commonly utilized type of OAuth access token , Bearer tokens, currently the most commonly utilized type of OAuth access token ,
allow any party in possession of a token to get access to the associated resou rces. allow any party in possession of a token to get access to the associated resou rces.
To prevent misuse, several important security assumptions must hold, one of wh ich is that To prevent misuse, several important security assumptions must hold, one of wh ich is that
an access token must only be valid for use at a an access token must only be valid for use at a
specific protected resource and for a specific scope of access. specific protected resource and for a specific scope of access.
Section 5.2 of <xref target="RFC6750"/>, for example, <xref target="RFC6750" sectionFormat="of" section="5.2"/>, for example,
prescribes including the token's intended recipients within the token to preve nt token redirect. prescribes including the token's intended recipients within the token to preve nt token redirect.
When the authorization server is informed of When the authorization server is informed of
the resource that will process the access token, it can restrict the intended audience of that token the resource that will process the access token, it can restrict the intended audience of that token
to the given resource such that the token cannot be used successfully at other resources. to the given resource such that the token cannot be used successfully at other resources.
</t> </t>
<t> <t>
OAuth scope, from Section 3.3 of <xref target="RFC6749"/>, is sometimes overlo OAuth scope, from <xref target="RFC6749" sectionFormat="of"
aded to convey the section="3.3"/>, is sometimes overloaded to convey the location or identity
location or identity of the protected resource, however, doing so isn't always of the protected resource, however, doing so isn't always feasible or
feasible or desirable. Scope is desirable. Scope is typically about what access is being requested rather
typically about what access is being requested rather than where that access w than where that access will be redeemed (e.g., <tt>email</tt>,
ill be redeemed <tt>admin:org</tt>, <tt>user_photos</tt>, <tt>channels:read</tt>, and
(e.g., <spanx style="verb">email</spanx>, <spanx style="verb">admin:org</spanx <tt>channels:write</tt> are a small sample of scope values in use in the
>, <spanx style="verb">user_photos</spanx>, wild that convey only the type of access and not the location or identity).
<spanx style="verb">channels:read</spanx>, and <spanx style="verb">channels:wr
ite</spanx> are a small sample of scope
values in use in the wild that convey only the type of access and not the loca
tion or identity).
</t> </t>
<t> <t>
In some circumstances and for some deployments, a means for the client to sign al to the authorization server where it In some circumstances and for some deployments, a means for the client to sign al to the authorization server where it
intends to use the access token it's requesting intends to use the access token it's requesting
is important and useful. A number of implementations and deployments of OAuth 2.0 have already employed proprietary parameters is important and useful. A number of implementations and deployments of OAuth 2.0 have already employed proprietary parameters
toward that end. toward that end.
Going forward, this specification aspires to provide a standardized and intero perable alternative to the proprietary approaches. Going forward, this specification aspires to provide a standardized and intero perable alternative to the proprietary approaches.
</t> </t>
<section anchor="RNC" title="Requirements Notation and Conventions"> <section anchor="RNC" numbered="true" toc="default">
<t> <name>Requirements Notation and Conventions</name>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL
"
in this document are to be interpreted as described in
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="Terminology" title="Terminology"> <t>
<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
This specification uses the terms "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"access token", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"refresh token", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"authorization server", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
"resource server", to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
"authorization endpoint", <xref target="RFC8174"/> when, and only when, they appear in all capitals,
"authorization request", as shown here.
"authorization response", </t>
"token endpoint",
"grant type",
"access token request",
"access token response",
and "client"
defined by <xref target="RFC6749">The OAuth 2.0 Authorization Framework<
/xref>.
</t>
</section>
</section>
<section anchor="Terminology" numbered="true" toc="default">
<name>Terminology</name>
<t>
This specification uses the terms "access token", "refresh token",
"authorization server", "resource server", "authorization endpoint",
"authorization request", "authorization response", "token endpoint",
"grant type", "access token request", "access token response", and
"client" defined by The OAuth 2.0 Authorization Framework <xref
target="RFC6749" format="default"></xref>.
</t>
</section>
</section> </section>
<section anchor="ResourceParameter" numbered="true" toc="default">
<section anchor="ResourceParameter" title="Resource Parameter"> <name>Resource Parameter</name>
<t> <t>
In requests to the authorization server, a client MAY indicate the prote In requests to the authorization server, a client <bcp14>MAY</bcp14>
cted resource (a.k.a. resource server, application, indicate the protected resource (a.k.a. resource server, application,
API, etc.) to which it is requesting access by API, etc.) to which it is requesting access by including the following
including the following parameter in the request. parameter in the request.
<list style="hanging">
<t hangText="resource">
<vspace/>
Indicates the target service or
resource to which access is being requested.
Its value MUST be an absolute URI, as specified by
Section 4.3 of <xref target="RFC3986"/>. The URI MUST NOT include
a fragment component. It SHOULD NOT include a query
component, but it is recognized that there are cases that make a query c
omponent a useful and necessary
part of the resource parameter, such as when query parameter(s) are used
to scope requests to an application.
The <spanx style="verb">resource</spanx> parameter URI value is an ident
ifier representing the identity of the resource,
which MAY be a locator that corresponds to a network addressable locatio
n where the target resource is hosted.
Multiple
<spanx style="verb">resource</spanx>
parameters MAY be used to indicate
that the requested token is intended to be used at multiple resources.
</t> </t>
</list> <dl newline="true" spacing="normal">
<dt>resource</dt>
<dd>
Indicates the target service or resource to which access is being
requested. Its value <bcp14>MUST</bcp14> be an absolute URI, as
specified by <xref target="RFC3986" sectionFormat="of"
section="4.3"/>. The URI <bcp14>MUST NOT</bcp14> include a fragment
component. It <bcp14>SHOULD NOT</bcp14> include a query component, but
it is recognized that there are cases that make a query component a
useful and necessary part of the resource parameter, such as when one
or more query parameters are used to scope requests to an application.
The <tt>resource</tt> parameter URI value is an identifier
representing the identity of the resource, which <bcp14>MAY</bcp14> be
a locator that corresponds to a network-addressable location where the
target resource is hosted. Multiple <tt>resource</tt> parameters
<bcp14>MAY</bcp14> be used to indicate that the requested token is
intended to be used at multiple resources.
</dd>
</dl>
<t>
The parameter value identifies a resource to which the client is request The parameter value identifies a resource to which the client is
ing access. requesting access. The parameter can carry the location of a
The parameter can carry the location of a protected resource, typically protected resource, typically as an https URL or a more abstract
as an https URL, or a more abstract identifier. identifier. This enables the authorization server to apply policy as
This enables the authorization server to apply policy as appropriate appropriate for the resource, such as determining the type and content
for the resource, such as determining the type and content of tokens to of tokens to be issued, if and how tokens are encrypted, and applying
be issued, if and how appropriate audience restrictions.
tokens are encrypted, and applying appropriate audience restrictions.
</t> </t>
<t> <t>
The client SHOULD provide the most specific URI that it can for the comp The client <bcp14>SHOULD</bcp14> provide the most specific URI that it
lete API or set of resources it intends to access. can for the complete API or set of resources it intends to access.
In practice a client will know a base URI for the application or resourc In practice, a client will know a base URI for the application or resour
e that it interacts with, which ce that it interacts with, which
is appropriate to use as the value of the <spanx style="verb">resource</ is appropriate to use as the value of the <tt>resource</tt> parameter.
spanx> parameter. The client <bcp14>SHOULD</bcp14> use the base URI of the API as the <tt>
The client SHOULD use the base URI of the API as the <spanx style="verb" resource</tt> parameter
>resource</spanx> parameter
value unless specific knowledge of the resource dictates otherwise. value unless specific knowledge of the resource dictates otherwise.
For example, the value <spanx style="verb">https://api.example.com/</spa For example, the value <tt>https://api.example.com/</tt> would be used
nx> would be used for a resource that is the exclusive application on that host; however,
for a resource that is the exclusive application on that host, however,
if the resource is one of many applications on that host, something like if the resource is one of many applications on that host, something like
<spanx style="verb">https://api.example.com/app/</spanx> would be used a <tt>https://api.example.com/app/</tt> would be used as a more specific
s a more specific value. value.
Another example, for an API like <xref target="RFC7644">SCIM</xref> that
has multiple endpoints such as Another example is when an API has multiple endpoints, e.g., when
<spanx style="verb">https://apps.example.com/scim/Users</spanx>, System for Cross-domain Identity Management (SCIM) <xref target="RFC7644" for
<spanx style="verb">https://apps.example.com/scim/Groups</spanx>, and mat="default"></xref> has
<spanx style="verb">https://apps.example.com/scim/Schemas</spanx> endpoints such as <tt>https://apps.example.com/scim/Users</tt>,
The client would use <spanx style="verb">https://apps.example.com/scim/< <tt>https://apps.example.com/scim/Groups</tt>, and
/spanx> as the resource <tt>https://apps.example.com/scim/Schemas</tt>. The client would use
so that the issued access token is valid for all the endpoints of the SC <tt>https://apps.example.com/scim/</tt> as the resource so that the issued
IM API. access token is valid for all the endpoints of the SCIM API.
</t> </t>
<t> <t>
The following error code is provided for an authorization server to indi cate problems with the requested resource(s) The following error code is provided for an authorization server to indi cate problems with the requested resource(s)
in response to an authorization request or access token request. It can also be used to inform the client that in response to an authorization request or access token request. It can also be used to inform the client that
it has requested an invalid combination of resource and scope. it has requested an invalid combination of resource and scope.
<list style="hanging">
<t hangText="invalid_target">
<vspace/>
The requested resource is invalid, missing, unknown, or malformed.
</t>
</list>
</t>
<t>
The authorization server SHOULD audience-restrict issued access tokens t
o the
resource(s) indicated by the <spanx style="verb">resource</spanx> parame
ter.
Audience restrictions can be communicated in <xref target="RFC7519">JSON
Web Tokens</xref> with the <spanx style="verb">aud</spanx> claim
and the top-level member of the same name provides the audience restrict
ion information in a <xref target="RFC7662">Token Introspection</xref> response.
The authorization server may use the exact <spanx style="verb">resource<
/spanx> value as the audience or it may map from that value to a more
general URI or abstract identifier for the given resource.
</t>
<section anchor="authz-req" title="Authorization Request">
<t>
When the <spanx style="verb">resource</spanx> parameter is used in an au
thorization request to the authorization endpoint, it indicates the identity of
the protected resource(s) to which access is being requested.
When an access token will be returned directly from the authorization en
dpoint via the implicit flow (Section 4.2 of <xref target="RFC6749">OAuth 2.0</x
ref>),
the requested resource is applicable to that access token. In the code f
low (Section 4.1 of <xref target="RFC6749">OAuth 2.0</xref>) where
an intermediate representation of the authorization grant (the authoriza
tion code) is returned from the authorization endpoint,
the requested resource is applicable to the full authorization grant.
</t> </t>
<dl newline="true" spacing="normal">
<dt>invalid_target</dt>
<dd>
The requested resource is invalid, missing, unknown, or malformed.
</dd>
</dl>
<t> <t>
For an authorization request sent as a JSON Web Token (JWT), such as whe The authorization server <bcp14>SHOULD</bcp14> audience-restrict
n using issued access tokens to the resource(s) indicated by the
<xref target="I-D.ietf-oauth-jwsreq">JWT Secured Authorization Request</ <tt>resource</tt> parameter. Audience restrictions can be
xref>, communicated in JSON Web Tokens <xref target="RFC7519"
a single <spanx style="verb">resource</spanx> parameter value format="default"></xref> with the <tt>aud</tt> claim and the top-level
is represented as a JSON string while multiple values are represented as member of the same name provides the audience restriction information
an array of strings. in a Token Introspection <xref target="RFC7662"
format="default"></xref> response. The authorization server may use
the exact <tt>resource</tt> value as the audience or it may map from
that value to a more general URI or abstract identifier for the given
resource.
</t> </t>
<t> <section anchor="authz-req" numbered="true" toc="default">
If the client omits the <spanx style="verb">resource</spanx> parameter w <name>Authorization Request</name>
hen requesting <t>
authorization, the authorization server MAY process the When the <tt>resource</tt> parameter is used in an authorization
request with no specific resource or by using a pre-defined default reso request to the authorization endpoint, it indicates the identity of
urce value. the protected resource(s) to which access is being requested. When an
Alternatively, the authorization server MAY require clients to specify t access token will be returned directly from the authorization endpoint
he resource(s) they intend to via the implicit flow (<xref target="RFC6749" sectionFormat="of"
access and MAY fail requests that omit the parameter with an <spanx styl section="4.2">OAuth 2.0</xref>), the requested resource is applicable
e="verb">invalid_target</spanx> error. to that access token. In the code flow (<xref
target="RFC6749" sectionFormat="of" section="4.1">OAuth 2.0</xref>) wher
e an
intermediate representation of the authorization grant (the
authorization code) is returned from the authorization endpoint, the
requested resource is applicable to the full authorization grant.
</t>
<t>
For an authorization request sent as a JSON Web Token (JWT), such as
when using the JWT Secured Authorization Request <xref target="I-D.ietf-
oauth-jwsreq"
format="default"></xref>, a single
<tt>resource</tt> parameter value is represented as a JSON string
while multiple values are represented as an array of strings.
</t>
<t>
If the client omits the <tt>resource</tt> parameter when requesting
authorization, the authorization server <bcp14>MAY</bcp14> process the
request with no specific resource or by using a predefined default
resource value.
Alternatively, the authorization server <bcp14>MAY</bcp14> require clien
ts to specify the resource(s) they intend to
access and <bcp14>MAY</bcp14> fail requests that omit the parameter with
an <tt>invalid_target</tt> error.
The authorization server might use this data to inform the user about th e resources the client The authorization server might use this data to inform the user about th e resources the client
is going to access on her behalf, to apply policy (e.g., refuse the requ is going to access on their behalf, to apply policy (e.g., refuse the re
est due to unknown resources), quest due to unknown resources),
and to determine the set of resources that can be used in subsequent acc and to determine the set of resources that can be used in subsequent
ess token requests. access token requests.
</t> </t>
<t> <t>
If the authorization server fails to parse the If the authorization server fails to parse the
provided value(s) or does not consider the resource(s) acceptable, it sh ould reject the request with provided value(s) or does not consider the resource(s) acceptable, it sh ould reject the request with
an error response using the error code <spanx style="verb">invalid_targe an error response using the error code <tt>invalid_target</tt> as the va
t</spanx> as the value of the lue of the
<spanx style="verb">error</spanx> parameter and can provide additional <tt>error</tt> parameter and can provide additional
information regarding the reasons for the error using the information regarding the reasons for the error using the
<spanx style='verb'>error_description</spanx>. <tt>error_description</tt>.
</t> </t>
<t> <t>
An example of an authorization request where the client tells the author ization server that it wants an access token for use at An example of an authorization request where the client tells the author ization server that it wants an access token for use at
<spanx style="verb">https://api.example.com/app/</spanx> is shown in <xr ef target="authz-endpoint-example-token"/> below <tt>https://api.example.com/app/</tt> is shown in <xref target="authz-en dpoint-example-token" format="default"/> below
(extra line breaks and indentation are for display purposes only). (extra line breaks and indentation are for display purposes only).
<figure title="Implicit Flow Authorization Request" anchor="authz-endpoint-examp </t>
le-token"> <figure anchor="authz-endpoint-example-token">
<artwork><![CDATA[ <name>Implicit Flow Authorization Request</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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.example.org%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
]]></artwork> ]]></artwork>
</figure> </figure>
</t>
<t> <t>
Below in <xref target="authz-endpoint-example-code"/> is an example of Below in <xref target="authz-endpoint-example-code" format="default"/>
an authorization request is an example of an authorization request
using the <spanx style="verb">code</spanx> response type using the <tt>code</tt> response type
where the client is requesting access to the resource owner's contacts and calendar data at where the client is requesting access to the resource owner's contacts and calendar data at
<spanx style="verb">https://cal.example.com/</spanx> and <spanx style= "verb">https://contacts.example.com/</spanx> <tt>https://cal.example.com/</tt> and <tt>https://contacts.example.com /</tt>
(extra line breaks and indentation are for display purposes only). (extra line breaks and indentation are for display purposes only).
<figure title="Code Flow Authorization Request" anchor="authz-endpoint-e </t>
xample-code"> <figure anchor="authz-endpoint-example-code">
<artwork><![CDATA[ <name>Code Flow Authorization Request</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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.example.org%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
]]></artwork> ]]></artwork>
</figure> </figure>
</t> </section>
</section> <section anchor="token-req" numbered="true" toc="default">
<name>Access Token Request</name>
<section anchor="token-req" title="Access Token Request"> <t>
When the <tt>resource</tt> parameter is used on an access token request ma
<t> de to the token endpoint,
When the <spanx style="verb">resource</spanx> parameter is used on an acce
ss token request made to the token endpoint,
for all grant types, it indicates the target service or protected resource where the client intends to use for all grant types, it indicates the target service or protected resource where the client intends to use
the requested access token. the requested access token.
</t> </t>
<t> <t>
The resource value(s) that are acceptable to an authorization server in fu The resource value(s) that is acceptable to an authorization server in ful
lfilling an access token request are filling an access token request is
at its sole discretion based on local policy or configuration. In the case of a at its sole discretion based on local policy or configuration. In the case of a
<spanx style="verb">refresh_token</spanx> or <spanx style="verb">authoriza tion_code</spanx> grant type request, such policy may limit the acceptable resou rces <tt>refresh_token</tt> or <tt>authorization_code</tt> grant type request, such policy may limit the acceptable resources
to those that were originally granted by the resource owner to those that were originally granted by the resource owner
or a subset thereof. or a subset thereof.
In the <spanx style="verb">authorization_code</spanx> case where the reque
sted resources are a subset of the set of resources originally granted, In the <tt>authorization_code</tt> case where the requested resources
the authorization server will issue an access token based on that subset o are a subset of the set of resources originally granted, the
f requested resources while any refresh token authorization server will issue an access token based on that subset of
that is returned is bound to the full original grant. requested resources, whereas any refresh token that is returned is bound t
</t> o
<t> the full original grant.
</t>
<t>
When requesting a token, the client can indicate the desired target When requesting a token, the client can indicate the desired target
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
<spanx style="verb">resource</spanx> parameter and can indicate the <tt>resource</tt> parameter and can indicate the desired scope of the
desired scope of the requested token using the <spanx style="verb">scope</ requested token using the <tt>scope</tt> parameter. The semantics of
spanx> parameter. such a request are that the client is asking for a token with the
The semantics of such a request are that the client is asking for a requested scope that is usable at all the requested target services.
token with the requested scope that is usable at all the requested Effectively, the requested access rights of the token are the cartesian
target services. Effectively, the requested access rights of the product of all the scopes at all the target services. To the extent
token are the cartesian product of all the scopes at all the target possible, when issuing access tokens, the authorization server should
services. downscope the scope value associated with an access token to the value
To the extent possible, when issuing access tokens, the respective resource is able to process and needs to know. (Here,
the authorization server should downscope the scope value associated with "downscope" means give fewer permissions than originally authorized by
an access token to the resource owner.) This
the value the respective resource is able to process and needs to know. further improves privacy as a list of scope values is an indication that
This further improves privacy as a list of scope values is an indication t the resource owner uses the multiple various services listed;
hat the downscoping a token to only that which is needed for a particular
resource owner uses the multiple various services listed; downscoping a to service can limit the extent to which such information is revealed
ken to only that which is needed for a particular service can across different services. As specified in <xref target="RFC6749"
limit the extent to which such information is revealed across different se sectionFormat="of" section="5.1"/>, the authorization server must
rvices. indicate the access token's effective scope to the client in the
As specified in Section 5.1 of <xref target="RFC6749"/>, the authorization <tt>scope</tt> response parameter value when it differs from the scope
server must indicate requested by the client.
the access token's effective scope to the client in the <spanx style="verb </t>
">scope</spanx> <t>
response parameter value when it differs from the scope requested by the c Following from the code flow authorization request shown in <xref target
lient. ="authz-endpoint-example-code" format="default"/>,
</t> the below examples show an <tt>authorization_code</tt> grant type access
<t> token request (<xref target="token-endpoint-example-ac" format="default"/>)
Following from the code flow authorization request shown in <xref target and response (<xref target="response-example-ac" format="default"/>) whe
="authz-endpoint-example-code"/>, re the client tells the authorization server that
the below examples show an <spanx style="verb">authorization_code</spanx it wants the access token for use at <tt>https://cal.example.com/</tt>
> grant type access token request (<xref target="token-endpoint-example-ac"/>)
and response (<xref target="response-example-ac"/>) where the client tel
ls the authorization server that
it wants the access token for use at <spanx style="verb">https://cal.exa
mple.com/</spanx>
(extra line breaks and indentation are for display purposes only). (extra line breaks and indentation are for display purposes only).
<figure title="Access Token Request" anchor="token-endpoint-example-ac"> </t>
<artwork><![CDATA[ <figure anchor="token-endpoint-example-ac">
<name>Access Token Request</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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.example.org%2Fcb &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ &code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ
&resource=https%3A%2F%2Fcal.example.com%2F]]></artwork> &resource=https%3A%2F%2Fcal.example.com%2F]]></artwork>
</figure> </figure>
<figure anchor="response-example-ac">
<figure title="Access Token Response" anchor="response-example-ac"> <name>Access Token Response</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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
iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgwMCwic2NvcGUiOiJjYWxlbmRhciIs iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgwMCwic2NvcGUiOiJjYWxlbmRhciIs
ImF1ZCI6Imh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLyJ9.nNWJ2dXSxaDRdMUK ImF1ZCI6Imh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLyJ9.nNWJ2dXSxaDRdMUK
lzs-cYIj8MDoM6Gy7pf_sKrLGsAFf1C2bDhB60DQfW1DZL5npdko1_Mmk5sUf lzs-cYIj8MDoM6Gy7pf_sKrLGsAFf1C2bDhB60DQfW1DZL5npdko1_Mmk5sUf
zkiQNVpYw", zkiQNVpYw",
"token_type":"Bearer", "token_type":"Bearer",
"expires_in":3600, "expires_in":3600,
"refresh_token":"4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2", "refresh_token":"4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2",
"scope":"calendar" "scope":"calendar"
}]]></artwork> }]]></artwork>
</figure> </figure>
</t> <t>
<t>
A subsequent access token request, using the refresh token, where the clie nt tells the authorization server that A subsequent access token request, using the refresh token, where the clie nt tells the authorization server that
it wants an access token for use at it wants an access token for use at
<spanx style="verb">https://contacts.example.com/</spanx> is shown in <xre <tt>https://contacts.example.com/</tt> is shown in <xref target="token-end
f target="token-endpoint-example-rt"/> below point-example-rt" format="default"/> below
with the response shown in <xref target="response-example-rt"/> with the response shown in <xref target="response-example-rt" format="defa
ult"/>
(extra line breaks and indentation are for display purposes only). (extra line breaks and indentation are for display purposes only).
<figure title="Access Token Request" anchor="token-endpoint-example-rt"> </t>
<artwork><![CDATA[ <figure anchor="token-endpoint-example-rt">
<name>Access Token Request</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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%2F &resource=https%3A%2F%2Fcontacts.example.com%2F
]]></artwork> ]]></artwork>
</figure> </figure>
<figure anchor="response-example-rt">
<figure title="Access Token Response" anchor="response-example-rt"> <name>Access Token Response</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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
iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgyNiwic2NvcGUiOiJjb250YWN0cyIs iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgyNiwic2NvcGUiOiJjb250YWN0cyIs
ImF1ZCI6Imh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20vIn0.5f4yhqazc ImF1ZCI6Imh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20vIn0.5f4yhqazc
OSlJw4y94KPeWNEFQqj2cfeO8x4hr3YbHtIl3nQXnBMw5wREY5O1YbZED-GfH OSlJw4y94KPeWNEFQqj2cfeO8x4hr3YbHtIl3nQXnBMw5wREY5O1YbZED-GfH
UowfmtNaA5EikYAw", UowfmtNaA5EikYAw",
"token_type":"Bearer", "token_type":"Bearer",
"expires_in":3600, "expires_in":3600,
"scope":"contacts" "scope":"contacts"
}]]></artwork> }]]></artwork>
</figure> </figure>
</t> </section>
</section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t> <t>
An audience-restricted access token, legitimately presented to a An audience-restricted access token that is legitimately presented to a
resource, cannot then be taken by that resource and presented elsewhere resource cannot then be taken by that resource and presented elsewhere
for illegitimate access to other resources. for illegitimate access to other resources.
The <spanx style="verb">resource</spanx> The <tt>resource</tt>
parameter enables a client to indicate the protected resources where the requested access parameter enables a client to indicate the protected resources where the requested access
token will be used, which in turn enables the authorization server to ap ply the token will be used, which in turn enables the authorization server to ap ply the
appropriate audience restrictions to the token. appropriate audience restrictions to the token.
</t> </t>
<t> <t>
Some servers may host user content or be multi-tenant. In order to avoid attacks where one tenant uses an Some servers may host user content or be multi-tenant. In order to avoid attacks where one tenant uses an
access token to illegitimately access resources owned by a different ten ant, access token to illegitimately access resources owned by a different ten ant,
it is important to use a specific it is important to use a specific
resource URI including any portion of the URI that identifies the resource URI including any portion of the URI that identifies the
tenant, such as a path component. This will allow access tokens to be au dience-restricted in a way that identifies the tenant tenant, such as a path component. This will allow access tokens to be au dience-restricted in a way that identifies the tenant
and prevent their use, due to an invalid audience, at resources owned by a different tenant. and prevents their use, due to an invalid audience, at resources owned b y a different tenant.
</t> </t>
<t> <t>
Although multiple occurrences of the <spanx style="verb">resource</spanx Although multiple occurrences of the <tt>resource</tt> parameter
> parameter may be included in a token request, using only a single <tt>resource</tt
may be included in a token request, using only a single <spanx style="ve > parameter
rb">resource</spanx> parameter is encouraged.
is encouraged. A bearer token that has multiple intended recipients (aud
iences) indicating that the token If a bearer token has multiple intended recipients
is valid at more than one protected resource can be used by any one of t (audiences), then the token is valid at more than one
hose protected resources to access protected resource and can be used by any one of those
any of the other protected resources. Thus, a high degree of trust betwe resources to access any of the others.
en the involved parties
is needed when using access tokens with multiple audiences. Furthermore Thus, a high degree of trust between the involved parties
an authorization server may is needed when using access tokens with multiple audiences. Furthermore,
an authorization server may
be unwilling or unable to fulfill a token request with multiple resource s. be unwilling or unable to fulfill a token request with multiple resource s.
</t> </t>
<t> <t>
Whenever feasible, the <spanx style="verb">resource</spanx> parameter Whenever feasible, the <tt>resource</tt> parameter
should correspond to the network addressable location of the protected r should correspond to the network-addressable location of the protected r
esource. esource.
This makes it possible for the client to validate that the resource bein g requested controls the corresponding This makes it possible for the client to validate that the resource bein g requested controls the corresponding
network location, reducing the risk of malicious endpoints obtaining tok ens meant for other resources. network location, reducing the risk of malicious endpoints obtaining tok ens meant for other resources.
If the <spanx style="verb">resource</spanx> parameter contains an abstra ct identifier, it is the client's If the <tt>resource</tt> parameter contains an abstract identifier, it i s the client's
responsibility to validate out of band that any network endpoint to whic h tokens are sent are the intended audience for that identifier. responsibility to validate out of band that any network endpoint to whic h tokens are sent are the intended audience for that identifier.
</t> </t>
</section> </section>
<section anchor="Privacy" numbered="true" toc="default">
<section anchor="Privacy" title="Privacy Considerations"> <name>Privacy Considerations</name>
<t> <t>
In typical OAuth deployments the authorization sever is in a position to observe and track a significant 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 n ature of OAuth and this document amount of user and client behavior. It is largely just inherent to the n ature of OAuth, and this document
does little to affect that. In some cases, however, such as when access token introspection is not being 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 trackin g behavior at a somewhat more used, use of the resource parameter defined herein may allow for trackin g behavior at a somewhat more
granular and specific level than would otherwise be possible in its abse nce. granular and specific level than would otherwise be possible in its abse nce.
</t> </t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<section title="OAuth Parameters Registration"> <section numbered="true" toc="default">
<name>OAuth Parameters Registration</name>
<t> <t>
This specification updates the following value This specification updates the following value
in the IANA "OAuth Parameters" registry in the IANA "OAuth Parameters" registry
<xref target="IANA.OAuth.Parameters"/> <xref target="IANA.OAuth.Parameters" format="default"/>
established by <xref target="RFC6749"/>. established by <xref target="RFC6749" format="default"/>.
</t>
<t>
<?rfc subcompact="yes"?>
<list style='symbols'>
<t>Parameter name: resource</t>
<t>Parameter usage location: authorization request, token request</t
>
<t>Change controller: IESG</t>
<t>Specification document(s): [[ this specification ]]</t>
</list>
</t> </t>
<dl spacing="compact">
<dt>Parameter name:</dt> <dd>resource</dd>
<dt>Parameter usage location:</dt> <dd>authorization request, token re
quest</dd>
<dt>Change controller:</dt> <dd>IESG</dd>
<dt>Specification document(s):</dt> <dd>RFC 8707</dd>
</dl>
</section> </section>
<section title="OAuth Extensions Error Registration"> <section numbered="true" toc="default">
<name>OAuth Extensions Error Registration</name>
<t> <t>
This specification updates the following error in This specification updates the following error in
the IANA "OAuth Extensions Error Registry" the IANA "OAuth Extensions Error Registry"
<xref target="IANA.OAuth.Parameters"/> <xref target="IANA.OAuth.Parameters" format="default"/>
established by <xref target="RFC6749"/>. established by <xref target="RFC6749" format="default"/>.
</t>
<t>
<?rfc subcompact="yes"?>
<list style='symbols'>
<t>Error name: invalid_target</t>
<t>Error usage location: implicit grant error response, token error
response</t>
<t>Related protocol extension: resource parameter</t>
<t>Change controller: IESG</t>
<t>Specification document(s): [[ this specification ]]</t>
</list>
</t> </t>
<dl spacing="compact">
<dt>Error name:</dt> <dd>invalid_target</dd>
<dt>Error usage location:</dt> <dd>implicit grant error response, toke
n error response</dd>
<dt>Related protocol extension:</dt> <dd>resource parameter</dd>
<dt>Change controller:</dt> <dd>IESG</dd>
<dt>Specification document(s):</dt> <dd>RFC 8707</dd>
</dl>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.3986.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.6749.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml' ?>
<reference anchor="IANA.OAuth.Parameters" target="http://www.iana.org/assi <displayreference target="I-D.ietf-oauth-jwsreq" to="JWT-SAR"/>
gnments/oauth-parameters">
<front>
<title>OAuth Parameters</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
</references> <references>
<name>References</name>
<references>
<name>Normative References</name>
<references title="Informative References"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R FC.2119.xml"/>
FC.7662.xml' ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R FC.3986.xml"/>
FC.7519.xml' ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R FC.6749.xml"/>
FC.6750.xml' ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R FC.8174.xml"/>
FC.7644.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.
I-D.draft-ietf-oauth-jwsreq-19.xml'?>
</references>
<section anchor="Acknowledgements" title="Acknowledgements"> <reference anchor="IANA.OAuth.Parameters" target="https://www.iana.org/a
ssignments/oauth-parameters">
<front>
<title>OAuth Parameters</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7662.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7519.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6750.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7644.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.ietf-oauth-jwsreq.xml"/>
</references>
</references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t> <t>
This specification was developed within the OAuth Working Group This specification was developed within the OAuth Working Group
under the chairmanship of Hannes Tschofenig under the chairmanship of <contact fullname="Hannes Tschofenig"/>
and Rifaat Shekh-Yusef with Eric Rescorla, Benjamin Kaduk and Roman Dany and <contact fullname="Rifaat Shekh-Yusef"/> with <contact fullname="Eri
liw c
Rescorla"/>, <contact fullname="Benjamin Kaduk"/>, and <contact fullname=
"Roman Danyliw"/>
serving as Security Area Directors. Additionally, the following serving as Security Area Directors. Additionally, the following
individuals contributed ideas, feedback, and wording individuals contributed ideas, feedback, and wording
that helped shape this specification:</t> that helped shape this specification:</t>
<t> <t>
Vittorio Bertocci, <contact fullname="Vittorio Bertocci"/>,
Sergey Beryozkin, <contact fullname="Sergey Beryozkin"/>,
Roman Danyliw, <contact fullname="Roman Danyliw"/>,
William Denniss, <contact fullname="William Denniss"/>,
Vladimir Dzhuvinov, <contact fullname="Vladimir Dzhuvinov"/>,
George Fletcher, <contact fullname="George Fletcher"/>,
Dick Hardt, <contact fullname="Dick Hardt"/>,
Phil Hunt, <contact fullname="Phil Hunt"/>,
Michael Jones, <contact fullname="Michael Jones"/>,
Benjamin Kaduk, <contact fullname="Benjamin Kaduk"/>,
Barry Leiba, <contact fullname="Barry Leiba"/>,
Torsten Lodderstedt, <contact fullname="Torsten Lodderstedt"/>,
Anthony Nadalin, <contact fullname="Anthony Nadalin"/>,
Justin Richer, <contact fullname="Justin Richer"/>,
Adam Roach, <contact fullname="Adam Roach"/>,
Nat Sakimura, <contact fullname="Nat Sakimura"/>,
Rifaat Shekh-Yusef, <contact fullname="Rifaat Shekh-Yusef"/>,
Filip Skokan, <contact fullname="Filip Skokan"/>,
Eric Vyncke, <contact fullname="Éric Vyncke"/>,
and and
Hans Zandbelt. <contact fullname="Hans Zandbelt"/>.
</t>
</section>
<section anchor="History" title="Document History">
<?rfc subcompact="yes"?>
<t>
[[ to be removed by the RFC Editor before publication as an RFC ]]
</t>
<t>
draft-ietf-oauth-resource-indicators-08
<list style='symbols'>
<t>One last update from IESG evaluation comments (https://mailarchive.
ietf.org/arch/msg/oauth/x87EQ0Dwq3_ERrH5PzDjRSaWBt4).</t>
</list>
</t>
<t>
draft-ietf-oauth-resource-indicators-07
<list style='symbols'>
<t>One more update from IESG evaluation comments (https://mailarchive.
ietf.org/arch/msg/oauth/RS0UZSsguQurHl4P18Zo77BzZnU).</t>
</list>
</t>
<t>
draft-ietf-oauth-resource-indicators-06
<list style='symbols'>
<t>Expand JWT acronym on first use per Genart last call review.</t>
<t>Updates from IESG evaluation comments.</t>
</list>
</t>
<t>
draft-ietf-oauth-resource-indicators-05
<list style='symbols'>
<t>Remove specific mention of error_uri, which is rarely (if ever) use
d and seems to only confuse things for readers of extensions like this one.</t>
</list>
</t>
<t>
draft-ietf-oauth-resource-indicators-04
<list style='symbols'>
<t>Editorial updates from AD review that were overlooked in -03.</t>
</list>
</t>
<t>
draft-ietf-oauth-resource-indicators-03
<list style='symbols'>
<t>Editorial updates from AD review.</t>
<t>Update draft-ietf-oauth-jwsreq ref to -19.</t>
<t>Update the IANA requests to say they update the registries.</t>
</list>
</t>
<t>
draft-ietf-oauth-resource-indicators-02
<list style='symbols'>
<t>Clarify that the value of the "resource" parameter is a URI which c
an be an abstract identifier for the target resource and doesn't necessarily hav
e to correspond to a network addressable location.</t>
</list>
</t>
<t>
draft-ietf-oauth-resource-indicators-01
<list style='symbols'>
<t>Significant rework of the main section of the document attempting t
o clarify a number of things that came up at, around and after IETF 102 and the
call for adoption. </t>
<t>Change the "invalid_resource" error to "invalid_target" to align wi
th draft-ietf-oauth-token-exchange, which has some overlap in functionality.</t>
<t>Allow the "resource" parameter value to have a query component (ali
gning with draft-ietf-oauth-token-exchange).</t>
<t>Moved the Security Considerations section to before the IANA Consid
erations.</t>
<t>Other editorial updates.</t>
<t>Rework the Acknowledgements section.</t>
<t>Use RFC 8174 boilerplate.</t>
</list>
</t>
<t>
draft-ietf-oauth-resource-indicators-00
<list style='symbols'>
<t>
First version of the working group document. A replica of draft-camp
bell-oauth-resource-indicators-02.
</t>
</list>
</t>
<t>
draft-campbell-oauth-resource-indicators-02
<list style='symbols'>
<t>No changes.</t>
</list>
</t>
<t>
draft-campbell-oauth-resource-indicators-01
<list style='symbols'>
<t>
Move Hannes Tschofenig, who wrote https://tools.ietf.org/html/draft-
tschofenig-oauth-audience in '13, from Acknowledgements to Authors.
</t>
<t>
Added IANA Considerations to register the "resource" parameter and "
invalid_resource" error code.
</t>
</list>
</t>
<t>
draft-campbell-oauth-resource-indicators-00
<list style='symbols'>
<t>
Initial draft to define a resource parameter for OAuth 2.0.
</t>
</list>
</t> </t>
<?rfc subcompact="no"?>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 85 change blocks. 
515 lines changed or deleted 388 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/