<?xml version="1.0" encoding="us-ascii"?>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/rfc2629.xslt' ?> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude"  docName="draft-ietf-oauth-access-token-jwt-13" ipr="trust200902"> number="9068" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <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"/>
    <author fullname="Vittorio Bertocci" initials="V." surname="Bertocci">
      <organization>Auth0</organization>
      <address>
        <email>vittorio@auth0.com</email>
      </address>
    </author>
    <date year="2021" month="October" />
    <area>Security</area>
        <workgroup>OAuth Working Group</workgroup>
    <workgroup>OAuth</workgroup>
    <keyword>OAuth</keyword>
    <keyword>Resource</keyword>
    <keyword>Access token</keyword>
    <keyword>JWT</keyword>
    <abstract>
      <t>
        This specification defines a profile for issuing OAuth 2.0 access tokens in JSON web token 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>
  </front>
  <middle>
    <section anchor="Introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
  The original
                <xref target="RFC6749">OAuth target="RFC6749" format="default">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">JSON target="RFC7519" format="default">JSON Web Tokens Token (JWT)</xref> format.

      </t>
      <t>
  Many vendor specific 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 forms 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 on a common set of claims and validation rules.
      </t>
      <t>
  The assumption that access tokens are associated to with specific information doesn't appear only in commercial implementations.
  Various specifications in the OAuth 2.0 family (such as
                <xref target="RFC8707">resource target="RFC8707" format="default">resource indicators</xref>,
                <xref target="RFC6750">OAuth target="RFC6750" format="default">OAuth 2.0 bearer token usage</xref> usage</xref>, and others) postulate the presence in access tokens of scoping mechanisms, such as an audience. audience, in access tokens.
The family of specifications associated to with introspection also indirectly
  suggest
  suggests a fundamental set of information that access tokens are expected to carry or at least be associated with.

      </t>
      <t>
 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>
  Finally, this specification provides security and privacy considerations meant to prevent common mistakes and anti patterns anti-patterns
that are likely to occur in naive use of the JWT format to represent access tokens.
      </t>
            <t>
      <t indent="3">
        Please note: although Although both this document and <xref target="RFC7523"/> target="RFC7523" format="default"/> use JSON Web Tokens in the context of the OAuth2 framework, the two specifications differ in both intent and mechanics. Whereas <xref target=" RFC7523"/> target="RFC7523" format="default"/> defines how a JWT Bearer Token can be used to request an access token, this documents document describes how to encode access tokens in JWT format.
      </t>
      <section anchor="RNC" title="Requirements numbered="true" toc="default">
        <name>Requirements Notation and Conventions"> Conventions</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in
  BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
      <section anchor="Terminology" title="Terminology">
                <t>
                    <list style="hanging">
                        <t hangText="JWT numbered="true" toc="default">
        <name>Terminology</name>
        <dl newline="false" spacing="normal">
          <dt>JWT access token:"> token:</dt>
          <dd>
        An OAuth 2.0 access token encoded in JWT format and complying with the requirements described in this specification.
						</t>
                    </list>
                </t>
						</dd>
        </dl>
        <t>
        This specification uses the terms
        "access token",
        "refresh token",
        "authorization server",
        "resource server",
        "authorization endpoint",
        "authorization request",
        "authorization response",
        "token endpoint",
        "grant type",
        "access token request",
        "access token response",
        and "client"
        defined by
                    <xref target="RFC6749">The target="RFC6749" format="default">The OAuth 2.0 Authorization Framework</xref>.
        </t>
      </section>
    </section>
    <section anchor="JWTATLayout" title="JWT numbered="true" toc="default">
      <name>JWT Access Token Header and Data Structure"> Structure</name>
      <section anchor="JWTATHeader" title="Header"> numbered="true" toc="default">
        <name>Header</name>
        <t>
				JWT access tokens MUST <bcp14>MUST</bcp14> be signed. Although JWT access tokens can use any signing algorithm, use of asymmetric cryptography is RECOMMENDED <bcp14>RECOMMENDED</bcp14> as it simplifies the process of acquiring validation information for resource servers (see
                    <xref target="JWTATLValidate"/>). target="JWTATLValidate" format="default"/>). JWT access tokens MUST NOT <bcp14>MUST NOT</bcp14> use "none" as the signing algorithm. See
                    <xref target="JWTATLValidate"/> target="JWTATLValidate" format="default"/> for more details.

        </t>
        <t>
                Authorization servers and resource servers conforming to this specification MUST <bcp14>MUST</bcp14> include RS256 (as defined in <xref target="RFC7518"/>) target="RFC7518" format="default"/>) among their supported signature algorithms.
        </t>
        <t>

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 MUST <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 Section 4.1.9 of <xref target="RFC7515"/>, target="RFC7515" sectionFormat="of" section="4.1.9"/>, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the "application/" prefix be omitted.  Therefore, the "typ" value used SHOULD <bcp14>SHOULD</bcp14> be "at+jwt".
 See the security considerations <xref target="SecurityConsiderations" format="title"/> section for details on the importance of preventing OpenID Connect ID Tokens (as defined by Section 2 of <xref target="OpenID.Core"/>) target="OpenID.Core" format="default"/>) from being accepted as access tokens by resource servers implementing this profile.

        </t>
      </section>
      <section anchor="JWTATDataStructure" title="Data Structure"> numbered="true" toc="default">
        <name>Data Structure</name>
        <t>
				The following claims are used in the JWT access token data structure.
        </t>
                <t>
                    <list style="hanging">
                        <t hangText="iss">
        REQUIRED
        <dl newline="false" spacing="normal">
          <dt>iss</dt>
          <dd>
        <bcp14>REQUIRED</bcp14> - as defined in Section 4.1.1 of <xref target="RFC7519"/>.

                        </t>
                        <t hangText="exp">
        REQUIRED target="RFC7519" sectionFormat="of" section="4.1.1"/>.

                        </dd>
          <dt>exp</dt>
          <dd>
        <bcp14>REQUIRED</bcp14> - as defined in Section 4.1.4 of <xref target="RFC7519"/>.

                        </t>
                        <t hangText="aud">
        REQUIRED target="RFC7519" sectionFormat="of" section="4.1.4"/>.

                        </dd>
          <dt>aud</dt>
          <dd>
        <bcp14>REQUIRED</bcp14> - as defined in Section 4.1.3 of <xref target="RFC7519"/>. target="RFC7519"  sectionFormat="of" section="4.1.3"/>. See
                            <xref target="JWTATLRequest"/> target="JWTATLRequest" format="default"/> for indications on how an authorization server should determine the value of "aud" depending on the request.

                        </t>
                        <t hangText="sub">
        REQUIRED

                        </dd>
          <dt>sub</dt>
          <dd>
        <bcp14>REQUIRED</bcp14> - as defined in Section 4.1.2 of <xref target="RFC7519"/>. target="RFC7519"  sectionFormat="of" section="4.1.2"/>. In case cases of access tokens obtained through grants where a resource owner is involved, such as the authorization code grant, the value of "sub" SHOULD <bcp14>SHOULD</bcp14> correspond to the subject identifier of the resource owner. In case cases of access tokens obtained through grants where no resource owner is involved, such as the client credentials grant, the value of "sub" SHOULD <bcp14>SHOULD</bcp14> correspond to an identifier the authorization server uses to indicate the client application.
                            See
                            <xref target="SecurityConsiderations"/> target="SecurityConsiderations" format="default"/> for more details on this scenario. Also, see
                            <xref target="PrivacyConsiderations"/> target="PrivacyConsiderations" format="default"/> for a discussion about how different choices in assigning "sub" values can impact privacy.

                        </t>
                        <t hangText="client_id">
        REQUIRED

                        </dd>
          <dt>client_id</dt>
          <dd>
        <bcp14>REQUIRED</bcp14> - as defined in Section 4.3 of <xref target="RFC8693"/>.

                        </t>
                        <t hangText="iat">
        REQUIRED target="RFC8693"  sectionFormat="of" section="4.3"/>.

                        </dd>
          <dt>iat</dt>
          <dd>
        <bcp14>REQUIRED</bcp14> - as defined in Section 4.1.6 of <xref target="RFC7519"/>. target="RFC7519" sectionFormat="of" section="4.1.6"/>.
						This claim identifies the time at which the JWT access token was issued.

                        </t>
                        <t hangText="jti">
        REQUIRED

                        </dd>
          <dt>jti</dt>
          <dd>
        <bcp14>REQUIRED</bcp14> - as defined in Section 4.1.7 of <xref target="RFC7519"/>.

                        </t>
                    </list>
                </t> target="RFC7519"  sectionFormat="of" section="4.1.7"/>.

                        </dd>
        </dl>
        <section anchor="AuthenticationInfoClaims" title="Authentication numbered="true" toc="default">
          <name>Authentication Information Claims">
                    <t>
						The Claims</name>
          <t>The claims listed in this section MAY <bcp14>MAY</bcp14> be issued in the context of authorization grants involving the resource owner, owner and reflect in the access token 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, 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, token or exchanging one access token for another via
                        <xref target="RFC8693"/> target="RFC8693" format="default"/> procedures).

                        <list style="hanging">
                            <t hangText="auth_time">
									OPTIONAL

          </t>
          <dl newline="false" spacing="normal">
            <dt>auth_time</dt>
            <dd>
									<bcp14>OPTIONAL</bcp14> - as defined in Section 2 of
                                <xref target="OpenID.Core"/>.

                            </t>
                            <t hangText="acr">
									OPTIONAL target="OpenID.Core" format="default"/>.

                            </dd>
            <dt>acr</dt>
            <dd>
									<bcp14>OPTIONAL</bcp14> - as defined in Section 2 of
                                <xref target="OpenID.Core"/>.

                            </t>
                            <t hangText="amr">
									OPTIONAL target="OpenID.Core" format="default"/>.

                            </dd>
            <dt>amr</dt>
            <dd>
									<bcp14>OPTIONAL</bcp14> - as defined in Section 2 of
                                <xref target="OpenID.Core"/>.

                            </t>
                        </list>
                    </t> target="OpenID.Core" format="default"/>.

                            </dd>
          </dl>
        </section>
        <section anchor="IdentityClaims" title="Identity Claims"> numbered="true" toc="default">
          <name>Identity Claims</name>
          <t>
					In the context of authorization grants involving the resource owner, commercial authorization servers will often include resource owner attributes directly in access tokens, tokens so that resource servers can consume them directly for authorization or other purposes without any further round trips to introspection (

                        <xref target="RFC7662"/>) (<xref target="RFC7662" format="default"/>) or UserInfo (

                        <xref target="OpenID.Core"/>) (<xref target="OpenID.Core" format="default"/>) 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 first-party clients invoking their own backend API.

          </t>
          <t>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 in consideration the client_id of the client, client and the "scope" and the "resource" parameters included in the request.</t> request into consideration.</t>
          <t>
                    Any additional identity attribute whose semantic is well described by an entry in the JSON "JSON Web Token (JWT) (JWT)" IANA registry introduced in <xref target="RFC7519"/> SHOULD target="RFC7519" format="default"/> <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"/>. target="OpenID.Core" format="default"/>.
          </t>
          <t>Authorization servers MAY <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 4.2 <xref target="RFC7519" sectionFormat="bare" section="4.2"/> and 4.3 <xref target="RFC7519" sectionFormat="bare" section="4.3"/> of <xref target="RFC7519"/> for details.
          </t>
          <t>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"/>. target="PrivacyConsiderations" format="default"/>.

          </t>
        </section>
        <section anchor="AuthorizationClaims" title="Authorization Claims"> numbered="true" toc="default">
          <name>Authorization Claims</name>
          <t>
					If an authorization request includes a scope parameter, the corresponding issued JWT access token SHOULD <bcp14>SHOULD</bcp14> include a "scope" claim as defined in Section 4.2 of  <xref target="RFC8693"/>. target="RFC8693" sectionFormat="of" section="4.2"/>.

          </t>
          <t>
					All the individual scope strings in the "scope" claim MUST <bcp14>MUST</bcp14> have meaning for the resources indicated in the "aud" claim. See
                        <xref target="SecurityConsiderations"/> target="SecurityConsiderations" format="default"/> for more considerations about the relationship between scope strings and resources indicated by the "aud" claim.

          </t>
          <section anchor="NDAuthorizationClaims" title="Claims numbered="true" toc="default">
            <name>Claims for Authorization Outside of Delegation Scenarios"> Scenarios</name>
            <t>
						Many authorization servers embed in the access tokens they issue authorization attributes that go beyond the delegated scenarios described by
                            <xref target="RFC7519"/>. target="RFC7519" format="default"/> 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>
An authorization server wanting to include such attributes in a JWT access token SHOULD <bcp14>SHOULD</bcp14> use as claim types the "groups","roles" "groups", "roles", and "entitlements" attributes of the "User" resource schema defined by Section 4.1.2 of <xref target="RFC7643"/>). target="RFC7643" sectionFormat="of" section="4.1.2"/>) as claim types.
</t>
            <t>
Authorization servers SHOULD <bcp14>SHOULD</bcp14> encode the corresponding claim values according to the guidance defined in <xref target="RFC7643"/>. target="RFC7643" format="default"/>. In particular, a non-normative example of a "groups" attribute can be found in Section 8.2 of <xref target="RFC7643"/>. target="RFC7643" sectionFormat="of" section="8.2"/>. No specific vocabulary is provided for "roles" and "entitlements".
</t>
            <t>
                            <xref target="IANA"/> target="IANAClaimsContent" format="default"/> of this document provides entries for registering "groups", "roles" "roles", and "entitlements" attributes from
                            <xref target="RFC7643"/> target="RFC7643" format="default"/> as claim types to be used in this profile.

            </t>
          </section>
        </section>
      </section>
    </section>
    <section anchor="JWTATLRequest" title="Requesting numbered="true" toc="default">
      <name>Requesting a JWT Access Token"> Token</name>
      <t>
			An authorization server can issue a JWT access token in response to any authorization grant defined by
                <xref target="RFC6749"/> target="RFC6749" format="default"/> and subsequent extensions meant to result in an access token.

      </t>
      <t>If the request includes a "resource" parameter (as defined in
                <xref target="RFC8707"/>), target="RFC8707" format="default"/>), the resulting JWT access token "aud" claim SHOULD <bcp14>SHOULD</bcp14> have the same value as the "resource" parameter in the request.

      </t>
      <t>Example request below:</t>
            <t>
      <figure title="Authorization anchor="authz-endpoint-example-code">
        <name>Authorization Request with Resource and Scope Parameters" anchor="authz-endpoint-example-code">
                    <artwork>
                        <![CDATA[ Parameters</name>

        <sourcecode name="" type=""><![CDATA[
GET /as/authorization.oauth2?response_type=code
        &client_id=s6BhdRkqt3
        &state=xyz
        &scope=openid%20profile%20reademail
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
        &resource=https%3A%2F%2Frs.example.com%2F HTTP/1.1
     Host: authorization-server.example.com
		  ]]>
                    </artwork>
]]></sourcecode>
      </figure>
            </t>
      <t>
		Once redeemed, the code obtained from the request above will result in a JWT access token in the form shown below:
      </t>
            <t>
      <figure title="The anchor="jwt-at-example-code">
        <name>The Header and JWT Claims Set of a JWT Access Token" anchor="jwt-at-example-code">
                    <artwork>
                        <![CDATA[ Token</name>
        <sourcecode name="" type="json"><![CDATA[
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"
   }
		  ]]>
                    </artwork>
]]></sourcecode>
      </figure>
            </t>
      <t>
		The authorization server MUST NOT <bcp14>MUST NOT</bcp14> issue a JWT access token if the authorization granted by the token would be ambiguous.
		See
                <xref target="SecurityConsiderations"/> target="SecurityConsiderations" format="default"/> for more details about common cases that might lead to ambiguity and strategies an authorization server can enact to prevent them.
      </t>
      <t>
		If the request does not include a "resource" parameter, the authorization server MUST <bcp14>MUST</bcp14> use in the "aud" claim a default resource indicator. indicator in the "aud" claim. If a "scope" parameter is present in the request, the authorization server SHOULD <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 to 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 SHOULD <bcp14>SHOULD</bcp14> reject the request with "invalid_scope" as described in Section 4.1.2.1 of <xref target="RFC6749"/>. target="RFC6749" sectionFormat="of" section="4.1.2.1"/>.

      </t>
    </section>
    <section anchor="JWTATLValidate" title="Validating numbered="true" toc="default">
      <name>Validating JWT Access Tokens"> Tokens</name>
      <t>
			For the purpose of facilitating validation data retrieval, it is <bcp14>RECOMMENDED</bcp14> here RECOMMENDED that authorization servers sign JWT access tokens with an asymmetric algorithm.
      </t>
      <t>
			Authorization servers SHOULD <bcp14>SHOULD</bcp14> use
                <xref target="RFC8414">OAuth target="RFC8414" format="default">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 MAY <bcp14>MAY</bcp14> use the <xref target="OpenID.Discovery">"OpenID target="OpenID.Discovery" format="default">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 MUST <bcp14>MUST</bcp14> be consistent across the two publication methods.
      </t>
      <t>
			An authorization server MAY <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 AS authorization server (AS) metadata or OpenID Connect discovery. See
                <xref target="SecurityConsiderations"/> target="SecurityConsiderations" format="default"/> for further guidance on security implications.

      </t>
      <t>
			Resource servers receiving a JWT access token MUST <bcp14>MUST</bcp14> validate it in the following manner.
      </t>
            <t>
                <list style="symbols">
                    <t>
      <ul spacing="normal">
        <li>
The resource server MUST <bcp14>MUST</bcp14> verify that the typ "typ" header value is "at+jwt" or "application/at+jwt" and reject tokens carrying any other value.
					</t>
                    <t>
					</li>
        <li>
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 SHOULD <bcp14>SHOULD</bcp14> reject it.
					</t>
                    <t>
					</li>
        <li>
The Issuer Identifier issuer identifier for the authorization server (which is typically obtained during discovery) MUST <bcp14>MUST</bcp14> exactly match the value of the "iss" claim.
					</t>
                    <t>
					</li>
        <li>
The resource server MUST <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 MUST <bcp14>MUST</bcp14> be rejected if "aud" does not contain a resource indicator of the current resource server as a valid audience.
					</t>
                    <t>
					</li>
        <li>
The resource server MUST <bcp14>MUST</bcp14> validate the signature of all incoming JWT access tokens according to

                        <xref target="RFC7515"/> target="RFC7515" format="default"/> using the algorithm specified in the JWT alg "alg" Header Parameter. The resource server MUST <bcp14>MUST</bcp14> reject any JWT in which the value of "alg" is "none". The resource server MUST <bcp14>MUST</bcp14> use the keys provided by the authorization server.

                    </t>
                    <t>

                    </li>
        <li>
The current time MUST <bcp14>MUST</bcp14> be before the time represented by the "exp" claim. Implementers MAY <bcp14>MAY</bcp14> provide for some small leeway, usually no more than a few minutes, to account for clock skew.
					</t>
                </list>
            </t>
					</li>
      </ul>
      <t>
            The resource server MUST <bcp14>MUST</bcp14> handle errors as described in Section 3.1 of <xref target="RFC6750"/>. target="RFC6750" sectionFormat="of" section="3.1"/>. In particular, in case of any failure in the validation checks listed above above, the authorization server response MUST <bcp14>MUST</bcp14> include the error code "invalid_token".

                Please note that this requirement does not prevent JWT access tokens to use authentications from using authentication schemes other than Bearer. "Bearer".

      </t>
      <t>
If the JWT access token includes authorization claims as described in
                <xref target="AuthorizationClaims"/>, target="AuthorizationClaims" format="default"/>, the resource server SHOULD <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" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
			The JWT access token data layout described here is very similar to the one that of the id_token as defined by
                <xref target="OpenID.Core"/>. target="OpenID.Core" format="default"/>. The explicit typing required in this profile, in line with the recommendations in
                <xref target="RFC8725"/> target="RFC8725" format="default"/>, helps the resource server to distinguish between JWT access tokens and OpenID Connect ID Tokens.

      </t>
      <t>
			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 high-privilege resource owner and confuse any authorization logic on the resource server relying on the "sub" value.
			For more details details, please refer to Section 4.14 of <xref target="OAuth2.Security.BestPractices"/>. target="I-D.ietf-oauth-security-topics" sectionFormat="of" section="4.14"/>.

      </t>
      <t>
To prevent cross-JWT confusion, authorization servers MUST <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 confusion, please refer to Section 2.8 of <xref target="RFC8725"/>. target="RFC8725" sectionFormat="of" section="2.8"/>.

      </t>
      <t>
			Authorization servers should use particular care when handling requests that might lead to ambiguous authorization grants. For example: 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, scenario dependent and hence is out of scope for this profile.
      </t>
      <t>
            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: 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" title="Privacy Considerations"> numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>
			 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>
			The client MUST NOT <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 example, by switching from this profile to opaque tokens) hence 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 it. them.
      </t>
      <t>
			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>
            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>
			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 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 a given resource server information about any of the non-mandatory claims enumerated in <xref target="JWTATLayout"/> target="JWTATLayout" format="default"/> (and subsections)." its subsections).
      </t>
      <t>
             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 servers 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, 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" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="IANAMediaTypes" title="Media numbered="true" toc="default">
        <name>Media Type Registration"> Registration</name>
        <section anchor="IANAMediaTypesContent" title="Registry Content"> numbered="true" toc="default">
          <name>Registry Content</name>
	            <t>
	    This section registers the "application/at+jwt" "application/at+jwt", a new media type <xref target="RFC2046"/> target="RFC2046" format="default"/> in the "Media Types" registry [IANA.MediaTypes] <xref target="IANA.MediaTypes"/> in the
   manner described in <xref target="RFC6838"/>, which target="RFC6838" format="default"/>. It can be used to indicate that the
   content is an access token encoded in JWT format.

          </t>
                        <t>
                            <list style='symbols'>
                                <t>Type name: application</t>
                                <t>Subtype name: at+jwt</t>
                                <t>Required parameters: N/A</t>
                                <t>Optional parameters: N/A</t>
                                <t>Encoding considerations: binary;
<dl spacing="normal">
            <dt>Type name:</dt><dd> Application</dd>
            <dt>Subtype name:</dt><dd>at+jwt</dd>
            <dt>Required parameters:</dt><dd>N/A</dd>
            <dt>Optional parameters:</dt><dd>N/A</dd>
            <dt>Encoding considerations:</dt><dd> 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.</t>
                                <t>Security considerations: characters.</dd>
            <dt>Security considerations:</dt><dd> See the Security Considerations Section section of [[TODO: update once there's a RFC number for the JWT AT profile]]</t>
                                <t>Interoperability considerations: N/A</t>
                                <t>Published specification: [[TODO: update once there's a RFC number for the JWT AT profile]]</t>
                                <t>Applications 9068.</dd>
            <dt>Interoperability considerations:</dt><dd>N/A</dd>
            <dt>Published specification:</dt><dd>RFC 9068</dd>
            <dt>Applications that use this media type: type:</dt><dd> Applications that access resource servers using OAuth 2.0 access tokens encoded in JWT format</t>
                                <t>Fragment format</dd>
            <dt>Fragment identifier considerations: N/A</t>
                                <t>Additional information:

         Magic number(s): N/A
         File extension(s): N/A
         Macintosh considerations:</dt><dd>N/A</dd>

<dt>Additional information:</dt>
<dd><t><br/></t>
  <dl spacing="compact" newline="false">
    <dt>Magic number(s):</dt><dd>N/A</dd>
    <dt>File extension(s):</dt><dd>N/A</dd>
    <dt>Macintosh file type code(s): N/A
							</t>
                                <t>Person and code(s):</dt><dd>N/A</dd>
  </dl>
</dd>
            <dt>Person &amp; email address to contact for further information: Vittorio Bertocci, vittorio@auth0.com</t>
                                <t>Intended usage: COMMON</t>
                                <t>Restrictions information:</dt>
	    <dd><t><br/>Vittorio Bertocci &lt;vittorio@auth0.com&gt;</t></dd>

            <dt>Intended usage:</dt><dd> COMMON</dd>
            <dt>Restrictions on usage: none</t>
                                <t>Author:       Vittorio Bertocci, vittorio@auth0.com</t>
                                <t>Change controller: IESG</t>
                                <t>Provisional registration?  No</t>
                            </list>
                        </t> usage:</dt><dd> None</dd>
            <dt>Author:</dt><dd>Vittorio Bertocci &lt;vittorio@auth0.com&gt;</dd>
            <dt>Change controller:</dt><dd>IETF</dd>
            <dt>Provisional registration?</dt><dd>No</dd>
          </dl>
        </section>
      </section>
      <section anchor="IANAClaimTypes" title="Claims Registration"> numbered="true" toc="default">
        <name>Claims Registration</name>
        <t>
                        <xref target="NDAuthorizationClaims"/> target="NDAuthorizationClaims" format="default"/> of this specification refers to the attributes "roles", "groups", "entitlements" defined in
                        <xref target="RFC7643"/> target="RFC7643" format="default"/> to express authorization information in JWT access tokens.
			This section registers those attributes as claims in the JSON "JSON Web Token (JWT) (JWT)" IANA registry introduced in
                        <xref target="RFC7519"/>. target="RFC7519" format="default"/>.

        </t>
        <section anchor="IANAClaimsContent" title="Registry Contents"> numbered="true" toc="default">
          <name>Registry Content</name>
          <section anchor="IANARoles" title="Roles">
                            <t>
                                <list style='symbols'>
                                    <t>Claim Name: "roles"</t>
                                    <t>Claim Description: Roles</t>
                                    <t>Change Controller: IESG</t>
                                    <t>Specification Document(s): Section 4.1.2 of <xref target="RFC7643"/> numbered="true" toc="default">
            <name>Roles</name>
            <dl spacing="compact" newline="false">
              <dt>Claim Name:</dt><dd>roles</dd>
              <dt>Claim Description:</dt><dd> Roles</dd>
              <dt>Change Controller:</dt><dd>IETF</dd>
              <dt>Specification Document(s):</dt><dd> <xref target="RFC7643" sectionFormat="of" section="4.1.2"/> and <xref target="NDAuthorizationClaims"/> target="NDAuthorizationClaims" format="default"/> of [[this specification]]</t>
                                </list>
                            </t> RFC 9068</dd>
            </dl>
          </section>
          <section anchor="IANAGroups" title="Groups">
                        <t>
                            <list style='symbols'>
                                <t>Claim Name: "groups"</t>
                                <t>Claim Description: Groups</t>
                                <t>Change Controller: IESG</t>
                                <t>Specification Document(s): Section 4.1.2 of <xref target="RFC7643"/> numbered="true" toc="default">
            <name>Groups</name>
            <dl spacing="compact" newline="false">
              <dt>Claim Name:</dt><dd> groups</dd>
              <dt>Claim Description:</dt><dd>Groups</dd>
              <dt>Change Controller:</dt><dd>IETF</dd>
              <dt>Specification Document(s):</dt><dd> <xref target="RFC7643" sectionFormat="of" section="4.1.2"/> and <xref target="NDAuthorizationClaims"/> target="NDAuthorizationClaims" format="default"/> of [[this specification]]</t>
                            </list>
                            </t> RFC 9068</dd>
            </dl>
          </section>
          <section anchor="IANAEntitlements" title="Entitlements">
                        <t>
                            <list style='symbols'>
                                <t>Claim Name: "entitlements"</t>
                                <t>Claim Description: Entitlements</t>
                                <t>Change Controller: IESG</t>
                                <t>Specification Document(s): Section 4.1.2 of <xref target="RFC7643"/> numbered="true" toc="default">
            <name>Entitlements</name>
            <dl spacing="compact" newline="false">
              <dt>Claim Name:</dt><dd> entitlements</dd>
              <dt>Claim Description:</dt><dd> Entitlements</dd>
              <dt>Change Controller:</dt><dd>IETF</dd>
              <dt>Specification Document(s):</dt><dd> <xref target="RFC7643" sectionFormat="of" section="4.1.2"/> and <xref target="NDAuthorizationClaims"/> target="NDAuthorizationClaims" format="default"/> of [[this specification]]</t>
                            </list>
                            </t> RFC 9068</dd>
            </dl>
          </section>
        </section>
      </section>
    </section>
  </middle>
  <back>
            <references title="Normative References">
                <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml' ?>
                <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml' ?>
                <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml' ?>
                <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml' ?>
                <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7643.xml' ?>
                <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml' ?>
                <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8414.xml' ?>
                <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml' ?>
                <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml' ?>
                <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8693.xml' ?>
                <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8707.xml' ?>
                <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8725.xml' ?>
                <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml' ?>

<displayreference target="I-D.ietf-oauth-security-topics" to="OAuth2.Security.BestPractices"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7643.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8414.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8693.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8707.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8725.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml"/>

        <reference anchor='OpenID.Core' target='https://openid.net/specs/openid-connect-core-1_0.html'> anchor="OpenID.Core" target="https://openid.net/specs/openid-connect-core-1_0.html">
          <front>
            <title>OpenID Connect Core 1.0</title> 1.0 incorporating errata set 1</title>
            <author initials='N' surname='Sakimura' fullname='Nat Sakimura'>
                            <organization /> initials="N" surname="Sakimura" fullname="Nat Sakimura">
              <organization/>
            </author>
            <author initials='J' surname='Bradley' fullname='John Bradley'>
                            <organization /> initials="J" surname="Bradley" fullname="John Bradley">
              <organization/>
            </author>
            <author initials='M' surname='Jones' fullname='Mike Jones'>
                            <organization /> initials="M" surname="Jones" fullname="Mike Jones">
              <organization/>
            </author>
            <author initials='B' surname='Medeiros' fullname='B Medeiros'>
                            <organization /> initials="B" surname="de Medeiros" fullname="Breno de Medeiros">
              <organization/>
            </author>
            <author initials='C' surname='Mortimore' fullname='Chuck Mortimore'>
                            <organization /> initials="C" surname="Mortimore" fullname="Chuck Mortimore">
              <organization/>
            </author>
            <date month='November' year='2014' /> month="November" year="2014"/>
          </front>
        </reference>

        <reference anchor='OpenID.Discovery' target='https://openid.net/specs/openid-connect-discovery-1_0.html'> anchor="OpenID.Discovery" target="https://openid.net/specs/openid-connect-discovery-1_0.html">
          <front>
            <title>OpenID Connect Discovery 1.0</title> 1.0 incorporating errata set 1</title>
            <author initials='N' surname='Sakimura' fullname='Nat Sakimura'>
                            <organization /> initials="N" surname="Sakimura" fullname="Nat Sakimura">
              <organization/>
            </author>
            <author initials='J' surname='Bradley' fullname='John Bradley'>
                            <organization /> initials="J" surname="Bradley" fullname="John Bradley">
              <organization/>
            </author>
            <author initials='M' surname='Jones' fullname='Mike Jones'>
                            <organization /> initials="M" surname="Jones" fullname="Mike Jones">
              <organization/>
            </author>
            <author initials='J' surname='Jay' fullname='Edmund Jay'>
                            <organization /> initials="E" surname="Jay" fullname="Edmund Jay">
              <organization/>
            </author>
            <date month='November' year='2014' /> month="November" year="2014"/>
          </front>
        </reference>
      </references>
            <references title="Informative References">
                <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7662.xml' ?>
                <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6750.xml' ?>
                <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7523.xml' ?>
      <references>
        <name>Informative References</name>

        <reference anchor='OAuth2.Security.BestPractices' target="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-18"> anchor="IANA.MediaTypes" target="https://www.iana.org/assignments/media-types/">
          <front>
                        <title>OAuth 2.0 Security Best Current Practice</title>
                        <author initials='T' surname='Lodderstedt' fullname='Torsten Lodderstedt'>
                            <organization />
                        </author>
                        <author initials='J' surname='Bradley' fullname='John Bradley'>
                            <organization />
                        </author>
                        <author initials='A' surname='Labunets' fullname='Andrey Labunets'>
                            <organization />
                        </author>
                        <author initials='D' surname='Fett' fullname='Daniel Fett'>
                            <organization />
                        </author>
                        <date month='July' year='2019' />
            <title>Media Types</title>
	    <author><organization>IANA</organization></author>
            <date/>
          </front>
        </reference>

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

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-oauth-security-topics.xml"/>

      </references>
    </references>
    <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
        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 Dominick Baier <contact fullname="Dominick Baier"/> (IdentityServer), Brian Campbell <contact fullname="Brian Campbell"/> (Ping Identity), Daniel Dobalian <contact fullname="Daniel Dobalian"/> (Microsoft), Karl Guinness and <contact fullname="Karl Guinness"/> (Okta) for providing sample tokens issued by their products and services.
		Brian Campbell and Filip Skokan
		<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>
        John Bradley,
		Brian Campbell,
		Vladimir Dzhuvinov,
        Torsten Lodderstedt,
        Nat Sakimura,
		Hannes Tschofenig
        <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>
			The following individuals contributed useful feedback and insights on the drafts, both on at the IETF OAuth 2.0 WG DL mailing list and during the IIW28 conference: 28th Internet Identity Workshop (IIW 28):
      </t>
      <t>
        Dale Olds,
		George Fletcher,
		David Waite,
        Michael Engan,
        Mike Jones,
        Hans Zandbelt,
        Vladimir Dzhuvinov,
        Martin Schanzenbach	,
		Aaron Parecki,
		Annabelle
        <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,
        Dick Hardt,
        Denis Pinkas,
        Benjamin Kaduk,
        Dominick Baier,
        Andrii Deinega,
        Mike Jones 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 IIW28 IIW 28 unconference discussions and the IETF OAuth 2.0 WG DL mailing list discussions.
        Thanks to Roman Danyliw <contact fullname="Roman Danyliw"/> for the AD review, Joseph Salowey and Roni Even for the SECDIR/GENART reviews, Francesca Palomini, Lars Eggert, Murray Kucherawy, Roberto Polli, Martin Duke, Benjamin Kaduk 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="History" title="Document History">
                <?rfc subcompact="yes"?>
                <t>
	[[ to be removed by the RFC Editor before publication as an RFC ]]
			</t>
            <t>
			    draft-ietf-oauth-access-token-jwt-13
                    <list style='symbols'>
                        <t>
                       Added an explicit requirement for the JWT access tokens to be signed in <xref target="JWTATHeader"/>.
                       </t>
                            <t>
                       Added sections in <xref target="IANAClaimTypes"/> for improving readability.
                       </t>
                       <t>
                       In <xref target="jwt-at-example-code"/>, added jti and iat claims.
                       </t>
                       <t>
                       Editorial fixes in <xref target="AuthenticationInfoClaims"/> and <xref target="JWTATLValidate"/>.
                       </t>
                        <t>
                        Clarified that additional claims are to be added only if necessary - in <xref target="IdentityClaims"/>. Editorial changes in the same section.
                        </t>
                        <t>
                       Updates sample values in <xref target="JWTATLRequest"/>.
                       </t>
                       <t>
                       Added leeway language to the exp validation step in <xref target="JWTATLValidate"/>.
                       </t>
                       <t>
                       In <xref target="JWTATLValidate"/>, clarified that the use of RFC6750 error codes does not imply that JWT ATs can only be Bearer tokens.
                       </t>
                       <t>
                       Various edits and nits in <xref target="SecurityConsiderations"/> and <xref target="PrivacyConsiderations"/>.
                       </t>
                       <t>
                       Added clarifying language in <xref target="PrivacyConsiderations"/> regarding what claims in the AT might require explicit user consent.
                       </t>
                       <t>
                       Added URLs for the OpenID references and the oauth security BCP. Moved RFC7523 to the informative references section.
                       </t>
                    </list>
                </t>
             <t>
			    draft-ietf-oauth-access-token-jwt-12
                    <list style='symbols'>
                        <t>
                       Editorial changes in the abstract.
                       </t>
                        <t>
                       Updated the client_id value in the figures in <xref target="JWTATLRequest"/>.
                       </t>
                       <t>
                       Added clarifying language in <xref target="Introduction"/> positioning this specification vs <xref target="RFC7523"/>.
                       </t>
                       <t>
                       In section <xref target="JWTATHeader"/> added a sentence that makes RS256 support mandatory for AS and RS.
                       </t>
                    </list>
                </t>
             <t>
			    draft-ietf-oauth-access-token-jwt-11

                    <list style='symbols'>
                        <t>
                       Editorial updates and typo fixes in <xref target="Terminology"/>,  <xref target="JWTATDataStructure"/>,
                        <xref target="AuthenticationInfoClaims"/>, <xref target="IdentityClaims"/>, <xref target="JWTATLRequest"/>,
                         <xref target="JWTATLValidate"/>,  <xref target="SecurityConsiderations"/>, <xref target="Acknowledgements"/>
                       </t>
                       <t>
                       Updated language in <xref target="IdentityClaims"/> to explicitly refer to the JWT IANA registry.
                       </t>
                        <t>
                       Citation added in in <xref target="JWTATHeader"/>
                       </t>
                        <t>
                       Added a normative reference entry for OpenID Connect Discovery 1.0 and referenced it from <xref target="JWTATLValidate"/>
                       </t>

                    </list>
                </t>
             <t>
			    draft-ietf-oauth-access-token-jwt-10

                    <list style='symbols'>
                        <t>
                       Updated Figure 2 in <xref target="JWTATLRequest"/> to clarify that the intent of that snippet is to describe the content rather than exact JWT AT format.
                       </t>
                        <t>
                            Updated registry references in <xref target="IANAClaimsContent"/> to point to <xref target="NDAuthorizationClaims"/>
                        </t>
                        <t>
                        Modified <xref target="NDAuthorizationClaims"/> to make it easier for the reader to understand what values and format is expected for the groups, roles and entitlement claims. Minor formatting issues fixed.
                        </t>
                    </list>
                </t>
                <t>
			    draft-ietf-oauth-access-token-jwt-09

                    <list style='symbols'>
                        <t>
                       Removed unused reference to http://www.iana.org/assignments/oauth-parameters; moved the OAuth2 security BCP to the informative references section.
                       </t>
                        <t>
                       Restructured opening paragraphs in
                            <xref target="PrivacyConsiderations"/> for clarity.

                        </t>
                    </list>
                </t>
                <t>
			    draft-ietf-oauth-access-token-jwt-08

                    <list style='symbols'>
                        <t>
                       Numerous edits for correcting typos, improving clarity and precision of language.
                       </t>
                        <t>
                       Moved RFC7519 to the normative section; eliminated unused references RFC7644 and RFC3986.
                       </t>
                    </list>
                </t>
                <t>
			    draft-ietf-oauth-access-token-jwt-07

                    <list style='symbols'>
                        <t>
                       In
                            <xref target="JWTATHeader"/>, added language that forbids use of none as alg value, and references
                            <xref target="JWTATLValidate"/> where the same prohibition was already expressed from the RS perspective.

                        </t>
                        <t>
                       In the sub definition in
                            <xref target="JWTATDataStructure"/>, added a sentence that clarifies what goes in the sub in the case of grants where a resource owner is involved.

                        </t>
                        <t>
                       Updated acknowledgements.
                       </t>
                        <t>
                       Updated
                            <xref target="AuthenticationInfoClaims"/> to clarify that acr, amr and auth_type can occur if the AT has been obtained by grants where the resource owner is involved.

                        </t>
                        <t>
                       Updated
                            <xref target="IdentityClaims"/>  to clarify that identity claims can occur if the AT has been obtained by grants where the resource owner is involved.

                        </t>
                        <t>
                       In
                            <xref target="NDAuthorizationClaims"/> eliminated the claim that SCIM doesn't provide a vocabulary for the attributes listed there.

                        </t>
                        <t>
                       In
                            <xref target="SecurityConsiderations"/> added reference to 8725.

                        </t>
                        <t>
                       In
                            <xref target="JWTATLValidate"/> added application/jwt+at as accepted typ value.

                        </t>
                        <t>
                       Various typos and formatting issues fixed.
                       </t>
                    </list>
                </t>
                <t>
			    draft-ietf-oauth-access-token-jwt-06

                    <list style='symbols'>
                        <t>
                       In
                            <xref target="JWTATDataStructure"/> and
                            <xref target="PrivacyConsiderations"/> added a discussion about how different sub values affect the privacy properties of a solution.

                        </t>
                        <t>
                       In
                            <xref target="AuthorizationClaims"/> and
                            <xref target="JWTATLRequest"/> eliminated language prohibiting JWT AT requests featuring multiple resources, substituting it with the prohibition for the AS to emit JWT ATs expressing ambiguous authorization grants.
                       In
                            <xref target="SecurityConsiderations"/>, added language warning against scope confusion and mentioned the existence of other ambiguous authorization grant.

                        </t>
                        <t>
                       In
                            <xref target="JWTATDataStructure"/> promoted claims iat and jti from RECOMMENDED to REQUIRED.

                        </t>
                        <t>
                       In
                            <xref target="JWTATHeader"/> eliminated temporary note on the lack of authenticated encryption methods specifications.

                        </t>
                        <t>
                       Updated acknowledgements.
                       </t>
                    </list>
                </t>
                <t>
			    draft-ietf-oauth-access-token-jwt-05

                    <list style='symbols'>
                        <t>
						Varios typos, grammar issues and improper abbreviations fixed.
					   </t>
                        <t>
                       Reworded the definition of at+jwt in
                            <xref target="JWTATHeader"/>.

                        </t>
                        <t>
                       In
                            <xref target="JWTATDataStructure"/>, clarified that iat refers to the issuance time of the JWT itself.

                        </t>
                        <t>
                       In
                            <xref target="IdentityClaims"/>, added a reference to public/private claims definitions (Sections 4.2, 4.3) of
                            <xref target="RFC7519"/>.

                        </t>
                        <t>
                       In
                            <xref target="JWTATLRequest"/>, removed the paragrah stating that every JWT AT MUST have an aud, as it is already defined in
                            <xref target="JWTATDataStructure"/>.

                        </t>
                        <t>
                       Reworded description of the JWT AT adoption landscape in
                            <xref target="Introduction"/>.

                        </t>
                        <t>
                       Simplified the individual descriptions of the claims list in
                            <xref target="AuthenticationInfoClaims"/>.

                        </t>
                        <t>
                        Updated
                            <xref target="JWTATLValidate"/> and
                            <xref target="SecurityConsiderations"/> to clarify that the AS can use any of the published keys to sign JWT access tokens, and that the AS should not rely on use of different signing keys per token type as a security mechanism.

                        </t>
                        <t>
                       In
                            <xref target="JWTATDataStructure"/> promoted claims iat and jti from OPTIONAL to RECOMMENDED

                        </t>
                        <t>
                        In
                            <xref target="JWTATLValidate"/>, switched the validation steps list type from numbers to bullets.

                        </t>
                        <t>
                        In
                            <xref target="JWTATLValidate"/>, eliminated the auth_time instructions from the validation steps list.

                        </t>
                        <t>
                        In
                            <xref target="IdentityClaims"/>, added a reference to the JWT claims registry as source of claims for JWT ATs

                        </t>
                        <t>
                         In
                            <xref target="JWTATLValidate"/>, clarified that failures in JWT AT validation checks will result in invalid_token.

                        </t>
                    </list>
                </t>
                <t>
			 draft-ietf-oauth-access-token-jwt-04

                    <list style='symbols'>
                        <t>Eliminated reference to resource aliases list from the aud claim description in

                            <xref target="JWTATLayout"/>.

                        </t>
                        <t>Eliminated references to resource aliases list from the aud validation guidance in

                            <xref target="JWTATLValidate"/>.

                        </t>
                        <t>Introduced a new subsection

                            <xref target="AuthenticationInfoClaims"/>, moved the definitions of auth_time, acr and amr there and incorporated the language proposed by Annabelle and Brian on the WG mailing list.

                        </t>
                        <t>In section

                            <xref target="JWTATLRequest"/> softened (from MUST to SHOULD) the requirement that ties the resource identifier in the request to the value in the aud claim of the issued access token.

                        </t>
                        <t>Updated acknowledgements.</t>
                        <t>In the section

                            <xref target="JWTATLRequest"/>, the example request now has response_type=code.

                        </t>
                        <t>Updated text in the Privacy Consideration section to clarify what protection steps the text refers to.</t>
                        <t>Updated the typ header discussion in

                            <xref target="JWTATHeader"/> to clarify that it helps preventing resources from accepting OpenID Connect ID Tokens as JWT access tokens.

                        </t>
                        <t>Updated refrences to token exchange, resource indicators and JWT best practices to reflect their RFC status (8693,8707,8725).

                    </t>
                    </list>
                </t>
                <t>
			 draft-ietf-oauth-access-token-jwt-03

                    <list style='symbols'>
                        <t>
							Varios typos fixed.
					</t>
                        <t>In the security considerations section, relaxed the claim that the typ header value "at+jwt" will prevent RS from misinterpreting JWT ATs as idtokens.</t>
                        <t>In the "Requesting JWT Access Tokens" section, added "invalid_target" as a possible error returned for the multiple resources request case.</t>
                        <t>In the Validating JWT Access Tokens" section, disallowed JWTs with "alg":"none"</t>
                        <t>in the IANA registration entries for the SCIM claim types, complemented the reference to the SCIM spec with a reference to this spec so that the eventual registration entries have better context.</t>
                        <t>Updated acknowledgements.</t>
                        <t>In the section

                            <xref target="JWTATLRequest"/>, the example request now has response_type=code.

                        </t>
                        <t>Updated text in the Privacy Consideration section to clarify what protection steps the text refers to.</t>
                    </list>
                </t>
                <t>
			 draft-ietf-oauth-access-token-jwt-02

                    <list style='symbols'>
                        <t>
							In 2.2.1, opened the sources of identity attributes to any identity related specification.
					</t>
                        <t>
							In 2.2.2, relaxed from MUST to SHOULD the requirement that requests including a scope always result in access tkens containing a corresponding scope claim.
					</t>
                        <t>
					In the security considerations setting, added a requirement for the authorization server to assing unique identifiers for different resources- to prevent cross JWT confusion.
					</t>
                        <t>
					Added IANA registration for the authorization attributes borrowed from SCIM CORE
					</t>
                    </list>
                </t>
                <t>
        draft-ietf-oauth-access-token-jwt-01

                    <list style='symbols'>
                        <t>
							Added note on authenticated encryption.
					</t>
                        <t>
					Added a mention to the 1st party clients scenarios in the identity claims section.
					</t>
                        <t>
			Changed the definition reference for the iss, exp, aud, sub, iat claims from OpenID.Core to RFC7519.
					</t>
                        <t>
					Added a mention of the client_id==sub case in the security considerations section, added a reference to draft-ietf-oauth-security-topics-13. Added a reference to the security considerations from the sub claim definition section.
					</t>
                        <t>
							Specified invalid_request as the error code the authorization server should return in case of multiple resources in the access token request.
					</t>
                        <t>Specified invalid_scope as the error code the authorization server should return in case it isn;t possible to determine to which resource the requested scopes refers to.</t>
                        <t>
					In the identity claims section, added a reference to introspection as possible source of claim types and added language explicitly stating that the AS can add arbitrary attributes as long as they are collision resistant or private.
					</t>
                        <t>
					Updated language for the auth_time claim to include the case in which the AS reauthenticates the user mid-session (e.g. during step up auth).
					</t>
                        <t>
							Removed note about adding a mechanism for extablishing whether the token was obtained on behalf or the resource owner or of the client itself (client credentials grant).
					</t>
                        <t>
							Removed note about adding a mechanism for indicating whether the authorization server sent the resource owner to authenticate with a federated identity provider, and the identity of that federated provider.
					</t>
                        <t>
							Removed the note in the security consideration sections about discussing the purpose of aud, iss, exp validation (redundant).
					</t>
                        <t>
					In the authorization claims section, stated intent to register roles, groups and entitlements as claim types in IANA
					</t>
                        <t>
					Clarified in the privacy considerations that clients should not inspect access tokens.
					</t>
                        <t>
					Expanded the privacy considerations with more explicit guidance about privacy preserving approaches.
					</t>
                        <t>Added IANA registry content for the at+JWT MIME type.
					</t>
                        <t>
            Updated acknowledgements.
					</t>
                    </list>
                </t>
                <t>
        draft-ietf-oauth-access-token-jwt-00

                    <list style='symbols'>
                        <t>
            Initial draft to define a JWTt profile for OAuth 2.0 access tokens.
					</t>
                    </list>
                </t>
                <?rfc subcompact="no"?>
    </section>
</back>
</rfc>