<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-oauth-access-token-jwt-13" indexInclude="true" ipr="trust200902" number="9068" prepTime="2021-10-21T16:35:26" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="4" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt-13" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9068" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="OAuth 2.0 Access Token JWT Profile">JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens</title>
    <seriesInfo name="RFC" value="9068" stream="IETF"/>
    <author fullname="Vittorio Bertocci" initials="V." surname="Bertocci">
      <organization showOnFrontPage="true">Auth0</organization>
      <address>
        <email>vittorio@auth0.com</email>
      </address>
    </author>
    <date month="10" year="2021"/>
    <area>Security</area>
    <workgroup>OAuth</workgroup>
    <keyword>OAuth</keyword>
    <keyword>Resource</keyword>
    <keyword>Access token</keyword>
    <keyword>JWT</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
        This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization 
servers
		and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner.  
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9068" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-notation-and-c">Requirements Notation and Conventions</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-jwt-access-token-header-and">JWT Access Token Header and Data Structure</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-header">Header</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-data-structure">Data Structure</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2.2.2">
                  <li pn="section-toc.1-1.2.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.2.2.2.2.1.1"><xref derivedContent="2.2.1" format="counter" sectionFormat="of" target="section-2.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authentication-information-">Authentication Information Claims</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.2.2.2.2.2.1"><xref derivedContent="2.2.2" format="counter" sectionFormat="of" target="section-2.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-identity-claims">Identity Claims</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.2.2.2.2.3.1"><xref derivedContent="2.2.3" format="counter" sectionFormat="of" target="section-2.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authorization-claims">Authorization Claims</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2.2.2.3.2">
                      <li pn="section-toc.1-1.2.2.2.2.3.2.1">
                        <t indent="0" pn="section-toc.1-1.2.2.2.2.3.2.1.1"><xref derivedContent="2.2.3.1" format="counter" sectionFormat="of" target="section-2.2.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-claims-for-authorization-ou">Claims for Authorization Outside of Delegation Scenarios</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requesting-a-jwt-access-tok">Requesting a JWT Access Token</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-validating-jwt-access-token">Validating JWT Access Tokens</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-considerations">Privacy Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-type-registration">Media Type Registration</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.1.2">
                  <li pn="section-toc.1-1.7.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.1.2.1.1"><xref derivedContent="7.1.1" format="counter" sectionFormat="of" target="section-7.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registry-content">Registry Content</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-claims-registration">Claims Registration</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.2.2">
                  <li pn="section-toc.1-1.7.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.1.1"><xref derivedContent="7.2.1" format="counter" sectionFormat="of" target="section-7.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registry-content-2">Registry Content</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.2.2.1.2">
                      <li pn="section-toc.1-1.7.2.2.2.1.2.1">
                        <t indent="0" pn="section-toc.1-1.7.2.2.2.1.2.1.1"><xref derivedContent="7.2.1.1" format="counter" sectionFormat="of" target="section-7.2.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-roles">Roles</xref></t>
                      </li>
                      <li pn="section-toc.1-1.7.2.2.2.1.2.2">
                        <t indent="0" pn="section-toc.1-1.7.2.2.2.1.2.2.1"><xref derivedContent="7.2.1.2" format="counter" sectionFormat="of" target="section-7.2.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-groups">Groups</xref></t>
                      </li>
                      <li pn="section-toc.1-1.7.2.2.2.1.2.3">
                        <t indent="0" pn="section-toc.1-1.7.2.2.2.1.2.3.1"><xref derivedContent="7.2.1.3" format="counter" sectionFormat="of" target="section-7.2.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-entitlements">Entitlements</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="Introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
  The original 
                <xref target="RFC6749" format="default" sectionFormat="of" derivedContent="RFC6749">OAuth 2.0 Authorization Framework</xref> specification does not mandate any specific format for access tokens. 
  While that remains perfectly appropriate for many important scenarios, in-market use has shown that many commercial OAuth 2.0 
  implementations elected to issue access tokens using a format that can be parsed and validated by resource servers directly, without further authorization server involvement. 
  The approach is particularly common in topologies where the authorization server and resource server are not co-located, 
  are not run by the same entity, or are otherwise separated by some boundary. At the time of writing, many commercial implementations leverage the 
                <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="RFC7519">JSON Web Token (JWT)</xref> format.
            
      </t>
      <t indent="0" pn="section-1-2">
  Many vendor-specific JWT access tokens share the same functional layout, using JWT claims to convey the information needed to support a common set of use cases: token validation, transporting authorization information in the form of scopes and entitlements,
  carrying identity information about the subject, and so on. The differences are mostly confined to the claim names and syntax 
  used to represent the same entities, suggesting that interoperability could be easily achieved by standardizing a common set of claims and validation rules.
      </t>
      <t indent="0" pn="section-1-3">
  The assumption that access tokens are associated with specific information doesn't appear only in commercial implementations. 
  Various specifications in the OAuth 2.0 family (such as 
                <xref target="RFC8707" format="default" sectionFormat="of" derivedContent="RFC8707">resource indicators</xref>, 
                <xref target="RFC6750" format="default" sectionFormat="of" derivedContent="RFC6750">OAuth 2.0 bearer token usage</xref>, and others) postulate the presence of scoping mechanisms, such as an audience, in access tokens. 
The family of specifications associated with introspection also indirectly 
  suggests a fundamental set of information that access tokens are expected to carry or at least be associated with.			
            
      </t>
      <t indent="0" pn="section-1-4">
 This specification aims to provide a standardized and interoperable profile as an alternative to the proprietary JWT access token layouts going forward. 
 Besides defining a common set of mandatory and optional claims, the profile provides clear indications on how authorization request 
 parameters determine the content of the issued JWT access token, how an authorization server can publish metadata relevant to the 
 JWT access tokens it issues, and how a resource server should validate incoming JWT access tokens.
      </t>
      <t indent="0" pn="section-1-5">
  Finally, this specification provides security and privacy considerations meant to prevent common mistakes and anti-patterns 
that are likely to occur in naive use of the JWT format to represent access tokens.
      </t>
      <t indent="3" pn="section-1-6">
        Please note: Although both this document and <xref target="RFC7523" format="default" sectionFormat="of" derivedContent="RFC7523"/> use JSON Web Tokens in the context of the OAuth2 framework, the two specifications differ in both intent and mechanics. Whereas <xref target="RFC7523" format="default" sectionFormat="of" derivedContent="RFC7523"/> defines how a JWT Bearer Token can be used to request an access token, this document describes how to encode access tokens in JWT format.
      </t>
      <section anchor="RNC" numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-requirements-notation-and-c">Requirements Notation and Conventions</name>
        <t indent="0" pn="section-1.1-1">
    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" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
      <section anchor="Terminology" numbered="true" toc="include" removeInRFC="false" pn="section-1.2">
        <name slugifiedName="name-terminology">Terminology</name>
        <dl newline="false" spacing="normal" indent="3" pn="section-1.2-1">
          <dt pn="section-1.2-1.1">JWT access token:</dt>
          <dd pn="section-1.2-1.2">							
        An OAuth 2.0 access token encoded in JWT format and complying with the requirements described in this specification.
						</dd>
        </dl>
        <t indent="0" pn="section-1.2-2">
        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" format="default" sectionFormat="of" derivedContent="RFC6749">The OAuth 2.0 Authorization Framework</xref>.
        </t>
      </section>
    </section>
    <section anchor="JWTATLayout" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-jwt-access-token-header-and">JWT Access Token Header and Data Structure</name>
      <section anchor="JWTATHeader" numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-header">Header</name>
        <t indent="0" pn="section-2.1-1">
				JWT access tokens <bcp14>MUST</bcp14> be signed. Although JWT access tokens can use any signing algorithm, use of asymmetric cryptography is <bcp14>RECOMMENDED</bcp14> as it simplifies the process of acquiring validation information for resource servers (see 
                    <xref target="JWTATLValidate" format="default" sectionFormat="of" derivedContent="Section 4"/>). JWT access tokens <bcp14>MUST NOT</bcp14> use "none" as the signing algorithm. See 
                    <xref target="JWTATLValidate" format="default" sectionFormat="of" derivedContent="Section 4"/> for more details.
                
        </t>
        <t indent="0" pn="section-2.1-2">
                Authorization servers and resource servers conforming to this specification <bcp14>MUST</bcp14> include RS256 (as defined in <xref target="RFC7518" format="default" sectionFormat="of" derivedContent="RFC7518"/>) among their supported signature algorithms.  
        </t>
        <t indent="0" pn="section-2.1-3">
            
This specification registers the "application/at+jwt" media type, which can be used to indicate that the content is a JWT access token. 
   JWT access tokens <bcp14>MUST</bcp14> include this media type in the "typ" header parameter to explicitly declare that the JWT represents an access token complying with this profile.
   Per the definition of "typ" in <xref target="RFC7515" sectionFormat="of" section="4.1.9" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7515#section-4.1.9" derivedContent="RFC7515"/>, it is <bcp14>RECOMMENDED</bcp14> that the "application/" prefix be omitted.  Therefore, the "typ" value used <bcp14>SHOULD</bcp14> be "at+jwt".
 See the <xref target="SecurityConsiderations" format="title" sectionFormat="of" derivedContent="Security Considerations"/> section for details on the importance of preventing OpenID Connect ID Tokens (as defined by Section 2 of <xref target="OpenID.Core" format="default" sectionFormat="of" derivedContent="OpenID.Core"/>) from being accepted as access tokens by resource servers implementing this profile.
				
        </t>
      </section>
      <section anchor="JWTATDataStructure" numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-data-structure">Data Structure</name>
        <t indent="0" pn="section-2.2-1">
				The following claims are used in the JWT access token data structure.
        </t>
        <dl newline="false" spacing="normal" indent="3" pn="section-2.2-2">
          <dt pn="section-2.2-2.1">iss</dt>
          <dd pn="section-2.2-2.2">
            <bcp14>REQUIRED</bcp14> - as defined in <xref target="RFC7519" sectionFormat="of" section="4.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7519#section-4.1.1" derivedContent="RFC7519"/>.						
                        
                        </dd>
          <dt pn="section-2.2-2.3">exp</dt>
          <dd pn="section-2.2-2.4">
            <bcp14>REQUIRED</bcp14> - as defined in <xref target="RFC7519" sectionFormat="of" section="4.1.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7519#section-4.1.4" derivedContent="RFC7519"/>.						
                        
                        </dd>
          <dt pn="section-2.2-2.5">aud</dt>
          <dd pn="section-2.2-2.6">
            <bcp14>REQUIRED</bcp14> - as defined in <xref target="RFC7519" sectionFormat="of" section="4.1.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7519#section-4.1.3" derivedContent="RFC7519"/>. See 
                            <xref target="JWTATLRequest" format="default" sectionFormat="of" derivedContent="Section 3"/> for indications on how an authorization server should determine the value of "aud" depending on the request.					 						
                        
                        </dd>
          <dt pn="section-2.2-2.7">sub</dt>
          <dd pn="section-2.2-2.8">
            <bcp14>REQUIRED</bcp14> - as defined in <xref target="RFC7519" sectionFormat="of" section="4.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7519#section-4.1.2" derivedContent="RFC7519"/>. In cases of access tokens obtained through grants where a resource owner is involved, such as the authorization code grant, the value of "sub" <bcp14>SHOULD</bcp14> correspond to the subject identifier of the resource owner. In cases of access tokens obtained through grants where no resource owner is involved, such as the client credentials grant, the value of "sub" <bcp14>SHOULD</bcp14> correspond to an identifier the authorization server uses to indicate the client application. 
                            See 
                            <xref target="SecurityConsiderations" format="default" sectionFormat="of" derivedContent="Section 5"/> for more details on this scenario. Also, see 
                            <xref target="PrivacyConsiderations" format="default" sectionFormat="of" derivedContent="Section 6"/> for a discussion about how different choices in assigning "sub" values can impact privacy. 
                        
                        </dd>
          <dt pn="section-2.2-2.9">client_id</dt>
          <dd pn="section-2.2-2.10">
            <bcp14>REQUIRED</bcp14> - as defined in <xref target="RFC8693" sectionFormat="of" section="4.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8693#section-4.3" derivedContent="RFC8693"/>.
                        
                        </dd>
          <dt pn="section-2.2-2.11">iat</dt>
          <dd pn="section-2.2-2.12">
            <bcp14>REQUIRED</bcp14> - as defined in <xref target="RFC7519" sectionFormat="of" section="4.1.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7519#section-4.1.6" derivedContent="RFC7519"/>.
						This claim identifies the time at which the JWT access token was issued.                         
                        
                        </dd>
          <dt pn="section-2.2-2.13">jti</dt>
          <dd pn="section-2.2-2.14">
            <bcp14>REQUIRED</bcp14> - as defined in <xref target="RFC7519" sectionFormat="of" section="4.1.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7519#section-4.1.7" derivedContent="RFC7519"/>.
                        
                        </dd>
        </dl>
        <section anchor="AuthenticationInfoClaims" numbered="true" toc="include" removeInRFC="false" pn="section-2.2.1">
          <name slugifiedName="name-authentication-information-">Authentication Information Claims</name>
          <t indent="0" pn="section-2.2.1-1">The claims listed in this section <bcp14>MAY</bcp14> be issued in the context of authorization grants involving the resource owner and reflect the types and strength of authentication in the access token that the authentication server enforced prior to returning the authorization response to the client. Their values are fixed and remain the same across all access tokens that derive from a given authorization response, whether the access token was obtained directly 
                        in the response (e.g., via the implicit flow) or after one or more token exchanges (e.g., obtaining a fresh access token using a refresh token or exchanging one access token for another via 
                        <xref target="RFC8693" format="default" sectionFormat="of" derivedContent="RFC8693"/> procedures). 
                        
          </t>
          <dl newline="false" spacing="normal" indent="3" pn="section-2.2.1-2">
            <dt pn="section-2.2.1-2.1">auth_time</dt>
            <dd pn="section-2.2.1-2.2">
              <bcp14>OPTIONAL</bcp14> - as defined in Section 2 of 
                                <xref target="OpenID.Core" format="default" sectionFormat="of" derivedContent="OpenID.Core"/>.
                            
                            </dd>
            <dt pn="section-2.2.1-2.3">acr</dt>
            <dd pn="section-2.2.1-2.4">
              <bcp14>OPTIONAL</bcp14> - as defined in Section 2 of 
                                <xref target="OpenID.Core" format="default" sectionFormat="of" derivedContent="OpenID.Core"/>. 
                            
                            </dd>
            <dt pn="section-2.2.1-2.5">amr</dt>
            <dd pn="section-2.2.1-2.6">
              <bcp14>OPTIONAL</bcp14> - as defined in Section 2 of 
                                <xref target="OpenID.Core" format="default" sectionFormat="of" derivedContent="OpenID.Core"/>. 
                            
                            </dd>
          </dl>
        </section>
        <section anchor="IdentityClaims" numbered="true" toc="include" removeInRFC="false" pn="section-2.2.2">
          <name slugifiedName="name-identity-claims">Identity Claims</name>
          <t indent="0" pn="section-2.2.2-1">
					In the context of authorization grants involving the resource owner, commercial authorization servers will often include resource owner attributes directly in access tokens so that resource servers can consume them directly for authorization or other purposes without any further round trips to introspection (<xref target="RFC7662" format="default" sectionFormat="of" derivedContent="RFC7662"/>) or UserInfo (<xref target="OpenID.Core" format="default" sectionFormat="of" derivedContent="OpenID.Core"/>) endpoints.
					This is particularly common in scenarios where the client and the resource server belong to the same entity and are part of the same solution, as is the case for first-party clients invoking their own backend API.
					
                    
                    
                    
          </t>
          <t indent="0" pn="section-2.2.2-2">This profile does not introduce any mechanism for a client to directly request the presence of specific claims in JWT access tokens, as the authorization server can determine what additional claims are required by a particular resource server by taking the client_id of the client and the "scope" and the "resource" parameters included in the request into consideration.</t>
          <t indent="0" pn="section-2.2.2-3">
                    Any additional identity attribute whose semantic is well described by an entry in the "JSON Web Token (JWT)" IANA registry introduced in <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="RFC7519"/> <bcp14>SHOULD</bcp14> be encoded using the corresponding claim name, if that attribute is to be included in the JWT access token. Note that the JWT IANA registry includes the claims found in Section 5.1 of <xref target="OpenID.Core" format="default" sectionFormat="of" derivedContent="OpenID.Core"/>.
          </t>
          <t indent="0" pn="section-2.2.2-4">Authorization servers <bcp14>MAY</bcp14> return arbitrary attributes not defined in any existing specification, as long as the corresponding claim names are collision resistant or the access tokens are meant to be used only within a private subsystem. Please refer to Sections <xref target="RFC7519" sectionFormat="bare" section="4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7519#section-4.2" derivedContent="RFC7519"/> and <xref target="RFC7519" sectionFormat="bare" section="4.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7519#section-4.3" derivedContent="RFC7519"/> of <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="RFC7519"/> for details.
          </t>
          <t indent="0" pn="section-2.2.2-5">Authorization servers including resource owner attributes in JWT access tokens need to exercise care and verify that all privacy requirements are met, as discussed in 
                        
                        
                        
                        <xref target="PrivacyConsiderations" format="default" sectionFormat="of" derivedContent="Section 6"/>.
                    
                    
                    
          </t>
        </section>
        <section anchor="AuthorizationClaims" numbered="true" toc="include" removeInRFC="false" pn="section-2.2.3">
          <name slugifiedName="name-authorization-claims">Authorization Claims</name>
          <t indent="0" pn="section-2.2.3-1">
					If an authorization request includes a scope parameter, the corresponding issued JWT access token <bcp14>SHOULD</bcp14> include a "scope" claim as defined in  <xref target="RFC8693" sectionFormat="of" section="4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8693#section-4.2" derivedContent="RFC8693"/>.
                    
          </t>
          <t indent="0" pn="section-2.2.3-2">
					All the individual scope strings in the "scope" claim <bcp14>MUST</bcp14> have meaning for the resources indicated in the "aud" claim. See 
                        <xref target="SecurityConsiderations" format="default" sectionFormat="of" derivedContent="Section 5"/> for more considerations about the relationship between scope strings and resources indicated by the "aud" claim.
					
          </t>
          <section anchor="NDAuthorizationClaims" numbered="true" toc="include" removeInRFC="false" pn="section-2.2.3.1">
            <name slugifiedName="name-claims-for-authorization-ou">Claims for Authorization Outside of Delegation Scenarios</name>
            <t indent="0" pn="section-2.2.3.1-1">
						Many authorization servers embed authorization attributes that go beyond the delegated scenarios described by 
                            <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="RFC7519"/> in the access tokens they issue. Typical examples include resource owner memberships in roles and groups that are relevant to the resource being accessed, entitlements assigned to the resource owner for the targeted resource that the authorization server knows about, and so on.
                        
            </t>
            <t indent="0" pn="section-2.2.3.1-2">
An authorization server wanting to include such attributes in a JWT access token <bcp14>SHOULD</bcp14> use the "groups", "roles", and "entitlements" attributes of the "User" resource schema defined by <xref target="RFC7643" sectionFormat="of" section="4.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7643#section-4.1.2" derivedContent="RFC7643"/>) as claim types. 
</t>
            <t indent="0" pn="section-2.2.3.1-3">
Authorization servers <bcp14>SHOULD</bcp14> encode the corresponding claim values according to the guidance defined in <xref target="RFC7643" format="default" sectionFormat="of" derivedContent="RFC7643"/>. In particular, a non-normative example of a "groups" attribute can be found in <xref target="RFC7643" sectionFormat="of" section="8.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7643#section-8.2" derivedContent="RFC7643"/>. No specific vocabulary is provided for "roles" and "entitlements".
</t>
            <t indent="0" pn="section-2.2.3.1-4">
                            <xref target="IANAClaimsContent" format="default" sectionFormat="of" derivedContent="Section 7.2.1"/> of this document provides entries for registering "groups", "roles", and "entitlements" attributes from 
                            <xref target="RFC7643" format="default" sectionFormat="of" derivedContent="RFC7643"/> as claim types to be used in this profile.   
                        
            </t>
          </section>
        </section>
      </section>
    </section>
    <section anchor="JWTATLRequest" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-requesting-a-jwt-access-tok">Requesting a JWT Access Token</name>
      <t indent="0" pn="section-3-1">
			An authorization server can issue a JWT access token in response to any authorization grant defined by 
                <xref target="RFC6749" format="default" sectionFormat="of" derivedContent="RFC6749"/> and subsequent extensions meant to result in an access token.
            
      </t>
      <t indent="0" pn="section-3-2">If the request includes a "resource" parameter (as defined in 
                <xref target="RFC8707" format="default" sectionFormat="of" derivedContent="RFC8707"/>), the resulting JWT access token "aud" claim <bcp14>SHOULD</bcp14> have the same value as the "resource" parameter in the request. 
            
      </t>
      <t indent="0" pn="section-3-3">Example request below:</t>
      <figure anchor="authz-endpoint-example-code" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-authorization-request-with-">Authorization Request with Resource and Scope Parameters</name>
        <sourcecode name="" type="" markers="false" pn="section-3-4.1">
GET /as/authorization.oauth2?response_type=code
        &amp;client_id=s6BhdRkqt3
        &amp;state=xyz
        &amp;scope=openid%20profile%20reademail
        &amp;redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
        &amp;resource=https%3A%2F%2Frs.example.com%2F HTTP/1.1
     Host: authorization-server.example.com
</sourcecode>
      </figure>
      <t indent="0" pn="section-3-5">
		Once redeemed, the code obtained from the request above will result in a JWT access token in the form shown below:
      </t>
      <figure anchor="jwt-at-example-code" align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-the-header-and-jwt-claims-s">The Header and JWT Claims Set of a JWT Access Token</name>
        <sourcecode name="" type="json" markers="false" pn="section-3-6.1">
Header:

   {"typ":"at+JWT","alg":"RS256","kid":"RjEwOwOA"}

Claims:

   {
     "iss": "https://authorization-server.example.com/",
     "sub": "5ba552d67",
     "aud":   "https://rs.example.com/",
     "exp": 1639528912,
     "iat": 1618354090,
     "jti" : "dbe39bf3a3ba4238a513f51d6e1691c4",
     "client_id": "s6BhdRkqt3",
     "scope": "openid profile reademail"
   }
</sourcecode>
      </figure>
      <t indent="0" pn="section-3-7">
		The authorization server <bcp14>MUST NOT</bcp14> issue a JWT access token if the authorization granted by the token would be ambiguous.  
		See 
                <xref target="SecurityConsiderations" format="default" sectionFormat="of" derivedContent="Section 5"/> for more details about common cases that might lead to ambiguity and strategies an authorization server can enact to prevent them.
      </t>
      <t indent="0" pn="section-3-8">
		If the request does not include a "resource" parameter, the authorization server <bcp14>MUST</bcp14> use a default resource indicator in the "aud" claim. If a "scope" parameter is present in the request, the authorization server <bcp14>SHOULD</bcp14> use it to infer the value of the default resource indicator to be used in the "aud" claim. The mechanism through which scopes are associated with default resource indicator values is outside the scope of this specification. If the values in the "scope" parameter refer to different default resource indicator values, the authorization server <bcp14>SHOULD</bcp14> reject the request with "invalid_scope" as described in <xref target="RFC6749" sectionFormat="of" section="4.1.2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6749#section-4.1.2.1" derivedContent="RFC6749"/>.
			
            
            
            
      </t>
    </section>
    <section anchor="JWTATLValidate" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-validating-jwt-access-token">Validating JWT Access Tokens</name>
      <t indent="0" pn="section-4-1">
			For the purpose of facilitating validation data retrieval, it is <bcp14>RECOMMENDED</bcp14> here that authorization servers sign JWT access tokens with an asymmetric algorithm.
      </t>
      <t indent="0" pn="section-4-2">
			Authorization servers <bcp14>SHOULD</bcp14> use 
                <xref target="RFC8414" format="default" sectionFormat="of" derivedContent="RFC8414">OAuth 2.0 Authorization Server Metadata</xref> to advertise to resource servers their signing keys via "jwks_uri" and what "iss" claim value to expect 
                via the "issuer" metadata value. Alternatively, authorization servers implementing OpenID Connect <bcp14>MAY</bcp14> use the <xref target="OpenID.Discovery" format="default" sectionFormat="of" derivedContent="OpenID.Discovery">OpenID Connect discovery</xref> document for the same purpose. If an authorization server supports both OAuth 2.0 Authorization Server Metadata and OpenID Connect discovery, the values provided <bcp14>MUST</bcp14> be consistent across the two publication methods.
      </t>
      <t indent="0" pn="section-4-3">
			An authorization server <bcp14>MAY</bcp14> elect to use different keys to sign OpenID Connect ID Tokens and JWT access tokens. This specification does not provide a mechanism for identifying a specific key as the one used to sign JWT access tokens. An authorization server can sign JWT access tokens with any of the keys advertised via authorization server (AS) metadata or OpenID Connect discovery. See 
                <xref target="SecurityConsiderations" format="default" sectionFormat="of" derivedContent="Section 5"/> for further guidance on security implications.   
			
      </t>
      <t indent="0" pn="section-4-4">
			Resource servers receiving a JWT access token <bcp14>MUST</bcp14> validate it in the following manner.
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-5">
        <li pn="section-4-5.1">							
The resource server <bcp14>MUST</bcp14> verify that the "typ" header value is "at+jwt" or "application/at+jwt" and reject tokens carrying any other value.
					</li>
        <li pn="section-4-5.2">
If the JWT access token is encrypted, decrypt it using the keys and algorithms that the resource server specified during registration. If encryption was negotiated with the authorization server at registration time and the incoming JWT access token is not encrypted, the resource server <bcp14>SHOULD</bcp14> reject it.					
					</li>
        <li pn="section-4-5.3">
The issuer identifier for the authorization server (which is typically obtained during discovery) <bcp14>MUST</bcp14> exactly match the value of the "iss" claim.					
					</li>
        <li pn="section-4-5.4">
The resource server <bcp14>MUST</bcp14> validate that the "aud" claim contains a resource indicator value corresponding to an identifier the resource server expects for itself. The JWT access token <bcp14>MUST</bcp14> be rejected if "aud" does not contain a resource indicator of the current resource server as a valid audience.					
					</li>
        <li pn="section-4-5.5">
The resource server <bcp14>MUST</bcp14> validate the signature of all incoming JWT access tokens according to 
                        
                        
                        
                        <xref target="RFC7515" format="default" sectionFormat="of" derivedContent="RFC7515"/> using the algorithm specified in the JWT "alg" Header Parameter. The resource server <bcp14>MUST</bcp14> reject any JWT in which the value of "alg" is "none". The resource server <bcp14>MUST</bcp14> use the keys provided by the authorization server.  
					
                    
                    
                    
                    </li>
        <li pn="section-4-5.6">
The current time <bcp14>MUST</bcp14> be before the time represented by the "exp" claim. Implementers <bcp14>MAY</bcp14> provide for some small leeway, usually no more than a few minutes, to account for clock skew.					
					</li>
      </ul>
      <t indent="0" pn="section-4-6">
            The resource server <bcp14>MUST</bcp14> handle errors as described in <xref target="RFC6750" sectionFormat="of" section="3.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6750#section-3.1" derivedContent="RFC6750"/>. In particular, in case of any failure in the validation checks listed above, the authorization server response <bcp14>MUST</bcp14> include the error code "invalid_token".

                Please note that this requirement does not prevent JWT access tokens from using authentication schemes other than "Bearer".
            
      </t>
      <t indent="0" pn="section-4-7">			
If the JWT access token includes authorization claims as described in 
                <xref target="AuthorizationClaims" format="default" sectionFormat="of" derivedContent="Section 2.2.3"/>, the resource server <bcp14>SHOULD</bcp14> use them in combination with any other contextual information available to determine whether the current call should be authorized or rejected. Details about how a resource server performs those checks is beyond the scope of this profile specification.
			
      </t>
    </section>
    <section anchor="SecurityConsiderations" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">
			The JWT access token data layout described here is very similar to that of the id_token as defined by 
                <xref target="OpenID.Core" format="default" sectionFormat="of" derivedContent="OpenID.Core"/>. The explicit typing required in this profile, in line with the recommendations in 
                <xref target="RFC8725" format="default" sectionFormat="of" derivedContent="RFC8725"/>, helps the resource server to distinguish between JWT access tokens and OpenID Connect ID Tokens. 
            
      </t>
      <t indent="0" pn="section-5-2">
			Authorization servers should prevent scenarios where clients can affect the value of the "sub" claim in ways that could confuse resource servers. 
            For example, if the authorization server elects to use the client_id as the "sub" value for access tokens issued using the client credentials grant, the authorization server should prevent clients from registering an arbitrary client_id value, as this would allow malicious clients to select the sub of a high-privilege resource owner and confuse any authorization logic on the resource server relying on the "sub" value.       
			For more details, please refer to <xref target="I-D.ietf-oauth-security-topics" sectionFormat="of" section="4.14" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-18#section-4.14" derivedContent="OAuth2.Security.BestPractices"/>.
            
      </t>
      <t indent="0" pn="section-5-3">
To prevent cross-JWT confusion, authorization servers <bcp14>MUST</bcp14> use a distinct identifier as an "aud" claim value to uniquely identify access tokens issued by the same issuer for distinct resources. For more details on cross-JWT confusion, please refer to <xref target="RFC8725" sectionFormat="of" section="2.8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8725#section-2.8" derivedContent="RFC8725"/>. 
			
      </t>
      <t indent="0" pn="section-5-4">
			Authorization servers should use particular care when handling requests that might lead to ambiguous authorization grants. For example, if a request includes multiple resource indicators, the authorization server should ensure that each scope string included in the resulting JWT access token, if any, can be unambiguously correlated to a specific resource among the ones listed in the "aud" claim. The details on how to recognize and mitigate this and other ambiguous situations is highly scenario dependent and hence is out of scope for this profile.
      </t>
      <t indent="0" pn="section-5-5">
            Authorization servers cannot rely on the use of different keys for signing OpenID Connect ID Tokens and JWT tokens as a method to safeguard against the consequences of leaking specific keys. Given that resource servers have no way of knowing what key should be used to validate JWT access tokens in particular, they have to accept signatures performed with any of the keys published in AS metadata or OpenID Connect discovery; consequently, an attacker just needs to compromise any key among the ones published to be able to generate and sign JWTs that will be accepted as valid by the resource server.  
      </t>
    </section>
    <section anchor="PrivacyConsiderations" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <t indent="0" pn="section-6-1">
			 As JWT access tokens carry information by value, it now becomes possible for clients and potentially even end users to directly peek inside the token claims collection of unencrypted tokens.
            
      </t>
      <t indent="0" pn="section-6-2">
			The client <bcp14>MUST NOT</bcp14> inspect the content of the access token: the authorization server and the resource server might decide to change the token format at any time (for example, by switching from this profile to opaque tokens); hence, any logic in the client relying on the ability to read the access token content would break without recourse. 
            The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients. 
			Administrators of authorization servers should also take into account that the content of an access token is visible to the client. 
            Whenever client access to the access token content presents privacy issues for a given scenario, the authorization server needs to take explicit steps to prevent them.   
      </t>
      <t indent="0" pn="section-6-3">
			In scenarios in which JWT access tokens are accessible to the end user, it should be evaluated whether the information can be accessed without privacy violations (for example, if an end user would simply access his or her own personal information) or if steps must be taken to enforce confidentiality.
      </t>
      <t indent="0" pn="section-6-4">
            Possible measures to prevent leakage of information to clients and end users include: encrypting the access token, encrypting the sensitive claims, omitting the sensitive claims or not using this profile, and falling back on opaque access tokens.
      </t>
      <t indent="0" pn="section-6-5">
			In every scenario, the content of the JWT access token will eventually be accessible to the resource server. It's important to evaluate whether 
			the resource server gained the proper entitlement to have access to any content received in the form of claims, for example, through user consent 
			in some form, policies and agreements with the organization running the authorization servers, and so on. 
            For example, a user might not wish to consent to granting given resource server information about any of the non-mandatory claims enumerated in <xref target="JWTATLayout" format="default" sectionFormat="of" derivedContent="Section 2"/> (and its subsections). 
      </t>
      <t indent="0" pn="section-6-6">
             This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information for correlating incoming requests with data stored locally for the authenticated principal. 
             Although the ability to correlate requests might be required by design in many scenarios, there are scenarios where the authorization server might want to prevent correlation. The "sub" claim should be populated by the authorization servers according to a privacy impact assessment.
             For instance, if a solution requires preventing tracking of principal activities across multiple resource servers, the authorization server should ensure that JWT access tokens meant for different resource servers have distinct "sub" values that cannot be correlated in the event of resource server collusion.  
             Similarly, if a solution requires preventing a resource server from correlating the principal's activity within the resource itself, the authorization server should assign different "sub" values for every JWT access token issued. 
             In turn, the client should obtain a new JWT access token for every call to the resource server to ensure that the resource server receives different "sub" and "jti" values at every call, thus preventing correlation between distinct requests.
      </t>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="IANAMediaTypes" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-media-type-registration">Media Type Registration</name>
        <section anchor="IANAMediaTypesContent" numbered="true" toc="include" removeInRFC="false" pn="section-7.1.1">
          <name slugifiedName="name-registry-content">Registry Content</name>
          <t indent="0" pn="section-7.1.1-1">
	    This section registers "application/at+jwt", a new media type <xref target="RFC2046" format="default" sectionFormat="of" derivedContent="RFC2046"/> in the "Media Types" registry <xref target="IANA.MediaTypes" format="default" sectionFormat="of" derivedContent="IANA.MediaTypes"/> in the
   manner described in <xref target="RFC6838" format="default" sectionFormat="of" derivedContent="RFC6838"/>. It can be used to indicate that the
   content is an access token encoded in JWT format.
		                
          </t>
          <dl spacing="normal" indent="3" newline="false" pn="section-7.1.1-2">
            <dt pn="section-7.1.1-2.1">Type name:</dt>
            <dd pn="section-7.1.1-2.2"> Application</dd>
            <dt pn="section-7.1.1-2.3">Subtype name:</dt>
            <dd pn="section-7.1.1-2.4">at+jwt</dd>
            <dt pn="section-7.1.1-2.5">Required parameters:</dt>
            <dd pn="section-7.1.1-2.6">N/A</dd>
            <dt pn="section-7.1.1-2.7">Optional parameters:</dt>
            <dd pn="section-7.1.1-2.8">N/A</dd>
            <dt pn="section-7.1.1-2.9">Encoding considerations:</dt>
            <dd pn="section-7.1.1-2.10"> Binary; JWT values are
      encoded as a series of base64url-encoded values (with trailing '='
      characters removed), some of which may be the empty string,
      separated by period ('.') characters.</dd>
            <dt pn="section-7.1.1-2.11">Security considerations:</dt>
            <dd pn="section-7.1.1-2.12"> See the Security Considerations section of RFC 9068.</dd>
            <dt pn="section-7.1.1-2.13">Interoperability considerations:</dt>
            <dd pn="section-7.1.1-2.14">N/A</dd>
            <dt pn="section-7.1.1-2.15">Published specification:</dt>
            <dd pn="section-7.1.1-2.16">RFC 9068</dd>
            <dt pn="section-7.1.1-2.17">Applications that use this media type:</dt>
            <dd pn="section-7.1.1-2.18"> Applications that access resource servers using OAuth 2.0 access tokens encoded in JWT format</dd>
            <dt pn="section-7.1.1-2.19">Fragment identifier considerations:</dt>
            <dd pn="section-7.1.1-2.20">N/A</dd>
            <dt pn="section-7.1.1-2.21">Additional information:</dt>
            <dd pn="section-7.1.1-2.22">
              <t indent="0" pn="section-7.1.1-2.22.1"><br/></t>
              <dl spacing="compact" newline="false" indent="3" pn="section-7.1.1-2.22.2">
                <dt pn="section-7.1.1-2.22.2.1">Magic number(s):</dt>
                <dd pn="section-7.1.1-2.22.2.2">N/A</dd>
                <dt pn="section-7.1.1-2.22.2.3">File extension(s):</dt>
                <dd pn="section-7.1.1-2.22.2.4">N/A</dd>
                <dt pn="section-7.1.1-2.22.2.5">Macintosh file type code(s):</dt>
                <dd pn="section-7.1.1-2.22.2.6">N/A</dd>
              </dl>
            </dd>
            <dt pn="section-7.1.1-2.23">Person &amp; email address to contact for further information:</dt>
            <dd pn="section-7.1.1-2.24">
              <t indent="0" pn="section-7.1.1-2.24.1"><br/>Vittorio Bertocci &lt;vittorio@auth0.com&gt;</t>
            </dd>
            <dt pn="section-7.1.1-2.25">Intended usage:</dt>
            <dd pn="section-7.1.1-2.26"> COMMON</dd>
            <dt pn="section-7.1.1-2.27">Restrictions on usage:</dt>
            <dd pn="section-7.1.1-2.28"> None</dd>
            <dt pn="section-7.1.1-2.29">Author:</dt>
            <dd pn="section-7.1.1-2.30">Vittorio Bertocci &lt;vittorio@auth0.com&gt;</dd>
            <dt pn="section-7.1.1-2.31">Change controller:</dt>
            <dd pn="section-7.1.1-2.32">IETF</dd>
            <dt pn="section-7.1.1-2.33">Provisional registration?</dt>
            <dd pn="section-7.1.1-2.34">No</dd>
          </dl>
        </section>
      </section>
      <section anchor="IANAClaimTypes" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-claims-registration">Claims Registration</name>
        <t indent="0" pn="section-7.2-1">
                        <xref target="NDAuthorizationClaims" format="default" sectionFormat="of" derivedContent="Section 2.2.3.1"/> of this specification refers to the attributes "roles", "groups", "entitlements" defined in 
                        <xref target="RFC7643" format="default" sectionFormat="of" derivedContent="RFC7643"/> to express authorization information in JWT access tokens.
			This section registers those attributes as claims in the "JSON Web Token (JWT)" IANA registry introduced in 
                        <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="RFC7519"/>.
            
        </t>
        <section anchor="IANAClaimsContent" numbered="true" toc="include" removeInRFC="false" pn="section-7.2.1">
          <name slugifiedName="name-registry-content-2">Registry Content</name>
          <section anchor="IANARoles" numbered="true" toc="include" removeInRFC="false" pn="section-7.2.1.1">
            <name slugifiedName="name-roles">Roles</name>
            <dl spacing="compact" newline="false" indent="3" pn="section-7.2.1.1-1">
              <dt pn="section-7.2.1.1-1.1">Claim Name:</dt>
              <dd pn="section-7.2.1.1-1.2">roles</dd>
              <dt pn="section-7.2.1.1-1.3">Claim Description:</dt>
              <dd pn="section-7.2.1.1-1.4"> Roles</dd>
              <dt pn="section-7.2.1.1-1.5">Change Controller:</dt>
              <dd pn="section-7.2.1.1-1.6">IETF</dd>
              <dt pn="section-7.2.1.1-1.7">Specification Document(s):</dt>
              <dd pn="section-7.2.1.1-1.8">
                <xref target="RFC7643" sectionFormat="of" section="4.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7643#section-4.1.2" derivedContent="RFC7643"/> and <xref target="NDAuthorizationClaims" format="default" sectionFormat="of" derivedContent="Section 2.2.3.1"/> of RFC 9068</dd>
            </dl>
          </section>
          <section anchor="IANAGroups" numbered="true" toc="include" removeInRFC="false" pn="section-7.2.1.2">
            <name slugifiedName="name-groups">Groups</name>
            <dl spacing="compact" newline="false" indent="3" pn="section-7.2.1.2-1">
              <dt pn="section-7.2.1.2-1.1">Claim Name:</dt>
              <dd pn="section-7.2.1.2-1.2"> groups</dd>
              <dt pn="section-7.2.1.2-1.3">Claim Description:</dt>
              <dd pn="section-7.2.1.2-1.4">Groups</dd>
              <dt pn="section-7.2.1.2-1.5">Change Controller:</dt>
              <dd pn="section-7.2.1.2-1.6">IETF</dd>
              <dt pn="section-7.2.1.2-1.7">Specification Document(s):</dt>
              <dd pn="section-7.2.1.2-1.8">
                <xref target="RFC7643" sectionFormat="of" section="4.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7643#section-4.1.2" derivedContent="RFC7643"/> and <xref target="NDAuthorizationClaims" format="default" sectionFormat="of" derivedContent="Section 2.2.3.1"/> of RFC 9068</dd>
            </dl>
          </section>
          <section anchor="IANAEntitlements" numbered="true" toc="include" removeInRFC="false" pn="section-7.2.1.3">
            <name slugifiedName="name-entitlements">Entitlements</name>
            <dl spacing="compact" newline="false" indent="3" pn="section-7.2.1.3-1">
              <dt pn="section-7.2.1.3-1.1">Claim Name:</dt>
              <dd pn="section-7.2.1.3-1.2"> entitlements</dd>
              <dt pn="section-7.2.1.3-1.3">Claim Description:</dt>
              <dd pn="section-7.2.1.3-1.4"> Entitlements</dd>
              <dt pn="section-7.2.1.3-1.5">Change Controller:</dt>
              <dd pn="section-7.2.1.3-1.6">IETF</dd>
              <dt pn="section-7.2.1.3-1.7">Specification Document(s):</dt>
              <dd pn="section-7.2.1.3-1.8">
                <xref target="RFC7643" sectionFormat="of" section="4.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7643#section-4.1.2" derivedContent="RFC7643"/> and <xref target="NDAuthorizationClaims" format="default" sectionFormat="of" derivedContent="Section 2.2.3.1"/> of RFC 9068</dd>
            </dl>
          </section>
        </section>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-oauth-security-topics" to="OAuth2.Security.BestPractices"/>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="OpenID.Core" target="https://openid.net/specs/openid-connect-core-1_0.html" quoteTitle="true" derivedAnchor="OpenID.Core">
          <front>
            <title>OpenID Connect Core 1.0 incorporating errata set 1</title>
            <author initials="N" surname="Sakimura" fullname="Nat Sakimura">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J" surname="Bradley" fullname="John Bradley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Jones" fullname="Mike Jones">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B" surname="de Medeiros" fullname="Breno de Medeiros">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C" surname="Mortimore" fullname="Chuck Mortimore">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="November" year="2014"/>
          </front>
        </reference>
        <reference anchor="OpenID.Discovery" target="https://openid.net/specs/openid-connect-discovery-1_0.html" quoteTitle="true" derivedAnchor="OpenID.Discovery">
          <front>
            <title>OpenID Connect Discovery 1.0 incorporating errata set 1</title>
            <author initials="N" surname="Sakimura" fullname="Nat Sakimura">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J" surname="Bradley" fullname="John Bradley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Jones" fullname="Mike Jones">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E" surname="Jay" fullname="Edmund Jay">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="November" year="2014"/>
          </front>
        </reference>
        <reference anchor="RFC2046" target="https://www.rfc-editor.org/info/rfc2046" quoteTitle="true" derivedAnchor="RFC2046">
          <front>
            <title>Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
            <author initials="N." surname="Freed" fullname="N. Freed">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Borenstein" fullname="N. Borenstein">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1996" month="November"/>
            <abstract>
              <t indent="0">This second document defines the general structure of the MIME media typing system and defines an initial set of media types.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2046"/>
          <seriesInfo name="DOI" value="10.17487/RFC2046"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">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="RFC6749" target="https://www.rfc-editor.org/info/rfc6749" quoteTitle="true" derivedAnchor="RFC6749">
          <front>
            <title>The OAuth 2.0 Authorization Framework</title>
            <author initials="D." surname="Hardt" fullname="D. Hardt" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2012" month="October"/>
            <abstract>
              <t indent="0">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="RFC6838" target="https://www.rfc-editor.org/info/rfc6838" quoteTitle="true" derivedAnchor="RFC6838">
          <front>
            <title>Media Type Specifications and Registration Procedures</title>
            <author initials="N." surname="Freed" fullname="N. Freed">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Klensin" fullname="J. Klensin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Hansen" fullname="T. Hansen">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2013" month="January"/>
            <abstract>
              <t indent="0">This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols.  This memo documents an Internet Best Current Practice.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="13"/>
          <seriesInfo name="RFC" value="6838"/>
          <seriesInfo name="DOI" value="10.17487/RFC6838"/>
        </reference>
        <reference anchor="RFC7515" target="https://www.rfc-editor.org/info/rfc7515" quoteTitle="true" derivedAnchor="RFC7515">
          <front>
            <title>JSON Web Signature (JWS)</title>
            <author initials="M." surname="Jones" fullname="M. Jones">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Bradley" fullname="J. Bradley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Sakimura" fullname="N. Sakimura">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="May"/>
            <abstract>
              <t indent="0">JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification.  Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7515"/>
          <seriesInfo name="DOI" value="10.17487/RFC7515"/>
        </reference>
        <reference anchor="RFC7518" target="https://www.rfc-editor.org/info/rfc7518" quoteTitle="true" derivedAnchor="RFC7518">
          <front>
            <title>JSON Web Algorithms (JWA)</title>
            <author initials="M." surname="Jones" fullname="M. Jones">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="May"/>
            <abstract>
              <t indent="0">This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications.  It defines several IANA registries for these identifiers.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7518"/>
          <seriesInfo name="DOI" value="10.17487/RFC7518"/>
        </reference>
        <reference anchor="RFC7519" target="https://www.rfc-editor.org/info/rfc7519" quoteTitle="true" derivedAnchor="RFC7519">
          <front>
            <title>JSON Web Token (JWT)</title>
            <author initials="M." surname="Jones" fullname="M. Jones">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Bradley" fullname="J. Bradley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Sakimura" fullname="N. Sakimura">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="May"/>
            <abstract>
              <t indent="0">JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.  The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7519"/>
          <seriesInfo name="DOI" value="10.17487/RFC7519"/>
        </reference>
        <reference anchor="RFC7643" target="https://www.rfc-editor.org/info/rfc7643" quoteTitle="true" derivedAnchor="RFC7643">
          <front>
            <title>System for Cross-domain Identity Management: Core Schema</title>
            <author initials="P." surname="Hunt" fullname="P. Hunt" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Grizzle" fullname="K. Grizzle">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Wahlstroem" fullname="E. Wahlstroem">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Mortimore" fullname="C. Mortimore">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="September"/>
            <abstract>
              <t indent="0">The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier.  The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models.  Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model as well as binding documents to provide patterns for exchanging this schema using HTTP.</t>
              <t indent="0">This document provides a platform-neutral schema and extension model for representing users and groups and other resource types in JSON format.  This schema is intended for exchange and use with cloud service providers.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7643"/>
          <seriesInfo name="DOI" value="10.17487/RFC7643"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">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>
        <reference anchor="RFC8414" target="https://www.rfc-editor.org/info/rfc8414" quoteTitle="true" derivedAnchor="RFC8414">
          <front>
            <title>OAuth 2.0 Authorization Server Metadata</title>
            <author initials="M." surname="Jones" fullname="M. Jones">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Sakimura" fullname="N. Sakimura">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Bradley" fullname="J. Bradley">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="June"/>
            <abstract>
              <t indent="0">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="RFC8693" target="https://www.rfc-editor.org/info/rfc8693" quoteTitle="true" derivedAnchor="RFC8693">
          <front>
            <title>OAuth 2.0 Token Exchange</title>
            <author initials="M." surname="Jones" fullname="M. Jones">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Nadalin" fullname="A. Nadalin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Campbell" fullname="B. Campbell" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Bradley" fullname="J. Bradley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Mortimore" fullname="C. Mortimore">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020" month="January"/>
            <abstract>
              <t indent="0">This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8693"/>
          <seriesInfo name="DOI" value="10.17487/RFC8693"/>
        </reference>
        <reference anchor="RFC8707" target="https://www.rfc-editor.org/info/rfc8707" quoteTitle="true" derivedAnchor="RFC8707">
          <front>
            <title>Resource Indicators for OAuth 2.0</title>
            <author initials="B." surname="Campbell" fullname="B. Campbell">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Bradley" fullname="J. Bradley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020" month="February"/>
            <abstract>
              <t indent="0">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="RFC8725" target="https://www.rfc-editor.org/info/rfc8725" quoteTitle="true" derivedAnchor="RFC8725">
          <front>
            <title>JSON Web Token Best Current Practices</title>
            <author initials="Y." surname="Sheffer" fullname="Y. Sheffer">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Hardt" fullname="D. Hardt">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Jones" fullname="M. Jones">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020" month="February"/>
            <abstract>
              <t indent="0">JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas.  This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="225"/>
          <seriesInfo name="RFC" value="8725"/>
          <seriesInfo name="DOI" value="10.17487/RFC8725"/>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="IANA.MediaTypes" target="https://www.iana.org/assignments/media-types/" quoteTitle="true" derivedAnchor="IANA.MediaTypes">
          <front>
            <title>Media Types</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="I-D.ietf-oauth-security-topics" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-18" derivedAnchor="OAuth2.Security.BestPractices">
          <front>
            <title>OAuth 2.0 Security Best Current Practice</title>
            <author fullname="Torsten Lodderstedt">
              <organization showOnFrontPage="true">yes.com</organization>
            </author>
            <author fullname="John Bradley">
              <organization showOnFrontPage="true">Yubico</organization>
            </author>
            <author fullname="Andrey Labunets">
	 </author>
            <author fullname="Daniel Fett">
              <organization showOnFrontPage="true">yes.com</organization>
            </author>
            <date month="April" day="13" year="2021"/>
            <abstract>
              <t indent="0">   This document describes best current security practice for OAuth 2.0.
   It updates and extends the OAuth 2.0 Security Threat Model to
   incorporate practical experiences gathered since OAuth 2.0 was
   published and covers new threats relevant due to the broader
   application of OAuth 2.0.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-oauth-security-topics-18"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-18.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC6750" target="https://www.rfc-editor.org/info/rfc6750" quoteTitle="true" derivedAnchor="RFC6750">
          <front>
            <title>The OAuth 2.0 Authorization Framework: Bearer Token Usage</title>
            <author initials="M." surname="Jones" fullname="M. Jones">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Hardt" fullname="D. Hardt">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2012" month="October"/>
            <abstract>
              <t indent="0">This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources.  Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key).  To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6750"/>
          <seriesInfo name="DOI" value="10.17487/RFC6750"/>
        </reference>
        <reference anchor="RFC7523" target="https://www.rfc-editor.org/info/rfc7523" quoteTitle="true" derivedAnchor="RFC7523">
          <front>
            <title>JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants</title>
            <author initials="M." surname="Jones" fullname="M. Jones">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Campbell" fullname="B. Campbell">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Mortimore" fullname="C. Mortimore">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="May"/>
            <abstract>
              <t indent="0">This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7523"/>
          <seriesInfo name="DOI" value="10.17487/RFC7523"/>
        </reference>
        <reference anchor="RFC7662" target="https://www.rfc-editor.org/info/rfc7662" quoteTitle="true" derivedAnchor="RFC7662">
          <front>
            <title>OAuth 2.0 Token Introspection</title>
            <author initials="J." surname="Richer" fullname="J. Richer" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="October"/>
            <abstract>
              <t indent="0">This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7662"/>
          <seriesInfo name="DOI" value="10.17487/RFC7662"/>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">
        The initial set of requirements informing this specification was extracted by numerous examples of access tokens issued in JWT format by production systems.
Thanks to <contact fullname="Dominick Baier"/> (IdentityServer), <contact fullname="Brian Campbell"/> (Ping Identity), <contact fullname="Daniel Dobalian"/> (Microsoft), and <contact fullname="Karl Guinness"/> (Okta) for providing sample tokens issued by their products and services.		
		<contact fullname="Brian Campbell"/> and <contact fullname="Filip Skokan"/> provided early feedback that shaped the direction of the specification.
		This profile was discussed at length during the OAuth Security Workshop 2019, with several individuals contributing ideas and feedback. The author would like to acknowledge the contributions of:</t>
      <t indent="0" pn="section-appendix.a-2">
        <contact fullname="John Bradley"/>,
	<contact fullname="Brian Campbell"/>,
	<contact fullname="Vladimir Dzhuvinov"/>,
        <contact fullname="Torsten Lodderstedt"/>,
        <contact fullname="Nat Sakimura"/>,
	<contact fullname="Hannes Tschofenig"/>,         
        and
        everyone who actively participated in the unconference discussions.
      </t>
      <t indent="0" pn="section-appendix.a-3">
			The following individuals contributed useful feedback and insights on the drafts, both at the IETF OAuth 2.0 WG mailing list and during the 28th Internet Identity Workshop (IIW 28):
      </t>
      <t indent="0" pn="section-appendix.a-4">
        <contact fullname="Dale Olds"/>,
	<contact fullname="George Fletcher"/>,
	<contact fullname="David Waite"/>,
        <contact fullname="Michael Engan"/>,
        <contact fullname="Mike Jones"/>,
        <contact fullname="Hans Zandbelt"/>,
        <contact fullname="Vladimir Dzhuvinov"/>,
        <contact fullname="Martin Schanzenbach"/>,
	<contact fullname="Aaron Parecki"/>,
	<contact fullname="Annabelle Richard Backman"/>,
        <contact fullname="Dick Hardt"/>,
        <contact fullname="Denis Pinkas"/>,
        <contact fullname="Benjamin Kaduk"/>,
        <contact fullname="Dominick Baier"/>,
        <contact fullname="Andrii Deinega"/>,
        <contact fullname="Mike Jones"/>, 		
        and
        everyone who actively participated in the IIW 28 unconference discussions and the IETF OAuth 2.0 WG mailing list discussions.
        Thanks to <contact fullname="Roman Danyliw"/> for the AD review; <contact fullname="Joseph Salowey"/> and <contact fullname="Roni Even"/> for the SECDIR and GENART reviews; and <contact fullname="Francesca Palomini"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Roberto Polli"/>, <contact fullname="Martin Duke"/>, <contact fullname="Benjamin Kaduk"/> for the IESG reviews.
      </t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author fullname="Vittorio Bertocci" initials="V." surname="Bertocci">
        <organization showOnFrontPage="true">Auth0</organization>
        <address>
          <email>vittorio@auth0.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
