draft-ietf-oauth-jwt-introspection-response.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--
		This template is for creating an Internet Draft using xml2rfc, which
		is available here: http://xml.resource.org.
	-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!--
		For a complete list and description of processing instructions (PIs),
		please see http://xml.resource.org/authoring/README.html.
	-->
<!--
		Below are generally applicable Processing Instructions (PIs) that most
		I-Ds might want to use. (Here they are set differently than their
		defaults in xml2rfc v1.32)
	-->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!--
		control vertical white space (using these PIs as follows is
		recommended by the RFC Editor)
	-->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-oauth-jwt-introspection-response-07"
     ipr="trust200902">
  <!--
		category values: std, bcp, info, exp, and historic ipr values:
		full3667, noModification3667, noDerivatives3667 you can add the
		attributes updates="NNNN" and obsoletes="NNNN" they will automatically
		be output with "(if approved)"
	-->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!--
			The abbreviated title is used in the page header - it is only
			necessary if the full title is longer than 39 characters
		-->

    <title abbrev="JWT Response">JWT Response for OAuth Token Introspection</title>

    <author fullname="Torsten Lodderstedt" initials="T." role="editor"
            surname="Lodderstedt">
      <organization>yes.com AG</organization>

      <address>
        <email>torsten@lodderstedt.net</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
      </author>
          
    <author fullname="Vladimir Dzhuvinov" initials="V." 
            surname="Dzhuvinov">
      <organization>Connect2id Ltd.</organization>

      <address>
        <email>vladimir@connect2id.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date day="29" month="Aug" year="2019" />

    <!-- Meta-data Declarations -->

    <area>Security Area</area>

    <workgroup>Open Authentication Protocol</workgroup>

    <!--
			WG name at the upperleft corner of the doc, IETF is fine for
			individual submissions. If this element is not present, the default
			is "Network Working Group", which is used by the RFC Editor as a nod
			to the history of the IETF.
		-->

    <keyword>token introspection</keyword>
    
    <keyword>JWT</keyword>

    <keyword>oauth2</keyword>

    <!--
			Keywords will be incorporated into HTML output files in a meta tag
			but they have no effect on text or nroff output. If you submit your
			draft to the RFC Editor, the keywords will be used for the search
			engine.
		-->

    <abstract>
      <t>This draft proposes an additional JSON Web Token (JWT) based response 
      for OAuth 2.0 Token Introspection.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
      <t><xref target="RFC7662">OAuth 2.0 Token Introspection</xref> specifies a 
      method for a protected resource to query an OAuth 2.0 authorization server 
      to determine the state of an access token and obtain data associated with
      the access token.
      This allows deployments to implement identifier-based access tokens 
      in an interoperable way.</t>
      <t>The introspection response, as specified in <xref target="RFC7662">OAuth
      2.0 Token Introspection</xref>, is a plain JSON object.
      However, there are use cases where the resource server requires stronger
      assurance that the authorization server issued the access token,
      including cases where the authorization server assumes liability for the
      token's content. An example is a resource server using verified person
      data to create certificates, which in turn are used to create qualified 
      electronic signatures.</t>
      <t>In such use cases it may be useful or even required to return a
      signed JWT as the introspection response. This specification extends the
      token introspection endpoint with the capability to return responses as
      JWTs.</t>
       <section anchor="RNC" title="Requirements Notation and Conventions">
<t>
  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL"
  in this document are to be interpreted as described in
  BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
  when, and only when, they appear in all capitals, as shown here.
</t>
    </section>
    </section>

	<section anchor="jwt_request" title="Requesting a JWT Response">
	<t>A resource server requests to receive a JWT introspection response by
        including an Accept header with content type "application/jwt" in the
        introspection request.</t>

      <t>The following is a non-normative example request:</t>
	  <t>
	  	<figure>
          <artwork><![CDATA[POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/jwt
Content-Type: application/x-www-form-urlencoded

token=2YotnFZFEjr1zCsicMWpAA]]></artwork>
        </figure>
	  </t>
	</section>
	
    <section anchor="jwt_response" title="JWT Response">
      <t>The introspection endpoint responds with a JWT, setting the
          Content-Type header to "application/jwt".</t>
      <t>This JWT MUST contain the claims 
	  <spanx style="verb">iss</spanx> and <spanx style="verb">aud</spanx> in order to 
	  prevent misuse of the JWT as ID or access token 
	  (see <xref target="Cross-JWT_Confusion"/>).</t>
      <t>This JWT MAY furthermore contain all claims defined in the "OAuth Token 
      Introspection Response" registry established by <xref target="RFC7662"/>.</t>
      <t>The following is a non-normative example response 
      (with line breaks for display purposes only):</t>
	  <t>
	  	<figure>
          <artwork><![CDATA[HTTP/1.1 200 OK
Content-Type: application/jwt

eyJraWQiOiIxIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJaNU8zdXBQQzg4UXJBa
ngwMGRpcyIsImF1ZCI6Imh0dHBzOlwvXC9wcm90ZWN0ZWQuZXhhbXBsZS5uZXRcL
3Jlc291cmNlIiwiZXh0ZW5zaW9uX2ZpZWxkIjoidHdlbnR5LXNldmVuIiwic2Nvc
GUiOiJyZWFkIHdyaXRlIGRvbHBoaW4iLCJpc3MiOiJodHRwczpcL1wvc2VydmVyL
mV4YW1wbGUuY29tXC8iLCJhY3RpdmUiOnRydWUsImV4cCI6MTQxOTM1NjIzOCwia
WF0IjoxNDE5MzUwMjM4LCJjbGllbnRfaWQiOiJsMjM4ajMyM2RzLTIzaWo0Iiwid
XNlcm5hbWUiOiJqZG9lIn0.HEQHf05vqVvWVnWuEjbzUnPz6JDQVR69QkxgzBNq5
kk-sK54ieg1STazXGsdFAT8nUhiiV1f_Z4HOKNnBs8TLKaFXokhA0MqNBOYI--2u
nVHDqI_RPmC3p0NmP02Xmv4hzxFmTmpgjSy3vpKQDihOjhwNBh7G81JNaJqjJQTR
v_1dHUPJotQjMK3k8_5FyiO2p64Y2VyxyQn1VWVlgOHlJwhj6BaGHk4Qf5F8DHQZ
1WCPg2p_-hwfINfXh1_buSjxyDRF4oe9pKy6ZB3ejh9qIMm-WrwltuU1uWMXxN6e
S6tUtpKo8UCHBwLWCHmJN7KU6ZojmaISspdS23lELAlyw]]></artwork>
        </figure>	
        </t>
        <t>
        The example response contains the following JSON document:
        </t>
        <t>
        <figure>
          <artwork><![CDATA[{
  "sub": "Z5O3upPC88QrAjx00dis",
  "aud": "https://protected.example.net/resource",
  "scope": "read write dolphin",
  "iss": "https://server.example.com/",
  "active": true,
  "exp": 1419356238,
  "iat": 1419350238,
  "client_id": "l238j323ds-23ij4",
  "given_name": "John",
  "family_name":"Doe",
  "birthdate":"1982-02-01"
}]]></artwork>
        </figure>

	  </t>  
	  <t>Depending on the specific resource server policy the JWT is either
      signed, or signed and encrypted. If the JWT is signed and encrypted it
      MUST be a Nested JWT, as defined in <xref target="RFC7519">JWT</xref>.</t>
	  <t>Note: If the resource server policy requires a signed and encrypted
      response and the authorization server receives an unauthenticated request
	  containing an Accept header with content type other than "application/jwt", it MUST
      refuse to serve the request and return an HTTP status code 400. This is
      done to prevent downgrading attacks to obtain token data intended for
      release to legitimate recipients only 
      (see <xref target="token_data_leakage"/>).</t>
    </section>
    
    <section anchor="client_metadata" title="Client Metadata">
      <t>The authorization server determines what algorithm to employ to
      secure the JWT for a particular introspection response. This decision can
      be based on registered metadata parameters for the resource server,
      supplied via dynamic client registration with the resource server posing
      as the client, as defined by this draft.</t>
      <t>The parameter names follow the pattern established by
      <xref target="OpenID.Registration">OpenID Connect
      Dynamic Client Registration</xref> for configuring signing and encryption
      algorithms for JWT responses at the UserInfo endpoint.</t>
      <t>The following client metadata parameters are introduced by this
      specification:
		<list hangIndent="8" style="hanging">
      	  <t hangText="introspection_signed_response_alg">OPTIONAL. 
      	  <xref target="RFC7515">JWS</xref> 
      	  algorithm (<spanx style="verb">alg</spanx> value) as defined in 
      	  <xref target="RFC7518">JWA</xref> for signing introspection responses. If
      	  this is specified, the response will be signed using JWS and the 
      	  configured algorithm. The default, if omitted, is <spanx style="verb">RS256</spanx>.</t>
          <t hangText="introspection_encrypted_response_alg">OPTIONAL.
          <xref target="RFC7516">JWE</xref> algorithm (<spanx style="verb">alg</spanx> value) 
          as defined in <xref target="RFC7518">JWA</xref> for encrypting introspection responses.
          
          If this is specified, the response will be encrypted using JWE and the 
          configured algorithm. The default, if
           omitted, is that no encryption is performed.
          
          If both signing and 
          encryption are requested, the response will be 
          signed then encrypted, with the result being a Nested JWT, as defined in 
          <xref target="RFC7519">JWT</xref>.</t>
          <t hangText="introspection_encrypted_response_enc">OPTIONAL.
          <xref target="RFC7516">JWE</xref> algorithm (<spanx style="verb">enc</spanx> value) 
          as defined in <xref target="RFC7518">JWA</xref> for authenticated encryption of introspection responses. The default, if omitted, is <spanx style="verb">A128CBC-HS256</spanx>.
          Note: This parameter MUST NOT be specified without setting 
          <spanx style="verb">introspection_encrypted_response_alg</spanx>.</t>
        </list>
      </t>
     <t>Resource servers may register their public encryption keys 
      using the <spanx style="verb">jwks_uri</spanx> or <spanx style="verb">jwks</spanx> 
      metadata parameters.</t>
    </section>    
    
    <section anchor="server_metadata" title="Authorization Server Metadata">
      <t>Authorization servers SHOULD publish the supported algorithms for
      signing and encrypting the JWT of an introspection response by utilizing
      <xref target="RFC8414">OAuth 2.0 Authorization Server Metadata</xref>
      parameters.</t>
     <t>The following parameters are introduced by this specification: 
		<list hangIndent="8" style="hanging">
				
		<t hangText="introspection_signing_alg_values_supported">
		OPTIONAL. JSON array containing a list of the <xref target="RFC7515">JWS</xref> signing 
		algorithms (<spanx style="verb">alg</spanx> values) as defined in 
		<xref target="RFC7518">JWA</xref> supported by the introspection
		endpoint to sign the response.</t>

		<t hangText="introspection_encryption_alg_values_supported">
		OPTIONAL. JSON array containing a list of the <xref target="RFC7516">JWE</xref> 
		encryption algorithms (<spanx style="verb">alg</spanx> values) as defined in
		<xref target="RFC7518">JWA</xref> supported by the 
		introspection endpoint to encrypt the response.</t>

		<t hangText="introspection_encryption_enc_values_supported">
		OPTIONAL. JSON array containing a list of the <xref target="RFC7516">JWE</xref> encryption 
		algorithms (<spanx style="verb">enc</spanx> values) as defined in
		<xref target="RFC7518">JWA</xref> supported by the introspection
		endpoint to encrypt the response.</t>

        </list>
      </t>
    </section>
    
    <section anchor="Security" title="Security Considerations">
     <section anchor="Cross-JWT_Confusion" title="Cross-JWT Confusion">
      <t>JWT introspection responses and OpenID Connect ID Tokens are 
      syntactically similar. An attacker could therefore attempt to impersonate
      an end-user at a OpenID Connect relying party by passing the JWT as an ID
      token.</t>
      
      <t>Such an attack can be prevented like any other token substitution
      attack. The authorization server MUST include the claims
      <spanx style="verb">iss</spanx> and <spanx style="verb">aud</spanx> in
      each JWT introspection response, with the <spanx style="verb">iss</spanx> 
      value set to the authorization server's issuer URL and the 
      <spanx style="verb">aud</spanx> value set
      to the resource server's identifier. This allows a correctly implemented
      OpenID Connect relying party to detect substitution by checking the
      <spanx style="verb">iss</spanx> and
      <spanx style="verb">aud</spanx> claims as described in Section 3.1.3.7. of 
      <xref target="OpenID.Core"/>. Relying parties SHOULD also use and check
      the <spanx style="verb">nonce</spanx> parameter and claim to prevent
      token and code replay.</t>
      
      <t>Resource servers utilizing JWTs to represent self-contained access
      tokens could be susceptible to replay attacks. Resource servers
      should therefore apply proper counter measures against replay as 
      described in <xref target="I-D.ietf-oauth-security-topics"/>, 
      section 2.2.</t>
      <t>JWT Confusion and other attacks involving JWTs are discussed in
      <xref target="I-D.ietf-oauth-jwt-bcp"/>.</t>
           </section>

      <section anchor="token_data_leakage" title="Token Data Leakage">
     <t>The authorization server MUST use Transport Layer Security (TLS) 1.2 
      (or higher) per <xref target="RFC7525"/> in order to prevent token data leakage.</t>
      <t>To prevent introspection of leaked tokens and to present an additional
      security layer against token guessing attacks the authorization server
      may require all requests to the token introspection endpoint to be
      authenticated. As an alternative or as an addition to the authentication,
      the intended recipients may be set up for encrypted responses.</t>
      <t>In the latter case, confidentiality is ensured by the fact that only
      the legitimate recipient is able to decrypt the response.
      An attacker could try to circumvent this measure by requesting a plain 
      JSON response, using an Accept header with the content type set
      to, for example, "application/json" instead of "application/jwt". To prevent this
      attack the authorization server MUST NOT serve requests with content type
      other than "application/jwt" if the resource server is set up to receive 
      encrypted responses (see also <xref target="jwt_response"/>).</t>
      </section>

      <section anchor="confidential_token_data" title="Keeping Token Data Confidential from OAuth Clients">
      <t>Authorization servers with a policy that requires token data to be
      kept confidential from OAuth clients must require all requests to the
      token introspection endpoint to be authenticated. As an alternative or as
      an addition to the authentication, the intended recipients may be set up
      for encrypted responses.</t>
            </section>

      <section anchor="introspection_activity_audit" title="Logging and Audit of Introspection Activity">
      <t>Authorization servers with a policy that requires token introspection
      activity to be logged and audited must require all requests to the token
      introspection endpoint to be authenticated.</t>
      </section>
            
      <section title="Data Minimization">
      <t>The authorisation server determines the token data a resource server is 
      allowed to see based on the resource server’s client_id and suitable token data, 
      e.g. the scope value. </t>
      </section>

    </section>
    
    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>We would like to thank Petteri Stenius, Neil Madden, Filip Skokan, and Tony 
      Nadalin for their valuable feedback.</t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">  
      
      <section anchor="DynRegReg" title="OAuth Dynamic Client Registration Metadata Registration">
        <t>
          This specification requests registration of the following client metadata definitions
          in the IANA "OAuth Dynamic Client Registration Metadata" registry
          <xref target="IANA.OAuth.Parameters"/>
          established by <xref target="RFC7591"/>:
        </t>

        <section anchor="DynRegContents" title="Registry Contents">
          <t>
            <list style="symbols">
              <t>
                Client Metadata Name: <spanx style="verb">introspection_signed_response_alg</spanx>
              </t>
              <t>
                Client Metadata Description:
                String value indicating the client's desired introspection response 
                signing algorithm.
              </t>
              <t>
                Change Controller: IESG
              </t>
              <t>
                Specification Document(s): <xref target="client_metadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style="symbols">
              <t>
                Client Metadata Name: <spanx style="verb">introspection_encrypted_response_alg</spanx>
              </t>
              <t>
                Client Metadata Description:
                String value specifying the desired introspection response 
                encryption algorithm (alg value).
              </t>
              <t>
                Change Controller: IESG
              </t>
              <t>
                Specification Document(s): <xref target="client_metadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style="symbols">
              <t>
                Client Metadata Name: <spanx style="verb">introspection_encrypted_response_enc</spanx>
              </t>
              <t>
                Client Metadata Description:
                    String value specifying the desired introspection response 
                encryption algorithm (enc value).
              </t>
              <t>
                Change Controller: IESG
              </t>
              <t>
                Specification Document(s): <xref target="client_metadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>

        </section>
      </section>
      
      <section anchor="ietf-oauth-discoveryIANA" title="OAuth Authorization Server Metadata Registration">
      <t>
        This specification requests registration of the following values
        in the IANA "OAuth Authorization Server Metadata" registry
        <xref target="IANA.OAuth.Parameters"/> established by <xref target="RFC8414"/>.
      </t>
        <section title="Registry Contents">
          <t>
            <list style='symbols'>
              <t>Metadata Name: <spanx style="verb">introspection_signing_alg_values_supported</spanx></t>
              <t>Metadata Description: JSON array containing a list of algorithms supported 
              by the authorization server for introspection response signing.</t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s): <xref target="server_metadata"/> of [[ this specification ]]</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Metadata Name: <spanx style="verb">introspection_encryption_alg_values_supported</spanx></t>
              <t>Metadata Description: JSON array containing a list of algorithms supported 
              by the authorization server for introspection response encryption (alg value).</t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s): <xref target="server_metadata"/> of [[ this specification ]]</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Metadata Name: <spanx style="verb">introspection_encryption_enc_values_supported</spanx></t>
              <t>Metadata Description: JSON array containing a list of algorithms supported 
              by the authorization server for introspection response encryption (enc value).</t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s): <xref target="server_metadata"/> of [[ this specification ]]</t>             
            </list>
          </t>
        </section>
      </section>     
      
    <section anchor="ietf-oauth-introspectionIANA" title="OAuth Token Introspection Response">
     <t>
        This specification requests registration of the following claim values as defined 
        in <xref target="OpenID.Core"/>, Section 5.1, in the IANA "OAuth Token Introspection 
        Response" registry.
        <xref target="IANA.OAuth.Parameters"/> established by <xref target="RFC7662"/>.
      </t>
        <section title="Registry Contents">
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">name</spanx></t>
              <t>Description: End-User's full name in displayable form including all name 
              parts, possibly including titles and suffixes, ordered according to the 
              End-User's locale and preferences.</t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">given_name</spanx></t>
              <t>Description: Given name(s) or first name(s) of the End-User. 
              Note that in some cultures, people can have multiple given names; all can 
              be present, with the names being separated by space characters.</t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">family_name</spanx></t>
              <t>Description: Surname(s) or last name(s) of the End-User. Note that in 
              some cultures, people can have multiple family names or no family name; all 
              can be present, with the names being separated by space characters.</t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">middle_name</spanx></t>
              <t>Description: Middle name(s) of the End-User. Note that in some cultures, 
              people can have multiple middle names; all can be present, with the names 
              being separated by space characters. Also note that in some cultures, 
              middle names are not used.</t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">nickname</spanx></t>
              <t>Description: Casual name of the End-User that may or may not be the same 
              as the given_name. For instance, a nickname value of Mike might be returned 
              alongside a given_name value of Michael.</t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">preferred_username</spanx></t>
              <t>Description: Shorthand name by which the End-User wishes to be referred 
              to at the RP, such as janedoe or j.doe. This value MAY be any valid JSON 
              string including special characters such as @, /, or whitespace.</t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">profile</spanx></t>
              <t>Description:URL of the End-User's profile page. The contents of this Web 
              page SHOULD be about the End-User.</t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">picture</spanx></t>
              <t>Description: URL of the End-User's profile picture. This URL MUST refer 
              to an image file (for example, a PNG, JPEG, or GIF image file), rather than 
              to a Web page containing an image. Note that this URL SHOULD specifically 
              reference a profile photo of the End-User suitable for displaying when 
              describing the End-User, rather than an arbitrary photo taken by the 
              End-User.</t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">website</spanx></t>
              <t>Description: URL of the End-User's Web page or blog. This Web page SHOULD 
              contain information published by the End-User or an organization that the 
              End-User is affiliated with.</t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">email</spanx></t>
              <t>Description: End-User's preferred e-mail address. Its value MUST conform 
              to the <xref target="RFC5322"/> <spanx style="verb">addr-spec</spanx> syntax. </t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">email_verified</spanx></t>
              <t>Description: True if the End-User's e-mail address has been verified; 
              otherwise false. When this Claim Value is true, this means that the OP took 
              affirmative steps to ensure that this e-mail address was controlled by the 
              End-User at the time the verification was performed. The means by which an 
              e-mail address is verified is context-specific, and dependent upon the 
              trust framework or contractual agreements within which the parties are 
              operating. </t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">gender</spanx></t>
              <t>Description:End-User's gender. Values defined by this specification are 
              female and male. Other values MAY be used when neither of the defined 
              values are applicable. </t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">birthdate</spanx></t>
              <t>Description:Time the End-User's information was last updated. Its value 
              is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z 
              as measured in UTC until the date/time.</t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">zoneinfo</spanx></t>
              <t>Description: String from zoneinfo [zoneinfo] time zone database 
              representing the End-User's time zone. For example, Europe/Paris or 
              America/Los_Angeles. </t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">locale</spanx></t>
              <t>Description: End-User's locale, represented as a BCP47 [RFC5646] 
              language tag. This is typically an ISO 639-1 Alpha-2 <xref target="ISO639-1"/> 
              language code in lowercase and an ISO 3166-1 Alpha-2 <xref target="ISO3166-1"/>
              country code in 
              uppercase, separated by a dash. For example, en-US or fr-CA. As a 
              compatibility note, some implementations have used an underscore as 
              the separator rather than a dash, for example, en_US; Relying Parties 
              MAY choose to accept this locale syntax as well.</t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">phone_number</spanx></t>
              <t>Description: End-User's preferred telephone number. <xref target="E.164"/>
              is 
              RECOMMENDED as the format of this Claim, for example, +1 (425) 555-1212 or 
              +56 (2) 687 2400. If the phone number contains an extension, it is 
              RECOMMENDED that the extension be represented using the <xref target="RFC3966"/> 
              extension syntax, for example, +1 (604) 555-1234;ext=5678. </t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">phone_number_verified</spanx></t>
              <t>Description: True if the End-User's phone number has been verified; 
              otherwise false. When this Claim Value is true, this means that the OP 
              took affirmative steps to ensure that this phone number was controlled by 
              the End-User at the time the verification was performed. The means by which 
              a phone number is verified is context-specific, and dependent upon the 
              trust framework or contractual agreements within which the parties are 
              operating. When true, the phone_number Claim MUST be in <xref target="E.164"/> format and 
              any extensions MUST be represented in <xref target="RFC3966"/> format. </t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">address</spanx></t>
              <t>Description: End-User's preferred postal address. The value of the 
              address member is a JSON <xref target="RFC8259"/> structure containing some or all of 
              the members defined in <xref target="OpenID.Core"/>, Section 5.1.1. </t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Name: <spanx style="verb">updated_at</spanx></t>
              <t>Description: Time the End-User's information was last updated. Its value 
              is a JSON number representing the number of seconds from 
              1970-01-01T0:0:0Z as measured in UTC until the date/time. </t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s):<xref target="OpenID.Core"/>, Section 5.1</t>             
            </list>
          </t>
        </section>
      </section>     


    </section>
    
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.3966"?>       
      <?rfc include="reference.RFC.5322"?>
      <?rfc include="reference.RFC.7519"?>
      <?rfc include="reference.RFC.7525"?>
      <?rfc include="reference.RFC.8259"?>   
      <?rfc include="reference.RFC.7591"?>
      <?rfc include="reference.RFC.7662"?>
      <?rfc include="reference.RFC.7518"?>
      <?rfc include="reference.RFC.7515"?>
      <?rfc include="reference.RFC.7516"?>
      <?rfc include="reference.RFC.8174"?>
      <?rfc include="reference.RFC.8414"?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-oauth-jwt-bcp-06.xml'?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-oauth-security-topics-13.xml'?>
      
       <reference anchor="OpenID.Registration" target="https://openid.net/specs/openid-connect-registration-1_0.html">
        <front>
          <title>OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1</title>

		  <author fullname="Nat Sakimura">
            <organization>NRI</organization>
          </author>
          <author fullname="John Bradley">
            <organization>Ping Identity</organization>
          </author>
          <author fullname="Mike Jones">
            <organization>Microsoft</organization>
          </author>
          <date day="8" month="Nov" year="2014"/>
        </front>
      </reference>
      
       <reference anchor="OpenID.Core" target="http://openid.net/specs/openid-connect-core-1_0.html">
        <front>
          <title>OpenID Connect Core 1.0 incorporating errata set 1</title>

		  <author fullname="Nat Sakimura">
            <organization>NRI</organization>
          </author>
          <author fullname="John Bradley">
            <organization>Ping Identity</organization>
          </author>
          <author fullname="Mike Jones">
            <organization>Microsoft</organization>
          </author>
          <author fullname="Breno de Medeiros">
            <organization>Google</organization>
          </author>
          <author fullname="Chuck Mortimore">
            <organization>Salesforce</organization>
          </author>
          <date day="8" month="Nov" year="2014"/>
        </front>
      </reference>

<reference anchor="ISO3166-1" target="https://www.iso.org/standard/63545.html">
	<front>
	  <title>ISO 3166-1:1997. Codes for the representation of names of
	  countries and their subdivisions -- Part 1: Country codes</title>
	  <author fullname="International Organization for Standardization">
	    <organization abbrev="ISO">International Organization for
	    Standardization</organization>
	  </author>
	  <date year="2013" />
	</front>
</reference>

<reference anchor="ISO639-1" target="https://www.iso.org/standard/22109.html">
	<front>
	  <title>ISO 639-1:2002 Codes for the representation of names of languages 
	  -- part 1: Alpha-2 Code</title>
	  <author fullname="International Organization for Standardization">
	    <organization abbrev="ISO">International Organization for
	    Standardization</organization>
	  </author>
	  <date year="2002" />
	</front>
</reference>

<reference anchor="E.164" target="https://www.itu.int/rec/T-REC-E.164-201011-I/en">
	<front>
	  <title>E.164: The international public telecommunication numbering plan</title>
	  <author fullname="International Organization for Standardization">
	    <organization abbrev="ITU">International Telecommunication Union</organization>
	  </author>
	  <date year="2010" />
	</front>
</reference>

    </references>

    <references title="Informative References">
          <reference anchor="IANA.OAuth.Parameters" target="http://www.iana.org/assignments/oauth-parameters">
        <front>
          <title>OAuth Parameters</title>
          <author>
            <organization>IANA</organization>
          </author>
          <date/>
        </front>
      </reference>
    </references> 
    
    <section anchor="History" title="Document History">
      <t>[[ To be removed from the final specification ]]</t>
      
	  <t>-07<list style="symbols">
          <t>fixed wrong description of "locale"</t>
          <t>added references for ISO and ITU specifications</t>
        </list>
      </t>     
      
	  <t>-06<list style="symbols">
          <t>replaced reference to RFC 7159 with reference to RFC 8259</t>
        </list>
      </t> 
      
	  <t>-05<list style="symbols">
          <t>improved wording for TLS requirement</t>
          <t>added RFC 2119 boilerplate</t>
          <t>fixed and updated some references</t>
        </list>
      </t> 
      
	  <t>-04<list style="symbols">
          <t>reworked definition of parameters in section 4</t>
          <t>added text on data minimization to security considerations section</t>
          <t>added statement regarding TLS to security considerations section</t>
        </list>
      </t> 
      
	  <t>-03<list style="symbols">
          <t>added registration for OpenID Connect Standard Claims to 
          OAuth Token Introspection Response registry</t>
        </list>
      </t> 
	  <t>-02<list style="symbols">
          <t>updated references</t>
        </list>
      </t> 
	  <t>-01<list style="symbols">
          <t>adapted wording to preclude any accept header except "application/jwt" if 
          encrypted responses are required</t>
          <t>use registered alg value RS256 for default signing algorithm</t>
          <t>added text on claims in the token introspection response</t>
        </list>
      </t>        
	  <t>-00<list style="symbols">
          <t>initial version of the WG draft</t>   
          <t>defined default signing algorithm</t>
          <t>changed behavior in case resource server is set up for encryption</t> 
          <t>Added text on token data leakage prevention to the security considerations</t>
          <t>moved Security Considerations section forward</t>
        </list>
      </t>   
      <t>WG draft</t>
      <t>-01<list style="symbols">
      	  <t>fixed typos in client meta data field names</t>
      	  <t>added OAuth Server Metadata parameters to publish algorithms supported 
      	  for signing and encrypting the introspection response</t>
      	  <t>added registration of new parameters for OAuth Server Metadata
      	  and Client Registration</t>
      	  <t>added explicit request for JWT introspection response</t>
      	  <t>made iss and aud claims mandatory in introspection response</t>
      	  <t>Stylistic and clarifying edits, updates references</t>
        </list></t> 
      <t>-00<list style="symbols">
          <t>initial version</t>
        </list></t>  
        
    </section>	
  </back>
</rfc>