<?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-01" 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-01"/>
    <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>[[TODO: Should the response use <tt>resource</tt> (a JSON string) when a
single resource is indicated and <tt>resources</tt> (a JSON array of strings)
when multiple are indicated instead?]]</t>
      <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 202?>

<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:
H4sIAAAAAAAAA5VZ61bbOhb+r6fQhD/trCQkgXLJnHN6ICkQSgjlUqCX1cq2
EqtxLB/JJjUs+izzLPNks7dkO85thtMf1Jalrb2/ffuk1Go1Eos44G1aueRa
JsrltBd6wmWxVBSGIhlqTi+YYhMec0WHMDw4SGKftuqNCmGOo/gDrLZjhYx8
ZYWAJD6SKm1THXuEeNINQVSbeooN45oeyzELa5LB6prKVuODWV1rNEkSeSBB
t+nebmOX6MSZCK2FDOM0Aim9d9dHJEwmDldtghPbxMWVoU5gSawSTkC7LcIU
Z6DlFXcTJeK0QqZSjUdKJhGM3nKHovpSiUcWg2x6oWQsXRlUyJinMNVrE1qz
duNDbiY+HySe4CE8P/Awge0pfYlYSq3+lVvQQ4QjeoyLcHzCRADjBpE/BY+H
dalG+IEp14cPfhxHur25ifNwSDzwej5tEwc2HSWnmm8aCZu4ciRiP3FgbcTC
B7Zpkc8gH7qIqyM0TgwQ6bi0iVlQt+vrQq5ZuvkSX9b9eAKGE2YQQTxhQ0qH
SRDYgDgSgYjolRFiPoFBLMyga9PBOGZmmFuErGoi+nOE73VXTggJpZrA9Afj
hsujztb+3k72uLO7vZ89otb42Ds4P6gbn9aL+NZts0eeEzaqZ18r9itTIw4w
5ShNp9O6YCGzLoDoHIUTHsbauqAWFcvN6gIA86+GZraNLmbExDAdskBzQur1
OiG1Wo0yR8eKuTEh177QFJIowR2ox4ci5JrGPqffc8i/02h1ulLmulxrEssx
D2nuGF2lPGROgFHIwky9PGI1Vw8gJpZU2KrA8Rm2I24gUAPcOd/4lX5Np75w
fZQDWZpwL9uS2i1BdVCoTnsxzdKarCg7eqHI0FfgNJP+rwEOg8dEeF4AAG3A
qlhJL3FRW/IiaU9PWQw8P6/Bjyj+VwKJsIBjAoVQLAKUTdVg8ryxuZA5eGmO
mqQYJSwwO9t4ohFUB+7GAFoJUHDWOq/U6YmccnioUgGhIMGOUOYxgXtJZX3s
wd4kd3fJqNhnMZ3KJADNg0BOjTJr/A9ldTJJQhsCDnPHWRzkFlm/lyMBP64I
AgJBAJGcwI6piQZCbqG+yCQGlZeVrM5Ac1mI9ikeCMAzBUPh+wRtxXjkwyGA
B7k/p4QcrovFqQ9/lgwmmcEgI1bCjW1o2BXoCQoNSIOvQK6NfOPjksvA3VIR
IxycwqIIdAeD0SssCeJiHo1kINwUA8plkISoj+JlRD3hEbRXhG6QeHx9jgvc
Sue61BdrBPM8WKVNlIO/RyyiTmqjBGNynVhSDvkycEXdgJ02NqAX/pUIxU3B
o+cytnGD2dCRIfREfNWoE6fQSyk2U00r/Zur60rV/k/PB+b58t2Hm97luy4+
X50cnJ0VDySbcXUyuDnrzp5mKzuDfv/dedcuhlE6N0Qq/YN7+IJaVQYX173B
+cFZBS2L56FSprw5aDRAECmOrmWaeFy7SjjwAmsOOxf/+XdzGwrJP6CStJrN
fagk9mWvubsNL+h+u5sMIVDtKwCdEggIzozLIP7B85GIodTDXE21L6chxSgA
YP/5GZH52qa/OW7U3P4jG0CD5wZzzOYGDWbLI0uLLYgrhlZsU6A5N76A9Ly+
B/dz7znupcHf3gaYvrXm3ts/CFbzAxto1ybQCvZZFPUZDX3ayAfzWcW3Z0J6
60K2+j+yCDMIPA7c0TqdMnJ6NTiHoFAsxYTHihCOQEYSBmLMswIA/sT5kC2T
GvBA6cELZA7kokrJTDxkkgmeol/YMm3GSh2pbjNlpYb5CkxMtsZC8urp6Yqb
bkjf1JuodkZ+np9fo41Gj+V2TmftnPzddk6KFW0CPC1zMzSlIRUeFgAX+5xc
hP6BBYnZY1ZEoS6hAjTT5l9UwquaCs2rNI90ZA/aLkYFGF3tJBBiKypnYIAd
NfNDJFMySMD0m8ueSbyIu2IozP6wbAbgdn0rAxCJ5PNzNbNnmNpmvtywEQ+z
M6JmmssCXqC38OoUfWxVNlkNR5aYYU2IacCZjkGEhLwwRgK8Xz5/+Xw96A7a
9Mo33TojXTY7sEaXYH2VIWJNfm37HCMaXoJZb0Rd8hDwTKUqROiZjEVUX9vG
NoFGJqKAm3o5kyJCcCLz3n75+uXrUhivoB+m1aIHtZjgWYYqGRTx+F27MjJU
bGndXOasC/Y2tl8RYlrqMl8t2n45yoGzS1cYI6bARdZSF08AyQAyqOQEBLG4
nDlFFKN3AV1gK1S6cNwstiQrqdXfZRpkjmmsoTG58PX8g7yEf9CX8A+yxD96
w5XAzLCcRVBhDHWSeD1Ixhl6qeoZQmMKt8XQljZGytBJzcvkbC1UJhFLtpJ1
XGsu+UwlxSArW2xdtpqR2tyfMVqcCRnFoJ8AUROokamWtqjbXmGomN0WzrqG
tc1wgwIWcg5dJ2sdQ4lUPq924MGwVhyLKf/JJgg70uJsEx56kRTGT1kLmUXC
al9kCZ/xyTW5AmPEFLvi6ARzv+cnZugI9UwXPLlvQsnhP+GESw0fcBRnY3Oi
gtjCiptxSmXqKwSmjgKoS1GiIomhiyQLj4a/fv0iJ9fXF5tNKAatRoMO3hMg
oTFIqF2b6xaTD64Rt/lDA93vQHfgNZwExacNaNVcHKnik4bTI5wxn/BcXrG2
fTO2VdoVnp76zrErBuL06Oax1zwXPd2bxNGnTm+n98Pd6oWNOsyJ3K0+zDEn
+1PpnVxOB2Lv4f7uY4Md76fsLvK94+DBEc3HT3enrU93veTTne87d4f609Wb
H06rIc46p4/ebc9IwN2Gd63T4X2Ku33cdmG3/vXN9qD7Ie13R9N+Zyrc1vmD
e3yDc3/c3/4MnMml74J2RkJvctQ0Kk78hndy+Gi0aR3pMxB2f9ucOsc3yX1r
Pz5LT/fr4fntacu7u/rJupde/+a9kRA86pp73/ux1+/K/s5xuhsNv+n36uxY
HxwNm52W0/UPdxrdD8PbZvfT2Zsw8say+a0/Gb/RN0Mj4XEsPpx/jO6nlapB
1kD6Da/DANdDYMdcZV/4zwhOFvqbAMS3dhoNO6r4EAb9whXbZ9edvcBpgId2
Buk2MPXm+Xj/8LbTEJOD6cnuWLjNncNup5VJNY0F1kEMQuyzfLM8oyrtz5V1
YVr5Sp5NlD216UZxSZnNKK687O3R75XVZNY0mJy8Vp6R9ea3knhi0kAxFCsO
TeXTiQghMUXWKHS+xp1bg5k9Tyffh3IacG/EZ51k1viGpoNkFG8lVynuFSAV
7U0Lh3ozndvf5Sq01yyzImjr3AoCUOLEE6gzcDzC4qehNGFqFk3bpny80GS5
QEJIWAAVwktLrUWq2dyVVau4LACWx5ADQ/IjlrYN4lGWXijxwNxVXvh/TMbF
k26q51RnjkyW+fQi01iEfflmpU6vBF4vL6FQsh5ey13OooGHbSzkZcvT1e3V
goBFz/g2skDU8BpdmL5RNgwKO1RgN5A6Z+wQKwUWBkm8zVyCcWODLl6nQh6M
BN5s2ts7E+4ZG7dFOr8mNHjMOlvG/m0vNpvZm1pSuqkFOIzsFPJh5U0vnNMB
PbyZ077FxiSOpY9gxlMbUj5ibvw8E0vNVTWccgoaVfqWaAZZFkirOs5aeVVY
ne/u1cUTHOn4LARBrm1KAf6ykf3QQa7mwMkrAwQWTpmR4VZGhbNbTqT3YNva
A/OzLQ0Ce0QuM7toxXi0B/NxVkfMRQ+AY3904d7vFXNZjZUMEwXMHQmkMC+5
ip3zNSlfzE7x/G3Qs0F2qASkSgcKrcODoArN1A9hkHkBT+1NywkLQ67JtXZ9
OeShGJlI7ObF80RgO09XK/6y36IaAAkYAxkB5pkla2/RVp7NS5T5v4Xvmbl4
GwAA

-->

</rfc>
