<?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.43 (Ruby 3.4.9) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-emelia-oauth-user-authorization-mgmt-uri-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.34.1 -->
  <front>
    <title>OAuth User Authorization Management URI</title>
    <seriesInfo name="Internet-Draft" value="draft-emelia-oauth-user-authorization-mgmt-uri-00"/>
    <author fullname="Emelia Smith">
      <organization/>
      <address>
        <email>emelia@brandedcode.com</email>
        <uri>https://thisismissem.social</uri>
      </address>
    </author>
    <date year="2026" month="October" day="24"/>
    <area>Security</area>
    <workgroup>Web Authorization Protocol</workgroup>
    <keyword>oauth</keyword>
    <abstract>
      <?line 36?>

<t>This specification defines a <tt>user_authorization_management_uri</tt> property for the OAuth Authorization Server Metadata (<xref target="RFC8414"/>), which allows an authorization server to specify a URI through which the user may manage the authorized clients that have access to their account.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://drafts.thisismissem.social/draft-emelia-oauth-user-authorization-mgmt-uri/draft-emelia-oauth-user-authorization-mgmt-uri.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-emelia-oauth-user-authorization-mgmt-uri/"/>.
      </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/ThisIsMissEm/draft-emelia-oauth-user-authorization-mgmt-uri"/>.</t>
    </note>
  </front>
  <middle>
    <?line 40?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>An OAuth 2.0 <xref target="RFC6749"/> client may wish to provide access to a web-based UI at which a user can manage the applications authorized to access their account with the Authorization Server. This is a feature many Authorization Servers already support, however, when you don't have a primary service for the Authorization Server, there may be no clear path for a user to access this management page. This is especially true for decentralized social web applications where the mapping between Authorization Servers and Clients is many to many.</t>
      <t>This specification defines the new property of <tt>user_authorization_management_uri</tt> for the OAuth Authorization Server Metadata, as defined in <xref target="RFC8414"/>. This URI should point to a website at which the user can manage the authorizations that they have granted with their Authorization Server (for example, to revoke any client or active session, or review the security history of their account).</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</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 anchor="authorization-management-ui">
      <name>Authorization Management UI</name>
      <t>An Authorization Server may provide a user interface through which users can manage the OAuth Clients that have access to their account, such that users can manage their account security with the Authorization Server. This user interface is typically at an URI specific to the Authorization Server implementation, and requires authentication to access.</t>
      <t>This specification does not define specifics of the user interface, however, recommends that the user interface allows a user to manage their account security and authorized clients with the Authorization Server, for example, allowing them to see all authorized clients that have access to their account.</t>
      <t>To allow OAuth Clients to discover the URI of this user interface, this specification defines the new property <tt>user_authorization_management_uri</tt> for the OAuth Authorization Server Metadata, as defined in <xref target="RFC8414"/>.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This specification does not define how the Authorization Server should secure the authorization management UI. Authorization Servers should take appropriate measures to ensure that the user is authenticated and authorized to view the authorization management UI.</t>
      <t>The OAuth Client <bcp14>MUST NOT</bcp14> open the <tt>user_authorization_management_uri</tt> in a webview or similar embedded browser, and instead delegate that to the users' default browser, such that the OAuth Client has no access to the account credentials or to other sensitive data.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="oauth-authorization-server-metadata-registry">
        <name>OAuth Authorization Server Metadata Registry</name>
        <t>The following authorization server metadata value is defined by this specification and registered in the IANA "OAuth Authorization Server Metadata" registry established in OAuth 2.0 Authorization Server Metadata <xref target="RFC8414"/>.</t>
        <ul spacing="normal">
          <li>
            <t>Metadata Name: user_authorization_management_uri</t>
          </li>
          <li>
            <t>Metadata Description: URI of the authorization management user interface provided by the Authorization Server.</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document: This document</t>
          </li>
        </ul>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <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="RFC8414">
        <front>
          <title>OAuth 2.0 Authorization Server Metadata</title>
          <author fullname="M. Jones" initials="M." surname="Jones"/>
          <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
          <author fullname="J. Bradley" initials="J." surname="Bradley"/>
          <date month="June" year="2018"/>
          <abstract>
            <t>This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8414"/>
        <seriesInfo name="DOI" value="10.17487/RFC8414"/>
      </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 95?>

<section numbered="false" anchor="document-history">
      <name>Document History</name>
      <t>(This appendix to be deleted by the RFC editor in the final specification.)</t>
      <section numbered="false" anchor="draft-emelia-oauth-user-authorization-mgmt-uri-00">
        <name>draft-emelia-oauth-user-authorization-mgmt-uri-00</name>
        <ul spacing="normal">
          <li>
            <t>Replaces draft-emelia-oauth-authorization-management-uri-00.</t>
          </li>
          <li>
            <t>Renamed to clarify that this is about users managing their authorization grants at a given URI.</t>
          </li>
          <li>
            <t>Renamed the authorization server metadata parameter from authorization_management_uri to user_authorization_management_uri.</t>
          </li>
        </ul>
      </section>
      <section numbered="false" anchor="draft-emelia-oauth-authorization-management-uri-00">
        <name>draft-emelia-oauth-authorization-management-uri-00</name>
        <ul spacing="normal">
          <li>
            <t>Initial draft.</t>
          </li>
        </ul>
      </section>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA71Y224jNxJ976+o1QDJzEKtjBNjMxFy89qejABfZn1BEASD
Cbubkgh3NzskW4pi+F/yLfmyPUVSl5Zlj70P+ySpSFYVT526UGmaJk65Ug6p
d37QuildW2mIv2mj/hRO6ZpORS0mspK1o+uLUS/JhZMTbRZDsq5IkkLntaig
oTBi7FJsLJVItYCOtIW2VGxqS6tJ5dLWqPT168S2WaWshdgtGmgYHV+9Teq2
yqQZJgXMDJNc11bWtrVDcqaVyWxIXyXCSAGPL2UORW7RS+ba3EyMbhtIf5bZ
1gXeG+10rsteciMX2FoME6KUvIvJTNatZMFTzhMFR3s/w6CqJ/QTH2J5JVQJ
udf5o5JuPNBmwgsT5aZthqWrqbIje4r7HldfPA8r1lMCDuugZ+pcY4dfBBV2
4KBWWYZRVgOrcyXKZ2p/5vbB1FWAIgmrAcpxW5aBBMdeC11WuDaWiGRAJmj/
MTOiLmSR60IOcl35HdA5pOWtdlwnSWptKjgx83G6eHv4r6/3v4lf3+zv7Q+T
RNXj9Z4EVAUteMfl8cnbiD2BqC2zGL6naUois86I3CWJX7WNzNVY5SHkhRyr
WloS9BtD8bEDxcdqlREf4fxv1BjdSOMWBCfITSWFXOqy6FKaGXLrVDoBagt6
eXsb/b+7e9Wn+VTlUxJlqecwW1PHItlw2Ono5wKeIRlhDAScTONpNs3ugo0L
Ck562VKXLCgvFdy2EAtHUzHDYp5La1k1tirDv3Vbu0FAqVJFUcokeUGj2hld
tDn7kyQHdbzkl4PX9GuMyYeo3tufKztlrQBnpopNO4LmMkszYeHP9YjgSLx8
cD7H7Tedb5oyhsVu3oQVRZWbfsOuC0jsgn9APtiKIzuWwrVGsq3Fzs3YVKLS
FAuybdNo4/o01XOJFQ6XrGmhW7Cq/nyJJO6qKmEWPlwqlys+7NLe5xVvfkGZ
pFoDPCkMNQL+88EIx+Y94feae9g5kesLSc8MEGjhK6VXUcgcG40oPWIhnRj8
Lqhz7wf7WUHOZS2Tbi5xwQdQqQs6jDwKHi3YS/4cPJpNbKKW83W+6PGT8usZ
adUnYaO9glTtqck59iECxUljp7otC2q0AohLPlrl5JqKq0zaJuOm7ZhFkC8C
ASaobg52lxRU2600OvuSLyT/EFVTyj57YORM30A7gIwZxPHPuZyBS75D9lmE
fQr4sSc2Nj/CrRy6MWPZSYRXA87aQ13PuBz65EHcjhga5X9zqCShJRL3REu9
0+vLq14/fNLZuf9+cfyf69HF8RF/v3x3cHKy+pLEHZfvzq9Pjtbf1icPz09P
j8+OwmFIqSNKeqcHv2CFveqdv78anZ8dnPQ4Zm6zWpNgbmpOEYRLmsZIhljY
pJA2NyoLcf734fu//9rbp9vbfyDiX+7tfXN3F3+82fsaJdZnbLCma+RI+Mmx
S0B6TjxoQfYg4o1yorSeSaDKvCbOD6D5z18ZmQ9D+jbLm73976OAL9wRLjHr
CD1m9yX3DgcQd4h2mFmh2ZFvId319+CXzu8l7hvCb38okTyU7r354fuEKfTw
NDjyfWAnxbmqrSp/SCUfvrHI5VbX4kW7nWgh1Q+f2q36KNE+bbFvl76N/rBK
nKc0ii3HIcEAiLLGVRamYMMXlFjtolu7EVGc7YyblwYmGvl7q4wMfY3TNBbM
Vc1/oJ5qHKm1i4VutWpjEdhye6NtGYmpC04U69q1fcflCLLqPo+jyNfYMV88
Cm6fOgXQW+S2g/2Vn3Gkd+N/nVuudFC5TSJNhbK59oMUPOPIebzuxbkfhE9s
Yv+3DsbJuHzzcGG3SC4jVrX8kzQBCx6mZ2yKPq47et3m3HE9GjwwGUQlTtz4
uQ0IGYV3C1VS2JZ5jhjwa85b6NCvkwJc37u0wrlV53vMr9DTNuNOyxJNCFft
FTwlYNwMeCzwVhE8qypVoklIPE4LvGAoM8gSpjJ7qmrrMCgC6FJO+MLhdnp1
Qfs5B0G0pVsfXFes7YIHgnPguhRfpV5uZMFAoUexZ1jVPEkSv5OVHxmYRp4t
o4Ozg3tMefHiSe+TCznBZGEWAdKxXibpzodJtTw1E2Xr6+SSwdliVzKF4scG
0FqL0PRlcLf3BOd68TDGHjyKRVbirRHUrB8lj99uM6vStfjMP2I/yY/NI0d+
DGl413BdUx6h6Va9jV0yIvVAN4LBw6moUYYRTbzDylKa+H9JSpcdaI/i4DTE
+PMZv3/v7sJTLhP5DZNiuYHehckxuR2G/1xk8V1vDFbJHk689AWFR6O6UH/E
CYz57dauAkOShYKSZQQRc7wwOrEevPKUe/6/QzvdSsHLpgRudpfGLWUrzKPK
gT/Of1T4ipIjofkpHXMwvgsz3S5nCK8gNibuMJ3I+GHf+imAJsg6Pwp0LNwj
wXayNMJgJ4hAY6Mreoxx7O8naTl4COlP4PIQ1CN+KSCeXuMg+S8FsmimLhQA
AA==

-->

</rfc>
