openid-connect-implicit-1_0.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml.resource.org/authoring/rfc2629.dtd">
<rfc category="std" docName="openid-connect-implicit-1_0" ipr="trust200902">

  <?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 Implicit Client Guide 1.0">OpenID Connect
    Implicit Client Implementer's Guide 1.0 - draft 14</title>

    <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
      <organization abbrev="NRI">Nomura Research Institute, Ltd.</organization>
      <address>
        <email>n-sakimura@nri.co.jp</email>
        <uri>http://nat.sakimura.org/</uri>
      </address>
    </author>

    <author fullname="John Bradley" initials="J." surname="Bradley">
      <organization abbrev="Ping Identity">Ping Identity</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="Salesforce">Salesforce</organization>
      <address>
        <email>cmortimore@salesforce.com</email>
        <uri>https://twitter.com/cmort</uri>
      </address>
    </author>

    <date day="18" month="December" year="2013" />

    <workgroup>OpenID Connect Working Group</workgroup>

    <abstract>
      <t>
        OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである.
        このプロトコルは, Client が Authorization Server の認証結果に基づいて End-User のアイデンティティを検証することを可能にする.
        また同時に End-User の必要最低限のプロフィール情報を, 相互運用可能かつ RESTful な形で取得することも可能にする.
      </t>
      <!--
      <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>
        本ドキュメント OpenID Connect Implicit Client Implementer's Guide 1.0 は,
        OpenID Connect Core 1.0 仕様のサブセットであり,
        OAuth 2.0 Implicit Flowを利用して Webベースの Relying Party
        を実装する際に読みやすいように構成されている.
        本仕様は Core 仕様と重複したコンテンツを含んでいるが, それは実装者が本仕様を読むだけで OAuth Implicit Flow を利用した Relying Party を実装できるよう意図したものである.
      </t>
      <!--
      <t>
        This OpenID Connect Implicit Client Implementer's Guide 1.0 contains a subset of the
        OpenID Connect Core 1.0 specification
        that is designed to be easy to read and implement for basic
        Web-based Relying Parties using the
        OAuth 2.0 Implicit Flow.
        This specification intentionally duplicates content from the Core
        specification to provide a self-contained implementer's guide for basic
        Web-based Relying Parties using the
        OAuth Implicit Flow.
      </t>
      -->
      <t>
        OpenID Provider および Web ベース以外のアプリケーションの実装者は, Core 仕様を参照のこと.
      </t>
      <!--
      <t>
        OpenID Providers and non-Web-based applications
        should instead consult the Core specification.
      </t>
      -->
    </abstract>
  </front>

  <middle>

    <section anchor="Introduction" title="Introduction">

      <t>
        本ドキュメント OpenID Connect Implicit Client Implementer's Guide 1.0 は,
        <xref target="OpenID.Core">OpenID Connect Core 1.0</xref> 仕様のサブセットであり,
        OAuth 2.0 <xref target="RFC6749"/> Implicit Flowを利用して Webベースの Relying Party
        を実装する際に読みやすいように構成されている.
        本仕様は Core 仕様と重複したコンテンツを含んでいるが, それは実装者が本仕様を読むだけで OAuth Implicit Flow を利用した Relying Party を実装できるよう意図したものである.
        本実装者ガイドと OpenID Connect Core 仕様の間に齟齬がある場合は, Core 仕様を優先する.
      </t>
      <!--
      <t>
        This OpenID Connect Implicit Client Implementer's Guide 1.0 contains a subset of the
        <xref target="OpenID.Core">OpenID Connect Core 1.0</xref> specification
        that is designed to be easy to read and implement for basic
        Web-based Relying Parties using the
        OAuth <xref target="RFC6749"/> Implicit Flow.
        This specification intentionally duplicates content from the Core
        specification to provide a self-contained implementer's guide for basic
        Web-based Relying Parties using the
        OAuth Implicit Flow.
        Should there be any conflicts between the contents of this implementer's guide
        and the OpenID Connect Core specification, the latter takes precedence.
      </t>
      -->
      <t>
        OAuth <spanx style="verb">authorization_code</spanx> grant typeを利用する
        Webベース Relying Partyを実装する場合には,
        <xref target="OpenID.Basic">OpenID Connect Basic Client Implementer's Guide 1.0</xref>
        を参照のこと.
        OpenID Provider および Web ベース以外のアプリケーションの実装者は, Core 仕様を参照のこと.
        本ガイドは OpenID Provider および Web ベース以外のアプリケーションに関する Implementation Considerations および Security Considerations を省略している.
      </t>
      <!--
      <t>
        See the
        <xref target="OpenID.Basic">OpenID Connect Basic Client Implementer's Guide 1.0</xref>
        for a related guide for basic
        Web-based Relying Parties using the
        OAuth <spanx style="verb">authorization_code</spanx> grant type.
        OpenID Providers and non-Web-based applications
        should instead consult the Core specification.
        This guide omits implementation and security
        considerations for OpenID Providers and non-Web-based applications.
      </t>
      -->

      <t>
        OpenID Connect のベースとなる <xref target="RFC6749">OAuth 2.0 Authorization Framework</xref> と <xref target="RFC6750">OAuth 2.0 Bearer Token Usage</xref> は, 3rd-party アプリケーションが HTTP リソースへの限定的アクセス権を取得および行使するための全般的フレームワークを提供している.
        これらはリソースアクセスのための Access Token を取得および行使する方法は定義するが, アイデンティティ情報を提供するための標準的手段は定義しない.
        とりわけ, OAuth 2.0 のプロファイリングを行わずに End-User の認証に必要な情報を提供することは不可能である.
        本ドキュメント読者は上記2つの仕様を理解していることが期待される.
      </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 は OAuth 2.0 認可プロセスを拡張し, 認証目的で利用できるようにする.
        本拡張を利用する場合, Client は <spanx style="verb">openid</spanx> scope を指定して Authorization Request を送信する.
        本拡張を利用した Authorization Request は, Authentication Request と呼ばれる.
      </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.
        An Authorization Request using these extensions
        is called an Authentication Request.
      </t>
      -->
      <t>
        認証結果は ID Token (<xref target="IDToken"/> 参照) と呼ばれる <xref target="JWT">JSON Web Token (JWT)</xref> として返される.
        OpenID Connect をサポートする OAuth 2.0 Authentication Server は, OpenID Provider (OP) とも呼ばれる.
        OpenID Connect を利用する OAuth 2.0 Client は Relying Party (RP) とも呼ばれる.
      </t>
      <!--
      <t>
        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>
        本ドキュメントでは, Relying Party は Authorization Endpoint, Token Endpoint 等を含む OpenID Provider の設定情報を既に得ているものとする.
        これらの情報は通常 <xref target="OpenID.Discovery">OpenID Connect Discovery 1.0</xref> にある Discovery を通じて得られるが, その他の手段で得られることもある.
      </t>
      <!--
      <t>
        This specification assumes that the Relying Party has already obtained
        configuration information about the OpenID Provider, including its
        Authorization Endpoint location.
        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>
        また同様に, Relying Party は OpenID Provider 利用に必要なクレデンシャルを取得し, OP 利用に必要な情報を登録しているものとする.
        これの処理は通常 <xref target="OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</xref> にある Dynamic Registration を通じて行われるが, その他の手段で行われることもある.
      </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>本ドキュメント中の "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" の意味するところは, <xref target="RFC2119"/> の定める通りである.</t>
        <!--
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref
        target="RFC2119"/>.</t>
        -->

        <t>
          本ドキュメントの .txt バージョンでは, 表記そのままで利用される値についてはクオートで囲んでいる.
          このような値をプロトコルメッセージ中で用いる場合, クオートを含めてはならない (MUST NOT).
          HTML バージョンではクオートで囲う代わりに <spanx style="verb">this fixed-width font</spanx> を用いる.
        </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>
          <xref target="JWS">JSON Web Signature (JWS)</xref> を用いる場合, シリアライゼーションには JWS Compact Serialization を用いる.
          JWS JSON Serialization は利用しない.
        </t>
        <!--
        <t>
          All uses of <xref target="JWS">JSON Web Signature (JWS)</xref>
          data structures in this specification utilize
          the JWS Compact Serialization;
          the JWS JSON Serialization is not used.
        </t>
        -->
        <t>
          本ドキュメント中の RFC 2119 に定義されるキーワードが OpenID Provider の挙動に言及する場合, それはあくまで Client 実装者が OpenID Provider の挙動を理解しやすいように用いられているに過ぎない.
        </t>
        <!--
        <t>
          When the RFC 2119 language applies to the behavior of OpenID Providers,
          it is in this specification for explanatory value to help Client
          implementers understand the expected behavior of OpenID Providers.
        </t>
        -->
      </section>

      <section anchor="Terminology" title="Terminology">
        <t>
          本ドキュメントでは,
          <xref target="RFC6749">OAuth 2.0</xref> で定義された "Access Token", "Authorization Code",
          "Authorization Endpoint", "Authorization Grant", "Authorization Server",
          "Client", "Client Identifier", "Client Secret",
          "Protected Resource", "Redirection URI", "Refresh Token",
          "Resource Owner", "Resource Server", "Response Type", および "Token Endpoint",
          <xref target="JWT">JSON Web Token (JWT)</xref> で定義された "Claim Name", "Claim Value", および "JSON Web Token (JWT)",
          <xref target="RFC2616">RFC 2616</xref> で定義された "User Agent" という用語を用いる.
        </t>
        <!--
        <t>
          This specification uses the terms "Access Token", "Authorization Code",
          "Authorization Endpoint", "Authorization Grant", "Authorization Server",
          "Client", "Client Identifier", "Client Secret",
          "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", and "JSON Web Token (JWT)"
          defined by <xref target="JWT">JSON Web Token (JWT)</xref>,
          and the term "User Agent" defined by <xref target="RFC2616">RFC 2616</xref>.
        </t>
        -->
        <t>
          本ドキュメントはその他に以下の用語を用いる.
          <!--
          This specification also defines the following terms:
          -->
          <list style="hanging">
            <t hangText="Authentication">
              提示された Identity と実際の Entity が紐づいているという十分な確信を得るためのプロセス.
            </t>
            <!--
            <t hangText="Authentication">
              Process used to achieve sufficient confidence in the binding
              between the Entity and the presented Identity.
            </t>
            -->
            <t hangText="Authentication Request">
              OpenID Connect が定める拡張パラメータおよびスコープを利用して, Authorization Server に End-User の認証を要求する OAuth 2.0 Authorization Request.
              このとき Authorization Server は OpenID Connect Provider, Client は OpenID Connect Relying Party となる.
            </t>
            <!--
            <t hangText="Authentication Request">
              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="Claim">
              Entity に関する情報の部分集合.
            </t>
            <!--
            <t hangText="Claim">
              Piece of information asserted about an Entity.
            </t>
            -->
            <t hangText="Claims Provider">
              Entity の Claim を返すサーバー.
            </t>
            <!--
            <t hangText="Claims Provider">
              Server that can return Claims about an Entity.
            </t>
            -->
            <t hangText="End-User">
              一連のフローに参加する人間.
            </t>
            <!--
            <t hangText="End-User">
              Human participant.
            </t>
            -->
            <t hangText="Entity">
              あるコンテキストの中で識別される, 他と独立した個.
              End-User は Entity の一例.
            </t>
            <!--
            <t hangText="Entity">
              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="ID Token">
              Authentication イベントに関する Claim を含む <xref target="JWT">JSON Web Token (JWT)</xref>.
              その他の Claim を含むこともある (MAY).
            </t>
            <!--
            <t hangText="ID Token">
              <xref target="JWT">JSON Web Token (JWT)</xref> that contains Claims about the Authentication event.
              It MAY contain other Claims.
            </t>
            -->

            <t hangText="Identifier">
              あるコンテキスト中で Entity をユニークに特徴づける値.
            </t>
            <!--
            <t hangText="Identifier">
             Value that uniquely characterizes an Entity in a specific context.
            </t>
            -->

            <t hangText="Issuer">
              Claim を発行する Entity.
            </t>
            <!--
            <t hangText="Issuer">
              Entity that issues a set of Claims.
            </t>
            -->

            <t hangText="Issuer Identifier">
              検証可能な Issuer の識別子.
              Issuer Identifier は, 大文字小文字を区別する URL である.
              この URL は <spanx style="verb">https</spanx> スキーム, ホスト, そして任意でポート番号およびパス要素からなり, クエリーとフラグメント要素は含まない.
            </t>
            <!--
            <t hangText="Issuer Identifier">
              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="OpenID Provider (OP)">
              End-User を Authenticate できる OAuth 2.0 Authorization Server.
              End-User の Authentication イベントに関する Claim を Relying Party に提供する.
            </t>
            <!--
            <t hangText="OpenID Provider (OP)">
              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="Pairwise Pseudonymous Identifier (PPID)">
              ある Relying Party に対してのみ, ある Entity の識別子として提供される値.
              他の Relying Party には, 当該 PPID を当該 Entity と関連づけることはできない.
            </t>
            <!--
            <t hangText="Pairwise Pseudonymous Identifier (PPID)">
              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)">
              特定の人物に紐づき, 実際の人物の識別に用いることができる情報.
              もしくは特定の人物に直接および間接的にリンクされる可能性のある情報.
            </t>
            <!--
            <t hangText="Personally Identifiable Information (PII)">
              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)">
              OpenID Provider に End-User Authentication と Claim を要求する OAuth 2.0 Client.
            </t>
            <!--
            <t hangText="Relying Party (RP)">
              OAuth 2.0 Client application requiring End-User Authentication
              and Claims from an OpenID Provider.
            </t>
            -->
            <t hangText="Self-Issued OpenID Provider">
              私有の self-hosted な OpenID Providerであり, 自己署名つきの ID Token を発行するもの.
            </t>
            <!--
            <t hangText="Self-Issued OpenID Provider">
              Personal, self-hosted OpenID Provider that issues self-signed ID Tokens.
            </t>
            -->
            <t hangText="Subject Identifier">
              Issuer にとって局地的にユニークで再利用されることのない End-User 識別子.
              この値は Client に利用されることを想定する.
            </t>
            <!--
            <t hangText="Subject Identifier">
              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">
              Protected Resource のひとつ.
              Access Token を提示する Client に対して, Authorization Grant に従って End-User に関する情報を提供する.
            </t>
            <!--
            <t hangText="UserInfo Endpoint">
              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.
            </t>
            -->
            <t hangText="Validation">
              あるものごとの健全性および正当性を確立するためのプロセス.
            </t>
            <!--
            <t hangText="Validation">
              Process intended to establish the soundness or correctness of a construct.
            </t>
            -->
            <t hangText="Verification">
              ある事実や値の正確さを検査もしくは証明するためのプロセス.
            </t>
            <!--
            <t hangText="Verification">
              Process intended to test or prove the truth or accuracy of a fact or value.
            </t>
            -->
            <t hangText="Voluntary Claim">
              Client が End-User が要求するあるタスクを実行する際に, 有用ではあるが Essential ではないとを Client が指定した Claim.
            </t>
            <!--
            <t hangText="Voluntary Claim">
              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:
          上記の用語定義は本仕様が定めるところであり, 本仕様の実装においてはこれらの定義に従うこと.
          "Issuer Identifier" をはじめとして, 本仕様で大文字表記されている用語はすべて上記の定義に従う.
          仕様書読者は必ずこれらの用語定義に従うこと.
        </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>
        -->
      </section>

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

        <t>
          OpenID Connect プロトコルは, おおまかに言って以下のステップに従う.
        </t>
        <!--
        <t>The OpenID Connect protocol, in abstract, follows the following
        steps.</t>
        -->

        <t>
          <list style="numbers">
            <t>
              RP (Client) が OpenID Provider (OP) にリクエストを送る.
            </t>
            <!--
            <t>The RP (Client) sends a request to the OpenID Provider (OP).</t>
            -->

            <t>
              OP は End-User を認証し, 認可を受ける.
            </t>
            <!--
            <t>The OP authenticates the End-User and obtains authorization.</t>
            -->

            <t>
              OP は ID Token および (通常は) Access Token を返す.
            </t>
            <!--
            <t>The OP responds with an ID Token and usually an Access Token.</t>
            -->

            <t>
              RP は Access Token を添えて UserInfo Endpoint にリクエストを送る.
            </t>
            <!--
            <t>The RP can send a request with the Access Token to the UserInfo Endpoint.</t>
            -->

            <t>
              UserInfo Endpoint は End-User の Claim を返す.
            </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="ProtocolElements" title="Protocol Elements">
      <t>
        Authentication Requests は Authorization Code Flow, Implicit Flow および Hybrid Flow のいずれかのフローに従う.
        Authorization Code Flow は, Authorization Server と Client 自身との間でセキュアに Client Secret を管理できる Client 向けのフローである.
        それが不可能な Client は Implicit Flow を用いる.
        しかしながら, Client Secret をセキュアに保持できないにも関わらず, Refresh Token 取得のためにしばしば Native アプリケーションやその他の Client が Authorization Code flow を利用することもある.
        Hybrid Flow は Authorization Code Flow と Implicit Flow をあわせたものであり, Client が Authorization Server から直接 ID Token およびオプションで Access Token を受け取ることでレイテンシ低下を防ぎつつも, 後から Client が Token Endpoint にアクセスして各種トークン (特に Refresh Token) を取得できるようにするものである.
      </t>
      <!--
      <t>
        Authentication Requests can follow one of three paths:
        the Authorization Code Flow,
        the Implicit Flow, or
        the Hybrid Flow.
        The Authorization Code Flow is
        intended for Clients that can securely maintain a Client Secret between
        themselves and the Authorization Server, whereas the Implicit Flow is
        intended for Clients that cannot.
        However, the Authorization Code flow is sometimes also used by Native applications
        and other Clients in order to be able to obtain a Refresh Token,
        even when they cannot ensure the secrecy of the Client Secret value.
        The Hybrid Flow combines aspects of the Authorization Code Flow
        and the Implicit Flow.
        It enables Clients to obtain an ID Token optionally an Access Token with only
        one round trip to the Authorization Server, possibly minimizing latency,
        while still enabling Clients to later get tokens from the Token Endpoint
        &#45;&#45; especially a Refresh Token.
      </t>
      -->

      <t>
        このドキュメントは Implicit Flow を利用する Client に対して必要十分な情報のみを提供する.
      </t>
      <!--
      <t>
        This specification only provides information that is sufficient for
        basic Clients using the Implicit Flow.
      </t>
      -->

      <section anchor="ImplicitFlow" title="Implicit Flow">
        <t>Implicit Flow は以下のステップからなる.</t>
        <!--
        <t>The Implicit Flow consists of the following steps:</t>
        -->
        <t>
          <list style="numbers">
            <t>
              Client は必要なリクエストパラメータを含んだ Authentication Request を構築する.
            </t>
            <!--
            <t>Client prepares an Authentication Request containing the desired
            request parameters.</t>
            -->

            <t>
              Client は Authorization Server にリクエストを送信する.
            </t>
            <!--
            <t>Client sends the request to the Authorization Server.</t>
            -->

            <t>
              Authorization Server は End-User を認証する.
            </t>
            <!--
            <t>Authorization Server authenticates the End-User.</t>
            -->

            <t>
              Authorization Server は End-User の Consent/Authorization を取得する.
            </t>
            <!--
            <t>Authorization Server obtains End-User Consent/Authorization.</t>
            -->

            <t>
              Authorization Server は End-User を ID Token, およびもし要求されていれば Access Token とともに, Client に戻す.
            </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 はそれらのトークンを検証し, End-User の Subject Identifier を取得する.
            </t>
            <!--
            <t>Client validates the tokens and retrieves the End-User's
            Subject Identifier.</t>
            -->
          </list>
        </t>

        <section anchor="AuthenticationRequest" title="Client Prepares Authentication Request">
          <t>
            RP が End-User を Authenticate したい, もしくは End-User が既に Authenticated であるかどうか知りたい場合, Client は Authorization Endpoint に Authorization Request を送る.
          </t>
          <!--
          <t>
            When the RP wishes to Authenticate the End-User
            or determine whether the End-User is already Authenticated,
            the Client prepares an Authentication Request
            to be sent to the Authorization Endpoint.
          </t>
          -->
          <t>
            Authorization Endpoint との間の通信は TLS を利用しなければならない (MUST).
            TLS の詳細については <xref target="TLSRequirements"/> を参照のこと.
          </t>
          <!--
          <t>
            Communication with the Authorization Endpoint MUST utilize TLS.
            See <xref target="TLSRequirements"/> for more information on using TLS.
          </t>
          -->

          <t>
            Client は <xref target="RFC2616">RFC 2616</xref> に定義される HTTP <spanx style="verb">GET</spanx> もしくは HTTP <spanx style="verb">POST</spanx> を利用できる (MAY).
          </t>
          <!--
          <t>Clients MAY construct the request using the HTTP
          <spanx style="verb">GET</spanx> or the HTTP
          <spanx style="verb">POST</spanx> method as defined in
          <xref target="RFC2616">RFC 2616</xref>.</t>
          -->

          <t>
            HTTP <spanx style="verb">GET</spanx> を利用する場合, パラメータは <xref target="QuerySerialization"/> にある Query String Serialization を用いてシリアライズされる.
            HTTP <spanx style="verb">POST</spanx> を利用する場合, パラメータは <xref target="W3C.REC-html401-19991224"/> にある <spanx style="verb">application/x-www-form-urlencoded</spanx> フォーマットを用いてエンティティボディ中に含まれる.
          </t>
          <!--
          <t>If using the HTTP <spanx style="verb">GET</spanx> method, the
          parameters are serialized using
          the Query String Serialization, per <xref target="QuerySerialization"/>.
          If using the HTTP
          <spanx style="verb">POST</spanx> method, the request parameters are
          added to the HTTP request entity-body using the
          <spanx style="verb">application/x-www-form-urlencoded</spanx> format
          as defined by <xref target="W3C.REC-html401-19991224"/>.</t>
          -->

          <figure>
            <preamble>
              以下は Authorization Request URL の一例である.
              (改行は掲載上の都合による)
            </preamble>
            <!--
            <preamble>The following is a non-normative example of an
            Authentication Request URL
            (with line wraps within values for display purposes only):</preamble>
            -->

            <artwork><![CDATA[
  https://server.example.com/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
]]></artwork>
          </figure>

          <section anchor="RequestParameters" title="Request Parameters">

            <t>
              OpenID Connect は以下の OAuth 2.0 リクエストパラメータを利用する.
            </t>
            <!--
            <t>
              This subset of
              OpenID Connect uses the following OAuth 2.0 request parameters:
            </t>
            -->
            <t>
              <list style="hanging">
                <t hangText="response_type">
                  REQUIRED.
                  値は <spanx style="verb">id_token</spanx> および <spanx style="verb">token</spanx> を空白で区切ったリストである.
                  これにより, Authorization Endpoint から Access Token および ID Token の両方が返される.
                  詳細は <xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref> 参照.
                </t>
                <!--
                <t hangText="response_type">
                  REQUIRED.
                  This value consists of <spanx style="verb">id_token</spanx> and
                  <spanx style="verb">token</spanx>, as a space delimited list.
                  This requests that both an Access Token and an ID Token be returned
                  from the Authorization Endpoint, as specified in
                  <xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref>.
                </t>
                -->

                <t hangText="client_id">
                  REQUIRED.
                  Authorization Server における OAuth 2.0 Client Identifier の値.
                </t>
                <!--
                <t hangText="client_id">
                  REQUIRED.
                  OAuth 2.0 Client Identifier
                  valid at the Authorization Server.
                </t>
                -->

                <t hangText="scope">
                  REQUIRED.
                  OpenID Connect リクエストは scope に <spanx style="verb">openid</spanx> を含まねばならない (MUST).
                  OPTIONAL な scope としては,
                  <spanx style="verb">profile</spanx>,
                  <spanx style="verb">email</spanx>,
                  <spanx style="verb">address</spanx>,
                  <spanx style="verb">phone</spanx>,
                  および <spanx style="verb">offline_access</spanx> が定義されている.
                  それぞれの scope 値についての詳細は <xref target="Scopes"/> を参照のこと.
                </t>
                <!--
                <t hangText="scope">
                  REQUIRED.
                  OpenID Connect requests MUST contain the <spanx style="verb">openid</spanx> scope value.
                  OPTIONAL scope values of
                  <spanx style="verb">profile</spanx>,
                  <spanx style="verb">email</spanx>,
                  <spanx style="verb">address</spanx>,
                  <spanx style="verb">phone</spanx>,
                  and <spanx style="verb">offline_access</spanx>
                  are also defined.
                  See <xref target="Scopes"/> for more about the scope values defined by this specification.
                </t>
                -->

                <t hangText="redirect_uri">
                  REQUIRED.
                  レスポンスが返される Redirection URI.
                  この URI は, Client が OpenID Provider に対して事前に登録済みの Redirection URI のいずれかと完全一致しなければならない (MUST).
                  マッチングルールは <xref target="RFC3986"/> (Simple String Comparison) の Section 6.2.1 に従うこと.
                  Redirection URI は <spanx style="verb">http</spanx> スキーマを使用してはならない (MUST NOT).
                  ただし, Client がネイティブアプリケーションである場合は,
                  <spanx style="verb">http:</spanx> スキーマをホスト部
                  <spanx style="verb">localhost</spanx> と組み合わせて使うことができる (MAY).
                </t>
                <!--
                <t hangText="redirect_uri">
                  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).
                  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="state">
                  RECOMMENDED.
                  リクエストとコールバックの間で維持されるランダムな値.
                  一般的に Cross-Site Request Forgery (CSRF, XSRF) 対策の目的で利用される, ブラウザ Cookie と紐づく暗号論的にセキュアな値を取る.
                </t>
                <!--
                <t hangText="state">
                  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>
              本仕様は上記に加えて以下のリクエストパラメータを定義する.
            </t>
            <!--
            <t>
              This specification also defines the following request parameters:
            </t>
            -->

            <t>
              <list style="hanging">

                <t hangText="nonce">
                  REQUIRED.
                  Client セッションと ID Token を紐づける文字列であり, リプレイアタック対策に用いられる.
                  この値は Authentication Request で指定され, そのままの値で ID Token に含まれる.
                  <spanx style="verb">nonce</spanx> 値には, 推測不可能なように十分なエントロピーを持たせること (MUST).
                  この条件を満たすには, 暗号論的にセキュアな乱数を HTML5 ローカルストレージに保存し, その暗号論的ハッシュ値を <spanx style="verb">nonce</spanx> として利用するといった方法が考えられる.
                  この場合, ID Token に含まれて返される <spanx style="verb">nonce</spanx> 値をローカルストレージに保存した値のハッシュ値と比較することで, 第三者によるリプレイアタックを検知することができる.
                </t>
                <!--
                <t hangText="nonce">
                  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.
                  One method to achieve this is to store a cryptographically random value
                  in HTML5 local storage 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 value in local storage
                  to detect ID Token replay by third parties.
                </t>
                -->

                <t hangText="display">
                  OPTIONAL.
                  Authorization Server が認証および同意のためのユーザーインタフェースを End-User にどのように表示するかを指定するための ASCII 値.
                  以下の値が定義されている.

                  <!--
                  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">
                      Authorization Server は認証および同意 UI を User Agent の全画面に表示すべきである (SHOULD).
                      display パラメータが指定されていない場合, この値がデフォルトとなる.
                    </t>
                    <!--
                    <t hangText="page">
                      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">
                      Authorization Server は認証および同意 UI を User Agent のポップアップウィンドウに表示すべきである (SHOULD).
                      User Agent のポップアップウィンドウはログインダイアログに適切なサイズで, 親ウィンドウ全体を覆うことのないようにすべきである.
                    </t>
                    <!--
                    <t hangText="popup">
                      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">
                      Authorization Server は認証および同意 UI をタッチインタフェースを持つデバイスに適した形で表示すべきである (SHOULD).
                    </t>
                    <!--
                    <t hangText="touch">
                      The Authorization Server SHOULD display the
                      authentication and consent UI consistent with a device that
                      leverages a touch interface.
                    </t>
                    -->

                    <t hangText="wap">
                      Authorization Server は認証および同意 UI を "feature phone" に適した形で表示すべきである (SHOULD).
                    </t>
                    <!--
                    <t hangText="wap">
                      The Authorization Server SHOULD display the
                      authentication and consent UI consistent with a "feature phone"
                      type display.
                    </t>
                    -->
                  </list>

                  Authorization Server は User Agent の機能を検知して適切な表示を行うようにしても良い (MAY).
                  <!--
                  The Authorization Server MAY also attempt to detect the capabilities
                  of the User Agent and present an appropriate display.
                  -->
                </t>

                <t hangText="prompt">
                  OPTIONAL.
                  Authorization Server が End-User に再認証および同意を再度要求するかどうか指定するための, スペース区切りの ASCII 文字列のリスト.
                  以下の値が定義されている.

                  <!--
                  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">
                      Authorization Server はいかなる認証および同意 UI をも表示してはならない (MUST NOT).
                      End-User が認証済でない場合, Client が要求する Claim 取得に十分な事前同意を取得済でない場合, またはリクエストを処理するために必要な何らかの条件を満たさない場合には, エラーが返される.
                      典型的なエラーコードは <spanx style="verb">login_required</spanx>, <spanx style="verb">interaction_required</spanx> である.
                      この prompt 値は現在の認証状態, 同意状況を確認する為にも利用できる.
                    </t>
                    <!--
                    <t hangText="none">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>.
                    This can be used as a
                    method to check for existing authentication and/or consent.</t>
                    -->

                    <t hangText="login">
                      Authorization Server は End-User を再認証するべきである (SHOULD).
                      再認証が不可能な場合はエラーを返す (MUST).
                      典型的なエラーコードは <spanx style="verb">login_required</spanx> である.
                    </t>
                    <!--
                    <t hangText="login">
                      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">
                      Authorization Server は Client にレスポンスを返す前に End-User に同意を要求するべきである (SHOULD).
                      同意要求が不可能な場合はエラーを返す (MUST).
                      典型的なエラーコードは <spanx style="verb">consent_required</spanx> である.
                    </t>
                    <!--
                    <t hangText="consent">
                      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">
                      Authorization Server は End-User にアカウント選択を促すべきである (SHOULD).
                      この prompt 値は, End-User が Authorization Server 上に複数アカウントを持っているとき, 現在のセッションに紐づくアカウントの中から一つを選択することを可能にする.
                      End-User によるアカウント選択が不可能な場合はエラーを返す (MUST).
                      典型的なエラーコードは <spanx style="verb">account_selection_required</spanx> である.
                    </t>
                    <!--
                    <t hangText="select_account">
                      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>

                  <spanx style="verb">prompt</spanx> パラメータは Client に対して, End-User のセッションがアクティブであることを確認したり, End-User にリクエストに対する注意を促すことを可能にする.
                  <spanx style="verb">none</spanx> がその他の値とともに用いられる場合はエラーとなる.
                  <!--
                  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">
                  OPTIONAL.
                  Authentication Age の最大値.
                  End-User が OP によって明示的に認証されてからの経過時間の最大許容値 (秒).
                  もし経過時間がこの値より大きい場合, OP は End-User を明示的に再認証しなければならない (MUST).
                  <spanx style="verb">max_age</spanx> が指定された場合, 発行される ID Token は <spanx style="verb">auth_time</spanx> Claim を含まねばならない (MUST).
                </t>
                <!--
                <t hangText="max_age">
                  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.
                  When <spanx style="verb">max_age</spanx> is used, the ID Token returned
                  MUST include an <spanx style="verb">auth_time</spanx> Claim Value.
                </t>
                -->

                <t hangText="ui_locales">
                  OPTIONAL.
                  End-User の選好する UI の表示言語および文字種.
                  スペース区切りの <xref target="RFC5646">BCP47</xref> 言語タグ値のリストとして表現され, 順序は選好順となる.
                  例えば "fr-CA fr en" という値が指定された場合, カナダで用いられるフランス語が第一選好となり, 次いで地域指定のないフランス語, そして英語と続く.
                  要求されたロケールがサポートされていない場合でも, OpenID Provider はエラーとするべきではない (SHOULD NOT).
                </t>
                <!--
                <t hangText="ui_locales">
                  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="claims_locales">
                  OPTIONAL.
                  End-User の選好する Claim の表示言語および文字種.
                  スペース区切りの <xref target="RFC5646">BCP47</xref> 言語タグ値のリストとして表現され, 順序は選好順となる.
                  要求されたロケールがサポートされていない場合でも, OpenID Provider はエラーとするべきではない (SHOULD NOT).
                </t>
                <!--
                <t hangText="claims_locales">
                  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>
                -->

                <t hangText="id_token_hint">
                  OPTIONAL.
                  Authorization Server が以前発行した ID Token.
                  Client が認証した End-User の現在もしくは過去のセッションに関するヒントとして利用される.
                  もしこの ID Token に紐づく End-User が認証済, もしくはこのリクエスト中で認証された場合, Authorization Server はポジティブレスポンスを返す.
                  さもなければ, Authorization Server はエラーを返す (SHOULD).
                  <spanx style="verb">prompt=none</spanx> を利用する場合は, 可能であれば <spanx style="verb">id_token_hint</spanx> を指定するべきであり (SHOULD), さもなければ <spanx style="verb">invalid_request</spanx> を返しても良い (MAY).
                  ただしサーバーはその場合可能な限りサクセスレスポンスを返すこと.
                  <spanx style="verb">id_token_hint</spanx> 利用時は, ID Token の audience に Authorization Server 自身が含まれている必要はない.
                </t>
                <!--
                <t hangText="id_token_hint">
                  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.
                  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 hangText="login_hint">
                  OPTIONAL.
                  Authorization Server に対する End-User ログイン識別子のヒントとして利用される.
                  RP が End-User に Email アドレス (もしくはその他の識別子) を要求し, それを Authorization Server にヒントとして送信することでヒントとする.
                  Discovery に利用された値をヒントの値として利用することを推奨する (RECOMMENDED).
                  この値は <spanx style="verb">phone_number</spanx> Claim に指定されるフォーマットに従った電話番号でもよい (MAY).
                  このパラメータを利用するか否かは OP の判断にゆだねる.
                </t>
                <!--
                <t hangText="login_hint">
                  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">
                  OPTIONAL.
                  Authentication Context Class Reference リクエスト値.
                  Authorization Server が認可リクエストを処理する際に要求される <spanx style="verb">acr</spanx> の値をスペース区切りで示した文字列.
                  認証処理が満たした Authentication Context Class は, <xref target="IDToken"/> に示す <spanx style="verb">acr</spanx> Claim Value として返される.
                  <spanx style="verb">acr</spanx> Claim はこのパラメータを用いることで Voluntary Claim としてリクエストされることになる.
                </t>
                <!--
                <t hangText="acr_values">
                  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>
                -->

                <t hangText="registration">
                  OPTIONAL.
                  Client が自身の情報を Self-Issued OP に提供するために使用される.
                  なお, 通常 Client は自身の情報を Dynamic Client Registration (<xref target="RegistrationParameter"/> 参照) を通じて OP に提供する.
                </t>
                <!--
                <t hangText="registration">
                  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>
                -->
              </list>
            </t>
          </section>
        </section>

        <section anchor="ImplicitRequest"
                 title="Client Sends Request to Authorization Server">
          <t>
            Client は Authorization Endpoint に HTTPS で Authentication Request を送信する.
          </t>
          <!--
          <t>Having constructed the Authentication Request, the Client sends it
          to the Authorization Endpoint using HTTPS.</t>
          -->

          <figure>
            <preamble>
              以下の例では Client が User Agent に HTTP 302 リダイレクトレスポンスを返し, User Agent に対して Authorization Endpoint に Authentication Request を送るよう指示している. (改行は掲載上の都合による)

              <!--
              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=id_token%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj
]]></artwork>
          </figure>

          <figure>
            <preamble>
              User Agent は上記の Client からの HTTP 302 リダイレクトレスポンスに従い, Authorization Server に以下のようなリクエストを送る. (改行は掲載上の都合による)
              <!--
              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=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="Authenticates" title="Authorization Server Authenticates End-User">

          <t>
            Authorization Server は, リクエストパラメータ値に基づき, End-User をログインさせたり既にログイン済みであることを検証する.
            End-User とのインタラクションが HTTP で行われる場合は, <xref target="TLSRequirements"/> に基づきTLS を用いること (MUST).
            認証手段の詳細については, 本仕様の定めるところではない.
          </t>
          <!--
          <t>
            The Authorization Server logs in the End-User or verifies whether
            the End-User is logged in, depending upon the request parameter values used.
            If interaction with the End-User occurs over an HTTP channel,
            it MUST use TLS, as per <xref target="TLSRequirements"/>.
            The exact authentication methods used are out of scope for this specification.
          </t>
          -->
        </section>

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

          <t>
            Authorization Server は要求された Claim に対する認可結果を得る.
            認可取得には, End-User が何に同意をしようとしているのかを明示する同意ダイアログを用いることもあれば, その他の何らかの手段 (事前の管理者による同意等) を用いることもあろう.
          </t>
          <!--
          <t>The Authorization Server obtains an authorization decision
          for the requested Claims. This can done by presenting the End-User
          with a dialogue that enables the End-User to recognize what is being
          consenting to and grant consent or by establishing consent via
          other means (for example, via previous administrative consent).</t>
          -->

          <t>
            <spanx style="verb">openid</spanx> scope 値は, その OAuth 2.0 リクエストが OpenID Connect リクエストであることを宣言する.
            その他の scope 値の利用は任意である (OPTIONAL).
          </t>
          <!--
          <t>
            The <spanx style="verb">openid</spanx> scope value declares
            that this OAuth 2.0 request is an OpenID Connect request.
            Use of all other scope values is OPTIONAL.
          </t>
          -->
        </section>

        <section anchor="ImplicitResponse"
                 title="Authorization Server Sends End-User Back to Client">

          <t>
            認可結果が得られると, Authorization Server はサクセスレスポンスまたはエラーレスポンスを返す.
          </t>
          <!--
          <t>Once the authorization is determined, the Authorization Server
          returns a successful response or an error response.</t>
          -->

          <section anchor="ImplicitOK" title="End-User Grants Authorization">

            <t>
              End-User がアクセス権要求を承認した場合, Authorization Server は Access Token を発行し, <xref target="RFC6749">OAuth 2.0</xref> の Section 4.2.2 および <xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref> に従い, 以下のパラメータを Redirection URI のフラグメント部に <spanx style="verb">application/x-www-form-urlencoded</spanx> フォーマットで付与して Client に渡す.
            </t>
            <!--
            <t>If the End-User grants the access request, the
            Authorization Server issues an Access Token and delivers it to the
            Client by adding the following parameters to the fragment component
            of the Redirection URI using the
            <spanx style="verb">application/x-www-form-urlencoded</spanx>
            format as defined in Section 4.2.2 of
            <xref target="RFC6749">OAuth 2.0</xref> and
            <xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref>.</t>
            -->

            <t>
              Implicit Flow では, <xref target="RFC6749">OAuth 2.0</xref> の Section 4.2.2 に従い, レスポンスの全体が Redirection URI のフラグメント部に返される.
            </t>
            <!--
            <t>In the Implicit Flow, the entire response is returned in the
            fragment component of the Redirection URI, as defined in 4.2.2 of
            <xref target="RFC6749">OAuth 2.0</xref>.</t>
            -->

            <t>
              <list style="hanging">
                <t hangText="access_token">
                  REQUIRED.
                  UserInfo Endpoint アクセスのための Access Token.
                </t>
                <!--
                <t hangText="access_token">REQUIRED.
                Access Token for the
                UserInfo Endpoint.</t>
                -->

                <t hangText="token_type">
                  REQUIRED.
                  OAuth 2.0 Token Type 値.
                  このサブセットを使う Clint について, この値は <xref target="RFC6750">OAuth 2.0 Bearer Token Usage</xref>
                  に従い, <spanx style="verb">Bearer</spanx> でなければならない (MUST).
                </t>
                <!--
                <t hangText="token_type">
                  REQUIRED.
                  OAuth 2.0 Token Type value.
                  The value MUST be <spanx style="verb">Bearer</spanx>, as specified in
                  <xref target="RFC6750">OAuth 2.0 Bearer Token Usage</xref>,
                  for Clients using this subset.
                </t>
                -->

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

                <t hangText="state">
                  OAuth 2.0 state 値.
                  Authorization Request に <spanx style="verb">state</spanx> パラメータが含まれていた場合は必須 (REQUIRED).
                  Clients は <spanx style="verb">state</spanx> 値が Authorization Request に含めた値と同一であることを検証しなければならない (MUST).
                </t>
                <!--
                <t hangText="state">
                  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">OPTIONAL.
                レスポンス生成時点から Access Token の期限切れまでの時間を秒で表したもの.
                </t>
                <!--
                <t hangText="expires_in">OPTIONAL.
                Expiration time of the Access Token in seconds
                since the response was generated.</t>
                -->
              </list>
            </t>

            <t>
              Client はこの Access Token を用いて Resource Server 上の保護されたリソースにアクセスが可能である.
            </t>
            <!--
            <t>The Client can then use the Access Token to access protected
            resources at Resource Servers.</t>
            -->

            <figure>
              <preamble>
                以下に例を示す. (改行は掲載上の都合による)
              </preamble>
              <!--
              <preamble>The following is a non-normative example
              (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="ImplicitAuthzError"
                   title="End-User Denies Authorization or Invalid Request">

            <t>
              End-User が認可を拒否したり, End-User の認証に失敗した場合, Authorization Server は <xref target="RFC6749">OAuth 2.0</xref> Section 4.2.2.1 に従ってエラーの Authorization Response を返さなければならない (MUST).
              (RFC 6749 に関係のないエラーは, 適切な HTTP ステータスコードを用いて User Agent に返すこと)
            </t>
            <!--
            <t>
              If the End-User denies the authorization or the End-User authentication
              fails, the Authorization Server MUST return the error
              Authorization Response as defined in 4.2.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>
            -->
          </section>

          <section anchor="ImplicitCallback"
                   title="Redirect URI Fragment Handling">
            <t>
              レスポンスのパラメータは Redirection URI フラグメントで渡されるため,
              Client はフラグメントエンコードされた値を User Agent でパースして
              Client の処理ロジックに送る必要がある.
              暗号 API に直接アクセス可能な User Agent では,
              例えばすべての Client コードを JavaScript で書くことにより,
              処理を User Agent 内で完結することができる.
            </t>
            <!--
            <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.
              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>
              しかし, Client 処理が User Agent 内で完結しない場合には,
              パラメータを Web Server Client へポストして検証する方法がある.
            </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>
              以下は Client が <spanx style="verb">redirect_uri</spanx> で提供する JavaScript ファイルの例である.
              このファイルは Authorization Server からのリダイレクトによって読み込まれる.
              フラグメント部分はパースされ, <spanx style="verb">POST</spanx> によって送信される先の URI で検証とユーザー情報の受信が行われる.
            </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>
                以下に Redirect URI レスポンスの例を示す.
              </preamble>
              <!--
              <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>

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

        <t>
          ID Token は, ある Client を利用するというコンテキスト中での, Authorization Server による End-User 認証に関する Claim を含んだセキュリティトークンである.
          潜在的にはその他の Cliam を含む可能性もある.
          ID Token は <xref target="JWT">JSON Web Token (JWT)</xref> である.
        </t>
        <!--
        <t>
          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>
          ID Token には以下の Cliam が含まれる.
        </t>
        <!--
        <t>The following Claims are used within the ID Token:</t>
        -->

        <t>
          <list style="hanging">
            <t hangText="iss">
              REQUIRED.
              レスポンスを返した Issuer の Issuer Identifier.
              <spanx style="verb">iss</spanx> 値は, <spanx style="verb">https</spanx> スキーマで始まる大文字小文字を区別する URL であり, スキーマ, ホスト, そして任意でポート番号とパスを含む. クエリーとフラグメントは含まない.
            </t>
            <!--
            <t hangText="iss">
              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">
              REQUIRED.
              Subject Identifier.
              Client に利用される前提で, Issuer のローカルでユニークであり再利用されない End-User の識別子.
              (例: <spanx style="verb">24400320</spanx> や <spanx style="verb">AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4</spanx> 等)
              この値は ASCII で255文字を超えてはならない (MUST NOT).
              <spanx style="verb">sub</spanx> 値は大文字小文字を区別する.
            </t>
            <!--
            <t hangText="sub">
              REQUIRED.
              Subject Identifier. 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 characters in length.
              The <spanx style="verb">sub</spanx> value is a case sensitive string.
            </t>
            -->

            <t hangText="aud">
              REQUIRED.
              ID Token の想定されるオーディエンス (Audience).
              この値は Relying Party の OAuth 2.0 <spanx style="verb">client_id</spanx> を含まなければならない (MUST).
              他のオーディエンスの識別子を含んでもよい (MAY).
              一般的には <spanx style="verb">aud</spanx> は大文字小文字を区別した文字列の配列であるが, オーディエンスが単体の場合は <spanx style="verb">aud</spanx> 値を大文字小文字を区別した単一文字列としてもよい.
            </t>
            <!--
            <t hangText="aud">
              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">
              REQUIRED.
              ID Token の有効期限.
              この有効期限以降に該当 ID Token を受け入れたり処理してはならない (MUST NOT).
              ある ID Token が有効期限内であるためには, この値が示す時刻より現在時刻が前でなければならない (MUST).
              実装者は, 通常数分以内で, 時計のズレを考慮して多少の猶予期間を設けてもよい (MAY).
              この値は UTC 1970-01-01T0:0:0Z から該当時刻までの秒数を示す JSON 数値である.
              詳細は <xref target="RFC3339">RFC 3339</xref> を参照のこと.
            </t>
            <!--
            <t hangText="exp">REQUIRED.
            Expiration time on or after which the ID Token MUST NOT be
            accepted for processing. 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 number representing the number of seconds from
            1970-01-01T0:0:0Z 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.
            </t>
            -->

            <t hangText="iat">
              REQUIRED.
              JWT 発行時刻.
              この値は UTC 1970-01-01T0:0:0Z から該当時刻までの秒数を示す JSON 数値である.
            </t>
            <!--
            <t hangText="iat">REQUIRED.
            Time at which the JWT was issued.
            Its value is a JSON number representing the number of seconds from
            1970-01-01T0:0:0Z as measured in UTC until the date/time.
            </t>
            -->

            <t hangText="auth_time">
              End-User の認証が発生した時刻.
              この値は UTC 1970-01-01T0:0:0Z から該当時刻までの秒数を示す JSON 数値である.
              リクエストに <spanx style="verb">max_age</spanx> が含まれていた場合, この Cliam は必須である (REQUIRED).
              その他の場合は任意 (OPTIONAL).
            </t>
            <!--
            <t hangText="auth_time">
            Time when the End-User authentication occurred.
            Its value is a JSON number representing the number of seconds from
            1970-01-01T0:0:0Z as measured in UTC until the date/time.
            When a <spanx style="verb">max_age</spanx> request is made
            then this Claim is REQUIRED; otherwise, its inclusion is OPTIONAL.
            </t>
            -->

            <t hangText="nonce">
              OPTIONAL.
              Client セッションと ID Token を紐づける文字列値.
              リプレイアタック防止のために用いられる.
              Authentication Request で指定されたままの値を ID Token に含める.
              Client は Authentication Request に含めた <spanx style="verb">nonce</spanx> 値が ID Token に含まれる <spanx style="verb">nonce</spanx> Claim 値と一致することを検証しなければならない (MUST).
              Authentication Request に nonce が含まれていた場合, Authorization Server は ID Token にそのままの値で <spanx style="verb">nonce</spanx> Claim を含めねばならない (MUST).
              <spanx style="verb">nonce</spanx> は大文字小文字を区別する文字列である.
            </t>
            <!--
            <t hangText="nonce">
              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.
              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.
              The <spanx style="verb">nonce</spanx> value is a case sensitive string.
            </t>
            -->

            <t hangText="at_hash">
              REQUIRED.
              Access Token のハッシュ値.
              Implicit Flow 内で ID Token が <spanx style="verb">access_token</spanx> とともに発行された場合 (この項で説明しているOpenID Connectのサブセットではこのケースに該当する), この Claim は必須である (REQUIRED).
              この値は, <spanx style="verb">access_token</spanx> の ASCII バイト列のハッシュ値の左半分を Basd64URL エンコードしたものであり, ハッシュアルゴリズムは ID Token の <xref target="JWS">JWS</xref> ヘッダーにある <spanx style="verb">alg</spanx> で用いられるハッシュアルゴリズムと同じものを用いる.
              例えば <spanx style="verb">alg</spanx> が <spanx style="verb">RS256</spanx> であれば, <spanx style="verb">access_token</spanx> の SHA-256 ハッシュ値を計算し, その左半分の128ビットを Base64URL エンコードする.
              <spanx style="verb">at_hash</spanx> は大文字小文字を区別する文字列である.
            </t>
            <!--
            <t hangText="at_hash">
              REQUIRED.
              Access Token hash value.
              If the ID Token is issued with an <spanx style="verb">access_token</spanx>
              in an Implicit Flow, this is REQUIRED,
              which is the case for this subset of OpenID Connect.
              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> parameter
              of the ID Token's <xref target="JWS">JWS</xref> 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 hangText="acr">
              OPTIONAL.
              Authentication Context Class Reference.
              実施された認証処理が満たす Authentication Context Class を表す Authentication Context Class Reference 値を示す文字列.
              "0" という値は End-User 認証が <xref target="ISO29115">ISO/IEC 29115</xref> の定める level 1 を満たさないことを意味する.
              長期間有効なブラウザクッキーを用いた認証などが, "level 0" の例として挙げられる.
              金銭にかかわるリソースへのアクセス認可要求時には, level 0 の認証を受け入れるべきではない (SHOULD NOT).
              <spanx style="verb">acr</spanx> 値には, 絶対 URL か <xref target="RFC6711">RFC 6711</xref> に登録された値を用いるべきである (SHOULD).
              <xref target="RFC6711">RFC 6711</xref> 登録済の値を用いる場合, <xref target="RFC6711">RFC 6711</xref> と異なる意味でそれを用いてはならない (MUST NOT).
              この値の意味するところはコンテキストによって異なる可能性があるため, この Claim を利用する場合は, 関係者間で値の意味するところについて合意しておくこと.
              <spanx style="verb">acr</spanx> は大文字小文字を区別する文字列である.
            </t>
            <!--
            <t hangText="acr">
              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.
              Authentication using a long-lived browser cookie, for instance, is one
              example where the use of "level 0" is appropriate. Authentications with
              level 0 SHOULD NOT be used to authorize access to any resource of any
              monetary value.
              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">
              OPTIONAL.
              Authentication Methods References.
              認証時に用いられた認証方式を示す識別子文字列の JSON 配列.
              例として, パスワードと OTP 認証が両方行われたことを示すといったケースが考えられる.
              <spanx style="verb">amr</spanx> Claim にどのような値を用いるかは本仕様の定めるところではない.
              この値の意味するところはコンテキストによって異なる可能性があるため, この Claim を利用する場合は, 関係者間で値の意味するところについて合意しておくこと.
              <spanx style="verb">amr</spanx> は大文字小文字を区別する文字列である.
            </t>
            <!--
            <t hangText="amr">
              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">
              OPTIONAL.
              ID Token 発行対象である認可された関係者 (authorized party).
              この Claim が存在する場合, その値は受け取り手の OAuth 2.0 Client ID でなければならない.
              この Claim は, ID Token のオーディエンス値が単一文字列であり, かつその値が <spanx style="verb">azp</spanx> の値と異なる場合にのみ必要となる.
              オーディエンスと <spanx style="verb">azp</spanx> 値が同値である場合にも, この Claim を含んでもよい (MAY).
              <spanx style="verb">azp</spanx> は大文字小文字を区別する文字列である.
            </t>
            <!--
            <t hangText="azp">
              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>
            -->

            <t hangText="sub_jwk">
              <xref target="SelfIssued"/> で定義されるとおり, Self-Issued OpenID Provider から発行された ID Token の署名検証に使われる公開鍵.
              鍵は <xref target="JWK"/> フォーマットのベア鍵である (X.509 証明書ではない).
              <spanx style="verb">sub_jwk</spanx> Claim の使用は,
              OP が Self-Issued OP の場合は必須 (REQUIRED) であり,
              そうでない場合は推奨されない (NOT RECOMMENDED).
              <spanx style="verb">sub_jwk</spanx> 値は JSON オブジェクトである.
            </t>
            <!--
            <t hangText="sub_jwk">
              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).
              Use of the <spanx style="verb">sub_jwk</spanx> Claim
              is REQUIRED when the OP is a Self-Issued OP and
              is NOT RECOMMENDED when the OP is not Self-Issued.
              The <spanx style="verb">sub_jwk</spanx> value is a JSON object.
            </t>
            -->

          </list>
        </t>

        <t>
          ID Token はその他の Claim を含んでもよい (MAY).
          解釈不可能な Claim は全て無視すること (MUST).
        </t>
        <!--
        <t>
          ID Tokens MAY contain other Claims.
          Any Claims used that are not understood MUST be ignored.
        </t>
        -->

        <t>
          ID Token は <xref target="JWS">JWS</xref> を使って署名されなければならない (MUST).
          Client は ID Token を <xref target="IDTokenValidation"/> に従って検証しなければならない (MUST).
        </t>
        <!--
        <t>ID Tokens MUST be signed using <xref
        target="JWS">JWS</xref>.
        Clients MUST validate the ID Token per
        <xref target="IDTokenValidation"/>.
        </t>
        -->
        <t>
          ID Token は JWS および JWE の
          <spanx style="verb">x5u</spanx>,
          <spanx style="verb">x5c</spanx>,
          <spanx style="verb">jku</spanx>,
          <spanx style="verb">jwk</spanx>
          ヘッダーフィールドを含むべきではない (SHOULD NOT).
          これらの代わりに事前の Discovery および Registration において, ID Token に用いる鍵を得ること.
        </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, keys used for ID Tokens are
          communicated in advance using Discovery and Registration parameters.
        </t>
        -->

        <figure>
          <preamble>
            以下は Base64URL デコードされた ID Token の例である.
          </preamble>
          <!--
          <preamble>The following is a non-normative example of a base64url decoded
          ID Token:</preamble>
          -->

          <artwork><![CDATA[
  {
   "iss": "https://server.example.com",
   "sub": "24400320",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "at_hash": "MTIzNDU2Nzg5MDEyMzQ1Ng"
  }
]]></artwork>
        </figure>

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

          <t>
            本仕様の定めるバリデーションが1つでも失敗した場合, バリデーションが失敗した情報を必要とする処理を全て中止し (MUST), バリデーションが失敗した情報を利用してはならない (MUST NOT).
          </t>
          <!--
          <t>
            If any of the validation procedures defined in this specification fail, any operations requiring
            the information that failed to correctly validate MUST be aborted and
            the information that failed to validate MUST NOT be used.
          </t>
          -->

          <t>
            Client は Authorization Response に含まれる ID Token を以下のようにバリデートしなければならない (MUST).
          </t>
          <!--
          <t>To validate the ID Token in the Authorization Response,
          the Client MUST do the following:</t>
          -->

          <t>
            <list style="numbers">

              <t>
                OpenID Provider の Issuer Identifier (これは通常 Discovery によって得られる) が <spanx style="verb">iss</spanx> (issuer) Claim と一致しなければならない (MUST).
              </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>
                <spanx style="verb">aud</spanx> Claim が, <spanx style="verb">iss</spanx> Claim に紐づく Issuer に登録されている Client 自身の <spanx style="verb">client_id</spanx> を含まなければならない (MUST).
                ID Token のオーディエンスに Client が含まれていなかったり, Client にとって信頼できない主体がオーディエンスに含まれている場合, その ID Token を拒絶しなければならない (MUST).
              </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 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>
                ID Token が複数のオーディエンスを含む場合, Client は <spanx style="verb">azp</spanx> Claim が存在することを検証すべきである (SHOULD).
              </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>
                <spanx style="verb">azp</spanx> Claim が存在する場合, Client はそれが自身の <spanx style="verb">client_id</spanx> と一致することを検証すべきである (SHOULD).
              </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>
                Client は ID Token の署名を, JWT ヘッダ中の <spanx style="verb">alg</spanx> パラメータで指定されたアルゴリズムを使い, <xref target="JWS">JWS</xref> に従って検証しなければならない (MUST).
                Client は Issuer によって提供された鍵を使わなければならない (MUST).
              </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> parameter of the JWT header.
                The Client MUST use the keys provided by the Issuer.
              </t>
              -->

              <t>
                <spanx style="verb">alg</spanx> の値は <spanx style="verb">RS256</spanx> であるべきである (SHOULD).
                他の署名アルゴリズムを用いたトークン検証については
                <xref target="OpenID.Core">OpenID Connect Core 1.0</xref>
                に記述されている.
              </t>
              <!--
              <t>The <spanx style="verb">alg</spanx> value SHOULD be <spanx style="verb">RS256</spanx>.
              Validation of tokens using other signing algorithms is described in the
              <xref target="OpenID.Core">OpenID Connect Core 1.0</xref>
              specification.</t>
              -->

              <t>
                現在時刻が <spanx style="verb">exp</spanx> Claim より前でなければならない (MUST).
                (時計のズレを考慮した多少の猶予は許容される)
              </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>
                <spanx style="verb">iat</spanx> Claim が現在時刻からあまりにかけ離れている場合は, そのトークンを拒絶してもよい.
                これにより nonce の保存期間を制限することができる.
                適切な閾値は, Client ごとにことなる.
              </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>
                <spanx style="verb">nonce</spanx>
                Claim の値が Authentication Request にて送られたものと一致することを確認しなければならない (MUST).
                Client は <spanx style="verb">nonce</spanx> の値をリプレイアタック対策のためにチェックすべきである (SHOULD).
                リプレイアタック検知方法の詳細は Client によって異なる.
              </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>
              -->

              <t>
                <spanx style="verb">acr</spanx> Claim が要求されたならば, Client は主張された Claim の値が適切かどうかをチェックすべきである (SHOULD).
                <spanx style="verb">acr</spanx> Claim の値と意味はこの仕様の対象外である.
              </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>
                <spanx style="verb">max_age</spanx> が要求されたならば,
                Client は <spanx style="verb">auth_time</spanx> Claim の値をチェックし, もし最新のユーザー認証からあまりに長い時間が経過したと判定されたときは再認証を要求すべきである (SHOULD).
              </t>
              <!--
              <t>
                When a <spanx style="verb">max_age</spanx> request is made,
                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="AccessTokenValidation" title="Access Token Validation">
          <t>
            Implicit Flow で ID Token とともに 発行された Access Token を検証するには,
            Client は以下を検証するべきである (SHOULD).
          </t>
          <!--
          <t>To validate an Access Token issued with an ID Token in
          the Implicit Flow, the Client SHOULD do the following:</t>
          -->

          <t>
            <list style="numbers">
              <t>
                <spanx style="verb">access_token</spanx> の ASCII オクテット列のハッシュ値を求める.
                このとき用いるハッシュアルゴリズムは ID Token の <xref target="JWS">JWS</xref> ヘッダーにある <spanx style="verb">alg</spanx> ヘッダーパラメータに対応する <xref target="JWA">JWA</xref> で定められたものである.
                例えば <spanx style="verb">alg</spanx> が <spanx style="verb">RS256</spanx> であれば, ハッシュアルゴリズムは SHA-256である.
              </t>
              <!--
              <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>
              parameter in the ID Token's <xref target="JWS">JWS</xref> 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>
                ハッシュ値の左半分を Base64URL エンコードする.
              </t>
              <!--
              <t>Take the left-most half of the hash and base64url encode it.</t>
              -->

              <t>
                ID Token に <spanx style="verb">at_hash</spanx> が存在する場合は,
                その値は, 直前のステップで求めた値と一致しなければならない (MUST).
              </t>
              <!--
              <t>The value of <spanx style="verb">at_hash</spanx> in the ID Token MUST
              match the value produced in the previous step if <spanx style="verb">at_hash</spanx>
              is present in the ID Token.</t>
              -->
          </list>
          </t>
        </section>

      </section>

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

        <!-- 2.3はまるごと basic と同じ -->
        <t>
          UserInfo Endpoint は, 認証された End-User に関する Claim を返す OAuth 2.0 Protected Resource である.
          UserInfo Endpoint は <spanx style="verb">https</spanx> スキーマの URL であり, ポート番号, パス, クエリーを含むことができる (MAY).
          Claim は JSON オブジェクトとして返される.
        </t>
        <!--
        <t>
          The UserInfo Endpoint is an OAuth 2.0 Protected Resource that
          returns Claims about the authenticated End-User.
          The location of the UserInfo Endpoint MUST be
          a URL using the <spanx style="verb">https</spanx> scheme, which MAY contain
          port, path, and query parameter components.
          The returned Claims are
          represented by a JSON object that contains a collection of
          name and value pairs for the Claims.
        </t>
        -->

        <t>
          UserInfo Endpoint にアクセスする際には TLS は必須である (MUST).
          TLS 利用についての詳細は <xref target="TLSRequirements"/> 参照.
        </t>
        <!--
        <t>
          Communication with the UserInfo Endpoint MUST utilize TLS.
          See <xref target="TLSRequirements"/> for more information on using TLS.
        </t>
        -->

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

          <t>
            Client は, OpenID Connect Authentication で得られた Access Token を使って, UserInfo Endpoint に End-User の Claim をリクエストする.
            UserInfo Endpoint は <xref target="RFC6750">OAuth 2.0 Bearer Token Usage</xref> に従った <xref target="RFC6749">OAuth 2.0</xref> Protected Resource である.
            このリクエストは HTTP <spanx style="verb">GET</spanx> で行われるべきであり (SHOULD), Access Token は <spanx style="verb">Authorization</spanx> ヘッダー経由で渡されるべきである (SHOULD).
          </t>
          <!--
          <t>
            Clients send requests to the
            UserInfo Endpoint to obtain Claims about the End-User
            using an Access Token obtained through OpenID Connect Authentication.
            The UserInfo Endpoint is an <xref target="RFC6749">OAuth 2.0</xref>
            Protected Resource that complies with the <xref
            target="RFC6750">OAuth 2.0 Bearer Token Usage</xref> specification.
            The request SHOULD use the
            HTTP <spanx style="verb">GET</spanx> method and
            the Access Token SHOULD be sent using the
            <spanx style="verb">Authorization</spanx> header field.
          </t>
          -->

          <figure>
            <preamble>
              以下に UserInfo Request の例を示す.
            </preamble>
            <!--
            <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>
            UserInfo Claim は JSON オブジェクトのメンバーとして返される (MUST).
            レスポンスボディは UTF-8 エンコードされる (SHOULD).
            <xref target="StandardClaims"/> に定義されている Claim に加え, そこに明記されていない Claim も返却可能である.
          </t>
          <!--
          <t>
            The UserInfo Claims MUST be returned as the members of a JSON object.
            The response body SHOULD be encoded using UTF-8.
            The Claims defined in <xref target="StandardClaims"/> can be returned,
            as can additional Claims not specified there.
          </t>
          -->
          <t>
            Claim が返されない場合, Claim Name は JSON オブジェクトから除かれるべきであり (SHOULD), 値を null や空文字列にした状態で該当 Claim を含めるべきではない (SHOULD NOT).
          </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>
            UserInfo Response には, 必ず <spanx style="verb">sub</spanx> Claim を含むこと (MUST).
          </t>
          <!--
          <t>
            The <spanx style="verb">sub</spanx> (subject) Claim
            MUST always be returned in the UserInfo Response.
          </t>
          -->
          <t>
            注) トークン置換攻撃を考慮すると, UserInfo Response が必ずしも ID Token の <spanx style="verb">sub</spanx> Claim が示す End-User のものであるとは保証できない.
            そのため UserInfo Response に含まれる <spanx style="verb">sub</spanx> Claim が ID Token のそれと一致することを検証しなければならない (MUST).
            もし2つが一致しない場合, UserInfo Response を利用してはならない (MUST NOT).
          </t>
          <!--
          <t>
            NOTE:  Due to the possibility of token substitution attacks,
            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>
            Client はレスポンスを返した OP が意図した通りの OP であることを, <xref target="RFC6125">RFC 6125</xref> に従い TLS サーバー証明書チェックを通じて検証しなければならない (MUST).
          </t>
          <!--
          <t>
            The Client MUST verify that the OP that responded was
            the intended OP through a TLS server certificate check,
            per <xref target="RFC6125">RFC 6125</xref>.
          </t>
          -->
        </section>

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

          <t>
            もし何らかのエラーが起こった場合, UserInfo Endpoint は  <xref target="RFC6750">OAuth 2.0 Bearer Token Usage</xref> SEction 3 に示す Error Response を返す.
          </t>
          <!--
          <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>.
          </t>
          -->
        </section>
      </section>

      <section anchor="Scopes" title="Scope Values">
        <t>
          OpenID Connect Client は <xref target="RFC6749">OAuth 2.0</xref> Section 3.3 に従い, Access Token に要求されるアクセス権限を <spanx style="verb">scope</spanx> 値を通じて指定する.
          Access Tokens に紐づく scope は, そのトークンを使って OAuth 2.0 で保護されたエンドポイントにアクセスした際にどのようなリソースが得られるかを規定する.
          OpenID Connect では, scope は Claim Value として取得可能な情報セットを指定する為に利用できる.
          本仕様では OpenID Connect で用いられる scope についてのみ述べる.
        </t>
        <!--
        <t>OpenID Connect Clients use <spanx style="verb">scope</spanx> values as defined in 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. For OpenID Connect, scopes
        can be used to request that specific sets of information
        be made available as Claim Values.
        This specification describes only the scope values used by OpenID Connect.</t>
        -->
        <t>
          OpenID Connect は, ここで述べる scope 値以外の値を定義および利用することを制限しない.
          また実装が理解できない scope 値は無視されるべきである (SHOULD).
        </t>
        <!--
        <t>
          OpenID Connect allows additional scope values to be defined and used.
          Scope values used that are not understood by an implementation SHOULD be ignored.
        </t>
        -->
        <t>
          Authorization Server は, 以下の scope によって要求される Claim を Voluntary Claim として扱う.
        </t>
        <!--
        <t>
          Claims requested by the following scopes are treated by Authorization Servers
          as Voluntary Claims.
        </t>
        -->

        <t>
          OpenID Connect は以下の <spanx style="verb">scope</spanx> 値を定義する.
        </t>
        <!--
        <t>OpenID Connect defines the following <spanx style="verb">scope</spanx> values:</t>
        -->
        <t>
          <list style="hanging">
            <t hangText="openid">
              REQUIRED.
              Client が Authorization Server に OpenID Connect リクエストを投げていることを示す.
              <spanx style="verb">openid</spanx> scope 値が存在しない場合の挙動は定義しない.
            </t>
            <!--
            <t hangText="openid">REQUIRED. Informs the Authorization Server
            that the Client is making an OpenID Connect request. If the
            <spanx style="verb">openid</spanx> scope value is not present,
            the behavior is entirely unspecified.
            </t>
            -->

            <t hangText="profile">
              OPTIONAL.
              この scope 値は, 以下に示す End-User のデフォルトプロフィール Claim へのアクセス要求に用いる.
            <!--
            <t hangText="profile">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">
              OPTIONAL.
              <spanx style="verb">email</spanx> および <spanx style="verb">email_verified</spanx> Claim へのアクセス要求に用いる.
            </t>
            <!--
            <t hangText="email">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">
              OPTIONAL.
              <spanx style="verb">address</spanx> Claim へのアクセス要求に用いる.
            </t>
            <!--
            <t hangText="address">OPTIONAL. This scope value requests access to
            the <spanx style="verb">address</spanx> Claim.</t>
            -->

            <t hangText="phone">
              OPTIONAL.
              <spanx style="verb">phone_number</spanx> および <spanx style="verb">phone_number_verified</spanx> Claim へのアクセス要求に用いる.
            </t>
            <!--
            <t hangText="phone">OPTIONAL. This scope value requests access to
            the <spanx style="verb">phone_number</spanx> and
            <spanx style="verb">phone_number_verified</spanx> Claims.</t>
            -->

            <!-- basicと異なる -->
            <t hangText="offline_access">
              この scope 値は OpenID Connect Implicit Client Implementer's Guide 1.0 では使用してはならない (MUST NOT).
              Basic Client での使用については <xref target="OpenID.Basic">OpenID Connect Basic Client Implementer's Guide 1.0</xref> を参照のこと.
            </t>
            <!--
            <t hangText="offline_access">This scope value MUST NOT be used with the
            OpenID Connect Implicit Client Implementer's Guide 1.0.
            See the
            <xref target="OpenID.Basic">OpenID Connect Basic Client Implementer's Guide 1.0</xref>
            for its usage in that subset of OpenID Connect.</t>
            -->

          </list>
        </t>

        <t>
          複数の scope 値は, スペース区切りの大文字小文字を区別した ASCII scope 値のリストによって指定することができる (MAY).
        </t>
        <!--
        <t>Multiple scope values MAY be used by creating a space delimited, case
        sensitive list of ASCII scope values.</t>
        -->

        <t>
          <spanx style="verb">profile</spanx>,
          <spanx style="verb">email</spanx>,
          <spanx style="verb">address</spanx>, および
          <spanx style="verb">phone</spanx> scope 値により要求される Claim は, <xref target="UserInfoResponse"/> にある通り UserInfo Endpoint から返される.
        </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"/>.
        </t>
        -->

        <t>
          End-User が OpenID Provider に対して RP に要求された情報の一部もしくは全ての提供を拒否することもある.
          End-User に要求する情報を最小化するために, RP は UserInfo Endpoint で提供される情報の一部のみをリクエストすることもできる.
        </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>
              以下に <spanx style="verb">scope</spanx> リクエスト例を示す.
            </preamble>
            <!--
            <preamble>The following is a non-normative example of a <spanx style="verb">scope</spanx>
            Request:</preamble>
            -->

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

      <section anchor="StandardClaims" title="Standard Claims">
        <t>
          OpenID Connect では以下に示す標準 Claim セットを定義する.
          これらは通常の OP からは UserInfo Response として,
          Self-Issued OP からは ID Token の中に返される.
        </t>
        <!--
        <t>This subset of OpenID Connect defines a set of standard Claims.
        They are returned by normal OPs in the UserInfo Response
        and are returned by Self-Issued OPs in the ID Token.
        </t>
        -->

        <!-- 以下, 2.5はまるごと basic と同じ -->

        <texttable anchor="ClaimTable" title="Reserved 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 - Issuer における End-User の識別子.
          </c>
          <!--
          <c>Subject - Identifier for the End-User at the Issuer.</c>
          -->

          <c>name</c>
          <c>string</c>
          <c>
            End-User の表示用フルネーム.
            肩書きや称号 (suffix) 等が含まれることもある.
            氏名等の表示順は End-User の locale や選好に従う.
          </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>
            End-User の名 (given name / first name).
            複数の given name を持つ文化圏もあることに注意.
            全ての given name が含まれる可能性があり, その場合はスペース区切りで表記される.
          </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>
            End-User の姓 (surname / last name).
            複数の family name を持つ文化圏や family name を持たない文化圏もあることに注意.
            全ての family name が含まれる可能性があり, その場合はスペース区切りで表記される.
          </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>
            End-User の middle name.
            複数の middle name を持つ文化圏もあることに注意.
            全ての middle name が含まれる可能性があり, その場合はスペース区切りで表記される.
            また middle name を使用しない文化圏もある.
          </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>
            End-User のニックネーム.
            これは <spanx style="verb">given_name</spanx> と同じこともあれば異なることもある.
            例えば, <spanx style="verb">nickname</spanx> が <spanx style="verb">Mike</spanx>, <spanx style="verb">given_name</spanx> が <spanx style="verb">Michael</spanx> として返されることがある.
          </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>
            <spanx style="verb">janedoe</spanx> や <spanx style="verb">j.doe</spanx> といった, End-User の選好する簡略名.
            これは <spanx style="verb">@</spanx> や <spanx style="verb">/</spanx> や空白文字といった特殊文字を含むあらゆる valid な JSON 文字列でありうる (MAY).
            <xref target="ClaimStability"></xref> にあるように, RP は この値がユニークであるという前提で扱ってはならない (MUST NOT).
          </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>
            End-User のプロフィールページの URL.
            この Web ページに掲載されるコンテンツはこの End-User に関するものであろう (SHOULD).
          </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>
            End-User のプロフィール画像の URL.
            この URL は画像ファイル (PNG, JPEG, GIF 画像ファイル等) を参照すること (MUST).
            またこの画像は End-User が撮影した任意の写真ではなく, End-User に言及する際に適切な画像とするべきである (SHOULD).
          </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>
            End-User の Web ページやブログの URL.
            この Web ページは End-User 自身や End-User が所属する組織が発信する情報を含むべきである (SHOULD).
          </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 の選好する Email アドレス.
            <xref target="RFC5322">RFC 5322</xref> の addr-spec シンタックスに従うこと.
            <xref target="ClaimStability"></xref> にあるように, RP は この値がユニークであるという前提で扱ってはならない (MUST NOT).
          </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>
            End-User の Email アドレスが検証済であれば true, さもなければ false.
            Claim Value が <spanx style="verb">true</spanx> の場合, これは OP が検証を行った時点において該当 Email アドレスが End-User のコントロール下にあるという確認処理を行ったことを示す.
            Email アドレスの検証の詳細についてはコンテキストに依存し, 関係者間でのトラストフレームワークや契約上の同意事項等などによって異なる.
          </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 の性別.
            本仕様では <spanx style="verb">female</spanx>, <spanx style="verb">male</spanx> を定義する.
            定義済の値に適切なものがない場合, その他の値を利用してもよい (MAY).
          </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 の誕生日.
            <xref target="ISO8601-2004">ISO 8601:2004</xref> <spanx style="verb">YYYY-MM-DD</spanx> 形式で表現される.
            生年を <spanx style="verb">0000</spanx> とすることで生年を省略することもできる (MAY).
            生年のみを提示する場合は <spanx style="verb">YYYY</spanx> 形式としても良い.
            プラットフォームの日付関連の関数の実装によって, 生年のみを提供した場合の月日の扱いは様々であるため, 実装者はこの点を考慮にいれて日付を処理すべきである.
          </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>
            End-User のタイムゾーンを示す <xref target="zoneinfo"/> に登録された文字列.
            (<spanx style="verb">Europe/Paris</spanx>, <spanx style="verb">America/Los_Angeles</spanx> 等)
          </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 の locale.
            <xref target="RFC5646">BCP47</xref> 言語タグ表現.
            これは通常 <xref target="ISO639-1">ISO 639-1 Alpha-2</xref> 言語コードを小文字表記, <xref target="ISO3166-1">ISO 3166-1 Alpha-2</xref> 国コードを大文字表記し, ダッシュでつなげたものである.
            (<spanx style="verb">en-US</spanx>, <spanx style="verb">fr-CA</spanx> 等)
            実装によってはダッシュの代わりにアンダースコアを区切り文字に用いる場合もあるため, 互換性の観点からは注意すること.
            (<spanx style="verb">en_US</spanx> 等)
            Relying Party はダッシュ区切りに加えてアンダースコア区切りのシンタックスを受け入れてもよい (MAY).
          </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 の選好する電話番号.
            この Claim のフォーマットとしては <xref target="E.164">E.164</xref> を推奨する (RECOMMENDED).
            (<spanx style="verb">+1 (425) 555-1212</spanx>, <spanx style="verb">+56 (2) 687 2400</spanx> 等)
            電話番号が拡張を含む場合, その拡張は <xref target="RFC3966">RFC 3966</xref> 拡張シンタックスで表記することを推奨する (RECOMMENDED).
            (<spanx style="verb">+1 (604) 555-1234;ext=5678</spanx> 等)
          </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>
            End-User の電話番号が検証済であれば ture, さもなければ false.
            Claim Value が <spanx style="verb">true</spanx> の場合, これは OP が検証を行った時点において該当電話番号が End-User のコントロール下にあるという確認処理を行ったことを示す.
            電話番号の検証の詳細についてはコンテキストに依存し, 関係者間でのトラストフレームワークや契約上の同意事項等などによって異なる.
            また true の場合, <spanx style="verb">phone_number</spanx> Claim は E.164 形式でなければならず (MUST), すべての拡張は RFC 3966 形式でなければならない (MUST).
          </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 の選好する郵送先住所.
            <spanx style="verb">address</spanx> メンバーは <xref target="AddressClaim"/> に定義されたメンバーを含む JSON <xref target="RFC4627"/> 構造である.
          </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>
            End-User に関する情報の最終更新日時.
            この値は UTC 1970-01-01T0:0:0Z から該当時刻までの秒数を示す JSON 数値である.
          </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-01T0:0:0Z as measured in UTC until the date/time.
          </c>
          -->
        </texttable>

        <figure>
          <preamble>
            以下に例を示す.
          </preamble>
          <!--
          <preamble>Following is a non-normative example of such
          a response:</preamble>
          -->

          <artwork><![CDATA[
  {
   "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>

        <t>
          Registration <xref target="OpenID.Registration"/> において特に他フォーマットを指定されない限り, UserInfo Endpoint では Claim を JSON 形式で返し (MUST), Content-Type ヘッダーを用いてフォーマットを示すこと (MUST).
          以下に許可されたコンテンツタイプを示す.
        </t>
        <!--
        <t>The UserInfo Endpoint MUST return Claims in JSON format 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 following are accepted content
        types:</t>
        -->

        <texttable style="all">
          <ttcol>Content-Type</ttcol>
          <ttcol>Format Returned</ttcol>

          <c>application/json</c>
          <c>plain text JSON object</c>

          <c>application/jwt</c>
          <c>JSON Web Token (JWT)</c>
        </texttable>

        <section anchor="AddressClaim" title="Address Claim">
          <t>
            Address Claim は物理的な郵送先住所である.
            End-User の登録済情報とプライバシー設定に基づいて, <spanx style="verb">address</spanx> の一部のみを返却することもある (MAY).
            例えば <spanx style="verb">country</spanx> と <spanx style="verb">region</spanx> を返し, それ以外の詳細なアドレス情報を省略するなどが考えられる.
          </t>
          <!--
          <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>
            住所全体を整形済サブフィールドに1文字列として入れてもよいし (MAY), 他のサブフィールドに個別の要素として各住所要素を指定するだけでもよいし (MAY), 両方を含めてもよい (MAY).
            もし両方を含める場合, 整形済住所は住所の各要素の連結方法を示すものとし, 両方が同じアドレスを示すこと (SHOULD).
          </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">
                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">
                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">City or locality component.</t>

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

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

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

        <section anchor="ClaimsLanguagesAndScripts" title="Claims Languages and Scripts">
          <t>
            Human-readable な Claim Value およびそれらへの参照は, 複数言語および複数文字種で表現することができる (MAY).
            言語および文字種の指定には <xref target="RFC5646">BCP47</xref> 言語タグを <spanx style="verb">#</spanx> を区切り文字としてメンバー名に付与する.
            例えば <spanx style="verb">family_name#ja-Kana-JP</spanx> は日本語のカタカナ表記の Family Name を示す.
            カタカナ表記の氏名は, 漢字表記 (<spanx style="verb">family_name#ja-Hani-JP</spanx>) の氏名の発音を示したりインデックス目的等で用いられることが多い.
            他にも <spanx style="verb">website</spanx> が言語指定のない Web サイト, <spanx style="verb">website#de</spanx> がドイツ語の Web サイトを参照していることを示すといった例も挙げられる.
          </t>
          <!--
          <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>
            Claim Name は大文字小文字を区別するため, Claim Name 内の言語タグは <xref target="IANA.Language">IANA Language Subtag Registry</xref> に登録されたままの表記とすることを強く推奨する (RECOMMENDED).
            一般的に言語名は小文字, 地域名は大文字, 文字種は大文字小文字混合で表記されることが多い.
            しかしながら BCP47 言語タグ値は大文字小文字を区別しないため, 実装は言語タグを大文字小文字区別なく処理できるべきである (SHOULD).
          </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
            <xref target="IANA.Language">IANA Language Subtag Registry</xref>.
            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>
            BCP47 で推奨されるように, Claim の言語タグ値は必要な時にのみ指定すべきである (SHOULD).
            例えばほとんどの場合 <spanx style="verb">fr-CA</spanx> や <spanx style="verb">fr-FR</spanx> でなく <spanx style="verb">fr</spanx> で十分である.
            可能であれば OP は要求された Claim locale と自身が持つ Claim のマッチングを試みるべきである (SHOULD).
            例えば Client が <spanx style="verb">de</spanx> (ドイツ語) の Claim を要求してきており, OP が <spanx style="verb">de-CH</spanx> (スイスのドイツ語) 表記の Claim は持つが地域指定無しの一般的ドイツ語表記の Claim を持たない場合, OP はスイスのドイツ語の値を返すのが適切である.
            (Client をできるかぎりシンプルに保つため, ここでは言語タグのマッチングが内包する複雑性をわざと OP に寄せている)
          </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>
            リクエスト中の <spanx style="verb">claims_locales</spanx> を使って, 返却される Claim の好ましい言語および文字種を指定することができる.
          </t>
          <!--
          <t>
            A <spanx style="verb">claims_locales</spanx> request can be used to
            specify the preferred languages and scripts to use for the returned Claims.
          </t>
          -->
          <t>
            OP が <spanx style="verb">claims_locales</spanx> やその他の手段により End-User と Client が単一言語および文字種表記の Claim を要求していると特定した場合, 該当言語および文字種表記の Claim を返却する際には言語タグを付けずに返すことを推奨する (RECOMMENDED).
            また Client は言語タグ付きの Claim を処理可能なよう実装することを推奨する (RECOMMENDED).
          </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="ClaimStability" title="Claim Stability and Uniqueness">

          <t>
            <spanx style="verb">sub</spanx> (subject) と <spanx style="verb">iss</spanx> (issuer) Claim のペアは, RP が End-User の不変な識別子として信頼できる唯一の Claim である.
            <xref target="IDToken"></xref> で述べたように, <spanx style="verb">sub</spanx> は Issuer が End-User に割り振るローカルでユニークかつ再利用されない識別子でなければならない (MUST).
            以上のことから, <spanx style="verb">iss</spanx> Claim と <spanx style="verb">sub</spanx> Claim のペアが, 唯一の保証された End-User の識別子となる.
          </t>
          <!--
          <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>
            その他の Claim に関しては, 時間経過や複数ユーザー間での不変性等は保証されず, Issuer は独自の制約やポリシーを適用してよい.
            例えば Issuer は時系列上の異なるポイントにおいて, 同一の <spanx style="verb">email</spanx> Claim Value を異なるユーザーのために再利用してもよい (MAY).
            よって <spanx style="verb">email</spanx> アドレスは時間経過によって異なる End-User に紐づく可能性がある (MAY).
            以上のことより, <spanx style="verb">email</spanx>, <spanx style="verb">phone_number</spanx>, <spanx style="verb">preferred_username</spanx> などの Claim を End-User のユニークな識別子として利用してはならない (MUST NOT).
          </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>

    <section anchor="SelfIssued" title="Self-Issued OpenID Provider">
      <t>
        OpenID Connect は Self-Issued OpenID プロバイダー (私有の self-hosted な OpenID Provider であり, 自己署名つきの ID Token を発行するもの) をサポートしている.
        Self-Issued OP は
        <spanx style="verb">https://self-issued.me</spanx> という特別な Issuer 識別子を使用する.
      </t>
      <!--
      <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>
      -->

      <section anchor="SelfIssuedDiscovery" title="Self-Issued OpenID Provider Discovery">
        <t>
          ディスカバリプロセスで入力された識別子が self-issued.me ドメインを含んでいた場合, ダイナミックディスカバリは実行されない.
          その代わりに以下の静的な設定値が使用される.
        </t>
        <!--
        <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>
          注記: OpenID ファウンデーションは
          <spanx style="verb">https://self-issued.me/</spanx>
          という OpenID プロバイダーサイトを提供することを計画している.
          その場合は WebFinger サービスも提供され, ディスカバリを実行すると上記の静的なディスカバリ情報を返すため, RP は Self-Issued OP のディスカバリのために特別な処理を行う必要はない.
          このサイトは実験的に提供される予定である.
          プロダクション環境を実装する際は, OpenID ファウンデーションが当該サイトをプロダクション用途を想定して提供するまでその環境に依存すべきではない.
        </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>
          Self-Issued OP を使う際は登録は必要ない.
          Client は登録しなくても OP に登録したかのように振る舞い, 以下の Client Registration Response を得る.
       </t>
        <!--
        <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">
              Client の <spanx style="verb">redirect_uri</spanx> 値.
            </t>
            <!--
            <t hangText="client_id">
              <spanx style="verb">redirect_uri</spanx> value of the Client.
            </t>
            -->
            <t hangText="client_secret_expires_at">
              0
            </t>
            <!--
            <t hangText="client_secret_expires_at">
              0
            </t>
            -->
          </list>
        </t>
        <t>
          注記: OpenID ファウンデーションは
          <spanx style="verb">https://self-issued.me/registration/1.0/</spanx>
          という (ステートレスな) エンドポイントを提供することを計画しており, そのエンドポイントは上記レスポンスを返すため, RP は Self-Issued OP の登録のために特別な処理を行う必要はない.
          このサイトは実験的に提供される予定である.
          プロダクション環境を実装する際は, OpenID ファウンデーションが当該サイトをプロダクション用途を想定して提供するまでその環境に依存すべきではない.
        </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 は Client が Self-Issued OpenID プロバイダーに追加の登録情報を提供することが出来るようにするために以下の認可リクエストパラメータを定義している.
            <!--
            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">
                任意 (OPTIONAL).
                このパラメータは通常, Dynamic Client Registration の間に Client が自身の情報を Self-Issued OP に提供する際に利用される.
                この値は
                <xref target="OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</xref>
                仕様の Section 2.1 で定義されている Client メタデータの値を含む JSON オブジェクトである.
                <spanx style="verb">registration</spanx> パラメータは OP が Self-Issued OP ではないときは利用すべきではない (SHOULD NOT).
              </t>
              <!--
              <t hangText="registration">
                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>
            この情報の中で Self-Issued OP により必須 (REQUIRED) なものはなく, このパラメータの利用は任意 (OPTIONAL) である.
          </t>
          <!--
          <t>
            None of this information is REQUIRED by Self-Issued OPs,
            so the use of this parameter is OPTIONAL.
          </t>
          -->
          <t>
            <spanx style="verb">registration</spanx> パラメータの値は OAuth 2.0 リクエストの中で UTF-8 エンコードされた JSON として表わされる.
            (OAuth パラメータとして渡される際, form-urlencoded される).
          </t>
          <!--
          <t>
            The <spanx style="verb">registration</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).
          </t>
          -->
          <t>
            Self-Issued OP へのリクエストの中で典型的に利用する登録パラメータは以下である.
            <spanx style="verb">policy_uri</spanx>,
            <spanx style="verb">tos_uri</spanx>, and
            <spanx style="verb">logo_uri</spanx>.
            Client が一つ以上の Redirection URI を使用する際, それらを登録するために
            <spanx style="verb">redirect_uris</spanx>
            パラメータを利用する.
          </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.
          </t>
          -->
        </section>
      </section>

      <section anchor="SelfIssuedRequest" title="Self-Issued OpenID Provider Request">
        <t>Client は Authorization Endpoint へ以下のパラメータを付けて Authentication Request を送信する.</t>
        <!--
        <t>The Client sends the Authentication Request to the Authorization Endpoint
        with the following parameters:</t>
        -->
        <t><list style="hanging">
          <t hangText="response_type">
            必須 (REQUIRED). 固定の文字列 <spanx style="verb">id_token</spanx>.
          </t>
          <!--
          <t hangText="response_type">
            REQUIRED. Constant string value <spanx style="verb">id_token</spanx>.
          </t>
          -->
          <t hangText="client_id">
            必須 (REQUIRED).
            Client の Client ID, この場合は Client の
            <spanx style="verb">redirect_uri</spanx> の値を含む.
            Client の
            <spanx style="verb">redirect_uri</spanx> URI の値は Client ID として送信されるので,
            <spanx style="verb">redirect_uri</spanx> パラメータをリクエストの中に含む必要はない (NOT REQUIRED).
          </t>
          <!--
          <t hangText="client_id">
            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="scope">
            必須 (REQUIRED).
            <xref target="RequestParameters"/> で定義されている <spanx style="verb">scope</spanx> パラメータの値.
          </t>
          <!--
          <t hangText="scope">
            REQUIRED.
            <spanx style="verb">scope</spanx> parameter value,
            as defined in <xref target="RequestParameters"/>.
          </t>
          -->
          <t hangText="id_token_hint">
            任意 (OPTIONAL).
            <xref target="RequestParameters"/> で定義されている <spanx style="verb">id_token_hint</spanx> パラメータの値.
          </t>
          <!--
          <t hangText="id_token_hint">
            OPTIONAL.
            <spanx style="verb">id_token_hint</spanx> parameter value,
            as specified in <xref target="RequestParameters"/>.
          </t>
          -->
          <t hangText="registration">
            任意 (OPTIONAL).
            このパラメータは通常 <xref target="RegistrationParameter"/> で定義されているように, Dynamic Client Registration の間に Client が自身の情報を Self-Issued OP に提供する際に利用される.
          </t>
          <!--
          <t hangText="registration">
            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>
          -->
        </list>
        </t>
        <t>
          他のパラメータも送ってもよい (MAY).
          すべての Claim は ID Token の中で返されることに留意すること.
        </t>
        <!--
        <t>
          Other parameters MAY be sent.
          Note that all Claims are returned in the ID Token.
        </t>
        -->
        <t>全体 URL 長は ASCII で 2048 文字を超えてはならない (MUST NOT).</t>
        <!--
        <t>The entire URL MUST NOT exceed 2048 ASCII characters.</t>
        -->
        <figure>
          <preamble>
            以下は, User Agent が Self-Issued OpenID プロバイダーに対して Authentication Request を生成するためのトリガーとなる, Client による HTTP 302 リダイレクトレスポンスの参考例である.
            (改行は掲載上の都合による)
            <!--
            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>Self-Issued OpenID プロバイダーのレスポンスは, 通常の Implicit フローのレスポンスに以下の改変をしたものと同じである. Implicit フローのレスポンスなので, レスポンスパラメータは URL フラグメントコンポーネントの中で返される.
        </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.
        </t>
        -->
        <t><list style="numbers">
          <t>
            <spanx style="verb">iss</spanx> (issuer) Claim の値が
            <spanx style="verb">https://self-issued.me</spanx> である.
          </t>
          <!--
          <t>
            The <spanx style="verb">iss</spanx> (issuer) Claim Value is
            <spanx style="verb">https://self-issued.me</spanx>.
          </t>
          -->
          <t>
            <spanx style="verb">sub_jwk</spanx> Claim が存在し, その値が ID Token の署名を検証するための公開鍵となっている.
          </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>
            <spanx style="verb">sub</spanx> (subject) Claim の値は
            <spanx style="verb">sub_jwk</spanx> Claim の中の Base64URL エンコードされたキー値の UTF-8 表現のオクテットを結合したものの SHA-256 ハッシュを Base64URL エンコードしたものである.
            <spanx style="verb">kty</spanx> の値が
            <spanx style="verb">RSA</spanx> である時, キーの値は
            <spanx style="verb">n</spanx> と,
            <spanx style="verb">e</spanx> が順に結合されたものである.
            <spanx style="verb">kty</spanx> の値が
            <spanx style="verb">EC</spanx> である時, キーの値は
            <spanx style="verb">crv</spanx> と,
            <spanx style="verb">x</spanx> と,
            <spanx style="verb">y</spanx> が順に結合されたものである.
          </t>
          <!--
          <t>
            The <spanx style="verb">sub</spanx> (subject) Claim
            value is the base64url encoded SHA-256 hash of
            the concatenation of the octets of the UTF-8 representations of
            the base64url encoded key values in the
            <spanx style="verb">sub_jwk</spanx> Claim.
            When the <spanx style="verb">kty</spanx> value is
            <spanx style="verb">RSA</spanx>, the key values
            <spanx style="verb">n</spanx> and
            <spanx style="verb">e</spanx> are concatenated in that order.
            When the <spanx style="verb">kty</spanx> value is
            <spanx style="verb">EC</spanx>, the key values
            <spanx style="verb">crv</spanx>,
            <spanx style="verb">x</spanx>, and
            <spanx style="verb">y</spanx> are concatenated in that order.
          </t>
          -->
          <t>
            UserInfo エンドポイントへアクセスするための Access Token は返されないため,
            すべての Claim は ID Token の中で返されなければならない (MUST).
          </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>
          返された ID Token の検証を行うため, Client は以下のことを実施しなくてはならない (MUST).
        </t>
        <!--
        <t>
          To validate the ID Token received, the Client MUST do the following:
        </t>
        -->
        <t>
          <list style="numbers">
            <t>
              Client は, <spanx style="verb">iss</spanx> (issuer) Claim の値が <spanx style="verb">https://self-isued.me</spanx> であることを検証しなければならない (MUST).
              もし <spanx style="verb">iss</spanx> が別の値を含んでいた場合,
              その ID Token は Self-Issued ではないので,
              <xref target="IDTokenValidation"/>
              に沿って検証されなければならない (MUST).
            </t>
            <!--
            <t>
              The Client MUST validate that the value of the <spanx style="verb">iss</spanx> (issuer) Claim is <spanx style="verb">https://self-isued.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>
              Client は, Client が認証リクエストで送信した <spanx style="verb">redirect_uri</spanx> の値が, <spanx style="verb">aud</spanx> Claim にオーディエンスとして含まれていることを検証しなければならない (MUST).
            </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>
              Client は, JWT ヘッダ <xref target="JWT"/> の <spanx style="verb">alg</spanx> パラメータに指定されたアルゴリズムを使い <xref target="JWS">JWS</xref> に沿って ID Token の署名を検証しなければならない (MUST).
              その際, <spanx style="verb">sub_jwk</spanx> Claim の中の鍵を使用する;
              鍵は <xref target="JWK"/> フォーマットの鍵である (X.509 証明書ではない).
            </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> parameter of the JWT header <xref target="JWT"/>,
              using the key in the <spanx style="verb">sub_jwk</spanx> Claim;
              the key is a bare key in JWK <xref target="JWK"/> format
              (not an X.509 certificate value).
            </t>
            -->
            <t>
              <spanx style="verb">alg</spanx> の値はデフォルトとしては <spanx style="verb">RS256</spanx> であるべきである (SHOULD).
              この値は <spanx style="verb">ES256</spanx> であってもよい (MAY).
            </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>
              Client は <spanx style="verb">sub</spanx> (subject) Claim の値が
              Base64URL エンコードされた <spanx style="verb">sub_jwk</spanx> Claim の中のキーの値が Base64URL エンコードされた UTF-8 表現のオクテットを結合したものの SHA-256 ハッシュであることを検証しなくてはならない (MUST).
              <spanx style="verb">kty</spanx> の値が
              <spanx style="verb">RSA</spanx> である時, キーの値は
              <spanx style="verb">n</spanx> と
              <spanx style="verb">e</spanx> が順に結合されたものである.
              <spanx style="verb">kty</spanx> の値が
              <spanx style="verb">EC</spanx> である時, キーの値は
              <spanx style="verb">crv</spanx> と,
              <spanx style="verb">x</spanx> と,
              <spanx style="verb">y</spanx> が順に結合されたものである.
            </t>
            <!--
            <t>
              The Client MUST validate that the <spanx style="verb">sub</spanx> (subject) Claim
              value is the base64url encoded SHA-256 hash of
              the concatenation of the octets of the UTF-8 representations of
              the base64url encoded key values in the
              <spanx style="verb">sub_jwk</spanx> Claim.
              When the <spanx style="verb">kty</spanx> value is
              <spanx style="verb">RSA</spanx>, the key values
              <spanx style="verb">n</spanx> and
              <spanx style="verb">e</spanx> are concatenated in that order.
              When the <spanx style="verb">kty</spanx> value is
              <spanx style="verb">EC</spanx>, the key values
              <spanx style="verb">crv</spanx>,
              <spanx style="verb">x</spanx>, and
              <spanx style="verb">y</spanx> are concatenated in that order.
            </t>
            -->
            <t>
              現在時刻が <spanx style="verb">exp</spanx> Claim より前でなければならない (MUST).
              (時計のズレを考慮した多少の猶予は許容される)
            </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>
              <spanx style="verb">iat</spanx> Claim が現在時刻からあまりにかけ離れている場合は, そのトークンを拒絶してもよい.
              これにより nonce の保存期間を制限することができる.
              適切な閾値は, Client ごとにことなる.
            </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>
              nonce が Authentication Request で送られた場合,
              <spanx style="verb">nonce</spanx> Claim が存在し,
              その値は Authentication Request で送られたものと同じ値であることを検証されなくてはならない (MUST).
              Client はリプレイアタックを防ぐため <spanx style="verb">nonce</spanx> の値を検証すべきである (SHOULD).
              リプレイアタックを検知するための詳細は方法は Client ごとに固有である.
            </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 of the 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>以下は Self-Issued ID Token を Base64URL デコードした参考例である.
          (改行は掲載上の都合による)</preamble>
          <!--
          <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": "wBy8QvHbPzUnL0x63h13QqvUYcOur1X0cbQpPVRqX5k",
   "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="Serializations" title="Serializations">
      <t>
        リクエストメッセージは以下のいずれかの方法でシリアライズできる (MAY).
        <!--
        A request message MAY be serialized using one of the following methods:
        -->
        <list style="numbers">
          <t>Query String Serialization</t>
          <t>Form Serialization</t>
        </list>
      </t>

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

        <t>Query String Serialization を使ってパラメータをシリアライズするためには,
        Client は <xref target="W3C.REC-html401-19991224"/> で定義された
        <spanx style="verb">application/x-www-form-urlencoded</spanx> フォーマットを使いパラメータと値をクエリコンポーネントへ追加することで文字列を構成する.
        Query String Serialization は一般的に
        HTTP <spanx style="verb">GET</spanx> リクエストで使用される.
        同じシリアライズ手法は URL のフラグメントコンポーネントにパラメータを追加する際にも使用される.
        </t>
        <!--
        <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 using the <spanx
        style="verb">application/x-www-form-urlencoded</spanx> format as
        defined by <xref target="W3C.REC-html401-19991224"/>.
        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>
            以下はシリアライズの参考例である.
            (改行は掲載上の都合による)
            <!--
            Following is a non-normative example of this serialization
            (with line wraps within values for display purposes only):
            -->
          </preamble>

          <artwork><![CDATA[
  GET /authorize?scope=openid
    &response_type=id_token%20token
    &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>パラメータやその値は, HTTP リクエストのエンティティボディに <xref target="W3C.REC-html401-19991224"/> に定義されているように <spanx style="verb">application/x-www-form-urlencoded</spanx> フォーマットでパラメータ名とその値を追加することで Form Serialize される.
        Form Serialization は一般的には HTTP <spanx style="verb">POST</spanx> リクエストで利用される.</t>
        <!--
        <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"/>.
        Form Serialization is typically used in HTTP <spanx style="verb">POST</spanx> requests.</t>
        -->

        <figure>
          <preamble>
            以下はシリアライズの参考例である.
            (改行は掲載上の都合による)
            <!--
            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

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

    </section>

    <section anchor="StringOps" title="String Operations">
      <t>
        いくつかの OpenID Connect メッセージを処理する際にはメッセージの中の値を既知の値を比較することが求められる.
        例えば, UserInfo エンドポイントから返された Claim Name は <spanx style="verb">sub</spanx> などの特定の Claim Name と比較される.
        よって Unicode 文字列比較処理はセキュリティ上重要な意味を持つ.
      </t>
      <!--
      <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 strings,
        however, has significant security implications.
      </t>
      -->
      <t>
        したがって, JSON 文字列を他の Unicode 文字列と比較する際は下記の通り実施しなければならない (MUST).
        <!--
        Therefore, comparisons between JSON strings and other Unicode
        strings MUST be performed as specified below:
        -->
        <list style="numbers">
          <t>
            JSON に適用されたすべてのエスケープ処理を取り除き Unicode コードポイントの配列を生成する.
          </t>
          <!--
          <t>
            Remove any JSON applied escaping to produce an array of
            Unicode code points.
          </t>
          -->
          <t>
            Unicode Normalization <xref target="USA15"/> を JSON 文字列, もしくは比較対象文字列に対していかなる時点であっても適用してはならない (MUST NOT).
          </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>
            二つの文字列の比較は, Unicode コードポイント同士の等値比較として実施されなければならない (MUST).
          </t>
          <!--
          <t>
            Comparisons between the two strings MUST be performed as a
            Unicode code point to code point equality comparison.
          </t>
          -->
        </list>
      </t>
      <t>
        いくつかの箇所において, 本仕様はスペースで区切られた文字列のリストを使用している.
        そのようないかなる場合においても, この目的では ASCII のスペース文字 (0x20)
        のみを使用しなければならない (MUST).
      </t>
      <!--
      <t>
        In several places, this specification uses space delimited
        lists of strings.  In all such cases, the ASCII space
        character (0x20) MUST be the only character used for this purpose.
      </t>
      -->

    </section>

    <section anchor='TLS' title='TLS Version'>
      <t>
        本仕様では Transport Layer Security (TLS) が用いられるが, 実際に広く使われているかどうかや既知のセキュリティ脆弱性に依存して, TLS の適切なバージョンはその時々で異なりうる.
        本仕様執筆時には, TLS バージョン 1.2 <xref target='RFC5246' />　が最新であるが, 実装が限定されており, すぐに各実装で利用可能とはいえないかもしれない.
        TLS バージョン 1.0 <xref target='RFC2246' /> は現在もっとも広く利用されているバージョンで, 最も広範な相互運用性を提供するであろう.
      </t>
      <!--
      <t>
        Whenever Transport Layer Security (TLS) is used by this specification,
        the appropriate version (or versions) of
        TLS will vary over time, based on the widespread deployment and known security
        vulnerabilities. At the time of this writing, TLS version 1.2 <xref target='RFC5246' />
        is the most recent version, but has a very limited deployment base and might not be
        readily available for implementation. TLS version 1.0 <xref target='RFC2246' /> is the
        most widely deployed version and will provide the broadest interoperability.
      </t>
      -->
    </section>

    <section anchor="ImplementationConsiderations" title="Implementation Considerations">
      <t>
        本仕様書では Relying Party が, OAuth Implicit Flow で利用する機能を定義する.
        Relying Parties は本仕様書内で "REQUIRED" であると記載されている, もしくは "MUST" 付きで説明されている機能を実装しなければならない (MUST).
      </t>
      <!--
      <t>
        This specification defines features used by Relying Parties
        using the OAuth Implicit Flow.
        These Relying Parties MUST implement the features that are listed
        in this specification as being "REQUIRED" or are described with a "MUST".
      </t>
      -->

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

        <t>
          OpenID Connect 環境によっては, あらかじめ設定された OpenID Provider や Relying Party を利用することができる.
          その場合, アイデンティティ情報やサービス情報の Discovery や Client の Dynamic Registration をサポートする必要はないかもしれない.
        </t>
        <!--
        <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>
          しかしながら, 事前の信頼構築を前提とせず, Relying Party と OpenID Provider の間での事前予測不可能な形でのインタラクションをサポートする場合には, <xref target="OpenID.Discovery">OpenID Connect Discovery 1.0</xref> と <xref target="OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</xref> によってこれを実現すべきである (SHOULD).
        </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>

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

      <t>
        以下に挙げたもの以外のセキュリティ上の考慮点については,
        <xref target="OpenID.Core">OpenID Connect Core 1.0</xref> 仕様を参照すること.
      </t>
      <!--
      <t>
        For security considerations other than those listed below, refer to the
        <xref target="OpenID.Core">OpenID Connect Core 1.0</xref> specification.
      </t>
      -->

      <section anchor="TLSRequirements" title="TLS Requirements">
        <t>
          実装する際は TLS をサポートしなくてはならない (MUST).
          どのバージョンを実装するかは時期によって異なり, 実装時に広く使われているかと既知のセキュリティ上の脆弱性に依存する.
          本仕様を執筆している段階では TLS バージョン 1.2 <xref target='RFC5246' /> が最新バージョンであるが, 実際に使われている例は非常に限られており, 実装に利用するツールキットが対応していない可能性もある.
          TLS version 1.0 <xref target='RFC2246' /> が最も広く使われているバージョンであり, 最も高い相互運用性を提供している.
        </t>
        <!--
        <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>
          情報の漏えいや改ざんを防ぐため, TLS を使った機密保護を, 機密性と完全性の保護を提供する暗号スイートを用いて適用しなくてはならない (MUST).
        </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>
          TLS を使用する際は, <xref target="RFC6125">RFC 6125</xref> に従い TLS サーバ証明書を検証しなければならない (MUST).
        </t>
        <!--
        <t>
          Whenever TLS is used, a TLS server certificate check
          MUST be performed, per <xref target="RFC6125">RFC 6125</xref>.
        </t>
        -->
      </section>
    </section>

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

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

        <t>
          UserInfo Response は一般的には Personally Identifiable Information (PII) を含む.
          したがって, 特定の目的のための情報の開示に関する End-User の同意は, 関連する法律に従い, 認可時もしくは認可時に先立って取得されるべきである (SHOULD).
          利用目的は一般的には <spanx style="verb">redirect_uris</spanx> とともに登録される.
        </t>
        <!--
        <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>
          必要な UserInfo データだけが Client 側に保管されるべきであり, Client は受信したデータを告知した利用目的と関連づけるべきである (SHOULD).
        </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>
          Resource Server は End-User に対して, 誰が自分のデータにアクセスしたかを監視できよう, 自身の UserInfo へのアクセスログを閲覧可能にべきである (SHOULD).
        </t>
        <!--
        <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>
          Client 間での名寄せの可能性からエンドユーザを保護するため, Pairwise Pseudonymous Identifier (PPID) を <spanx style="verb">sub</spanx> (subject) として使用することを検討すべきである (SHOULD).
        </t>
        <!--
        <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>

    <section anchor="IANA" title="IANA Considerations">
      <t>本仕様から IANA への要求事項は存在しない.</t>
      <!--
      <t>This document makes no requests of IANA.</t>
      -->
    </section>

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3339"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3966"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4627"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5646"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6711"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6749"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6750"?>

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

      <reference anchor="USA15">
        <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>

          <author fullname="Martin D&uuml;rst" initials="M." surname="D&uuml;rst">
          </author>

          <date day="03" month="09" year="2009" />
        </front>

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

      <reference anchor="ISO29115">
        <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" />
        <format target="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45138"
                type="HTML" />
      </reference>

      <reference anchor="ISO639-1">
        <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">
        <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>

        <format target="http://www.w3.org/WAI/ER/IG/ert/iso639.htm"
                type="HTML" />
      </reference>

      <reference anchor="ISO8601-2004">
        <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">
        <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>

        <format target="http://www.itu.int/rec/T-REC-E.164-201011-I/en"
                type="HTML" />
      </reference>

      <reference anchor="zoneinfo">
        <front>
          <title>The tz database</title>

          <author fullname="Public Domain">
            <organization abbrev="Public">Public Domain</organization>
          </author>

          <date month="June" year="2011" />
        </front>

        <format target="http://www.twinsun.com/tz/tz-link.htm" type="HTML" />
      </reference>

      <reference anchor="OpenID.Core">
        <front>
          <title>OpenID Connect Core 1.0</title>

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

          <author fullname="John Bradley" initials="J." surname="Bradley">
            <organization abbrev="Ping Identity">Ping Identity</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="Salesforce">Salesforce</organization>
          </author>

          <date day="18" month="December" year="2013"/>
        </front>

        <format target="http://openid.net/specs/openid-connect-core-1_0.html"
                type="HTML" />
      </reference>

      <reference anchor="OpenID.Discovery">
        <front>
          <title>OpenID Connect Discovery 1.0</title>

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

          <author fullname="John Bradley" initials="J." surname="Bradley">
            <organization abbrev="Ping Identity">Ping Identity</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="18" month="December" year="2013"/>
        </front>

        <format target="http://openid.net/specs/openid-connect-discovery-1_0.html"
                type="HTML" />
      </reference>

      <reference anchor="OpenID.Registration">
        <front>
          <title>OpenID Connect Dynamic Client Registration 1.0</title>

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

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

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

          <date day="18" month="December" year="2013"/>
        </front>

        <format target="http://openid.net/specs/openid-connect-registration-1_0.html"
                type="HTML" />
      </reference>

      <reference anchor="JWT">
        <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 day="12" month="November" year="2013" />
        </front>

        <seriesInfo value="draft-ietf-oauth-json-web-token" name="Internet-Draft"/>
        <format target="http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-13"
                type="HTML" />
      </reference>

      <reference anchor="JWS">
        <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 day="12" month="November" year="2013" />
        </front>

        <seriesInfo value="draft-ietf-jose-json-web-signature" name="Internet-Draft"/>
        <format target="http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-18" type="HTML" />
      </reference>

      <reference anchor="JWK">
        <front>
          <title>JSON Web Key (JWK)</title>

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

          <date day="12" month="November" year="2013" />
        </front>

        <seriesInfo value="draft-ietf-jose-json-web-key" name="Internet-Draft"/>
        <format target="http://tools.ietf.org/html/draft-ietf-jose-json-web-key-18" type="HTML" />
      </reference>

      <reference anchor="JWA">
        <front>
          <title>JSON Web Algorithms (JWA)</title>

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

          <date day="12" month="November" year="2013" />
        </front>

        <seriesInfo value="draft-ietf-jose-json-web-algorithms" name="Internet-Draft"/>
        <format target="http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-18" type="HTML" />
      </reference>

      <reference anchor="OAuth.Responses">
        <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="18" month="December" year="2013" />
        </front>

        <format target="http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html"
                type="HTML" />
      </reference>

      <reference anchor="IANA.Language">
        <front>
          <title>Language Subtag Registry</title>
          <author>
            <organization>Internet Assigned Numbers Authority (IANA)</organization>
          </author>
          <date year="2005"/>
        </front>

        <format target="http://www.iana.org/assignments/language-subtag-registry"
                type="TXT" />
      </reference>

    </references>
    <references title="Informative References">

      <reference anchor="OpenID.Basic">
        <front>
          <title>OpenID Connect Basic Client Implementer's Guide 1.0</title>

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

          <author fullname="John Bradley" initials="J." surname="Bradley">
            <organization abbrev="Ping Identity">Ping Identity</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="Salesforce">Salesforce</organization>
          </author>

          <date day="18" month="December" year="2013"/>
        </front>

        <format target="http://openid.net/specs/openid-connect-basic-1_0.html"
                type="HTML" />
      </reference>

    </references>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
        The OpenID Community would like to thank the following people for
        their contributions to this specification:
      </t>
      <!--
      <t>
        The OpenID Community would like to thank the following people for
        their contributions to this specification:
      </t>
      -->
      <t>
        <list style="empty">
          <t>Naveen Agarwal (naa@google.com), Google</t>
          <t>Casper Biering (cb@peercraft.com), Peercraft</t>
          <t>John Bradley (ve7jtb@ve7jtb.com), Ping Identity</t>
          <t>Tim Bray (tbray@textuality.com), Google</t>
          <t>Johnny Bufu (jbufu@janrain.com), Janrain</t>
          <t>Breno de Medeiros (breno@google.com), Google</t>
          <t>Pamela Dingle (pdingle@pingidentity.com), Ping Identity</t>
          <t>George Fletcher (george.fletcher@corp.aol.com), AOL</t>
          <t>Roland Hedberg (roland.hedberg@adm.umu.se), University of Umea</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 (t.lodderstedt@telekom.de), Deutsche Telekom</t>
          <t>Nov Matake (nov@matake.jp), Independent</t>
          <t>Chuck Mortimore (cmortimore@salesforce.com), 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 (dr@fb.com), Facebook</t>
          <t>Justin Richer (jricher@mitre.org), MITRE</t>
          <t>Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute, Ltd.</t>
          <t>Luke Shepard (lshepard@fb.com), Facebook</t>
          <t>Andreas &Aring;kre Solberg (andreas.solberg@uninett.no), UNINET</t>
          <t>Paul Tarjan (pt@fb.com), Facebook</t>
        </list>
      </t>
    </section>

    <section anchor="Notices" title="Notices">
      <t>Copyright (c) 2013 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 final specification ]]</t>

      <t>
        -14
        <list style="symbols">
          <t>
            Fixed #896 - Replaced the term Authorization Request with
            Authentication Request, where applicable.
          </t>
          <t>
            Incorporated terms defined by the JWT specification.
          </t>
          <t>
            Applied proofreading corrections by Michael B. Jones.
          </t>
        </list>
      </t>
      <t>
        -13
        <list style="symbols">
          <t>
            Updated the <spanx style="verb">response_type</spanx> language.
          </t>
          <t>
            Fixed #878 - Generalized description of errors that can be returned
            when <spanx style="verb">id_token_hint"</spanx> is used.
          </t>
          <t>
            Provided more context in the introduction.
          </t>
          <t>
            Expanded the Authentication Request example to show both
            the 302 redirect response by the Client and the resulting
            HTTP GET request sent by the User Agent.
          </t>
        </list>
      </t>

      <t>
        -12
        <list style="symbols">
          <t>
            Tracked editorial changes applied to OpenID Connect Core.
          </t>
          <t>
            Fixed #862 - Clarified <spanx style="verb">azp</spanx> definition.
          </t>
          <t>
            Fixed #878 - Defined negative response for "id_token_hint".
          </t>
          <t>
            Updated the description of the plans to host the site
            <spanx style="verb">https://self-issued.me/</spanx>,
            per tasks #879 and #880.
          </t>
          <t>
            Replaced uses of the OpenID Connect Messages and OpenID Connect Standard
            specifications with OpenID Connect Core.
          </t>
          <t>
            Fixed #884 - Changed the descriptions of Basic and Implicit from being profiles
            to being implementer's guides containing subsets of OpenID Connect Core.
          </t>
        </list>
      </t>

      <t>
        -11
        <list style="symbols">
          <t>
            Fixed #847 - Corrected type of <spanx style="verb">updated_at</spanx>
            to number.
          </t>
          <t>
            Stated that <spanx style="verb">redirect_uri</spanx> matches must be exact,
            with matching performed as described in
            Section 6.2.1 of RFC 3986 (Simple String Comparison).
          </t>
          <t>
            Fixed #854 - Clarified that the <spanx style="verb">acr_values</spanx> values
            are in order of preference and that <spanx style="verb">acr_values</spanx>
            requests the <spanx style="verb">acr</spanx> Claim as a Voluntary Claim.
          </t>
          <t>
            Fixed #858 - Incorporated elements of the Issuer Identifier definition
            into the <spanx style="verb">iss</spanx> Claim description.
          </t>
          <t>
            Fixed #859 - Added IMPORTANT NOTE TO READERS about the terminology
            definitions being a normative part of the specification.
          </t>
        </list>
      </t>

      <t>-10
        <list style="symbols">
          <t>
            Stated that sufficient entropy must be present in
            <spanx style="verb">nonce</spanx> values to prevent
            attackers from guessing values.
          </t>
          <t>
            Stated that 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>
            Restricted the meaning of the <spanx style="verb">azp</spanx>
            (authorized party) Claim to simply be the single party
            to which the ID Token was issued.
          </t>
          <t>
            Changed from using the term "byte" to either "octet" or "character".
          </t>
          <t>
            Stated that the JWS Compact Serialization is always used
            for JWS data structures.
          </t>
        </list>
      </t>

      <t>-09
        <list style="symbols">
          <t>
            Fixed #825 - Replaced <spanx style="verb">updated_time</spanx>, which used the
            RFC 3339 textual time format, with <spanx style="verb">updated_at</spanx>,
            using the numeric time format used by <spanx style="verb">iat</spanx>, etc.
          </t>
          <t>
            Fixed #829 - Stated that additional scope values can be defined and used
            and that scope values that are not understood should be ignored.
          </t>
          <t>
            Fixed #831 - Stated that JWS and JWE header parameters used to communicate
            key values and key references should not be used in ID Tokens, since these
            are communicated in advance using Discovery and Registration parameters.
          </t>
          <t>
            Fixed #712 and #830 - Clarified the <spanx style="verb">azp</spanx>
            description and made <spanx style="verb">azp</spanx> multi-valued,
            like <spanx style="verb">aud</spanx>.
          </t>
        </list>
      </t>

      <t>-08
        <list style="symbols">
          <t>
            Fixed #802 - Clarified recommendations and responsibilities for
            producing and consuming Claims with and without language tags.
          </t>
          <t>
            Fixed #797 - Clarified the intended semantics of e-mail verification
            and that the precise verification rules are context-specific.
          </t>
          <t>
            Fixed #806 - Added <spanx style="verb">phone_number_verified</spanx> Claim.
          </t>
          <t>
            Fixed #800 - Specified that phone number extensions are to be
            represented using RFC 3966 extension syntax.
          </t>
          <t>
            Fixed #795 - Specified that e-mail addresses must conform to the
            RFC 5322 addr-spec syntax.
          </t>
          <t>
            Fixed #808 - Specified that phone numbers may be used as
            <spanx style="verb">login_hint</spanx> values.
          </t>
          <t>
            Fixed #801 - Removed <spanx style="verb">schema</spanx> and <spanx style="verb">id</spanx>
            parameters to UserInfo Endpoint.
            Also fixed related issue #791 - Removed <spanx style="verb">invalid_schema</spanx> error.
          </t>
          <t>
            Fixed #793, #796, and #799 - Allow name Claims to contain multiple space-separated names.
          </t>
          <t>
            Fixed #794 - Required <spanx style="verb">picture</spanx>
            to refer to an image file that is a picture of the End-User.
          </t>
          <t>
            Fixed #811 - Specify that language tag components should be spelled using
            the character cases registered in the IANA Language Subtag Registry.
          </t>
          <t>
            Fixed #812 - Clarified that language tag values used need not be
            unnecessarily specific.
          </t>
          <t>
            Fixed #816 - Changed "must understand" language to "MUST be ignored if not understood".
          </t>
        </list>
      </t>

      <t>-07
        <list style="symbols">
          <t>
            Fixed #711 - Awkward phrase "The following Claims are REQUIRED and OPTIONAL".
          </t>
          <t>
            Fixed #712 - "azp" definition clarification.
          </t>
          <t>
            Fixed #713 - Explicitly require "sub" claim to be returned from UserInfo endpoint.
          </t>
          <t>
            Fixed #716 - Client/server 2119 blurriness.
          </t>
          <t>
            Fixed #722 - Text on "id_token_hint" needs to be clarified.
          </t>
          <t>
            Fixed #718 - Text on re-encrypting should be clearer.
          </t>
          <t>
            Fixed #732 - Capitalize name of "Bearer" authentication scheme.
          </t>
          <t>
            Fixed #738 - Behavior when "openid" scope is omitted.
          </t>
          <t>
            Added Security Considerations section about TLS version requirements and usage.
          </t>
          <t>
            Removed language about clients that do not support TLS.
            Also removed language about supporting other transport-layer
            mechanisms with equivalent security to TLS.
          </t>
          <t>
            State that when any validations fail, any operations requiring
            the information that failed to correctly validate MUST be aborted and
            the information that failed to validate MUST NOT be used.
          </t>
          <t>
            Added <spanx style="verb">id_token_hint</spanx> parameter to Implicit, since
            it SHOULD be present when <spanx style="verb">prompt=none</spanx> is used.
          </t>
          <t>
            Removed vestigial encryption text that had been copied over from Standard,
            since encryption is not part of the Implicit profile.
          </t>
          <t>
            Fixed #742 - Added new <spanx style="verb">ui_locales</spanx> parameter.
          </t>
          <t>
            Fixed #743 - Added <spanx style="verb">claims_locales</spanx> parameter.
          </t>
          <t>
            Fixed #744 - Added <spanx style="verb">max_age</spanx> parameter.
          </t>
          <t>
            Fixed #765 - Added new <spanx style="verb">acr_values</spanx> parameter.
          </t>
          <t>
            Fixed #597 - Changed representation of omitted year in <spanx style="verb">birthdate</spanx>
            from <spanx style="verb">9999</spanx> to <spanx style="verb">0000</spanx>.
          </t>
          <t>
            Fixed #739 - Added registration parameter and members of registration object.
          </t>
          <t>
            Deleted top-level <spanx style="verb">policy_url</spanx> parameter from the
            Self-Issued case, since it is already a
            <spanx style="verb">registration</spanx> parameter member.
          </t>
          <t>
            Fixed #778 - Added <spanx style="verb">registration</spanx> parameter
            to Self-Issued request example.
          </t>
          <t>
            Fixed #782 - Changed uses of "_url" in identifiers to "_uri".
          </t>
          <t>
            Consolidated the
            <spanx style="verb">x509_encryption_uri</spanx> and
            <spanx style="verb">jwk_encryption_uri</spanx> parameters into
            a combined <spanx style="verb">jwk_uri</spanx> parameter (per other changes related to #703).
          </t>
          <t>
            Fixed #786 - Changed the name of <spanx style="verb">jwk_uri</spanx>
            to <spanx style="verb">jwks_uri</spanx>.
          </t>
          <t>
            Clarified when the <spanx style="verb">http</spanx> scheme can and can not
            be used in <spanx style="verb">redirect_uri</spanx> values.
          </t>
          <t>
            Stated that the <spanx style="verb">azp</spanx> Claim
            is only needed when the party requesting the ID Token
            is different than the audience of the ID Token.
          </t>
          <t>
            Use legal <spanx style="verb">acr</spanx> values in examples.
          </t>
          <t>
            Fixed #789 - Added <spanx style="verb">amr</spanx>
            (authentication methods references) Claim.
          </t>
        </list>
      </t>

      <t>-06
        <list style="symbols">
          <t>
            Fixed #637 removed requirement for hash of at_token and code to be SHA2 in
            Section 2.1.2.1 and Section 5.2.
          </t>
          <t>Added Section 2.5 Access Token Validation.</t>
          <t>
            Fixed #620 - Update Section 2.2.5.1 to allow for other token types, but make bearer mandatory to support for implicit clients.
          </t>
          <t>Fixed #657 - Update Section 3.3 to say that the sub is sent as the kid if the id_token is encrypted in the request.</t>
          <t>
            Added Implementation Considerations section.
          </t>
          <t>
            Fixed #698 - Inconsistent use of articles.
          </t>
          <t>Updated Scopes description.</t>
          <t>Added auth_time definition to ID Token schema.</t>
          <t>
            Fixed #655 - Specify UTF-8 as encoding scheme whenever necessary.
          </t>
          <t>
            Renamed the <spanx style="verb">user_jwk</spanx> Claim to
            <spanx style="verb">sub_jwk</spanx>, paralleling the change from
            <spanx style="verb">user_id</spanx> to <spanx style="verb">sub</spanx>.
          </t>
          <t>
            Defined the <spanx style="verb">sub_jwk</spanx> claim.
          </t>
          <t>
            Clarified that the <spanx style="verb">offline_access</spanx> scope value
            MUST NOT be used with the Implicit Client Profile.
          </t>
          <t>
            To remove ambiguity in the self-issued <spanx style="verb">sub</spanx>
            computation, changed the text "the concatenation of the key values" to
            "the concatenation of the bytes of the UTF-8 representations of
            the base64url encoded key values".
          </t>
          <t>
            Tracked JWK parameter name changes alg -> kty, mod -> n, exp -> e.
          </t>
        </list>
      </t>

      <t>-05
        <list style="symbols">
          <t>
            Fixed #687 - Inconsistency between <spanx style="verb">user_id</spanx>
            and <spanx style="verb">prn</spanx> claims.  The fix changed these names:
            user_id -> sub, user_id_types_supported -> subject_types_supported,
            user_id_type -> subject_type, and prn -> sub.
          </t>
          <t>
            Fixed #689 - Track JWT change that allows JWTs to have multiple audiences.
          </t>
          <t>
            Fixed #660 - Clarified that returning the <spanx style="verb">sub</spanx>
            value from the UserInfo endpoint is mandatory.
          </t>
          <t>
            Fixed #636 - ID Token authorized party claim.
          </t>
          <t>
            Fixed #689 - Add caution about multiple audiences.
          </t>
          <t>Fixed #694 - Add login_hint</t>
        </list></t>

      <t>-04
        <list style="symbols">
          <t>Make it clear that nonce is REQUIRED for implicit</t>
          <t>RE #607 add example decoded id_token for non self-issued.</t>
          <t>
            Fixed #614 - Discovery - 3.2 Distinguishing between signature and integrity parameters for HMAC algorithms.
            This fix tracks the parameter changes made to the JWE spec in draft-ietf-jose-json-web-encryption-06.
            It deletes the parameters {userinfo,id_token}_encrypted_response_int.
            It replaces the parameters {userinfo,id_token,request_object,token_endpoint}_algs_supported
            with {userinfo,id_token,request_object,token_endpoint}_signing_alg_values_supported
            and {userinfo,id_token,request_object,token_endpoint}_encryption_{alg,enc}_values_supported.
          </t>
          <t>Fixed #666 - JWS signature validation vs. verification.</t>
          <t>Fixed #682 - Change remaining uses of "birthday" to "birthdate".</t>
          <t>Referenced OAuth 2.0 RFCs -- RFC 6749 and RFC 6750.</t>
      </list></t>

      <t>-03
        <list style="symbols">
          <t>Defined means of using a self-issued OP</t>
      </list></t>

      <t>-02
        <list style="symbols">
        <t>Added <spanx style="verb">preferred_username</spanx> claim
        under <spanx style="verb">profile</spanx> scope</t>
        <t>Added ID Token section to describe required claims</t>
        <t>Added section on claim stability</t>
        </list></t>

      <t>-01
        <list style="symbols">
          <t>Removed <spanx style="verb">claims_in_id_token</spanx> scope value,
          per decision on June 15, 2012 special working group call</t>
      </list></t>

      <t>-00
        <list style="symbols">
          <t>Initial version, based upon Basic Client specification version -17</t>
          <t>Renamed from Basic Client to Implicit Client, per issue #567</t>
          <t>Changed <spanx style="verb">verified</spanx> to
          <spanx style="verb">email_verified</spanx>, per issue #564</t>
          <t>Removed Check ID Endpoint and added ID token signature verification text,
          per issue #570</t>
          <t>Changed client.example.com to client.example.org, per issue #251</t>
          <t>Added claims_in_id_token scope definition to Basic and Implicit,
          per issue #594</t>
          <t>Use standards track version of JSON Web Token spec
          (draft-ietf-oauth-json-web-token)</t>
        </list>
      </t>

    </section>
  </back>
</rfc>