<?xml version="1.0" encoding="us-ascii"?>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/rfc2629.xslt' ?> version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> "rfc2629-xhtml.ent">

<rfc number="8707" xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
     docName="draft-ietf-oauth-resource-indicators-08" ipr="trust200902"> ipr="trust200902"
     consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en"
     tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.32.0 -->

  <front>
    <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">
      <organization>Ping Identity</organization>
      <address><email>brian.d.campbell@gmail.com</email></address>
      <address>
        <email>brian.d.campbell@gmail.com</email>
      </address>
    </author>
    <author fullname="John Bradley" initials="J." surname="Bradley">
      <organization>Yubico</organization>
      <address><email>ve7jtb@ve7jtb.com</email></address>
      <address>
        <email>ve7jtb@ve7jtb.com</email>
      </address>
    </author>
    <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
      <organization>Arm Limited</organization>
      <address><email>hannes.tschofenig@gmx.net</email></address>
      <address>
        <email>hannes.tschofenig@gmx.net</email>
      </address>
    </author>
    <date month="February" year="2020" />
    <area>Security</area>

    <workgroup>OAuth Working Group</workgroup>
    <keyword>OAuth</keyword>
    <keyword>Resource</keyword>
    <keyword>Audience</keyword>

    <abstract>
      <t>
        This document specifies an extension to the OAuth 2.0
        Authorization Framework defining request parameters that enable a client
        to explicitly signal to an authorization server about the identity of the protected
        resource(s) to which it is requesting access.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="Introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
  Several years of deployment and implementation experience with the <xref target="RFC6749">OAuth OAuth 2.0
  Authorization Framework</xref> Framework <xref
  target="RFC6749" format="default"></xref>
  has uncovered a need, in need (in some circumstances circumstances, such as an authorization server
  servicing a significant number of diverse resources, resources) for the client to
  explicitly signal to the authorization server where it intends to use the
  access token it is requesting.
</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 construct the token
  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. Furthermore, various resources oftentimes have
  different requirements with respect to the data contained in, or in (or referenced by, by) the token token, and knowing the resource
  where the client intends to use the
  token allows the authorization server to mint the token accordingly.
</t>
      <t>
  Specific knowledge of the intended recipient(s) of the access token also helps facilitate improved
  security characteristics of the token itself.
  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 resources.
  To prevent misuse, several important security assumptions must hold, one of which is that
  an access token must only be valid for use at a
  specific protected resource and for a specific scope of access.
  Section 5.2 of
  <xref target="RFC6750"/>, target="RFC6750" sectionFormat="of" section="5.2"/>, for example,
  prescribes including the token's intended recipients within the token to prevent token redirect.
  When the authorization server is informed of
  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.
</t>
      <t>
  OAuth scope, from Section 3.3 of <xref target="RFC6749"/>, target="RFC6749" sectionFormat="of"
  section="3.3"/>, is sometimes overloaded to convey the location or identity
  of the protected resource, however, doing so isn't always feasible or
  desirable. Scope is typically about what access is being requested rather
  than where that access will be redeemed (e.g., <spanx style="verb">email</spanx>, <spanx style="verb">admin:org</spanx>, <spanx style="verb">user_photos</spanx>,
  <spanx style="verb">channels:read</spanx>, <tt>email</tt>,
  <tt>admin:org</tt>, <tt>user_photos</tt>, <tt>channels:read</tt>, and <spanx style="verb">channels:write</spanx>
  <tt>channels:write</tt> are a small sample of scope values in use in the
  wild that convey only the type of access and not the location or identity).
</t>
      <t>
  In some circumstances and for some deployments, a means for the client to signal to the authorization server where it
  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
  toward that end.
  Going forward, this specification aspires to provide a standardized and interoperable alternative to the proprietary approaches.
</t>
      <section anchor="RNC" title="Requirements numbered="true" toc="default">
        <name>Requirements Notation and Conventions"> Conventions</name>

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in
  BCP 14 BCP&nbsp;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"> 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 <xref target="RFC6749">The The OAuth 2.0 Authorization Framework</xref>. Framework <xref
        target="RFC6749" format="default"></xref>.
        </t>
      </section>
    </section>
    <section anchor="ResourceParameter" title="Resource Parameter"> numbered="true" toc="default">
      <name>Resource Parameter</name>
      <t>
        In requests to the authorization server, a client MAY <bcp14>MAY</bcp14>
        indicate the protected resource (a.k.a. resource server, application,
        API, etc.) to which it is requesting access by including the following
        parameter in the request.

      <list style="hanging">

      <t hangText="resource">
        <vspace/>

      </t>
      <dl newline="true" spacing="normal">
        <dt>resource</dt>
        <dd>
        Indicates the target service or resource to which access is being
        requested.  Its value MUST <bcp14>MUST</bcp14> be an absolute URI, as
        specified by
        Section 4.3 of <xref target="RFC3986"/>. target="RFC3986" sectionFormat="of"
        section="4.3"/>.  The URI MUST NOT <bcp14>MUST NOT</bcp14> include a fragment
        component. It SHOULD NOT <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 parameter(s) parameters are used to scope requests to an application.
        The <spanx style="verb">resource</spanx> <tt>resource</tt> parameter URI value is an identifier
        representing the identity of the resource, which MAY <bcp14>MAY</bcp14> be
        a locator that corresponds to a network addressable network-addressable location where the
        target resource is hosted.  Multiple
        <spanx style="verb">resource</spanx> <tt>resource</tt> parameters MAY
        <bcp14>MAY</bcp14> be used to indicate that the requested token is
        intended to be used at multiple resources.
      </t>
      </list>
      </dd>
      </dl>
      <t>

        The parameter value identifies a resource to which the client is
        requesting access.  The parameter can carry the location of a
        protected resource, typically as an https URL, URL or a more abstract
        identifier.  This enables the authorization server to apply policy as
        appropriate for the resource, such as determining the type and content
        of tokens to be issued, if and how tokens are encrypted, and applying
        appropriate audience restrictions.
      </t>
      <t>
        The client SHOULD <bcp14>SHOULD</bcp14> provide the most specific URI that it
	can for the complete API or set of resources it intends to access.
        In practice practice, a client will know a base URI for the application or resource that it interacts with, which
        is appropriate to use as the value of the <spanx style="verb">resource</spanx> <tt>resource</tt> parameter.
        The client SHOULD <bcp14>SHOULD</bcp14> use the base URI of the API as the <spanx style="verb">resource</spanx> <tt>resource</tt> parameter
        value unless specific knowledge of the resource dictates otherwise.
        For example, the value <spanx style="verb">https://api.example.com/</spanx> <tt>https://api.example.com/</tt> would be used
        for a resource that is the exclusive application on that host, host; however,
        if the resource is one of many applications on that host, something like
        <spanx style="verb">https://api.example.com/app/</spanx>
        <tt>https://api.example.com/app/</tt> would be used as a more specific
	value.

   Another example, for example is when an API like <xref target="RFC7644">SCIM</xref> that has multiple endpoints, e.g., when
   System for Cross-domain Identity Management (SCIM) <xref target="RFC7644" format="default"></xref> has
   endpoints such as
        <spanx style="verb">https://apps.example.com/scim/Users</spanx>,
        <spanx style="verb">https://apps.example.com/scim/Groups</spanx>, <tt>https://apps.example.com/scim/Users</tt>,
   <tt>https://apps.example.com/scim/Groups</tt>, and
        <spanx style="verb">https://apps.example.com/scim/Schemas</spanx>
   <tt>https://apps.example.com/scim/Schemas</tt>.  The client would use <spanx style="verb">https://apps.example.com/scim/</spanx>
   <tt>https://apps.example.com/scim/</tt> as the resource so that the issued
   access token is valid for all the endpoints of the SCIM API.
      </t>
      <t>
        The following error code is provided for an authorization server to indicate 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
        it has requested an invalid combination of resource and scope.
        <list style="hanging">
          <t hangText="invalid_target">
            <vspace/>
      </t>
      <dl newline="true" spacing="normal">
        <dt>invalid_target</dt>
        <dd>
            The requested resource is invalid, missing, unknown, or malformed.
          </t>
        </list>
      </t>
          </dd>
      </dl>
      <t>
        The authorization server SHOULD <bcp14>SHOULD</bcp14> audience-restrict
        issued access tokens to the resource(s) indicated by the <spanx style="verb">resource</spanx>
        <tt>resource</tt> parameter. Audience restrictions can be
        communicated in <xref target="RFC7519">JSON JSON Web Tokens</xref> Tokens <xref target="RFC7519"
        format="default"></xref> with the <spanx style="verb">aud</spanx> <tt>aud</tt> claim and the top-level
        member of the same name provides the audience restriction information
        in a Token Introspection <xref target="RFC7662">Token Introspection</xref> target="RFC7662"
        format="default"></xref> response. The authorization server may use
        the exact <spanx style="verb">resource</spanx> <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>
      <section anchor="authz-req" title="Authorization Request"> numbered="true" toc="default">
        <name>Authorization Request</name>
        <t>
        When the <spanx style="verb">resource</spanx> <tt>resource</tt> parameter is used in an authorization
        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 endpoint
        via the implicit flow (Section 4.2 of <xref target="RFC6749">OAuth (<xref target="RFC6749" sectionFormat="of"
        section="4.2">OAuth 2.0</xref>), the requested resource is applicable
        to that access token. In the code flow (Section 4.1 of <xref target="RFC6749">OAuth (<xref
        target="RFC6749" sectionFormat="of" section="4.1">OAuth 2.0</xref>) where 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
        <xref target="I-D.ietf-oauth-jwsreq">JWT the JWT Secured Authorization Request</xref>, Request <xref target="I-D.ietf-oauth-jwsreq"
        format="default"></xref>, a single <spanx style="verb">resource</spanx>
        <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 <spanx style="verb">resource</spanx> <tt>resource</tt> parameter when requesting
        authorization, the authorization server MAY <bcp14>MAY</bcp14> process the
        request with no specific resource or by using a pre-defined predefined default
	resource value.
        Alternatively, the authorization server MAY <bcp14>MAY</bcp14> require clients to specify the resource(s) they intend to
        access and MAY <bcp14>MAY</bcp14> fail requests that omit the parameter with an <spanx style="verb">invalid_target</spanx> <tt>invalid_target</tt> error.
        The authorization server might use this data to inform the user about the resources the client
        is going to access on her their behalf, to apply policy (e.g., refuse the request due to unknown resources),
        and to determine the set of resources that can be used in subsequent
	access token requests.
        </t>
        <t>
        If the authorization server fails to parse the
        provided value(s) or does not consider the resource(s) acceptable, it should reject the request with
        an error response using the error code <spanx style="verb">invalid_target</spanx> <tt>invalid_target</tt> as the value of the
        <spanx style="verb">error</spanx>
        <tt>error</tt> parameter and can provide additional
        information regarding the reasons for the error using the
        <spanx style='verb'>error_description</spanx>.
        <tt>error_description</tt>.
        </t>
        <t>
        An example of an authorization request where the client tells the authorization server that it wants an access token for use at
        <spanx style="verb">https://api.example.com/app/</spanx>
        <tt>https://api.example.com/app/</tt> is shown in <xref target="authz-endpoint-example-token"/> target="authz-endpoint-example-token" format="default"/> below
        (extra line breaks and indentation are for display purposes only).

</t>
        <figure title="Implicit anchor="authz-endpoint-example-token">
          <name>Implicit Flow Authorization Request" anchor="authz-endpoint-example-token">
<artwork><![CDATA[ Request</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  GET /as/authorization.oauth2?response_type=token
     &client_id=example-client
     &state=XzZaJlcwYew1u0QBrRv_Gw
     &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
     &resource=https%3A%2F%2Fapi.example.com%2Fapp%2F HTTP/1.1
  Host: authorization-server.example.com
]]></artwork>
        </figure>
      </t>
        <t>
          Below in <xref target="authz-endpoint-example-code"/> target="authz-endpoint-example-code" format="default"/> is an example of an authorization request
          using the <spanx style="verb">code</spanx> <tt>code</tt> response type
          where the client is requesting access to the resource owner's contacts and calendar data at
          <spanx style="verb">https://cal.example.com/</spanx>
          <tt>https://cal.example.com/</tt> and <spanx style="verb">https://contacts.example.com/</spanx> <tt>https://contacts.example.com/</tt>
          (extra line breaks and indentation are for display purposes only).

        </t>
        <figure title="Code anchor="authz-endpoint-example-code">
          <name>Code Flow Authorization Request" anchor="authz-endpoint-example-code">
          <artwork><![CDATA[ Request</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  GET /as/authorization.oauth2?response_type=code
     &client_id=s6BhdRkqt3
     &state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI
     &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
     &scope=calendar%20contacts
     &resource=https%3A%2F%2Fcal.example.com%2F
     &resource=https%3A%2F%2Fcontacts.example.com%2F HTTP/1.1
  Host: authorization-server.example.com
]]></artwork>
        </figure>
        </t>
      </section>
      <section anchor="token-req" title="Access numbered="true" toc="default">
        <name>Access Token Request"> Request</name>
        <t>
      When the <spanx style="verb">resource</spanx> <tt>resource</tt> parameter is used on an access 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
      the requested access token.
        </t>
        <t>
      The resource value(s) that are is acceptable to an authorization server in fulfilling an access token request are is
      at its sole discretion based on local policy or configuration. In the case of a
      <spanx style="verb">refresh_token</spanx>
      <tt>refresh_token</tt> or <spanx style="verb">authorization_code</spanx> <tt>authorization_code</tt> grant type request, such policy may limit the acceptable resources
      to those that were originally granted by the resource owner
      or a subset thereof.

      In the <spanx style="verb">authorization_code</spanx> <tt>authorization_code</tt> case where the requested resources
      are a subset of the set of resources originally granted, the
      authorization server will issue an access token based on that subset of
      requested resources while resources, whereas any refresh token that is returned is bound to
      the full original grant.
        </t>
        <t>
      When requesting a token, the client can indicate the desired target
      service(s) where it intends to use that token by way of the
      <spanx style="verb">resource</spanx>
      <tt>resource</tt> parameter and can indicate the desired scope of the
      requested token using the <spanx style="verb">scope</spanx> <tt>scope</tt> parameter.  The semantics of
      such a request are that the client is asking for a token with the
      requested scope that is usable at all the requested target services.
      Effectively, the requested access rights of the token are the cartesian
      product of all the scopes at all the target services.  To the extent
      possible, when issuing access tokens, the authorization server should
      downscope the scope value associated with an access token to the value
      the respective resource is able to process and needs to know. (Here,
      "downscope" means give fewer permissions than originally authorized by
      the resource owner.) This
      further improves privacy as a list of scope values is an indication that
      the resource owner uses the multiple various services listed;
      downscoping a token to only that which is needed for a particular
      service can limit the extent to which such information is revealed
      across different services.  As specified in Section 5.1 of <xref target="RFC6749"/>, target="RFC6749"
      sectionFormat="of" section="5.1"/>, the authorization server must
      indicate the access token's effective scope to the client in the <spanx style="verb">scope</spanx>
      <tt>scope</tt> response parameter value when it differs from the scope
      requested by the client.
        </t>
        <t>
        Following from the code flow authorization request shown in <xref target="authz-endpoint-example-code"/>, target="authz-endpoint-example-code" format="default"/>,
        the below examples show an <spanx style="verb">authorization_code</spanx> <tt>authorization_code</tt> grant type access token request (<xref target="token-endpoint-example-ac"/>) target="token-endpoint-example-ac" format="default"/>)
        and response (<xref target="response-example-ac"/>) target="response-example-ac" format="default"/>) where the client tells the authorization server that
        it wants the access token for use at <spanx style="verb">https://cal.example.com/</spanx> <tt>https://cal.example.com/</tt>
        (extra line breaks and indentation are for display purposes only).

        </t>
        <figure title="Access Token Request" anchor="token-endpoint-example-ac">
          <artwork><![CDATA[
          <name>Access Token Request</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  POST /as/token.oauth2 HTTP/1.1
  Host: authorization-server.example.com
  Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ
  Content-Type: application/x-www-form-urlencoded

  grant_type=authorization_code
  &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
  &code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ
  &resource=https%3A%2F%2Fcal.example.com%2F]]></artwork>
        </figure>
        <figure title="Access Token Response" anchor="response-example-ac">
          <artwork><![CDATA[
          <name>Access Token Response</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
   HTTP/1.1 200 OK
   Content-Type: application/json
   Cache-Control: no-cache, no-store

   {
      "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi
       JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI
       iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgwMCwic2NvcGUiOiJjYWxlbmRhciIs
       ImF1ZCI6Imh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLyJ9.nNWJ2dXSxaDRdMUK
       lzs-cYIj8MDoM6Gy7pf_sKrLGsAFf1C2bDhB60DQfW1DZL5npdko1_Mmk5sUf
       zkiQNVpYw",
      "token_type":"Bearer",
      "expires_in":3600,
      "refresh_token":"4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2",
      "scope":"calendar"
   }]]></artwork>
        </figure>
      </t>
        <t>
      A subsequent access token request, using the refresh token, where the client tells the authorization server that
      it wants an access token for use at
      <spanx style="verb">https://contacts.example.com/</spanx>
      <tt>https://contacts.example.com/</tt> is shown in <xref target="token-endpoint-example-rt"/> target="token-endpoint-example-rt" format="default"/> below
      with the response shown in <xref target="response-example-rt"/> target="response-example-rt" format="default"/>
      (extra line breaks and indentation are for display purposes only).

</t>
        <figure title="Access Token Request" anchor="token-endpoint-example-rt">
<artwork><![CDATA[
          <name>Access Token Request</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  POST /as/token.oauth2 HTTP/1.1
  Host: authorization-server.example.com
  Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ
  Content-Type: application/x-www-form-urlencoded

  grant_type=refresh_token
  &refresh_token=4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2
  &resource=https%3A%2F%2Fcontacts.example.com%2F
]]></artwork>
        </figure>
        <figure title="Access Token Response" anchor="response-example-rt">
        <artwork><![CDATA[
          <name>Access Token Response</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
   HTTP/1.1 200 OK
   Content-Type: application/json
   Cache-Control: no-cache, no-store

   {
      "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi
       JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI
       iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgyNiwic2NvcGUiOiJjb250YWN0cyIs
       ImF1ZCI6Imh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20vIn0.5f4yhqazc
       OSlJw4y94KPeWNEFQqj2cfeO8x4hr3YbHtIl3nQXnBMw5wREY5O1YbZED-GfH
       UowfmtNaA5EikYAw",
      "token_type":"Bearer",
      "expires_in":3600,
      "scope":"contacts"
   }]]></artwork>
        </figure>
    </t>
      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
        An audience-restricted access token, token that is legitimately presented to a
        resource,
        resource cannot then be taken by that resource and presented elsewhere
        for illegitimate access to other resources.
        The <spanx style="verb">resource</spanx> <tt>resource</tt>
        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 apply the
        appropriate audience restrictions to the token.
      </t>
      <t>
        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 tenant,
        it is important to use a specific
        resource URI including any portion of the URI that identifies the
        tenant, such as a path component. This will allow access tokens to be audience-restricted in a way that identifies the tenant
        and prevent prevents their use, due to an invalid audience, at resources owned by a different tenant.
      </t>
      <t>
        Although multiple occurrences of the <spanx style="verb">resource</spanx> <tt>resource</tt> parameter
        may be included in a token request, using only a single <spanx style="verb">resource</spanx> <tt>resource</tt> parameter
        is encouraged. A

   If a bearer token that has multiple intended recipients (audiences) indicating that
   (audiences), then the token is valid at more than one
   protected resource and can be used by any one of those protected
   resources to access any of the other protected resources. others.

Thus, a high degree of trust between the involved parties
        is needed when using access tokens with multiple audiences. Furthermore Furthermore, an authorization server may
        be unwilling or unable to fulfill a token request with multiple resources.
      </t>
      <t>
        Whenever feasible, the <spanx style="verb">resource</spanx> <tt>resource</tt> parameter
        should correspond to the network addressable network-addressable location of the protected resource.
        This makes it possible for the client to validate that the resource being requested controls the corresponding
        network location, reducing the risk of malicious endpoints obtaining tokens meant for other resources.
        If the <spanx style="verb">resource</spanx> <tt>resource</tt> parameter contains an abstract identifier, it is the client's
        responsibility to validate out of band that any network endpoint to which tokens are sent are the intended audience for that identifier.
      </t>
    </section>
    <section anchor="Privacy" title="Privacy Considerations"> numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>
        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 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.
      </t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section title="OAuth numbered="true" toc="default">
        <name>OAuth Parameters Registration"> Registration</name>
        <t>
          This specification updates the following value
          in the IANA "OAuth Parameters" registry
          <xref target="IANA.OAuth.Parameters"/> target="IANA.OAuth.Parameters" format="default"/>
          established by <xref target="RFC6749"/>. target="RFC6749" format="default"/>.
        </t>
        <t>
          <?rfc subcompact="yes"?>
          <list style='symbols'>
            <t>Parameter name: resource</t>
            <t>Parameter
        <dl spacing="compact">
          <dt>Parameter name:</dt> <dd>resource</dd>
          <dt>Parameter usage location: authorization location:</dt> <dd>authorization request, token request</t>
            <t>Change controller: IESG</t>
            <t>Specification document(s): [[ this specification ]]</t>
          </list>
        </t> request</dd>
          <dt>Change controller:</dt> <dd>IESG</dd>
          <dt>Specification document(s):</dt> <dd>RFC 8707</dd>
        </dl>
      </section>
      <section title="OAuth numbered="true" toc="default">
        <name>OAuth Extensions Error Registration"> Registration</name>
        <t>
          This specification updates the following error in
          the IANA "OAuth Extensions Error Registry"
          <xref target="IANA.OAuth.Parameters"/> target="IANA.OAuth.Parameters" format="default"/>
          established by <xref target="RFC6749"/>. target="RFC6749" format="default"/>.
        </t>
        <t>
          <?rfc subcompact="yes"?>
          <list style='symbols'>
            <t>Error name: invalid_target</t>
            <t>Error
        <dl spacing="compact">
          <dt>Error name:</dt> <dd>invalid_target</dd>
          <dt>Error usage location: implicit location:</dt> <dd>implicit grant error response, token error response</t>
            <t>Related response</dd>
          <dt>Related protocol extension: resource parameter</t>
            <t>Change controller: IESG</t>
            <t>Specification document(s): [[ this specification ]]</t>
          </list>
        </t> 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>
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml' ?>

<displayreference target="I-D.ietf-oauth-jwsreq" to="JWT-SAR"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

        <reference anchor="IANA.OAuth.Parameters" target="http://www.iana.org/assignments/oauth-parameters"> target="https://www.iana.org/assignments/oauth-parameters">
          <front>
            <title>OAuth Parameters</title>
            <author>
              <organization>IANA</organization>
            </author>
          <date/>
          </front>
        </reference>
      </references>

    <references title="Informative References">
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7662.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6750.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7644.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-oauth-jwsreq-19.xml'?>

      <references>
        <name>Informative References</name>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7662.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6750.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7644.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-jwsreq.xml"/>
      </references>
    </references>
    <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
        This specification was developed within the OAuth Working Group
        under the chairmanship of Hannes Tschofenig <contact fullname="Hannes Tschofenig"/>
        and Rifaat Shekh-Yusef <contact fullname="Rifaat Shekh-Yusef"/> with Eric Rescorla, Benjamin Kaduk and Roman Danyliw <contact fullname="Eric
	Rescorla"/>, <contact fullname="Benjamin Kaduk"/>, and <contact fullname="Roman Danyliw"/>
        serving as Security Area Directors.  Additionally, the following
        individuals contributed ideas, feedback, and wording
        that helped shape this specification:</t>
      <t>
        Vittorio Bertocci,
        Sergey Beryozkin,
        Roman Danyliw,
        William Denniss,
        Vladimir Dzhuvinov,
        George Fletcher,
        Dick Hardt,
        Phil Hunt,
        Michael Jones,
        Benjamin Kaduk,
        Barry Leiba,
        Torsten Lodderstedt,
        Anthony Nadalin,
        Justin Richer,
        Adam Roach,
        Nat Sakimura,
        Rifaat Shekh-Yusef,
        Filip Skokan,
        Eric Vyncke,
        and
        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) used 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 can be an abstract identifier for the target resource and doesn't necessarily have 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 to 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 with draft-ietf-oauth-token-exchange, which has some overlap in functionality.</t>
          <t>Allow the "resource" parameter value to have a query component (aligning with draft-ietf-oauth-token-exchange).</t>
          <t>Moved the Security Considerations section to before the IANA Considerations.</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-campbell-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>
        <contact fullname="Vittorio Bertocci"/>,
        <contact fullname="Sergey Beryozkin"/>,
        <contact fullname="Roman Danyliw"/>,
        <contact fullname="William Denniss"/>,
        <contact fullname="Vladimir Dzhuvinov"/>,
        <contact fullname="George Fletcher"/>,
        <contact fullname="Dick Hardt"/>,
        <contact fullname="Phil Hunt"/>,
        <contact fullname="Michael Jones"/>,
        <contact fullname="Benjamin Kaduk"/>,
        <contact fullname="Barry Leiba"/>,
        <contact fullname="Torsten Lodderstedt"/>,
        <contact fullname="Anthony Nadalin"/>,
        <contact fullname="Justin Richer"/>,
        <contact fullname="Adam Roach"/>,
        <contact fullname="Nat Sakimura"/>,
        <contact fullname="Rifaat Shekh-Yusef"/>,
        <contact fullname="Filip Skokan"/>,
        <contact fullname="Éric Vyncke"/>,
        and
        <contact fullname="Hans Zandbelt"/>.
      </t>
      <?rfc subcompact="no"?>
    </section>
  </back>
</rfc>