<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.30 (Ruby 3.4.8) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-skokan-oauth-resource-response-00" category="std" consensus="true" submissionType="IETF" updates="8707" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->
  <front>
    <title abbrev="OAuth Resource Response">Resource Indicator Response Parameter for OAuth 2.0</title>
    <seriesInfo name="Internet-Draft" value="draft-skokan-oauth-resource-response-00"/>
    <author fullname="Filip Skokan">
      <organization>Okta</organization>
      <address>
        <email>panva.ip@gmail.com</email>
      </address>
    </author>
    <date year="2026" month="March" day="01"/>
    <area>Security</area>
    <workgroup>Web Authorization Protocol</workgroup>
    <keyword>OAuth</keyword>
    <keyword>Resource</keyword>
    <keyword>Audience</keyword>
    <abstract>
      <?line 46?>

<t>This document defines the <tt>resource</tt> parameter for OAuth 2.0 access
token responses, enabling an authorization server to indicate to the
client the resource(s) which an issued access token is for. It updates
"Resource Indicators for OAuth 2.0" (RFC 8707).</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://panva.github.io/draft-oauth-rfc8707bis/draft-skokan-oauth-resource-response.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-skokan-oauth-resource-response/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Web Authorization Protocol Working Group mailing list (<eref target="mailto:oauth@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/oauth/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/oauth/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/panva/draft-oauth-rfc8707bis"/>.</t>
    </note>
  </front>
  <middle>
    <?line 54?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>"Resource Indicators for OAuth 2.0" <xref target="RFC8707"/> defines the <tt>resource</tt>
request parameter for use in authorization requests and access token
requests, enabling a client to signal the target protected resource(s)
to an authorization server. However, it does not define a corresponding
response parameter that would allow the authorization server to
communicate back to the client which resource(s) the issued access token
is actually for.</t>
      <t>Without a response parameter, a client cannot reliably determine the
effective resource(s) of an issued access token when the authorization
server restricts the token to a subset of the requested resources, or
when it applies a default resource policy in cases where the client did
not include the <tt>resource</tt> parameter in its request.</t>
      <t>This document addresses that gap by defining the <tt>resource</tt> parameter
for use in access token responses.</t>
      <section anchor="requirements-notation-and-conventions">
        <name>Requirements Notation and Conventions</name>
        <t>The key words "<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 "<bcp14>OPTIONAL</bcp14>" 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>
        <?line -18?>

</section>
    </section>
    <section anchor="ResourceResponseParameter">
      <name>Access Token Response Resource Parameter</name>
      <t>In access token responses, the <tt>resource</tt> parameter is represented as a
JSON array of strings, unlike the repeated form-encoded or query
parameter used in requests defined in <xref target="RFC8707"/>.</t>
      <t>The <tt>resource</tt> parameter defined for an access token response
(<xref section="5.1" sectionFormat="of" target="RFC6749"/>) is used to indicate to the client the
resource(s) which an issued access token is for.</t>
      <dl>
        <dt>resource:</dt>
        <dd>
          <t><bcp14>OPTIONAL</bcp14>, if identical to the <tt>resource</tt> value(s) requested by the
client; otherwise, <bcp14>REQUIRED</bcp14>. Its value is a JSON array of strings,
where each string is an absolute URI as specified by
<xref section="4.3" sectionFormat="of" target="RFC3986"/>, identifying a protected resource for
which the access token is valid. The array <bcp14>MUST</bcp14> contain at least
one value.</t>
        </dd>
      </dl>
      <t>The <tt>resource</tt> response parameter serves a similar role to the <tt>scope</tt>
response parameter defined in <xref section="5.1" sectionFormat="of" target="RFC6749"/>: it informs the
client when the resource(s) associated with the issued access token
differ from what the client requested. This can occur when the
authorization server restricts the token to a subset of the requested
resources, or when the authorization server applies a default resource
policy in cases where the client did not include the <tt>resource</tt> parameter
in its request.</t>
      <t>If the client requested access to multiple resources but the
authorization server issues an access token that is restricted to a
subset of those resources, the authorization server <bcp14>MUST</bcp14> include the
<tt>resource</tt> parameter in the response to inform the client of the
effective resource(s). The client can then make additional token requests
for the remaining resources as needed.</t>
      <t>The following is a non-normative example of a token endpoint response
where the authorization server indicates that the issued access token is
valid for use at <tt>https://cal.example.com/</tt> (extra line breaks and
indentation are for display purposes only).</t>
      <figure anchor="response-example-resource">
        <name>Access Token Response with Resource</name>
        <artwork><![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",
   "resource":["https://cal.example.com/"]
}
]]></artwork>
      </figure>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document inherits the security considerations of <xref target="RFC8707"/>.</t>
      <t>Knowledge of the resource(s) for which an access token is valid does not
introduce new security concerns for the client. The <tt>resource</tt> response
parameter merely makes explicit information that the client either
already requested or that the authorization server determined based on
its policy.</t>
    </section>
    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
      <t>The <tt>resource</tt> response parameter conveys information about the
resource(s) associated with an access token back to the client. Since
the client either requested these resources or they were determined by
authorization server policy, no new privacy-sensitive information is
disclosed by this parameter.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="oauth-parameters-registration">
        <name>OAuth Parameters Registration</name>
        <t>This specification updates the following value in the IANA "OAuth
Parameters" registry <xref target="IANA.OAuth.Parameters"/> established by
<xref target="RFC6749"/>.</t>
        <dl spacing="compact">
          <dt>Parameter name:</dt>
          <dd>
            <t>resource</t>
          </dd>
          <dt>Parameter usage location:</dt>
          <dd>
            <t>authorization request, token request, token response</t>
          </dd>
          <dt>Change controller:</dt>
          <dd>
            <t>IETF</t>
          </dd>
          <dt>Specification document(s):</dt>
          <dd>
            <t><xref section="2" sectionFormat="of" target="RFC8707"/> and <xref target="ResourceResponseParameter"/> of this
document</t>
          </dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="RFC3986">
        <front>
          <title>Uniform Resource Identifier (URI): Generic Syntax</title>
          <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
          <author fullname="R. Fielding" initials="R." surname="Fielding"/>
          <author fullname="L. Masinter" initials="L." surname="Masinter"/>
          <date month="January" year="2005"/>
          <abstract>
            <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="66"/>
        <seriesInfo name="RFC" value="3986"/>
        <seriesInfo name="DOI" value="10.17487/RFC3986"/>
      </reference>
      <reference anchor="RFC6749">
        <front>
          <title>The OAuth 2.0 Authorization Framework</title>
          <author fullname="D. Hardt" initials="D." role="editor" surname="Hardt"/>
          <date month="October" year="2012"/>
          <abstract>
            <t>The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6749"/>
        <seriesInfo name="DOI" value="10.17487/RFC6749"/>
      </reference>
      <reference anchor="RFC8707">
        <front>
          <title>Resource Indicators for OAuth 2.0</title>
          <author fullname="B. Campbell" initials="B." surname="Campbell"/>
          <author fullname="J. Bradley" initials="J." surname="Bradley"/>
          <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
          <date month="February" year="2020"/>
          <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>
        <seriesInfo name="RFC" value="8707"/>
        <seriesInfo name="DOI" value="10.17487/RFC8707"/>
      </reference>
      <reference anchor="IANA.OAuth.Parameters" target="https://www.iana.org/assignments/oauth-parameters">
        <front>
          <title>OAuth Parameters</title>
          <author>
            <organization>IANA</organization>
          </author>
          <date/>
        </front>
      </reference>
      <reference anchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
    </references>
    <?line 198?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>The original "Resource Indicators for OAuth 2.0" specification
<xref target="RFC8707"/> was authored by Brian Campbell, John Bradley, and Hannes
Tschofenig.</t>
    </section>
    <section numbered="false" anchor="document-history">
      <name>Document History</name>
      <t>draft-skokan-oauth-resource-response-00</t>
      <ul spacing="normal">
        <li>
          <t>Initial draft defining the <tt>resource</tt> access token response parameter</t>
        </li>
      </ul>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA5VZ7VbbSBL930/R6/zJ7MHGdggB73yBCWACOOFjgMyZk7Sk
tt2xrNaoJRzDYZ5ln2WfbG91S7KM7V0mP4jU6q6uulV1q7pdr9dZqtJQdnjt
QhqdJb7kvShQvkh1wjEU68hI/lEkYiJTmfABhvt7WTri7UazxoTnJfIeq91Y
KaNYWWOQJIc6mXW4SQPGAu1HENXhQSIGad2M9VhEdS2wup7kq+nBrq43myyL
A0gwHb7zrvmOmcybKGOUjtJZDCm991eHLMomnkw6jCZ2mE8rI5NhSZpkkkG7
N0wkUkDLS+lniUpnNTbVyXiY6CzG6I30OKmvE/UgUsjmHxOdal+HNTaWM0wN
OozXnd30UJhJz3tZoGSE53sZZdie85eI5dzpX7uBHioa8iNaROMToUKMW0R+
VTIdNHQypA8i8Uf4MErT2HQ2N2keDal72SimbdLAppfoqZGbVsImrRyqdJR5
WBuL6F5sOuRzyAc+4eopQxNDQjqtbGIXNNz6htJrlm6+xJeNUTqB4UxYRAhP
bMj5IAtDFxCHKlQxv7RC7CcYJKIcug7vj1Nhh6VDyKmm4l+H9N7w9YSxSCcT
TL+3brg47L7Z3dnOH7ffbe3mj6Q1Pfb2zvca1qeNMr5Nx+5R5ISL6vnXmvsq
kqEETAVK0+m0oUQknAsQncNoIqPUOBfU43K5XV0CYP/VycyO1cWO2BjmAxEa
yVij0WCsXq9z4Zk0EX7K2NVIGY4kymgHHsiBiqTh6UjyrwXkX3m8Ol258H1p
DEv1WEa8cIzZ4DISXkhRKKJcvSJijUzuISbVXDlWkPSM7ZgfKtKAdi42fm1+
4NOR8kckB1maySDfkrstoToUavBeyvO0ZitoxzwjGf4aTrPp/wPgsHhMVBCE
AOgVVqWJDjKftGUvkvb4mMfA09Ma/Fgi/8yQCM9wzECE6jlA+VQDkxeNLYQs
wMsL1DSnKBGh3dnFE4/BDtJPAVoFUDhrnVca/FhPJR42uEIoaNgR6SImaC+d
OB8H2JsV7q4YlY5Eyqc6C6F5GOqpVWaN/0Grk0kWuRDwhD/O46CwyPm9Ggn0
cUUQMAQBIjnDjjMbDYzdgF90lkLlZSU35qD5IiL7Ehkq4DmDofg+IVspHuVg
APCQ+wtK6MG6WJyO8GfJYJYbDBlpovzUhYZbQZ7gKEAGvoJcF/nWxxWXwd06
YVY4nCLiGLrDYPKKyMK0nMdjHSp/RgHlCyQh6ZPIKqKBChjZqyI/zAK5PscV
bWUKXRrPOUIEAVYZG+Xw91DE3Ju5KKGYXCeWVUO+ClzJG9jp1SvUwj8zlUhL
ePxcpy5uKBu6OkJNpFdDOkmOWsqpmBpeO7u+vKptuP/5ed8+X7z/dN27eH9A
z5fHe6en5QPLZ1we969PD+ZP85Xd/tnZ+/MDtxijfGGI1c727vCFtKr1P171
+ud7pzWyLF2EKrH05pHRgCBOJLlWGBZI4yfKwwvW7Hc//uffrS0QyT/AJO1W
axdM4l52Wu+28ELud7vpCIHqXgH0jCEgpLAuQ/zD87FKQfWYa7gZ6WnEKQoA
7D9/J2T+6PAfPT9ubf2cD5DBC4MFZguDFrPlkaXFDsQVQyu2KdFcGH+G9KK+
e3cL7wXulcEffwkpfeutnV9+ZsTmey7Qrmygld1nSerzNvTxVTFYzCq/PTHW
WxeyG/8jiyiD4HH0js7pXLCTy/45giIRM0p4YoRoCBlZFKqxzAkA/qT5yJZJ
HX2gDvCCzEEuJjM2F49MssFT1gtH03asUpEaLlNWalisoMQUayxkrx8fL6Wt
hvxto0Vq583P09MPZKPVY7mc83k5Z3+3nLNyRYehT8vdjKI04CogAvCpzunn
0N+LMLN7zEkUvEQK8Fybf3GN12SqjNzgRaRT92DcYlJA8NVOghDHqFLAADdq
50fUTOkwg+nXFz2beLH01UDZ/bFsDuBW400OIDWST08buT2DmSvmywWb8LA7
E2q2uDzDC3qroMHJx05lm9U4sqSCOCHloRQmhQiNvLBGLkfEikpuqxaBYdSE
jgU80WHp2q/G17HtapbWLQThurjpUCVTEUW4qbZ+ZQWtBgzaX+0rmxJTlPW1
XUCgUK/RVyV6AkEirQZhGRAEFEBD4efax8mt3JKt7FL+btFmC0V7TUdQCF9f
ytlLSjl/SSlnS6W8N1gJzBxLPoEqKg7nXjDcy9L1IFlnmCUCsb2B5UCHoWMJ
warQaSOrfc5aqGxMV2xl69qWPHhcVFpSoiCrWuxctrq5c2k0bw5pZoTzM6gZ
PY8ijSzxOH50tGu7Grctjo22AZrjBi6IpASB5zk30NQVF8QBD0b18oTJ5Xcx
Idipw8w3kVEQa2X9lLPxPBJW+yIn4bw1W5MrGGOWN8pTCOZ+LQ6fINdGrgsd
gje/8tfyOw6L3JZWL5FibA8niC0ir7w9SyxVITBNHIKF4iyJNYUu9St0yvrr
r7/Y8dXVx80WyKDdbPL+B4Z+LoWE+pW9ubD54Ftxm98MOucuiFbWaRLIpwO0
6j6NbNCTwUEMx7VHOuLWnG1frG21Tk3OTkbeka/66uTw+qHXOlc905uk8edu
b7v3zX/Ti5oNzIn9N2eYYw/JJzo4vpj21c793e1vTXG0OxO38Sg4Cu891Xr4
fHvS/nzbyz7fjkbe7b75fPn2m9duqtPuyUNw07MSaLfBbftkcDej3X7b8rHb
2dX1Vv/g0+zsYDg9606V3z6/94+uae63u5vvoTe5GPnQzkroTQ5bVsXJqBkc
7z9YbdqH5hTC7m5aU+/oOrtr76ans5PdRnR+c9IObi+/i4OL4Oz6g5UQPpi6
f9f7tnN2oM+2j2bv4sEX8yE5PTJ7h4NWt+0djPa3mwefBjetg8+nb6M4GOvW
l7PJ+K25HlgJD2P16fy3+G5a27DIWki/0M0ScN1HoymT/Iv8HqNJN18UEH+z
3Wy60UQOMDgqXbF1etXdCb0mPLTdn22h6W2dj3f3b7pNNdmbHr8bK7+1vX/Q
bedSbWHBOsQgYl8UmxUZVev8XlsXprU/2JONsscOf1Xe9+UzytsjdxHzU211
X2gLTNEH1p6ogSwu+OjwYVCtE1GeP6qNvoqQmCovFKZY4y+socxe7Mw+RHoa
ymAo55VkXvgGtoLk3dLKsl8e0ZGK7tJCgm+mC/v7MoncjcWcBB3PrWgAKu3l
BDyDkwaRnwE1UWqWRdulfPqsyEpFvRUTIRgimFVKi07mc1eyVnnuRsMkqJ1E
8hOWrgzSqZB/TNS98Fd54f91Mj4dGmdmQXXh6Wy5NX3eaTyHffmSosEvFd3U
LqFQsR6v1Srn0KBzKxF51fLZ6vLqQCDSs76NHRB1upFWtm5UDQOxg4H9UJui
+UWslFhYJOlicAlGHLuf30wiD4aKLgndRZgN97yxdSRd3LhZPOaVLW+kXS22
m7lLT1a59AQcVvYM+bDy0hRHXqBHl1xm5LCxiePaR5jx2EHKx8JPn+Ziub31
xYGhbKMq3zIjkGWhdqrTrJW3bhuL1X3j+WGIdUcigiDfFaWQfiTIfzNglwvg
FMyAwKIp82a4nbfC+YUhnelh29qz55OjBkU1opCZ31lSPLoz7jjnEXtnAnDc
7xcy+Klm732JyShRYO5QUQvzklvNBV+z6h3nlI6yFj0XZPuJQqp0QbSeDMMN
FNNRhEERhHLmLi2ORRRJw66MP9IDGamhjcSDgjyPFZXz2WrFX/qzDqvDGGQE
zLNL1l5IrTzmVlrm/wI1y7SxwxoAAA==

-->

</rfc>
