openid-connect-core-1_0.xml

<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml2rfc.tools.ietf.org/authoring/rfc2629.dtd">
<!--
  NOTE:  This XML file is input used to produce the authoritative copy of an
  OpenID Foundation specification.  The authoritative copy is the HTML output.
  This XML source file is not authoritative.  The statement ipr="none" is
  present only to satisfy the document compilation tool and is not indicative
  of the IPR status of this specification.  The IPR for this specification is
  described in the "Notices" section.  This is a public OpenID Foundation
  document and not a private document, as the private="..." declaration could
  be taken to indicate.
-->
<rfc category="std" docName="openid-connect-core-1_0" ipr="none">

  <?rfc toc="yes" ?>
  <?rfc tocdepth="5" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc strict="yes" ?>
  <?rfc iprnotified="no" ?>
  <?rfc private="Draft" ?>

  <front>
    <title abbrev="OpenID Connect Core 1.0">OpenID Connect Core 1.0 - draft 27 incorporating errata set 2</title>

    <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
      <organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</organization>
      <address>
        <email>nat@nat.consulting</email>
	<uri>http://nat.sakimura.org/</uri>
      </address>
    </author>

    <author fullname="John Bradley" initials="J." surname="Bradley">
      <organization abbrev="Yubico (was at Ping Identity)">Yubico</organization>
      <address>
        <email>ve7jtb@ve7jtb.com</email>
	<uri>http://www.thread-safe.com/</uri>
      </address>
    </author>

    <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
      <organization abbrev="Microsoft">Microsoft</organization>
      <address>
        <email>mbj@microsoft.com</email>
	<uri>http://self-issued.info/</uri>
      </address>
    </author>

    <author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
      <organization abbrev="Google">Google</organization>
      <address>
        <email>breno@google.com</email>
	<uri>http://stackoverflow.com/users/311376/breno</uri>
      </address>
    </author>

    <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
      <organization abbrev="VISA (was at Salesforce)">VISA</organization>
      <address>
        <email>charliemortimore@gmail.com</email>
	<uri>https://twitter.com/cmort</uri>
      </address>
    </author>

    <date day="7" month="August" year="2020" />

    <workgroup>OpenID Connect Working Group</workgroup>

    <abstract>
      <t>OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
      protocol. It enables Clients to verify the identity of the End-User based
      on the authentication performed by an Authorization Server, as well as to
      obtain basic profile information about the End-User in an interoperable and 
      REST-like manner.</t>

      <t>
	This specification defines
	the core OpenID Connect functionality:
	authentication built on top of OAuth 2.0 and
	the use of Claims to communicate information about the End-User.
	It also describes the security and privacy considerations for using OpenID Connect.
      </t>
    </abstract>
  </front>

  <middle>
    <section anchor='Introduction' title='Introduction'>

      <t>
	OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
	<xref target="RFC6749"/>
	protocol. It enables Clients to verify the identity of the End-User based
	on the authentication performed by an Authorization Server, as well as to
	obtain basic profile information about the End-User in an interoperable and 
	REST-like manner.
      </t>
      <t>
	The OpenID Connect Core 1.0 specification defines
	the core OpenID Connect functionality:
	authentication built on top of OAuth 2.0 and
	the use of Claims to communicate information about the End-User.
	It also describes the security and privacy considerations for using OpenID Connect.
      </t>

      <t>
	As background,
	the <xref target="RFC6749">OAuth 2.0 Authorization Framework</xref>
	and <xref target="RFC6750">OAuth 2.0 Bearer Token Usage</xref>
	specifications provide a general framework for third-party applications
	to obtain and use limited access to HTTP resources.  They define
	mechanisms to obtain and use Access Tokens to access resources but
	do not define standard methods to provide identity information.
	Notably, without profiling OAuth 2.0, it is incapable of
	providing information about the authentication of an End-User.
	Readers are expected to be familiar with these specifications.
      </t>
      <t>
	OpenID Connect implements authentication as an extension to the
	OAuth 2.0 authorization process.
	Use of this extension is requested by Clients by including
	the <spanx style="verb">openid</spanx> scope value
	in the Authorization Request.
	Information about the authentication performed is returned
	in a <xref target="JWT">JSON Web Token (JWT)</xref>
	called an ID Token (see <xref target="IDToken"/>).
	OAuth 2.0 Authentication Servers implementing OpenID Connect
	are also referred to as OpenID Providers (OPs).
	OAuth 2.0 Clients using OpenID Connect
	are also referred to as Relying Parties (RPs).
      </t>
      <t>
	This specification assumes that the Relying Party has already obtained
	configuration information about the OpenID Provider, including its
	Authorization Endpoint and Token Endpoint locations.
	This information is normally obtained via Discovery,
	as described in <xref target="OpenID.Discovery">OpenID Connect Discovery 1.0</xref>,
	or may be obtained via other mechanisms.
      </t>
      <t>
	Likewise, this specification assumes that the Relying Party has already obtained
	sufficient credentials and provided information needed to use the OpenID Provider.
	This is normally done via Dynamic Registration,
	as described in
	<xref target="OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</xref>,
	or may be obtained via other mechanisms.
      </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 <xref
	target="RFC2119">RFC 2119</xref>.</t>

	<t>
	  In the .txt version of this document,
	  values are quoted to indicate that they are to be taken literally.
	  When using these values in protocol messages,
	  the quotes MUST NOT be used as part of the value.
	  In the HTML version of this document,
	  values to be taken literally are indicated by
	  the use of <spanx style="verb">this fixed-width font</spanx>.
	</t>
	<t>
	  All uses of <xref target="JWS">JSON Web Signature (JWS)</xref>
	  and <xref target="JWE">JSON Web Encryption (JWE)</xref>
	  data structures in this specification utilize
	  the JWS Compact Serialization or the JWE Compact Serialization;
	  the JWS JSON Serialization and the JWE JSON Serialization are not used.
	</t>
      </section>

      <section anchor="Terminology" title="Terminology">
        <t>
	  This specification uses the terms "Access Token", "Authorization Code",
	  "Authorization Endpoint", "Authorization Grant", "Authorization Server",
	  "Client", "Client Authentication", "Client Identifier", "Client Secret",
	  "Grant Type", "Protected Resource", "Redirection URI", "Refresh Token",
	  "Resource Owner", "Resource Server", "Response Type", and "Token Endpoint"
	  defined by <xref target="RFC6749">OAuth 2.0</xref>,
	  the terms "Claim Name", "Claim Value", "JSON Web Token (JWT)",
	  "JWT Claims Set", and "Nested JWT"
	  defined by <xref target="JWT">JSON Web Token (JWT)</xref>,
	  the terms "Header Parameter" and "JOSE Header"
	  defined by <xref target="JWS">JSON Web Signature (JWS)</xref>,
	  the term "User Agent" defined by <xref target="RFC7230">RFC 7230</xref>,
	  and the term "Response Mode" defined by
	  <xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref>.
        </t>
        <t>
          This specification also defines the following terms:
          <list style="hanging">
            <t hangText="Authentication">
	      <vspace/>
	      Process used to achieve sufficient confidence in the binding
	      between the Entity and the presented Identity.
	    </t>
            <t hangText="Authentication Request">
	      <vspace/>
	      OAuth 2.0 Authorization Request using extension parameters and scopes
	      defined by OpenID Connect to request that the End-User be authenticated
	      by the Authorization Server, which is an OpenID Connect Provider,
	      to the Client, which is an OpenID Connect Relying Party.
	    </t>

            <t hangText="Authentication Context">
	      <vspace/>
              Information that the Relying Party can require before it makes an 
              entitlement decision with respect to an authentication response. 
              Such context can include, but is not limited to, the actual 
              authentication method used or level of assurance such as 
              <xref target="ISO29115">ISO/IEC 29115</xref> 
              entity authentication assurance level.
            </t>

            <t hangText="Authentication Context Class">
	      <vspace/>
              Set of authentication methods or procedures that are considered
	      to be equivalent to each other in a particular context.
            </t>

            <t hangText="Authentication Context Class Reference">
	      <vspace/>
              Identifier for an Authentication Context Class. 
            </t>

            <t hangText="Authorization Code Flow">
	      <vspace/>
              OAuth 2.0 flow in which
	      an Authorization Code is returned from the Authorization Endpoint and
	      all tokens are returned from the Token Endpoint.
            </t>

            <t hangText="Authorization Request">
	      <vspace/>
              OAuth 2.0 Authorization Request as defined by <xref target="RFC6749"/>.
            </t>

            <t hangText="Claim">
	      <vspace/>
	      Piece of information asserted about an Entity.
	    </t>

	    <t hangText="Claim Type">
	      <vspace/>
	      Syntax used for representing a Claim Value.
	      This specification defines Normal, Aggregated, and Distributed Claim Types.
	    </t>

            <t hangText="Claims Provider">
	      <vspace/>
	      Server that can return Claims about an Entity.
	    </t>

	    <t hangText="Credential">
	      <vspace/>
	      Data presented as evidence of the right to use an identity
	      or other resources.
	    </t>

            <t hangText="End-User">
	      <vspace/>
              Human participant.
            </t>
            <t hangText="Entity">
	      <vspace/>
              Something that has a separate and distinct existence and that can be
	      identified in a context. An End-User is one example of an Entity.
            </t>

            <t hangText="Essential Claim">
	      <vspace/>
              Claim specified by the Client as being necessary to ensure a smooth
	      authorization experience for the specific task requested by the End-User.
            </t>

            <t hangText="Hybrid Flow">
	      <vspace/>
              OAuth 2.0 flow in which
	      an Authorization Code is returned from the Authorization Endpoint,
	      some tokens are returned from the Authorization Endpoint,
	      and others are returned from the Token Endpoint.
            </t>

            <t hangText="ID Token">
	      <vspace/>
              <xref target="JWT">JSON Web Token (JWT)</xref> that contains Claims about the Authentication event.
	      It MAY contain other Claims.
            </t>

            <t hangText="Identifier">
	      <vspace/>
	     Value that uniquely characterizes an Entity in a specific context.
	    </t>

            <t hangText="Identity">
	      <vspace/>
	      Set of attributes related to an Entity.
	    </t>

            <t hangText="Implicit Flow">
	      <vspace/>
              OAuth 2.0 flow in which all tokens are returned from the Authorization Endpoint
	      and neither the Token Endpoint nor an Authorization Code are used.
            </t>

            <t hangText="Issuer">
	      <vspace/>
	      Entity that issues a set of Claims.
	    </t>

            <t hangText="Issuer Identifier">
	      <vspace/>
	      Verifiable Identifier for an Issuer.
	      An Issuer Identifier is a case-sensitive URL
	      using the <spanx style="verb">https</spanx> scheme that
	      contains scheme, host, and optionally, port number and path
	      components and no query or fragment components.
	    </t>

            <t hangText="Message">
	      <vspace/>
	      Request or a response between an OpenID 
	      Relying Party and an OpenID Provider.
	    </t>

            <t hangText="OpenID Provider (OP)">
	      <vspace/>
              OAuth 2.0 Authorization Server that is capable of
	      Authenticating the End-User and
              providing Claims to a Relying Party
              about the Authentication event and the End-User. 
            </t>

            <t hangText="Request Object">
	      <vspace/>
	      JWT that contains a set of request parameters as its Claims.
	    </t>

	    <t hangText="Request URI">
	      <vspace/>
	      URL that references a resource containing a Request Object.
	      The Request URI contents MUST be retrievable by the
	      Authorization Server.
	    </t>

            <t hangText="Pairwise Pseudonymous Identifier (PPID)">
	      <vspace/>
	      Identifier that identifies the Entity to a Relying Party that cannot be correlated 
	      with the Entity's PPID at another Relying Party.
	    </t>

            <t hangText="Personally Identifiable Information (PII)">
	      <vspace/>
              Information that (a) can be used to identify the natural person
              to whom such information relates, or
              (b) is or might be directly or indirectly linked to a
	      natural person to whom such information relates.
	    </t>

            <t hangText="Relying Party (RP)">
	      <vspace/>
              OAuth 2.0 Client application requiring End-User Authentication
	      and Claims from an OpenID Provider.
            </t>

	    <t hangText="Sector Identifier">
	      <vspace/>
	      Host component of a URL used by the Relying Party's organization
	      that is an input to the computation of pairwise Subject Identifiers
	      for that Relying Party.
	    </t>

	    <t hangText="Self-Issued OpenID Provider">
	      <vspace/>
	      Personal, self-hosted OpenID Provider that issues self-signed ID Tokens.
	    </t>

	    <t hangText="Subject Identifier">
	      <vspace/>
	      Locally unique and never
	      reassigned identifier within the Issuer for the End-User, 
	      which is intended to be consumed by the Client.
	    </t>

            <t hangText="UserInfo Endpoint">
	      <vspace/>
              Protected Resource that, when presented with an Access Token by the Client,
	      returns authorized information about the End-User represented by the corresponding 
              Authorization Grant.
	      The UserInfo Endpoint
	      URL MUST use the <spanx style="verb">https</spanx> scheme and MAY contain
	      port, path, and query parameter components.

            </t>
 
            <t hangText="Validation">
	      <vspace/>
	      Process intended to establish the soundness or correctness of a construct.
	    </t>

            <t hangText="Verification">
	      <vspace/>
	      Process intended to test or prove the truth or accuracy of a fact or value.
	    </t>

            <t hangText="Voluntary Claim">
	      <vspace/>
              Claim specified by the Client as being useful but not Essential
              for the specific task requested by the End-User.
            </t>

          </list>
        </t>
	<t>
	  IMPORTANT NOTE TO READERS: The terminology definitions in
	  this section are a normative portion of this specification,
	  imposing requirements upon implementations.  All the
	  capitalized words in the text of this specification, such as
	  "Issuer Identifier", reference these defined terms.
	  Whenever the reader encounters them, their definitions
	  found in this section must be followed.
	</t>
	<t>
	  For more background on some of the terminology used,
	  see <xref target="RFC4949">Internet Security Glossary, Version 2</xref>,
	  <xref target="ISO29115">ISO/IEC 29115 Entity Authentication Assurance</xref>,
	  and <xref target="X.1252">ITU-T X.1252</xref>.
	</t>
      </section>

      <section anchor="Overview" title="Overview">

	<t>The OpenID Connect protocol, in abstract, follows the following
	steps.</t>

	<t>
	  <list style="numbers">
	    <t>The RP (Client) sends a request to the OpenID Provider (OP).</t>

	    <t>The OP authenticates the End-User and obtains authorization.</t>

	    <t>The OP responds with an ID Token and usually an Access Token.</t>
	    
	    <t>The RP can send a request with the Access Token to the UserInfo Endpoint.</t>

	    <t>The UserInfo Endpoint returns Claims about the End-User.</t>

	  </list>
	</t>
	
	<figure>
	  <preamble>
	    These steps are illustrated in the following diagram:
	  </preamble>

	  <artwork><![CDATA[
+--------+                                   +--------+ 
|        |                                   |        |
|        |---------(1) AuthN Request-------->|        |
|        |                                   |        |
|        |  +--------+                       |        |
|        |  |        |                       |        |
|        |  |  End-  |<--(2) AuthN & AuthZ-->|        |
|        |  |  User  |                       |        |
|   RP   |  |        |                       |   OP   |
|        |  +--------+                       |        |
|        |                                   |        |
|        |<--------(3) AuthN Response--------|        |
|        |                                   |        |
|        |---------(4) UserInfo Request----->|        |
|        |                                   |        |
|        |<--------(5) UserInfo Response-----|        |
|        |                                   |        |
+--------+                                   +--------+
]]></artwork>
	</figure>

      </section>
    </section>

    <section anchor="IDToken" title="ID Token">

      <t>
	The primary extension that OpenID Connect makes to OAuth 2.0
	to enable End-Users to be Authenticated
	is the ID Token data structure.
	The ID Token is a security token that contains Claims about the
	Authentication of an End-User by an Authorization Server when using a Client,
	and potentially other requested Claims.
	The ID Token is represented as a
	<xref target="JWT">JSON Web Token (JWT)</xref>.
      </t>
      <t>
	The following Claims are used within the ID Token
	for all OAuth 2.0 flows used by OpenID Connect:
      </t>

      <t>
	<list style="hanging">
	  <t hangText="iss">
	    <vspace/>
	    REQUIRED.
	    Issuer Identifier for the Issuer of the response.
	    The <spanx style="verb">iss</spanx> value is a case-sensitive URL
	    using the <spanx style="verb">https</spanx> scheme that
	    contains scheme, host, and optionally, port number and path
	    components and no query or fragment components.
	  </t>

	  <t hangText="sub">
	    <vspace/>
	    REQUIRED.
	    Subject Identifier.  A locally unique and never
	    reassigned identifier within the Issuer for the End-User, 
	    which is intended to be consumed by the Client,
	    e.g., <spanx style="verb">24400320</spanx>
	    or <spanx style="verb">AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4</spanx>.
	    It MUST NOT exceed 255 ASCII <xref target="RFC20"/> characters in length.
	    The <spanx style="verb">sub</spanx> value is a case-sensitive string.
	  </t>

	  <t hangText="aud">
	    <vspace/>
	    REQUIRED.
	    Audience(s) that this ID Token is intended for.
	    It MUST contain the OAuth 2.0 <spanx style="verb">client_id</spanx>
	    of the Relying Party as an audience value.
	    It MAY also contain identifiers for other audiences.
	    In the general case,
	    the <spanx style="verb">aud</spanx> value is an array of
	    case-sensitive strings.
	    In the common special case when there is one audience,
	    the <spanx style="verb">aud</spanx> value MAY be a single
	    case-sensitive string.
	  </t>

	  <t hangText="exp">
	    <vspace/>
	    REQUIRED.
	    Expiration time on or after which the ID Token MUST NOT be
	    accepted by the RP when performing authentication with the OP.
	    The processing of this parameter
	    requires that the current date/time MUST be before the
	    expiration date/time listed in the value. Implementers MAY
	    provide for some small leeway, usually no more than a few
	    minutes, to account for clock skew.
	    Its value is a JSON <xref target="RFC7159"/> number representing the number of seconds from
	    1970-01-01T00:00:00Z as measured in UTC until the date/time.
	    See <xref target="RFC3339">RFC 3339</xref>
	    for details regarding date/times in general and UTC in
	    particular.
	    NOTE:  The ID Token expiration time is unrelated the lifetime of
	    the authenticated session between the RP and the OP.
	  </t>
	  
	  <t hangText="iat">
	    <vspace/>
	    REQUIRED.
	    Time at which the JWT was issued.
	    Its value is a JSON number representing the number of seconds from
	    1970-01-01T00:00:00Z as measured in UTC until the date/time.
	  </t>

	  <t hangText="auth_time">
	    <vspace/>
	    Time when the End-User authentication occurred.
	    Its value is a JSON number representing the number of seconds from
	    1970-01-01T00:00:00Z as measured in UTC until the date/time.
	    When a <spanx style="verb">max_age</spanx> request is made
	    or when <spanx style="verb">auth_time</spanx> is requested
	    as an Essential Claim,
	    then this Claim is REQUIRED; otherwise, its inclusion is OPTIONAL.
	    (The <spanx style="verb">auth_time</spanx> Claim semantically
	    corresponds to the OpenID 2.0 <xref target="OpenID.PAPE">PAPE</xref> 
	    <spanx style="verb">auth_time</spanx> response parameter.)
	  </t>

	  <t hangText="nonce">
	    <vspace/>
	    String value used to associate a Client session 
	    with an ID Token, and to mitigate replay attacks. 
	    The value is passed through unmodified from the Authentication Request to the ID Token.
	    If present in the ID Token,
	    Clients MUST verify that
	    the <spanx style="verb">nonce</spanx> Claim Value is equal to
	    the value of the <spanx style="verb">nonce</spanx>
	    parameter sent in the Authentication Request.
	    If present in the Authentication Request, Authorization Servers
	    MUST include a <spanx style="verb">nonce</spanx> Claim in the
	    ID Token with the Claim Value
	    being the nonce value sent in the Authentication Request.
	    Authorization Servers SHOULD perform no other processing
	    on <spanx style="verb">nonce</spanx> values used.
	    The <spanx style="verb">nonce</spanx> value is a case-sensitive string.
	  </t>

	  <t hangText="acr">
	    <vspace/>
	    OPTIONAL.
	    Authentication Context Class Reference.
	    String specifying an Authentication Context Class Reference value
	    that identifies the Authentication Context Class that the
	    authentication performed satisfied.
	    The value "0" indicates the End-User authentication
	    did not meet the requirements of
	    <xref target="ISO29115">ISO/IEC 29115</xref> level 1.
	    For historic reasons, the value "0" is used to indicate that
	    there is no confidence that the same person is actually there.
	    Authentications with
	    level 0 SHOULD NOT be used to authorize access to any resource of any 
	    monetary value.  
	    (This corresponds to the OpenID 2.0
	    <xref target="OpenID.PAPE">PAPE</xref> 
	    <spanx style="verb">nist_auth_level</spanx> 0.)
	    An absolute URI or an <xref target="RFC6711">RFC 6711</xref>
	    registered name
	    SHOULD be used as the <spanx style="verb">acr</spanx> value;
	    registered names MUST NOT be used with a different meaning than
	    that which is registered.
	    Parties using this claim will need to agree upon the meanings of
	    the values used, which may be context specific.
	    The <spanx style="verb">acr</spanx> value is a case-sensitive string.
	  </t>

	  <t hangText="amr">
	    <vspace/>
	    OPTIONAL.
	    Authentication Methods References.
	    JSON array of strings that are identifiers for authentication methods
	    used in the authentication.
	    For instance, values might indicate that both password and OTP
	    authentication methods were used.
	    The definition of particular values to be used in the
	    <spanx style="verb">amr</spanx> Claim
	    is beyond the scope of this specification.
	    Parties using this claim will need to agree upon the meanings of
	    the values used, which may be context specific.
	    The <spanx style="verb">amr</spanx> value is an array of
	    case-sensitive strings.
	  </t>

	  <t hangText="azp">
	    <vspace/>
	    OPTIONAL.
	    Authorized party - the party to which the ID Token was issued.
	    If present, it MUST contain the OAuth 2.0
	    Client ID of this party.
	    This Claim is only needed when
	    the ID Token has a single audience value
	    and that audience is different than the authorized party.
	    It MAY be included even when the authorized party is the same
	    as the sole audience.
	    The <spanx style="verb">azp</spanx> value is a case-sensitive string
	    containing a StringOrURI value.
	  </t>

	</list>
      </t>

      <t>
	ID Tokens MAY contain other Claims.
	Any Claims used that are not understood MUST be ignored.
	See Sections
	<xref target="CodeIDToken" format="counter"/>,
	<xref target="HybridIDToken" format="counter"/>,
	<xref target="StandardClaims" format="counter"/>, and
	<xref target="SelfIssuedResponse" format="counter"/>
	for additional Claims defined by this specification.
      </t>
      <t>
	ID Tokens MUST be signed using <xref
	target="JWS">JWS</xref> and optionally both signed and then
	encrypted using <xref target="JWS">JWS</xref> and <xref
	target="JWE">JWE</xref> respectively, thereby providing
	authentication, integrity,
	non-repudiation, and optionally, confidentiality,
	per <xref target="SigningOrder"/>.
	If the ID Token is encrypted, it MUST be signed then encrypted,
	with the result being a Nested JWT, as defined in <xref target="JWT"/>.
	ID Tokens MUST NOT use <spanx style="verb">none</spanx>
	as the <spanx style="verb">alg</spanx> value
	unless the Response Type used returns no ID Token from the
	Authorization Endpoint
	(such as when using the Authorization Code Flow)
	and the Client explicitly requested the use of
	<spanx style="verb">none</spanx> at Registration time.
      </t>
      <t>
	ID Tokens SHOULD NOT use the JWS or JWE
	<spanx style="verb">x5u</spanx>,
	<spanx style="verb">x5c</spanx>,
	<spanx style="verb">jku</spanx>, or
	<spanx style="verb">jwk</spanx>
	Header Parameter fields.
	Instead, references to keys used are
	communicated in advance using Discovery and Registration parameters,
	per <xref target="SigEnc"/>.
      </t>

      <figure>
	<preamble>
	  The following is a non-normative example of
	  the set of Claims (the JWT Claims Set) in an ID Token:
	</preamble>

	<artwork><![CDATA[
  {
   "iss": "https://server.example.com",
   "sub": "24400320",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "auth_time": 1311280969,
   "acr": "urn:mace:incommon:iap:silver"
  }
]]></artwork>
      </figure>

    </section>

    <section anchor="Authentication" title="Authentication">
      <t>
	OpenID Connect performs authentication to log in the End-User
	or to determine that the End-User is already logged in.
	OpenID Connect returns the result of the Authentication
	performed by the Server to the Client in a secure manner
	so that the Client can rely on it.
	For this reason, the Client is called Relying Party (RP) in this case.
      </t>
      <t>
	The Authentication result is returned in an
	ID Token, as defined in <xref target="IDToken"/>.
	It has Claims expressing such information as the Issuer,
	the Subject Identifier, when the authentication was performed, etc.
      </t>
      <t>
	Authentication can follow one of three paths:
	the Authorization Code Flow (<spanx style="verb">response_type=code</spanx>),
	the Implicit Flow (<spanx style="verb">response_type=id_token&nbsp;token</spanx>
	or <spanx style="verb">response_type=id_token</spanx>), or
	the Hybrid Flow (using other Response Type values defined in
	<xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref>).
	The flows determine how the ID Token and Access Token
	are returned to the Client.
      </t>
      <t>
	The characteristics of the three flows are summarized
	in the following non-normative table.
	The table is intended to provide some guidance on which flow to choose
	in particular contexts.
      </t>

      <texttable title="OpenID Connect Authentication Flows">

	<ttcol>Property</ttcol>
	<ttcol>Authorization Code Flow</ttcol>
	<ttcol>Implicit Flow</ttcol>
	<ttcol>Hybrid Flow</ttcol>

	<c>All tokens returned from Authorization Endpoint</c>
	<c>no</c>
	<c>yes</c>
	<c>no</c>

	<c>All tokens returned from Token Endpoint</c>
	<c>yes</c>
	<c>no</c>
	<c>no</c>

	<c>Tokens not revealed to User Agent</c>
	<c>yes</c>
	<c>no</c>
	<c>no</c>

	<c>Client can be authenticated</c>
	<c>yes</c>
	<c>no</c>
	<c>yes</c>

	<c>Refresh Token possible</c>
	<c>yes</c>
	<c>no</c>
	<c>yes</c>

	<c>Communication in one round trip</c>
	<c>no</c>
	<c>yes</c>
	<c>no</c>

	<c>Most communication server-to-server</c>
	<c>yes</c>
	<c>no</c>
	<c>varies</c>

      </texttable>

      <t>
	The flow used is determined by the <spanx style="verb">response_type</spanx>
	value contained in the Authorization Request.
	These <spanx style="verb">response_type</spanx> values select
	these flows:
      </t>

      <texttable title='OpenID Connect "response_type" Values'>
	<ttcol>"response_type" value</ttcol>
	<ttcol>Flow</ttcol>

	<c><spanx style="verb">code</spanx></c>
	<c>Authorization Code Flow</c>

	<c><spanx style="verb">id_token</spanx></c>
	<c>Implicit Flow</c>

	<c><spanx style="verb">id_token&nbsp;token</spanx></c>
	<c>Implicit Flow</c>

	<c><spanx style="verb">code&nbsp;id_token</spanx></c>
	<c>Hybrid Flow</c>
	
	<c><spanx style="verb">code&nbsp;token</spanx></c>
	<c>Hybrid Flow</c>

	<c><spanx style="verb">code&nbsp;id_token&nbsp;token</spanx></c>
	<c>Hybrid Flow</c>

      </texttable>
      <t>
	All but the <spanx style="verb">code</spanx> Response Type value,
	which is defined by <xref target="RFC6749">OAuth 2.0</xref>,
	are defined in the
	<xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref>
	specification.
	NOTE:  While OAuth 2.0 also defines the
	<spanx style="verb">token</spanx> Response Type value
	for the Implicit Flow, OpenID Connect does not use this Response Type,
	since no ID Token would be returned.
      </t>

      <section anchor="CodeFlowAuth" title="Authentication using the Authorization Code Flow">
	<t>
	  This section describes how to perform authentication using the Authorization Code Flow.
	  When using the Authorization Code Flow,
	  all tokens are returned from the Token Endpoint.
	</t>

	<t>The Authorization Code Flow returns an Authorization Code to the
	Client, which can then exchange it for an ID Token and an Access Token directly.
	This provides the benefit of not exposing any tokens to the 
	User Agent and possibly other malicious applications with access
	to the User Agent.
	The Authorization Server can also
	authenticate the Client before exchanging the Authorization Code for an
	Access Token. The Authorization Code flow is suitable for Clients that 
	can securely maintain a Client Secret between themselves and the
	Authorization Server.</t>

	<section anchor="CodeFlowSteps" title="Authorization Code Flow Steps">
	  <t>The Authorization Code Flow goes through the following
	  steps.</t>          
	  <t>
	    <list style="numbers">
	      <t>Client prepares an Authentication Request containing the desired
	      request parameters.</t>

	      <t>Client sends the request to the Authorization Server.</t>

	      <t>Authorization Server Authenticates the End-User.</t>

	      <t>Authorization Server obtains End-User Consent/Authorization.</t>

	      <t>Authorization Server sends the End-User back to the Client with
	      an Authorization Code.</t>

	      <t>Client requests a response using the Authorization Code at the
	      Token Endpoint.</t>

	      <t>Client receives a response that contains an ID Token
	      and Access Token in the response body.</t>

	      <t>Client validates the ID token and retrieves the End-User's
	      Subject Identifier.</t>

	    </list>
	  </t>
	</section>
	
	<section anchor="AuthorizationEndpoint" title="Authorization Endpoint">
	  <t>
	    The Authorization Endpoint performs Authentication of the
	    End-User.
	    This is done by sending the User Agent to
	    the Authorization Server's Authorization Endpoint for Authentication and
	    Authorization, using request parameters defined by OAuth 2.0 and
	    additional parameters and parameter values defined by OpenID Connect.
	  </t>
	  <t>
	    Communication with the Authorization Endpoint MUST utilize TLS.
	    See <xref target="TLSRequirements"/> for more information on using TLS.
	  </t>

	  <section anchor="AuthRequest" title="Authentication Request">
	    <t>
	      An Authentication Request is
	      an OAuth 2.0 Authorization Request that requests that the End-User
	      be authenticated by the Authorization Server.
	    </t>

	    <t>Authorization Servers MUST support the use of the HTTP <spanx style="verb">GET</spanx> and 
	    <spanx style="verb">POST</spanx> methods defined in <xref target="RFC7231">RFC 7231</xref> at the
	    Authorization Endpoint.
	    Clients MAY use the HTTP <spanx style="verb">GET</spanx> or
	    <spanx style="verb">POST</spanx> methods to send the
	    Authorization Request to the Authorization Server. If using the HTTP
	    <spanx style="verb">GET</spanx> method, the request parameters are serialized using
	    URI Query String Serialization, per <xref target="QuerySerialization"/>.
	    If using the HTTP <spanx style="verb">POST</spanx>
	    method, the request parameters are serialized using 
	    Form Serialization, per <xref target="FormSerialization"/>.</t>

	    <t>
	      OpenID Connect uses the following OAuth 2.0 request parameters with
	      the Authorization Code Flow:
	    </t>
	    <t>
	      <list style="hanging">
		<t hangText="scope">
		  <vspace/>
		  REQUIRED.
		  OpenID Connect requests MUST contain the <spanx style="verb">openid</spanx> scope value.
		  If the <spanx style="verb">openid</spanx> scope value is not present,
		  the behavior is entirely unspecified.
		  Other scope values MAY be present.
		  Scope values used that are not understood by an implementation SHOULD be ignored.
		  See Sections <xref target="ScopeClaims" format="counter"/>
		  and <xref target="OfflineAccess" format="counter"/>
		  for additional scope values defined by this specification.
		</t>

		<t hangText="response_type">
		  <vspace/>
		  REQUIRED.
		  OAuth 2.0 Response Type value that determines
		  the authorization processing flow to be used,
		  including what parameters are returned from the endpoints used.
		  When using the Authorization Code Flow, this value is
		  <spanx style="verb">code</spanx>.
		</t>

		<t hangText="client_id">
		  <vspace/>
		  REQUIRED.
		  OAuth 2.0 Client Identifier
		  valid at the Authorization Server.
		</t>

		<t hangText="redirect_uri">
		  <vspace/>
		  REQUIRED.
		  Redirection URI to which the response will be sent.
		  This URI MUST exactly match one of the Redirection URI values
		  for the Client pre-registered at the OpenID Provider,
		  with the matching performed as described in
		  Section 6.2.1 of <xref target="RFC3986"/> (Simple String Comparison).
		  When using this flow, the Redirection URI
		  SHOULD use the <spanx style="verb">https</spanx> scheme;
		  however, it MAY use the <spanx style="verb">http</spanx> scheme,
		  provided that the Client Type is
		  <spanx style="verb">confidential</spanx>,
		  as defined in Section 2.1 of OAuth 2.0, and
		  provided the OP allows the use of
		  <spanx style="verb">http</spanx> Redirection URIs in this case.
		  The Redirection URI MAY use an alternate scheme,
		  such as one that is intended to identify a callback into a native application.
		</t>

		<t hangText="state">
		  <vspace/>
		  RECOMMENDED.
		  Opaque value used
		  to maintain state between the request and the callback.
		  Typically, Cross-Site Request Forgery (CSRF, XSRF)
		  mitigation is done by cryptographically binding the value of
		  this parameter with a browser cookie.
		</t>

	      </list>
	    </t>

	    <t>
	      OpenID Connect also uses the following OAuth 2.0 request parameter,
	      which is defined in
	      <xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref>:
	    </t>
	    <t>

	      <list style="hanging">
		<t hangText="response_mode">
		  <vspace/>
		  OPTIONAL.
		  Informs the Authorization Server of the mechanism to be used
		  for returning parameters from the Authorization Endpoint.
		  This use of this parameter is NOT RECOMMENDED when the Response Mode
		  that would be requested is the default mode specified for the Response Type.
		</t>
	      </list>
	    </t>

	    <t>
	      This specification also defines the following request parameters:
	    </t>

	    <t>
	      <list style="hanging">
		<t hangText="nonce">
		  <vspace/>
		  OPTIONAL.
		  String value used to associate a Client session 
		  with an ID Token, and to mitigate replay attacks.
		  The value is passed through unmodified from the Authentication Request to the ID Token.
		  Sufficient entropy MUST be present in the
		  <spanx style="verb">nonce</spanx> values used to prevent
		  attackers from guessing values.
		  For implementation notes, see <xref target="NonceNotes"/>.
		</t>

		<t hangText="display">
		  <vspace/>
		  OPTIONAL.
		  ASCII string value that specifies
		  how the Authorization Server displays the authentication and
		  consent user interface pages to the End-User.
		  The defined values are:

		  <list style="hanging">
		    <t hangText="page">
		      <vspace/>
		      The Authorization Server SHOULD display the
		      authentication and consent UI consistent with a full User Agent page
		      view. If the display parameter is not specified, this is the
		      default display mode.
		    </t>

		    <t hangText="popup">
		      <vspace/>
		      The Authorization Server SHOULD display the
		      authentication and consent UI consistent with a popup User Agent
		      window.
		      The popup User Agent window should be of an appropriate size
		      for a login-focused dialog and should not obscure
		      the entire window that it is popping up over.
		    </t>

		    <t hangText="touch">
		      <vspace/>
		      The Authorization Server SHOULD display the
		      authentication and consent UI consistent with a device that
		      leverages a touch interface.
		    </t>

		    <t hangText="wap">
		      <vspace/>
		      The Authorization Server SHOULD display the
		      authentication and consent UI consistent with a "feature phone"
		      type display.
		    </t>
		  </list>
		</t>
		<t>
		  The Authorization Server MAY also attempt to detect the capabilities
		  of the User Agent and present an appropriate display.
		</t>

		<t hangText="prompt">
		  <vspace/>
		  OPTIONAL.
		  Space-delimited, case-sensitive list of ASCII string values
		  that specifies whether the Authorization Server prompts
		  the End-User for reauthentication and consent.
		  The defined values are:

		  <list style="hanging">
		    <t hangText="none">
		      <vspace/>
		      The Authorization Server
		      MUST NOT display any authentication or consent
		      user interface pages.
		      An error is returned
		      if an End-User
		      is not already authenticated or the Client does not have 
		      pre-configured consent for the requested
		      Claims or does not fulfill other conditions for processing the request.
		      The error code will typically be
		      <spanx style="verb">login_required</spanx>,
		      <spanx style="verb">interaction_required</spanx>,
		      or another code defined in <xref target="AuthError"/>.
		      This can be used as a
		      method to check for existing authentication and/or consent.
		    </t>

		    <t hangText="login">
		      <vspace/>
		      The Authorization Server SHOULD prompt the
		      End-User for reauthentication.
		      If it cannot reauthenticate the End-User, it MUST return an error,
		      typically <spanx style="verb">login_required</spanx>.
		    </t>

		    <t hangText="consent">
		      <vspace/>
		      The Authorization Server SHOULD prompt the End-User for consent
		      before returning information to the Client.
		      If it cannot obtain consent, it MUST return an error,
		      typically <spanx style="verb">consent_required</spanx>.
		    </t>

		    <t hangText="select_account">
		      <vspace/>
		      The Authorization Server SHOULD
		      prompt the End-User to select a user account.  This enables 
		      an End-User who has multiple accounts at the Authorization Server
		      to select amongst the multiple accounts that they might have 
		      current sessions for.
		      If it cannot obtain an account selection choice made by the End-User,
		      it MUST return an error,
		      typically <spanx style="verb">account_selection_required</spanx>.
		    </t>
		  </list>
		</t>
		<t>
		  The <spanx style="verb">prompt</spanx> parameter
		  can be used by the Client to make sure that the End-User is
		  still present for the current session or to bring attention to the
		  request. If this parameter contains <spanx style="verb">none</spanx>
		  with any other value, an
		  error is returned.
		</t>

		<t hangText="max_age">
		  <vspace/>
		  OPTIONAL.
		  Maximum Authentication Age.
		  Specifies the allowable elapsed time in seconds
		  since the last time the End-User was actively
		  authenticated by the OP. If the elapsed time is greater than
		  this value, the OP MUST attempt to actively
		  re-authenticate the End-User.
		  (The <spanx style="verb">max_age</spanx> request parameter corresponds to
		  the OpenID 2.0 <xref target="OpenID.PAPE">PAPE</xref>
		  <spanx style="verb">max_auth_age</spanx> request parameter.)
		  When <spanx style="verb">max_age</spanx> is used, the ID Token returned
		  MUST include an <spanx style="verb">auth_time</spanx> Claim Value.
		  Note that <spanx style="verb">max_age=0</spanx> is equivalent
		  to <spanx style="verb">prompt=login</spanx>.
		</t>

		<t hangText="ui_locales">
		  <vspace/>
		  OPTIONAL.
		  End-User's preferred languages and scripts for the user interface,
		  represented as a space-separated list of
		  <xref target="RFC5646">BCP47</xref> language tag values,
		  ordered by preference.
		  For instance, the value "fr-CA fr en" represents a preference
		  for French as spoken in Canada,
		  then French (without a region designation),
		  followed by English (without a region designation). 
		  An error SHOULD NOT result if some or all of the requested locales
		  are not supported by the OpenID Provider.
		</t>

		<t hangText="id_token_hint">
		  <vspace/>
		  OPTIONAL.
		  ID Token previously issued by the Authorization Server
		  being passed as a hint about the End-User's current or past
		  authenticated session with the Client.
		  If the End-User identified by the ID Token is logged in or is logged in by the request,
		  then the Authorization Server returns a positive response;
		  otherwise, it SHOULD return
		  an error, such as <spanx style="verb">login_required</spanx>.
		  When possible, an <spanx style="verb">id_token_hint</spanx>
		  SHOULD be present when <spanx style="verb">prompt=none</spanx> is used
		  and an <spanx style="verb">invalid_request</spanx> error
		  MAY be returned if it is not;
		  however, the server SHOULD respond successfully when possible,
		  even if it is not present.
		  The Authorization Server need not be listed as an
		  audience of the ID Token when it is used as an
		  <spanx style="verb">id_token_hint</spanx> value.
		</t>
		<t>
		  If the ID Token received by the RP from the OP is encrypted,
		  to use it as an <spanx style="verb">id_token_hint</spanx>, the Client MUST
		  decrypt the signed ID Token contained within the encrypted ID Token.
		  The Client MAY re-encrypt the signed ID token to the Authentication Server
		  using a key that enables the server to decrypt the ID Token,
		  and use the re-encrypted ID token as the
		  <spanx style="verb">id_token_hint</spanx> value.
		</t>

		<t hangText="login_hint">
		  <vspace/>
		  OPTIONAL.
		  Hint to the Authorization Server
		  about the login identifier the End-User might use to log in (if necessary).
		  This hint can be used by an RP if it first asks the End-User for their e-mail 
		  address (or other identifier) and then wants to pass that value as a hint
		  to the discovered authorization service.
		  It is RECOMMENDED that the hint value match the value used for discovery.
		  This value MAY also be a phone number in the format specified for the
		  <spanx style="verb">phone_number</spanx> Claim.
		  The use of this parameter is left to the OP's discretion.
		</t>

		<t hangText="acr_values">
		  <vspace/>
		  OPTIONAL.
		  Requested Authentication Context Class Reference values. 
		  Space-separated string that specifies the <spanx style="verb">acr</spanx>
		  values that the Authorization Server is being requested to use 
		  for processing this Authentication Request,
		  with the values appearing in order of preference.
		  The Authentication Context Class satisfied by the authentication
		  performed is returned as the <spanx style="verb">acr</spanx> Claim Value,
		  as specified in <xref target="IDToken"/>.
		  The <spanx style="verb">acr</spanx> Claim is requested as
		  a Voluntary Claim by this parameter.
		</t>
	      </list>
	    </t>
	    <t>
	      Other parameters MAY be sent. 
	      See Sections <xref target="ImplicitAuthorizationEndpoint" format="counter"/>,
	      <xref target="HybridAuthorizationEndpoint" format="counter"/>,
	      <xref target="ClaimsLanguagesAndScripts" format="counter"/>,
	      <xref target="ClaimsParameter" format="counter"/>,
	      <xref target="JWTRequests" format="counter"/>, and
	      <xref target="RegistrationParameter" format="counter"/>
	      for additional Authorization Request parameters and parameter values
	      defined by this specification.
	    </t>

	    <figure>
	      <preamble>
		The following is a non-normative example
		HTTP 302 redirect response by the Client, which triggers
		the User Agent to make an Authentication Request
		to the Authorization Endpoint
		(with line wraps within values for display purposes only):
	      </preamble>

	      <artwork><![CDATA[
  HTTP/1.1 302 Found
  Location: https://server.example.com/authorize?
    response_type=code
    &scope=openid%20profile%20email
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
]]></artwork>
	    </figure>

	    <figure>
	      <preamble>
		The following is the non-normative example request
		that would be sent by the User Agent to the Authorization Server
		in response to the HTTP 302 redirect response by the Client above
		(with line wraps within values for display purposes only):
	      </preamble>

	      <artwork><![CDATA[
  GET /authorize?
    response_type=code
    &scope=openid%20profile%20email
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
  Host: server.example.com
]]></artwork>
	    </figure>

	  </section>

	  <section anchor="AuthRequestValidation" title="Authentication Request Validation">
	    <t>
	      The Authorization Server MUST validate the request received as follows:
	    </t>
	    <t>
	      <list style="numbers">
		<t>
		  The Authorization Server MUST validate all the 
		  OAuth 2.0 parameters according to the OAuth 2.0 specification.
		</t>
		<t>
		  Verify that a <spanx style="verb">scope</spanx> parameter is present
		  and contains the <spanx style="verb">openid</spanx> scope value.
		  (If no <spanx style="verb">openid</spanx> scope value is present,
		  the request may still be a valid OAuth 2.0 request,
		  but is not an OpenID Connect request.)
		</t>
		<t>
		  The Authorization Server MUST verify that all the REQUIRED parameters 
		  are present
		  and their usage conforms to this specification.
		</t>
		<t>
		  If the <spanx style="verb">sub</spanx> (subject) Claim
		  is requested with a specific value for the ID Token, 
		  the Authorization Server MUST only send a positive response
		  if the End-User identified by that <spanx style="verb">sub</spanx> value
		  has an active session with the Authorization Server
		  or has been Authenticated as a result of the request.
		  The Authorization Server MUST NOT reply with an ID Token or
		  Access Token for a different user, 
		  even if they have an active session with the Authorization Server.
		  Such a request can be made either using an
		  <spanx style="verb">id_token_hint</spanx> parameter
		  or by requesting a specific Claim Value
		  as described in <xref target="IndividualClaimsRequests"/>,
		  if the <spanx style="verb">claims</spanx> parameter
		  is supported by the implementation.
		</t>
		<t>
		  When an <spanx style="verb">id_token_hint</spanx> is present,
		  the OP MUST validate that it was the issuer of the ID Token.
		  The OP SHOULD accept ID Tokens when the RP identified by the ID Token
		  has a current session or had a recent session at the OP,
		  even when the <spanx style="verb">exp</spanx> time has passed.
		</t>
	      </list>
	    </t>

	    <t>
	      As specified in <xref target="RFC6749">OAuth 2.0</xref>,
	      Authorization Servers SHOULD ignore unrecognized request parameters.
	    </t>
	    <t>
	      If the Authorization Server encounters any error, 
	      it MUST return an error response, per <xref target="AuthError"/>.
	    </t>
	  </section>

	  <section anchor="Authenticates" title="Authorization Server Authenticates End-User">

	    <t>
	      If the request is valid, the Authorization Server attempts
	      to Authenticate the End-User or determines whether the End-User is Authenticated,
	      depending upon the request parameter values used.
	      The methods used by the Authorization Server to Authenticate the End-User
	      (e.g. username and password, session cookies, etc.)
	      are beyond the scope of this specification.
	      An Authentication user interface MAY be displayed by
	      the Authorization Server, depending upon the request parameter values used
	      and the authentication methods used.
	    </t>

	    <t>The Authorization Server MUST attempt to Authenticate the 
	    End-User in the following cases:
	    <list style="symbols">
	      <t>The End-User is not already Authenticated.</t>

	      <t>The Authentication Request contains the <spanx 
	      style="verb">prompt</spanx> parameter with the value
	      <spanx style="verb">login</spanx>.  In this case, the
	      Authorization Server MUST reauthenticate the End-User
	      even if the End-User is already authenticated.</t>
	    </list>
	    </t>
	    <t>The Authorization Server MUST NOT interact with the End-User
	    in the following case:
            <list style="symbols">
	      <t>The Authentication Request contains the <spanx 
	      style="verb">prompt</spanx> parameter with the value
	      <spanx style="verb">none</spanx>.  In this case,
	      the Authorization Server MUST return
	      an error if an End-User
	      is not already Authenticated or could not be silently Authenticated.</t>
	    </list>
	    </t>

	    <t>
	      When interacting with the End-User,
	      the Authorization Server MUST employ appropriate measures against
	      Cross-Site Request Forgery and Clickjacking as, described in
	      Sections 10.12 and 10.13 of <xref target="RFC6749">OAuth 2.0</xref>.
	    </t>
	  </section>

	  <section anchor="Consent" title="Authorization Server Obtains End-User Consent/Authorization">

	    <t>
	      Once the End-User is authenticated, the Authorization Server MUST
	      obtain an authorization decision before releasing information
	      to the Relying Party.
	      When permitted by the request parameters used,
	      this MAY be done through an interactive dialogue with the End-User
	      that makes it clear what is being consented to
	      or by establishing consent via conditions for processing the request or
	      other means (for example, via previous administrative consent).
	      Sections <xref target="IDToken" format="counter"/> and
	      <xref target="UserInfo" format="counter"/> describe
	      information release mechanisms.
	    </t>

	  </section>

	  <section anchor="AuthResponse" title="Successful Authentication Response">

	    <t>
	      An Authentication Response is an OAuth 2.0 Authorization Response
	      message returned from the 
	      OP's Authorization Endpoint in response to the Authorization Request
	      message sent by the RP.
	    </t>
	    <t>
	      When using the Authorization Code Flow, the Authorization Response
	      MUST return the parameters defined in Section 4.1.2 of
	      <xref target="RFC6749">OAuth 2.0</xref>
	      by adding them as query parameters to the
	      <spanx style="verb">redirect_uri</spanx> specified in the Authorization Request
	      using the <spanx style="verb">application/x-www-form-urlencoded</spanx> format,
	      unless a different Response Mode was specified.
	    </t>

	    <figure>
	      <preamble>
		The following is a non-normative example
		successful response using this flow
		(with line wraps within values for display purposes only):
	      </preamble>

	      <artwork><![CDATA[
  HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    code=SplxlOBeZQQYbYS6WxSbIA
    &state=af0ifjsldkj
]]></artwork>
	    </figure>

	    <t>
	      For implementation notes on the contents of
	      the Authorization Code, see <xref target="CodeNotes"/>.
	    </t>
	  </section>

	  <section anchor="AuthError" title="Authentication Error Response">

	    <t>
	      An Authentication Error Response is an OAuth 2.0 Authorization Error Response
	      message returned from the 
	      OP's Authorization Endpoint in response to the Authorization Request
	      message sent by the RP.
	    </t>

	    <t>
	      If the End-User denies the request or the End-User authentication
	      fails, the OP (Authorization Server) informs the RP (Client)
	      by using the Error Response parameters defined in
	      Section 4.1.2.1 of <xref target="RFC6749">OAuth 2.0</xref>.
	      (HTTP errors unrelated to RFC 6749 are returned to the User Agent using the
	      appropriate HTTP status code.)
	    </t>
	    <t>
	      Unless the Redirection URI is invalid,
	      the Authorization Server returns the Client to
	      the Redirection URI specified in the Authorization Request
	      with the appropriate error and state parameters.
	      Other parameters SHOULD NOT be returned.
	      If the Redirection URI is invalid,
	      the Authorization Server MUST NOT redirect
	      the User Agent to the invalid Redirection URI.
	    </t>
	    <t>
	      In addition to the error codes defined in Section 4.1.2.1 of
	      OAuth 2.0, this specification also defines the following error codes:
	    </t>

	    <t>
	      <list style="hanging">

		<t hangText="interaction_required">
		  <vspace/>
		  The Authorization Server
		  requires End-User interaction of some form to proceed.
		  This error MAY be returned when the 
		  <spanx style="verb">prompt</spanx> parameter value in the
		  Authentication Request is <spanx style="verb">none</spanx>,
		  but the Authentication Request cannot be completed
		  without displaying a user interface for End-User interaction.
		</t>

		<t hangText="login_required">
		  <vspace/>
		  The Authorization Server requires
		  End-User authentication. This error MAY be returned when the 
		  <spanx style="verb">prompt</spanx> parameter value in the
		  Authentication Request is <spanx style="verb">none</spanx>,
		  but the Authentication Request cannot be completed
		  without displaying a user interface for End-User authentication.
		</t>

		<t hangText="account_selection_required">
		  <vspace/>
		  The End-User is REQUIRED
		  to select a session at the Authorization Server. The End-User MAY
		  be authenticated at the Authorization Server with different
		  associated accounts, but the End-User did not select a session.
		  This error MAY be returned 
		  when the <spanx style="verb">prompt</spanx> parameter value in the
		  Authentication Request is <spanx style="verb">none</spanx>,
		  but the Authentication Request cannot be completed
		  without displaying a user interface to prompt for a session to use.
		</t>

		<t hangText="consent_required">
		  <vspace/>
		  The Authorization Server
		  requires End-User consent. This error MAY be returned when the 
		  <spanx style="verb">prompt</spanx> parameter value in the
		  Authentication Request is <spanx style="verb">none</spanx>,
		  but the Authentication Request cannot be completed
		  without displaying a user interface for End-User consent.
		</t>

		<t hangText="invalid_request_uri">
		  <vspace/>
		  The 
		  <spanx style="verb">request_uri</spanx> in
		  the Authorization Request returns an error or contains invalid data.
		</t>

		<t hangText="invalid_request_object">
		  <vspace/>
		  The 
		  <spanx style="verb">request</spanx> parameter contains an invalid 
		  Request Object.
		</t>

		<t hangText="request_not_supported">
		  <vspace/>
		  The OP does not support use of the
		  <spanx style="verb">request</spanx> parameter
		  defined in <xref target="JWTRequests"/>.
		</t>

		<t hangText="request_uri_not_supported">
		  <vspace/>
		  The OP does not support use of the
		  <spanx style="verb">request_uri</spanx> parameter
		  defined in <xref target="JWTRequests"/>.
		</t>

		<t hangText="registration_not_supported">
		  <vspace/>
		  The OP does not support use of the
		  <spanx style="verb">registration</spanx> parameter
		  defined in <xref target="RegistrationParameter"/>.
		</t>

	      </list>
	    </t>

	    <t>
	      The error response parameters are the following:

	      <list style="hanging">
		<t hangText="error">
		  <vspace/>
		  REQUIRED. Error code.
		</t>

		<t hangText="error_description">
		  <vspace/>
		  OPTIONAL. Human-readable ASCII
		  encoded text description of the error.
		</t>

		<t hangText="error_uri">
		  <vspace/>
		  OPTIONAL. URI of a web page that
		  includes additional information about the error.
		</t>

		<t hangText="state">
		  <vspace/>
		  OAuth 2.0 state value.
		  REQUIRED if the Authorization Request
		  included the <spanx style="verb">state</spanx> parameter. Set
		  to the value received from the Client.
		</t>
	      </list>
	    </t>

	    <t>
	      When using the Authorization Code Flow, the error response
	      parameters are added to the query component of the Redirection URI,
	      unless a different Response Mode was specified.
	    </t>

	    <t>
	      <figure>
		<preamble>
		  The following is a non-normative example
		  error response using this flow
		  (with line wraps within values for display purposes only):
		</preamble>

		<artwork><![CDATA[
  HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    error=invalid_request
    &error_description=
      Unsupported%20response_type%20value
    &state=af0ifjsldkj
]]></artwork>
	      </figure>
	    </t>
	  </section>

	  <section anchor="AuthResponseValidation" title="Authentication Response Validation">
	    <t>
	      When using the Authorization Code Flow,
	      the Client MUST validate the response according to RFC 6749,
	      especially Sections 4.1.2 and 10.12.
	    </t>
	  </section>

	</section>

	<section anchor="TokenEndpoint" title="Token Endpoint">
	  <t>
	    To obtain an Access Token, an ID Token, and optionally a Refresh Token,
	    the RP (Client) sends a Token Request to the Token Endpoint
	    to obtain a Token Response, as described in
	    Section 3.2 of <xref target="RFC6749">OAuth 2.0</xref>,
	    when using the Authorization Code Flow.
	  </t>

	  <t>
	    Communication with the Token Endpoint MUST utilize TLS.
	    See <xref target="TLSRequirements"/> for more information on using TLS.
	  </t>

	  <section anchor="TokenRequest" title="Token Request">

	    <t>
	      A Client makes a Token Request by
	      presenting its Authorization Grant (in the form of
	      an Authorization Code) to the Token Endpoint
	      using the <spanx style="verb">grant_type</spanx> value
	      <spanx style="verb">authorization_code</spanx>, as described in 
	      Section 4.1.3 of <xref target="RFC6749">OAuth 2.0</xref>.
	      If the Client is a Confidential Client, then it MUST
	      authenticate to the Token Endpoint using the authentication method
	      registered for its <spanx style="verb">client_id</spanx>,
	      as described in <xref target="ClientAuthentication"/>.
	    </t>
	    <t>
	      The Client sends the parameters to the Token Endpoint
	      using the HTTP <spanx style="verb">POST</spanx> method and the
	      Form Serialization, per <xref target="FormSerialization"/>,
	      as described in Section 4.1.3 of 
	      <xref target="RFC6749">OAuth 2.0</xref>.
	    </t>

	    <figure>
	      <preamble>
		The following is a non-normative example of a Token Request
		(with line wraps within values for display purposes only):
	      </preamble>

	      <artwork><![CDATA[
  POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

  grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
]]></artwork>
	    </figure>
	  </section>

	  <section anchor="TokenRequestValidation" title="Token Request Validation">
	    <t>
	      The Authorization Server MUST validate the Token Request as follows:
	    </t>
	    <t>
	      <list style='symbols'>
		<t>
		  Authenticate the Client if it was issued Client Credentials
		  or if it uses another Client Authentication method,
		  per <xref target="ClientAuthentication"/>.
		</t>
		<t>
		  Ensure the
		  Authorization Code was issued to the authenticated Client.
		</t>
		<t>
		  Verify that the Authorization Code is valid.
		</t>
		<t>
		  If possible,
		  verify that the Authorization Code has not been previously used.
		</t>
		<t>
		  Ensure that the
		  <spanx style='verb'>redirect_uri</spanx> parameter value
		  is identical to the <spanx style='verb'>redirect_uri</spanx>
		  parameter value that was included in the initial Authorization Request.
		  If the <spanx style='verb'>redirect_uri</spanx> parameter value
		  is not present when there is only one registered
		  <spanx style='verb'>redirect_uri</spanx> value,
		  the Authorization Server MAY return an error
		  (since the Client should have included the parameter)
		  or MAY proceed without an error
		  (since OAuth 2.0 permits the parameter to be omitted in this case).
		</t>
		<t>
		  Verify that the Authorization Code used was issued
		  in response to an OpenID Connect Authentication Request
		  (so that an ID Token will be returned from the Token Endpoint).
		</t>
	      </list>
	    </t>

	  </section>

	  <section anchor="TokenResponse" title="Successful Token Response">
	    <t>
	      After receiving and validating a valid and authorized Token Request
	      from the Client, the Authorization Server returns a successful
	      response that includes an ID Token and an Access Token.  The
	      parameters in the successful response are defined in Section 4.1.4
	      of <xref target="RFC6749">OAuth 2.0</xref>.
	      The response uses the <spanx style="verb">application/json</spanx>
	      media type.
	    </t>
	    <t>
	      The OAuth 2.0 <spanx style="verb">token_type</spanx> response parameter
	      value MUST be <spanx style="verb">Bearer</spanx>,
	      as specified in <xref target="RFC6750">OAuth 2.0 Bearer Token Usage</xref>,
	      unless another Token Type has been negotiated with the Client.
	      Servers SHOULD support the <spanx style="verb">Bearer</spanx> Token Type;
	      use of other Token Types is outside the scope of this specification.
	      Note that the <spanx style="verb">token_type</spanx> value is case insensitive.
	    </t>
	    <t>
	      In addition to the response parameters specified by OAuth 2.0, the following
	      parameters MUST be included in the response:
	    </t>
	    <t>
	      <list style="hanging">
		<t hangText="id_token">
		  <vspace/>
		  ID Token value associated with the
		  authenticated session.
		</t>
	      </list>
	    </t>
	    <t>
	      All Token Responses that contain tokens, secrets, or other
	      sensitive information MUST include the following HTTP response header
	      fields and values:
	    </t>

	    <texttable title="HTTP Response Headers and Values">
	      <ttcol>Header Name</ttcol>

	      <ttcol>Header Value</ttcol>

	      <c>Cache-Control</c>

	      <c>no-cache, no-store</c>

	      <c>Pragma</c>

	      <c>no-cache</c>
	    </texttable>

	    <figure>
	      <preamble>
		The following is a non-normative example of a successful Token Response.
		The ID Token signature in the example can be verified with the key at
		<xref target="ExampleRSAKey"/>.
	      </preamble>

	      <artwork><![CDATA[
  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-cache, no-store
  Pragma: no-cache

  {
   "access_token": "SlAV32hkKG",
   "token_type": "Bearer",
   "refresh_token": "8xLOxBtZp8",
   "expires_in": 3600,
   "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
     yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
     NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
     fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
     AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
     Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
     NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
     QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
     K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
     XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
  }
]]></artwork>
	    </figure>

	    <t>As specified in <xref target="RFC6749">OAuth 2.0</xref>, Clients
	    SHOULD ignore unrecognized response parameters.</t>
	  </section>

	  <section anchor="TokenErrorResponse" title="Token Error Response">

	    <t>
	      If the Token Request is invalid or unauthorized, the
	      Authorization Server constructs the error response. The parameters
	      of the Token Error Response are defined as in Section 5.2 of <xref
	      target="RFC6749">OAuth 2.0</xref>.
	      The HTTP response body uses the <spanx style="verb">application/json</spanx>
	      media type with HTTP response code of 400.
	    </t>

	    <figure>
	      <preamble>The following is a non-normative example Token Error Response:</preamble>

	      <artwork><![CDATA[
  HTTP/1.1 400 Bad Request
  Content-Type: application/json
  Cache-Control: no-cache, no-store
  Pragma: no-cache

  {
   "error": "invalid_request"
  }
]]></artwork>
	    </figure>
	  </section>

	  <section anchor="TokenResponseValidation" title="Token Response Validation">
	    <t>
	      The Client MUST validate the Token Response as follows:
	      <list style="numbers">
		<t>
		  Follow the validation rules in RFC 6749,
		  especially those in Sections 5.1 and 10.12.
		</t>
		<t>
		  Follow the ID Token validation rules in <xref target="IDTokenValidation"/>.
		</t>
		<t>
		  Follow the Access Token validation rules in <xref target="CodeFlowTokenValidation"/>.
		</t>
	      </list>
	    </t>

	  </section>

          <section anchor="CodeIDToken" title="ID Token">

	    <t>
	      The contents of the ID Token are as described in <xref target="IDToken"/>.
	      When using the Authorization Code Flow,
	      these additional requirements for the following ID Token Claims apply:
	    </t>
            <t>
	      <list style="hanging">

                <t hangText="at_hash">
		  <vspace/>
		  OPTIONAL. 
		  Access Token hash value.
		  Its value is the base64url encoding of the left-most half of the
		  hash of the octets of the ASCII representation of the
		  <spanx style="verb">access_token</spanx> value,
		  where the hash algorithm used is the hash algorithm
		  used in the <spanx style="verb">alg</spanx> Header Parameter
		  of the ID Token's JOSE Header.
		  For instance, if the <spanx style="verb">alg</spanx> is
		  <spanx style="verb">RS256</spanx>, hash the
		  <spanx style="verb">access_token</spanx> value
		  with SHA-256, then take the left-most 128 bits and base64url-encode them.
		  The <spanx style="verb">at_hash</spanx> value is a case-sensitive string.
		</t>

              </list>
	    </t>

	  </section>

	  <section anchor="IDTokenValidation" title="ID Token Validation">
            <t>
              Clients MUST validate the ID Token in the Token Response
	      in the following manner:
	    </t>

	    <t>
	      <list style="numbers">
		<t>
		  If the ID Token is encrypted, decrypt it using the
		  keys and algorithms that the Client specified during Registration
		  that the OP was to use to encrypt the ID Token.
		  If encryption was negotiated with the OP at Registration time
		  and the ID Token is not encrypted, the RP SHOULD reject it.
		</t>
		<t>
		  The Issuer Identifier for the OpenID Provider
		  (which is typically obtained during Discovery)
		  MUST exactly match the value of the 
		  <spanx style="verb">iss</spanx> (issuer) Claim.
		</t>
		<t>
		  The Client MUST validate that the
		  <spanx style="verb">aud</spanx> (audience) Claim
		  contains its <spanx style="verb">client_id</spanx> value
		  registered at the Issuer identified by the
		  <spanx style="verb">iss</spanx> (issuer) Claim
		  as an audience.
		  The <spanx style="verb">aud</spanx> (audience) Claim
		  MAY contain an array with more than one element.
		  The ID Token MUST be rejected if the ID Token does not list
		  the Client as a valid audience, or if it contains additional audiences not trusted by the Client.
		</t>
		<t>
		  If the ID Token contains multiple audiences, the Client SHOULD verify
		  that an <spanx style="verb">azp</spanx> Claim is present.
		</t>
		<t>
		  If an <spanx style="verb">azp</spanx> (authorized party) Claim is present,
		  the Client SHOULD verify that its <spanx style="verb">client_id</spanx>
		  is the Claim Value.
		</t>

		<t>
		  If the ID Token is received via direct
		  communication between the Client and the Token Endpoint
		  (which it is in this flow), the TLS server 
		  validation MAY be used to validate the issuer in place of 
		  checking the token signature.
		  The Client MUST validate the signature of all other ID Tokens according to
		  <xref target="JWS">JWS</xref> using the algorithm specified in the 
		  JWT <spanx style="verb">alg</spanx> Header Parameter.
		  The Client MUST use the keys provided by the Issuer.
		</t>

		<t>The <spanx style="verb">alg</spanx> value SHOULD be the default of
		<spanx style="verb">RS256</spanx>
		or the algorithm sent by the Client 
		in the <spanx style="verb">id_token_signed_response_alg</spanx> parameter 
		during Registration.</t>

		<t>If the JWT <spanx style="verb">alg</spanx> Header Parameter
		uses a MAC based algorithm such as 
		<spanx style="verb">HS256</spanx>, <spanx style="verb">HS384</spanx>,
		or <spanx style="verb">HS512</spanx>,
		the octets of the UTF-8 <xref target="RFC3629"/> representation of
		the <spanx style="verb">client_secret</spanx> corresponding to the 
		<spanx style="verb">client_id</spanx> contained in the 
		<spanx style="verb">aud</spanx> (audience) Claim are used as the key
		to validate the signature.
		For MAC based algorithms, the behavior is unspecified
		if the <spanx style="verb">aud</spanx> is multi-valued or
		if an <spanx style="verb">azp</spanx> value is present
		that is different than the <spanx style="verb">aud</spanx> value.
		</t> 
		<t>
		  The current time MUST be before the time represented by the 
		  <spanx style="verb">exp</spanx> Claim.
		</t>

		<t>The <spanx style="verb">iat</spanx> Claim can be used to reject tokens that 
		were issued too far away from the current time, limiting the amount of
		time that nonces need to be stored to prevent attacks. 
		The acceptable range is Client specific.</t>

		<t>
		  If a nonce value was sent in the Authentication Request,
		  a <spanx style="verb">nonce</spanx> Claim MUST be present
		  and its value checked to verify that
		  it is the same value as the one that was sent in the Authentication Request.
		  The Client SHOULD check the <spanx style="verb">nonce</spanx> value
		  for replay attacks.
		  The precise method for detecting replay attacks is Client specific.
		</t>

		<t>If the <spanx style="verb">acr</spanx> Claim was requested, the 
		Client SHOULD check that the asserted Claim Value is appropriate.
		The meaning and processing of  
		<spanx style="verb">acr</spanx> Claim Values is out of scope for this specification.</t>

		<t>
		  If the <spanx style="verb">auth_time</spanx> Claim was requested,
		  either through a specific request for this Claim
		  or by using the <spanx style="verb">max_age</spanx> parameter,
		  the Client SHOULD check the <spanx style="verb">auth_time</spanx> Claim
		  value and request re-authentication if it determines too much time
		  has elapsed since the last End-User authentication.
		</t>
	      </list>
	    </t>

	  </section>

	  <section anchor="CodeFlowTokenValidation" title="Access Token Validation">
	    <t>
	      When using the Authorization Code Flow,
	      if the ID Token contains an <spanx style="verb">at_hash</spanx> Claim,
	      the Client MAY use it to validate the Access Token
	      in the same manner as for the Implicit Flow,
	      as defined in <xref target="ImplicitTokenValidation"/>,
	      but using the ID Token and Access Token returned from the Token Endpoint.
	    </t>
	  </section>

	</section>

      </section>

      <section anchor="ImplicitFlowAuth" title="Authentication using the Implicit Flow">
	<t>
	  This section describes how to perform authentication using the Implicit Flow.
	  When using the Implicit Flow,
	  all tokens are returned from the Authorization Endpoint;
	  the Token Endpoint is not used.
	</t>

	<t>The Implicit Flow is mainly used by Clients implemented in a browser
	using a scripting language. The Access Token and ID Token are returned
	directly to the Client, which may expose them to the End-User and
	applications that have access to the End-User's User Agent.
	The Authorization Server does not perform Client Authentication.
	</t>

	<section anchor="ImplicitFlowSteps" title="Implicit Flow Steps">
	  <t>The Implicit Flow follows the following steps:</t>

	  <t>
	    <list style="numbers">
	      <t>Client prepares an Authentication Request containing the desired
	      request parameters.</t>

	      <t>Client sends the request to the Authorization Server.</t>

	      <t>Authorization Server Authenticates the End-User.</t>

	      <t>Authorization Server obtains End-User Consent/Authorization.</t>

	      <t>Authorization Server sends the End-User back to the Client with
	      an ID Token and, if requested, an Access Token.</t>

	      <t>Client validates the ID token and retrieves the End-User's
	      Subject Identifier.</t>

	    </list>
	  </t>
	</section>

	<section anchor="ImplicitAuthorizationEndpoint" title="Authorization Endpoint">
	  <t>
	    When using the Implicit Flow, the Authorization Endpoint is used
	    in the same manner as for the Authorization Code Flow,
	    as defined in <xref target="AuthorizationEndpoint"/>,
	    with the exception of the differences specified in this section.
	  </t>

	  <section anchor="ImplicitAuthRequest" title="Authentication Request">
	    <t>
	      Authentication Requests are made
	      as defined in <xref target="AuthRequest"/>,
	      except that these Authentication Request parameters
	      are used as follows:
	    </t>
	    <t>
	      <list style="hanging">
		<t hangText="response_type">
		  <vspace/>
		  REQUIRED.
		  OAuth 2.0 Response Type value that determines
		  the authorization processing flow to be used,
		  including what parameters are returned from the endpoints used.
		  When using the Implicit Flow, this value is
		  <spanx style="verb">id_token&nbsp;token</spanx> or
		  <spanx style="verb">id_token</spanx>.
		  The meanings of both of these values are defined in
		  <xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref>.
		  No Access Token is returned when the value is
		  <spanx style="verb">id_token</spanx>.
		</t>
		<t>
		  NOTE:  While OAuth 2.0 also defines the
		  <spanx style="verb">token</spanx> Response Type value
		  for the Implicit Flow, OpenID Connect does not use this Response Type,
		  since no ID Token would be returned.
		</t>

		<t hangText="redirect_uri">
		  <vspace/>
		  REQUIRED.
		  Redirection URI to which the response will be sent.
		  This URI MUST exactly match one of the Redirection URI values
		  for the Client pre-registered at the OpenID Provider,
		  with the matching performed as described in
		  Section 6.2.1 of <xref target="RFC3986"/> (Simple String Comparison).
		  When using this flow, the Redirection URI
		  MUST NOT use the <spanx style="verb">http</spanx> scheme
		  unless the Client is a native application, in which case it MAY
		  use the <spanx style="verb">http:</spanx> scheme with
		  <spanx style="verb">localhost</spanx> as the hostname.
		</t>

		<t hangText="nonce">
		  <vspace/>
		  REQUIRED.
		  String value used to associate a Client session 
		  with an ID Token, and to mitigate replay attacks. 
		  The value is passed through unmodified from the Authentication Request to the ID Token.
		  Sufficient entropy MUST be present in the
		  <spanx style="verb">nonce</spanx> values used to prevent
		  attackers from guessing values.
		  For implementation notes, see <xref target="NonceNotes"/>.
		</t>
	      </list>
	    </t>

	    <figure>
	      <preamble>
		The following is a non-normative example request using the Implicit Flow
		that would be sent by the User Agent to the Authorization Server
		in response to a corresponding HTTP 302 redirect response by the Client
		(with line wraps within values for display purposes only):
	      </preamble>

	      <artwork><![CDATA[
  GET /authorize?
    response_type=id_token%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj HTTP/1.1
  Host: server.example.com
]]></artwork>
	    </figure>

	  </section>

	  <section anchor="ImplicitValidation" title="Authentication Request Validation">
	    <t>
	      When using the Implicit Flow, the Authentication Request is validated
	      in the same manner as for the Authorization Code Flow,
	      as defined in <xref target="AuthRequestValidation"/>.
	    </t>
	  </section>

	  <section anchor="ImplicitAuthenticates" title="Authorization Server Authenticates End-User">
	    <t>
	      When using the Implicit Flow, End-User Authentication is performed
	      in the same manner as for the Authorization Code Flow,
	      as defined in <xref target="Authenticates"/>.
	    </t>
	  </section>

	  <section anchor="ImplicitConsent" title="Authorization Server Obtains End-User Consent/Authorization">
	    <t>
	      When using the Implicit Flow, End-User Consent is obtained
	      in the same manner as for the Authorization Code Flow,
	      as defined in <xref target="Consent"/>.
	    </t>
	  </section>


	  <section anchor="ImplicitAuthResponse" title="Successful Authentication Response">
	    <t>
	      When using the Implicit Flow, Authentication Responses are made
	      in the same manner as for the Authorization Code Flow,
	      as defined in <xref target="AuthResponse"/>,
	      with the exception of the differences specified in this section.
	    </t>
	    <t>
	      When using the Implicit Flow,
	      all response parameters are added to the fragment component
	      of the Redirection URI, as specified in
	      <xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref>,
	      unless a different Response Mode was specified.
	    </t>

	    <t>
	      These parameters are returned from the Authorization Endpoint:
	    </t>
            <t>
	      <list style="hanging">
                <t hangText="access_token">
		  <vspace/>
		  OAuth 2.0 Access Token.
		  This is returned
		  unless the <spanx style="verb">response_type</spanx> value used is
		  <spanx style="verb">id_token</spanx>.
		</t>

                <t hangText="token_type">
		  <vspace/>
		  OAuth 2.0 Token Type value.
		  The value MUST be <spanx style="verb">Bearer</spanx> or
		  another <spanx style="verb">token_type</spanx> value that the Client 
		  has negotiated with the Authorization Server.
		  Clients implementing this profile MUST support the <xref
		  target="RFC6750">OAuth 2.0 Bearer Token Usage</xref> specification.
		  This profile only describes the use of bearer tokens.
		  This is returned in the same cases as
		  <spanx style="verb">access_token</spanx> is.
		</t>

                <t hangText="id_token">
		  <vspace/>
		  REQUIRED.
		  ID Token.
		</t>

                <t hangText="state">
		  <vspace/>
		  OAuth 2.0 state value.
		  REQUIRED if the 
		  <spanx style="verb">state</spanx> parameter is present in the
		  Authorization Request. Clients MUST verify that the 
		  <spanx style="verb">state</spanx> value is equal to the 
		  value of <spanx style="verb">state</spanx> parameter in the 
		  Authorization Request.
		</t>

                <t hangText="expires_in">
		  <vspace/>
		  OPTIONAL.
		  Expiration time of the Access Token in seconds
		  since the response was generated.
		</t>
              </list>
	    </t>

	    <t>
	      Per Section 4.2.2 of <xref target="RFC6749">OAuth 2.0</xref>,
	      no <spanx style="verb">code</spanx> result is returned
	      when using the Implicit Flow.
	    </t>

            <figure>
              <preamble>The following is a non-normative example
	      of a successful response using the Implicit Flow
	      (with line wraps for the display purposes only):</preamble>

              <artwork><![CDATA[
  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    access_token=SlAV32hkKG
    &token_type=bearer
    &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    &expires_in=3600
    &state=af0ifjsldkj
]]></artwork>
            </figure>
	  </section>

	  <section anchor="ImplicitAuthError" title="Authentication Error Response">

	    <t>
	      When using the Implicit Flow, Authorization Error Responses are made
	      in the same manner as for the Authorization Code Flow,
	      as defined in <xref target="AuthError"/>,
	      with the exception of the differences specified in this section.
	    </t>
            <t>
	      If the End-User denies the request or the End-User authentication
	      fails, the Authorization Server MUST return the error
	      Authorization Response in the
	      fragment component of the Redirection URI,
	      as defined in 4.2.2.1 of 
	      <xref target="RFC6749">OAuth 2.0</xref> and
	      <xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref>,
	      unless a different Response Mode was specified.
	    </t>
	  </section>

	  <section anchor="ImplicitCallback" title="Redirect URI Fragment Handling">
	    <t>
	      Since response parameters are returned in the Redirection URI fragment value,
	      the Client needs to have the User Agent parse the fragment encoded values
	      and pass them to on to the Client's processing logic for consumption.
	      See <xref target="FragmentNotes"/> for implementation notes
	      on URI fragment handling.
	    </t>
	  </section>

	  <section anchor="ImplicitAuthResponseValidation" title="Authentication Response Validation">
	    <t>
	      When using the Implicit Flow,
	      the Client MUST validate the response as follows:
	      <list style="numbers">
		<t>
		  Verify that the response conforms to Section 5 of
		  <xref target="OAuth.Responses"/>.
		</t>
		<t>
		  Follow the validation rules in RFC 6749,
		  especially those in Sections 4.2.2 and 10.12.
		</t>
		<t>
		  Follow the ID Token validation rules in <xref target="ImplicitIDTValidation"/>.
		</t>
		<t>
		  Follow the Access Token validation rules in <xref target="ImplicitTokenValidation"/>,
		  unless the <spanx style="verb">response_type</spanx> value used is
		  <spanx style="verb">id_token</spanx>.
		</t>
	      </list>
	    </t>
	  </section>

	  <section anchor="ImplicitTokenValidation" title="Access Token Validation">
	    <t>To validate an Access Token issued from the Authorization Endpoint with an ID Token, 
	    the Client SHOULD do the following:</t>

	    <t>
	      <list style="numbers">
		<t>Hash the octets of the ASCII representation of
		the <spanx style="verb">access_token</spanx> 
		with the hash algorithm specified in <xref target="JWA">JWA</xref> for the
		<spanx style="verb">alg</spanx> Header Parameter
		of the ID Token's JOSE Header.
		For instance, if the <spanx style="verb">alg</spanx> is
		<spanx style="verb">RS256</spanx>,
		the hash algorithm used is SHA-256.
		</t>

		<t>Take the left-most half of the hash and base64url-encode it.</t>
		<t>
		  The value of <spanx style="verb">at_hash</spanx> in the ID Token MUST
		  match the value produced in the previous step.
		</t>
	      </list>
	    </t>
	  </section>

          <section anchor="ImplicitIDToken" title="ID Token">

	    <t>
	      The contents of the ID Token are as described in <xref target="IDToken"/>.
	      When using the Implicit Flow,
	      these additional requirements for the following ID Token Claims apply:
	    </t>
            <t>
	      <list style="hanging">

                <t hangText="nonce">
		  <vspace/>
		  Use of the <spanx style="verb">nonce</spanx> Claim is REQUIRED
		  for this flow.
		</t>

                <t hangText="at_hash">
		  <vspace/>
		  Access Token hash value.
		  Its value is the base64url encoding of the left-most half of the
		  hash of the octets of the ASCII representation of the
		  <spanx style="verb">access_token</spanx> value,
		  where the hash algorithm used is the hash algorithm
		  used in the <spanx style="verb">alg</spanx> Header Parameter
		  of the ID Token's JOSE Header.
		  For instance, if the <spanx style="verb">alg</spanx> is
		  <spanx style="verb">RS256</spanx>, hash the
		  <spanx style="verb">access_token</spanx> value
		  with SHA-256, then take the left-most 128 bits and base64url-encode them.
		  The <spanx style="verb">at_hash</spanx> value is a case-sensitive string.
		</t>
		<t>
		  If the ID Token is issued from the Authorization Endpoint with an 
		  <spanx style="verb">access_token</spanx> value,
		  which is the case for the <spanx style="verb">response_type</spanx> value
		  <spanx style="verb">id_token&nbsp;token</spanx>,
		  this is REQUIRED;
		  it MAY NOT be used when no Access Token is issued,
		  which is the case for the <spanx style="verb">response_type</spanx> value
		  <spanx style="verb">id_token</spanx>.
		</t>

	      </list>
	    </t>
	  </section>

	  <section anchor="ImplicitIDTValidation" title="ID Token Validation">
	    <t>
	      When using the Implicit Flow, the contents of the ID Token MUST be validated
	      in the same manner as for the Authorization Code Flow,
	      as defined in <xref target="IDTokenValidation"/>,
	      with the exception of the differences specified in this section.
	    </t>
	    <t>
	      <list style="numbers">
		<t>
		  The Client MUST validate the signature of the ID Token according to
		  <xref target="JWS">JWS</xref> using the algorithm specified in the 
		  <spanx style="verb">alg</spanx> Header Parameter of the JOSE Header.
		</t>

		<t>
		  The value of the <spanx style="verb">nonce</spanx>
		  Claim MUST be checked to verify that
		  it is the same value as the one that was sent in the Authentication Request.
		  The Client SHOULD check the <spanx style="verb">nonce</spanx> value
		  for replay attacks.
		  The precise method for detecting replay attacks is Client specific.
		</t>

	      </list>
	    </t>
	  </section>

	</section>
      </section>

      <section anchor="HybridFlowAuth" title="Authentication using the Hybrid Flow">

	<t>
	  This section describes how to perform authentication using the Hybrid Flow.
	  When using the Hybrid Flow,
	  some tokens are returned from the Authorization Endpoint
	  and others are returned from the Token Endpoint.
	  The mechanisms for returning tokens in the Hybrid Flow are specified in
	  <xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref>.
	</t>

	<section anchor="HybridFlowSteps" title="Hybrid Flow Steps">

	  <t>The Hybrid Flow follows the following steps:</t>

	  <t>
	    <list style="numbers">
	      <t>Client prepares an Authentication Request containing the desired
	      request parameters.</t>

	      <t>Client sends the request to the Authorization Server.</t>

	      <t>Authorization Server Authenticates the End-User.</t>

	      <t>Authorization Server obtains End-User Consent/Authorization.</t>

	      <t>
		Authorization Server sends the End-User back to the Client with
		an Authorization Code and, depending on the Response Type,
		one or more additional parameters.
	      </t>

	      <t>Client requests a response using the Authorization Code at the
	      Token Endpoint.</t>

	      <t>Client receives a response that contains an ID Token
	      and Access Token in the response body.</t>

	      <t>Client validates the ID Token and retrieves the End-User's
	      Subject Identifier.</t>

	    </list>
	  </t>
	</section>

	<section anchor="HybridAuthorizationEndpoint" title="Authorization Endpoint">

	  <t>
	    When using the Hybrid Flow, the Authorization Endpoint is used
	    in the same manner as for the Authorization Code Flow,
	    as defined in <xref target="AuthorizationEndpoint"/>,
	    with the exception of the differences specified in this section.
	  </t>

	  <section anchor="HybridAuthRequest" title="Authentication Request">

	    <t>
	      Authentication Requests are made
	      as defined in <xref target="AuthRequest"/>,
	      except that these Authentication Request parameters
	      are used as follows:
	    </t>
	    <t>
	      <list style="hanging">
		<t hangText="response_type">
		  <vspace/>
		  REQUIRED.
		  OAuth 2.0 Response Type value that determines
		  the authorization processing flow to be used,
		  including what parameters are returned from the endpoints used.
		  When using the Hybrid Flow, this value is
		  <spanx style="verb">code&nbsp;id_token</spanx>,
		  <spanx style="verb">code&nbsp;token</spanx>, or
		  <spanx style="verb">code&nbsp;id_token&nbsp;token</spanx>.
		  The meanings of these values are defined in
		  <xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref>.
		</t>

		<t hangText="nonce">
		  <vspace/>
		  REQUIRED if the Response Type of the request is <spanx style="verb">code&nbsp;id_token</spanx>
		  or <spanx style="verb">code&nbsp;id_token&nbsp;token</spanx> and OPTIONAL when the Response Type of
		  the request is <spanx style="verb">code&nbsp;token</spanx>.
		  It is a string value used to associate a Client session
		  with an ID Token, and to mitigate replay attacks.
		  The value is passed through unmodified from the Authentication Request to the ID Token.
		  Sufficient entropy MUST be present in the
		  <spanx style="verb">nonce</spanx> values used to prevent
		  attackers from guessing values.
		  For implementation notes, see <xref target="NonceNotes"/>.
		</t>

	      </list>
	    </t>


	    <figure>
	      <preamble>
		The following is a non-normative example request using the Hybrid Flow
		that would be sent by the User Agent to the Authorization Server
		in response to a corresponding HTTP 302 redirect response by the Client
		(with line wraps within values for display purposes only):
	      </preamble>

	      <artwork><![CDATA[
  GET /authorize?
    response_type=code%20id_token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile%20email
    &nonce=n-0S6_WzA2Mj
    &state=af0ifjsldkj HTTP/1.1
  Host: server.example.com
]]></artwork>
	    </figure>

	  </section>

	  <section anchor="HybridValidation" title="Authentication Request Validation">

	    <t>
	      When using the Hybrid Flow, the Authentication Request is validated
	      in the same manner as for the Authorization Code Flow,
	      as defined in <xref target="AuthRequestValidation"/>.
	    </t>
	  </section>

	  <section anchor="HybridAuthenticates" title="Authorization Server Authenticates End-User">

	    <t>
	      When using the Hybrid Flow, End-User Authentication is performed
	      in the same manner as for the Authorization Code Flow,
	      as defined in <xref target="Authenticates"/>.
	    </t>
	  </section>

	  <section anchor="HybridConsent" title="Authorization Server Obtains End-User Consent/Authorization">

	    <t>
	      When using the Hybrid Flow, End-User Consent is obtained
	      in the same manner as for the Authorization Code Flow,
	      as defined in <xref target="Consent"/>.
	    </t>
	  </section>

	  <section anchor="HybridAuthResponse" title="Successful Authentication Response">

	    <t>
	      When using the Hybrid Flow, Authentication Responses are made
	      in the same manner as for the Implicit Flow,
	      as defined in <xref target="ImplicitAuthResponse"/>,
	      with the exception of the differences specified in this section.
	    </t>

	    <t>
	      These Authorization Endpoint results are used in the following manner:
	    </t>
            <t>
	      <list style="hanging">
                <t hangText="access_token">
		  <vspace/>
		  OAuth 2.0 Access Token.
		  This is returned
		  when the <spanx style="verb">response_type</spanx> value used is
		  <spanx style="verb">code&nbsp;token</spanx>,
		  or <spanx style="verb">code&nbsp;id_token&nbsp;token</spanx>.
		  (A <spanx style="verb">token_type</spanx> value is also returned in the same cases.)
		</t>

                <t hangText="id_token">
		  <vspace/>
		  ID Token.
		  This is returned
		  when the <spanx style="verb">response_type</spanx> value used is
		  <spanx style="verb">code&nbsp;id_token</spanx> or
		  <spanx style="verb">code&nbsp;id_token&nbsp;token</spanx>.
		</t>

                <t hangText="code">
		  <vspace/>
		  Authorization Code.
		  This is always returned when using the Hybrid Flow.
		</t>

              </list>
	    </t>

            <figure>
              <preamble>The following is a non-normative example
	      of a successful response using the Hybrid Flow
	      (with line wraps for the display purposes only):</preamble>

              <artwork><![CDATA[
  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    code=SplxlOBeZQQYbYS6WxSbIA
    &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    &state=af0ifjsldkj
]]></artwork>
            </figure>

	  </section>

	  <section anchor="HybridAuthError" title="Authentication Error Response">

	    <t>
	      When using the Hybrid Flow, Authorization Error Responses are made
	      in the same manner as for the Authorization Code Flow,
	      as defined in <xref target="AuthError"/>,
	      with the exception of the differences specified in this section.
	    </t>
            <t>
	      If the End-User denies the request or the End-User authentication
	      fails, the Authorization Server MUST return the error
	      Authorization Response in the
	      fragment component of the Redirection URI,
	      as defined in 4.2.2.1 of 
	      <xref target="RFC6749">OAuth 2.0</xref> and
	      <xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref>,
	      unless a different Response Mode was specified.
	    </t>
	  </section>

	  <section anchor="HybridCallback" title="Redirect URI Fragment Handling">

	    <t>
	      When using the Hybrid Flow, the same requirements for
	      Redirection URI fragment parameter handling apply as do for
	      the Implicit Flow, as defined in <xref target="ImplicitCallback"/>.
	      Also see <xref target="FragmentNotes"/> for implementation notes
	      on URI fragment handling.
	    </t>
	  </section>

	  <section anchor="HybridAuthResponseValidation" title="Authentication Response Validation">

	    <t>
	      When using the Hybrid Flow,
	      the Client MUST validate the response as follows:
	      <list style="numbers">
		<t>
		  Verify that the response conforms to Section 5 of
		  <xref target="OAuth.Responses"/>.
		</t>
		<t>
		  Follow the validation rules in RFC 6749,
		  especially those in Sections 4.2.2 and 10.12.
		</t>
		<t>
		  Follow the ID Token validation rules in <xref target="HybridIDTValidation"/>
		  when the <spanx style="verb">response_type</spanx> value used is
		  <spanx style="verb">code&nbsp;id_token</spanx> or
		  <spanx style="verb">code&nbsp;id_token&nbsp;token</spanx>.
		</t>
		<t>
		  Follow the Access Token validation rules in <xref target="HybridTokenValidation"/>
		  when the <spanx style="verb">response_type</spanx> value used is
		  <spanx style="verb">code&nbsp;token</spanx> or
		  <spanx style="verb">code&nbsp;id_token&nbsp;token</spanx>.
		</t>
		<t>
		  Follow the Authorization Code validation rules in <xref target="CodeValidation"/>
		  when the <spanx style="verb">response_type</spanx> value used is
		  <spanx style="verb">code&nbsp;id_token</spanx> or
		  <!-- <spanx style="verb">code&nbsp;token</spanx>
		       is not included because Authorization Code validation requires an ID Token -->
		  <spanx style="verb">code&nbsp;id_token&nbsp;token</spanx>.
		</t>
	      </list>
	    </t>
	  </section>

	  <section anchor="HybridTokenValidation" title="Access Token Validation">

	    <t>
	      When using the Hybrid Flow, Access Tokens
	      returned from the Authorization Endpoint are validated
	      in the same manner as for the Implicit Flow,
	      as defined in <xref target="ImplicitTokenValidation"/>.
	    </t>
	  </section>

	  <section anchor="CodeValidation" title="Authorization Code Validation">

	    <t>To validate an Authorization Code issued from the Authorization Endpoint with an ID Token,
	    the Client SHOULD do the following:</t>

	    <t>
	      <list style="numbers">
		<t>Hash the octets of the ASCII representation of
		the <spanx style="verb">code</spanx> 
		with the hash algorithm specified in <xref target="JWA">JWA</xref> for the
		<spanx style="verb">alg</spanx> Header Parameter
		of the ID Token's JOSE Header.
		For instance, if the <spanx style="verb">alg</spanx> is
		<spanx style="verb">RS256</spanx>,
		the hash algorithm used is SHA-256.
		</t>

		<t>Take the left-most half of the hash and base64url-encode it.</t>

		<t>The value of <spanx style="verb">c_hash</spanx> in the ID Token MUST
		match the value produced in the previous step if <spanx style="verb">c_hash</spanx>
		is present in the ID Token.</t>
	      </list>
	    </t>
	  </section>

          <section anchor="HybridIDToken" title="ID Token">

	    <t>
	      The contents of the ID Token are as described in <xref target="IDToken"/>.
	      When using the Hybrid Flow,
	      these additional requirements for the following ID Token Claims apply
	      to an ID Token returned from the Authorization Endpoint:
	    </t>
            <t>
	      <list style="hanging">

                <t hangText="nonce">
		  <vspace/>
		  If a <spanx style="verb">nonce</spanx> parameter is present in the Authentication Request,
		  Authorization Servers MUST include a <spanx style="verb">nonce</spanx> Claim in the ID Token.
		</t>

                <t hangText="at_hash">
		  <vspace/>
		  Access Token hash value.
		  Its value is the base64url encoding of the left-most half of the
		  hash of the octets of the ASCII representation of the
		  <spanx style="verb">access_token</spanx> value,
		  where the hash algorithm used is the hash algorithm
		  used in the <spanx style="verb">alg</spanx> Header Parameter
		  of the ID Token's JOSE Header.
		  For instance, if the <spanx style="verb">alg</spanx> is
		  <spanx style="verb">RS256</spanx>, hash the
		  <spanx style="verb">access_token</spanx> value
		  with SHA-256, then take the left-most 128 bits and base64url-encode them.
		  The <spanx style="verb">at_hash</spanx> value is a case-sensitive string.
		</t>
		<t>
		  If the ID Token is issued from the Authorization Endpoint with an 
		  <spanx style="verb">access_token</spanx> value,
		  which is the case for the <spanx style="verb">response_type</spanx> value
		  <spanx style="verb">code&nbsp;id_token&nbsp;token</spanx>,
		  this is REQUIRED; otherwise, its inclusion is OPTIONAL.
		</t>

		<t hangText="c_hash">
		  <vspace/>
		  Code hash value.
		  Its value is the base64url encoding of the left-most half of the
		  hash of the octets of the ASCII representation of the
		  <spanx style="verb">code</spanx> value,
		  where the hash algorithm used is the hash algorithm
		  used in the <spanx style="verb">alg</spanx> Header Parameter
		  of the ID Token's JOSE Header.
		  For instance, if the <spanx style="verb">alg</spanx> is
		  <spanx style="verb">HS512</spanx>, hash the
		  <spanx style="verb">code</spanx> value
		  with SHA-512, then take the left-most 256 bits and base64url-encode them.
		  The <spanx style="verb">c_hash</spanx> value is a case-sensitive string.
		</t>
		<t>
		  If the ID Token is issued from the Authorization Endpoint with a
		  <spanx style="verb">code</spanx>,
		  which is the case for the <spanx style="verb">response_type</spanx> values
		  <spanx style="verb">code&nbsp;id_token</spanx> and
		  <spanx style="verb">code&nbsp;id_token&nbsp;token</spanx>,
		  this is REQUIRED; otherwise, its inclusion is OPTIONAL.
		</t>

	      </list>
	    </t>
	  </section>

	  <section anchor="HybridIDTValidation" title="ID Token Validation">

	    <t>
	      When using the Hybrid Flow, the contents of an ID Token
	      returned from the Authorization Endpoint MUST be validated
	      in the same manner as for the Implicit Flow,
	      as defined in <xref target="ImplicitIDTValidation"/>.
	    </t>
	  </section>

	</section>

	<section anchor="HybridTokenEndpoint" title="Token Endpoint">

	  <t>
	    When using the Hybrid Flow, the Token Endpoint is used
	    in the same manner as for the Authorization Code Flow,
	    as defined in <xref target="TokenEndpoint"/>,
	    with the exception of the differences specified in this section.
	  </t>

	  <section anchor="HybridTokenRequest" title="Token Request">

	    <t>
	      When using the Hybrid Flow, Token Requests are made
	      in the same manner as for the Authorization Code Flow,
	      as defined in <xref target="TokenRequest"/>.
	    </t>
	  </section>

	  <section anchor="HybridTokenRequestValidation" title="Token Request Validation">

	    <t>
	      When using the Hybrid Flow, Token Requests are validated
	      in the same manner as for the Authorization Code Flow,
	      as defined in <xref target="TokenRequestValidation"/>.
	    </t>
	  </section>

	  <section anchor="HybridTokenResponse" title="Successful Token Response">

	    <t>
	      When using the Hybrid Flow, Token Responses are made
	      in the same manner as for the Authorization Code Flow,
	      as defined in <xref target="TokenResponse"/>.
	    </t>
	  </section>

	  <section anchor="HybridTokenErrorResponse" title="Token Error Response">

	    <t>
	      When using the Hybrid Flow, Token Error Responses are made
	      in the same manner as for the Authorization Code Flow,
	      as defined in <xref target="TokenErrorResponse"/>.
	    </t>
	  </section>

	  <section anchor="HybridTokenResponseValidation" title="Token Response Validation">

	    <t>
	      When using the Hybrid Flow, Token Responses are validated
	      in the same manner as for the Authorization Code Flow,
	      as defined in <xref target="TokenResponseValidation"/>.
	    </t>
	  </section>

          <section anchor="HybridIDToken2" title="ID Token">

	    <t>
	      When using the Hybrid Flow, the contents of an ID Token
	      returned from the Token Endpoint are
	      the same as for an ID Token returned from the Authorization Endpoint,
	      as defined in <xref target="HybridIDToken"/>,
	      with the exception of the differences specified in this section.
	    </t>
	    <t>
	      If an ID Token is returned from both the Authorization Endpoint
	      and from the Token Endpoint,
	      which is the case for the <spanx style="verb">response_type</spanx> values
	      <spanx style="verb">code&nbsp;id_token</spanx> and
	      <spanx style="verb">code&nbsp;id_token&nbsp;token</spanx>,
	      the <spanx style="verb">iss</spanx> and <spanx style="verb">sub</spanx>
	      Claim Values MUST be identical in both ID Tokens.
	      All Claims about the Authentication event present in either
	      SHOULD be present in both.
	      If either ID Token contains Claims about the End-User,
	      any that are present in both SHOULD have the same values in both.
	      Note that the OP MAY choose to return fewer Claims about the End-User
	      from the Authorization Endpoint, for instance, for privacy reasons.
	      The <spanx style="verb">at_hash</spanx>
	      and <spanx style="verb">c_hash</spanx> Claims
	      MAY be omitted from the ID Token returned from the Token Endpoint
	      even when these Claims are
	      present in the ID Token returned from the Authorization Endpoint,
	      because the ID Token and Access Token values returned from
	      the Token Endpoint are already cryptographically bound together
	      by the TLS encryption performed by the Token Endpoint.
	    </t>
	  </section>

	  <section anchor="HybridIDTValidation2" title="ID Token Validation">

	    <t>
	      When using the Hybrid Flow, the contents of an ID Token
	      returned from the Token Endpoint MUST be validated
	      in the same manner as for the Authorization Code Flow,
	      as defined in <xref target="IDTokenValidation"/>.
	    </t>
	  </section>

          <section anchor="HybridAccessToken2" title="Access Token">

	    <t>
	      If an Access Token is returned from both the Authorization Endpoint
	      and from the Token Endpoint,
	      which is the case for the <spanx style="verb">response_type</spanx> values
	      <spanx style="verb">code&nbsp;token</spanx> and
	      <spanx style="verb">code&nbsp;id_token&nbsp;token</spanx>,
	      their values MAY be the same
	      or they MAY be different.
	      Note that different Access Tokens might be returned
	      be due to the different security characteristics
	      of the two endpoints and the lifetimes and
	      the access to resources granted by them might also be different.
	    </t>
	  </section>

	  <section anchor="HybridTokenValidation2" title="Access Token Validation">

	    <t>
	      When using the Hybrid Flow, the Access Token
	      returned from the Token Endpoint
	      is validated
	      in the same manner as for the Authorization Code Flow,
	      as defined in <xref target="CodeFlowTokenValidation"/>.
	    </t>
	  </section>

	</section>
      </section>

    </section>

    <section anchor="ThirdPartyInitiatedLogin" title="Initiating Login from a Third Party">
      <t>
	In some cases, the login flow is initiated by an OpenID Provider
	or another party, rather than the Relying Party.
	In this case, the initiator redirects to the RP at its login initiation endpoint,
	which requests that the RP send an Authentication Request to a specified OP.
	Note that this login initiation endpoint can be a different page at the RP
	than the RP's default landing page.
	RPs supporting
	<xref target="OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</xref>
	register this endpoint value using the
	<spanx style="verb">initiate_login_uri</spanx> Registration parameter.
      </t>
      <t>
	The party initiating the login request does so by redirecting
	to the login initiation endpoint at the RP, passing the following parameters:
      </t>
      <t>
	<list style="hanging">
          <t hangText="iss">
	    <vspace/>
	    REQUIRED.
	    Issuer Identifier for the OP that the RP is to send
	    the Authentication Request to. 
            Its value MUST be a URL using the <spanx style="verb">https</spanx> scheme.
          </t>
          <t hangText="login_hint">
	    <vspace/>
	    OPTIONAL.
	    Hint to the Authorization Server
            about the login identifier the End-User might use to log in.
	    If the client receives a value for this string-valued parameter,
	    it MUST include it in the Authentication Request
	    as the <spanx style="verb">login_hint</spanx> parameter value.
          </t>
          <t hangText="target_link_uri">
	    <vspace/>
	    OPTIONAL.
	    URL that the RP is requested to redirect to after authentication.
	    RPs MUST verify the value of the
            <spanx style="verb">target_link_uri</spanx> to prevent being used as
	    an open redirector to external sites.
          </t>

        </list>
      </t>
      <t>
	The parameters can either be passed as query parameters using
	the HTTP <spanx style="verb">GET</spanx> method
	or be passed as HTML form values that are auto-submitted in the User Agent,
	and thus are transmitted via the HTTP <spanx style="verb">POST</spanx> method.
      </t>
      
      <t>
	Other parameters MAY be sent, if defined by extensions.
	Any parameters used that are not understood MUST be ignored by the Client.
      </t>
      
      <t>
	Clients SHOULD employ frame busting and other techniques to prevent
	End-Users from being logged in by third party sites without their knowledge
	through attacks such as Clickjacking.
	Refer to Section 4.4.1.9 of <xref target="RFC6819"/> for more details.
      </t>
      
    </section>

    <section anchor="Claims" title="Claims">
      <t>
	This section specifies how the Client can obtain Claims about the End-User
	and the Authentication event.
	It also defines a standard set of basic profile Claims.
	Pre-defined sets of Claims can be requested using specific scope values
	or individual Claims can be requested using the
	<spanx style="verb">claims</spanx> request parameter.
	The Claims can come directly from the OpenID Provider
	or from distributed sources as well.
      </t>

      <section anchor="StandardClaims" title="Standard Claims">
	<t>This specification defines a set of standard Claims.
	They can be requested to be returned either in the
	UserInfo Response, per <xref target="UserInfoResponse"/>,
	or in the ID Token, per <xref target="IDToken"/>.
	</t>

	<texttable anchor="ClaimTable" title="Registered Member Definitions">
	  <ttcol align="left">Member</ttcol>

	  <ttcol align="left">Type</ttcol>

	  <ttcol align="left">Description</ttcol>

	  <c>sub</c>
	  <c>string</c>
	  <c>Subject - Identifier for the End-User at the Issuer.</c>

	  <c>name</c>
	  <c>string</c>
	  <c>
	    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.
	  </c>

	  <c>given_name</c>
	  <c>string</c>
	  <c>
	    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.
	  </c>

	  <c>family_name</c>
	  <c>string</c>
	  <c>
	    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.
	  </c>

	  <c>middle_name</c>
	  <c>string</c>
	  <c>
	    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.
	  </c>

	  <c>nickname</c>
	  <c>string</c>
	  <c>Casual name of the End-User that may or may not be the same as the
	  <spanx style="verb">given_name</spanx>. For instance, a <spanx
	  style="verb">nickname</spanx> value of <spanx style="verb">Mike</spanx>
	  might be returned alongside a <spanx style="verb">given_name</spanx>
	  value of <spanx style="verb">Michael</spanx>.</c>

	  <c>preferred_username</c>
	  <c>string</c>
	  <c>Shorthand name by which the End-User wishes to be referred to at the RP, such as
	  <spanx style="verb">janedoe</spanx> or <spanx style="verb">j.doe</spanx>. 
	  This value MAY be any valid JSON string including 
	  special characters such as <spanx style="verb">@</spanx>, 
	  <spanx style="verb">/</spanx>, or whitespace.
	  The RP MUST NOT rely upon this value being unique,
	  as discussed in <xref target="ClaimStability"></xref>.
	  </c>

	  <c>profile</c>
	  <c>string</c>
	  <c>
	    URL of the End-User's profile page.
	    The contents of this Web page SHOULD be about the End-User.
	  </c>

	  <c>picture</c>
	  <c>string</c>
	  <c>
	    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.
	  </c>

	  <c>website</c>
	  <c>string</c>
	  <c>
	    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.
	  </c>

	  <c>email</c>
	  <c>string</c>
	  <c>
	    End-User's preferred e-mail address.
	    Its value MUST conform to the <xref target="RFC5322">RFC 5322</xref>
	    addr-spec syntax.
	    The RP MUST NOT rely upon this value being unique,
	    as discussed in <xref target="ClaimStability"></xref>.
	  </c>

	  <c>email_verified</c>
	  <c>boolean</c>
	  <c>
	    True if the End-User's e-mail address has been verified; otherwise false.
	    When this Claim Value is <spanx style="verb">true</spanx>,
	    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.
	  </c>

	  <c>gender</c>
	  <c>string</c>
	  <c> End-User's gender.  Values defined by this
	  specification are <spanx style="verb">female</spanx> and
	  <spanx style="verb">male</spanx>.  Other values MAY be used
	  when neither of the defined values are applicable.</c>

	  <c>birthdate</c>
	  <c>string</c>
	  <c>End-User's birthday, represented as an
	  <xref target="ISO8601-2004">ISO 8601:2004</xref> <spanx style="verb">YYYY-MM-DD</spanx>
	  format. The year MAY be <spanx style="verb">0000</spanx>, indicating that it is omitted.
	  To represent only the year, <spanx style="verb">YYYY</spanx> format is allowed. Note that
	  depending on the underlying platform's date related function, providing just year can
	  result in varying month and day, so the implementers need to take this factor into account
	  to correctly process the dates. </c>

	  <c>zoneinfo</c>
	  <c>string</c>
	  <c>String from zoneinfo <xref target="zoneinfo"/> time zone
	  database representing the End-User's time zone.
	  For example, <spanx style="verb">Europe/Paris</spanx> or
	  <spanx style="verb">America/Los_Angeles</spanx>.</c>

	  <c>locale</c>
	  <c>string</c>
	  <c>End-User's locale, represented as a
	  <xref target="RFC5646">BCP47</xref> language tag.
	  This is typically an <xref target="ISO639-1">ISO 639-1 Alpha-2</xref>
	  language code in
	  lowercase and an <xref target="ISO3166-1">ISO 3166-1 Alpha-2</xref>
	  country code in uppercase, separated by a dash. For example,
	  <spanx style="verb">en-US</spanx> or <spanx style="verb">fr-CA</spanx>.
	  As a compatibility note, some implementations have used an underscore
	  as the separator rather than a dash, for example,
	  <spanx style="verb">en_US</spanx>; Relying Parties MAY choose to
	  accept this locale syntax as well.</c>

	  <c>phone_number</c>
	  <c>string</c>
	  <c>
	    End-User's preferred telephone number. <xref target="E.164">E.164</xref>
	    is RECOMMENDED as the format of this Claim,
	    for example, <spanx style="verb">+1 (425) 555-1212</spanx>
	    or <spanx style="verb">+56 (2) 687 2400</spanx>.
	    If the phone number contains an extension, it is RECOMMENDED that
	    the extension be represented using the
	    <xref target="RFC3966">RFC 3966</xref> extension syntax,
	    for example, <spanx style="verb">+1 (604) 555-1234;ext=5678</spanx>.
	  </c>

	  <c>phone_number_verified</c>
	  <c>boolean</c>
	  <c>
	    True if the End-User's phone number has been verified; otherwise false.
	    When this Claim Value is <spanx style="verb">true</spanx>,
	    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 <spanx style="verb">phone_number</spanx>
	    Claim MUST be in E.164 format
	    and any extensions MUST be represented in RFC 3966 format.
	  </c>

	  <c>address</c>
	  <c>JSON object</c>
	  <c>
	    End-User's preferred postal address.
	    The value of the <spanx style="verb">address</spanx> member is
	    a JSON <xref target="RFC4627"/> structure containing some or all of
	    the members defined in <xref target="AddressClaim"/>.
	  </c>

	  <c>updated_at</c>
	  <c>number</c>
	  <c>
	    Time the End-User's information was last updated.
	    Its value is a JSON number representing the number of seconds from
	    1970-01-01T00:00:00Z as measured in UTC until the date/time.
	  </c>
	</texttable>

	<section anchor="AddressClaim" title="Address Claim">
	  <t>
	    The Address Claim represents a physical mailing address. 
	    Implementations MAY return only a subset of the
	    fields of an <spanx style="verb">address</spanx>, depending upon
	    the information available and the End-User's privacy 
	    preferences. For
	    example, the <spanx style="verb">country</spanx> and <spanx 
	    style="verb">region</spanx> might be returned without returning
	    more fine-grained address information.
	  </t>
	  <t>
	    Implementations MAY return just the full address 
	    as a single string in the formatted sub-field, 
	    or they MAY return just the individual component 
	    fields using the other sub-fields, 
	    or they MAY return both. 
	    If both variants are returned, 
	    they SHOULD be describing the same address, 
	    with the formatted address indicating how the 
	    component fields are combined.
	  </t>
	  <t>
	    <list style="hanging">
	      <t hangText="formatted">
		<vspace/>
		Full mailing address, 
		formatted for display or use on a mailing label. 
		This field MAY contain multiple lines, separated by newlines.
		Newlines can be represented either as
		a carriage return/line feed pair ("\r\n") or as
		a single line feed character ("\n").
	      </t>

	      <t hangText="street_address">
		<vspace/>
		Full street address component, 
		which MAY include house number, street name, 
		Post Office Box, and multi-line extended street 
		address information.
		This field MAY contain multiple lines, separated by newlines.
		Newlines can be represented either as
		a carriage return/line feed pair ("\r\n") or as
		a single line feed character ("\n").
	      </t>

	      <t hangText="locality">
		<vspace/>
		City or locality component.
	      </t>

	      <t hangText="region">
		<vspace/>
		State, province, 
		prefecture, or region component.
	      </t>

	      <t hangText="postal_code">
		<vspace/>
		Zip code or 
		postal code component.
	      </t>

	      <t hangText="country">
		<vspace/>
		Country name component.
	      </t>
	    </list>
	  </t>
	</section>

	<section anchor="AdditionalClaims" title="Additional Claims">
	  <t>
	    While this specification defines only a small set of Claims as
	    standard Claims, other Claims MAY be used in conjunction
	    with the standard Claims.
	    When using such Claims, it is RECOMMENDED that
	    collision-resistant names be used for the Claim Names,
	    as described in <!-- Section 4.2 (Public Claim Names) of --> the
	    <xref target="JWT">JSON Web Token (JWT)</xref> specification.
	    Alternatively, Private Claim Names can be safely used
	    when naming conflicts are unlikely to arise,
	    as described in <!-- Section 4.3 of --> the JWT specification.
	    Or, if specific additional Claims will have broad and general applicability,
	    they can be registered with Registered Claim Names,
	    per <!-- Sections 4.1 and 10.1 of --> the JWT specification.
	  </t>
	</section>
      </section>

      <section anchor="ClaimsLanguagesAndScripts" title="Claims Languages and Scripts">
	<t>
	  Human-readable Claim Values and Claim Values that reference human-readable values
	  MAY be represented in multiple languages and scripts.
	  To specify the languages and scripts, <xref
	  target="RFC5646">BCP47</xref> language tags are added to member names,
	  delimited by a <spanx style="verb">#</spanx> character.  For example,
	  <spanx style="verb">family_name#ja-Kana-JP</spanx> expresses the
	  Family Name in Katakana in Japanese, which is commonly used to index
	  and represent the phonetics of the Kanji representation of the same
	  represented as <spanx style="verb">family_name#ja-Hani-JP</spanx>.
	  As another example, both <spanx style="verb">website</spanx> and
	  <spanx style="verb">website#de</spanx> Claim Values might be returned,
	  referencing a Web site in an unspecified language and a Web site
	  in German.
	</t>
	<t>
	  Since Claim Names are case sensitive, it is strongly RECOMMENDED
	  that language tag values used in Claim Names be spelled using the
	  character case with which they are registered in the
	  IANA "Language Subtag Registry" <xref target="IANA.Language"/>.
	  In particular, normally language names are spelled with lowercase characters,
	  region names are spelled with uppercase characters, and
	  scripts are spelled with mixed case characters.
	  However, since BCP47 language tag values are case insensitive,
	  implementations SHOULD interpret the language tag values supplied
	  in a case-insensitive manner.
	</t>
	<t>
	  Per the recommendations in BCP47, language tag values for Claims
	  SHOULD only be as specific as necessary.
	  For instance, using <spanx style="verb">fr</spanx> might be sufficient
	  in many contexts, rather than <spanx style="verb">fr-CA</spanx> or
	  <spanx style="verb">fr-FR</spanx>.
	  Where possible, OPs SHOULD try to match requested Claim locales with
	  Claims it has.  For instance, if the Client asks for a Claim with
	  a <spanx style="verb">de</spanx> (German) language tag and the OP
	  has a value tagged with <spanx style="verb">de-CH</spanx> (Swiss German)
	  and no generic German value, it would be appropriate for the OP
	  to return the Swiss German value to the Client.
	  (This intentionally moves as much of the complexity of language tag
	  matching to the OP as possible, to simplify Clients.)
	</t>
	<t>
	  OpenID Connect defines the following Authorization Request parameter
	  to enable specify the preferred languages and scripts to be used
	  for the returned Claims:

	  <list style="hanging">

	    <t hangText="claims_locales">
	      <vspace/>
	      OPTIONAL.
	      End-User's preferred languages and scripts for Claims being returned, 
	      represented as a space-separated list of
	      <xref target="RFC5646">BCP47</xref> language tag values,
	      ordered by preference.
	      An error SHOULD NOT result if some or all of the requested locales
	      are not supported by the OpenID Provider.
	    </t>
	  </list>
	</t>
	<t>
	  When the OP determines, either through the
	  <spanx style="verb">claims_locales</spanx> parameter,
	  or by other means, that the End-User and Client are
	  requesting Claims in only one set of languages and scripts,
	  it is RECOMMENDED that OPs return Claims without language tags
	  when they employ this language and script.
	  It is also RECOMMENDED that Clients be written in a manner
	  that they can handle and utilize Claims using language tags.
	</t>

      </section>

      <section anchor="UserInfo" title="UserInfo Endpoint">

	<t>
	  The UserInfo Endpoint is an OAuth 2.0 Protected Resource that
	  returns Claims about the authenticated End-User.
	  To obtain the requested Claims about the End-User, the Client
	  makes a request to the UserInfo Endpoint
	  using an Access Token obtained through OpenID Connect Authentication.
	  These Claims are normally represented by a JSON object that contains
	  a collection of name and value pairs for the Claims.
	</t>
	<t>
	  Communication with the UserInfo Endpoint MUST utilize TLS.
	  See <xref target="TLSRequirements"/> for more information on using TLS.
	</t>

	<t>
	  The UserInfo Endpoint MUST support the use of the
	  HTTP <spanx style="verb">GET</spanx> and
	  HTTP <spanx style="verb">POST</spanx> methods
	  defined in <xref target="RFC7231">RFC 7231</xref>.
	</t>

	<t>The UserInfo Endpoint MUST accept Access Tokens as
	<xref target="RFC6750">OAuth 2.0 Bearer Token Usage</xref>.</t>
	
	<t>The UserInfo Endpoint SHOULD support the use of 
	<xref target="CORS">Cross Origin Resource Sharing (CORS)</xref> and
	or other methods as appropriate to enable Java Script Clients to access the endpoint.</t>

	<section anchor="UserInfoRequest" title="UserInfo Request">

	  <t>
	    The Client sends the UserInfo Request using either
	    HTTP <spanx style="verb">GET</spanx> or HTTP <spanx style="verb">POST</spanx>.
	    The Access Token obtained
	    from an OpenID Connect Authentication Request MUST be sent as a Bearer Token,
	    per Section 2 of <xref target="RFC6750">OAuth 2.0 Bearer Token Usage</xref>.
	  </t>
	  <t>
	    It is RECOMMENDED that the request use the 
	    HTTP <spanx style="verb">GET</spanx> method and
	    the Access Token be sent using the
	    <spanx style="verb">Authorization</spanx> header field.
	  </t>

	  <figure>
	    <preamble>
	      The following is a non-normative example of a UserInfo Request:
	    </preamble>

	    <artwork><![CDATA[
  GET /userinfo HTTP/1.1
  Host: server.example.com
  Authorization: Bearer SlAV32hkKG
]]></artwork>
	  </figure>
	</section>

	<section anchor="UserInfoResponse" title="Successful UserInfo Response">
	  <t>
	    The UserInfo Claims MUST be returned as the members of a JSON object
	    unless a signed or encrypted response was requested during Client Registration.
	    The Claims defined in <xref target="StandardClaims"/> can be returned,
	    as can additional Claims not specified there.
	  </t>
	  <t>
	    For privacy reasons, OpenID Providers MAY elect to not return
	    values for some requested Claims.
	  </t>
	  <t>
	    If a Claim is not returned, that Claim Name SHOULD be
	    omitted from the JSON object representing the Claims; it
	    SHOULD NOT be present with a null or empty string value.
	  </t>
	  <t>
	    The <spanx style="verb">sub</spanx> (subject) Claim
	    MUST always be returned in the UserInfo Response.
	  </t>
	  <t>
	    NOTE:  Due to the possibility of token substitution attacks
	    (see <xref target="TokenSubstitution"/>),
	    the UserInfo Response is not guaranteed to be about the
	    End-User identified by the <spanx style="verb">sub</spanx> (subject)
	    element of the ID Token.
	    The <spanx style="verb">sub</spanx> Claim in the UserInfo Response
	    MUST be verified to exactly match the
	    <spanx style="verb">sub</spanx> Claim in the ID Token;
	    if they do not match, the UserInfo Response values MUST NOT be used.
	  </t>
	  <t>
	    Upon receipt of the UserInfo Request, the UserInfo Endpoint MUST
	    return the JSON Serialization of the UserInfo Response as in
	    <xref target="JSONSerialization"/> in the HTTP response
	    body unless a
	    different format was specified during Registration
	    <xref target="OpenID.Registration"/>.
	    The UserInfo Endpoint MUST return a content-type header to indicate
	    which format is being returned.
	    The content-type of the HTTP response MUST be <spanx
	    style="verb">application/json</spanx> if the response body is a text
	    JSON object;
	    the response body SHOULD be encoded using UTF-8.
	  </t>
	  <t>
	    If the UserInfo Response is
	    signed and/or encrypted, then the Claims are returned in a JWT and the
	    content-type MUST be <spanx style="verb">application/jwt</spanx>.
	    The response MAY be encrypted without also being signed.
	    If both signing and encryption are requested,
	    the response MUST be signed then encrypted,
	    with the result being a Nested JWT, as defined in <xref target="JWT"/>.
	  </t>
	  <t>
	    If signed, the UserInfo Response
	    SHOULD contain the Claims
	    <spanx style="verb">iss</spanx> (issuer)
	    and <spanx style="verb">aud</spanx> (audience) as members.
	    The <spanx style="verb">iss</spanx> value SHOULD be the OP's Issuer Identifier URL.
	    The <spanx style="verb">aud</spanx> value SHOULD be or include the RP's Client ID value.
	  </t>

	  <figure>
	    <preamble>The following is a non-normative example
	    of a UserInfo Response:</preamble>

	    <artwork><![CDATA[
  HTTP/1.1 200 OK
  Content-Type: application/json

  {
   "sub": "248289761001",
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "preferred_username": "j.doe",
   "email": "janedoe@example.com",
   "picture": "http://example.com/janedoe/me.jpg"
  }
]]></artwork>
	  </figure>
	</section>

	<section anchor="UserInfoError" title="UserInfo Error Response">

	  <t>
	    When an error condition occurs, the UserInfo Endpoint returns
	    an Error Response as defined in Section 3 of
	    <xref target="RFC6750">OAuth 2.0 Bearer Token Usage</xref>.
	    (HTTP errors unrelated to RFC 6750 are returned to the User Agent using the
	    appropriate HTTP status code.)
	  </t>

	  <figure>
	    <preamble>The following is a non-normative example
	    of a UserInfo Error Response:</preamble>

	    <artwork><![CDATA[
  HTTP/1.1 401 Unauthorized
  WWW-Authenticate: Bearer error="invalid_token",
    error_description="The Access Token expired"
]]></artwork>
	  </figure>
	</section>

	<section anchor="UserInfoResponseValidation" title="UserInfo Response Validation">

	  <t>
	    The Client MUST validate the UserInfo Response as follows:
	  </t>

	  <t>
	    <list style="numbers">
	      <t>Verify that the OP that responded was the intended OP
	      through a TLS server certificate check, per
	      <xref target="RFC6125">RFC 6125</xref>.</t>

	      <t>If the Client has provided a 
	      <spanx style="verb">userinfo_encrypted_response_alg</spanx>
	      parameter during Registration, decrypt the UserInfo Response
	      using the keys specified during Registration.</t>

	      <t>If the response was signed, the Client SHOULD validate the
	      signature according to <xref
	      target="JWS">JWS</xref>.</t>
	    </list>
	  </t>
	</section>

      </section>

      <section anchor="ScopeClaims" title="Requesting Claims using Scope Values">

	<t>
	  OpenID Connect Clients use <spanx style="verb">scope</spanx> values,
	  as defined in Section 3.3 of <xref target="RFC6749">OAuth 2.0</xref>,
	  to specify what
	  access privileges are being requested for Access Tokens. The scopes associated
	  with Access Tokens determine what resources will be available when they are 
	  used to access OAuth 2.0 protected endpoints.
	  Protected Resource endpoints MAY perform different actions and
	  return different information based on the scope values and other parameters
	  used when requesting the presented Access Token.
	</t>
	<t>
	  For OpenID Connect, scopes
	  can be used to request that specific sets of information
	  be made available as Claim Values.
	</t>
	<t>
	  Claims requested by the following scopes are treated by Authorization Servers
	  as Voluntary Claims.
	</t>

	<t>
	  OpenID Connect defines the following <spanx style="verb">scope</spanx> values
	  that are used to request Claims:
	</t>
	<t>
	  <list style="hanging">

	    <t hangText="profile">
	      <vspace/>
	      OPTIONAL. This scope value 
	      requests access to the End-User's default profile Claims,
	      which are:

	      <spanx style="verb">name</spanx>,
	      <spanx style="verb">family_name</spanx>,
	      <spanx style="verb">given_name</spanx>,
	      <spanx style="verb">middle_name</spanx>,
	      <spanx style="verb">nickname</spanx>,
	      <spanx style="verb">preferred_username</spanx>,
	      <spanx style="verb">profile</spanx>,
	      <spanx style="verb">picture</spanx>,
	      <spanx style="verb">website</spanx>,
	      <spanx style="verb">gender</spanx>,
	      <spanx style="verb">birthdate</spanx>,
	      <spanx style="verb">zoneinfo</spanx>,
	      <spanx style="verb">locale</spanx>, and
	      <spanx style="verb">updated_at</spanx>.
	    </t>

	    <t hangText="email">
	      <vspace/>
	      OPTIONAL. This scope value requests access to
	      the <spanx style="verb">email</spanx> and
	      <spanx style="verb">email_verified</spanx> Claims.
	    </t>

	    <t hangText="address">
	      <vspace/>
	      OPTIONAL. This scope value requests access to
	      the <spanx style="verb">address</spanx> Claim.
	    </t>

	    <t hangText="phone">
	      <vspace/>
	      OPTIONAL. This scope value requests access to
	      the <spanx style="verb">phone_number</spanx> and
	      <spanx style="verb">phone_number_verified</spanx> Claims.
	    </t>

	  </list>
	</t>

	<t>
	  Multiple scope values MAY be used by creating a space-delimited,
	  case-sensitive list of ASCII scope values.
	</t>

	<t>
	  The Claims requested by the
	  <spanx style="verb">profile</spanx>,
	  <spanx style="verb">email</spanx>,
	  <spanx style="verb">address</spanx>, and
	  <spanx style="verb">phone</spanx> scope values
	  are returned from the UserInfo Endpoint,
	  as described in <xref target="UserInfoResponse"/>,
	  when a <spanx style="verb">response_type</spanx> value is used
	  that results in an Access Token being issued.
	  However, when no Access Token is issued
	  (which is the case for the <spanx style="verb">response_type</spanx>
	  value <spanx style="verb">id_token</spanx>),
	  the resulting Claims are returned in the ID Token.
	</t>

	<t>In some cases, the End-User will be given the option to
	have the OpenID Provider decline to provide some or all
	information requested by RPs.
	To minimize the amount of information that the End-User is being asked
	to disclose, an RP can elect to
	only request a subset of the information available from the
	UserInfo Endpoint.</t>

	<t>
	  <figure>
	    <preamble>
	      The following is a non-normative example of an unencoded
	      <spanx style="verb">scope</spanx> request:
	    </preamble>

	    <artwork><![CDATA[
  scope=openid profile email phone
]]></artwork>
	  </figure>
	</t>
      </section>

      <section anchor="ClaimsParameter" title='Requesting Claims using the "claims" Request Parameter'>

	<t>
	  OpenID Connect defines the following Authorization Request parameter
	  to enable requesting individual Claims
	  and specifying parameters that apply to the requested Claims:

	  <list style="hanging">

	    <t hangText="claims">
	      <vspace/>
	      OPTIONAL.
	      This parameter is used to request that specific Claims be returned.
	      The value is a JSON object listing the requested Claims.
	    </t>
	  </list>
	</t>
	<t>
	  The <spanx style="verb">claims</spanx> Authentication Request
	  parameter requests that specific Claims
	  be returned from the UserInfo Endpoint and/or in the ID Token.
	  It is represented as a JSON object containing lists of Claims being requested
	  from these locations.
	  Properties of the Claims being requested MAY also be specified.
	</t>
	<t>
	  Support for the <spanx style="verb">claims</spanx> parameter is OPTIONAL.
	  Should an OP not support this parameter and an RP uses it,
	  the OP SHOULD return a set of Claims to the RP that it believes would
	  be useful to the RP and the End-User using whatever heuristics it
	  believes are appropriate.
	  The <spanx style="verb">claims_parameter_supported</spanx>
	  Discovery result indicates whether the OP supports this parameter.
	</t>
	<t>
	  The <spanx style="verb">claims</spanx> parameter value is represented
	  in an OAuth 2.0 request as UTF-8 encoded JSON
	  (which ends up being form-urlencoded when passed as an OAuth parameter).
	  When used in a Request Object value, per <xref target="RequestObject"/>,
	  the JSON is used as the value of the
	  <spanx style="verb">claims</spanx> member.
	</t>
	<t>
	  The top-level members of the Claims request JSON object are:

	  <list style="hanging">
	    <t hangText="userinfo">
	      <vspace/>
	      OPTIONAL.
	      Requests that the listed individual Claims be returned
	      from the UserInfo Endpoint.
	      If present, the listed Claims are being requested to be added to
	      any Claims that are being requested using
	      <spanx style="verb">scope</spanx> values.
	      If not present, the Claims being requested from the UserInfo Endpoint
	      are only those requested using  <spanx style="verb">scope</spanx> values.
	    </t>
	    <t>
	      When the <spanx style="verb">userinfo</spanx> member is used,
	      the request MUST also use a <spanx style="verb">response_type</spanx>
	      value that results in an Access Token being issued to the Client
	      for use at the UserInfo Endpoint.
	    </t>

	    <t hangText="id_token">
	      <vspace/>
	      OPTIONAL.
	      Requests that the listed individual Claims be returned
	      in the ID Token.
	      If present, the listed Claims are being requested to be added to
	      the default Claims in the ID Token.
	      If not present, the default ID Token Claims are requested,
	      as per the ID Token definition in <xref target="IDToken"/>
	      and per the additional per-flow ID Token requirements in Sections
	      <xref target="CodeIDToken" format="counter"/>,
	      <xref target="ImplicitIDToken" format="counter"/>,
	      <xref target="HybridIDToken" format="counter"/>,
	      and <xref target="HybridIDToken2" format="counter"/>.
	    </t>

	  </list>
	</t>
	<t>
	  Other members MAY be present.
	  Any members used that are not understood MUST be ignored.
	</t>

	<t>
	  <figure>
	    <preamble>An example Claims request is as follows:</preamble>

	    <artwork><![CDATA[
  {
   "userinfo":
    {
     "given_name": {"essential": true},
     "nickname": null,
     "email": {"essential": true},
     "email_verified": {"essential": true},
     "picture": null,
     "http://example.info/claims/groups": null
    },
   "id_token":
    {
     "auth_time": {"essential": true},
     "acr": {"values": ["urn:mace:incommon:iap:silver"] }
    }
  }
]]></artwork>
	  </figure>
	  Note that a Claim that is not in the standard set defined in
	  <xref target="StandardClaims"/>, the (example)
	  <spanx style="verb">http://example.info/claims/groups</spanx> Claim,
	  is being requested.
	  Using the <spanx style="verb">claims</spanx> parameter is the only
	  way to request Claims outside the standard set.
	  It is also the only way to request specific combinations of the
	  standard Claims that cannot be specified using scope values.
	</t>

	<section anchor="IndividualClaimsRequests" title="Individual Claims Requests">
	  <t>
	    The <spanx style="verb">userinfo</spanx> and
	    <spanx style="verb">id_token</spanx> members of the
	    <spanx style="verb">claims</spanx> request both are JSON objects
	    with the names of the individual Claims being requested as the member names.
	    The member values MUST be one of the following:

	    <list style="hanging">
	      <t hangText="null">
		<vspace/>
		Indicates that this Claim is being requested in the default manner.
		In particular, this is a Voluntary Claim.
		For instance, the Claim request:

		<figure>
		  <artwork><![CDATA[
  "given_name": null
]]></artwork>
		</figure>

		requests the <spanx style="verb">given_name</spanx> Claim
		in the default manner.
	      </t>
	      <t hangText="JSON Object">
		<vspace/>
		Used to provide additional information about the Claim being 
		requested. This specification defines the following members: 

		<list style="hanging">
		  <t hangText="essential">
		    <vspace/>
		    OPTIONAL.
		    Indicates whether the Claim being requested is an Essential Claim.
		    If the value is <spanx style="verb">true</spanx>, 
		    this indicates that the Claim is an Essential Claim.
		    For instance, the Claim request:

		    <figure>
		      <artwork><![CDATA[
  "auth_time": {"essential": true}
]]></artwork>
		    </figure>

		    can be used to specify that it is Essential to return an
		    <spanx style="verb">auth_time</spanx> Claim Value.
		  </t>
		  <t>
		    If the value is <spanx style="verb">false</spanx>,
		    it indicates that it is a Voluntary Claim.
		    The default is <spanx style="verb">false</spanx>.
		  </t>
		  <t>
		    By requesting Claims as Essential Claims,
		    the RP indicates to the End-User
		    that releasing these Claims will ensure a smooth authorization
		    for the specific task requested by the End-User.
		    Note that even if the Claims are not available because
		    the End-User did not authorize their release or they are not present,
		    the Authorization Server MUST NOT generate an error when
		    Claims are not returned, whether they are Essential or Voluntary,
		    unless otherwise specified in the description of the specific claim.
		  </t>

		  <t hangText="value">
		    <vspace/>
		    OPTIONAL.
		    Requests that the Claim be returned with a particular value.
		    For instance, the Claim request:

		    <figure>
		      <artwork><![CDATA[
  "sub": {"value": "248289761001"}
]]></artwork>
		    </figure>

		    can be used to specify that the request apply to the End-User
		    with Subject Identifier <spanx style="verb">248289761001</spanx>.
		  </t>
		  <t>
		    The value of the <spanx style="verb">value</spanx> member
		    MUST be a valid value for the Claim being requested.
		    Definitions of individual Claims can include requirements on
		    how and whether the <spanx style="verb">value</spanx>
		    qualifier is to be used when requesting that Claim.
		  </t>
		  <t hangText="values">
		    <vspace/>
		    OPTIONAL.
		    Requests that the Claim be returned with one of a set of values,
		    with the values appearing in order of preference.
		    For instance, the Claim request:

		    <figure>
		      <artwork><![CDATA[
  "acr": {"essential": true,
          "values": ["urn:mace:incommon:iap:silver",
                     "urn:mace:incommon:iap:bronze"]}
]]></artwork>
		    </figure>

		    specifies that it is Essential that the <spanx style="verb">acr</spanx>
		    Claim be returned with either the value
		    <spanx style="verb">urn:mace:incommon:iap:silver</spanx> or
		    <spanx style="verb">urn:mace:incommon:iap:bronze</spanx>.
		  </t>
		  <t>
		    The values in the <spanx style="verb">values</spanx> member array
		    MUST be valid values for the Claim being requested.
		    Definitions of individual Claims can include requirements on
		    how and whether the <spanx style="verb">values</spanx>
		    qualifier is to be used when requesting that Claim.
		  </t>
		</list>
	      </t>
	      <t>
		Other members MAY be defined to provide additional 
		information about the requested Claims.
		Any members used that are not understood MUST be ignored.
	      </t>
	    </list>
	  </t>
	  <t>
	    Note that when the <spanx style="verb">claims</spanx> request parameter
	    is supported, the scope values that request Claims, as defined in
	    <xref target="ScopeClaims"/>, are effectively shorthand methods for
	    requesting sets of individual Claims.
	    For example, using the scope value <spanx style="verb">openid email</spanx>
	    and a <spanx style="verb">response_type</spanx> that returns an Access Token
	    is equivalent to using the scope value <spanx style="verb">openid</spanx>
	    and the following request for individual Claims.

	    <figure>
	      <preamble>
		Equivalent of using the <spanx style="verb">email</spanx> scope value:
	      </preamble>

	      <artwork><![CDATA[
  {
   "userinfo":
    {
     "email": null,
     "email_verified": null
    }
  }
]]></artwork>
	    </figure>
	  </t>

	  <section anchor="acrSemantics" title='Requesting the "acr" Claim'>

	    <t>
	      If the <spanx style="verb">acr</spanx> Claim is requested
	      as an Essential Claim for the ID Token
	      with a <spanx style="verb">values</spanx> parameter requesting
	      specific Authentication Context Class Reference values and
	      the implementation supports the <spanx style="verb">claims</spanx> parameter,
	      the Authorization Server MUST return an <spanx style="verb">acr</spanx>
	      Claim Value that matches one of the requested values.
	      The Authorization Server MAY ask the End-User to re-authenticate
	      with additional factors
	      to meet this requirement. If this is an Essential Claim and the
	      requirement cannot be met, then the Authorization Server MUST
	      treat that outcome as a failed authentication attempt.
	    </t>
	    <t>
	      Note that the RP MAY request the <spanx style="verb">acr</spanx>
	      Claim as a Voluntary Claim
	      by using the <spanx style="verb">acr_values</spanx> request parameter
	      or by not including "essential": true in an individual
	      <spanx style="verb">acr</spanx> Claim request.
	      If the Claim is not Essential and a requested value
	      cannot be provided, the Authorization Server SHOULD return
	      the session's current <spanx style="verb">acr</spanx> as
	      the value of the <spanx style="verb">acr</spanx> Claim.
	      If the Claim is not Essential, the Authorization Server is not required to
	      provide this Claim in its response.
	    </t>
	    <t>
	      If the client requests the <spanx style="verb">acr</spanx> Claim using
	      both the <spanx style="verb">acr_values</spanx> request parameter and
	      an individual <spanx style="verb">acr</spanx> Claim request for the ID Token
	      listing specific requested values,
	      the resulting behavior is unspecified.
	    </t>
	  </section>

	</section>

	<section anchor="IndividualClaimsLanguages" title="Languages and Scripts for Individual Claims">
	  <t>
	    As described in <xref target="ClaimsLanguagesAndScripts"/>,
	    human-readable Claim Values and Claim Values that reference human-readable values
	    MAY be represented in multiple languages and scripts.
	    Within a request for individual Claims, requested languages and scripts
	    for particular Claims MAY be requested by including Claim Names
	    that contain <spanx style="verb">#</spanx>-separated
	    <xref target="RFC5646">BCP47</xref> language tags
	    in the Claims request, using the Claim Name syntax specified in
	    <xref target="ClaimsLanguagesAndScripts"/>.
	    For example, a Family Name in Katakana in Japanese
	    can be requested using the Claim Name
	    <spanx style="verb">family_name#ja-Kana-JP</spanx>
	    and a Kanji representation of the Family Name in Japanese
	    can be requested using the Claim Name
	    <spanx style="verb">family_name#ja-Hani-JP</spanx>.
	    A German-language Web site can be requested with the Claim Name
	    <spanx style="verb">website#de</spanx>.
	  </t>
	  <t>
	    If an OP receives a request for human-readable Claims in a language and script
	    that it does not have, any versions of those Claims returned that do not use
	    the requested language and script SHOULD use a language tag in the Claim Name.
	  </t>
	</section>

      </section>

      <section anchor="ClaimTypes" title="Claim Types">
	<t>
	  Three representations of Claim Values are defined by this specification:
	</t>
	<t>
	  <list style="hanging">
	    <t hangText="Normal Claims">
	      <vspace/>
	      Claims that are directly asserted by
	      the OpenID Provider.
	    </t>

	    <t hangText="Aggregated Claims">
	      <vspace/>
	      Claims that are asserted by a
	      Claims Provider other than the OpenID Provider but are returned
	      by OpenID Provider.
	    </t>

	    <t hangText="Distributed Claims">
	      <vspace/>
	      Claims that are asserted by a
	      Claims Provider other than the OpenID Provider but are returned
	      as references by the OpenID Provider.
	    </t>
	  </list>
	</t>
	<t>
	  Normal Claims MUST be supported.
	  Support for Aggregated Claims and Distributed Claims is OPTIONAL.
	</t>

	<section anchor="NormalClaims" title="Normal Claims">

	  <t>Normal Claims are represented as members in a JSON object. The
	  Claim Name is the member name and the Claim Value is the member
	  value.</t>

	  <t>The following is a non-normative response containing Normal Claims:</t>

	  <figure>
	    <artwork><![CDATA[
  {
   "sub": "248289761001",
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "email": "janedoe@example.com",
   "picture": "http://example.com/janedoe/me.jpg"
  }
]]></artwork>
	  </figure>

	</section>

	<section anchor="AggregatedDistributedClaims" title="Aggregated and Distributed Claims">
	  <t>Aggregated and distributed Claims are represented by
	  using special <spanx style="verb">_claim_names</spanx> and
	  <spanx style="verb">_claim_sources</spanx> members
	  of the JSON object containing the Claims.</t>

	  <t>
	    <list style="hanging">
	      <t hangText="_claim_names">
		<vspace/>
		JSON object whose member
		names are the Claim Names for the Aggregated and Distributed
		Claims. The member values are references to the member names
		in the <spanx style="verb">_claim_sources</spanx> member from which
		the actual Claim Values can be retrieved.
	      </t>

	      <t hangText="_claim_sources">
		<vspace/>
		JSON object whose
		member names are referenced by the member values of the
		<spanx style="verb">_claim_names</spanx> member. The member values
		contain sets of Aggregated Claims or reference locations for
		Distributed Claims. The member values can have one of the
		following formats depending on whether it is providing
		Aggregated or Distributed Claims:

		<list style="hanging">

		  <t hangText="Aggregated Claims">
		    <vspace/>
		    JSON object that MUST
		    contain the <spanx style="verb">JWT</spanx> member whose value is a <xref
		    target="JWT">JWT</xref> that MUST contain all the Claims
		    in the <spanx style="verb">_claim_names</spanx> object that references the
		    corresponding <spanx style="verb">_claim_sources</spanx> member.
		    Other members MAY be present.
		    Any members used that are not understood MUST be ignored.

		    <list style="hanging">
		      <t hangText="JWT">
			<vspace/>
			REQUIRED.
			JWT containing Claim Values.
		      </t>
		    </list>
		  </t>
		  <t>
		    The JWT SHOULD NOT contain a <spanx style="verb">sub</spanx> (subject)
		    Claim unless its value is an identifier for the End-User at
		    the Claims Provider (and not for the OpenID Provider or another party);
		    this typically means that a <spanx style="verb">sub</spanx> Claim
		    SHOULD NOT be provided.
		  </t>

		  <t hangText="Distributed Claims">
		    <vspace/>
		    JSON object that
		    contains the following members and values:

		    <list style="hanging">
		      <t hangText="endpoint">
			<vspace/>
			REQUIRED.
			OAuth 2.0 resource endpoint from which the associated
			Claim can be retrieved. The endpoint URL MUST return
			the Claim as a JWT.
		      </t>

		      <t hangText="access_token">
			<vspace/>
			OPTIONAL.
			Access Token
			enabling retrieval of the Claims from the endpoint URL
			by using the <xref target="RFC6750">OAuth 2.0 Bearer Token Usage</xref>
			protocol. Claims SHOULD be requested using
			the Authorization Request header field and Claims Providers
			MUST support this method. If the Access Token
			is not available, RPs MAY need to retrieve the
			Access Token out of band or use an Access Token
			that was pre-negotiated between the Claims Provider and
			RP, or the Claims Provider MAY reauthenticate the
			End-User and/or reauthorize the RP.
		      </t>
		    </list>
		  </t>
		  <t>
		    A <spanx style="verb">sub</spanx> (subject) Claim SHOULD NOT
		    be returned from the Claims Provider
		    unless its value is an identifier for the End-User at
		    the Claims Provider (and not for the OpenID Provider or another party);
		    this typically means that a <spanx style="verb">sub</spanx> Claim
		    SHOULD NOT be provided.
		  </t>
		</list>
	      </t>
	    </list>
	  </t>
	  <t>
	    In general, it is up to the OP when it is appropriate to use
	    Aggregated Claims and Distributed Claims.
	    In some cases, information about when to use what Claim Types
	    might be negotiated out of band between RPs and OPs.
	  </t>

	  <section anchor="AggregatedExample" title="Example of Aggregated Claims">

	    <t>
	      In this non-normative example, Claims from Claims Provider A
	      are combined with other Claims held by the OpenID provider, with the
	      Claims from Claims Provider A being returned as Aggregated Claims.
	    </t>
	    <t>
	      <figure>
		<preamble>
		  In this example, these Claims about Jane Doe have been issued by
		  Claims Provider A:
		</preamble>
		<artwork><![CDATA[
  {
   "address": {
     "street_address": "1234 Hollywood Blvd.",
     "locality": "Los Angeles",
     "region": "CA",
     "postal_code": "90210",
     "country": "United States of America"},
   "phone_number": "+1 (310) 123-4567"
  }
]]></artwork>
	      </figure>
	    </t>

	    <t>
	      Claims Provider A signs the JSON Claims, representing them in a signed JWT:
	      jwt_header.jwt_part2.jwt_part3.
	      It is this JWT that is used by the OpenID Provider.
	    </t>
	    <t>
	      <figure>
		<preamble>
		  In this example, this JWT containing Jane Doe's Aggregated Claims
		  from Claims Provider A is combined with other Normal Claims,
		  and returned as the following set of Claims:
		</preamble>
		<artwork><![CDATA[
  {
   "sub": "248289761001",
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "birthdate": "0000-03-22",
   "eye_color": "blue",
   "email": "janedoe@example.com",
   "_claim_names": {
     "address": "src1",
     "phone_number": "src1"
   },
   "_claim_sources": {
     "src1": {"JWT": "jwt_header.jwt_part2.jwt_part3"}
   }
  }
]]></artwork>
	      </figure>
	    </t>

	  </section>

	  <section anchor="DistributedExample" title="Example of Distributed Claims">

	    <t>
	      In this non-normative example, the OpenID Provider combines
	      Normal Claims that it holds with references to Claims held by
	      two different Claims Providers, B and C, incorporating references
	      to some of the Claims held by B and C as Distributed Claims.
	    </t>
	    <t>
	      <figure>
		<preamble>
		  In this example, these Claims about Jane Doe are held by
		  Claims Provider B (Jane Doe's bank):
		</preamble>
		<artwork><![CDATA[
  {
   "shipping_address": {
     "street_address": "1234 Hollywood Blvd.",
     "locality": "Los Angeles",
     "region": "CA",
     "postal_code": "90210",
     "country": "United States of America"},
   "payment_info": "Some_Card 1234 5678 9012 3456",
   "phone_number": "+1 (310) 123-4567"
  }
]]></artwork>
	      </figure>
	    </t>

	    <t>
	      <figure>
		<preamble>
		  Also in this example, this Claim about Jane Doe is held by
		  Claims Provider C (a credit agency):
		</preamble>
		<artwork><![CDATA[
  {
   "credit_score": 650
  }
]]></artwork>
	      </figure>
	    </t>

	    <t>
	      <figure>
		<preamble>
		  The OpenID Provider returns Jane Doe's Claims along with references
		  to the Distributed Claims from Claims Provider B and Claims Provider C
		  by sending the Access Tokens and URLs of locations from which the	
		  Distributed Claims can be retrieved:
		</preamble>
		<artwork><![CDATA[
  {
   "sub": "248289761001",
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "email": "janedoe@example.com",
   "birthdate": "0000-03-22",
   "eye_color": "blue",
   "_claim_names": {
     "payment_info": "src1",
     "shipping_address": "src1",
     "credit_score": "src2"
    },
   "_claim_sources": {
     "src1": {"endpoint":
                "https://bank.example.com/claim_source"},
     "src2": {"endpoint":
                "https://creditagency.example.com/claims_here",
              "access_token": "ksj3n283dke"}
   }
  }
]]></artwork>
	      </figure>
	    </t>
	  </section>

	</section>
      </section>

      <section anchor="ClaimStability" title="Claim Stability and Uniqueness">

	<t>
	  The <spanx style="verb">sub</spanx> (subject) and
	  <spanx style="verb">iss</spanx> (issuer) Claims, used together,
	  are the only Claims that an RP
	  can rely upon as a stable identifier for the End-User,
	  since the <spanx style="verb">sub</spanx>
	  Claim MUST be locally unique and never reassigned within the Issuer
	  for a particular End-User, as described in <xref target="IDToken"></xref>.
	  Therefore, the only guaranteed unique identifier for a given End-User is the
	  combination of the <spanx style="verb">iss</spanx> Claim
	  and the <spanx style="verb">sub</spanx> Claim.
	</t>
	<t>
	  All other Claims carry no such guarantees across different issuers in terms of
	  stability over time or uniqueness across users, and Issuers are permitted to
	  apply local restrictions and policies. For instance, an Issuer MAY re-use an
	  <spanx style="verb">email</spanx> Claim Value across different
	  End-Users at different points in time, and the claimed 
	  <spanx style="verb">email</spanx> address for a given End-User MAY change 
	  over time.
	  Therefore, other Claims such as <spanx style="verb">email</spanx>,
	  <spanx style="verb">phone_number</spanx>, and
	  <spanx style="verb">preferred_username</spanx>
	  and MUST NOT be used as unique identifiers for the End-User.
	</t>

      </section>

    </section>

    <section anchor="JWTRequests" title="Passing Request Parameters as JWTs">

      <t>
	OpenID Connect defines the following Authorization Request parameters
	to enable Authentication Requests to be signed and optionally encrypted:

	<list style="hanging">
	  <t hangText="request">
	    <vspace/>
	    OPTIONAL.
	    This parameter enables
	    OpenID Connect requests to be passed in a single,
	    self-contained parameter and to be optionally signed and/or encrypted.
	    The parameter value is a Request Object value,
	    as specified in <xref target="RequestObject"/>.
	    It represents the request as a JWT whose Claims
	    are the request parameters.
	  </t>
	  <t hangText="request_uri">
	    <vspace/>
	    OPTIONAL.
	    This parameter enables
	    OpenID Connect requests to be passed by reference, rather than by value.
	    The <spanx style="verb">request_uri</spanx> value is a URL
	    referencing a resource containing a Request Object value,
	    which is a JWT containing the request parameters.
	    This URL MUST use the <spanx style="verb">https</spanx> scheme
	    unless the target Request Object is signed in a way that is verifiable by the OP.
	  </t>
	</list>
      </t>
      <t>
	Requests using these parameters are represented as JWTs, which are respectively
	passed by value or by reference.
	The ability to pass requests by reference is particularly useful for large requests.
	If one of these parameters is used,
	the other MUST NOT be used in the same request.
      </t>

      <section title="Passing a Request Object by Value" anchor="RequestObject">

	<t>
	  The <spanx style="verb">request</spanx> Authorization Request parameter
	  enables OpenID Connect requests to be passed in a single,
	  self-contained parameter and to be optionally signed and/or encrypted.
	  It represents the request as a JWT whose Claims are the request parameters
	  specified in <xref target="AuthorizationEndpoint"/>.
	  This JWT is called a Request Object.
	</t>
	<t>
	  Support for the <spanx style="verb">request</spanx> parameter is OPTIONAL.
	  The <spanx style="verb">request_parameter_supported</spanx>
	  Discovery result indicates whether the OP supports this parameter.
	  Should an OP not support this parameter and an RP uses it,
	  the OP MUST return the <spanx style="verb">request_not_supported</spanx>
	  error.
	</t>
	<t>
	  When the <spanx style="verb">request</spanx> parameter is used,
	  the OpenID Connect request parameter values contained in the JWT
	  supersede those passed using the OAuth 2.0 request syntax.
	  However, parameters MAY also be passed using the OAuth 2.0 request syntax
	  even when a Request Object is used;
	  this would typically be done to enable a cached,
	  pre-signed (and possibly pre-encrypted) Request Object value
	  to be used containing the fixed request parameters, while parameters that
	  can vary with each request, such as <spanx style="verb">state</spanx> and
	  <spanx style="verb">nonce</spanx>, are passed as OAuth 2.0 parameters.
	</t>
	<t>
	  So that the request is a valid OAuth 2.0 Authorization Request,
	  values for the <spanx style="verb">response_type</spanx> and
	  <spanx style="verb">client_id</spanx> parameters MUST be included
	  using the OAuth 2.0 request syntax, since they are REQUIRED by OAuth 2.0.
	  The values for these parameters MUST match those in the Request Object,
	  if present.
	</t>
	<t>
	  Even if a <spanx style="verb">scope</spanx> parameter
	  is present in the Request Object value,
	  a <spanx style="verb">scope</spanx> parameter MUST always be passed using
	  the OAuth 2.0 request syntax containing the
	  <spanx style="verb">openid</spanx> scope value to indicate to the
	  underlying OAuth 2.0 logic that this is an OpenID Connect request.
	</t>
	<t>
	  The Request Object MAY be signed or unsigned (unsecured).
	  When it is unsecured, this is indicated by use of the
	  <spanx style="verb">none</spanx> algorithm <xref target="JWA" />
	  in the JOSE Header.  If signed, the Request Object
	  SHOULD contain the Claims
	  <spanx style="verb">iss</spanx> (issuer)
	  and <spanx style="verb">aud</spanx> (audience) as members.
	  The <spanx style="verb">iss</spanx> value SHOULD be the Client ID of the RP,
	  unless it was signed by a different party than the RP.
	  The <spanx style="verb">aud</spanx> value SHOULD be or include
	  the OP's Issuer Identifier URL.
	</t>
	<t>
	  The Request Object MAY also be encrypted using <xref target="JWE">JWE</xref>
	  and MAY be encrypted without also being signed.
	  If both signing and encryption are performed, it MUST be signed then encrypted,
	  with the result being a Nested JWT, as defined in <xref target="JWT"/>.
	</t>
	<t>
	  <spanx style="verb">request</spanx> and
	  <spanx style="verb">request_uri</spanx> parameters
	  MUST NOT be included in Request Objects.
	</t>

	<t>
	  <figure>
	    <preamble>
	      The following is a non-normative example of the Claims in
	      a Request Object before base64url-encoding and signing:
	    </preamble>

	    <artwork><![CDATA[
  {
   "iss": "s6BhdRkqt3",
   "aud": "https://server.example.com",
   "response_type": "code id_token",
   "client_id": "s6BhdRkqt3",
   "redirect_uri": "https://client.example.org/cb",
   "scope": "openid",
   "state": "af0ifjsldkj",
   "nonce": "n-0S6_WzA2Mj",
   "max_age": 86400,
   "claims": 
    {
     "userinfo": 
      {
       "given_name": {"essential": true},
       "nickname": null,
       "email": {"essential": true},
       "email_verified": {"essential": true},
       "picture": null
      },
     "id_token": 
      {
       "gender": null,
       "birthdate": {"essential": true},
       "acr": {"values": ["urn:mace:incommon:iap:silver"]}
      }
    }
  }
]]></artwork>
	  </figure>
	  <figure>
	    <preamble>
	      Signing it with the <spanx style="verb">RS256</spanx> algorithm
	      results in this Request Object value
	      (with line wraps within values for display purposes only):
	    </preamble>

	    <artwork><![CDATA[
  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
  F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
  c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
  JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
  bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
  Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
  ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
  ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
  Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
  wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
  ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
  sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
  dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
  luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
  F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
  KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
  0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
  ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
  iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
]]></artwork>
	  </figure>
	  <figure>
	    <preamble>
	      The following RSA public key, represented in JWK format, can be used to
	      validate the Request Object signature in this
	      and subsequent Request Object examples
	      (with line wraps within values for display purposes only):
	    </preamble>

	    <artwork><![CDATA[
  {
   "kty":"RSA",
   "kid":"k2bdc",
   "n":"y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAtKlE5P
        7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5OaaXDF
        I6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVjdEFgZa
        ZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghLL0HzOuYR
        adBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUGsqkNA9b3xV
        W53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw",
   "e":"AQAB"
  }
]]></artwork>
	  </figure>
<!-- The private key is archived here, but is not included in the specification output.
	  <figure>
	    <preamble>
	      The following is the RSA private key, represented in JWK format,
	      that was used to sign the Request Object in this
	      and subsequent Request Object examples
	      (with line wraps within values for display purposes only):
	    </preamble>

	    <artwork><![CDATA[
  {
   "kty": "RSA",
   "kid":"k2bdc",
   "n": "y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAtKlE
         5P7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5Oa
         aXDFI6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVj
         dEFgZaZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghL
         L0HzOuYRadBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUG
         sqkNA9b3xVW53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw",
   "e": "AQAB",
   "d": "LNwG_pCKrwowALpCpRdcOKlSVqylSurZhE6CpkRiE9cpDgGKIkO9CxPlXOL
         zjqxXuQc8MdMqRQZTnAwgd7HH0B6gncrruV3NewI-XQV0ckldTjqNfOTz1V
         Rs-jE-57KAXI3YBIhu-_0YpIDzdk_wBuAk661Svn0GsPQe7m9DoxdzenQu9
         O_soewUhlPzRrTH0EeIqYI715rwI3TYaSzoWBmEPD2fICyj18FF0MPy_SQz
         k3noVUUIzfzLnnJiWy_p63QBCMqjRoSHHdMnI4z9iVpIwJWQ3jO5n_2lC2-
         cSgwjmKsFzDBbQNJc7qMG1N6EssJUwgGJxz1eAUFf0w4YAQ",
   "qi": "J-mG0swR4FTy3atrcQ7dd0hhYn1E9QndN-
         -sDG4EQO0RnFj6wIefCvwIc4
         7hCtVeFnCTPYJNc_JyV-mU-9vlzS5GSNuyR5qdpsMZXUMpEvQcwKt23ffPZ
         YGaqfKyEesmf_Wi8fFcE68H9REQjnniKrXm7w2-IuG_IrVJA9Ox-uU",
   "q": "4hlMYAGa0dvogdK1jnxQ7J_Lqpqi99e-AeoFvoYpMPhthChTzwFZO9lQmUo
         BpMqVQTws_s7vWGmt7ZAB3ywkurf0pV7BD0fweJiUzrWk4KJjxtmP_auuxr
         jvm3s2FUGn6f0wRY9Z8Hj9A7C72DnYCjuZiJQMYCWDsZ8-d-L1a-s",
   "p": "5sd9Er3I2FFT9R-gy84_oakEyCmgw036B_nfYEEOCwpSvi2z7UcIVK3bSEL
         5WCW6BNgB3HDWhq8aYPirwQnqm0K9mX1E-4xM10WWZ-rP3XjYpQeS0Snru5
         LFVWsAzi-FX7BOqBibSAXLdEGXcXa44l08iec_bPD3xduq5V_1YoE",
   "dq": "Nz2PF3XM6bEc4XsluKZO70ErdYdKgdtIJReUR7Rno_tOZpejwlPGBYVW19
         zpAeYtCT82jxroB2XqhLxGeMxEPQpsz2qTKLSe4BgHY2ml2uxSDGdjcsrbb
         NoKUKaN1CuyZszhWl1n0AT_bENl4bJgQj_Fh0UEsQj5YBBUJt5gr_k",
   "dp": "Zc877jirkkLOtyTs2vxyNe9KnMNAmOidlUc2tE_-0gAL4Lpo1hSwKCtKwe
         ZJ-gkqt1hT-dwNx_0Xtg_-NXsadMRMwJnzBMYwYAfjApUkfqABc0yUCJJl3
         KozRCugf1WXkU9GZAH2_x8PUopdNUEa70ISowPRh04HANKX4fkjWAE"
  }
]]></artwork>
	  </figure>
-->
	</t>

	<section anchor="RequestParameter"
		 title='Request using the "request" Request Parameter'>
	  <t>The Client sends the Authorization Request to the
	  Authorization Endpoint.</t>

	  <t>
	    <figure>
	      <preamble>The following is a non-normative example of an
	      Authorization Request using the <spanx style='verb'>request</spanx>
	      parameter
	      (with line wraps within values for display purposes only):
	      </preamble>

	      <artwork><![CDATA[
  https://server.example.com/authorize?
    response_type=code%20id_token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj
    &request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiA
    iczZCaGRSa3F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmN
    vbSIsDQogInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWV
    udF9pZCI6ICJzNkJoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8
    vY2xpZW50LmV4YW1wbGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiA
    ic3RhdGUiOiAiYWYwaWZqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWo
    iLA0KICJtYXhfYWdlIjogODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXN
    lcmluZm8iOiANCiAgICB7DQogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWw
    iOiB0cnVlfSwNCiAgICAgIm5pY2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjo
    geyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJ
    lc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgInBpY3R1cmUiOiBudWxsDQogICAgfSw
    NCiAgICJpZF90b2tlbiI6IA0KICAgIHsNCiAgICAgImdlbmRlciI6IG51bGwsDQo
    gICAgICJiaXJ0aGRhdGUiOiB7ImVzc2VudGlhbCI6IHRydWV9LA0KICAgICAiYWN
    yIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOmluY29tbW9uOmlhcDpzaWx2ZXIiXX0
    NCiAgICB9DQogIH0NCn0.nwwnNsk1-ZkbmnvsF6zTHm8CHERFMGQPhos-EJcaH4H
    h-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyFKzuMXZFSZ3p6Mb8dkxtVyjoy2
    GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx0GxFbuPbj96tVuj11pTnmFC
    UR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8Kol-cSLWoYE9l5QqholImz
    jT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPGiyon_-Te111V8uE83Il
    zCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
]]></artwork>
	    </figure>
	  </t>
	</section>
      </section>

      <section anchor="RequestUriParameter" title="Passing a Request Object by Reference">
	<t>
	  The <spanx style="verb">request_uri</spanx> Authorization Request parameter enables
	  OpenID Connect requests to be passed by reference, rather than by value.
	  This parameter is used identically to the
	  <spanx style="verb">request</spanx> parameter, other than that
	  the Request Object value is retrieved from the resource at the specified URL,
	  rather than passed by value.
	</t>
	<t>
	  The <spanx style="verb">request_uri_parameter_supported</spanx>
	  Discovery result indicates whether the OP supports this parameter.
	  Should an OP not support this parameter and an RP uses it,
	  the OP MUST return the <spanx style="verb">request_uri_not_supported</spanx>
	  error.
	</t>
	<t>
	  When the <spanx style="verb">request_uri</spanx> parameter is used,
	  the OpenID Connect request parameter values contained in the referenced JWT
	  supersede those passed using the OAuth 2.0 request syntax.
	  However, parameters MAY also be passed using the OAuth 2.0 request syntax
	  even when a <spanx style="verb">request_uri</spanx> is used;
	  this would typically be done to enable a cached,
	  pre-signed (and possibly pre-encrypted) Request Object value
	  to be used containing the fixed request parameters, while parameters that
	  can vary with each request, such as <spanx style="verb">state</spanx> and
	  <spanx style="verb">nonce</spanx>, are passed as OAuth 2.0 parameters.
	</t>
	<t>
	  So that the request is a valid OAuth 2.0 Authorization Request,
	  values for the <spanx style="verb">response_type</spanx> and
	  <spanx style="verb">client_id</spanx> parameters MUST be included
	  using the OAuth 2.0 request syntax, since they are REQUIRED by OAuth 2.0.
	  The values for these parameters MUST match those in the Request Object,
	  if present.
	</t>
	<t>
	  Even if a <spanx style="verb">scope</spanx> parameter
	  is present in the referenced Request Object,
	  a <spanx style="verb">scope</spanx> parameter MUST always be passed using
	  the OAuth 2.0 request syntax containing the
	  <spanx style="verb">openid</spanx> scope value to indicate to the
	  underlying OAuth 2.0 logic that this is an OpenID Connect request.
	</t>
	<t>
	  Servers MAY cache the contents of the resources referenced by Request URIs.
	  If the contents of the referenced resource could ever change,
	  the URI SHOULD include the base64url-encoded SHA-256 hash of the
	  referenced resource contents as the fragment component of the URI.
	  If the fragment value used for a URI changes, that signals the server
	  that any cached value for that URI with the old fragment value
	  is no longer valid.
	</t>
	<t>
	  Note that Clients MAY pre-register
	  <spanx style="verb">request_uri</spanx> values using the
	  <spanx style="verb">request_uris</spanx> parameter defined in
	  Section 2.1 of the
	  <xref target="OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</xref>
	  specification.
	  OPs can require that <spanx style="verb">request_uri</spanx> values used
	  be pre-registered with the <spanx style="verb">require_request_uri_registration</spanx>
	  discovery parameter.
	</t>
	<t>
	  The entire Request URI SHOULD NOT exceed 512 ASCII characters.
	</t>
	<t>
	  The contents of the resource referenced by the URL MUST be a Request Object.
	  The scheme used in the 
	  <spanx style="verb">request_uri</spanx> value MUST be <spanx style="verb">https</spanx>, 
	  unless the target Request Object is signed in a way that is verifiable by the 
	  Authorization Server.
	  The <spanx style="verb">request_uri</spanx> value MUST be reachable by the
	  Authorization Server and SHOULD be reachable by the Client.
	</t>

	<t>
	  <figure>
	    <preamble>The following is a non-normative example of
	    the contents of a Request Object resource that can be
	    referenced by a <spanx style="verb">request_uri</spanx>
	    (with line wraps within values for display purposes only):</preamble>

	    <artwork><![CDATA[
  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
  F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
  c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
  JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
  bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
  Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
  ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
  ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
  Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
  wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
  ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
  sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
  dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
  luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
  F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
  KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
  0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
  ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
  iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
  ]]></artwork>
	  </figure>
	</t>

	<section anchor="CreateRequestUri"
		 title="URL Referencing the Request Object">
	  <t>
	    The Client stores the Request Object resource either
	    locally or remotely at a URL the Server can access.
	    This URL is the Request URI, <spanx style="verb">request_uri</spanx>.
	  </t>
	  <t>
	    If the Request Object includes requested values for Claims,
	    it MUST NOT be revealed to anybody but the Authorization Server.
	    As such, the <spanx style="verb">request_uri</spanx> MUST have
	    appropriate entropy for its lifetime.
	    It is RECOMMENDED that it be removed
	    if it is known that it will not be used again
	    or after a reasonable timeout
	    unless access control measures are taken.
	  </t>
	  <figure>
	    <preamble>The following is a non-normative example
	    of a Request URI value
	    (with line wraps within values for display purposes only):</preamble>

	    <artwork><![CDATA[
  https://client.example.org/request.jwt#
    GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
]]></artwork>
	  </figure>

	</section>

	<section anchor="UseRequestUri"
		 title='Request using the "request_uri" Request Parameter'>
	  <t>The Client sends the Authorization Request to the
	  Authorization Endpoint.</t>

	  <figure>
	    <preamble>The following is a non-normative example
	    of an Authorization Request using the <spanx style="verb">request_uri</spanx> parameter
	    (with line wraps within values for display purposes only):</preamble>

	    <artwork><![CDATA[
  https://server.example.com/authorize?
    response_type=code%20id_token
    &client_id=s6BhdRkqt3
    &request_uri=https%3A%2F%2Fclient.example.org%2Frequest.jwt
    %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
    &state=af0ifjsldkj&nonce=n-0S6_WzA2Mj
    &scope=openid
]]></artwork>
	  </figure>
	</section>

	<section anchor="GetRequestUri" title="Authorization Server Fetches Request Object">
	  <t>Upon receipt of the Request, the Authorization Server MUST
	  send an HTTP <spanx style="verb">GET</spanx> request to the <spanx style="verb">request_uri</spanx>
	  to retrieve the referenced Request Object, unless it is already cached, and parse it
	  to recreate the Authorization Request parameters.</t>

	  <t>Note that the RP SHOULD use a unique URI for each
	  request utilizing distinct parameters, or otherwise
	  prevent the Authorization Server from caching the <spanx style="verb">request_uri</spanx>.
	  </t>

	  <figure>
	    <preamble>The following is a non-normative example of this fetch
	    process:</preamble>

	    <artwork><![CDATA[
  GET /request.jwt HTTP/1.1
  Host: client.example.org
]]></artwork>
	  </figure>
	</section>

	<section anchor="RequestUriRationale" title="&quot;request_uri&quot; Rationale">
	  <t>
	    There are several reasons that one might choose to use the
	    <spanx style="verb">request_uri</spanx> parameter:
	  </t>
	  <t>
	    <list style="numbers">
	      <t>
		The set of request parameters can become large and can exceed browser
		URI size limitations.  Passing the request parameters by reference
		can solve this problem.
	      </t>
	      <t>
		Passing a <spanx style="verb">request_uri</spanx> value, rather than
		a complete request by value, can reduce request latency.
	      </t>
	      <t>
		Most requests for Claims from an RP are constant.
		The <spanx style="verb">request_uri</spanx> is a way of creating
		and sometimes also signing and encrypting a constant set of
		request parameters in advance.
		(The <spanx style="verb">request_uri</spanx> value becomes an "artifact"
		representing a particular fixed set of request parameters.)
	      </t>
	      <t>
		Pre-registering a fixed set of request parameters at Registration time
		enables OPs to cache and pre-validate the request parameters at
		Registration time, meaning they need not be retrieved at request time.
	      </t>
	      <t>
		Pre-registering a fixed set of request parameters at
		Registration time enables OPs to vet the contents of
		the request from consumer protection and other points
		of views, either itself or by utilizing a third party.
	      </t>
	    </list>
	  </t>
	</section>
      </section>

      <section anchor="JWTRequestValidation" title="Validating JWT-Based Requests">

	<t>
	  When the <spanx style="verb">request</spanx> or
	  <spanx style="verb">request_uri</spanx> Authorization Request parameters
	  are used, additional steps must be performed to validate the
	  Authentication Request beyond those specified in
	  Sections <xref target="AuthRequestValidation" format="counter"/>,
	  <xref target="ImplicitValidation" format="counter"/>, or
	  <xref target="HybridValidation" format="counter"/>.
	  These steps are to validate the JWT containing the Request Object
	  and to validate the Request Object itself.

	</t>

	<section anchor="EncryptedRequestObject" title="Encrypted Request Object">

	  <t>
	    If the Authorization Server has advertised JWE encryption algorithms
	    in the <spanx style="verb">request_object_encryption_alg_values_supported</spanx> and
	    <spanx style="verb">request_object_encryption_enc_values_supported</spanx> elements of its 
	    Discovery document <xref target="OpenID.Discovery"/>,
	    or has supplied encryption algorithms by other means,
	    these are used by the Client to encrypt the JWT.
	  </t>

	  <t>
	    The Authorization Server MUST decrypt the JWT in accordance with
	    the <xref target="JWE">JSON Web Encryption</xref> specification.
	    The result MAY be either a signed or unsigned (unsecured) Request Object. 
	    In the former case, signature validation MUST be performed 
	    as defined in <xref target="SignedRequestObject"/>.
	  </t>

	  <t>
	    The Authorization Server MUST return an error if decryption fails.
	  </t>
	</section>

	<section anchor="SignedRequestObject" title="Signed Request Object">

	  <t>
	    To perform Signature Validation, 
	    the <spanx style="verb">alg</spanx> Header Parameter in the JOSE Header MUST match the value
	    of the <spanx style="verb">request_object_signing_alg</spanx> set during
	    Client Registration <xref target="OpenID.Registration"/> or a value that was
	    pre-registered by other means.
	    The signature MUST be validated against the appropriate key
	    for that <spanx style="verb">client_id</spanx>
	    and algorithm.
	  </t>

	  <t>
	    The Authorization Server MUST return an error if signature validation fails.
	  </t>
	</section>

	<section anchor="RequestParameterValidation" title="Request Parameter Assembly and Validation">

	  <t>
	    The Authorization Server MUST assemble
	    the set of Authorization Request parameters to be used
	    from the Request Object value
	    and the OAuth 2.0 Authorization Request parameters
	    (minus the <spanx style="verb">request</spanx> or
	    <spanx style="verb">request_uri</spanx> parameters).
	    If the same parameter exists both in 
	    the Request Object and the OAuth Authorization Request parameters,
	    the parameter in the Request Object is used.
	    Using the assembled set of Authorization Request parameters,
	    the Authorization Server then validates the request
	    the normal manner for the flow being used, as specified in
	    Sections <xref target="AuthRequestValidation" format="counter"/>,
	    <xref target="ImplicitValidation" format="counter"/>, or
	    <xref target="HybridValidation" format="counter"/>.
	  </t>

	</section>
      </section>

    </section>

    <section anchor="SelfIssued" title="Self-Issued OpenID Provider">

      <t>
	OpenID Connect supports Self-Issued OpenID Providers -
	personal, self-hosted OPs that issue self-signed ID Tokens.
	Self-Issued OPs use the special Issuer Identifier
	<spanx style="verb">https://self-issued.me</spanx>.
      </t>
      <t>
	The messages used to communicate with Self-Issued OPs are
	mostly the same as those used to communicate with other OPs.
	Specifications for the few additional parameters used and
	for the values of some parameters in the Self-Issued case
	are defined in this section.
      </t>

      <section anchor="SelfIssuedDiscovery" title="Self-Issued OpenID Provider Discovery">
	<t>
	  If the input identifier for the discovery process
	  contains the domain self-issued.me, dynamic discovery is not performed. 
	  Instead, then the following static configuration values are used:
	</t>
	<t>
	  <figure>
	    <artwork><![CDATA[
  {
   "authorization_endpoint":
     "openid:",
   "issuer":
     "https://self-issued.me",
   "scopes_supported":
     ["openid", "profile", "email", "address", "phone"],
   "response_types_supported":
     ["id_token"],
   "subject_types_supported":
     ["pairwise"],
   "id_token_signing_alg_values_supported":
     ["RS256"],
   "request_object_signing_alg_values_supported":
     ["none", "RS256"]
  }
]]></artwork>
	  </figure>
	</t>
	<t>
	  NOTE:  The OpenID Foundation plans to host the OpenID Provider site
	  <spanx style="verb">https://self-issued.me/</spanx>,
	  including its WebFinger service, so that performing discovery on it
	  returns the above static discovery information, enabling RPs
	  to not need any special processing for discovery of the Self-Issued OP.
	  This site will be hosted on an experimental basis.
	  Production implementations should not take a dependency upon it
	  without a subsequent commitment by the OpenID Foundation
	  to host the site in a manner intended for production use.
	</t>
      </section>

      <section anchor="SelfIssuedRegistration" title="Self-Issued OpenID Provider Registration">
	<t>
	  When using a Self-Issued OP, registration is not required.
	  The Client can proceed without registration as if it had
	  registered with the OP and obtained the following
	  Client Registration Response:
	</t>
	<t>
	  <list style="hanging">
	    <t hangText="client_id">
	      <vspace/>
	      <spanx style="verb">redirect_uri</spanx> value of the Client. 
	    </t>
	    <t hangText="client_secret_expires_at">
	      <vspace/>
	      0
	    </t>
	  </list>
	</t>
	<t>
	  NOTE:  The OpenID Foundation plans to host the (stateless) endpoint
	  <spanx style="verb">https://self-issued.me/registration/1.0/</spanx> 
	  that returns the response above, enabling RPs to not need
	  any special processing for registration with the Self-Issued OP.
	  This site will be hosted on an experimental basis.
	  Production implementations should not take a dependency upon it
	  without a subsequent commitment by the OpenID Foundation
	  to host the site in a manner intended for production use.
	</t>

	<section anchor="RegistrationParameter"
		 title='Providing Information with the "registration" Request Parameter'>

	  <t>
	    OpenID Connect defines the following Authorization Request parameter
	    to enable Clients to provide additional registration information to
	    Self-Issued OpenID Providers:

	    <list style="hanging">

	      <t hangText="registration">
		<vspace/>
		OPTIONAL.
		This parameter is used by the Client to provide information about itself
		to a Self-Issued OP that would normally be provided to an OP during
		Dynamic Client Registration.
		The value is a JSON object containing Client metadata values,
		as defined in Section 2.1 of the 
		<xref target="OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</xref>
		specification.
		The <spanx style="verb">registration</spanx> parameter SHOULD NOT be used
		when the OP is not a Self-Issued OP.
	      </t>
	    </list>
	  </t>
	  <t>
	    None of this information is REQUIRED by Self-Issued OPs,
	    so the use of this parameter is OPTIONAL.
	  </t>
	  <t>
	    The <spanx style="verb">registration</spanx> parameter value is represented
	    in an OAuth 2.0 request as a UTF-8 encoded JSON object
	    (which ends up being form-urlencoded when passed as an OAuth parameter).
	    When used in a Request Object value, per <xref target="RequestObject"/>,
	    the JSON object is used as the value of the
	    <spanx style="verb">registration</spanx> member.
	  </t>
	  <t>
	    The Registration parameters that would typically be used in requests
	    to Self-Issued OPs are
	    <spanx style="verb">policy_uri</spanx>,
	    <spanx style="verb">tos_uri</spanx>, and
	    <spanx style="verb">logo_uri</spanx>.
	    If the Client uses more than one Redirection URI, the
	    <spanx style="verb">redirect_uris</spanx>
	    parameter would be used to register them.
	    Finally, if the Client is requesting encrypted responses, it would typically use the
	    <spanx style="verb">jwks_uri</spanx>,
	    <spanx style="verb">id_token_encrypted_response_alg</spanx> and
	    <spanx style="verb">id_token_encrypted_response_enc</spanx> parameters.
	  </t>
	</section>
      </section>

      <section anchor="SelfIssuedRequest" title="Self-Issued OpenID Provider Request">
	<t>The Client sends the Authentication Request to the Authorization Endpoint
	with the following parameters:</t>
	<t>
	  <list style="hanging">
	    <t hangText="scope">
	      <vspace/>
	      REQUIRED.
	      <spanx style="verb">scope</spanx> parameter value,
	      as specified in <xref target="AuthorizationEndpoint"/>.
	    </t>
	    <t hangText="response_type">
	      <vspace/>
	      REQUIRED. Constant string value <spanx style="verb">id_token</spanx>.
	    </t>
	    <t hangText="client_id">
	      <vspace/>
	      REQUIRED.
	      Client ID value for the Client, which in this case contains the
	      <spanx style="verb">redirect_uri</spanx> value of the Client.
	      Since the Client's
	      <spanx style="verb">redirect_uri</spanx> URI value is communicated
	      as the Client ID,
	      a <spanx style="verb">redirect_uri</spanx> parameter
	      is NOT REQUIRED to also be included in the request.
	    </t>
	    <t hangText="id_token_hint">
	      <vspace/>
	      OPTIONAL.
	      <spanx style="verb">id_token_hint</spanx> parameter value,
	      as specified in <xref target="AuthorizationEndpoint"/>.
	      If the ID Token is encrypted to the Self-Issued OP,
	      the <spanx style="verb">sub</spanx> (subject)
	      of the signed ID Token MUST be sent as the
	      <spanx style="verb">kid</spanx> (key ID) of the JWE.
	      Encrypting content to Self-Issued OPs is currently only supported when
	      the OP's JWK key type is <spanx style="verb">RSA</spanx> and the encryption
	      algorithm used is <spanx style="verb">RSA1_5</spanx>.
	    </t>
	    <t hangText="claims">
	      <vspace/>
	      OPTIONAL.
	      <spanx style="verb">claims</spanx> parameter value,
	      as specified in <xref target="ClaimsParameter"/>.
	    </t>
	    <t hangText="registration">
	      <vspace/>
	      OPTIONAL.
	      This parameter is used by the Client to provide information about itself
	      to a Self-Issued OP that would normally be provided to an OP during
	      Dynamic Client Registration,
	      as specified in <xref target="RegistrationParameter"/>.
	    </t>
	    <t hangText="request">
	      <vspace/>
	      OPTIONAL.
	      Request Object value, as specified in <xref target="RequestObject"/>.
	      The Request Object MAY be encrypted to the Self-Issued OP by the Client.
	      In this case, the <spanx style="verb">sub</spanx> (subject) of
	      a previously issued ID Token for this Client
	      MUST be sent as the <spanx style="verb">kid</spanx> (key ID) of the JWE.
	      Encrypting content to Self-Issued OPs is currently only supported when
	      the OP's JWK key type is <spanx style="verb">RSA</spanx> and the encryption
	      algorithm used is <spanx style="verb">RSA1_5</spanx>.
	    </t>
	  </list>
	</t>
	<t>
	  Other parameters MAY be sent. 
	  Note that all Claims are returned in the ID Token.
	</t>
	<t>The entire URL MUST NOT exceed 2048 ASCII characters.</t>
	<figure>
	  <preamble>
	    The following is a non-normative example
	    HTTP 302 redirect response by the Client, which triggers
	    the User Agent to make an Authentication Request
	    to the Self-Issued OpenID Provider
	    (with line wraps within values for display purposes only):
	  </preamble>
	  <artwork><![CDATA[
  HTTP/1.1 302 Found
  Location: openid://?
    response_type=id_token
    &client_id=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj
    &registration=%7B%22logo_uri%22%3A%22https%3A%2F%2F
      client.example.org%2Flogo.png%22%7D
]]></artwork>
	</figure> 
      </section>

      <section anchor="SelfIssuedResponse" title="Self-Issued OpenID Provider Response">

	<t>
	  OpenID Connect defines the following Claim
	  for use in Self-Issued OpenID Provider Responses:

	  <list style="hanging">

	    <t hangText="sub_jwk">
	      <vspace/>
	      REQUIRED.
	      Public key used to check the signature of an ID Token
	      issued by a Self-Issued OpenID Provider,
	      as specified in <xref target="SelfIssued"/>.
	      The key is a bare key in JWK <xref target="JWK"/> format
	      (not an X.509 certificate value).
	      The <spanx style="verb">sub_jwk</spanx> value is a JSON object.
	      Use of the <spanx style="verb">sub_jwk</spanx> Claim
	      is NOT RECOMMENDED when the OP is not Self-Issued.
	    </t>
	  </list>
	</t>

	<t>
	  The Self-Issued OpenID Provider response is the same as the normal Implicit Flow 
	  response with the following refinements.  Since it is an Implicit Flow
	  response, the response parameters will be returned in the URL fragment component,
	  unless a different Response Mode was specified.
	</t>
	<t>
	  <list style="numbers">
	    <t>
	      The <spanx style="verb">iss</spanx> (issuer) Claim Value is 
	      <spanx style="verb">https://self-issued.me</spanx>.
	    </t>
	    <t>
	      A <spanx style="verb">sub_jwk</spanx> Claim is present, with its value being
	      the public key used to check the signature of the ID Token.
	    </t>
	    <t>
	      The <spanx style="verb">sub</spanx> (subject) Claim
	      value is the base64url-encoded representation of
	      the thumbprint of
	      the key in the <spanx style="verb">sub_jwk</spanx> Claim.
	      This thumbprint value is computed as
	      the SHA-256 hash of
	      the octets of the UTF-8 representation of
	      a JWK constructed containing only the REQUIRED members to represent the key,
	      with the member names sorted into lexicographic order,
	      and with no whitespace or line breaks.
	      For instance,
	      when the <spanx style="verb">kty</spanx> value is
	      <spanx style="verb">RSA</spanx>, the member names
	      <spanx style="verb">e</spanx>,
	      <spanx style="verb">kty</spanx>, and
	      <spanx style="verb">n</spanx>
	      are the ones present in the constructed JWK used
	      in the thumbprint computation and appear in that order;
	      when the <spanx style="verb">kty</spanx> value is
	      <spanx style="verb">EC</spanx>, the member names
	      <spanx style="verb">crv</spanx>,
	      <spanx style="verb">kty</spanx>,
	      <spanx style="verb">x</spanx>, and
	      <spanx style="verb">y</spanx>
	      are present in that order.
	      Note that this thumbprint calculation is the same as that defined in
	      the JWK Thumbprint <xref target="JWK.Thumbprint"/> specification.
	    </t>
	    <t>
	      No Access Token is returned for accessing a UserInfo Endpoint,
	      so all Claims returned MUST be in the ID Token.
	    </t>
	  </list>
	</t>
      </section>

      <section anchor="SelfIssuedValidation" title="Self-Issued ID Token Validation">

	<t>
	  To validate the ID Token received, the Client MUST do the following:
	</t>
	<t>
	  <list style="numbers">
	    <t>
	      The Client MUST validate that the value of the <spanx style="verb">iss</spanx> (issuer) Claim is <spanx style="verb">https://self-issued.me</spanx>.  
	      If <spanx style="verb">iss</spanx> contains a different value, 
	      the ID Token is not Self-Issued, and instead 
	      it MUST be validated according to
	      <xref target="IDTokenValidation"/>.
	    </t>
	    <t>
	      The Client MUST validate that the 
	      <spanx style="verb">aud</spanx> (audience) Claim
	      contains the value of the <spanx style="verb">redirect_uri</spanx>
	      that the Client sent in the Authentication Request as an audience.
	    </t>
	    <t>
	      The Client MUST validate the signature of the ID Token according to
	      <xref target="JWS">JWS</xref> using the algorithm specified in the 
	      <spanx style="verb">alg</spanx> Header Parameter of the JOSE Header,
	      using the key in the <spanx style="verb">sub_jwk</spanx> Claim;
	      the key is a bare key in JWK format
	      (not an X.509 certificate value).
	    </t>
	    <t>
	      The <spanx style="verb">alg</spanx> value SHOULD be the default of 
	      <spanx style="verb">RS256</spanx>.
	      It MAY also be <spanx style="verb">ES256</spanx>.
	    </t>
	    <t>
	      The Client MUST validate that the <spanx style="verb">sub</spanx> Claim
	      value is the base64url-encoded representation of
	      the thumbprint of
	      the key in the <spanx style="verb">sub_jwk</spanx> Claim,
	      as specified in <xref target="SelfIssuedResponse"/>.
	    </t>
	    <t>
	      The current time MUST be before the time represented by the 
	      <spanx style="verb">exp</spanx> Claim
	      (possibly allowing for some small leeway to account for clock skew).
	    </t>
	    <t>
	      The <spanx style="verb">iat</spanx> Claim can be used to reject tokens that 
	      were issued too far away from the current time, limiting the amount of
	      time that nonces need to be stored to prevent attacks. 
	      The acceptable range is Client specific.
	    </t>
	    <t>
	      If a nonce value was sent in the Authentication Request, 
	      a <spanx style="verb">nonce</spanx> Claim MUST be present 
	      and its value checked to verify that
	      it is the same value as the one that was sent in the Authentication Request.
	      The Client SHOULD check the <spanx style="verb">nonce</spanx> value
	      for replay attacks.
	      The precise method for detecting replay attacks is Client specific.
	    </t>
	  </list>
	</t>
	<figure>
	  <preamble>The following is a non-normative example of a base64url-decoded
	  Self-Issued ID Token
	  (with line wraps within values for display purposes only):</preamble>

	  <artwork><![CDATA[
  {
   "iss": "https://self-issued.me",
   "sub": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
   "aud": "https://client.example.org/cb",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "sub_jwk": {
     "kty":"RSA",
     "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
     4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
     tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
     QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
     SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
     w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
     "e":"AQAB" 
    }
  }
]]></artwork>
	</figure>

      </section>
    </section>

    <section anchor="SubjectIDTypes" title="Subject Identifier Types">
      <t>
	A Subject Identifier is a locally unique and never
	reassigned identifier within the Issuer for the End-User, 
	which is intended to be consumed by the Client.
	Two Subject Identifier types are defined by this specification:

	<list style="hanging">
	  <t hangText="public">
	    <vspace/>
	    This provides the same <spanx style="verb">sub</spanx> (subject) value to all Clients.
	    It is the default if the provider has no <spanx style="verb">subject_types_supported</spanx>
	    element in its discovery document.
	  </t>
	  <t hangText="pairwise">
	    <vspace/>
	    This provides a different <spanx style="verb">sub</spanx>
	    value to each Client, so as not to enable Clients to correlate
	    the End-User's activities without permission.
	  </t>
	</list>
      </t>
      <t>
	The OpenID Provider's Discovery document MUST list
	its supported Subject Identifier types in the
	<spanx style="verb">subject_types_supported</spanx> element.
	If there is more than one type listed in the array, the Client MAY elect to
	provide its preferred identifier type using the
	<spanx style="verb">subject_type</spanx> parameter during Registration.
      </t>

      <section anchor="PairwiseAlg" title="Pairwise Identifier Algorithm">

	<t>
	  When pairwise Subject Identifiers are used,
	  the OpenID Provider MUST calculate a unique
	  <spanx style="verb">sub</spanx> (subject) value for each
	  Sector Identifier.  The Subject Identifier value MUST NOT be reversible
	  by any party other than the OpenID Provider.
	</t>

	<t>
	  Providers that use pairwise <spanx style="verb">sub</spanx> values
	  and support
	  <xref target="OpenID.Registration">Dynamic Client Registration</xref>
	  SHOULD use the <spanx style="verb">sector_identifier_uri</spanx> parameter.
	  It provides a way for a group of websites under common administrative 
	  control to have consistent pairwise <spanx style="verb">sub</spanx> 
	  values independent of the individual domain names.
	  It also provides a way for Clients to change 
	  <spanx style="verb">redirect_uri</spanx> domains without having to 
	  reregister all of their users.
	</t>

	<t>If the Client has not provided a value for
	<spanx style="verb">sector_identifier_uri</spanx> in 
	<xref target="OpenID.Registration">Dynamic Client Registration</xref>,
	the Sector Identifier
	used for pairwise identifier calculation is the host component 
	of the registered <spanx style="verb">redirect_uri</spanx>.
	If there are multiple hostnames in the registered
	<spanx style="verb">redirect_uris</spanx>, the Client MUST register a 
	<spanx style="verb">sector_identifier_uri</spanx>.</t>

	<t>When a <spanx style="verb">sector_identifier_uri</spanx>
	is provided, the host component of that URL is used as
	the Sector Identifier for the pairwise identifier calculation.
	The value of the <spanx style="verb">sector_identifier_uri</spanx>
	MUST be a URL using the <spanx style="verb">https</spanx> scheme that points to
	a JSON file containing an array of
	<spanx style="verb">redirect_uri</spanx> values.
	The values of the registered <spanx style="verb">redirect_uris</spanx>
	MUST be included in the elements of the array.
	</t>

	<t>
	  Any algorithm with the following properties
	  can be used by OpenID Providers to
	  calculate pairwise Subject Identifiers:

	  <list style="symbols">
	    <t>
	      The Subject Identifier value MUST NOT be reversible
	      by any party other than the OpenID Provider.
	    </t>
	    <t>
	      Distinct Sector Identifier values MUST result in
	      distinct Subject Identifier values.
	    </t>
	    <t>
	      The algorithm MUST be deterministic.
	    </t>
	  </list>
	</t>
	<t>
	  Three example methods are:

	  <list style="numbers">

	    <t>
	      The Sector Identifier can be concatenated with a local account ID and a salt 
	      value that is kept secret by the Provider. The concatenated string is then 
	      hashed using an appropriate algorithm.
	      <vspace blankLines="1"/>
	      Calculate <spanx style="verb">sub</spanx> = SHA-256 ( sector_identifier || local_account_id || salt ).
	      <vspace blankLines="1"/>
	    </t>

	    <t>
	      The Sector Identifier can be concatenated with a local account ID and a salt 
	      value that is kept secret by the Provider. The concatenated string is then 
	      encrypted using an appropriate algorithm.
	      <vspace blankLines="1"/>
	      Calculate <spanx style="verb">sub</spanx> = AES-128 ( sector_identifier || local_account_id || salt ).
	      <vspace blankLines="1"/>
	    </t>

	    <t>
	      The Issuer creates a Globally Unique Identifier (GUID) for the pair of
	      Sector Identifier and local account ID and stores this value.
	    </t>

	  </list>
	</t>

      </section>
    </section>

    <section anchor="ClientAuthentication" title="Client Authentication">

      <t>
	This section defines a set of Client Authentication methods
	that are used by Clients to authenticate to the Authorization Server
	when using the Token Endpoint.
	During Client Registration, the RP (Client) MAY register a Client Authentication method.
	If no method is registered, the default method is <spanx style="verb">client_secret_basic</spanx>.
      </t>
      <t>These Client Authentication methods are:</t>

      <t>
	<list style="hanging">

	  <t hangText="client_secret_basic">
	    <vspace/> 
	    Clients that have received a <spanx style='verb'>client_secret</spanx> value
	    from the Authorization Server authenticate with the Authorization Server
	    in accordance with Section 2.3.1 of <xref
	    target="RFC6749">OAuth 2.0</xref> using the HTTP Basic authentication scheme.
	  </t>

	  <t hangText="client_secret_post">
	    <vspace/>
	    Clients that have received a <spanx style='verb'>client_secret</spanx> value 
	    from the Authorization Server, authenticate with the Authorization Server
	    in accordance with Section 2.3.1 of <xref
	    target="RFC6749">OAuth 2.0</xref> by including the Client Credentials in the request body.
	  </t>

	  <t hangText="client_secret_jwt">
	    <vspace/> 
	    Clients that have received a <spanx style='verb'>client_secret</spanx> value 
	    from the Authorization Server create a JWT using an
	    HMAC SHA algorithm, such as HMAC SHA-256. 
	    The HMAC (Hash-based Message Authentication Code) is calculated using
	    the octets of the UTF-8 representation of
	    the <spanx style='verb'>client_secret</spanx> as the shared key.
	  </t>
	  <t>
	    The Client authenticates in accordance with <!-- Section 2.2 of --> <xref
	    target="OAuth.JWT">JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants</xref> and 
	    <xref target="OAuth.Assertions">Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants</xref>.
	    The JWT MUST contain the following REQUIRED Claim Values and
	    MAY contain the following OPTIONAL Claim Values:
	  </t>

	  <t>
	    <list style="hanging">
	      <t hangText="iss">
		<vspace/>
		REQUIRED.
		Issuer.
		This MUST contain the <spanx style="verb">client_id</spanx> of the OAuth Client.
	      </t>

	      <t hangText="sub">
		<vspace/>
		REQUIRED.
		Subject.
		This MUST contain the <spanx style="verb">client_id</spanx> of the OAuth Client.
	      </t>

	      <t hangText="aud">
		<vspace/>
		REQUIRED.
		Audience.
		The <spanx style="verb">aud</spanx> (audience) Claim.
		Value that identifies the Authorization Server as an intended audience.
		The Authorization Server MUST verify that it is an intended audience
		for the token.
		The Audience SHOULD be the URL of the
		Authorization Server's Token Endpoint.
	      </t>

	      <t hangText="jti">
		<vspace/>
		REQUIRED.
		JWT ID.
		A unique identifier for the token,
		which can be used to prevent reuse of the token.
		These tokens MUST only be used once,
		unless conditions for reuse were negotiated between the parties;
		any such negotiation is beyond the scope of this specification.
	      </t>

	      <t hangText="exp">
		<vspace/>
		REQUIRED.
		Expiration time on or after which the JWT MUST NOT be
		accepted for processing.
	      </t>

	      <t hangText="iat">
		<vspace/>
		OPTIONAL.
		Time at which the JWT was issued.
	      </t>
	    </list>
	  </t>

	  <t>
	    The JWT MAY contain other Claims.
	    Any Claims used that are not understood MUST be ignored.
	  </t>

	  <t>The authentication token MUST be sent as the value of the
	  <xref target="OAuth.Assertions"/>
	  <spanx style='verb'>client_assertion</spanx> parameter.</t>

	  <t>The value of the
	  <xref target="OAuth.Assertions"/>
	  <spanx style='verb'>client_assertion_type</spanx> parameter
	  MUST be "urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
	  per <xref target="OAuth.JWT"/>.</t>

	  <t hangText="private_key_jwt">
	    <vspace/>
	    Clients that have registered a public key sign a JWT using 
	    that key.
	    The Client authenticates in accordance with <!-- Section 2.2 of --> <xref
	    target="OAuth.JWT">JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants</xref> and 
	    <xref target="OAuth.Assertions">Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants</xref>.
	    The JWT MUST contain the following REQUIRED Claim Values and
	  MAY contain the following OPTIONAL Claim Values:</t>

	  <t>
	    <list style="hanging">
	      <t hangText="iss">
		<vspace/>
		REQUIRED.
		Issuer.
		This MUST contain the <spanx style="verb">client_id</spanx> of the OAuth Client.
	      </t>

	      <t hangText="sub">
		<vspace/>
		REQUIRED.
		Subject.
		This MUST contain the <spanx style="verb">client_id</spanx> of the OAuth Client.
	      </t>

	      <t hangText="aud">
		<vspace/>
		REQUIRED.
		Audience.
		The <spanx style="verb">aud</spanx> (audience) Claim.
		Value that identifies the Authorization Server as an intended audience.
		The Authorization Server MUST verify that it is an intended audience
		for the token.
		The Audience SHOULD be the URL of the
		Authorization Server's Token Endpoint.
	      </t>

	      <t hangText="jti">
		<vspace/>
		REQUIRED.
		JWT ID.
		A unique identifier for the token,
		which can be used to prevent reuse of the token.
		These tokens MUST only be used once,
		unless conditions for reuse were negotiated between the parties;
		any such negotiation is beyond the scope of this specification.
	      </t>

	      <t hangText="exp">
		<vspace/>
		REQUIRED.
		Expiration time on or after which the JWT MUST NOT be
		accepted for processing.
	      </t>

	      <t hangText="iat">
		<vspace/>
		OPTIONAL.
		Time at which the JWT was issued.
	      </t>
	    </list>
	  </t>

	  <t>
	    The JWT MAY contain other Claims.
	    Any Claims used that are not understood MUST be ignored.
	  </t>

	  <t>The authentication token MUST be sent as the value of the
	  <xref target="OAuth.Assertions"/>
	  <spanx style='verb'>client_assertion</spanx> parameter.</t>

	  <t>The value of the
	  <xref target="OAuth.Assertions"/>
	  <spanx style='verb'>client_assertion_type</spanx> parameter
	  MUST be "urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
	  per <xref target="OAuth.JWT"/>.</t>

	  <t>
	    <figure>
	      <preamble>
		For example
		(with line wraps within values for display purposes only):
	      </preamble>
	      <artwork><![CDATA[
  POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded

  grant_type=authorization_code&
    code=i1WsRn1uB1&
    client_id=s6BhdRkqt3&
    client_assertion_type=
    urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
    client_assertion=PHNhbWxwOl ... ZT
]]></artwork>
	    </figure>
	  </t>

	  <t hangText="none">
	    <vspace/>
	    The Client does not authenticate itself at the Token Endpoint,
	    either because it uses only the Implicit Flow (and so does not use the Token Endpoint)
	    or because it is a Public Client with no Client Secret or other authentication mechanism.
	  </t>
	</list>
      </t>

    </section>

    <section anchor="SigEnc" title="Signatures and Encryption">
      <t>
	Depending on the transport through which the messages are sent, the
	integrity of the message might not be guaranteed and the originator of the
	message might not be authenticated. To mitigate these risks,
	ID Token, UserInfo Response, Request Object,
	and Client Authentication JWT values can utilize
	<xref target="JWS">JSON Web Signature (JWS)</xref> to sign their contents.
	To achieve message confidentiality, these values can also use
	<xref target="JWE">JSON Web Encryption (JWE)</xref> to encrypt their contents.
      </t>
      <t>
	When the message is both signed and encrypted, it MUST be
	signed first and then encrypted, per <xref target="SigningOrder"/>,
	with the result being a Nested JWT, as specified in <xref target="JWT"/>.
	Note that all JWE encryption methods perform integrity checking.
      </t>
      <t>
	The OP advertises its supported signing and encryption algorithms
	in its Discovery document,
	or may supply this information by other means.
	The RP declares its required signing and encryption algorithms
	in its Dynamic Registration request,
	or may communicate this information by other means.
      </t>
      <t>
	The OP advertises its public keys
	via its Discovery document,
	or may supply this information by other means.
	The RP declares its public keys
	via its Dynamic Registration request,
	or may communicate this information by other means.
      </t>

      <section anchor="Signing" title="Signing">
	<t>
	  The signing party MUST select a signature algorithm 
	  based on the algorithms supported by the recipient.
	</t>

	<t>
	  <list style="hanging">
	    <t hangText="Asymmetric Signatures">
	      <vspace/>
	      When using RSA or ECDSA Signatures, 
	      the <spanx style="verb">alg</spanx> Header Parameter value
	      of the JOSE Header MUST be set to an appropriate algorithm
	      as defined in <xref target="JWA">JSON Web Algorithms</xref>.
	      The private key used to sign the content MUST be associated with
	      a public key used for signature verification published by the sender
	      in its JWK Set document.
	      If there are multiple keys in the referenced JWK Set document, a
	      <spanx style="verb">kid</spanx> value MUST be provided in the JOSE Header.
	      The key usage of the respective keys MUST support signing.
	    </t>
	    <t hangText="Symmetric Signatures">
	      <vspace/>
	      When using MAC-based signatures,
	      the <spanx style="verb">alg</spanx> Header Parameter value
	      of the JOSE Header MUST be set to a MAC algorithm,
	      as defined in <xref target="JWA">JSON Web Algorithms</xref>. 
	      The MAC key used is
	      the octets of the UTF-8 representation of
	      the <spanx style="verb">client_secret</spanx> value.
	      See <xref target="SymmetricKeyEntropy"/> for a discussion of
	      entropy requirements for <spanx style="verb">client_secret</spanx> values.
	      Symmetric signatures MUST NOT be used by public (non-confidential) Clients
	      because of their inability to keep secrets.
	    </t>
	  </list>
	</t>
	<t>
	  See <xref target="NeedForSignedRequests"/> for Security Considerations
	  about the need for signed requests.
	</t>
	<section anchor="RotateSigKeys" title="Rotation of Asymmetric Signing Keys">
	  <t>Rotation of signing keys can be accomplished with the following approach. The signer publishes
	  its keys in a JWK Set at its <spanx style="verb">jwks_uri</spanx> location
	  and includes the <spanx style="verb">kid</spanx> of the
	  signing key in the JOSE Header of each message
	  to indicate to the verifier which key is to be used to validate the signature. Keys can be rolled over
	  by periodically adding new keys to the JWK Set at the <spanx style="verb">jwks_uri</spanx> location.
	  The signer can begin using a new key at its
	  discretion and signals the change to the verifier using the <spanx style="verb">kid</spanx> value.
	  The verifier knows to go back to the <spanx style="verb">jwks_uri</spanx> location
	  to re-retrieve the keys when it sees an unfamiliar
	  <spanx style="verb">kid</spanx> value. The JWK Set document at the <spanx style="verb">jwks_uri</spanx>
	  SHOULD retain recently decommissioned signing keys for a reasonable period of time to facilitate a
	  smooth transition.
	  </t>
	</section>

      </section>

      <section anchor="Encryption" title="Encryption">
	<t>
	  The encrypting party MUST select an encryption algorithm
	  based on the algorithms supported by the recipient.
	</t>
	<t>
	  <list style="hanging">

	    <t hangText="Asymmetric Encryption: RSA">
	      <vspace/>
	      The public key to which the content was encrypted MUST be
	      a public key used for encryption published by the recipient
	      in its JWK Set document.
	      If there are multiple keys in the referenced JWK Set document, a
	      <spanx style="verb">kid</spanx> value MUST be provided in the JOSE Header.
	      Use the supported RSA encryption algorithm to encrypt a random 
	      Content Encryption Key to be used for encrypting 
	      the signed JWT.
	      The key usage of the respective keys MUST include encryption.
	    </t>
	    <t hangText="Asymmetric Encryption: Elliptic Curve">
	      <vspace/>
	      Create an ephemeral Elliptic Curve public key for the <spanx style="verb">epk</spanx>
	      element of the JOSE Header.
	      The other public key used for the key agreement computation MUST be
	      a public key published by the recipient
	      in its JWK Set document.
	      If there are multiple keys in the referenced JWK Set document, a
	      <spanx style="verb">kid</spanx> value MUST be provided in the JOSE Header.
	      Use the ECDH-ES algorithm to agree upon a
	      Content Encryption Key to be used for encrypting 
	      the signed JWT.
	      The key usage of the respective keys MUST support encryption.
	    </t>
	    <t hangText="Symmetric Encryption">
	      <vspace/>
	      The symmetric encryption key is derived from the
	      <spanx style="verb">client_secret</spanx> value by
	      using the left-most bits of a truncated SHA-2 hash of
	      the octets of the UTF-8 representation of
	      the <spanx style="verb">client_secret</spanx>.
	      For keys of 256 or fewer bits, SHA-256 is used;
	      for keys of 257-384 bits, SHA-384 is used;
	      for keys of 385-512 bits, SHA-512 is used.
	      The hash value MUST be truncated retaining the left-most bits to the appropriate bit length
	      for the AES key wrapping or direct encryption algorithm used,
	      for instance, truncating the SHA-256 hash
	      to 128 bits for <spanx style="verb">A128KW</spanx>.
	      If a symmetric key with greater than 512 bits is needed, a different method
	      of deriving the key from the <spanx style="verb">client_secret</spanx>
	      would have to be defined by an extension.
	      Symmetric encryption MUST NOT be used by public (non-confidential) Clients
	      because of their inability to keep secrets.
	    </t>
	  </list>
	</t>
	<t>
	  See <xref target="NeedForEncryptedRequests"/> for Security Considerations
	  about the need for encrypted requests.
	</t>

	<section anchor="RotateEncKeys" title="Rotation of Asymmetric Encryption Keys">
	  <t>
	    Rotating encryption keys necessarily uses a different process than the one for signing keys because
	    the encrypting party starts the process and thus cannot rely on
	    a change in <spanx style="verb">kid</spanx> as a signal
	    that keys need to change. The encrypting party
	    still uses the <spanx style="verb">kid</spanx> Header Parameter in the JWE
	    to tell the decrypting party which private key to use to decrypt, however, the encrypting party
	    needs to first select the most appropriate key from those provided in the JWK Set at
	    the recipient's <spanx style="verb">jwks_uri</spanx> location.
	  </t>
	  <t>
	    To rotate keys, the decrypting party can publish new keys
	    at its <spanx style="verb">jwks_uri</spanx> location
	    and remove from the JWK Set those that are being decommissioned.
	    The <spanx style="verb">jwks_uri</spanx> SHOULD include a <spanx style="verb">Cache-Control</spanx>
	    header in the response that contains a <spanx style="verb">max-age</spanx> directive,
	    as defined in <xref target="RFC7234">RFC 7234</xref>,
	    which enables the encrypting party to safely cache the JWK Set and not have to re-retrieve
	    the document for every encryption event. The decrypting party SHOULD remove decommissioned keys
	    from the JWK Set referenced by <spanx style="verb">jwks_uri</spanx>
	    but retain them internally for some reasonable
	    period of time, coordinated with the cache duration, to facilitate a smooth transition between keys
	    by allowing the encrypting party some time to obtain the new keys. The cache duration SHOULD also
	    be coordinated with the issuance of new signing keys, as described in <xref target="RotateSigKeys"/>.
	  </t>
	</section>

      </section>
    </section>

    <section anchor="OfflineAccess" title="Offline Access">

      <t>
	OpenID Connect defines the following <spanx style="verb">scope</spanx> value
	to request offline access:

	<list style="hanging">
	  <t hangText="offline_access">
	    <vspace/>
	    OPTIONAL. This scope value requests
	    that an OAuth 2.0 Refresh Token be issued that can be used to
	    obtain an Access Token that grants access to the End-User's
	    UserInfo Endpoint even when the End-User is not present (not logged in).
	  </t>
	</list>
      </t>
      <t>
	When offline access is requested, a <spanx style="verb">prompt</spanx>
	parameter value of <spanx style="verb">consent</spanx> MUST be used
	unless other conditions for processing the request permitting offline access
	to the requested resources are in place.
	The OP MUST always obtain consent to returning a Refresh Token
	that enables offline access to the requested resources.
	A previously saved user consent is not always sufficient to grant offline access.
      </t>
      <t>
	Upon receipt of a scope parameter containing the
	<spanx style="verb">offline_access</spanx> value, the Authorization Server:

	<list style="symbols">
	  <t>
	    MUST ensure that the prompt parameter contains
	    <spanx style="verb">consent</spanx>
	    unless other conditions for processing the request permitting offline access
	    to the requested resources are in place;
	    unless one or both of these conditions are fulfilled, then
	    it MUST ignore the <spanx style="verb">offline_access</spanx> request,
	  </t>
	  <t>
	    MUST ignore the <spanx style="verb">offline_access</spanx> request
	    unless the Client is using a <spanx style="verb">response_type</spanx>
	    value that would result in an Authorization Code being returned,
	  </t>
	  <t>
	    MUST explicitly receive or have consent for all Clients when
	    the registered <spanx style="verb">application_type</spanx>
	    is <spanx style="verb">web</spanx>,
	  </t>
	  <t>
	    SHOULD explicitly receive or have consent for all Clients when
	    the registered <spanx style="verb">application_type</spanx>
	    is <spanx style="verb">native</spanx>.
	  </t>
	</list>

	The use of Refresh Tokens is not exclusive to the
	<spanx style="verb">offline_access</spanx> use case.
	The Authorization Server MAY grant Refresh Tokens
	in other contexts that are beyond the scope of this specification.
      </t>
    </section>

    <section anchor="RefreshTokens" title="Using Refresh Tokens">
      <t>
	A request to the Token Endpoint can also use a Refresh Token
	by using the <spanx style="verb">grant_type</spanx> value
	<spanx style="verb">refresh_token</spanx>,
	as described in Section 6 of 
	<xref target="RFC6749">OAuth 2.0</xref>.
	This section defines the behaviors for OpenID Connect
	Authorization Servers when Refresh Tokens are used.
      </t>

      <section anchor="RefreshingAccessToken" title="Refresh Request">
	<t>
	  To refresh an Access Token, the Client MUST
	  authenticate to the Token Endpoint using the authentication method registered
	  for its <spanx style="verb">client_id</spanx>, as documented in
	  <xref target="ClientAuthentication"/>.
	  The Client sends the parameters via HTTP <spanx style="verb">POST</spanx>
	  to the Token Endpoint using
	  Form Serialization, per <xref target="FormSerialization"/>.
	</t>

	<figure>
	  <preamble>
	    The following is a non-normative example of a
	    Refresh Request
	    (with line wraps within values for display purposes only):
	  </preamble>

	  <artwork><![CDATA[
  POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded

  client_id=s6BhdRkqt3
    &client_secret=some_secret12345
    &grant_type=refresh_token
    &refresh_token=8xLOxBtZp8
    &scope=openid%20profile
    ]]></artwork>
	</figure>

	<t>
	  The Authorization Server MUST validate the Refresh Token,
	  MUST verify that it was issued to the Client,
	  and must verify that the Client successfully authenticated
	  it has a Client Authentication method.
	</t>
      </section>

      <section anchor="RefreshTokenResponse" title="Successful Refresh Response">
	<t>
	  Upon successful validation of the Refresh Token,
	  the response body is the Token Response of <xref target="TokenResponse"/>
	  except that it might not contain an <spanx style="verb">id_token</spanx>.
	</t>

	<t>
	  If an ID Token is returned as a result of a token refresh request,
	  the following requirements apply:
	  <list style="symbols">
	    <t>
	      its <spanx style="verb">iss</spanx> Claim Value MUST be the same as
	      in the ID Token issued when the original authentication occurred,
	    </t>
	    <t>
	      its <spanx style="verb">sub</spanx> Claim Value MUST be the same as
	      in the ID Token issued when the original authentication occurred,
	    </t>
	    <t>
	      its <spanx style="verb">iat</spanx> Claim MUST represent
	      the time that the new ID Token is issued,
	    </t>
	    <t>
	      its <spanx style="verb">aud</spanx> Claim Value MUST be the same as
	      in the ID Token issued when the original authentication occurred,
	    </t>
	    <t>
	      if the ID Token contains an <spanx style="verb">auth_time</spanx> Claim,
	      its value MUST represent the time of the original authentication - not
	      the time that the new ID token is issued,
	    </t>
	    <t>
	      its <spanx style="verb">azp</spanx> Claim Value MUST be the same as
	      in the ID Token issued when the original authentication occurred;
	      if no <spanx style="verb">azp</spanx> Claim was present in the original
	      ID Token, one MUST NOT be present in the new ID Token, and
	    </t>
	    <t>
	      otherwise, the same rules apply as apply when issuing an ID Token
	      at the time of the original authentication.
	    </t>
	  </list>
	</t>

	<figure>
	  <preamble>
	    The following is a non-normative example of a
	    Refresh Response:
	  </preamble>

	  <artwork><![CDATA[
  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-cache, no-store
  Pragma: no-cache

  {
   "access_token": "TlBN45jURg",
   "token_type": "Bearer",
   "refresh_token": "9yNOxJtZa5",
   "expires_in": 3600
  }
]]></artwork>
	</figure>
      </section>

      <section anchor="RefreshErrorResponse" title="Refresh Error Response">
	<t>If the Refresh Request is invalid or unauthorized, the
	Authorization Server returns the 
	Token Error Response as defined in Section 5.2 of <xref
	target="RFC6749">OAuth 2.0</xref>.</t>
      </section>

    </section>

    <section anchor="Serializations" title="Serializations">
      <t>
	Messages are serialized using one of the following methods:
        <list style="numbers">
	  <t>Query String Serialization</t>
	  <t>Form Serialization</t>
	  <t>JSON Serialization</t>
        </list>

	This section describes the syntax of these serialization methods;
	other sections describe when they can and must be used.
	Note that not all methods can be used for all messages.
      </t>

      <section anchor="QuerySerialization" title="Query String Serialization">

        <t>In order to serialize the parameters using the Query String
        Serialization, the Client constructs the string by adding the
        parameters and values to the query component of a URL using the <spanx
        style="verb">application/x-www-form-urlencoded</spanx> format as
        defined by <xref target="W3C.REC-html401-19991224"></xref>.
	Query String Serialization is typically used in
	HTTP <spanx style="verb">GET</spanx> requests.
	The same serialization method is also used when adding
	parameters to the fragment component of a URL.
	</t>

        <figure>
          <preamble>
	    The following is a non-normative example of this serialization
	    (with line wraps within values for display purposes only):
	  </preamble>

          <artwork><![CDATA[
  GET /authorize?
    response_type=code
    &scope=openid
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
  Host: server.example.com
]]></artwork>
        </figure>
      </section>

      <section anchor="FormSerialization" title="Form Serialization">

        <t>Parameters and their values are Form Serialized by adding the 
        parameter names and values to the entity body of the HTTP request using
        the <spanx style="verb">application/x-www-form-urlencoded</spanx> format
        as defined by <xref target="W3C.REC-html401-19991224"></xref>.
	Form Serialization is typically used in HTTP <spanx style="verb">POST</spanx> requests.</t>

        <figure>
          <preamble>
	    The following is a non-normative example of this serialization
	    (with line wraps within values for display purposes only):
	  </preamble>

          <artwork><![CDATA[
  POST /authorize HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded

  response_type=code
    &scope=openid
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
]]></artwork>
        </figure>
      </section>

      <section anchor="JSONSerialization" title="JSON Serialization">
	<t>
	  The parameters are serialized into a JSON object structure by adding each
	  parameter at the highest structure level. Parameter names and string
	  values are represented as JSON strings.
	  Numerical values are represented as JSON numbers.
	  Boolean values are represented as JSON booleans.
	  Omitted parameters and parameters with no value SHOULD be omitted
	  from the object and not represented by
	  a JSON <spanx style="verb">null</spanx> value, unless otherwise specified.
	  A parameter MAY have a JSON object or a JSON array as its value.
	</t>

	<figure>
          <preamble>
	    The following is a non-normative example of this serialization:
	  </preamble>

	  <artwork><![CDATA[
  {
   "access_token": "SlAV32hkKG",
   "token_type": "Bearer",
   "expires_in": 3600,
   "refresh_token": "8xLOxBtZp8"
  }
]]></artwork>
	</figure>
      </section>

    </section>

    <section anchor="StringOps" title="String Operations">

      <t>
	Processing some OpenID Connect messages requires comparing
	values in the messages to known values. For example, the Claim
	Names returned by the UserInfo Endpoint might be compared to
	specific Claim Names such as <spanx
	style="verb">sub</spanx>.  Comparing Unicode <xref target="UNICODE"/> strings,
	however, has significant security implications.
      </t>
      <t>
	Therefore, comparisons between JSON strings and other Unicode
	strings MUST be performed as specified below:

	<list style="numbers">

	  <t>
	    Remove any JSON applied escaping to produce an array of
	    Unicode code points.
	  </t>
	  <t>
	    Unicode Normalization <xref target="USA15"/> MUST NOT
	    be applied at any point to either the JSON string or to
	    the string it is to be compared against.
	  </t>
	  <t>
	    Comparisons between the two strings MUST be performed as a
	    Unicode code point to code point equality comparison.
	  </t>

	</list>
      </t>
      <t>
	In several places, this specification uses space-delimited
	lists of strings.  In all such cases, a single ASCII space
	character (0x20) MUST be used as the delimiter.
      </t>

    </section>

    <section anchor="ImplementationConsiderations" title="Implementation Considerations">
      <t>
	This specification defines features used by both Relying Parties and
	OpenID Providers.
	It is expected that some OpenID Providers will require
	static, out-of-band configuration of RPs using them,
	whereas others will support dynamic usage by RPs without
	a pre-established relationship between them.
	For that reason, the mandatory-to-implement features for OPs
	are listed below in two groups:
	the first for all OPs and the second for "Dynamic" OpenID Providers.
      </t>

      <section anchor="ServerMTI"
	       title="Mandatory to Implement Features for All OpenID Providers">
	<t>
	  All OpenID Providers MUST implement the following features defined in this specification.
	  This list augments the set of features that are already listed elsewhere
	  as being "REQUIRED" or are described with a "MUST",
	  and so is not, by itself, a comprehensive set of implementation requirements for OPs.
	</t>
	<t>
	  <list style="hanging">

	    <t hangText="Signing ID Tokens with RSA SHA-256">
	      <vspace/>
	      OPs MUST support signing ID Tokens with the RSA SHA-256 algorithm
	      (an <spanx style="verb">alg</spanx> value of
	      <spanx style="verb">RS256</spanx>),
	      unless the OP only supports returning ID Tokens from the Token Endpoint
	      (as is the case for the Authorization Code Flow)
	      and only allows Clients to register specifying
	      <spanx style="verb">none</spanx> as the requested ID Token signing algorithm.
	    </t>
	    <t hangText="Prompt Parameter">
	      <vspace/>
	      OPs MUST support the <spanx style="verb">prompt</spanx> parameter,
	      as defined in <xref target="AuthorizationEndpoint"/>, including the specified
	      user interface behaviors such as <spanx style="verb">none</spanx>
	      and <spanx style="verb">login</spanx>.
	    </t>
	    <t hangText="Display Parameter">
	      <vspace/>
	      OPs MUST support the <spanx style="verb">display</spanx> parameter,
	      as defined in <xref target="AuthorizationEndpoint"/>.
	      (Note that the minimum level of support required for this parameter is
	      simply that its use must not result in an error.)
	    </t>
	    <t hangText="Preferred Locales">
	      <vspace/>
	      OPs MUST support requests for preferred languages and scripts
	      for the user interface and for Claims via the
	      <spanx style="verb">ui_locales</spanx> and
	      <spanx style="verb">claims_locales</spanx> request parameters,
	      as defined in <xref target="AuthorizationEndpoint"/>.
	      (Note that the minimum level of support required for these parameters is
	      simply to have their use not result in errors.)
	    </t>
	    <t hangText="Authentication Time">
	      <vspace/>
	      OPs MUST support returning the time at which the End-User authenticated
	      via the <spanx style="verb">auth_time</spanx> Claim, when requested,
	      as defined in <xref target="IDToken"/>.
	    </t>
	    <t hangText="Maximum Authentication Age">
	      <vspace/>
	      OPs MUST support enforcing a maximum authentication age
	      via the <spanx style="verb">max_age</spanx> parameter,
	      as defined in <xref target="AuthorizationEndpoint"/>.
	    </t>
	    <t hangText="Authentication Context Class Reference">
	      <vspace/>
	      OPs MUST support requests for specific
	      Authentication Context Class Reference values
	      via the <spanx style="verb">acr_values</spanx> parameter,
	      as defined in <xref target="AuthorizationEndpoint"/>.
	      (Note that the minimum level of support required for this parameter is
	      simply to have its use not result in an error.)
	    </t>

	  </list>
	</t>
      </section>

      <section anchor="DynamicMTI"
	       title="Mandatory to Implement Features for Dynamic OpenID Providers">
	<t>
	  In addition to the features listed above,
	  OpenID Providers supporting dynamic establishment of relationships with RPs
	  that they do not have a pre-configured relationship with
	  MUST also implement the following features defined in this and related specifications.
	</t>
	<t>
	  <list style="hanging">

	    <t hangText="Response Types">
	      <vspace/>
	      These OpenID Providers MUST support the
	      <spanx style="verb">id_token</spanx> Response Type and
	      all that are not Self-Issued OPs MUST also support the
	      <spanx style="verb">code</spanx> and
	      <spanx style="verb">id_token&nbsp;token</spanx> Response Types.
	    </t>

	    <t hangText="Discovery">
	      <vspace/>
	      These OPs MUST support Discovery,
	      as defined in
	      <xref target="OpenID.Discovery">OpenID Connect Discovery 1.0</xref>.
	    </t>
	    <t hangText="Dynamic Registration">
	      <vspace/>
	      These OPs MUST support Dynamic Client Registration,
	      as defined in
	      <xref target="OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</xref>.
	    </t>
	    <t hangText="UserInfo Endpoint">
	      <vspace/>
	      All dynamic OPs that issue Access Tokens MUST support the UserInfo Endpoint,
	      as defined in <xref target="UserInfo"/>.
	      (Self-Issued OPs do not issue Access Tokens.)
	    </t>
	    <t hangText="Public Keys Published as Bare Keys">
	      <vspace/>
	      These OPs MUST publish their public keys as bare JWK keys
	      (which MAY also be accompanied by X.509 representations of those keys).
	    </t>
	    <t hangText="Request URI">
	      <vspace/>
	      These OPs MUST support requests made using a Request Object value
	      that is retrieved from a Request URI that is provided
	      with the <spanx style="verb">request_uri</spanx> parameter,
	      as defined in <xref target="RequestUriParameter"/>.
	    </t>

	  </list>
	</t>
      </section>

      <section anchor="DiscoReg" title="Discovery and Registration">

	<t>Some OpenID Connect installations can use a pre-configured set of
	OpenID Providers and/or Relying Parties. In those cases, it might not be
	necessary to support dynamic discovery of information about identities
	or services or dynamic registration of Clients.</t>

	<t>However, if installations choose to support unanticipated
	interactions between Relying Parties and OpenID Providers that do not
	have pre-configured relationships, they SHOULD accomplish this by
	implementing the facilities defined in the <xref
	target="OpenID.Discovery">OpenID Connect Discovery 1.0</xref> and <xref
	target="OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</xref>
	specifications.</t>
      </section>

      <section anchor="RPMTI" title="Mandatory to Implement Features for Relying Parties">
	<t>
	  In general, it is up to Relying Parties which features they use
	  when interacting with OpenID Providers.
	  However, some choices are dictated by the nature of their OAuth Client,
	  such as whether it is a Confidential Client, capable of keeping secrets,
	  in which case the Authorization Code Flow may be appropriate,
	  or whether it is a Public Client, for instance, a
	  User Agent Based Application or a statically registered Native Application,
	  in which case the Implicit Flow may be appropriate.
	</t>
	<t>
	  When using OpenID Connect features, those listed as being
	  "REQUIRED" or are described with a "MUST" are
	  mandatory to implement, when used by a Relying Party.
	  Likewise, those features that are described as "OPTIONAL"
	  need not be used or supported unless they provide value
	  in the particular application context.
	  Finally, when interacting with OpenID Providers that support Discovery,
	  the OP's Discovery document can be used to dynamically determine
	  which OP features are available for use by the RP.
      </t>
      <t>
	</t>
      </section>

      <section anchor="ImplementationNotes" title="Implementation Notes">

	<section anchor="CodeNotes" title="Authorization Code Implementation Notes">
	  <t>
	    When using the Authorization Code or Hybrid flows,
	    an ID Token is returned from the Token Endpoint
	    in response to a Token Request using an Authorization Code.
	    Some implementations may choose to encode state about
	    the ID Token to be returned in the Authorization Code value.
	    Others may use the Authorization Code value
	    as an index into a database storing this state.
	  </t>
	</section>

	<section anchor="NonceNotes" title="Nonce Implementation Notes">
	  <t>
	    The <spanx style="verb">nonce</spanx> parameter value needs to include
	    per-session state and be unguessable to attackers.
	    One method to achieve this for Web Server Clients is to store a cryptographically random value
	    as an HttpOnly session cookie and use a cryptographic hash of the value
	    as the <spanx style="verb">nonce</spanx> parameter.
	    In that case, the <spanx style="verb">nonce</spanx> in the returned
	    ID Token is compared to the hash of the session cookie
	    to detect ID Token replay by third parties.
	    A related method applicable to JavaScript Clients is to store the cryptographically random value
	    in HTML5 local storage and use a cryptographic hash of this value.
	  </t>
	</section>

	<section anchor="FragmentNotes"
		 title="Redirect URI Fragment Handling Implementation Notes">
	  <t>
	    When response parameters are returned in the Redirection URI fragment value,
	    the Client needs to have the User Agent parse the fragment encoded values
	    and pass them to on to the Client's processing logic for consumption.
	    User Agents that have direct access to cryptographic APIs may be able to be
	    self-contained, for instance, with all Client code being written in JavaScript.
	  </t>
	  <t>
	    However, if the Client does not run entirely in the User Agent,
	    one way to achieve this
	    is to post them to a Web Server Client for validation.
	  </t>

	  <t>The following is an example of a JavaScript file that a Client might host at its
	  <spanx style="verb">redirect_uri</spanx>.  This is loaded by the redirect from
	  the Authorization Server.  The fragment component is parsed and then sent by <spanx style="verb">POST</spanx> to a URI 
	  that will validate and use the information received.</t>

	  <figure>
	    <preamble>Following is a non-normative example of a
	    Redirect URI response:</preamble>
	    <artwork><![CDATA[
  GET /cb HTTP/1.1
  Host: client.example.org

  HTTP/1.1 200 OK
  Content-Type: text/html

  <script type="text/javascript">

  // First, parse the query string
  var params = {}, postBody = location.hash.substring(1),
      regex = /([^&=]+)=([^&]*)/g, m;
  while (m = regex.exec(postBody)) {
    params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
  }

  // And send the token over to the server
  var req = new XMLHttpRequest();
  // using POST so query isn't logged
  req.open('POST', 'https://' + window.location.host +
                   '/catch_response', true);
  req.setRequestHeader('Content-Type',
                       'application/x-www-form-urlencoded');

  req.onreadystatechange = function (e) {
    if (req.readyState == 4) {
      if (req.status == 200) {
  // If the response from the POST is 200 OK, perform a redirect
        window.location = 'https://'
          + window.location.host + '/redirect_after_login'
      }
  // if the OAuth response is invalid, generate an error message
      else if (req.status == 400) {
        alert('There was an error processing the token')
      } else {
        alert('Something other than 200 was returned')
      }
    }
  };
  req.send(postBody);
  ]]></artwork>
	  </figure>

	</section>

      </section>

      <section anchor="CompatibilityNotes" title="Compatibility Notes">

	<t>
	  NOTE: Potential compatibility issues that were previously described in
	  the original version of this specification have since been addressed.
	</t>

      </section>

      <section anchor="RelatedSpecs" title="Related Specifications and Implementer's Guides">

	<t>
	  These related OPTIONAL specifications MAY be used in
	  combination with this specification to provide additional functionality:

	  <list style="symbols">

	    <t>
	      <xref target="OpenID.Discovery">OpenID Connect Discovery 1.0</xref> -
	      Defines how Relying Parties dynamically discover information about OpenID Providers
	    </t>
	    <t>
	      <xref target="OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</xref> -
	      Defines how Relying Parties dynamically register with OpenID Providers
	    </t>
	    <t>
	      <xref target="OAuth.Post">OAuth 2.0 Form Post Response Mode</xref> -
	      Defines how to return OAuth 2.0 Authorization Response parameters
	      (including OpenID Connect Authentication Response parameters)
	      using HTML form values that are auto-submitted by the User Agent
	      using HTTP <spanx style="verb">POST</spanx>
	    </t>
	    <t>
	      <xref target="OpenID.RPInitiated">OpenID Connect RP-Initiated Logout 1.0</xref> -
	      Defines how a Relying Party
	      requests that an OpenID Provider log out the End-User
	    </t>
	    <t>
	      <xref target="OpenID.Session">OpenID Connect Session Management 1.0</xref> -
	      Defines how to manage OpenID Connect sessions, including postMessage-based logout and RP-initiated logout functionality
	    </t>
	    <t>
	      <xref target="OpenID.FrontChannel">OpenID Connect Front-Channel Logout 1.0</xref> -
	      Defines a front-channel logout mechanism that does not use an OP iframe on RP pages
	    </t>
	    <t>
	      <xref target="OpenID.BackChannel">OpenID Connect Back-Channel Logout 1.0</xref> -
	      Defines a logout mechanism that uses direct back-channel communication between the OP and RPs being logged out
	    </t>

	  </list>
	</t>
	<t>
	  These implementer's guides are intended to serve as self-contained references
	  for implementers of basic Web-based Relying Parties:

	  <list style="symbols">
	    <t><xref target="OpenID.Basic">OpenID Connect Basic Client Implementer's Guide 1.0</xref> -
	    Implementer's guide containing a subset of this specification
	    that is intended for use by basic
	    Web-based Relying Parties using the
	    OAuth Authorization Code Flow</t>

	    <t><xref target="OpenID.Implicit">OpenID Connect Implicit Client Implementer's Guide 1.0</xref> -
	    Implementer's guide containing a subset of this specification
	    that is intended for use by basic
	    Web-based Relying Parties using the
	    OAuth Implicit Flow</t>

	  </list>
	</t>
      </section>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t>
	This specification references the security considerations defined in
	Section 10 of <xref target="RFC6749">OAuth 2.0</xref>, and
	Section 5 of <xref target="RFC6750">OAuth 2.0 Bearer Token Usage</xref>.
	Furthermore, the <xref target="RFC6819">OAuth 2.0 Threat Model and Security
	Considerations</xref> specification provides an extensive list of threats and controls 
	that apply to this specification as well,
	given that it is based upon OAuth 2.0.
	<xref target="ISO29115">ISO/IEC 29115</xref> 
	also provides threats and controls that 
	implementers need to take into account. 
	Implementers are highly advised to
	read these references in detail and apply the countermeasures described therein.
      </t>

      <t>
	In addition, the following list of attack vectors and remedies are
	also considered.
      </t>

      <section anchor="RequestDisclosure" title="Request Disclosure">
	<t>If appropriate measures are not taken, a request might be disclosed to 
	an attacker, posing security and privacy threats.</t>
	<t>In addition to what is stated in Section 5.1.1 of <xref target="RFC6819" />, 
	this standard provides a way to provide the confidentiality of the request 
	end to end through the 
	use of <spanx style="verb">request</spanx> or <spanx style="verb">request_uri</spanx>
	parameters, where the content of the <spanx style="verb">request</spanx>
	is an encrypted JWT with the appropriate key and cipher.  
	This protects even against a compromised User Agent
	in the case of indirect request.</t>
      </section>

      <section anchor="ServerMasquerading" title="Server Masquerading">
	<t>A malicious Server might masquerade as the legitimate server 
	using various means. To detect such an attack, the Client needs to authenticate 
	the server.</t>
	<t>In addition to what is stated in Section 5.1.2 of <xref target="RFC6819" />, 
	this standard provides a way to authenticate the Server through either the 
	use of Signed or Encrypted JWTs 
	with an appropriate key and cipher.</t> 
      </section>

      <section anchor="TokenManufacture"
	       title="Token Manufacture/Modification">
	<t>
	  An Attacker might generate a bogus token or modify the token contents
	  (such as Claims values or the signature)
	  of an existing parseable token, causing the RP to grant 
	  inappropriate access to the Client. For example, an Attacker might modify 
	  the parseable token to extend the validity period; a Client might modify the 
	  parseable token to have access to information that they should not be able to view.
	</t>
	<t>There are two ways to mitigate this attack:</t>

	<t>
	  <list style="numbers">
	    <t>The token can be digitally signed by the OP. The Relying
	    Party SHOULD validate the digital signature to verify that it was
	    issued by a legitimate OP.</t>

	    <t>The token can be sent over a protected channel such as TLS.
	    See <xref target="TLSRequirements"/> for more information on using TLS.
	    In this specification, the token is always sent over a TLS protected channel.
	    Note however, that this measure is only a defense against third party attackers
	    and is not applicable to the case where the Client is the attacker.</t>
	  </list>
	</t>
      </section>

      <section anchor="AccessTokenDisclosure" title="Access Token Disclosure">
	<t>
	  Access Tokens are credentials used to access Protected 
	  Resources, as defined in Section 1.4 of 
	  <xref target="RFC6749">OAuth 2.0</xref>. Access Tokens represent 
	  an End-User's authorization and MUST NOT be exposed to 
	  unauthorized parties.
	</t>
      </section>

      <section anchor="ResponseDisclosure" title="Server Response Disclosure">
	<t>
	  The server response might contain authentication data and Claims
	  that include sensitive Client information. Disclosure of the 
	  response contents can make the Client vulnerable to other types of 
	  attacks.
	</t>

	<t>
	  The server response disclosure can be mitigated in the following two
	  ways:
	  <list style="numbers">
	    <t>Using the <spanx style="verb">code</spanx> Response Type.
	    The response is sent over a TLS protected 
	    channel, where the Client is authenticated by the
	    <spanx style="verb">client_id</spanx> and 
	    <spanx style="verb">client_secret</spanx>.</t>

	    <t>For other Response Types,
	    the signed response can be encrypted with the Client's 
	    public key or a shared secret as an encrypted JWT
	    with an appropriate key and cipher.</t>
	  </list>
	</t>
      </section>

      <section anchor="ServerResponseRepudiation" title="Server Response Repudiation">
	<t>A response might be repudiated by the server if the proper mechanisms are not in place. 
	For example, if a Server does not digitally sign a response, the Server can claim that it was not 
	generated through the services of the Server.</t>

	<t>To mitigate this threat, the response MAY be digitally signed by
	the Server using a key that supports non-repudiation. The Client SHOULD validate
	the digital signature to verify that it was issued by a legitimate
	Server and its integrity is intact.</t>
      </section>

      <section anchor="RequestRepudation" title="Request Repudiation">
	<t>Since it is possible for a 
	compromised or malicious Client to send a request to the wrong party,  
	a Client that was authenticated 
	using only a bearer token can repudiate any transaction.
	</t>
	<t>To mitigate this threat, the Server MAY require that the
	request be digitally signed by
	the Client using a key that supports non-repudiation. 
	The Server SHOULD validate
	the digital signature to verify that it was issued by a legitimate
	Client and its integrity is intact.</t>
      </section>

      <section anchor="AccessTokenRedirect" title="Access Token Redirect">
	<t>An Attacker uses the Access Token generated for one resource to 
	obtain access to a second resource.
	</t>
	<t>To mitigate this threat, the Access Token SHOULD be audience 
	and scope restricted. One way of implementing it is to include
	the identifier of the resource for whom it was generated as audience. 
	The resource verifies that
	incoming tokens include its identifier as the audience of the
	token.</t>
      </section>

      <section anchor="TokenReuse" title="Token Reuse">
	<t>An Attacker attempts to use a one-time use token such as
	an Authorization Code that has already
	been used once with the intended Resource.
	To mitigate this threat, the token SHOULD include a timestamp 
	and a short validity lifetime.
	The Relying Party then checks the timestamp and lifetime values
	to ensure that the token is currently valid.</t>

	<t>Alternatively, the server MAY record the state of the use of 
	the token and check the status for each request.</t>
      </section>

      <section anchor="AuthCodeCapture"
	       title=" Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture)">
	<t>In addition to the attack patterns described in
	Section 4.4.1.1 of <xref target="RFC6819"/>,
	an Authorization Code can be captured in the User Agent where the TLS
	session is terminated if the User Agent is infected by malware.
	However, capturing it is not useful as long as either
	Client Authentication or an encrypted response is used.
	</t>
      </section>

      <section anchor="TokenSubstitution" title="Token Substitution">
	<t>
	  Token Substitution is a class of attacks in which a malicious user
	  swaps various tokens, including swapping an Authorization Code for
	  a legitimate user with another token that the attacker has.
	  One means of accomplishing this is for the attacker to copy
	  a token out one session and use it in an HTTP message for
	  a different session, which is easy to do when the token is
	  available to the browser; this is known as the "cut and paste" attack.
	</t>
	<t>
	  The Implicit Flow of <xref target="RFC6749">OAuth 2.0</xref>
	  is not designed to mitigate this risk.  In Section 10.16,
	  it normatively requires that any use of the authorization
	  process as a form of delegated End-User authentication to the
	  Client MUST NOT use the Implicit Flow without employing
	  additional security mechanisms that enable the Client to
	  determine whether the ID Token and Access Token were issued for its use.
	</t>
	<t>
	  In OpenID Connect, this is mitigated through mechanisms
	  provided through the ID Token.  The ID Token is a signed
	  security token that provides Claims such as
	  <spanx style="verb">iss</spanx> (issuer),
	  <spanx style="verb">sub</spanx> (subject),
	  <spanx style="verb">aud</spanx> (audience),
	  <spanx style="verb">azp</spanx> (authorized party),
	  <spanx style="verb">at_hash</spanx> (access token hash), and
	  <spanx style="verb">c_hash</spanx> (code hash).  Using the ID Token,
	  the Client is capable of detecting the Token Substitution Attack.
	</t>
	<t>
	  The <spanx style="verb">c_hash</spanx> in the ID Token enables
	  Clients to prevent Authorization Code substitution.
	  The <spanx style="verb">at_hash</spanx> in the ID Token enables
	  Clients to prevent Access Token substitution.
	</t>
	<t>
	  Also, a malicious user may attempt to impersonate a more
	  privileged user by subverting the communication channel
	  between the Authorization Endpoint and Client, or the Token Endpoint
	  and Client, for example by swapping the Authorization Code
	  or reordering the messages, to convince the Token Endpoint
	  that the attacker's authorization grant corresponds to a grant
	  sent on behalf of a more privileged user.
	</t>
	<t>
	  For the HTTP binding defined by this specification, the
	  responses to Token Requests are bound to the corresponding
	  requests by message order in HTTP, as both the response
	  containing the token and requests are protected by TLS, which
	  will detect and prevent packet reordering.
	</t>
	<t>
	  When designing another binding of this specification to a
	  protocol incapable of strongly binding Token Endpoint
	  requests to responses, additional mechanisms to
	  address this issue MUST be utilized. One such mechanism could
	  be to include an ID Token with a <spanx style="verb">c_hash</spanx>
	  Claim in the token request and response.
	</t>
      </section>

      <section anchor="TimingAttack" title="Timing Attack">
	<t>A timing attack enables the attacker to 
	obtain an unnecessary large amount of information through the elapsed time 
	differences in the code paths taken by successful and unsuccessful decryption operations or
	successful and unsuccessful signature validation of a message. 
	It can be used to reduce the effective key length of the
	cipher used.</t>
	<t>Implementations SHOULD NOT terminate the validation process 
	at the instant of the finding an error but SHOULD continue 
	running until all the octets have been processed to avoid this attack.</t>
      </section>

      <section anchor="OtherCryptoAttacks" title="Other Crypto Related Attacks">
	<t>There are various crypto related attacks possible depending on the 
	method used for encryption and signature / integrity checking.
	Implementers need to consult the Security Considerations
	for the <xref target="JWT">JWT</xref> specification and
	specifications that it references
	to avoid the vulnerabilities
	identified in these specifications. 
	</t>
      </section>

      <section anchor="SigningOrder" title="Signing and Encryption Order">
	<t>
	  Signatures over encrypted text are not considered valid
	  in many jurisdictions.
	  Therefore, for integrity and non-repudiation,
	  this specification requires signing 
	  the plain text JSON Claims, when signing is performed.
	  If both signing and encryption are desired, it is performed on
	  the JWS containing the signed Claims,
	  with the result being a Nested JWT, as specified in <xref target="JWT"/>.
	  Note that since all JWE encryption algorithms provide integrity protection,
	  there is no need to separately sign the encrypted content.
	</t>
      </section>

      <section anchor="IssuerIdentifier" title="Issuer Identifier">
	<t>OpenID Connect supports multiple Issuers per Host and Port combination.
	The issuer returned by discovery MUST exactly match the value of 
	<spanx style="verb">iss</spanx> in the ID Token.</t>

	<t>
	  OpenID Connect treats the path component of any Issuer URI as
	  being part of the Issuer Identifier.  For instance, the subject
	  "1234" with an Issuer Identifier of "https://example.com" is not
	  equivalent to the subject "1234" with an Issuer Identifier of
	  "https://example.com/sales".
	</t>
	<t>
	  It is RECOMMENDED that only a single Issuer per host be used.
	  However, if a host supports multiple tenants,
	  multiple Issuers for that host may be needed.
	</t>
      </section>		

      <section anchor="ImplicitFlowThreats" title="Implicit Flow Threats">
        <t>In the Implicit Flow, the Access Token is returned in the
        fragment component of the Client's <spanx style="verb">redirect_uri</spanx> through HTTPS, thus it is
        protected between the OP and the User Agent, and between the User Agent and the
        RP. The only place it can be captured is the User Agent where the
        TLS session is terminated, which is possible if the User Agent is
        infected by malware or under the control of a malicious party.</t>
      </section>

      <section anchor="TLSRequirements" title="TLS Requirements">
	<t>
	  Implementations MUST support TLS.
	  Which version(s) ought to be implemented will vary over
	  time, and depend on the widespread deployment and known
	  security vulnerabilities at the time of implementation.
	  At the time of this writing,
	  TLS version 1.2 <xref target='RFC5246' />
	  is the most recent version, but has very limited actual
	  deployment, and might not be readily available in
	  implementation toolkits.
	  TLS version 1.0 <xref target='RFC2246' />
	  is the most widely deployed version, and will give the
	  broadest interoperability.
	</t>
	<t>
	  To protect against information disclosure and tampering,
	  confidentiality protection MUST be applied using TLS
	  with a ciphersuite that provides confidentiality and
	  integrity protection.
	</t>
	<t>
	  Whenever TLS is used, a TLS server certificate check
	  MUST be performed, per <xref target="RFC6125">RFC 6125</xref>.
	</t>
      </section>
      <section anchor="TokenLifetime" title="Lifetimes of Access Tokens and Refresh Tokens">
	<t>Access Tokens might not be revocable by the Authorization Server. 
	Access Token lifetimes SHOULD therefore be kept to single use or 
	very short lifetimes.</t>

	<t>
	  If ongoing access to the UserInfo Endpoint or other Protected Resources is required,
	  a Refresh Token can be used. The Client can then exchange the Refresh Token at
	  the Token Endpoint for a fresh short-lived Access Token that can be used to 
	  access the resource.
	</t>

	<t>
	  The Authorization Server SHOULD clearly identify long-term grants to the User
	  during Authorization.
	  The Authorization Server SHOULD provide a mechanism for the End-User to revoke
	  Access Tokens and Refresh Tokens granted to a Client.
	</t>
      </section>

      <section anchor="SymmetricKeyEntropy" title="Symmetric Key Entropy">
	<t>
	  In <xref target="Signing"/> and <xref target="Encryption"/>, keys are derived
	  from the <spanx style="verb">client_secret</spanx> value.
	  Thus, when used with symmetric signing or encryption operations,
	  <spanx style="verb">client_secret</spanx> values MUST contain
	  sufficient entropy to generate cryptographically strong keys.
	  Also, <spanx style="verb">client_secret</spanx> values MUST also contain
	  at least the minimum of number of octets required for MAC keys for the
	  particular algorithm used.
	  So for instance, for <spanx style="verb">HS256</spanx>, the
	  <spanx style="verb">client_secret</spanx> value MUST contain
	  at least 32 octets (and almost certainly SHOULD contain more,
	  since <spanx style="verb">client_secret</spanx> values are
	  likely to use a restricted alphabet).
	</t>
      </section>

      <section anchor="NeedForSignedRequests" title="Need for Signed Requests">
	<t>
	  In some situations, Clients might need to use signed requests to ensure that
	  the desired request parameters are delivered to the OP without having
	  been tampered with.  For instance, the <spanx style="verb">max_age</spanx>
	  and <spanx style="verb">acr_values</spanx> provide more assurance about
	  the nature of the authentication performed when delivered in signed requests.
	</t>
      </section>

      <section anchor="NeedForEncryptedRequests" title="Need for Encrypted Requests">
	<t>
	  In some situations, knowing the contents of an OpenID Connect request can,
	  in and of itself, reveal sensitive information about the End-User.
	  For instance, knowing that the Client is requesting a particular Claim or
	  that it is requesting that a particular authentication method be used
	  can reveal sensitive information about the End-User.
	  OpenID Connect enables requests to be encrypted to the OpenID Provider
	  to prevent such potentially sensitive information from being revealed.
	</t>
      </section>

      <section anchor="HTTP307Redirects" title="HTTP 307 Redirects">
	<t>
	  HTTP 307 redirects send a POST request to the party being redirected to
	  that contains all the form data from the previous request.
	  This can leak credentials intended for the OpenID Provider to the Relying Party.
	  Therefore, HTTP 307 redirects MUST NOT be used when redirecting to the Redirection URI.
	  Likewise, while HTTP 302 redirects are typically implemented in a way that does not do this,
	  the use of HTTP 303 redirect is preferable, as it is defined not to do this.
	</t>
      </section>

    </section>
    <section anchor="Privacy" title="Privacy Considerations">

      <section anchor="PII" title="Personally Identifiable Information">

	<t>The UserInfo Response typically contains Personally Identifiable
	Information (PII). As such, End-User consent for the release of the information
	for the specified purpose should be obtained at or prior to the
	authorization time in accordance with relevant regulations. The purpose
	of use is typically registered in association with the <spanx
	style="verb">redirect_uris</spanx>.</t>

	<t>Only necessary UserInfo data should be stored at the Client and the
	Client SHOULD associate the received data with the purpose of use
	statement.</t>
      </section>

      <section anchor="AccessMonitoring" title="Data Access Monitoring">
	<t>
	  The Resource Server SHOULD make End-Users' UserInfo access logs
	  available to them so that they can monitor who accessed their data.
	</t>
      </section>

      <section anchor="Correlation" title="Correlation">
	<t>To protect the End-User from a possible correlation among Clients, the
	use of a Pairwise Pseudonymous Identifier (PPID) as the
	<spanx style="verb">sub</spanx> (subject) SHOULD be considered.</t>
      </section>

      <section anchor="OfflineAccessPrivacy" title="Offline Access">

	<t>
	  Offline access enables access to Claims when the user is not present,
	  posing greater privacy risk than the Claims transfer when the user is present.
	  Therefore, it is prudent to obtain explicit consent for
	  offline access to resources.
	  This specification mandates the use of the <spanx style="verb">prompt</spanx>
	  parameter to obtain consent unless it is already known that the
	  request complies with the conditions for processing the request in each jurisdiction.
	</t>
	<t>
	  When an Access Token is returned via the User Agent
	  using the Implicit Flow or Hybrid Flow, there is
	  a greater risk of it being exposed to an attacker, who could
	  later use it to access the UserInfo endpoint.
	  If the Access Token does not enable offline access and the server
	  can differentiate whether the Client request has been made
	  offline or online, the risk will be substantially reduced.
	  Therefore, this specification mandates ignoring
	  the offline access request when the Access Token is
	  transmitted through the User Agent.
	  Note that differentiating between online and offline access
	  from the server can be difficult especially for native clients.
	  The server may well have to rely on heuristics.
	  Also, the risk of exposure for the Access Token delivered
	  through the User Agent for the Response Types of
	  <spanx style="verb">code&nbsp;token</spanx> and
	  <spanx style="verb">token</spanx> is the same.
	  Thus, the implementations should be prepared to detect
	  whether the Access Token was issued through the User Agent
	  or directly from the Token Endpoint and deny offline access
	  if the token was issued through the User Agent.
	</t>
	<t>
	  Note that although these provisions require an explicit
	  consent dialogue through the <spanx style="verb">prompt</spanx> parameter,
	  the mere fact that the user pressed an "accept" button etc.,
	  might not constitute a valid consent.
	  Developers should be aware that for the act of consent to
	  be valid, typically, the impact of the terms have to be
	  understood by the End-User, the consent must be freely given
	  and not forced (i.e., other options have to be available),
	  and the terms must fair and equitable.
	  In general, it is advisable for the service to follow the
	  required privacy principles in each jurisdiction and rely on
	  other conditions for processing the request than simply explicit consent,
	  as online self-service "explicit consent" often does not
	  form a valid consent in some jurisdictions.
	</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">

      <section anchor="ClaimsRegistry" title="JSON Web Token Claims Registration">
	<t>
	  This specification registers the Claims defined in
	  <xref target="StandardClaims"/> and <xref target="IDToken"/> in the IANA
	  "JSON Web Token Claims" registry <xref target="IANA.JWT.Claims"/>
	  established by <xref target="JWT"/>.
	</t>

	<section anchor='ClaimsContents' title='Registry Contents'>
	  <t> <?rfc subcompact="yes"?>
	  <list style='symbols'>
	    <t>
	      Claim Name: <spanx style="verb">name</spanx>
	    </t>
	    <t>
	      Claim Description: Full name
	    </t>
	    <t>
	      Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	    </t>
	    <t>
	      Specification Document(s): <xref target="StandardClaims"/> of this document
	    </t>
	  </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">given_name</spanx>
	      </t>
	      <t>
		Claim Description: Given name(s) or first name(s)
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">family_name</spanx>
	      </t>
	      <t>
		Claim Description: Surname(s) or last name(s)
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">middle_name</spanx>
	      </t>
	      <t>
		Claim Description: Middle name(s)
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">nickname</spanx>
	      </t>
	      <t>
		Claim Description: Casual name
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">preferred_username</spanx>
	      </t>
	      <t>
		Claim Description: Shorthand name by which the End-User wishes to be referred to
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">profile</spanx>
	      </t>
	      <t>
		Claim Description: Profile page URL
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">picture</spanx>
	      </t>
	      <t>
		Claim Description: Profile picture URL
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">website</spanx>
	      </t>
	      <t>
		Claim Description: Web page or blog URL
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">email</spanx>
	      </t>
	      <t>
		Claim Description: Preferred e-mail address
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">email_verified</spanx>
	      </t>
	      <t>
		Claim Description: True if the e-mail address has been verified; otherwise false
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">gender</spanx>
	      </t>
	      <t>
		Claim Description: Gender
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">birthdate</spanx>
	      </t>
	      <t>
		Claim Description: Birthday
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">zoneinfo</spanx>
	      </t>
	      <t>
		Claim Description: Time zone
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">locale</spanx>
	      </t>
	      <t>
		Claim Description: Locale
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">phone_number</spanx>
	      </t>
	      <t>
		Claim Description: Preferred telephone number
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">phone_number_verified</spanx>
	      </t>
	      <t>
		Claim Description: True if the phone number has been verified; otherwise false
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">address</spanx>
	      </t>
	      <t>
		Claim Description: Preferred postal address
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">updated_at</spanx>
	      </t>
	      <t>
		Claim Description: Time the information was last updated
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="StandardClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">azp</spanx>
	      </t>
	      <t>
		Claim Description: Authorized party - the party to which the ID Token was issued
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="IDToken"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">nonce</spanx>
	      </t>
	      <t>
		Claim Description: Value used to associate a Client session with an ID Token
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="IDToken"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">auth_time</spanx>
	      </t>
	      <t>
		Claim Description: Time when the authentication occurred
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="IDToken"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">at_hash</spanx>
	      </t>
	      <t>
		Claim Description: Access Token hash value
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="IDToken"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">c_hash</spanx>
	      </t>
	      <t>
		Claim Description: Code hash value
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="HybridIDToken"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">acr</spanx>
	      </t>
	      <t>
		Claim Description: Authentication Context Class Reference
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="IDToken"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">amr</spanx>
	      </t>
	      <t>
		Claim Description: Authentication Methods References
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="IDToken"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">sub_jwk</spanx>
	      </t>
	      <t>
		Claim Description: Public key used to check the signature of an ID Token
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="SelfIssuedResponse"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">_claim_names</spanx>
	      </t>
	      <t>
		Claim Description: JSON object whose member names are the Claim Names for the Aggregated and Distributed Claims
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="AggregatedDistributedClaims"/> of this document
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Claim Name: <spanx style="verb">_claim_sources</spanx>
	      </t>
	      <t>
		Claim Description: JSON object whose member names are referenced by the member values of the <spanx style="verb">_claim_names</spanx> member
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="AggregatedDistributedClaims"/> of this document
	      </t>
	    </list>
	  </t>
	</section>
	<?rfc subcompact="no"?>
      </section>

      <section anchor="OAuthParametersRegistry" title="OAuth Parameters Registration">

	<t>
	  This specification registers the following parameters
	  in the IANA
	  "OAuth Parameters" registry <xref target="IANA.OAuth.Parameters"/>
	  established by <xref target="RFC6749">RFC 6749</xref>.
	</t>

	<section anchor='ParametersContents' title='Registry Contents'>
	  <t> <?rfc subcompact="yes"?>
	  <list style="symbols">
	    <t>Parameter name: <spanx style="verb">nonce</spanx></t>

	    <t>Parameter usage location: Authorization Request</t>

	    <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	    <t>Specification document(s): <xref target="AuthorizationEndpoint"/> of this document</t>

	    <t>Related information: None</t>
	  </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Parameter name: <spanx style="verb">display</spanx></t>

	      <t>Parameter usage location: Authorization Request</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="AuthorizationEndpoint"/> of this document</t>

	      <t>Related information: None</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Parameter name: <spanx style="verb">prompt</spanx></t>

	      <t>Parameter usage location: Authorization Request</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="AuthorizationEndpoint"/> of this document</t>

	      <t>Related information: None</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Parameter name: <spanx style="verb">max_age</spanx></t>

	      <t>Parameter usage location: Authorization Request</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="AuthorizationEndpoint"/> of this document</t>

	      <t>Related information: None</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Parameter name: <spanx style="verb">ui_locales</spanx></t>

	      <t>Parameter usage location: Authorization Request</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="AuthorizationEndpoint"/> of this document</t>

	      <t>Related information: None</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Parameter name: <spanx style="verb">claims_locales</spanx></t>

	      <t>Parameter usage location: Authorization Request</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="ClaimsLanguagesAndScripts"/> of this document</t>

	      <t>Related information: None</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Parameter name: <spanx style="verb">id_token_hint</spanx></t>

	      <t>Parameter usage location: Authorization Request</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="AuthorizationEndpoint"/> of this document</t>

	      <t>Related information: None</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Parameter name: <spanx style="verb">login_hint</spanx></t>

	      <t>Parameter usage location: Authorization Request</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="AuthorizationEndpoint"/> of this document</t>

	      <t>Related information: None</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Parameter name: <spanx style="verb">acr_values</spanx></t>

	      <t>Parameter usage location: Authorization Request</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="AuthorizationEndpoint"/> of this document</t>

	      <t>Related information: None</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Parameter name: <spanx style="verb">claims</spanx></t>

	      <t>Parameter usage location: Authorization Request</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="ClaimsParameter"/> of this document</t>

	      <t>Related information: None</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Parameter name: <spanx style="verb">registration</spanx></t>

	      <t>Parameter usage location: Authorization Request</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="RegistrationParameter"/> of this document</t>

	      <t>Related information: None</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Parameter name: <spanx style="verb">request</spanx></t>

	      <t>Parameter usage location: Authorization Request</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="JWTRequests"/> of this document</t>

	      <t>Related information: None</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Parameter name: <spanx style="verb">request_uri</spanx></t>

	      <t>Parameter usage location: Authorization Request</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="JWTRequests"/> of this document</t>

	      <t>Related information: None</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Parameter name: <spanx style="verb">id_token</spanx></t>

	      <t>Parameter usage location: Authorization Response,
	      Access Token Response</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="TokenResponse"/> of this document</t>

	      <t>Related information: None</t>
	    </list>
	  </t>
	</section>
	<?rfc subcompact="no"?>

      </section>

      <section anchor="OAuthErrorRegistry" title="OAuth Extensions Error Registration">

	<t>
	  This specification registers the following errors
	  in the IANA
	  "OAuth Extensions Error" registry <xref target="IANA.OAuth.Parameters"/>
	  established by <xref target="RFC6749">RFC 6749</xref>.
	</t>

	<section anchor='ErrorContents' title='Registry Contents'>
	  <t> <?rfc subcompact="yes"?>
	    <list style="symbols">
	      <t>Error name: <spanx style="verb">interaction_required</spanx></t>

	      <t>Error usage location: Authorization Endpoint</t>

	      <t>Related protocol extension: OpenID Connect</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="AuthError"/> of this document</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Error name: <spanx style="verb">login_required</spanx></t>

	      <t>Error usage location: Authorization Endpoint</t>

	      <t>Related protocol extension: OpenID Connect</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="AuthError"/> of this document</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Error name: <spanx style="verb">account_selection_required</spanx></t>

	      <t>Error usage location: Authorization Endpoint</t>

	      <t>Related protocol extension: OpenID Connect</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="AuthError"/> of this document</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Error name: <spanx style="verb">consent_required</spanx></t>

	      <t>Error usage location: Authorization Endpoint</t>

	      <t>Related protocol extension: OpenID Connect</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="AuthError"/> of this document</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Error name: <spanx style="verb">invalid_request_uri</spanx></t>

	      <t>Error usage location: Authorization Endpoint</t>

	      <t>Related protocol extension: OpenID Connect</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="AuthError"/> of this document</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Error name: <spanx style="verb">invalid_request_object</spanx></t>

	      <t>Error usage location: Authorization Endpoint</t>

	      <t>Related protocol extension: OpenID Connect</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="AuthError"/> of this document</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Error name: <spanx style="verb">request_not_supported</spanx></t>

	      <t>Error usage location: Authorization Endpoint</t>

	      <t>Related protocol extension: OpenID Connect</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="AuthError"/> of this document</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Error name: <spanx style="verb">request_uri_not_supported</spanx></t>

	      <t>Error usage location: Authorization Endpoint</t>

	      <t>Related protocol extension: OpenID Connect</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="AuthError"/> of this document</t>
	    </list>
	  </t>

	  <t>
	    <list style="symbols">
	      <t>Error name: <spanx style="verb">registration_not_supported</spanx></t>

	      <t>Error usage location: Authorization Endpoint</t>

	      <t>Related protocol extension: OpenID Connect</t>

	      <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	      <t>Specification document(s): <xref target="AuthError"/> of this document</t>
	    </list>
	  </t>

	</section>
	<?rfc subcompact="no"?>

      </section>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2246"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4627"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3339"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3629"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3966"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3986"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5246"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5322"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5646"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6125"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6711"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6749"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6750"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6819"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7159"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7230"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7231"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7234"?>

      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml4/reference.W3C.REC-html401-19991224.xml' ?>

      <reference anchor="USA15" target="http://www.unicode.org/reports/tr15/">
	<front>
	  <title>Unicode Normalization Forms</title>

	  <author fullname="Mark Davis" initials="M." surname="Davis">
	    <address>
	      <email>markdavis@google.com</email>
	    </address>
	  </author>

	  <author fullname="Ken Whistler" initials="K." surname="Whistler">
	    <address>
	      <email>ken@unicode.org</email>
	    </address>
	  </author>

	  <date day="01" month="06" year="2015" />
	</front>

	<seriesInfo name="Unicode Standard Annex" value="15" />
      </reference>

      <reference anchor="OpenID.Discovery" target="http://openid.net/specs/openid-connect-discovery-1_0.html">
	<front>
	  <title>OpenID Connect Discovery 1.0</title>

	  <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	    <organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</organization>
	  </author>

	  <author fullname="John Bradley" initials="J." surname="Bradley">
	    <organization abbrev="Yubico (was at Ping Identity)">Yubico</organization>
	  </author>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Microsoft">Microsoft</organization>
	  </author>

	  <author fullname="Edmund Jay" initials="E." surname="Jay">
	    <organization abbrev="Illumila">Illumila</organization>
	  </author>

          <date day="8" month="November" year="2014"/>
	</front>
      </reference>

      <reference anchor="OpenID.Registration" target="http://openid.net/specs/openid-connect-registration-1_0.html">
	<front>
	  <title>OpenID Connect Dynamic Client Registration 1.0</title>

	  <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	    <organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</organization>
	  </author>

	  <author fullname="John Bradley" initials="J." surname="Bradley">
	    <organization abbrev="Yubico (was at Ping Identity)">Yubico</organization>
	  </author>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Microsoft">Microsoft</organization>
	  </author>

          <date day="8" month="November" year="2014"/>
	</front>
      </reference>

      <reference anchor="JWT" target="http://tools.ietf.org/html/rfc7519">
	<front>
	  <title>JSON Web Token (JWT)</title>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Microsoft">Microsoft</organization>
	  </author>

	  <author fullname="John Bradley" initials="J." surname="Bradley">
	    <organization abbrev="Ping Identity">Ping Identity</organization>
	  </author>

	  <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	    <organization abbrev="NRI">Nomura Research Institute, Ltd.</organization>
	  </author>

	  <date month="May" year="2015" />
	</front>

	<seriesInfo name="RFC" value="7519"/>
	<seriesInfo name="DOI" value="10.17487/RFC7519"/>
      </reference>

      <reference anchor="JWS" target="http://tools.ietf.org/html/rfc7515">
	<front>
	  <title>JSON Web Signature (JWS)</title>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Microsoft">Microsoft</organization>
	  </author>

	  <author fullname="John Bradley" initials="J." surname="Bradley">
	    <organization abbrev="Ping Identity">Ping Identity</organization>
	  </author>

	  <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	    <organization abbrev="NRI">Nomura Research Institute, Ltd.</organization>
	  </author>

	  <date month="May" year="2015" />
	</front>

	<seriesInfo name="RFC" value="7515"/>
	<seriesInfo name="DOI" value="10.17487/RFC7515"/>
      </reference>

      <reference anchor="JWE" target="http://tools.ietf.org/html/rfc7516">
	<front>
	  <title>JSON Web Encryption (JWE)</title>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization>Microsoft</organization>
	  </author>

	  <author fullname="Eric Rescorla" initials="E." surname="Rescorla">
	    <organization>RTFM, Inc.</organization>
	  </author>

	  <author fullname="Joe Hildebrand" initials="J." surname="Hildebrand">
	    <organization>Cisco Systems, Inc.</organization>
	  </author>

	  <date month="May" year="2015" />
	</front>

	<seriesInfo name="RFC" value="7516"/>
	<seriesInfo name="DOI" value="10.17487/RFC7516"/>
      </reference>

      <reference anchor="JWK" target="http://tools.ietf.org/html/rfc7517">
	<front>
	  <title>JSON Web Key (JWK)</title>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization>Microsoft</organization>
	  </author>

	  <date month="May" year="2015" />
	</front>

	<seriesInfo name="RFC" value="7517"/>
	<seriesInfo name="DOI" value="10.17487/RFC7517"/>
      </reference>

      <reference anchor="JWA" target="http://tools.ietf.org/html/rfc7518">
	<front>
	  <title>JSON Web Algorithms (JWA)</title>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization>Microsoft</organization>
	  </author>

	  <date month="May" year="2015" />
	</front>

	<seriesInfo name="RFC" value="7518"/>
	<seriesInfo name="DOI" value="10.17487/RFC7518"/>
      </reference>

      <reference anchor="OAuth.JWT" target="http://tools.ietf.org/html/rfc7523">
	<front>
	  <title abbrev="OAuth JWT Assertion Profiles">JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants</title>

	  <author fullname="Michael B. Jones" surname="Jones" initials="M.B."> <!-- role="editor" -->
	    <organization>Microsoft</organization>
	  </author>

	  <author fullname="Brian Campbell" initials="B." surname="Campbell">
	    <organization abbrev="Ping Identity">Ping Identity</organization>
	  </author>

	  <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
	    <organization>Salesforce</organization>
	  </author>

	  <date month="May" year="2015"/>
	</front>

	<seriesInfo name="RFC" value="7523"/>
	<seriesInfo name="DOI" value="10.17487/RFC7523"/>
      </reference>

      <reference anchor="OAuth.Assertions" target="http://tools.ietf.org/html/rfc7521">
	<front>
	  <title abbrev="OAuth Assertion Framework">Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants</title>

	  <author fullname="Brian Campbell" initials="B." surname="Campbell">
	    <organization abbrev="Ping Identity">Ping Identity</organization>
	  </author>

	  <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
	    <organization abbrev="Salesforce">Salesforce.com</organization>
	  </author>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Microsoft">Microsoft</organization>
	  </author>

	  <author fullname="Yaron Y. Goland" initials="Y.Y." surname="Goland">
	    <organization abbrev="Microsoft">Microsoft</organization>
	  </author>

	  <date month="May" year="2015"/>
	</front>

	<seriesInfo name="RFC" value="7521"/>
	<seriesInfo name="DOI" value="10.17487/RFC7521"/>
      </reference>

      <reference anchor="ISO29115" target="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45138">
	<front>
	  <title>ISO/IEC 29115:2013 --
	  Information technology - Security techniques - Entity authentication
	  assurance framework</title>

	  <author fullname="International Organization for Standardization">
	    <organization abbrev="ISO">International Organization for Standardization</organization>
	  </author>

	  <date month="March" year="2013" />
	</front>

	<seriesInfo name="ISO/IEC" value="29115" />
      </reference>

      <reference anchor="ISO639-1" target="http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=22109">
	<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="ISO3166-1" target="http://www.w3.org/WAI/ER/IG/ert/iso639.htm">
	<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="1997" />
	</front>
      </reference>

      <reference anchor="ISO8601-2004" target="http://www.iso.org/iso/catalogue_detail?csnumber=40874">
	<front>
	  <title>ISO 8601:2004. Data elements and interchange formats - Information interchange -
	  Representation of dates and times</title>

	  <author fullname="International Organization for Standardization">
	    <organization abbrev="ISO">International Organization for
	    Standardization</organization>
	  </author>

	  <date year="2004" />
	</front>
      </reference>

      <reference anchor="E.164" target="http://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 Telecommunication Union">
	    <organization abbrev="ITU">International Telecommunication Union</organization>
	  </author>

	  <date year="2010" />
	</front>
      </reference>

      <reference anchor="zoneinfo" target="http://www.twinsun.com/tz/tz-link.htm">
	<front>
	  <title>The tz database</title>

	  <author fullname="Public Domain">
	    <organization abbrev="Public">Public Domain</organization>
	  </author>

	  <date month="June" year="2011" />
	</front>
      </reference>

      <reference anchor="OAuth.Responses" target="http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html">
        <front>
	  <title>OAuth 2.0 Multiple Response Type Encoding Practices</title>

	  <author fullname="Breno de Medeiros" initials="B." role="editor" surname="de Medeiros">
	    <organization abbrev="Google">Google</organization>
	  </author>

	  <author fullname="Marius Scurtescu" initials="M." surname="Scurtescu">
	    <organization abbrev="Google">Google</organization>
	  </author>

	  <author fullname="Paul Tarjan" initials="P." surname="Tarjan">
	    <organization abbrev="Facebook"> Facebook</organization>
	  </author>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Microsoft">Microsoft</organization>
	  </author>

	  <date day="25" month="February" year="2014" />
        </front>
      </reference>

      <reference anchor="IANA.Language" target="http://www.iana.org/assignments/language-subtag-registry">
        <front>
          <title>Language Subtag Registry</title>
          <author>
            <organization>IANA</organization>
          </author>
	  <date/>
        </front>
      </reference>

      <reference anchor="CORS" target="http://www.w3.org/TR/access-control/">
        <front>
	  <title>Cross-Origin Resource Sharing</title>
	  <author fullname="Anne van Kesteren">
	    <organization abbrev="Opera">Opera Software ASA</organization>
	  </author>
	  <date day="27" month="July" year="2010"></date>
        </front>
      </reference>

      <reference anchor="IANA.JWT.Claims" target="http://www.iana.org/assignments/jwt">
        <front>
          <title>JSON Web Token Claims</title>
          <author>
            <organization>IANA</organization>
          </author>
	  <date/>
        </front>
      </reference>

      <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>

      <reference anchor="RFC20" target="http://www.rfc-editor.org/info/rfc20">
	<front>
	  <title>ASCII format for Network Interchange</title>
	  <author fullname="Vint Cerf" surname="Cerf" initials="V.">
	    <organization>University California Los Angeles (UCLA)</organization>
	  </author>
	  <date month="October" year="1969"/>
	</front>
	<seriesInfo name="STD" value="80"/>
	<seriesInfo name="RFC" value="20"/>
	<seriesInfo name="DOI" value="10.17487/RFC0020"/>
      </reference>

      <reference anchor="UNICODE" target="http://www.unicode.org/versions/latest/">
	<front>
	  <title abbrev="Unicode">The Unicode Standard</title>
	  <author>
	    <organization>The Unicode Consortium</organization>
	    <address />
	  </author>
	  <date />
	</front>
	<!--
	  Note that this reference is to the latest version of Unicode,
	  rather than to a specific release.  It is not expected that future changes in
	  the UNICODE specification will impact the syntax of JSON or the UTF-8 encoding.
	-->
      </reference>

    </references>
    <references title="Informative References">

      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4949"?>

      <reference anchor="OpenID.Basic" target="http://openid.net/specs/openid-connect-basic-1_0.html">
	<front>
	  <title>OpenID Connect Basic Client Implementer's Guide 1.0</title>

	  <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	    <organization abbrev="NAT.Consulting">NAT.Consulting</organization>
	  </author>

	  <author fullname="John Bradley" initials="J." surname="Bradley">
	    <organization abbrev="Yubico">Yubico</organization>
	  </author>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Microsoft">Microsoft</organization>
	  </author>

	  <author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
	    <organization abbrev="Google">Google</organization>
	  </author>

	  <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
	    <organization abbrev="VISA">VISA</organization>
	  </author>

	  <date day="24" month="July" year="2020"/>
	</front>
      </reference>

      <reference anchor="OpenID.Implicit" target="http://openid.net/specs/openid-connect-implicit-1_0.html">
	<front>
	  <title>OpenID Connect Implicit Client Implementer's Guide 1.0</title>

	  <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	    <organization abbrev="NAT.Consulting">NAT.Consulting</organization>
	  </author>

	  <author fullname="John Bradley" initials="J." surname="Bradley">
	    <organization abbrev="Yubico">Yubico</organization>
	  </author>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Microsoft">Microsoft</organization>
	  </author>

	  <author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
	    <organization abbrev="Google">Google</organization>
	  </author>

	  <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
	    <organization abbrev="VISA">VISA</organization>
	  </author>

	  <date day="24" month="July" year="2020"/>
	</front>
      </reference>

      <reference anchor="OpenID.RPInitiated" target="http://openid.net/specs/openid-connect-rpinitiated-1_0.html">
	<front>
	  <title>OpenID Connect Session Management 1.0</title>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Microsoft">Microsoft</organization>
	  </author>

	  <author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
	    <organization>Google</organization>
	  </author>

	  <author fullname="Naveen Agarwal" initials="N." surname="Agarwal">
	    <organization>Microsoft</organization>
	  </author>

	  <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	    <organization abbrev="NAT.Consulting">NAT.Consulting</organization>
	  </author>

	  <author fullname="John Bradley" initials="J." surname="Bradley">
	    <organization abbrev="Yubico">Yubico</organization>
	  </author>

	  <date day="7" month="August" year="2020" />
	</front>
      </reference>

      <reference anchor="OpenID.Session" target="http://openid.net/specs/openid-connect-session-1_0.html">
	<front>
	  <title>OpenID Connect Session Management 1.0</title>

	  <author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
	    <organization>Google</organization>
	  </author>

	  <author fullname="Naveen Agarwal" initials="N." surname="Agarwal">
	    <organization>Microsoft</organization>
	  </author>

	  <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	    <organization abbrev="NAT.Consulting">NAT.Consulting</organization>
	  </author>

	  <author fullname="John Bradley" initials="J." surname="Bradley">
	    <organization abbrev="Yubico">Yubico</organization>
	  </author>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Microsoft">Microsoft</organization>
	  </author>

	  <date day="7" month="August" year="2020"/>
	</front>
      </reference>

      <reference anchor="OpenID.FrontChannel" target="http://openid.net/specs/openid-connect-frontchannel-1_0.html">
	<front>
	  <title>OpenID Connect Front-Channel Logout 1.0</title>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Microsoft">Microsoft</organization>
	  </author>

	  <date day="7" month="August" year="2020" />
	</front>
      </reference>

      <reference anchor="OpenID.BackChannel" target="http://openid.net/specs/openid-connect-backchannel-1_0.html">
	<front>
	  <title>OpenID Connect Back-Channel Logout 1.0</title>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Microsoft">Microsoft</organization>
	  </author>

          <author fullname="John Bradley" initials="J." surname="Bradley">
            <organization abbrev="Yubico">Yubico</organization>
          </author>

	  <date day="7" month="August" year="2020" />
	</front>
      </reference>

      <reference anchor="OAuth.Post" target="http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html">
        <front>
	  <title>OAuth 2.0 Form Post Response Mode</title>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Microsoft">Microsoft</organization>
	  </author>

	  <author fullname="Brian Campbell" initials="B." surname="Campbell">
	    <organization abbrev="Ping Identity">Ping Identity</organization>
	  </author>

	  <date day="27" month="April" year="2015" />
        </front>
      </reference>

      <reference anchor="OpenID.2.0" target="http://openid.net/specs/openid-authentication-2_0.html">
	<front>
	  <title>OpenID Authentication 2.0</title>

	  <author fullname="OpenID Foundation">
	    <organization abbrev="OIDF">OpenID Foundation</organization>
	  </author>

	  <date day="5" month="December" year="2007" />
	</front>
      </reference>

      <reference anchor="OpenID.PAPE" target="http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html">
	<front>
	  <title abbrev="OpenID Provider Auth Policy Extension">OpenID Provider
	  Authentication Policy Extension 1.0</title>
	  <author fullname="David Recordon" initials="D.R" surname="Recordon">
	    <organization abbrev="Six Apart">Six Apart, Ltd.</organization>
	    <address>
	      <postal>
		<street>548 4th Street</street>
		<city>San Francisco</city>
		<region>CA</region>
		<code>94107</code>
		<country>USA</country>
	      </postal>
	      <email>david@sixapart.com</email>
	      <uri>http://www.sixapart.com/</uri>
	    </address>
	  </author>
	  <author fullname="Michael B. Jones" initials="M.J" surname="Jones">
	    <organization abbrev="Microsoft">Microsoft Corporation</organization>
	    <address>
	      <postal>
		<street>One Microsoft Way, Building 40/5138</street>
		<city>Redmond</city>
		<region>WA</region>
		<code>98052</code>
		<country>USA</country>
	      </postal>
	      <email>mbj@microsoft.com</email>
	      <uri>http://www.microsoft.com/</uri>
	    </address>
	  </author>
	  <author fullname="Johnny Bufu" initials="J.B" role="editor" surname="Bufu">
	    <organization>Independent</organization>
	    <address>
	      <email>johnny.bufu@gmail.com</email>
	      <uri></uri>
	    </address>
	  </author>
	  <author fullname="Jonathan Daugherty" initials="J.D" role="editor"
		  surname="Daugherty">
	    <organization>JanRain</organization>
	    <address>
	      <postal>
		<street>5331 SW Macadam Ave. #375</street>
		<city>Portland</city>
		<region>OR</region>
		<code>97239</code>
		<country>USA</country>
	      </postal>
	      <email>cygnus@janrain.com</email>
	      <uri>http://janrain.com/</uri>
	    </address>
	  </author>
	  <author fullname="Nat Sakimura" initials="N.S" surname="Sakimura">
	    <organization abbrev="NRI">Nomura Research Institute, Ltd.</organization>
	    <address>
	      <postal>
		<street>Marunouchi Kitaguchi Building, 1-6-5 Marunouchi</street>
		<city>Chiyoda-ku</city>
		<region>Tokyo</region>
		<code>100-0005</code>
		<country>Japan</country>
	      </postal>
	      <email>n-sakimura@nri.co.jp</email>
	      <uri>http://www.nri.co.jp/</uri>
	    </address>
	  </author>
	  <date day="30" month="December" year="2008" />
	</front>
      </reference>

      <reference anchor="X.1252" target="http://www.itu.int/rec/dologin_pub.asp?lang=e&amp;id=T-REC-X.1252-201004-I!!PDF-E&amp;type=items">
        <front>
          <title>ITU-T Recommendation X.1252 -- Cyberspace security -- Identity management
	  -- Baseline identity management terms and definitions</title>

          <author fullname="International Telecommunication Union">
            <organization abbrev="ITU-T">International Telecommunication Union</organization>
          </author>

          <date month="November" year="2010" />
        </front>
        <seriesInfo name="ITU-T" value="X.1252" />
      </reference>

      <reference anchor="JWK.Thumbprint" target="http://tools.ietf.org/html/rfc7638">
	<front>
	  <title>JSON Web Key (JWK) Thumbprint</title>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization>Microsoft</organization>
	    <address>
	      <email>mbj@microsoft.com</email>
	      <uri>http://self-issued.info/</uri>
	    </address>
	  </author>

	  <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	    <organization abbrev="NRI">Nomura Research Institute</organization>
	    <address>
	      <email>n-sakimura@nri.co.jp</email>
	      <uri>http://nat.sakimura.org/</uri>
	    </address>
	  </author>

	  <date month="September" year="2015" />
	</front>

	<seriesInfo name="RFC" value="7638"/>
	<seriesInfo name="DOI" value="10.17487/RFC7638"/>
      </reference>

    </references>

    <section anchor="AuthorizationExamples" title="Authorization Examples">

      <t>
	The following are non-normative examples of Authorization Requests with 
	different <spanx style="verb">response_type</spanx> values and their responses 
	(with line wraps within values for display purposes only):
      </t>

      <section anchor="codeExample" title="Example using response_type=code">

	<figure>
	  <artwork><![CDATA[
  GET /authorize?
    response_type=code
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile%20email
    &nonce=n-0S6_WzA2Mj
    &state=af0ifjsldkj HTTP/1.1
  Host: server.example.com

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
    &state=af0ifjsldkj
    ]]></artwork>
	</figure>
      </section>

      <section anchor="id_tokenExample" title="Example using response_type=id_token">

	<figure>
	  <artwork><![CDATA[
  GET /authorize?
    response_type=id_token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile%20email
    &nonce=n-0S6_WzA2Mj
    &state=af0ifjsldkj HTTP/1.1
  Host: server.example.com

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.
    ewogImlzcyI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsCiAic3ViIjog
    IjI0ODI4OTc2MTAwMSIsCiAiYXVkIjogInM2QmhkUmtxdDMiLAogIm5vbmNlIjog
    Im4tMFM2X1d6QTJNaiIsCiAiZXhwIjogMTMxMTI4MTk3MCwKICJpYXQiOiAxMzEx
    MjgwOTcwLAogIm5hbWUiOiAiSmFuZSBEb2UiLAogImdpdmVuX25hbWUiOiAiSmFu
    ZSIsCiAiZmFtaWx5X25hbWUiOiAiRG9lIiwKICJnZW5kZXIiOiAiZmVtYWxlIiwK
    ICJiaXJ0aGRhdGUiOiAiMDAwMC0xMC0zMSIsCiAiZW1haWwiOiAiamFuZWRvZUBl
    eGFtcGxlLmNvbSIsCiAicGljdHVyZSI6ICJodHRwOi8vZXhhbXBsZS5jb20vamFu
    ZWRvZS9tZS5qcGciCn0.
    NTibBYW_ZoNHGm4ZrWCqYA9oJaxr1AVrJCze6FEcac4t_EOQiJFbD2nVEPkUXPuM
    shKjjTn7ESLIFUnfHq8UKTGibIC8uqrBgQAcUQFMeWeg-PkLvDTHk43Dn4_aNrxh
    mWwMNQfkjqx3wd2Fvta9j8yG2Qn790Gwb5psGcmBhqMJUUnFrGpyxQDhFIzzodmP
    okM7tnUxBNj-JuES_4CE-BvZICH4jKLp0TMu-WQsVst0ss-vY2RPdU1MzL59mq_e
    Kk8Rv9XhxIr3WteA2ZlrgVyT0cwH3hlCnRUsLfHtIEb8k1Y_WaqKUu3DaKPxqRi6
    u0rN7RO2uZYPzC454xe-mg
    &state=af0ifjsldkj
]]></artwork>
	</figure>

	<t>
	  The value of the <spanx style="verb">id_token</spanx> parameter is the ID Token,
	  which is a signed JWT,
	  containing three base64url-encoded segments separated by period ('.') characters.
	  The first segment represents the JOSE Header.
	  Base64url decoding it will result in the following set of Header Parameters:
	</t>
	<figure>
	  <artwork><![CDATA[
  {"kid":"1e9gdk7","alg":"RS256"}
]]></artwork>
	</figure>
	<t>
	  The <spanx style="verb">alg</spanx> value represents the algorithm
	  that was used to sign the JWT, in this case
	  <spanx style="verb">RS256</spanx>, representing RSASSA-PKCS1-v1_5 using SHA-256.
	  The <spanx style="verb">kid</spanx> value is a key identifier used
	  in identifying the key to be used to verify the signature.
	  If the <spanx style="verb">kid</spanx> value is unknown to the RP,
	  it needs to retrieve the contents of the OP's JWK Set again
	  to obtain the OP's current set of keys.
	</t>
	<figure>
	  <preamble>
	    The second segment represents the Claims in the ID Token. 
	    Verifying and decoding the ID Token will yield the following Claims:
	  </preamble>
	  <artwork><![CDATA[
  {
   "iss": "https://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "gender": "female",
   "birthdate": "0000-10-31",
   "email": "janedoe@example.com",
   "picture": "http://example.com/janedoe/me.jpg"
  }
]]></artwork>
	</figure>
	<t>
	  The third segment represents the ID Token signature,
	  which is verified as described in <xref target="JWS"/>.
	</t>
      </section>

      <section anchor="id_token-tokenExample" title="Example using response_type=id_token&nbsp;token">

	<figure>
	  <artwork><![CDATA[
  GET /authorize?
    response_type=id_token%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile%20email
    &nonce=n-0S6_WzA2Mj
    &state=af0ifjsldkj HTTP/1.1
  Host: server.example.com

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
    &token_type=Bearer
    &id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.
    ewogImlzcyI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsCiAic3ViIjog
    IjI0ODI4OTc2MTAwMSIsCiAiYXVkIjogInM2QmhkUmtxdDMiLAogIm5vbmNlIjog
    Im4tMFM2X1d6QTJNaiIsCiAiZXhwIjogMTMxMTI4MTk3MCwKICJpYXQiOiAxMzEx
    MjgwOTcwLAogImF0X2hhc2giOiAiNzdRbVVQdGpQZnpXdEYyQW5wSzlSUSIKfQ.
    kdqTmftlaXg5WBYBr1wkxhkqCGZPc0k8vTiV5g2jj67jQ7XkrDamYx2bOkZLdZrp
    MPIzkdYB1nZI_G8vQGQuamRhJcEIt21kblGPZ-yhEhdkAiZIZLu38rChalDS2Mh0
    glE_rke5XXRhmqqoEFFdziFdnO3p61-7y51co84OEAZvARSINQaOWIzvioRfs4zw
    IFOaT33Vpxfqr8HDyh31zo9eBW2dSQuCa071z0ENWChWoPliK1JCo_Bk9eDg2uwo
    2ZwhsvHzj6TMQ0lYOTzufSlSmXIKfjlOsb3nftQeR697_hA-nMZyAdL8_NRfaC37
    XnAbW8WB9wCfECp7cuNuOg
    &state=af0ifjsldkj
]]></artwork>
	</figure>

	<figure>
	  <preamble>
	    Verifying and decoding the ID Token will yield the following Claims:
	  </preamble>
	  <artwork><![CDATA[
  {
   "iss": "https://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "at_hash": "77QmUPtjPfzWtF2AnpK9RQ"
  }
]]></artwork>
	</figure>
      </section>

      <section anchor="code-id_tokenExample" title="Example using response_type=code&nbsp;id_token">

	<figure>
	  <artwork><![CDATA[
  GET /authorize?
    response_type=code%20id_token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile%20email
    &nonce=n-0S6_WzA2Mj
    &state=af0ifjsldkj HTTP/1.1
  Host: server.example.com

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
    &id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.
    ewogImlzcyI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsCiAic3ViIjog
    IjI0ODI4OTc2MTAwMSIsCiAiYXVkIjogInM2QmhkUmtxdDMiLAogIm5vbmNlIjog
    Im4tMFM2X1d6QTJNaiIsCiAiZXhwIjogMTMxMTI4MTk3MCwKICJpYXQiOiAxMzEx
    MjgwOTcwLAogImNfaGFzaCI6ICJMRGt0S2RvUWFrM1BrMGNuWHhDbHRBIgp9.
    MRPihYtNIcwKTZ_mcMSPfreVytGR4jfl1Tzbv4tH5Jr4WqONs2lUWrIEpZ2joKbZ
    fAGlouAqwqSYpfR3FQYKYvdgnZ3kjIJ_5M4fAARXHVSciGyhfqB-OhDUMXSHzFHi
    GKNY9TKSgRfiXf_314WRujpqaDtj2uoXbppobYXvAZIxWtsOein0-t91LDS39EW4
    frNWAopKTBBi_XJPlpLVynWTDvNleEBP6UxIMgYJBKlqsP7RGfHTGk3ReXDacR7R
    GZlIVGa-0qRyDzvNqD7xfu9aYufUP0oBGqdBGgFVNmwJ7rmB0gdPtC2eJsXq9svC
    gBBfhRQZxhx1iLJjNc9nSw
    &state=af0ifjsldkj
]]></artwork>
	</figure>

	<figure>
	  <preamble>
	    Verifying and decoding the ID Token will yield the following Claims:
	  </preamble>
	  <artwork><![CDATA[
  {
   "iss": "https://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "c_hash": "LDktKdoQak3Pk0cnXxCltA"
  }
]]></artwork>
	</figure>
      </section>

      <section anchor="code-tokenExample" title="Example using response_type=code&nbsp;token">

	<figure>
	  <artwork><![CDATA[
  GET /authorize?
    response_type=code%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile%20email
    &nonce=n-0S6_WzA2Mj
    &state=af0ifjsldkj HTTP/1.1
  Host: server.example.com

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
    &access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
    &token_type=Bearer
    &state=af0ifjsldkj
]]></artwork>
	</figure>
      </section>

      <section anchor="code-id_token-tokenExample" title="Example using response_type=code&nbsp;id_token&nbsp;token">

	<figure>
	  <artwork><![CDATA[
  GET /authorize?
    response_type=code%20id_token%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile%20email
    &nonce=n-0S6_WzA2Mj
    &state=af0ifjsldkj HTTP/1.1
  Host: server.example.com

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
    &access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
    &token_type=Bearer
    &id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.
    ewogImlzcyI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsCiAic3ViIjog
    IjI0ODI4OTc2MTAwMSIsCiAiYXVkIjogInM2QmhkUmtxdDMiLAogIm5vbmNlIjog
    Im4tMFM2X1d6QTJNaiIsCiAiZXhwIjogMTMxMTI4MTk3MCwKICJpYXQiOiAxMzEx
    MjgwOTcwLAogImF0X2hhc2giOiAiNzdRbVVQdGpQZnpXdEYyQW5wSzlSUSIsCiAi
    Y19oYXNoIjogIkxEa3RLZG9RYWszUGswY25YeENsdEEiCn0.
    A2OhhJzbUNaCbNLqNaqetGLJoxB3ujVbq_HLYSOWgWCJ3-B__YxlqIg8gpeL0Vhv
    rWX0mwz7w_pGTRN4JdgsI0xAlT5fob1ZPnrazgonSyzaXcg2bgD896SsBSlG_8JX
    6JKaztXifn8k2gy65Me-sMyQrRF8xv_q1CeC871sZpMjJzy5nx65BTI17vcXjntZ
    HADv6o2CrHrEdHp8xSlnTLiiIqgDOmKlpkeqqOBK6dqa4rXZlSqMAUm1LYZmtb2D
    8sHvQsxTbWlBkX7VZaTSqMJ487s4ZIEea8Bw4KGVOntQue4VhBjBnQ4bQKhB_47D
    xlWpSyOWdy3cer_zxKrfvw
    &state=af0ifjsldkj
]]></artwork>
	</figure>

	<figure>
	  <preamble>
	    Verifying and decoding the ID Token will yield the following Claims:
	  </preamble>
	  <artwork><![CDATA[
  {
   "iss": "https://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "at_hash": "77QmUPtjPfzWtF2AnpK9RQ",
   "c_hash": "LDktKdoQak3Pk0cnXxCltA"
  }
]]></artwork>
	</figure>
      </section>

      <section anchor="ExampleRSAKey" title="RSA Key Used in Examples">

	<figure>
	  <preamble>
	    The following RSA public key, represented in JWK format, can be used to
	    validate the ID Token signatures in the above examples
	    (with line wraps within values for display purposes only):
	  </preamble>

	  <artwork><![CDATA[
  {
   "kty":"RSA",
   "kid":"1e9gdk7",
   "n":"w7Zdfmece8iaB0kiTY8pCtiBtzbptJmP28nSWwtdjRu0f2GFpajvWE4VhfJA
        jEsOcwYzay7XGN0b-X84BfC8hmCTOj2b2eHT7NsZegFPKRUQzJ9wW8ipn_aD
        JWMGDuB1XyqT1E7DYqjUCEOD1b4FLpy_xPn6oV_TYOfQ9fZdbE5HGxJUzeku
        GcOKqOQ8M7wfYHhHHLxGpQVgL0apWuP2gDDOdTtpuld4D2LK1MZK99s9gaSj
        RHE8JDb1Z4IGhEcEyzkxswVdPndUWzfvWBBWXWxtSUvQGBRkuy1BHOa4sP6F
        KjWEeeF7gm7UMs2Nm2QUgNZw6xvEDGaLk4KASdIxRQ",
   "e":"AQAB"
  }
]]></artwork>
	</figure>

<!-- The private key is archived here, but is not included in the specification output.
	<figure>
	  <preamble>
	    The following RSA private key, represented in JWK format, was used to
	    sign the ID Tokens in the above examples
	    (with line wraps within values for display purposes only):
	  </preamble>

	  <artwork><![CDATA[
  {"kty":"RSA",
   "kid":"1e9gdk7",
   "n":"w7Zdfmece8iaB0kiTY8pCtiBtzbptJmP28nSWwtdjRu0f2GFpajvWE4VhfJA
        jEsOcwYzay7XGN0b-X84BfC8hmCTOj2b2eHT7NsZegFPKRUQzJ9wW8ipn_aD
        JWMGDuB1XyqT1E7DYqjUCEOD1b4FLpy_xPn6oV_TYOfQ9fZdbE5HGxJUzeku
        GcOKqOQ8M7wfYHhHHLxGpQVgL0apWuP2gDDOdTtpuld4D2LK1MZK99s9gaSj
        RHE8JDb1Z4IGhEcEyzkxswVdPndUWzfvWBBWXWxtSUvQGBRkuy1BHOa4sP6F
        KjWEeeF7gm7UMs2Nm2QUgNZw6xvEDGaLk4KASdIxRQ",
   "e":"AQAB",
   "d":"N49U-WaWoPlw6LKVX2lN4HtYT9fx_sg9c8rWwev3EfEUi7j2xPGxiOMZ7x23
        v1wrbPIMtNfmTnOu1mSMVftiuc8-3KDS1sbqb-o_UEiA3YvSahS1RAkyRmwo
        DPwQozaLe4nNz87QXvjIwNPR4GMCe5oaQuQoh5l5m6ATzU-0c-NBevJY9HnH
        KF8C8lcQhdb0iaNahwNGR8XTVqZmnX0JydxSj2q5co5riguC1nMZbQs1mdQ_
        PRMCnmum3doFoqdvLd3VM58fBiLRmcfBn5CUcYfQxrF0kQqiTH99JIDGDr2h
        efDNIBDcPru1c8OEFZKLWHumwSxruwLvOgygGpYToQ",
   "p":"80AByCAy81oPRqrzFAjPZVBmu_jWrgoft4VRSvpwfZfjB2_JioXm9EEIR9hu
        foX9e7bYdF-SkYA_JOES9OJ4Tr0DMT8T13hoEarjNJsZGYY8pEgh0-pA-q_z
        5MmB5fwVtKJ5F3eDO-cvnVHVqFpvZDRwzZaU4-NzWGGTJvhs4Fk",
   "q":"zfh8P5XNE2FS4i7RBBrOM9eSkPuqhYGCSNIc7JzccQnLIvswnH5mYun0dQ-3
        sSS78MDvFzkMaH3Sggha2V94hb2szWzvb5pqdrTFPL_hSm8Fl_U0H1eR9FdY
        i5Ak7crjVdAfSeVufpOcZI372L6yi_Vk61LU_bI4x5ucn4t1ms0",
   "dp":"b3uiVWoMb-OSpLyscz4mbzSOIRBGs7UIHEAJpedpruXxsvLU15vO4Zr8hJD
        48xvNtOl0AsHalrzEM87DtWAl61BNKkDSgyo36AD96Jo8wqn3GQPGHS17Yml
        Jyk1gL1t9RzA_dzXa-5VVCTD8TxBDhRVTraWZz2fq8VKm8nFg1OE",
   "dq":"Qipp149K0sf39Tru4C-wQA0nQzXlYH_rF3OP4R6-3f00aWdiBVPBllLrudM
        zwk83pK6F3-Lurn6E6kq-zIeT0vrMkS1GeYaUXs_RcKN_PwcNN_SIKu1ZsLG
        Ce0rx4gXEI-P4uSdf6H-IxPCrj8Qq3TUWl1YDn__pp43Asav-Op0",
   "qi":"yTgfxGsqdbULf6uKfzoBE0zmFFwnEFeigvkI1w6sy5FeZ65JEb4aNBx0D8z
        PvD8-rPuY_oEjYUuAr5tbtZRRqlkClcxdAwM3TjamXU1FKcLjmDdvt_dl1aM
        w9DXBYKadmrgxnLgI3vkFNHzQxClXwAGRPvWWbGBqL1V5uj8O82o"
  }
]]></artwork>
	</figure>
-->
      </section>

    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>As a successor version of OpenID, this specification heavily relies
      on ideas explored in <xref target="OpenID.2.0">OpenID Authentication 2.0</xref>. Please
      refer to Appendix C of OpenID Authentication 2.0 for the full list of
      the contributors for that specification.</t>

      <t>
	In addition, the OpenID Community would like to thank the following people for
	their contributions to this specification:
      </t>
      <t>
	<list style="empty">
	  <t>Naveen Agarwal (Naveen.Agarwal@microsoft.com), Microsoft (was at Google)</t>
	  <t>Amanda Anganes (aanganes@mitre.org), MITRE</t>
	  <t>Casper Biering (cb@peercraft.com), Peercraft</t>
	  <t>John Bradley (ve7jtb@ve7jtb.com), Yubico (was at Ping Identity)</t>
	  <t>Tim Bray (tbray@textuality.com), Independent (was at Google)</t>
	  <t>Johnny Bufu (johnny.bufu@gmail.com), Independent (was at Janrain)</t>
	  <t>Brian Campbell (bcampbell@pingidentity.com), Ping Identity</t>
	  <t>Blaine Cook (romeda@gmail.com), Independent</t>
	  <t>Breno de Medeiros (breno@google.com), Google</t>
	  <t>Pamela Dingle (Pamela.Dingle@microsoft.com), Microsoft (was at Ping Identity)</t>
	  <t>Vladimir Dzhuvinov (vladimir@connect2id.com), Connect2id (was at Nimbus Directory Services)</t>
	  <t>George Fletcher (george.fletcher@corp.aol.com), AOL</t>
	  <t>Roland Hedberg (roland@catalogix.se), Independent (was at University of Ume&aring;)</t>
	  <t>Ryo Ito (ryo.ito@mixi.co.jp), mixi, Inc.</t>
	  <t>Edmund Jay (ejay@mgi1.com), Illumila</t>
	  <t>Michael B. Jones (mbj@microsoft.com), Microsoft</t>
	  <t>Torsten Lodderstedt (torsten@lodderstedt.net), yes.com (was at Deutsche Telekom)</t>
	  <t>James Manger (James.H.Manger@team.telstra.com), Telstra</t>
	  <t>Nov Matake (nov@matake.jp), Independent</t>
	  <t>Chuck Mortimore (charliemortimore@gmail.com), VISA (was at Salesforce)</t>
	  <t>Anthony Nadalin (tonynad@microsoft.com), Microsoft</t>
	  <t>Hideki Nara (hdknr@ic-tact.co.jp), Tact Communications</t>
	  <t>Axel Nennker (axel.nennker@telekom.de), Deutsche Telekom</t>
	  <t>David Recordon (recordond@gmail.com), Independent (was at Facebook)</t>
	  <t>Justin Richer (justin@bspk.io), Bespoke Engineering (was at MITRE)</t>
	  <t>Nat Sakimura (nat@nat.consulting), NAT.Consulting (was at NRI)</t>
	  <t>Luke Shepard (luke@lukeshepard.com), Facebook</t>
	  <t>Andreas &Aring;kre Solberg (andreas.solberg@uninett.no), UNINET</t>
	  <t>Paul Tarjan (paul@paultarjan.com), Facebook</t>
	</list>
      </t>
    </section>

    <section anchor="Notices" title="Notices">
      <t>Copyright (c) 2020 The OpenID Foundation.</t>
      <t>
	The OpenID Foundation (OIDF) grants to any Contributor, developer, 
	implementer, or other interested party a non-exclusive, royalty free, 
	worldwide copyright license to reproduce, prepare derivative works from, 
	distribute, perform and display, this Implementers Draft or 
	Final Specification solely for the purposes of (i) developing 
	specifications, and (ii) implementing Implementers Drafts and 
	Final Specifications based on such documents, provided that attribution 
	be made to the OIDF as the source of the material, but that such attribution 
	does not indicate an endorsement by the OIDF.
      </t>
      <t>
	The technology described in this specification was 
	made available from contributions from various sources, 
	including members of the OpenID Foundation and others.  
	Although the OpenID Foundation has taken steps to help ensure 
	that the technology is available for distribution, it takes 
	no position regarding the validity or scope of any intellectual 
	property or other rights that might be claimed to pertain to 
	the implementation or use of the technology described in 
	this specification or the extent to which any license under 
	such rights might or might not be available; neither does it 
	represent that it has made any independent effort to identify 
	any such rights.  The OpenID Foundation and the contributors 
	to this specification make no (and hereby expressly disclaim any) 
	warranties (express, implied, or otherwise), including implied 
	warranties of merchantability, non-infringement, fitness for 
	a particular purpose, or title, related to this specification, 
	and the entire risk as to implementing this specification is 
	assumed by the implementer.  The OpenID Intellectual 
	Property Rights policy requires contributors to offer 
	a patent promise not to assert certain patent claims against 
	other contributors and against implementers.  The OpenID Foundation invites 
	any interested party to bring to its attention any copyrights, 
	patents, patent applications, or other proprietary rights 
	that may cover technology that may be required to practice 
	this specification.
      </t>
    </section>

    <section anchor="History" title="Document History">
      <t>[[ To be removed from the approved errata ]]</t>

      <t>
	-27
        <list style="symbols">
	  <t>
	    Fixed #1087 - Insufficient description of <spanx style="verb">id_token_hint</spanx> processing and validation.
	  </t>
	</list>
      </t>

      <t>
	-26
        <list style="symbols">
	  <t>
	    Fixed #1085 - Split RP-Initiated Logout into its own specification.
	  </t>
	  <t>
	    Updated affiliations and acknowledgements.
	  </t>
	</list>
      </t>

      <t>
	-25
        <list style="symbols">
	  <t>
	    Fixed #972 - Clarified nonce requirement in hybrid authentication request.
	  </t>
	  <t>
	    Fixed #997 - Incorrect reference in Section 15.2.
	  </t>
	  <t>
	    Fixed #970 - ID Token acr claim incorrectly specifies the level 0 of assurance.
	  </t>
	  <t>
	    Fixed #982 - Error in JWT claim definitions for client authentication.
	  </t>
	  <t>
	    Fixed #985 - Noted that the token_type value is case insensitive.
	  </t>
	  <t>
	    Fixed #990 - UserInfo Error Response Example missing "Bearer" auth-scheme.
	  </t>
	  <t>
	    Fixed #986 - Softening the 512 ASCII characters restriction.
	  </t>
	  <t>
	    Fixed #993 - How to treat a zero max_age request parameter?
	  </t>
	  <t>
	    Fixed #994 - Definition of country value within address claim.
	  </t>
	  <t>
	    Fixed #975 - Added additional related specifications.
	  </t>
	  <t>
	    Fixed #996 - Explicitly Ban 307 as the authorization response redirect.
	  </t>
	  <t>
	    Fixed #998 - Reconciled subject_types_supported descriptions.
	  </t>
	  <t>
	    Fixed #999 - Clarified requirements when invalid Redirection URI supplied.
	  </t>
	  <t>
	    Fixed #1002 - Clarified meaning of "exp" claim in the ID Token.
	  </t>
	  <t>
	    Fixed #1005 - Clarify "left truncated SHA-2 hash" in section on symmetric encryption.
	  </t>
	  <t>
	    Fixed #1006 - Clarify text in Third Party Initiated Login.
	  </t>
	  <t>
	    Fixed #1018 - Missing "sub" in examples of aggregated and distributed claims.
	  </t>
	</list>
      </t>

      <t>
	-24
        <list style="symbols">
	  <t>
	    JWK Thumbprint is now RFC 7638.
	  </t>
	  <t>
	    Allowed signed request objects to be referenced by non-https URLs.
	  </t>
	</list>
      </t>

      <t>
	-23
        <list style="symbols">
	  <t>
	    Referenced completed RFCs.
	  </t>
	  <t>
	    Added missing URLs in references.
	  </t>
	  <t>
	    Removed compatibility note about Google issuer value.
	  </t>
	  <t>
	    Fixed issue #972 - Nonce requirement in hybrid auth request.
	  </t>
	  <t>
	    Corrected a typo in the spelling of self-issued.me.
	  </t>
	  <t>
	    Changed instances of http://server.example.com to https://server.example.com.
	  </t>
	  <t>
	    Changed to use "Cache-Control: no-cache, no-store" and "Pragma: no-cache" in examples.
	  </t>
	  <t>
	    Tracked terminology changes made in the referenced IETF specs since errata set 1.
	  </t>
          <t>
            Updated the RFC 2616 references to RFC 7230, RFC 7231, or RFC 7234, as appropriate.
          </t>
	</list>
      </t>

      <t>
	-22
        <list style="symbols">
	  <t>
	    Final specification incorporating errata set 1.
	  </t>
	</list>
      </t>

    </section>

  </back>
</rfc>