rfc6749.xml

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<rfc category="std" ipr="trust200902" obsoletes="5849" number="6749" submissionType="IETF" consensus="yes">

  <?rfc toc='yes' ?>
  <?rfc tocdepth='3' ?>
  <?rfc symrefs='yes' ?>
  <?rfc sortrefs='yes' ?>
  <?rfc compact='yes' ?>
  <?rfc subcompact='no' ?>
  <?rfc rfcedstyle="yes"?>

  <front>
    <title abbrev='OAuth 2.0'>The OAuth 2.0 Authorization Framework</title>

    <author fullname='Dick Hardt' surname='Hardt' initials='D' role='editor'>
      <organization>Microsoft</organization>
      <address>
        <email>dick.hardt@gmail.com</email>
        <uri>http://dickhardt.org/</uri>
      </address>
    </author>

    <date month="October" year="2012" />

    <area>Security</area>
    <workgroup>OAuth Working Group</workgroup>

    <abstract>
      <t>
        OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである.
        サードパーティーアプリケーションによるアクセス権の取得には, リソースオーナーとHTTPサービスの間で同意のためのインタラクションを伴う場合もあるが,
        サードパーティーアプリケーション自身が自らの権限においてアクセスを許可する場合もある.
        本仕様書はRFC 5849に記載されているOAuth 1.0 プロトコルを廃止し, その代替となるものである.
        <!--
        The OAuth 2.0 authorization framework enables a third-party application to obtain limited
        access to an HTTP service, either on behalf of a resource owner by orchestrating an approval
        interaction between the resource owner and the HTTP service, or by allowing the third-party
        application to obtain access on its own behalf. This specification replaces and obsoletes
        the OAuth 1.0 protocol described in RFC 5849.
        -->
      </t>
    </abstract>
  </front>

  <middle>

    <section title='はじめに'>
    <!-- <section title='Introduction'> -->
      <t>
        従来のクライアントサーバー型の認証モデルでは, クライアントはリソースオーナーのクレデンシャルを使ってサーバーに対して認証を行い, サーバー上の保護されたリソースにアクセスする.
        つまり, サードパーティーアプリケーションに保護されたリソースへのアクセス権を与えるには, リソースオーナーは自身のクレデンシャルをサードパーティーと共有する必要がある.
        これはいくつかの問題と制限をもたらす.
        <!--
        In the traditional client-server authentication model, the client requests an access-restricted
        resource (protected resource) on the server by authenticating with the server  using the resource
        owner's credentials. In order to provide third-party applications access to restricted resources,
        the resource owner shares its credentials with the third party.
        This creates several problems and limitations:
        -->
      </t>
      <t>
        <list style='symbols'>
          <t>
            サードパーティーアプリケーションは, 後の利用のためにリソースオーナーのクレデンシャルを保存しておかなければならない.
            特にパスワードは平文 (訳注: または復号可能な形) で保存されることになる.
            <!--
            Third-party applications are required to store the resource owner's credentials
            for future use, typically a password in clear-text.
            -->
          </t>
          <t>
            パスワードを利用することでセキュリティが低下したとしても, サーバーはパスワードベースの認証方式をサポートしなければならない.
            <!--
            Servers are required to support password authentication, despite the security
            weaknesses inherent in passwords.
            -->
          </t>
          <t>
            サードパーティーアプリケーションは, リソースオーナーの保護されたリソースに対して過度に広範囲のアクセス権を得ることになる一方で,
            リソースオーナーは, アクセスをリソースのサブセットに限定したりアクセス可能期間を制限したりできない.
            <!--
            Third-party applications gain overly broad access to the resource owner's protected
            resources, leaving resource owners without any ability to restrict duration or access
            to a limited subset of resources.
            -->
          </t>
          <t>
            リソースオーナーは各サードパーティーごとにアクセス権を無効化することはできず, アクセス権を無効化する際にはすべてのサードパーティーが持つアクセス権を無効化しなければならない.
            つまりそれはパスワード変更を意味する.
            <!-- NOTE: 3rd-partyのパスワードを変更するってどゆこと？ -->
            <!--
            Resource owners cannot revoke access to an individual third party without revoking
            access to all third parties, and must do so by changing the third party's password.
            -->
          </t>
          <t>
            サードパーティーアプリケーションの情報漏えいはエンドユーザーのパスワードおよびパスワードによって保護されているすべての情報の漏洩につながる.
            <!--
            Compromise of any third-party application results in compromise of the end-user's
            password and all of the data protected by that password.
            -->
          </t>
        </list>
      </t>
      <t>
        OAuthは, 認可レイヤーをもうけてクライアントとリソースオーナーの役割を分けることで, これらの問題の解決に取り組む.
        OAuthでは, クライアントは, リソースオーナーのコントロール下にありリソースサーバーによってホストされているリソースへのアクセス権を要求する.
        そしてリソースオーナーのクレデンシャルそのものとは別のクレデンシャルを取得する.
        <!--
        OAuth addresses these issues by introducing an authorization layer and separating the role
        of the client from that of the resource owner. In OAuth, the client requests access to
        resources controlled by the resource owner and hosted by the resource server, and is issued
        a different set of credentials than those of the resource owner.
        -->
      </t>
      <t>
        保護されたリソースにアクセスする為にリソースオーナーのクレデンシャルを使う代わりに, クライアントはアクセストークンを取得する.
        アクセストークンとは, ある特定のスコープ, 期間およびその他のアクセス権に関する情報を示す文字列である.
        アクセストークンはリソースオーナーの同意をもって認可サーバーからサードパーティークライアントへ発行される.
        クライアントはアクセストークンを用いてリソースサーバーがホストしている保護されたリソースにアクセスする.
        <!--
        Instead of using the resource owner's credentials to access protected resources, the client
        obtains an access token -- a string denoting a specific scope, lifetime, and other access
        attributes. Access tokens are issued to third-party clients by an authorization server with
        the approval of the resource owner. The client uses the access token to access the
        protected resources hosted by the resource server.
        -->
      </t>
      <t>
        例えば, あるユーザー (リソースオーナー) が, 印刷サービス (クライアント) に対して, 写真共有サービス上 (リソースサーバー) に保管されている彼女の保護された写真へのアクセス権を与えることを考える.
        OAuthでは, その際彼女のユーザー名とパスワードを印刷サービスに与える必要はない.
        そのかわり, 彼女は写真共有サービスの信任を得たサービス (認可サーバー) に対して認証を行い, 印刷サービスへのアクセス権限委譲用クレデンシャル (アクセストークン) を発行させる.
        <!--
        For example, an end-user (resource owner) can grant a printing service (client) access
        to her protected photos stored at a photo-sharing service (resource server), without
        sharing her username and password with the printing service. Instead, she authenticates
        directly with a server trusted by the photo-sharing service (authorization server), which
        issues the printing service delegation-specific credentials (access token).
        -->
      </t>
      <t>
        本仕様書はHTTP <xref target='RFC2616' /> での利用を想定して設計されている.
        HTTP以外の通信プロトコルでのOAuth利用については対象としない.
        <!--
        This specification is designed for use with HTTP (<xref target='RFC2616' />). The use of
        OAuth over any protocol other than HTTP is out of scope.
        -->
      </t>
      <t>
        Informationalドキュメントとして発行されたOAuth 1.0 (<xref target='RFC5849' />) は, 小規模のアドホックなコミュニティにより作られた.
        Standard Trackである本仕様は, OAuth 1.0で得られた経験を元に, IETFコミュニティから発生したさらなるユースケースや拡張性を加味して策定されている.
        OAuth 2.0はOAuth 1.0との互換性はない.
        2つのバージョンは共存可能であり, 実装者は両方をサポートすることも可能である.
        しかしながら本仕様は, 新規実装されるサービスではOAuth 2.0をサポートし, OAuth 1.0は既存サービスのサポートのためにのみ用いることを想定している.
        OAuth 2.0プロトコルには, OAuth 1.0と共通の実装詳細はごく少ない.
        OAuth 1.0に詳しい実装者は, OAuth 1.0の知識に基づく憶測を持たずに本仕様を理解すること.
        <!--
        The OAuth 1.0 protocol (<xref target='RFC5849' />), published as an informational document,
        was the result of a small ad hoc community effort. This Standards Track specification builds
        on the OAuth 1.0 deployment experience, as well as additional use cases and extensibility
        requirements gathered from the wider IETF community. The OAuth 2.0 protocol is not backward
        compatible with OAuth 1.0. The two versions may co-exist on the network, and implementations
        may choose to support both. However, it is the intention of this specification that new
        implementations support OAuth 2.0 as specified in this document and that OAuth 1.0 is used
        only to support existing deployments. The OAuth 2.0 protocol shares very few implementation
        details with the OAuth 1.0 protocol. Implementers familiar with OAuth 1.0 should approach
        this document without any assumptions as to its structure and details.
        -->
      </t>

      <section title='登場人物'>
      <!-- <section title='Roles'> -->
        <t>
          OAuthは以下の4つのロールを定義する.
          <!--
          OAuth defines four roles:
          -->
        </t>
        <t>
          <list style='hanging'>
            <t hangText='リソースオーナー (resource owner)'>
              <vspace />
              保護されたリソースへのアクセスを許可するエンティティー.
              リソースオーナーが人間の場合, エンドユーザーと呼ばれる.
              <!--
              An entity capable of granting access to a protected resource. When the resource owner
              is a person, it is referred to as an end&nbhy;user.
              -->
            </t>
            <t hangText='リソースサーバー (resource server)'>
              <vspace />
              保護されたリソースをホストし, アクセストークンを用いた保護されたリソースへのリクエストを受理してレスポンスを返すことのできるサーバー.
              <!--
              The server hosting the protected resources, capable of accepting and responding to
              protected resource requests using access tokens.
              -->
            </t>
            <t hangText='クライアント (client)'>
              <vspace />
              リソースオーナーの認可を得て, リソースオーナーの代理として保護されたリソースに対するリクエストを行うアプリケーション.
              「クライアント」という表現は, 該当アプリケーションの実装上の特徴には関係がない.
              (OAuthクライアントは, サーバー上で動くアプリケーションであることもあれば, デスクトップアプリケーションやその他のデバイス上で動くアプリケーションであることもある)
              <!--
              An application making protected resource requests on behalf of the resource owner and
              with its authorization. The term "client" does not imply any particular implementation
              characteristics (e.g., whether the application executes on a server, a desktop, or
              other devices).
              -->
            </t>
            <t hangText='認可サーバー (authorization server)'>
              <vspace />
              リソースオーナーの認証とリソースオーナーからの認可取得が成功した後, アクセストークンをクライアントに発行するサーバー.
              <!--
              The server issuing access tokens to the client after successfully authenticating the
              resource owner and obtaining authorization.
              -->
            </t>
          </list>
        </t>
        <t>
          認可サーバーとリソースサーバー間のやりとりについては本仕様書の範囲外である.
          認可サーバーはリソースサーバーと同一のサーバーでも異なるサーバーでもよい.
          単一の認可サーバーが複数のリソースサーバーにアクセス可能なアクセストークンを発行してもよい.
          <!--
          The interaction between the authorization server and resource server is beyond the scope
          of this specification. The authorization server may be the same server as the resource
          server or a separate entity. A single authorization server may issue access tokens
          accepted by multiple resource servers.
          -->
        </t>
      </section>

      <section title='プロトコルフロー'>
      <!-- <section title='Protocol Flow'> -->
        <figure title='Abstract Protocol Flow' anchor='Figure-1'>
          <artwork><![CDATA[
  +--------+                               +---------------+
  |        |--(A)- Authorization Request ->|   Resource    |
  |        |                               |     Owner     |
  |        |<-(B)-- Authorization Grant ---|               |
  |        |                               +---------------+
  |        |
  |        |                               +---------------+
  |        |--(C)-- Authorization Grant -->| Authorization |
  | Client |                               |     Server    |
  |        |<-(D)----- Access Token -------|               |
  |        |                               +---------------+
  |        |
  |        |                               +---------------+
  |        |--(E)----- Access Token ------>|    Resource   |
  |        |                               |     Server    |
  |        |<-(F)--- Protected Resource ---|               |
  +--------+                               +---------------+
]]></artwork>
        </figure>
        <t>
          <xref target='Figure-1' />で示されたOAuth 2.0のフロー概要は, 4つのロール間での相互作用と以下のステップについて記載している.
          <!--
          The abstract OAuth 2.0 flow illustrated in <xref target='Figure-1' /> describes the interaction
          between the four roles and includes the following steps:
          -->
        </t>
        <t>
          <list style='format (%C)'>
            <t>
              クライアントはリソースオーナーに対して認可を要求する.
              その際 (図のように) リソースオーナーに直接認可要求を行うことも出来るが, 認可サーバーを経由して間接的に行うことがのぞましい.
              <!--
              The client requests authorization from the resource owner. The authorization request
              can be made directly to the resource owner (as shown), or preferably indirectly via
              the authorization server as an intermediary.
              -->
            </t>
            <t>
              クライアントは, リソースオーナーの認可を表すクレデンシャルとして認可グラントを受け取る.
              認可グラントは本仕様で定義される4つのグラントタイプの内の1つ, または拡張されたグラントタイプで発行される.
              どの認可グラントタイプを用いるかは, クライアントの利用する認可リクエストの方式と認可サーバーがサポートするグラントタイプに依存する.
              <!--
              The client receives an authorization grant, which is a credential representing
              the resource owner's authorization, expressed using one of four grant types defined
              in this specification or using an extension grant type. The authorization grant type
              depends on the method used by the client to request authorization and the types
              supported by the authorization server.
              -->
            </t>
            <t>
              クライアントは認可サーバーに対して自身を認証し, 認可グラントを提示することで, アクセストークンを要求する.
              <!--
              The client requests an access token by authenticating with the authorization server
              and presenting the authorization grant.
              -->
            </t>
            <t>
              認可サーバーはクライアントを認証し, 認可グラントの正当性を確認する.
              そして認可グラントが正当であれば, アクセストークンを発行する.
              <!--
              The authorization server authenticates the client and validates the authorization
              grant, and if valid, issues an access token.
              -->
            </t>
            <t>
              クライアントはリソースサーバーの保護されたリソースへリクエストを行い, 発行されたアクセストークンにより認証を行う.
              <!--
              The client requests the protected resource from the resource server and authenticates
              by presenting the access token.
              -->
            </t>
            <t>
              リソースサーバーはアクセストークンの正当性を確認し, 正当であればリクエストを受け入れる.
              <!--
              The resource server validates the access token, and if valid, serves the request.
              -->
            </t>
          </list>
        </t>
        <t>
          クライアントがリソースオーナーから認可グラントを取得する (図中AおよびB) 際には, 認可サーバーが仲介を行う方式が望ましい.
          この方式は<xref target="grant-code"/>の<xref target='Figure-3'/>に示されている.
          <!--
          The preferred method for the client to obtain an authorization grant from the resource
          owner (depicted in steps (A) and (B)) is to use the authorizatio server as an intermediary,
          which is illustrated in <xref target='Figure-3'/>
          in <xref target="grant-code"/>.
          -->
        </t>

      </section>

      <section title='認可グラント'>
      <!-- <section title='Authorization Grant'> -->
        <t>
          認可グラントは, リソースオーナーによる (保護されたリソースへのアクセスを行うことに対する) 認可を示し, クライアントがアクセストークンを取得する際に用いられる.
          本仕様では認可コード, インプリシット, リソースオーナーパスワードクレデンシャル, クライアントクレデンシャルの4つのグラントタイプを定義しており, 拡張仕様によってタイプを追加することもできる.
          <!--
          An authorization grant is a credential representing the resource owner's authorization
          (to access its protected resources) used by the client to obtain an access token. This
          specification defines four grant types -- authorization code, implicit, resource owner
          password credentials, and client credentials -- as well as an extensibility mechanism for
          defining additional types.
          -->
        </t>

        <section title='認可コード'>
        <!-- <section title='Authorization Code'> -->
          <t>
            認可コードは, 認可サーバーがクライアントとリソースオーナーの仲介となって発行する.
            リソースオーナーへ直接認可を要求する代わりに, クライアントは (<xref target='RFC2616' /> に定義されたユーザーエージェントを経由して) リソースオーナーを認可サーバーへリダイレクトさせ, リソースオーナーがリダイレクトして戻ってきた際に認可コードを取得する.
            <!--
            The authorization code is obtained by using an authorization server as an intermediary
            between the client and resource owner. Instead of requesting authorization directly
            from the resource owner, the client directs the resource owner to an authorization
            server (via its user&nbhy;agent as defined in <xref target='RFC2616' />), which in turn
            directs the resource owner back to the client with the authorization code.
            -->
          </t>
          <t>
            リソースオーナーを認可コードとともにリダイレクト経由でクライアントに戻す前に, 認可サーバーはリソースオーナーを認証し認可を得る.
            これによりリソースオーナーは認可サーバーによってのみ認証され, リソースオーナーのクレデンシャルはクライアントへ共有されない.
            <!--
            Before directing the resource owner back to the client with the authorization code, the
            authorization server authenticates the resource owner and obtains authorization.
            Because the resource owner only authenticates with the authorization server, the
            resource owner's credentials are never shared with the client.
            -->
          </t>
          <t>
            認可コードは, クライアントを認証する機会を提供したり, リソースオーナーのユーザーエージェントを経由せずアクセストークンをクライアントに直接送信できるなど, いくつかの点で重要なセキュリティ的なメリットを提供する.
            リソースオーナーのユーザーエージェントを経由してデータを送信した場合, そのデータはリソースオーナーを含む第三者に露出する可能性がある.
            <!--
            The authorization code provides a few important security benefits,
            such as the ability to authenticate the client, as well as the
            transmission of the access token directly to the client without
            passing it through the resource owner's user-agent and potentially
            exposing it to others, including the resource owner.
            -->
          </t>
        </section>

        <section title='インプリシット' anchor="ImplicitIntro">
        <!-- <section title='Implicit' anchor="ImplicitIntro"> -->
          <t>
            インプリシットグラントは, 認可コードフローを単純化したものであり, JavaScriptの様なスクリプト言語を使用してブラウザ上で実行されるクライアントに最適化されている.
            インプリシットフローでは, クライアントは (リソースオーナー認可の結果) 認可コードの代わりに直接アクセストークンを受け取る.
            このグラントタイプは (認可コードのように後にアクセストークンを取得する際に用いられる) 仲介のクレデンシャルを利用しないため, インプリシット (訳注: implicit = 暗黙の) と呼ばれる.
            <!--
            The implicit grant is a simplified authorization code flow optimized for clients
            implemented in a browser using a scripting language such as JavaScript. In the implicit
            flow, instead of issuing the client an authorization code, the client is issued an
            access token directly (as the result of the resource owner authorization). The grant
            type is implicit, as no intermediate credentials (such as an authorization code) are
            issued (and later used to obtain an access token).
            -->
          </t>
          <t>
            インプリシットグラントフローでアクセストークンを発行する場合, 認可サーバーはクライアントを認証しない.
            ただし, クライアントにアクセストークンを渡す際に使用されるリダイレクトURIをもとに, クライアントの身元が検証可能なこともある.
            アクセストークンはリソースオーナー, もしくはリソースオーナーのユーザーエージェントにアクセスすることで他のアプリケーションに晒される可能性がある.
            <!--
            When issuing an access token during the implicit grant flow, the authorization server
            does not authenticate the client. In some cases, the client identity can be verified
            via the redirection URI used to deliver the access token to the client. The access
            token may be exposed to the resource owner or other applications with access to the
            resource owner's user-agent.
            -->
          </t>
          <t>
            アクセストークンを得るのに必要な往復の回数を減らせるため, インプリシットグラントは (ブラウザにおけるアプリケーションとして実行されたクライアントなど) いくつかのクライアントで応答性と効率性を高める.
            しかしながら, 特に認可コードグラントタイプが利用可能である場合, インプリシットグラントを用いた場合の利便性はセキュリティー面の影響とトレードオフの関係にあることを考慮すべきである.
            セキュリティー面の影響についての詳細は, <xref target="AccessTokenSecurity" format="counter"/>および<xref target="ImplicitImpersonation" format="counter"/>を参照のこと.
            <!--
            Implicit grants improve the responsiveness and efficiency of some clients (such as a
            client implemented as an in-browser application) since it reduces the number of round
            trips required to obtain an access token. However, this convenience should be weighed
            against the security implications of using implicit grants, especially when the
            authorization code grant type is available.

            Implicit grants improve the responsiveness and efficiency of some clients (such as a
            client implemented as an in-browser application), since it reduces the number of round
            trips required to obtain an access token. However, this convenience should be weighed
            against the security implications of using implicit grants,
            such as those described in Sections <xref target="AccessTokenSecurity" format="counter"/> and
            <xref target="ImplicitImpersonation" format="counter"/>,
            especially when the authorization code grant type is available.
            -->
          </t>
        </section>

        <section title="リソースオーナーパスワードクレデンシャル">
        <!-- <section title="Resource Owner Password Credentials"> -->
          <t>
            リソースオーナーパスワードクレデンシャル (例えばユーザー名とパスワード) を直接アクセストークンを得るための認可グラントとして使用することも出来る.
            このクレデンシャルは, (例えばクライアントがデバイスOSの一部となっていたり, 非常に特権のあるアプリケーションである場合のように) リソースオーナーとクライアントの間で高い信頼があり, (認可コードのような) 他の認可グラントタイプが利用できない場合のみ使用されるべきである.
            <!--
            The resource owner password credentials (i.e., username and password) can be used
            directly as an authorization grant to obtain an access token. The credentials should
            only be used when there is a high degree of trust between the resource owner and the
            client (e.g., the client is part of the device operating system or a highly privileged
            application), and when other authorization grant types are not available (such as an
            authorization code).
            -->
          </t>
          <t>
            このグラントタイプでは, クライアントがリソースオーナークレデンシャルへ直接アクセスすることになるが, リソースオーナークレデンシャルは一度きりのリクエストにのみ使用され, アクセストークンに交換される.
            このグラントタイプでは, クレデンシャルを寿命の長いアクセストークンやリフレッシュトークンと交換することにより, クライアントがリソースオーナークレデンシャルを後の利用のために保存しておく必要がなくなる.
            <!--
            Even though this grant type requires direct client access to the resource owner
            credentials, the resource owner credentials are used for a single request and are
            exchanged for an access token. This grant type can eliminate the need for the client
            to store the resource owner credentials for future use, by exchanging the credentials
            with a long-lived access token or refresh token.
            -->
          </t>
        </section>

        <section title='クライアントクレデンシャル'>
        <!-- <section title='Client Credentials'> -->
          <t>
            認可範囲がクライアントの管理下にある保護されたリソース, もしくはあらかじめ認可サーバーとの間で調整済の保護されたリソースに制限されている場合は, 認可グラントとしてクライアントクレデンシャル (もしくは他のクライアント認証形式) が使用できる.
            クライアントがクライアント自身の権限においてに行動している (つまりクライアントがリソースオーナーである) か, クライアントがあらかじめ認可サーバーとの間で調整済の保護されたリソースアクセスを求めている場合, クライアントクレデンシャルが認可グラントとして使用される.
            <!--
            The client credentials (or other forms of client authentication) can be used as an
            authorization grant when the authorization scope is limited to the protected resources
            under the control of the client, or to protected resources previously arranged with the
            authorization server. Client credentials are used as an authorization grant typically
            when the client is acting on its own behalf (the client is also the resource owner) or
            is requesting access to protected resources based on an authorization previously
            arranged with the authorization server.
            -->
          </t>
        </section>

      </section>

      <section title='アクセストークン'>
      <!-- <section title='Access Token'> -->
        <t>
          アクセストークンは保護されたリソースにアクセスするために使用されるクレデンシャルである.
          アクセストークンはクライアントに対して発行される認可を表す文字列である.
          この文字列は通常クライアントからみるとランダムな文字列になっている.
          トークンはアクセス範囲とアクセス期間を表し, それらはリソースのオーナーによって許可され, リソースサーバーと認可サーバーによって適用される.
          <!--
          Access tokens are credentials used to access protected resources. An access token is a
          string representing an authorization issued to the client. The string is usually opaque
          to the client. Tokens represent specific scopes and durations of access, granted by the
          resource owner, and enforced by the resource server and authorization server.
          -->
        </t>
        <t>
          トークンは認可情報を取り出すための識別子を表したり, 検証可能な方法でそれ自身に認可情報を含んでもよい (データと署名を含むトークン文字列など).
          クライアントがトークンを使用するために, 本仕様で定めていない追加の認証クレデンシャルを要求することもできる.
          <!--
          The token may denote an identifier used to retrieve the authorization information or may
          self-contain the authorization information in a verifiable manner (i.e., a token string
          consisting of some data and a signature). Additional authentication credentials, which
          are beyond the scope of this specification, may be required in order for the client to
          use a token.
          -->
        </t>
        <t>
          アクセストークンによって, 様々な認可要素 (例えばユーザー名やパスワード) をリソースサーバーが解釈できる単体のトークンに置き換えるような抽象化レイヤーが提供される.
          この抽象化は, これらの認可要素を取得するための認可グラントよりも制限の強いアクセストークンの発行を可能とするだけではなく, 広範囲の認証方式をリソースサーバーが解釈する必要性がなくなる.
          <!--
          The access token provides an abstraction layer, replacing different authorization
          constructs (e.g., username and password) with a single token understood by the resource
          server. This abstraction enables issuing access tokens more restrictive than the
          authorization grant used to obtain them, as well as removing the resource server's need to
          understand a wide range of authentication methods.
          -->
        </t>
        <t>
          アクセストークンはリソースサーバーのセキュリティ要件に基づいて異なるフォーマット, 構成, および利用方法を持つことができる (暗号の特性).
          アクセストークンの属性と保護されたリソースにアクセスするための方法は本仕様に定めるところではなく, <xref target="RFC6750"/>のように本仕様と対になる仕様によって定義される.
          <!--
          Access tokens can have different formats, structures, and methods of utilization (e.g.,
          cryptographic properties) based on the resource server security requirements. Access token
          attributes and the methods used to access protected resources are beyond the scope of this
          specification and are defined by companion specifications such as <xref target="RFC6750"/>.
          -->
        </t>
      </section>

      <section title='リフレッシュトークン'>
      <!-- <section title='Refresh Token'> -->
        <t>
          リフレッシュトークンはアクセストークンを取得するために使用されるクレデンシャルである.
          リフレッシュトークンは認可サーバーによってクライアントに対して発行され, 現在のアクセストークンが無効化されたあるいは期限切れの際に新しいアクセストークンを取得するため, または同一あるいは狭い範囲で追加のアクセストークンを取得するために利用される (アクセストークンはリソースオーナーによって認可されるよりも有効期限は短く, 権限が少なくてもよい).
          リフレッシュトークンの発行はオプションであり, 認可サーバーの判断に委ねられる.
          認可サーバーがリフレッシュトークンを発行する場合, アクセストークン発行 (<xref target='Figure-1' />中のDに該当) の際にリフレッシュトークンも含まれる.
          <!--
          Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to
          the client by the authorization server and are used to obtain a new access token when the
          current access token becomes invalid or expires, or to obtain additional access tokens
          with identical or narrower scope (access tokens may have a shorter lifetime and fewer
          permissions than authorized by the resource owner). Issuing a refresh token is optional
          at the discretion of the authorization server. If the authorization server issues a
          refresh token, it is included when issuing an access token (i.e., step (D) in
          <xref target='Figure-1' />).
          -->
        </t>
        <t>
          リフレッシュトークンはリソースオーナーによってクライアントに付与される認可を表す文字列である.
          この文字列は通常クライアントからみるとランダムな文字列になっている.
          そのトークンは認可情報を取り出すための識別子を意味してもよい.
          アクセストークンとは異なり, リフレッシュトークンは認可サーバーでのみ使用されるものであり, リソースサーバーに送信されることはない.
          <!--
          A refresh token is a string representing the authorization granted to the client by the
          resource owner. The string is usually opaque to the client. The token denotes an
          identifier used to retrieve the authorization information. Unlike access tokens, refresh
          tokens are intended for use only with authorization servers and are never sent to
          resource servers.
          -->
        </t>
        <figure title='Refreshing an Expired Access Token' anchor='Figure-2'>
          <artwork><![CDATA[
  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+
]]></artwork>
        </figure>
        <t>
          <xref target='Figure-2' /> のフローは, 以下の各ステップからなる.
          <!--
          The flow illustrated in <xref target='Figure-2' /> includes the following steps:
          -->
        </t>
        <t>
          <list style='format (%C)'>
            <t>
              クライアントは, 認可サーバーに対して自身を認証して認可グラントを提示することによって, アクセストークンを要求する.
              <!--
              The client requests an access token by authenticating with the authorization server
              and presenting an authorization grant.
              -->
            </t>
            <t>
              認可サーバーはクライアントを認証して認可グラントを確認し, 有効である場合はアクセストークンとリフレッシュトークンを発行する.
              <!--
              The authorization server authenticates the client and validates the authorization
              grant, and if valid, issues an access token and a refresh token.
              -->
            </t>
            <t>
              クライアントはアクセストークンを提示してリソースサーバー上の保護されたリソースに対してリクエストを行う.
              <!--
              The client makes a protected resource request to the resource server by presenting
              the access token.
              -->
            </t>
            <t>
              リソースサーバーはアクセストークンの正当性を確認し, 有効な場合はリクエストを処理する.
              <!--
              The resource server validates the access token, and if valid, serves the request.
              -->
            </t>
            <t>
              ステップ (C) と (D) はアクセストークンの有効期限が切れるまで繰り返される.
              クライアントがアクセストークンの期限切れを検知した場合, ステップ (G) にスキップし, そうでなければ保護されたリソースへのリクエストを続ける.
              <!--
              Steps (C) and (D) repeat until the access token expires. If the client knows the
              access token expired, it skips to step (G); otherwise, it makes another protected
              resource request.
              -->
            </t>
            <t>
              アクセストークンが有効でないとき, リソースサーバーはエラーを返し, トークンが無効なことを伝える.
              <!--
              Since the access token is invalid, the resource server returns an invalid token
              error.
              -->
            </t>
            <t>
              クライアントは, 認可サーバーに対して自身を認証してリフレッシュトークンを提示することによって, 新しいアクセストークンを要求する.
              クライアント認証の必要条件はクライアントタイプと認可サーバーのポリシーによって異なる.
              <!--
              The client requests a new access token by authenticating with the authorization
              server and presenting the refresh token. The client authentication requirements are
              based on the client type and on the authorization server policies.
              -->
            </t>
            <t>
              認可サーバーはクライアントを認証しリフレッシュトークンの正当性を確認し, 正当であれば新たなアクセストークン (およびオプションで新たなリフレッシュトークン) を発行する.
              <!--
              The authorization server authenticates the client and validates the refresh token,
              and if valid, issues a new access token (and, optionally, a new refresh token).
              -->
            </t>
          </list>
        </t>
        <t>
          <xref target='access-resource' />に述べる通り, (C), (D), (E) および (F) は本仕様の定めるところではない.
          <!--
          Steps (C), (D), (E), and (F) are outside the scope of this specification, as described in
          <xref target='access-resource' />.
          -->
        </t>
      </section>

      <section title='TLSバージョン' anchor='tls'>
      <!-- <section title='TLS Version' anchor='tls'> -->
        <t>
          本仕様でTransport Layer Security (TLS) を用いる場合, 将来的に実運用やセキュリティ上の脆弱性が発見されたりすることで, 適切なTLSのバージョンは変化しうる.
          本仕様執筆時点では, TLSバージョン1.2 <xref target='RFC5246' /> が最新バージョンであるが, 現実にはその実装は限られており, すぐに利用可能な状態ではない可能性もある.
          TLSバージョン1.0 <xref target='RFC2246' /> は最も広く実装されており, 最も広い相互運用性をもたらすであろう.
          <!--
          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>
        <t>
          実装者は, 自身のセキュリティ要件に合わせて, TLSの他にさらにトランスポートレイヤーのセキュリティメカニズムをサポートすることも可能である.
          <!--
          Implementations MAY also support additional transport-layer security mechanisms
          that meet their security requirements.
          -->
        </t>
      </section>

      <section title='HTTPリダイレクト'>
      <!-- <section title='HTTP Redirections'> -->
        <t>
          本仕様では, クライアントもしくは認可サーバーがリソースオーナーのユーザーエージェントを別の場所にリダイレクトさせる際に, HTTPリダイレクトを用いる.
          本仕様の例では302 HTTPステータスを用いるが, それ以外にもユーザーエージェントを通じてリダイレクトを行うことができる方法であれば, どのような手段を用いても良い.
          どのような手段を用いるかは実装者に委ねる.
          <!--
          This specification makes extensive use of HTTP redirections, in which the client or the
          authorization server directs the resource owner's user-agent to another destination. While
          the examples in this specification show the use of the HTTP 302 status code, any other
          method available via the user-agent to accomplish this redirection is allowed and is
          considered to be an implementation detail.
          -->
        </t>
      </section>

      <section title='相互運用性'>
      <!-- <section title='Interoperability'> -->
        <t>
          OAuth 2.0は明確に定義されたセキュリティ特性を持つリッチな認可フレームワークである.
          しかしながら, リッチで多くのオプション要素を持つ高度に拡張可能なフレームワークであることから, 様々な要因によって相互運用性を損なう実装をもたらす可能性もある.
          <!--
          OAuth 2.0 provides a rich authorization framework with well-defined security properties.
          However, as a rich and highly extensible framework with many optional components, on its
          own, this specification is likely to produce a wide range of non-interoperable
          implementations.
          -->
        </t>
        <t>
          加えて, 本仕様はいくつかの必須要素を部分的または完全に未定義な状態で残す.
          (例: クライアント登録, 認可サーバーに求められる機能, エンドポイントのディスカバリーなど)
          これらの要素が欠けているため, 相互運用性を確保するには, クライアントは各認可サーバーおよびリソースサーバーに対して個別に手動で設定される必要がある.
          <!--
          In addition, this specification leaves a few required components partially or fully
          undefined (e.g., client registration, authorization server capabilities, endpoint
          discovery). Without these components, clients must be manually and specifically
          configured against a specific authorization server and resource server in order to
          interoperate.
          -->
        </t>
        <t>
          将来的には, Web全体に渡る相互運用性獲得のために必要な規範的プロフィールや拡張が定義されることを期待する.
          <!--
          This framework was designed with the clear expectation that future work will define
          prescriptive profiles and extensions necessary to achieve full web-scale
          interoperability.
          -->
        </t>
      </section>

      <section title='表記規約'>
      <!-- <section title='Notational Conventions'> -->
        <t>
          本仕様書で用いられる各キーワード「MUST (しなければならない)」, 「MUST NOT (してはならない)」, 「REQUIRED (必須である)」, 「SHALL (するものとする)」, 「SHALL NOT (しないものとする)」, 「SHOULD (すべきである)」, 「SHOULD NOT (すべきではない)」, 「RECOMMENDED (推奨される)」, 「MAY (してもよい)」, 「OPTIONAL (任意である)」は <xref target='RFC2119' /> で述べられている通りに解釈されるべきものである.
          <!--
          The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
          NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as
          described in <xref target='RFC2119' />.
          -->
        </t>
        <t>
          本仕様書は <xref target='RFC5234' /> における Augmented Backus-Naur Form (ABNF) 表記法を使用している.
          加えてURI-referenceの規則には "Uniform Resource Identifier (URI): Generic Syntax" <xref target='RFC3986' /> を用いる.
          <xref target='RFC5234' />.
          <!--
          This specification uses the Augmented Backus-Naur Form (ABNF) notation of
          <xref target='RFC5234' />.
          Additionally, the rule URI-reference is included from
          "Uniform Resource Identifier (URI): Generic Syntax" <xref target='RFC3986' />.
          -->
        </t>
        <t>
          特定のセキュリティ関連の用語は <xref target='RFC4949' /> で定義された意味で理解されるべきである.
          これらの用語には, 「攻撃 (attack)」, 「認証 (authentication)」, 「認可 (authorization)」, 「証明書 (certificate)」, 「機密性 (confidentiality)」, 「クレデンシャル (credential)」, 「暗号化 (encryption)」, 「アイデンティティ (identity)」, 「記号 (sign)」, 「署名 (signature)」, 「信頼 (trust)」, 「正当性の確認 (validate)」, 「検証 (verify)」などがあるが, これらだけに限定はされない.
          <!--
          Certain security-related terms are to be understood in the sense defined in
          <xref target='RFC4949' />. These terms include, but are not limited to, "attack",
          "authentication", "authorization", "certificate", "confidentiality", "credential",
          "encryption", "identity", "sign", "signature", "trust", "validate", and "verify".
          -->
        </t>
        <t>
          特に記載が無い限り, すべてのプロトコルパラメーター名と値は, 大文字・小文字を区別する.
          <!--
          Unless otherwise noted, all the protocol parameter names and values are case sensitive.
          -->
        </t>
      </section>

    </section>

    <section title='クライアント登録'>
    <!-- <section title='Client Registration'> -->
      <t>
        OAuth プロトコルフローを開始する前に, クライアントは認可サーバーに登録する.
        クライアントが認可サーバーに登録する方法は本仕様での範囲外であるが, 通常エンドユーザーとの対話を伴うHTML登録フォームを持つ.
        <!--
        Before initiating the protocol, the client registers with the authorization server. The
        means through which the client registers with the authorization server are beyond the
        scope of this specification but typically involve end-user interaction with an HTML
        registration form.
        -->
      </t>
      <t>
        クライアントの登録は, クライアントと認可サーバー間の直接的なやりとりを必須としない.
        認可サーバーでサポートされている場合, 必要なクライアントのプロパティー (例えばリダイレクトURIやクライアントタイプ) を取得し信頼を確立する他の方法を用いて登録を行うことができる.
        例えば, クライアント自身もしくはサードパーティーが発行したアサーションを使用したり, 認可サーバーが信頼できるチャネルを使用してクライアントのディスカバリーを行うことで, 登録を行うことができる.
        <!--
        Client registration does not require a direct interaction between the client and the
        authorization server. When supported by the authorization server, registration can rely
        on other means for establishing trust and obtaining the required client properties (e.g.,
        redirection URI, client type). For example, registration can be accomplished using a
        self-issued or third-party-issued assertion, or by the authorization server performing
        client discovery using a trusted channel.
        -->
      </t>
      <t>
        クライアントを登録する場合, クライアント開発者は以下を満たすものとする (SHALL).
        <!--
        When registering a client, the client developer SHALL:
        -->
      </t>
      <t>
        <list style='symbols'>
          <t>
            <xref target='client-types' /> で説明されているようなクライアントタイプを指定し,
            <!--
            specify the client type as described in <xref target='client-types' />,
            -->
          </t>
          <t>
            <xref target='redirect-uri' /> で説明されているようなリダイレクトURIを提供し,
            <!--
            provide its client redirection URIs as described in
            <xref target='redirect-uri' />, and
            -->
          </t>
          <t>
            認可サーバーが要求するその他の情報 (例えばアプリケーション名, Webサイト, 説明, ロゴイメージ, 利用規則など) を提供する.
            <!--
            include any other information required by the authorization server (e.g., application
            name, website, description, logo image, the acceptance of legal terms).
            -->
          </t>
        </list>
      </t>

      <section title='クライアントタイプ' anchor='client-types'>
      <!-- <section title='Client Types' anchor='client-types'> -->
        <t>
          認可サーバーと安全に認証する能力 (クライアントクレデンシャルの機密性を維持できる能力など) に基づいて, OAuthは二つのクライアントタイプを定義している.
          <!--
          OAuth defines two client types, based on their ability to authenticate securely with the
          authorization server (i.e., ability to maintain the confidentiality of their client
          credentials):
          -->
        </t>
        <t>
          <list style='hanging'>
            <t hangText='コンフィデンシャル (confidential)'>
              <vspace />
              クレデンシャルの機密性を維持することができるクライアント (例えば, クライアントクレデンシャルへのアクセスが制限されたセキュアサーバー上に実装されたクライアント), または他の手段を使用したセキュアなクライアント認証ができるクライアント.
              <!--
              Clients capable of maintaining the confidentiality of their credentials (e.g.,
              client implemented on a secure server with restricted access to the client
              credentials), or capable of secure client authentication using other means.
              -->
            </t>
            <t hangText='パブリック (public)'>
              <vspace />
              (例えば, インストールされたネイティブアプリケーションやブラウザベースのWebアプリケーションなど, リソースオーナーのデバイス上で実行されるクライアントのように) クライアントクレデンシャルの機密性を維持することができず, かつ他の手段を使用したセキュアなクライアント認証もできないクライアント.
              <!--
              Clients incapable of maintaining the confidentiality of their credentials (e.g.,
              clients executing on the device used by the resource owner, such as an installed
              native application or a web browser-based application), and incapable of secure
              client authentication via any other means.
              -->
            </t>
          </list>
        </t>
        <t>
          クライアントタイプは, 認可サーバーが定めるセキュア認証の定義とクライアントクレデンシャルの許容公開レベルに基づいて決定される.
          認可サーバーは, クライアントタイプに関して憶測に頼るべきではない (SHOULD NOT).
          <!--
          The client type designation is based on the authorization server's definition of secure
          authentication and its acceptable exposure levels of client credentials. The
          authorization server SHOULD NOT make assumptions about the client type.
          -->
        </t>
        <t>
          クライアントによっては, 分散された複数のコンポーネントによって実装され, それぞれのコンポーネントが異なるクライアントタイプおよびセキュリティ特性を持つ場合もある.
          (例: コンフィデンシャルなサーバーベースコンポーネントとパブリックなブラウザベースのコンポーネントからなるクライアントなど)
          認可サーバーがこのようなクライアントをサポートしない, もしくはクライアント登録に関して何らかのガイダンスを提供していない場合, クライアントはそれぞれのコンポーネントを別のクライアントとして登録すべきである (SHOULD).
          <!--
          A client may be implemented as a distributed set of components, each with a different
          client type and security context (e.g., a distributed client with both a confidential
          server-based component and a public browser-based component). If the authorization server
          does not provide support for such clients or does not provide guidance with regard to
          their registration, the client SHOULD register each component as a separate client.
          -->
        </t>
        <t>
          本仕様は以下のようなクライアントプロファイルを考慮して設計されている,
          <!--
          This specification has been designed around the following client profiles:
          -->
        </t>
        <t>
          <list style='hanging'>
            <t hangText='Webアプリケーション (web application)'>
              <vspace />
              Webアプリケーションは, Webサーバー上で実行されているコンフィデンシャルクライアントである.
              リソースオーナーは, リソースオーナーのデバイス上のユーザーエージェントにレンダリングされたHTMLユーザーインターフェイスを通してクライアントにアクセスする.
              クライアントに発行されたアクセストークンと同様にクライアントクレデンシャルはWebサーバー上に保存され, リソースオーナーによって公開されたりアクセス可能な状態にならない.
              <!--
              A web application is a confidential client running on a web server. Resource owners
              access the client via an HTML user interface rendered in a user-agent on the device
              used by the resource owner. The client credentials as well as any access token issued
              to the client are stored on the web server and are not exposed to or accessible by
              the resource owner.
              -->
            </t>
            <t hangText='ユーザーエージェントベースアプリケーション (user-agent-based application)'>
              <vspace />
              ユーザーエージェントベースアプリケーションは, クライアントコードがWebサーバーからダウンロードされリソースオーナーのデバイス上のユーザーエージェント (例えばWebブラウザ) 内で実行されるパブリッククライアントである.
              プロトコルのデータとクレデンシャルはリソースオーナーに簡単にアクセス (かつ多くの場合は閲覧) できる.
              このようなアプリケーションはユーザーエージェント内にあるので, 認可を要求する時ユーザーエージェントの能力をシームレスに使用することができる.
              <!--
              A user-agent-based application is a public client in which the client code is
              downloaded from a web server and executes within a user-agent (e.g., web browser) on
              the device used by the resource owner. Protocol data and credentials are easily
              accessible (and often visible) to the resource owner. Since such applications reside
              within the user-agent, they can make seamless use of the user-agent capabilities when
              requesting authorization.
              -->
            </t>
            <t hangText='ネイティブアプリケーション (native application)'>
              <vspace />
              ネイティブアプリケーションは, リソースオーナーのデバイス上にインストールされ実行されるパブリッククライアントである.
              リソースオーナーはプロトコルのデータとクレデンシャルにアクセス可能である.
              アプリケーションに含まれるいかなるクライアント認証用のクレデンシャルも, 抽出可能であると想定される.
              一方, アクセストークンやリフレッシュトークンといった動的に発行されたクレデンシャルは許容できるレベルの保護が得られる.
              少なくとも, これらのクレデンシャルはアプリケーションと対話できる悪意のあるサーバーから保護されている.
              プラットフォームによっては, これらのクレデンシャルは同じデバイス上に存在する他のアプリケーションからも保護されているであろう.
              <!--
              A native application is a public client installed and executed on the device used by
              the resource owner. Protocol data and credentials are accessible to the resource
              owner. It is assumed that any client authentication credentials included in the
              application can be extracted. On the other hand, dynamically issued credentials such
              as access tokens or refresh tokens can receive an acceptable level of protection. At a
              minimum, these credentials are protected from hostile servers with which the
              application may interact. On some platforms, these credentials might be protected
              from other applications residing on the same device.
              -->
            </t>
          </list>
        </t>
      </section>

      <section title='クライアント識別子' anchor='client-identifier'>
      <!-- <section title='Client Identifier' anchor='client-identifier'> -->
        <t>
          認可サーバーは登録済みのクライアントにクライアント識別子 (クライアントが提供した登録情報を表すユニーク文字列) を発行する.
          クライアント識別子はシークレットと異なりリソースオーナーに露出されるため, その情報のみでクライアント認証を行ってはならない (MUST NOT).
          クライアント識別子は認可サーバーごとにユニークである.
          <!--
          The authorization server issues the registered client a client identifier -- a unique
          string representing the registration information provided by the client. The client
          identifier is not a secret; it is exposed to the resource owner and MUST NOT be used
          alone for client authentication. The client identifier is unique to the authorization
          server.
          -->
        </t>
        <t>
          クライアント識別子の文字列長は本仕様の定めるところではない.
          クライアントは識別子のサイズに関して憶測を持つべきではない.
          認可サーバーは, 発行するいかなる識別子に関しても, そのサイズに関する情報を提供すべきである (SHOULD).
          <!--
          The client identifier string size is left undefined by this specification. The client
          should avoid making assumptions about the identifier size.  The authorization server
          SHOULD document the size of any identifier it issues.
          -->
        </t>
      </section>

      <section title='クライアント認証' anchor='client-authentication'>
      <!-- <section title='Client Authentication' anchor='client-authentication'> -->
        <t>
          クライアントタイプがコンフィデンシャルである場合, クライアントと認可サーバーは, 認可サーバーのセキュリティ要求を満たすクライアント認証方式を確立する.
          認可サーバーは自身のセキュリティ要求さえ満たせば, どのような方式のクライアント認証に対応してもよい (MAY).
          <!--
          If the client type is confidential, the client and authorization server establish a client
          authentication method suitable for the security requirements of the authorization server.
          The authorization server MAY accept any form of client authentication meeting its
          security requirements.
          -->
        </t>
        <t>
          コンフィデンシャルクライアントには, 通常は認可サーバーでの認証に使われるクライアントクレデンシャルのセットが発行 (もしくは確立) される.
          例) パスワード, 公開鍵／秘密鍵のペア
          <!--
          Confidential clients are typically issued (or establish) a set of client credentials used for
          authenticating with the authorization server (e.g., password, public/private key pair).
          -->
        </t>
        <t>
          認可サーバーはパブリッククライアントとクライアント認証によって信頼確立してもよい (MAY).
          しかし, 認可サーバーはクライアントを識別する目的で, パブリッククライアントを信頼してはならない (MUST NOT).
          <!--
          The authorization server MAY establish a client authentication method with public clients.
          However, the authorization server MUST NOT rely on public client authentication for the
          purpose of identifying the client.
          -->
        </t>
        <t>
          クライアントは1回のリクエストにおいて二つ以上の認証方式を利用してはならない (MUST NOT).
          <!--
          The client MUST NOT use more than one authentication method in each request.
          -->
        </t>

        <section title='クライアントパスワード' anchor="client-password">
        <!-- <section title='Client Password' anchor="client-password"> -->
          <t>
            クライアントパスワードを保持しているクライアントは, 認可サーバー上での認証に<xref target='RFC2617' />で定義されているHTTP Basic認証スキームを使用してもよい (MAY).
            この場合, クライアント識別子は<xref target="urlencoded"/>の定める<spanx style='verb'>application/x-www-form-urlencoded</spanx>形式にエンコードされ, エンコードされた値がユーザーネームとして用いられる.
            クライアントパスワードも同様にエンコードされ, パスワードとして利用される.
            認可サーバーは, クライアントパスワードを発行されたクライアントの認証の為にHTTP Basic認証スキームをサポートしなければならない (MUST).
            <!--
            Clients in possession of a client password MAY use the HTTP Basic authentication scheme
            as defined in <xref target='RFC2617' /> to authenticate with the authorization server.
            The client identifier is encoded using the
            <spanx style='verb'>application/x-www-form-urlencoded</spanx>
            encoding algorithm per <xref target="urlencoded"/>, and the encoded value is
            used as the username; the client password is encoded using
            the same algorithm and used as the
            password. The authorization server MUST support the HTTP Basic authentication scheme
            for authenticating clients that were issued a client password.
            -->
          </t>
          <figure>
            <preamble>
              例 (改行は表示上の都合による):
              <!--
              For example (with extra line breaks for display purposes only):
              -->
            </preamble>
            <artwork><![CDATA[
  Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
]]></artwork>
          </figure>
          <t>
            HTTP Basic認証スキームの代わりに, 認可サーバーは以下のパラメーターを用いてリクエストボディーにクライアントクレデンシャルを含めてもよい (MAY).
            <!--
            Alternatively, the authorization server MAY support including the client credentials in
            the request-body using the following parameters:
            -->
          </t>
          <t>
            <list style='hanging' hangIndent='6'>
              <t hangText='client_id'>
                <vspace />
                必須 (REQUIRED).
                <xref target='client-identifier' /> に示されるクライアント登録時に発行されたクライアント識別子.
                <!--
                REQUIRED. The client identifier issued to the client during the registration process
                described by <xref target='client-identifier' />.
                -->
              </t>
              <t hangText='client_secret'>
                <vspace />
                必須 (REQUIRED).
                クライアントのシークレット.
                空の場合は省略してもよい (MAY).
                <!--
                REQUIRED. The client secret. The client MAY omit the parameter if the client secret
                is an empty string.
                -->
              </t>
            </list>
          </t>
          <t>
            2つのパラメーターを使ってクライアントクレデンシャルをリクエストボディーに含めることは推奨されていない (NOT RECOMMENDED).
            この方法はHTTP Basic認証スキーム (もしくは他のパスワードベースのHTTP認証スキーム) が直接利用できないクライアントに限定すべきある (SHOULD).
            これらのパラメーターはリクエストボディー経由でのみ送信可能であり, リクエストURI経由で送信してはならない (MUST NOT).
            <!--
            Including the client credentials in the request-body using the two parameters is NOT
            RECOMMENDED and SHOULD be limited to clients unable to directly utilize the HTTP Basic
            authentication scheme (or other password-based HTTP authentication schemes). The
            parameters can only be transmitted in the request-body and MUST NOT be included in the
            request URI.
            -->
          </t>
          <figure>
            <preamble>
              例：ボディパラメーターを使ってアクセストークンを更新 (<xref target='token-refresh' />) する場合 (改行は表示上の都合による)
              <!--
              For example, a request to refresh an access token (<xref target='token-refresh' />)
              using the body parameters (with extra line breaks for display purposes only):
              -->
            </preamble>
            <artwork><![CDATA[
  POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded

  grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
  &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
]]></artwork>
          </figure>
          <t>
            パスワード認証を行う場合, 認可サーバーは<xref target='tls' />にある通りTLSの利用を必須としなければならない (MUST).
            <!--
            The authorization server MUST require the use of TLS as described in
            <xref target='tls' /> when sending requests using password authentication.
            -->
          </t>
          <t>
            クライアント認証方式にパスワードが含まれるので, 認可サーバーはクライアント認証を行うすべてのエンドポイントでブルートフォースアタック対策を行わなくてはならない (MUST).
            <!--
            Since this client authentication method involves a password, the authorization server
            MUST protect any endpoint utilizing it against brute force attacks.
            -->
          </t>
        </section>

        <section title='その他の認証方式'>
        <!-- <section title='Other Authentication Methods'> -->
          <t>
            認可サーバーは, 自身のセキュリティ要件に適合するいかなるHTTP認証スキームをサポートしてよい (MAY).
            他の認証方式を利用する際には, 認可サーバーはクライアント識別子 (つまり登録されたクライアント) と認証スキームのマッピングを明確にしなければならない (MUST).
            <!--
            The authorization server MAY support any suitable HTTP authentication scheme matching
            its security requirements. When using other authentication methods, the authorization
            server MUST define a mapping between the client identifier (registration record) and
            authentication scheme.
            -->
          </t>
        </section>

      </section>

      <section title='未登録クライアント'>
      <!-- <section title='Unregistered Clients'> -->
        <t>
          本仕様は, 未登録のクライアントの利用を排除するものではない.
          しなしながら, そのようなクライアントの利用は本仕様のスコープ外であり, さらなるセキュリティー面の分析と相互運用性への影響度評価が必要である.
          <!--
          This specification does not exclude the use of unregistered clients. However, the use
          of such clients is beyond the scope of this specification and requires additional
          security analysis and review of its interoperability impact.
          -->
        </t>
      </section>

    </section>

    <section title='プロトコルエンドポイント'>
    <!-- <section title='Protocol Endpoints'> -->
      <t>
        認可プロセスは, 認可サーバー上の2つのエンドポイント (HTTP リソース) およびクライアント上の1つのエンドポイントを利用する.
        認可サーバー上のエンドポイントは以下の通り:
      </t>
      <!--
      <t>
        The authorization process utilizes two authorization server endpoints (HTTP resources):
      </t>
      -->
      <t>
        <list style='symbols'>
          <t>
            認可エンドポイント - ユーザーエージェント経由でリソースオーナーから認可を得るためにクライアントから利用される.
          </t>
          <!--
          <t>
            Authorization endpoint - used by the client to obtain authorization from the resource
            owner via user-agent redirection.
          </t>
          -->
          <t>
            トークンエンドポイント - 認可グラントとアクセストークンを交換するために, クライアントから利用される. 通常はクライアント認証を行う.
          </t>
          <!--
          <t>
            Token endpoint - used by the client to exchange an authorization grant for an access
            token, typically with client authentication.
          </t>
          -->
        </list>
      </t>
      <t>
        クライアント上のエンドポイントは以下の通り:
      </t>
      <!--
      <t>
        As well as one client endpoint:
      </t>
      -->
      <t>
        <list style='symbols'>
          <t>
            リダイレクトエンドポイント - リソースオーナーのユーザーエージェント経由で認可クレデンシャルを含むレスポンスをクライアント側へ返すために, 認可サーバーによって利用される.
          </t>
          <!--
          <t>
            Redirection endpoint - used by the authorization server to return
            responses containing authorization credentials to the client via
            the resource owner user-agent.
          </t>
          -->
        </list>
      </t>
      <t>
        すべてのグラントタイプが, これらすべてのエンドポイントを使用するわけではない.
        拡張されたグラントタイプは必要に応じて追加のエンドポイントを定義してもよい (MAY).
      </t>
      <!--
      <t>
        Not every authorization grant type utilizes both endpoints. Extension grant types MAY
        define additional endpoints as needed.
      </t>
      -->

      <section title='認可エンドポイント'>
      <!-- <section title='Authorization Endpoint'> -->
        <t>
          認可エンドポイントは, リソースオーナーとのインタラクションを通じて認可を得るために使用される.
          認可サーバーは, まずリソースオーナーのアイデンティティを確認しなければならない (MUST).
          認可サーバーが用いるリソースオーナーの認証方法 (ユーザー名とパスワードによるログイン, セッションクッキー) については, 本仕様の定めるところではない.
        </t>
        <!--
        <t>
          The authorization endpoint is used to interact with the resource owner and obtain
          an authorization grant. The authorization server MUST first verify the identity of the
          resource owner. The way in which the authorization server authenticates the resource
          owner (e.g., username and password login, session cookies) is beyond the scope of this
          specification.
        </t>
        -->
        <t>
          クライアントが認可エンドポイントURLを取得する方法は本仕様の定めるところではないが, そのURLは一般的にサービスドキュメントで提供される.
        </t>
        <!--
        <t>
          The means through which the client obtains the location of the authorization endpoint are
          beyond the scope of this specification, but the location is typically provided in the
          service documentation.
        </t>
        -->
        <t>
          エンドポイントURIは <spanx style='verb'>application/x-www-form-urlencoded</spanx> (<xref target='urlencoded' />) フォーマットのクエリーコンポーネント (<xref target='RFC3986' /> セクション3.4) を含んでもよい (MAY).
          クエリーパラメーターを追加する際, ここで指定されたクエリーコンポーネントは維持すること (MUST).
          エンドポイントURIはフラグメントコンポーネントを含んではいけない (MUST NOT).
        </t>
        <!--
        <t>
          The endpoint URI MAY include an
          <spanx style='verb'>application/x-www-form-urlencoded</spanx> formatted
          (per <xref target="urlencoded"/>) query component (<xref target='RFC3986' />
          Section 3.4), which MUST be retained when adding additional query parameters. The
          endpoint URI MUST NOT include a fragment component.
        </t>
        -->
        <t>
          認可エンドポイントへのリクエストはユーザー認証と (HTTPレスポンス内に) 平文のクレデンシャルの転送がされるため, 認可エンドポイントにリクエストを送信する際, 認可サーバーはTLS (<xref target='tls' />) を利用されなければならない (MUST).
        </t>
        <!--
        <t>
          Since requests to the authorization endpoint result in user authentication and the
          transmission of clear-text credentials (in the HTTP response), the authorization server
          MUST require the use of TLS as described in <xref target='tls' /> when sending requests
          to the authorization endpoint.
        </t>
        -->
        <t>
          認可サーバーは認可エンドポイントでHTTP <spanx style='verb'>GET</spanx> メソッド (<xref target='RFC2616' />) をサポートしなければならず (MUST), 同様に <spanx style='verb'>POST</spanx> メソッドをサポートしてもよい (MAY).
        </t>
        <!--
        <t>
          The authorization server MUST support the use of the HTTP <spanx style='verb'>GET</spanx>
          method <xref target='RFC2616' /> for the authorization endpoint and MAY support the use
          of the <spanx style='verb'>POST</spanx> method as well.
        </t>
        -->
        <t>
          パラメーターの値がない場合は, パラメーター自体が省略されているものとして扱わなければならない (MUST).
          認可サーバーは識別できないリクエストパラメーターを無視すること (MUST).
          リクエストおよびレスポンスパラメーターは重複してはならない (MUST NOT).
        </t>
        <!--
        <t>
          Parameters sent without a value MUST be treated as if they were omitted from the request.
          The authorization server MUST ignore unrecognized request parameters. Request and
          response parameters MUST NOT be included more than once.
        </t>
        -->

        <section title='レスポンスタイプ' anchor="response-type">
        <!-- <section title='Response Type' anchor="response-type"> -->
          <t>
            認可エンドポイントは認可コードグラントタイプとインプリシットタイプのフローで使用される.
            クライアントは以下に示すパラメーターを利用して, 希望するグラントタイプを認可サーバーに通知する.
          </t>
          <!--
          <t>
            The authorization endpoint is used by the authorization code grant type and implicit
            grant type flows. The client informs the authorization server of the desired grant
            type using the following parameter:
          </t>
          -->
          <t>
            <list style='hanging' hangIndent='6'>
              <t hangText='response_type'>
                <vspace />
                必須 (REQUIRED).
                レスポンスタイプの値は <xref target='code-authz-req' /> で後述する認可コードをリクエストするための <spanx style='verb'>code</spanx> あるいは, <xref target='implicit-authz-req' /> で後述するアクセストークン (インプリシットグラント) をリクエストする <spanx style='verb'>token</spanx> あるいは, <xref target='response-type-ext' /> で後述する登録されている拡張された値のいずれかでなければならない (MUST).
              </t>
              <!--
              <t hangText='response_type'>
                <vspace />
                REQUIRED. The value MUST be one of <spanx style='verb'>code</spanx> for requesting
                an authorization code as described by <xref target='code-authz-req' />,
                <spanx style='verb'>token</spanx> for requesting an access token (implicit grant)
                as described by <xref target='implicit-authz-req' />, or a registered extension
                value as described by <xref target='response-type-ext' />.
              </t>
              -->
            </list>
          </t>
          <t>
            拡張レスポンスタイプに空白文字 (%x20) 区切りのリスト値が含まれていてもよい (MAY).
            なお値の順序は問題としない (例：レスポンスタイプ <spanx style='verb'>a b</spanx> と <spanx style='verb'>b a</spanx> は同じである).
            このような復号レスポンスタイプの意味は各々の仕様にて定義される.
          </t>
          <!--
          <t>
            Extension response types MAY contain a space-delimited (%x20) list of values, where the
            order of values does not matter (e.g., response type <spanx style='verb'>a b</spanx> is
            the same as <spanx style='verb'>b a</spanx>). The meaning of such composite response
            types is defined by their respective specifications.
          </t>
          -->
          <t>
            認可リクエストで <spanx style='verb'>response_type</spanx> がない場合, もしくは未知のレスポンスタイプであった場合, 認可サーバーは <xref target='code-authz-error' /> で述べるエラーレスポンスを返さなくてはならない (MUST).
          </t>
          <!--
          <t>
            If an authorization request is missing the <spanx style='verb'>response_type</spanx>
            parameter, or if the response type is not understood, the authorization server MUST
            return an error response as described in <xref target='code-authz-error' />.
          </t>
          -->
        </section>

        <section title='リダイレクトエンドポイント' anchor='redirect-uri'>
        <!-- <section title='Redirection Endpoint' anchor='redirect-uri'> -->
          <t>
            リソースオーナーとのやりとりが完了した後, 認可サーバーはリソースオーナーのユーザーエージェントをクライアントへ誘導する.
            認可サーバーは, ユーザーエージェントを事前登録済もしくは認可リクエスト時に指定されたクライアントのリダイレクトエンドポイントにリダイレクトさせる.
          </t>
          <!--
          <t>
            After completing its interaction with the resource owner, the authorization server
            directs the resource owner's user-agent back to the client. The authorization server
            redirects the user-agent to the client's redirection endpoint previously established
            with the authorization server during the client registration process or when making
            the authorization request.
          </t>
          -->
          <t>
            リダイレクトエンドポイントのURIは <xref target='RFC3986' /> のセクション4.3で定義されている絶対URIでなければいけない (MUST).
            エンドポイントURIは <spanx style='verb'>application/x-www-form-urlencoded</spanx> (<xref target='urlencoded' />) フォーマットのクエリーコンポーネント (<xref target='RFC3986' /> セクション3.4) を含んでもよい (MAY).
            クエリーパラメーターを追加する際, ここで指定されたクエリーコンポーネントは維持すること (MUST).
            エンドポイントURIはフラグメントコンポーネントを含んではいけない (MUST NOT).
          </t>
          <!--
          <t>
            The redirection endpoint URI MUST be an absolute URI as defined by
            <xref target='RFC3986' /> Section 4.3. The endpoint URI MAY include an
            <spanx style='verb'>application/x-www-form-urlencoded</spanx> formatted
            (per <xref target="urlencoded"/>) query component (<xref target='RFC3986' />
            Section 3.4), which MUST be retained when adding additional query parameters. The
            endpoint URI MUST NOT include a fragment component.
          </t>
          -->

          <section title='エンドポイントリクエストの機密性'>
          <!-- <section title='Endpoint Request Confidentiality'> -->
            <t>
              リダイレクトエンドポイントは, リクエストされたレスポンスタイプが <spanx style='verb'>code</spanx> または <spanx style='verb'>token</spanx> である場合, およびリダイレクトリクエストによってオープンネットワーク上にセンシティブなクレデンシャルが転送されることになる場合は, <xref target='tls' /> に記載されているTLSを要求するべきである (SHOULD).
              本仕様作成時点においてクライアントがTLS対応するのは多くの開発者にとって大きな障害となることから, 本仕様ではTLSの使用を強制はしない.
              TLSが利用できない場合, 認可サーバーはリダイレクト前にリソースオーナーに対して安全でないエンドポイントであることを警告するべきである (SHOULD).
              (例えば, 認可リクエスト時にメッセージを表示する)
            </t>
            <!--
            <t>
              The redirection endpoint SHOULD require the use of TLS as described in
              <xref target='tls' /> when the requested response type is
              <spanx style='verb'>code</spanx> or <spanx style='verb'>token</spanx>, or
              when the redirection request will result in the transmission of sensitive credentials
              over an open network. This specification does not mandate the use of TLS because at
              the time of this writing, requiring clients to deploy TLS is a significant hurdle for
              many client developers. If TLS is not available, the authorization server SHOULD warn
              the resource owner about the insecure endpoint prior to redirection (e.g., display a
              message during the authorization request).
            </t>
            -->
            <t>
              トランスポート層のセキュリティの欠如は, クライアントのセキュリティ, およびアクセス認可対象の保護リソースのセキュリティに, 深刻な影響を及ぼす.
              トランスポート層のセキュリティは, クライアントが認可プロセスをエンドユーザー認証の委譲の為に利用する場合に, 特に重要である.
              (例えばサードパーティーサインインサービス)
            </t>
            <!--
            <t>
              Lack of transport-layer security can have a severe impact on the security of the
              client and the protected resources it is authorized to access. The use of
              transport-layer security is particularly critical when the authorization process is
              used as a form of delegated end-user authentication by the client (e.g., third-party
              sign-in service).
            </t>
            -->
          </section>

          <section title='登録要件'>
          <!-- <section title='Registration Requirements'> -->
            <t>
              認可サーバーは, 以下のようなクライアントに対してリダイレクトエンドポイントの事前登録を要求すること (MUST):
            </t>
            <!--
            <t>
              The authorization server MUST require the following clients to register their
              redirection endpoint:
            </t>
            -->
            <t>
              <list style='symbols'>
                <t>
                  パブリッククライアント.
                </t>
                <!--
                <t>
                  Public clients.
                </t>
                -->
                <t>
                  インプリシットグラントタイプを利用するコンフィデンシャルクライアント.
                </t>
                <!--
                <t>
                  Confidential clients utilizing the implicit grant type.
                </t>
                -->
              </list>
            </t>
            <t>
              認可サーバーは, すべてのクライアントに対して, 認可エンドポイントアクセス前にリダイレクトURIの事前登録を要求すべきである (SHOULD).
            </t>
            <!--
            <t>
              The authorization server SHOULD require all clients to register their redirection
              endpoint prior to utilizing the authorization endpoint.
            </t>
            -->
            <t>
              認可サーバーは, クライアントに (一部分ではなく) 完全なリダイレクトURIの登録を要求するべきである (SHOULD).
              (クライアントはリクエスト毎のカスタマイズするために <spanx style='verb'>state</spanx> リクエストパラメーターを使用できる (MAY))
              完全なリダイレクトURIの登録を要求することができない場合, 認可サーバーはURIスキーム, オーソリティー, パス (認可要求の時, リダイレクトURIのクエリーコンポーネントのみ動的に変更を許可する) の登録を要求するべきである (SHOULD).
            </t>
            <!--
            <t>
              The authorization server SHOULD require the client to provide the complete
              redirection URI (the client MAY use the <spanx style='verb'>state</spanx> request
              parameter to achieve per-request customization). If requiring the registration of
              the complete redirection URI is not possible, the authorization server SHOULD require
              the registration of the URI scheme, authority, and path (allowing the client to
              dynamically vary only the query component of the redirection URI when requesting
              authorization).
            </t>
            -->
            <t>
              認可サーバーはクライアントに複数のリダイレクトエンドポイントの登録を許可してもよい (MAY).
            </t>
            <!--
            <t>
              The authorization server MAY allow the client to register multiple redirection
              endpoints.
            </t>
            -->
            <t>
              リダイレクトURI登録が不要な場合, 攻撃者に認可エンドポイントを <xref target='open-redirect' /> に記載されているオープンリダイレクターとして利用されてしまうおそれがある.
            </t>
            <!--
            <t>
              Lack of a redirection URI registration requirement can enable an attacker to use
              the authorization endpoint as an open redirector as described in
              <xref target='open-redirect' />.
            </t>
            -->
          </section>

          <section title='動的設定'>
          <!-- <section title='Dynamic Configuration'> -->
            <t>
              リダイレクトURIが複数登録されている場合, リダイレクトURIの一部のみが登録されている場合, もしくはリダイレクトURIが登録されていない場合, クライアントは <spanx style='verb'>redirect_uri</spanx> リクエストパラメーターを使用して認可リクエストにリダイレクトURIを含めなければいけない (MUST).
            </t>
            <!--
            <t>
              If multiple redirection URIs have been registered, if only part of the redirection
              URI has been registered, or if no redirection URI has been registered, the client
              MUST include a redirection URI with the authorization request using the
              <spanx style='verb'>redirect_uri</spanx> request parameter.
            </t>
            -->
            <t>
              認可リクエスト中にリダイレクトURIが含まれており, かつリダイレクトURIが事前登録されている場合, <xref target='RFC3986' /> セクション6に示すとおり, 認可サーバーは認可リクエストに含まれる値を登録済リダイレクトURI (もしくはURIコンポーネント) と比較し, 少なくとも1つと一致することを確認しなければならない (MUST).
              もしクライアントの登録にフルのリダイレクトURIが含まれていた場合, 認可サーバーは <xref target='RFC3986' /> セクション6.2.1.で定義されているように単純な文字列比較を使用し二つのURIを比較しなければいけない (MUST).
            </t>
            <!--
            <t>
              When a redirection URI is included in an authorization request, the authorization
              server MUST compare and match the value received against at least one of the
              registered redirection URIs (or URI components) as defined in
              <xref target='RFC3986' /> Section 6, if any redirection URIs were registered.
              If the client registration included the full redirection URI, the authorization
              server MUST compare the two URIs using simple string comparison as defined
              in <xref target='RFC3986' /> Section 6.2.1.
            </t>
            -->
          </section>

          <section title='無効なエンドポイント'>
          <!-- <section title='Invalid Endpoint'> -->
            <t>
              認可リクエストがリダイレクトURIの欠落, 無効, もしくは不一致のため検証失敗なら, 認可サーバーはエラーをリソースオーナーに知らせるべきである (SHOULD).
              そして無効なリダイレクトURIにユーザーエージェントを自動でリダイレクトしてはいけない (MUST NOT).
            </t>
            <!--
            <t>
              If an authorization request fails validation due to a missing, invalid, or
              mismatching redirection URI, the authorization server SHOULD inform the resource
              owner of the error and MUST NOT automatically redirect the user-agent to the invalid
              redirection URI.
            </t>
            -->
          </section>

          <section title='エンドポイントコンテント'>
          <!-- <section title='Endpoint Content'> -->
            <t>
              クライアントのリダイレクトエンドポイントへリダイレクトすると, 通常はHTMLドキュメントが返され, そのレスポンスがユーザーエージェントに処理される.
              リダイレクトエンドポイントから直接HTMLレスポンスが返される場合, そのHTMLドキュメントに含まれるすべてのスクリプトはリダイレクトURIとそれに含まれるクレデンシャルにアクセス権限可能となる.
            </t>
            <!--
            <t>
              The redirection request to the client's endpoint typically results in an HTML
              document response, processed by the user-agent. If the HTML response is served
              directly as the result of the redirection request, any script included in the HTML
              document will execute with full access to the redirection URI and the credentials it
              contains.
            </t>
            -->
            <t>
              クライアントはリダイレクトエンドポイントのレスポンスにどのサードパーティーのスクリプトもインクルードするべきではない (SHOULD NOT).
              (例えばサードパーティーのアクセス解析, ソーシャルプラグイン, アドネットワーク)
              そのかわりに, クライアントはURIからクレデンシャルを抽出し, クレデンシャルを (URIや他のどこかに) 露出することなくユーザーエージェントを再び別のエンドポイントへリダイレクトするべきである (SHOULD).
              サードパーティのスクリプトがインクルードされていた場合, クライアントは自身の (URIからクレデンシャルを取得したり取り除くための) スクリプトが最初に実行されることを保証しなくてはならない (MUST).
            </t>
            <!--
            <t>
              The client SHOULD NOT include any third-party scripts (e.g., third-party analytics,
              social plug-ins, ad networks) in the redirection endpoint response. Instead, it
              SHOULD extract the credentials from the URI and redirect the user-agent again to
              another endpoint without exposing the credentials (in the URI or elsewhere). If
              third-party scripts are included, the client MUST ensure that its own scripts
              (used to extract and remove the credentials from the URI) will execute first.
            </t>
            -->
          </section>

        </section>

      </section>

      <section title='トークンエンドポイント'>
      <!-- <section title='Token Endpoint'> -->
        <t>
          トークンエンドポイントは, 認可グラントもしくはリフレッシュトークンをアクセストークンと交換するために, クライアントに利用される.
          トークンエンドポイントは, インプリシットグラントタイプ (アクセストークンが直接発行される) を除くすべてのグラントタイプで利用される.
        </t>
        <!--
        <t>
          The token endpoint is used by the client to obtain an access token by presenting its
          authorization grant or refresh token. The token endpoint is used with every authorization
          grant except for the implicit grant type (since an access token is issued directly).
        </t>
        -->
        <t>
          クライアントがトークンエンドポイントURLを取得する方法は本仕様の定めるところではないが, そのURLは一般的にサービスドキュメントで提供される.
        </t>
        <!--
        <t>
          The means through which the client obtains the location of the token endpoint are
          beyond the scope of this specification, but the location is typically provided in the service
          documentation.
        </t>
        -->
        <t>
          エンドポイントURIは <spanx style='verb'>application/x-www-form-urlencoded</spanx> (<xref target='urlencoded' />) フォーマットのクエリーコンポーネント (<xref target='RFC3986' /> セクション3.4) を含んでもよい (MAY).
          クエリーパラメーターを追加する際, ここで指定されたクエリーコンポーネントは維持すること (MUST).
          エンドポイントURIはフラグメントコンポーネントを含んではいけない (MUST NOT).
        </t>
        <!--
        <t>
          The endpoint URI MAY include an
          <spanx style='verb'>application/x-www-form-urlencoded</spanx> formatted
          (per <xref target="urlencoded"/>) query component (<xref target='RFC3986' />
          Section 3.4), which MUST be retained when adding additional query parameters. The
          endpoint URI MUST NOT include a fragment component.
        </t>
        -->
        <t>
          トークンエンドポイントでは, (HTTPリクエストおよびレスポンスにて) クレデンシャルが平文で転送されることになるため, 認可サーバーはトークンエンドポイントへリクエストにTLS (<xref target='tls' />) を必須としなくてはならない (MUST).
        </t>
        <!--
        <t>
          Since requests to the token endpoint result in the transmission of clear-text credentials
          (in the HTTP request and response), the authorization server MUST require the use of TLS
          as described in <xref target='tls' /> when sending requests to the token endpoint.
        </t>
        -->
        <t>
          クライアントはアクセストークンリクエストを送信する際に, HTTP <spanx style='verb'>POST</spanx> メソッドを使用しなければならない (MUST).
        </t>
        <!--
        <t>
          The client MUST use the HTTP <spanx style='verb'>POST</spanx> method when making access
          token requests.
        </t>
        -->
        <t>
          空の値で送信されたパラメーターは省略されたものとして扱われなければならない (MUST).
          認可サーバーは未知のリクエストパラメーターは無視しなければならない (MUST).
          リクエストおよびレスポンスパラメーターは重複を許さない (MUST NOT).
        </t>
        <!--
        <t>
          Parameters sent without a value MUST be treated as if they were omitted from the request.
          The authorization server MUST ignore unrecognized request parameters. Request and
          response parameters MUST NOT be included more than once.
        </t>
        -->

        <section title='クライアント認証' anchor='token-endpoint-auth'>
        <!-- <section title='Client Authentication' anchor='token-endpoint-auth'> -->
          <t>
            クライアントクレデンシャルまたは他の認証方法を利用可能なコンフィデンシャルクライアントは, <xref target='client-authentication' /> に従ってトークンエンドポイントへのリクエスト時に認可サーバーとの間で認証を行わなければならない (MUST).
            クライアント認証には以下の目的がある.
          </t>
          <!--
          <t>
            Confidential clients or other clients issued client credentials MUST authenticate with
            the authorization server as described in <xref target='client-authentication' /> when
            making requests to the token endpoint. Client authentication is used for:
          </t>
          -->
          <t>
            <list style='symbols'>
              <t>
                リフレッシュトークンおよび認可コードとその発行先のクライアントとの紐づけを強化する.
                認可コードがセキュアでないチャネルを通じてリダイレクトエンドポイントに送信された場合, またはリダイレクトURIが完全に登録されていない場合, クライアント認証は非常に重要である.
              </t>
              <!--
              <t>
                Enforcing the binding of refresh tokens and authorization codes to the client they
                were issued to. Client authentication is critical when an authorization code is
                transmitted to the redirection endpoint over an insecure channel or when the
                redirection URI has not been registered in full.
              </t>
              -->
              <t>
                クライアントの無効化あるいはクライアントクレデンシャルの変更によって, 盗まれたリフレッシュトークンの濫用を防止するなど, なんらかの攻撃にさらされたクライアントによる被害を抑える.
                一連のすべてのリフレッシュトークンを無効化するよりも, クライアントクレデンシャルの変更の方が遥かにすばやく実施できる.
              </t>
              <!--
              <t>
                Recovering from a compromised client by disabling the client or changing its
                credentials, thus preventing an attacker from abusing stolen refresh tokens. Changing
                a single set of client credentials is significantly faster than revoking an entire
                set of refresh tokens.
              </t>
              -->
              <t>
                定期的なクレデンシャルの更新など, 認証管理のベストプラクティスを実装する.
                一連のすべてのリフレッシュトークンを更新するのは困難だが, クライアントクレデンシャルの更新は非常に容易である.
              </t>
              <!--
              <t>
                Implementing authentication management best practices, which require periodic
                credential rotation. Rotation of an entire set of refresh tokens can be
                challenging, while rotation of a single set of client credentials is significantly
                easier.
              </t>
              -->
            </list>
          </t>
          <t>
            クライアントは, トークンエンドポイントへのリクエスト時に自身を識別するために, <spanx style='verb'>client_id</spanx> パラメーターを用いてもよい (MAY).
            トークンエンドポイントへのリクエスト時に <spanx style='verb'>authorization_code</spanx> <spanx style='verb'>grant_type</spanx> を指定する場合, 認証を行わないクライアントは, リクエストに <spanx style='verb'>client_id</spanx> を含み, 異なる <spanx style='verb'>client_id</spanx> に対して発行されたコードを不用意に受け入れてしまうことを防がなければならない (MUST).
            これはクライアントに対する認可コード置換攻撃への対策となる (保護リソースに対してのセキュリティ対策は提供していない).
          </t>
          <!--
          <t>
            A client MAY use the
            <spanx style='verb'>client_id</spanx> request parameter to identify itself when sending
            requests to the token endpoint.
            In the <spanx style='verb'>authorization_code</spanx>
            <spanx style='verb'>grant_type</spanx> request to the token endpoint,
            an unauthenticated client MUST send its
            <spanx style='verb'>client_id</spanx> to prevent itself from
            inadvertently accepting a code intended for a client with a different
            <spanx style='verb'>client_id</spanx>.  This protects the client from substitution of the
            authentication code.  (It provides no additional security for the
            protected resource.)
          </t>
          -->
        </section>

      </section>

      <section title='アクセストークンのスコープ' anchor='scope'>
      <!-- <section title='Access Token Scope' anchor='scope'> -->
        <t>
          認可エンドポイントおよびトークンエンドポイントでは, クライアントは <spanx style='verb'>scope</spanx> リクエストパラメーターを用いて要求するアクセス範囲を明示することができる.
          同様に, 認可サーバーは発行されたアクセストークンの範囲をクライアントに通知するために <spanx style='verb'>scope</spanx> レスポンスパラメーターを使用する.
        </t>
        <!--
        <t>
          The authorization and token endpoints allow the client to specify the scope of the access
          request using the <spanx style='verb'>scope</spanx> request parameter. In turn, the
          authorization server uses the <spanx style='verb'>scope</spanx> response parameter to
          inform the client of the scope of the access token issued.
        </t>
        -->
        <t>
          スコープパラメーターの値は大文字と小文字を区別する文字列で, スペース区切りのリストで示される.
          文字列は認可サーバーによって定義されている.
          値が複数のスペース区切りの文字列を含んでいる場合, その順序に意味は無く, それぞれのアクセス範囲を足し合わせたものが要求されるスコープになる.
        </t>
        <!--
        <t>
          The value of the scope parameter is expressed as a list of space-delimited, case-sensitive strings. The strings are defined by the authorization server. If the value
          contains multiple space-delimited strings, their order does not matter, and each string
          adds an additional access range to the requested scope.
        </t>
        -->
        <figure>
          <artwork><![CDATA[
  scope       = scope-token *( SP scope-token )
  scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
]]></artwork>
        </figure>
        <t>
          認可サーバーは, 認可サーバーのポリシーまたはリソースオーナーの指示に基づいて, クライアントに要求されたスコープの一部もしくはすべてを無視してもよい (MAY).
          発行されたアクセストークンのスコープがクライアントから要求されたものと異なる場合, 認可サーバーは実際に許可されたスコープをクライアントに通知するため, <spanx style='verb'>scope</spanx> レスポンスパラメーターを含めなくてはならない (MUST).
        </t>
        <!--
        <t>
          The authorization server MAY fully or partially ignore the scope requested by the client,
          based on the authorization server policy or the resource owner's instructions. If the
          issued access token scope is different from the one requested by the client, the
          authorization server MUST include the <spanx style='verb'>scope</spanx> response
          parameter to inform the client of the actual scope granted.
        </t>
        -->
        <t>
          認可リクエスト時にクライアントがスコープパラメーターを省略した場合, 認可サーバーは事前に定義されたデフォルト値が指定されたものとするか, 無効なスコープを意味しているものとしてリクエスト失敗とするかのどちらかを処理しなければならない (MUST).
          認可サーバーはスコープ要件と (もし定義されていれば) デフォルト値をドキュメント化するべきである (SHOULD).
        </t>
        <!--
        <t>
          If the client omits the scope parameter when requesting authorization, the authorization
          server MUST either process the request using a pre-defined default value or fail the
          request indicating an invalid scope. The authorization server SHOULD document its scope
          requirements and default value (if defined).
        </t>
        -->
      </section>

    </section>

    <section title='認可の取得'>
    <!-- <section title='Obtaining Authorization'> -->
      <t>
        アクセストークンを要求するため, まずクライアントはリソースオーナーから認可を取得する.
        認可は, クライアントがアクセストークンを要求するのに使用する認可グラントの形式で表現される.
        OAuthでは, 4つのグラントタイプ (認可コード, インプリシット, リソースオーナーパスワードクレデンシャル, クライアントクレデンシャル) を定義している.
        また, 拡張仕様によって新たなグラントタイプを追加することも可能である.
      </t>
      <!--
      <t>
        To request an access token, the client obtains authorization from the resource owner. The
        authorization is expressed in the form of an authorization grant, which the client uses to
        request the access token. OAuth defines four grant types: authorization code, implicit,
        resource owner password credentials, and client credentials. It also provides an extension
        mechanism for defining additional grant types.
      </t>
      -->

      <section title='認可コードによる認可' anchor='grant-code'>
      <!-- <section title='Authorization Code Grant' anchor='grant-code'> -->
        <t>
          認可コードグラントタイプは, アクセストークンとリフレッシュトークの両方を取得するために用いられ, コンフィデンシャルクライアントに最適化されている.
          このグラントタイプではリダイレクトベースのフローが利用されるため, クライアントはリソースオーナーのユーザーエージェント (通常はWebブラウザ) と対話し, 認可サーバーによる (リダイレクトを通した) リクエストを受け付けることが出来なくてはいけない.
        </t>
        <!--
        <t>
          The authorization code grant type is used to obtain both access tokens and refresh
          tokens and is optimized for confidential clients. Since this is a redirection-based flow, the client
          must be capable of interacting with the resource owner's user-agent (typically a web
          browser) and capable of receiving incoming requests (via redirection) from the
          authorization server.
        </t>
        -->
        <figure title='認可コード処理フロー' anchor='Figure-3'>
        <!-- <figure title='Authorization Code Flow' anchor='Figure-3'> -->
          <artwork><![CDATA[
  +----------+
  | Resource |
  |   Owner  |
  |          |
  +----------+
       ^
       |
      (B)
  +----|-----+          Client Identifier      +---------------+
  |         -+----(A)-- & Redirection URI ---->|               |
  |  User-   |                                 | Authorization |
  |  Agent  -+----(B)-- User authenticates --->|     Server    |
  |          |                                 |               |
  |         -+----(C)-- Authorization Code ---<|               |
  +-|----|---+                                 +---------------+
    |    |                                         ^      v
   (A)  (C)                                        |      |
    |    |                                         |      |
    ^    v                                         |      |
  +---------+                                      |      |
  |         |>---(D)-- Authorization Code ---------'      |
  |  Client |          & Redirection URI                  |
  |         |                                             |
  |         |<---(E)----- Access Token -------------------'
  +---------+       (w/ Optional Refresh Token)
]]></artwork>
          <postamble>
            注記: (A), (B), (C) のステップを表す線はユーザーエージェント経由で渡されるため２つに分かれている.
          </postamble>
          <!--
          <postamble>
            Note: The lines illustrating steps (A), (B), and (C) are broken into two parts as they pass
            through the user-agent.
          </postamble>
          -->
        </figure>
        <t>
          <xref target='Figure-3' /> のフローは以下の通りである.
        </t>
        <!--
        <t>
          The flow illustrated in <xref target='Figure-3' /> includes the following steps:
        </t>
        -->
        <t>
          <list style='format (%C)'>
            <t>
              クライアントがリソースオーナーのユーザーエージェントを認可エンドポイントに送ることで, フローが開始する.
              このときクライアントは, クライアント識別子, リクエストスコープ, ローカルステート, および認可サーバーがアクセス許可 (あるいは拒否) 取得後にユーザーエージェントを戻すリダイレクトURIをリクエストに含める.
            </t>
            <!--
            <t>
              The client initiates the flow by directing the resource owner's user-agent to the
              authorization endpoint. The client includes its client identifier, requested
              scope, local state, and a redirection URI to which the authorization server will send
              the user-agent back once access is granted (or denied).
            </t>
            -->
            <t>
              認可サーバーは (ユーザーエージェント経由で) リソースオーナーを認証し, リソースオーナーにアクセス要求の許可/拒否をたずねる.
            </t>
            <!--
            <t>
              The authorization server authenticates the resource owner (via the user-agent) and
              establishes whether the resource owner grants or denies the client's access request.
            </t>
            -->
            <t>
              リソースオーナーがアクセスを許可した場合, 認可サーバーは予め与えられていた (リクエストもしくはクライアント登録時に指定される) リダイレクトURIを用いて, ユーザーエージェントをリダイレクトさせてクライアントに戻す.
              リダイレクトURIには, 認可コード, クライアントから事前に送られたローカルステートが含まれる.
            </t>
            <!--
            <t>
              Assuming the resource owner grants access, the authorization server redirects the
              user-agent back to the client using the redirection URI provided earlier (in the
              request or during client registration). The redirection URI includes an authorization
              code and any local state provided by the client earlier.
            </t>
            -->
            <t>
              クライアントは前のステップで取得した認可コードを認可サーバーのトークンエンドポイントに送ることでアクセストークンを要求する.
              このとき, クライアントは認可サーバーとの間で認証を行う.
              またクライアントは認可コード取得時に使用したリダイレクトURIを検証のためリクエストに含める.
            </t>
            <!--
            <t>
              The client requests an access token from the authorization server's token endpoint
              by including the authorization code received in the previous step. When making the
              request, the client authenticates with the authorization server. The client includes
              the redirection URI used to obtain the authorization code for verification.
            </t>
            -->
            <t>
              認可サーバーはクライアントを認証し, 認可コードを検証し, 受け取ったリダイレクトURIがステップ (C) で使用したURIと同一であることを確かめる.
              その結果, 正当である場合, 認可サーバーはアクセストークンと任意でリフレッシュトークンを返却する.
            </t>
            <!--
            <t>
              The authorization server authenticates the client, validates the authorization code,
              and ensures that the redirection URI received matches the URI used to redirect the client
              in step&nbsp;(C). If valid, the authorization server responds back with an access token
              and, optionally, a refresh token.
            </t>
            -->
          </list>
        </t>

        <section title='認可リクエスト' anchor='code-authz-req'>
        <!-- <section title='Authorization Request' anchor='code-authz-req'> -->
          <t>
            クライアントは, <xref target='urlencoded' /> で規定された <spanx style='verb'>application/x-www-form-urlencoded</spanx> フォーマットを用いて認可エンドポイントURIへのクエリーとして, 次のパラメーターを付与する.
          </t>
          <!--
          <t>
            The client constructs the request URI by adding the following parameters to the
            query component of the authorization endpoint URI using the
            <spanx style='verb'>application/x-www-form-urlencoded</spanx> format,
            per <xref target="urlencoded"/>:
          </t>
          -->
          <t>
            <list style='hanging' hangIndent='6'>
              <t hangText='response_type'>
                <vspace />
                必須 (REQUIRED).
                値は必ず <spanx style='verb'>code</spanx> にしなければならない (MUST).
              </t>
              <!--
              <t hangText='response_type'>
                <vspace />
                REQUIRED. Value MUST be set to <spanx style='verb'>code</spanx>.
              </t>
              -->
              <t hangText='client_id'>
                <vspace />
                必須 (REQUIRED).
                詳細は <xref target='client-identifier' /> を参照のこと.
              </t>
              <!--
              <t hangText='client_id'>
                <vspace />
                REQUIRED. The client identifier as described in
                <xref target='client-identifier' />.
              </t>
              -->
              <t hangText='redirect_uri'>
                <vspace />
                任意 (OPTIONAL).
                詳細は <xref target='redirect-uri' /> を参照のこと.
              </t>
              <!--
              <t hangText='redirect_uri'>
                <vspace />
                OPTIONAL. As described in <xref target='redirect-uri' />.
              </t>
              -->
              <t hangText='scope'>
                <vspace />
                任意 (OPTIONAL).
                詳細は <xref target='scope' /> を参照のこと.
              </t>
              <!--
              <t hangText='scope'>
                <vspace />
                OPTIONAL. The scope of the access request as described by <xref target='scope' />.
              </t>
              -->
              <t hangText='state'>
                <vspace />
                推奨 (RECOMMENDED).
                リクエストとコールバックの間で状態を維持するために使用するランダムな値.
                認可サーバーはリダイレクトによってクライアントに処理を戻す際にこの値を付与する.
                このパラメーターは <xref target='CSRF' /> に記載されているクロスサイトリクエストフォージェリを防ぐために用いられるべきである (SHOULD).
              </t>
              <!--
              <t hangText='state'>
                <vspace />
                RECOMMENDED. An opaque value used by the client to maintain state between the request
                and callback. The authorization server includes this value when redirecting the
                user-agent back to the client. The parameter SHOULD be used for preventing
                cross-site request forgery as described in <xref target='CSRF' />.
              </t>
              -->
            </list>
          </t>
          <t>
            クライアントは, HTTPリダイレクトまたはユーザーエージェントを介したその他の利用可能な手段によって, リソースオーナーを構築されたURIに送る.
          </t>
          <!--
          <t>
            The client directs the resource owner to the constructed URI using an HTTP redirection
            response, or by other means available to it via the user&nbhy;agent.
          </t>
          -->
          <figure>
            <preamble>
              例えば, クライアントはユーザーエージェントに次のHTTPリクエストをTLSを用いて実行させる (改行は掲載上の都合による).
            </preamble>
            <!--
            <preamble>
              For example, the client directs the user-agent to make the following HTTP request
              using TLS (with extra line breaks for display purposes only):
            </preamble>
            -->
            <artwork><![CDATA[
  GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
      &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
  Host: server.example.com
]]></artwork>
          </figure>
          <t>
            認可サーバーは必要なリクエストパラメーターがすべて揃っていて, かつ正当であることを検証する.
            リクエストが正当であれば, 認可サーバーはリソースオーナーを認証し, (リソースオーナーに確認することによって, または他の手段によって承認を確立することによって) 認可の判定を得る.
          </t>
          <!--
          <t>
            The authorization server validates the request to ensure that all required parameters are
            present and valid. If the request is valid, the authorization server authenticates the
            resource owner and obtains an authorization decision (by asking the resource owner or
            by establishing approval via other means).
          </t>
          -->
          <t>
            判定が成立すると, 認可サーバーはHTTPリダイレクトレスポンスまたはユーザーエージェントを介したその他の利用可能な手段を用いて, 与えられたリダイレクトURIにユーザーエージェントを送る.
          </t>
          <!--
          <t>
            When a decision is established, the authorization server directs the user-agent to the
            provided client redirection URI using an HTTP redirection response, or by other means
            available to it via the user&nbhy;agent.
          </t>
          -->
        </section>

        <section title='認可レスポンス' anchor="code-authz-resp">
        <!-- <section title='Authorization Response' anchor="code-authz-resp"> -->
          <t>
            リソースオーナーがアクセスリクエストを許可した場合, 認可サーバーは認可コードを発行し, <spanx style='verb'>application/x-www-form-urlencoded</spanx> (<xref target="urlencoded"/>) フォーマットを用いてリダイレクトURIのクエリーコンポーネントに次のパラメーターを付与してクライアントに送る.
          </t>
          <!--
          <t>
            If the resource owner grants the access request, the authorization server issues an
            authorization code and delivers it to the client by adding the following parameters to
            the query component of the redirection URI using the
            <spanx style='verb'>application/x-www-form-urlencoded</spanx> format,
            per <xref target="urlencoded"/>:
          </t>
          -->
          <t>
            <list style='hanging' hangIndent='6'>
              <t hangText='code'>
                <vspace />
                必須 (REQUIRED).
                認可コードは認可サーバーによって許可される.
                漏洩のリスクを軽減するため, 認可コードは発行されてから短期間で無効にしなければならない (MUST).
                認可コードの有効期限は最大でも10分を推奨する (RECOMMENDED).
                クライアントは2回以上認可コードを使用してはならない (MUST NOT).
                もし認可コードが2回以上使用された場合は, 認可サーバーはリクエストを拒否しなければならず (MUST), この認可コードを基に発行されたこれまでのすべてのトークンを無効化すべきである (SHOULD).
                認可コードはクライアント識別子とリダイレクトURIに紐づく.
              </t>
              <!--
              <t hangText='code'>
                <vspace />
                REQUIRED. The authorization code generated by the authorization server. The
                authorization code MUST expire shortly after it is issued to mitigate the risk of
                leaks. A maximum authorization code lifetime of 10 minutes is RECOMMENDED. The
                client MUST NOT use the authorization code more than once. If an authorization code
                is used more than once, the authorization server MUST deny the request and SHOULD
                revoke (when possible) all tokens previously issued based on that authorization
                code. The authorization code is bound to the client identifier and redirection URI.
              </t>
              -->
              <t hangText='state'>
                <vspace />
                クライアントからの認可リクエストに <spanx style='verb'>state</spanx> パラメーターが含まれていた場合は必須 (REQUIRED).
                クライアントから受け取った値をそのまま返す.
              </t>
              <!--
              <t hangText='state'>
                <vspace />
                REQUIRED if the <spanx style='verb'>state</spanx> parameter was present in the
                client authorization request. The exact value received from the client.
              </t>
              -->
            </list>
          </t>
          <figure>
            <preamble>
              例えば, 認可サーバーは次のようなHTTPレスポンスをユーザーエージェントに返し, ユーザーエージェントをリダイレクトさせる.
            </preamble>
            <!--
            <preamble>
              For example, the authorization server redirects the user-agent by sending the
              following HTTP response:
            </preamble>
            -->
            <artwork><![CDATA[
  HTTP/1.1 302 Found
  Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
            &state=xyz
]]></artwork>
          </figure>
          <t>
            クライアントは認識できないレスポンスパラメーターを無視しなくてはならない (MUST).
            認可コードの文字列長は本仕様では定義しない.
            クライアントはコード値のサイズについてなんらかの仮定をすべきではない.
            認可サーバーは自身が発行するあらゆる値のサイズについてドキュメントに明記すべきである (SHOULD).
          </t>
          <!--
          <t>
            The client MUST ignore unrecognized response parameters. The authorization code
            string size is left undefined by this specification. The client should avoid making
            assumptions about code value sizes. The authorization server SHOULD document the size
            of any value it issues.
          </t>
          -->

          <section title='エラーレスポンス' anchor='code-authz-error'>
          <!-- <section title='Error Response' anchor='code-authz-error'> -->
            <t>
              リクエストが, リダイレクトURIの欠落 / 不正 / ミスマッチによって失敗した場合, もしくはクライアント識別子が不正な場合は, 認可サーバーはリソースオーナーにエラーを通知すべきである (SHOULD).
              不正なリダイレクトURIに対してユーザーエージェントを自動的にリダイレクトさせてはならない (MUST NOT).
            </t>
            <!--
            <t>
              If the request fails due to a missing, invalid, or mismatching redirection URI, or if
              the client identifier is missing or invalid, the authorization server SHOULD inform
              the resource owner of the error and MUST NOT automatically redirect the user-agent
              to the invalid redirection URI.
            </t>
            -->
            <t>
              リソースオーナーがアクセス要求を拒否した場合, もしくはリダイレクトURIの欠落や不正以外でリクエストが失敗した場合は, 認可サーバーは <spanx style='verb'>application/x-www-form-urlencoded</spanx> (<xref target="urlencoded"/>) フォーマットを用いてリダイレクトURIのクエリーコンポーネントに次のようなパラメーターを付与してクライアントに返却する.
            </t>
            <!--
            <t>
              If the resource owner denies the access request or if the request fails for reasons
              other than a missing or invalid redirection URI, the authorization server informs the
              client by adding the following parameters to the query component of the redirection
              URI using the <spanx style='verb'>application/x-www-form-urlencoded</spanx> format,
              per <xref target="urlencoded"/>:
            </t>
            -->
            <t>
              <list style='hanging' hangIndent='6'>
                <t hangText='error'>
                  <vspace />
                  必須 (REQUIRED).
                  次のASCII (<xref target="USASCII" />) で表されるエラーコードの中の1つ:
                  <!-- REQUIRED. A single ASCII <xref target="USASCII" /> error code from the following: -->

                  <list style='hanging' hangIndent='6'>
                    <t hangText='invalid_request'>
                      <vspace />
                      リクエストに必須パラメーターが含まれていない, サポート外のパラメーターが付与されている,
                      同一のパラメーターが複数含まれる場合, その他不正な形式であった場合もこれに含まれる.
                    </t>
                    <!--
                    <t hangText='invalid_request'>
                      <vspace />
                      The request is missing a required parameter, includes an invalid
                      parameter value, includes a parameter more than once, or is otherwise
                      malformed.
                    </t>
                    -->
                    <t hangText='unauthorized_client'>
                      <vspace />
                      クライアントは現在の方法で認可コードを取得することを認可されていない.
                    </t>
                    <!--
                    <t hangText='unauthorized_client'>
                      <vspace />
                      The client is not authorized to request an authorization code using this
                      method.
                    </t>
                    -->
                    <t hangText='access_denied'>
                      <vspace />
                      リソースオーナーまたは認可サーバーがリクエストを拒否した
                    </t>
                    <!--
                    <t hangText='access_denied'>
                      <vspace />
                      The resource owner or authorization server denied the request.
                    </t>
                    -->
                    <t hangText='unsupported_response_type'>
                      <vspace />
                      認可サーバーは現在の方法による認可コード取得をサポートしていない.
                    </t>
                    <!--
                    <t hangText='unsupported_response_type'>
                      <vspace />
                      The authorization server does not support obtaining an authorization code
                      using this method.
                    </t>
                    -->
                    <t hangText='invalid_scope'>
                      <vspace />
                      リクエストスコープが不正, 未知, もしくはその他の不当な形式である.
                    </t>
                    <!--
                    <t hangText='invalid_scope'>
                      <vspace />
                      The requested scope is invalid, unknown, or malformed.
                    </t>
                    -->
                    <t hangText='server_error'>
                      <vspace />
                      認可サーバーがリクエストの処理ができないような予期しない状況に遭遇した.
                      (500 Internal Server Error のHTTPステータスコードをHTTPのリダイレクトでクライアントに返すことができないため, このエラーコードは必要である)
                    </t>
                    <!--
                    <t hangText='server_error'>
                      <vspace />
                      The authorization server encountered an unexpected condition that prevented
                      it from fulfilling the request.
                      (This error code is needed because a 500 Internal Server Error
                      HTTP status code cannot be returned to the client
                      via an HTTP redirect.)
                    </t>
                    -->
                    <t hangText='temporarily_unavailable'>
                      <vspace />
                      認可サーバーが一時的な過負荷やメンテナンスによってリクエストを扱うことが出来ない.
                      (503 Service Unavailable のHTTPステータスコードをHTTPのリダイレクトでクライアントに返すことができないため, このエラーコードは必要である)
                    </t>
                    <!--
                    <t hangText='temporarily_unavailable'>
                      <vspace />
                      The authorization server is currently unable to handle the request due to a
                      temporary overloading or maintenance of the server.
                      (This error code is needed because a 503 Service Unavailable
                      HTTP status code cannot be returned to the client
                      via an HTTP redirect.)
                    </t>
                    -->
                  </list>

                  <spanx style='verb'>error</spanx> パラメーター値は %x20-21 / %x23-5B / %x5D-7E 以外の文字セットを含んではならない (MUST NOT).
                  <!--
                  Values for the <spanx style='verb'>error</spanx> parameter MUST NOT include
                  characters outside the set %x20-21 / %x23-5B / %x5D-7E.
                  -->
                </t>
                <t hangText='error_description'>
                  <vspace />
                  任意 (OPTIONAL).
                  クライアント開発者が発生したエラーを理解する際の手助けとなる, 可読性のあるASCII (<xref target="USASCII" />) 文字列で表される追加情報.
                  <vspace/>
                  <spanx style='verb'>error_description</spanx> パラメーター値は %x20-21 / %x23-5B / %x5D-7E 以外の文字セットを含んではならない (MUST NOT).
                </t>
                <!--
                <t hangText='error_description'>
                  <vspace />
                  OPTIONAL. Human-readable ASCII <xref target="USASCII" /> text providing additional information,
                  used to assist the client developer in understanding the error that occurred.
                  <vspace/>
                  Values for the <spanx style='verb'>error_description</spanx> parameter MUST NOT include
                  characters outside the set %x20-21 / %x23-5B / %x5D-7E.
                </t>
                -->
                <t hangText='error_uri'>
                  <vspace />
                  任意 (OPTIONAL).
                  クライアント開発者が発生したエラーに関する追加の情報を得ることができるWebページのURI.
                  <vspace/>
                  <spanx style='verb'>error_uri</spanx> パラメーター値はURI構文に従い (MUST), %x21 / %x23-5B / %x5D-7E 以外の文字セットを含んではならない (MUST NOT).
                </t>
                <!--
                <t hangText='error_uri'>
                  <vspace />
                  OPTIONAL. A URI identifying a human-readable web page with information about the
                  error, used to provide the client developer with additional information about the
                  error.
                  <vspace/>
                  Values for the <spanx style='verb'>error_uri</spanx> parameter
                  MUST conform to the URI&nbhy;reference syntax and thus MUST NOT include
                  characters outside the set %x21 / %x23-5B / %x5D-7E.
                </t>
                -->
                <t hangText='state'>
                  <vspace />
                  <spanx style='verb'>state</spanx> パラメーターがクライアントからの認可リクエストに含めれていた場合は必須 (REQUIRED).
                  クライアントから受け取った値をそのまま返す.
                </t>
                <!--
                <t hangText='state'>
                  <vspace />
                  REQUIRED if a <spanx style='verb'>state</spanx> parameter was present in the
                  client authorization request. The exact value received from the client.
                </t>
                -->
              </list>
            </t>
            <figure>
              <preamble>
                例として, 認可サーバーは次のようなHTTPレスポンスをユーザーエージェントに返し, ユーザーエージェントをリダイレクトさせる.
              </preamble>
              <!--
              <preamble>
                For example, the authorization server redirects the user-agent by sending the
                following HTTP response:
              </preamble>
              -->
              <artwork><![CDATA[
  HTTP/1.1 302 Found
  Location: https://client.example.com/cb?error=access_denied&state=xyz
]]></artwork>
            </figure>
          </section>

        </section>

        <section title='アクセストークンリクエスト' anchor="token-req">
        <!-- <section title='Access Token Request' anchor="token-req"> -->
          <t>
            クライアントはトークンエンドポイントに対して, 次のようなパラメーターを付与してリクエストを送信する.
            パラメーターはHTTPリクエストのエンティティーボディにUTF-8でそれぞれエンコード (<xref target="urlencoded"/>) して <spanx style='verb'>application/x-www-form-urlencoded</spanx> フォーマットで含める.
          </t>
          <!--
          <t>
            The client makes a request to the token endpoint by sending the following parameters
            using the <spanx style='verb'>application/x-www-form-urlencoded</spanx> format
            per <xref target="urlencoded"/> with a character encoding of UTF-8
            in the HTTP request entity-body:
          </t>
          -->
          <t>
            <list style='hanging' hangIndent='6'>
              <t hangText='grant_type'>
                <vspace />
                必須 (REQUIRED).
                値は <spanx style='verb'>authorization_code</spanx> でなければならない (MUST).
              </t>
              <!--
              <t hangText='grant_type'>
                <vspace />
                REQUIRED. Value MUST be set to <spanx style='verb'>authorization_code</spanx>.
              </t>
              -->
              <t hangText='code'>
                <vspace />
                必須 (REQUIRED).
                認可サーバーから受け取った認可コード.
              </t>
              <!--
              <t hangText='code'>
                <vspace />
                REQUIRED. The authorization code received from the authorization server.
              </t>
              -->
              <t hangText='redirect_uri'>
                <vspace />
                <xref target='code-authz-req' /> で示す認可リクエストに, <spanx style='verb'>redirect_uri</spanx> パラメーターが含まれていた場合は必須 (REQUIRED).
                認可リクエスト時と同じ値でなければならない (MUST).
              </t>
              <!--
              <t hangText='redirect_uri'>
                <vspace />
                REQUIRED, if the <spanx style='verb'>redirect_uri</spanx> parameter was included in
                the authorization request as described in <xref target='code-authz-req' />, and
                their values MUST be identical.
              </t>
              -->
              <t hangText="client_id">
                <vspace/>
                <xref target='token-endpoint-auth' /> で示すように認可サーバーよってクライアントが認証されていなければ必須 (REQUIRED) .
              </t>
              <!--
              <t hangText="client_id">
                <vspace/>
                REQUIRED, if the client is not authenticating with the
                authorization server as described in <xref target="token-endpoint-auth"/>.
              </t>
              -->
            </list>
          </t>
          <t>
            クライアントタイプがコンフィデンシャルである場合, あるいはクライアントクレデンシャルが発行された (もしくはその他の認証が要求された) クライアントの場合は, <xref target='token-endpoint-auth' /> に示すとおり認可サーバーにより認証されなければならない (MUST).
          </t>
          <!--
          <t>
            If the client type is confidential or the client was issued client credentials (or
            assigned other authentication requirements), the client MUST authenticate with the
            authorization server as described in <xref target='token-endpoint-auth' />.
          </t>
          -->
          <figure>
            <preamble>
              例として, クライアントは次のようなHTTPリクエストをTLSを用いて送信する (余分な改行は掲載上の都合による).
            </preamble>
            <!--
            <preamble>
              For example, the client makes the following HTTP request using TLS
              (with extra line breaks for display purposes only):
            </preamble>
            -->
            <artwork><![CDATA[
  POST /token HTTP/1.1
  Host: server.example.com
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
  Content-Type: application/x-www-form-urlencoded

  grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
  &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
]]></artwork>
          </figure>
          <t>
            認可サーバーは以下に従わなければならない (MUST):
          </t>
          <!--
          <t>
            The authorization server MUST:
          </t>
          -->
          <t>
            <list style='symbols'>
              <t>
                コンフィデンシャルクライアント, あるいはクライアントクレデンシャルが発行された (もしくはその他の認証が要求された) クライアントにクライアント認証を要求する.
              </t>
              <!--
              <t>
                require client authentication for confidential clients or for any client that was
                issued client credentials (or with other authentication requirements),
              </t>
              -->
              <t>
                クライアントの認証情報が含まれていた場合はクライアントを認証する.
              </t>
              <!--
              <t>
                authenticate the client if client authentication is included,
              </t>
              -->
              <t>
                クライアントがコンフィデンシャルクライアントの場合は, 認可コードが確かに認証されたクライアントに対して発行されたことを確認する.
                クライアントがパブリッククライアントの場合は, 認可コードが確かに指定された <spanx style='verb'>client_id</spanx> に紐づくクライアントに対して発行されていることを確認する.
              </t>
              <!--
              <t>
                ensure that the authorization code was issued to the authenticated
                confidential client, or if the client is public, ensure that the code was issued to
                <spanx style='verb'>client_id</spanx> in the request,
              </t>
              -->
              <t>
                認可コードが正当であることを検証する.
              </t>
              <!--
              <t>
                verify that the authorization code is valid, and
              </t>
              -->
              <t>
                <xref target='code-authz-req' /> で述べた認可リクエスト時に <spanx style='verb'>redirect_uri</spanx> パラメータが含まれていた場合, ここでも <spanx style='verb'>redirect_uri</spanx> が存在し認可リクエスト時と同じ値であることを確認する.
              </t>
              <!--
              <t>
                ensure that the <spanx style='verb'>redirect_uri</spanx> parameter is present if
                the <spanx style='verb'>redirect_uri</spanx> parameter was included in the initial
                authorization request as described in <xref target='code-authz-req' />, and if
                included ensure that their values are identical.
              </t>
              -->
            </list>
          </t>
        </section>

        <section title='アクセストークンレスポンス'>
        <!-- <section title='Access Token Response'> -->
          <t>
            アクセストークンリクエストが正当かつ認可された場合, 認可サーバーは <xref target='token-response' /> に示すとおりアクセストークンおよび任意でリフレッシュトークンを発行する.
            もしリクエストが失敗もしくは不正だった場合, 認可サーバーは <xref target='token-errors' /> に示すとおりエラーレスポンスを返却する.
          </t>
          <!--
          <t>
            If the access token request is valid and authorized, the authorization server issues an
            access token and optional refresh token as described in <xref target='token-response' />.
            If the request client authentication failed or is invalid, the authorization server returns
            an error response as described in <xref target='token-errors' />.
          </t>
          -->
          <figure>
            <preamble>
              成功レスポンス例を以下に示す.
            </preamble>
            <!--
            <preamble>
              An example successful response:
            </preamble>
            -->
            <artwork><![CDATA[
  HTTP/1.1 200 OK
  Content-Type: application/json;charset=UTF-8
  Cache-Control: no-store
  Pragma: no-cache

  {
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"example",
    "expires_in":3600,
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
    "example_parameter":"example_value"
  }
]]></artwork>
          </figure>
        </section>

      </section>

      <section title='インプリシットグラント' anchor='grant-implicit'>
      <!-- <section title='Implicit Grant' anchor='grant-implicit'> -->
        <t>
          インプリシットグラントタイプは, アクセストークンを取得するために用いられ (リフレッシュトークンの発行はサポートされない), 特定のリダイレクトURIを利用することが既知であるパブリッククライアントに最適化されている.
          これらのクライアントは, 通常JavaScriptなどのスクリプト言語を使用してブラウザ上に実装される.
        </t>
        <!--
        <t>
          The implicit grant type is used to obtain access tokens (it does not support the issuance
          of refresh tokens) and is optimized for public clients known to operate a particular
          redirection URI. These clients are typically implemented in a browser using a scripting
          language such as JavaScript.
        </t>
        -->
        <t>
          このグラントタイプではリダイレクトベースのフローが利用されるため, クライアントはリソースオーナーのユーザーエージェント (通常はWebブラウザ) と対話し, 認可サーバーによる (リダイレクトを通した) リクエストを受け付けることが出来なくてはいけない.
        </t>
        <!--
        <t>
          Since this is a redirection-based flow, the client must be capable of interacting with the
          resource owner's user-agent (typically a web browser) and capable of receiving incoming
          requests (via redirection) from the authorization server.
        </t>
        -->
        <t>
          認可リクエストとアクセストークン取得のリクエストが分離されている認可コードグラントタイプと異なり, クライアントは認可リクエストの結果としてアクセストークンを受け取る.
        </t>
        <!--
        <t>
          Unlike the authorization code grant type, in which the client makes separate requests for
          authorization and for an access token, the client receives the access token as the result of the
          authorization request.
        </t>
        -->
        <t>
          インプリシットグラントタイプではクライアント認証は行わず, リソースオーナーの介在とリダイレクトURIの事前登録に頼っている.
          アクセストークンはリダイレクトURI中にエンコードされるため, リソースオーナーと同一デバイス上のその他のアプリケーションに漏えいするかもしれない.
        </t>
        <!--
        <t>
          The implicit grant type does not include client authentication, and relies on the
          presence of the resource owner and the registration of the redirection URI. Because the
          access token is encoded into the redirection URI, it may be exposed to the resource owner
          and other applications residing on the same device.
        </t>
        -->
        <figure title='インプリシットグラントフロー' anchor='Figure-4'>
        <!-- <figure title='Implicit Grant Flow' anchor='Figure-4'> -->
          <artwork><![CDATA[
  +----------+
  | Resource |
  |  Owner   |
  |          |
  +----------+
       ^
       |
      (B)
  +----|-----+          Client Identifier     +---------------+
  |         -+----(A)-- & Redirection URI --->|               |
  |  User-   |                                | Authorization |
  |  Agent  -|----(B)-- User authenticates -->|     Server    |
  |          |                                |               |
  |          |<---(C)--- Redirection URI ----<|               |
  |          |          with Access Token     +---------------+
  |          |            in Fragment
  |          |                                +---------------+
  |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
  |          |          without Fragment      |     Client    |
  |          |                                |    Resource   |
  |     (F)  |<---(E)------- Script ---------<|               |
  |          |                                +---------------+
  +-|--------+
    |    |
   (A)  (G) Access Token
    |    |
    ^    v
  +---------+
  |         |
  |  Client |
  |         |
  +---------+
]]></artwork>
          <postamble>
            注記: ユーザーエージェントを通過するため, Step (A) と (B) を示す線は2つに分かれる.
          </postamble>
          <!--
          <postamble>
            Note: The lines illustrating steps (A) and (B) are broken into two parts as they pass
            through the user-agent.
          </postamble>
          -->
        </figure>
        <t>
          <xref target='Figure-4' /> のフローは以下の通りである.
        </t>
        <!--
        <t>
          The flow illustrated in <xref target='Figure-4' /> includes the following steps:
        </t>
        -->
        <t>
          <list style='format (%C)'>
            <t>
              クライアントがリソースオーナーのユーザーエージェントを認可エンドポイントに送ることで, フローが開始する.
              このときクライアントは, クライアント識別子, リクエストスコープ, ローカルステート, および認可サーバーがアクセス許可取得後にユーザーエージェントを戻すリダイレクトURIをリクエストに含める.
            </t>
            <!--
            <t>
              The client initiates the flow by directing the resource owner's user-agent to the
              authorization endpoint. The client includes its client identifier, requested
              scope, local state, and a redirection URI to which the authorization server will send
              the user-agent back once access is granted (or denied).
            </t>
            -->
            <t>
              認可サーバーは (ユーザーエージェントを通して) リソースオーナーを認証し, リソースオーナーにアクセス要求の許可/拒否をたずねる.
            </t>
            <!--
            <t>
              The authorization server authenticates the resource owner (via the user-agent) and
              establishes whether the resource owner grants or denies the client's access request.
            </t>
            -->
            <t>
              リソースオーナーがアクセスを許可した場合, 認可サーバーは予め与えられていたリダイレクトURIを用いて, ユーザーエージェントをリダイレクトさせてクライアントに戻す.
              リダイレクトURIには, アクセストークンが含まれる.
            </t>
            <!--
            <t>
              Assuming the resource owner grants access, the authorization server redirects the
              user-agent back to the client using the redirection URI provided earlier. The
              redirection URI includes the access token in the URI fragment.
            </t>
            -->
            <t>
              ユーザーエージェントは, リダイレクトの指示に従い, Web上にホストされたクライアントリソースにリクエストを送信する (このときフラグメントは送信されない.<xref target='RFC2616' />を参照).
              ユーザーエージェントはフラグメントの情報をローカルに保持する.
            </t>
            <!--
            <t>
              The user-agent follows the redirection instructions by making a request to the
              web-hosted client resource (which does not include the fragment per
              <xref target='RFC2616' />). The user-agent retains the fragment information locally.
            </t>
            -->
            <t>
              Webでホストされたクライアントリソースにアクセスすると, Webページ (通常, 埋め込みのスクリプトが含まれるHTMLドキュメント) が返される.
              そのWebページでは, ユーザーエージェントによって保持されているフラグメントを含む完全なリダイレクトURLにアクセスし, フラグメントに含まれているアクセストークン (とその他のパラメーター) を取り出すことができる.
            </t>
            <!--
            <t>
              The web-hosted client resource returns a web page (typically an HTML document with an
              embedded script) capable of accessing the full redirection URI including the fragment
              retained by the user-agent, and extracting the access token (and other parameters)
              contained in the fragment.
            </t>
            -->
            <t>
              ユーザーエージェントは上記Webページに含まれるスクリプトをローカルに実行し, アクセストークンを取り出す.</t>
            <t>ユーザーエージェントはアクセストークンをクライアントに渡す.
            </t>
            <!--
            <t>
              The user-agent executes the script provided by the web-hosted client resource
              locally, which extracts the access token.</t>
            <t>The user-agent passes the access token to the client.
            </t>
            -->
          </list>
        </t>

        <t>
          インプリシットグラントを利用する背景については<xref target="ImplicitIntro" format="counter"/>と
<xref target="NativeApps" format="counter"/>セクションを参照のこと.
          インプリシットグラントを利用するときの重要なセキュリティ面での考慮点については<xref target="AccessTokenSecurity" format="counter"/>
と<xref target="ImplicitImpersonation" format="counter"/>セクションを参照のこと.
        </t>
        <!--
        <t>
          See Sections <xref target="ImplicitIntro" format="counter"/> and
<xref target="NativeApps" format="counter"/>
          for background on using the implicit grant.
          See Sections <xref target="AccessTokenSecurity" format="counter"/>
and <xref target="ImplicitImpersonation" format="counter"/>
          for important security considerations when using the implicit grant.
        </t>
        -->

        <section title='認可リクエスト' anchor='implicit-authz-req'>
        <!-- <section title='Authorization Request' anchor='implicit-authz-req'> -->
          <t>
            クライアントは, <xref target="urlencoded"/> に従い <spanx style='verb'>application/x-www-form-urlencoded</spanx> フォーマットを用いて認可エンドポイントURIへのクエリーとして, 次のパラメーターを付与する.
          </t>
          <!--
          <t>
            The client constructs the request URI by adding the following parameters to the
            query component of the authorization endpoint URI using the
            <spanx style='verb'>application/x-www-form-urlencoded</spanx> format,
            per <xref target="urlencoded"/>:
          </t>
          -->
          <t>
            <list style='hanging' hangIndent='6'>
              <t hangText='response_type'>
                <vspace />
                必須 (REQUIRED).
                値は必ず <spanx style='verb'>token</spanx> にしなければならない (MUST).
              </t>
              <t hangText='client_id'>
                <vspace />
                必須 (REQUIRED).
                詳細は <xref target='client-identifier' /> を参照のこと.
              </t>
              <t hangText='redirect_uri'>
                <vspace />
                任意 (OPTIONAL).
                詳細は <xref target='redirect-uri' /> を参照のこと.
              </t>
              <t hangText='scope'>
                <vspace />
                任意 (OPTIONAL).
                詳細は <xref target='scope' /> を参照のこと.
              </t>
              <t hangText='state'>
                <vspace />
                推奨 (RECOMMENDED).
                リクエストとコールバックの間で状態を維持するために使用するランダムな値.
                認可サーバーはリダイレクトによってクライアントに処理を戻す際にこの値を付与する.
                このパラメーターは <xref target='CSRF' /> に記載されているクロスサイトリクエストフォージェリを防ぐために用いられるべきである (SHOULD).
              </t>
              <!--
              <t hangText='response_type'>
                <vspace />
                REQUIRED. Value MUST be set to <spanx style='verb'>token</spanx>.
              </t>
              <t hangText='client_id'>
                <vspace />
                REQUIRED. The client identifier as described in
                <xref target='client-identifier' />.
              </t>
              <t hangText='redirect_uri'>
                <vspace />
                OPTIONAL. As described in <xref target='redirect-uri' />.
              </t>
              <t hangText='scope'>
                <vspace />
                OPTIONAL. The scope of the access request as described by <xref target='scope' />.
              </t>
              <t hangText='state'>
                <vspace />
                RECOMMENDED. An opaque value used by the client to maintain state between the request
                and callback. The authorization server includes this value when redirecting the
                user-agent back to the client. The parameter SHOULD be used for preventing
                cross-site request forgery as described in <xref target='CSRF' />.
              </t>
              -->
            </list>
          </t>
          <t>
            クライアントは, HTTPリダイレクトまたはユーザーエージェントを介したその他の利用可能な手段によって, リソースオーナーを構築されたURIに送る.
          </t>
          <!--
          <t>
            The client directs the resource owner to the constructed URI using an HTTP redirection
            response, or by other means available to it via the user-agent.
          </t>
          -->
          <figure>
            <preamble>
              例えば, クライアントはユーザーエージェントに次のHTTPリクエストをTLSを用いて実行させる (改行は掲載上の都合による).
            </preamble>
            <!--
            <preamble>
              For example, the client directs the user-agent to make the following HTTP request
              using TLS (with extra line breaks for display purposes only):
            </preamble>
            -->
            <artwork><![CDATA[
  GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
      &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
  Host: server.example.com
]]></artwork>
          </figure>
          <t>
            認可サーバーは, 必要なリクエストパラメーターがすべて揃っていて, かつ正当であることを検証する.
            認可サーバーは, アクセストークンを返すリダイレクトURIが <xref target='redirect-uri' /> に述べるように事前登録されたリダイレクトURIと一致することを検証しなければならない (MUST).
          </t>
          <!--
          <t>
            The authorization server validates the request to ensure that all required parameters are
            present and valid. The authorization server MUST verify that the redirection URI to which
            it will redirect the access token matches a redirection URI registered by the client as
            described in <xref target='redirect-uri' />.
          </t>
          -->
          <t>
            リクエストが正当なものであれば, 認可サーバーはリソースオーナーを認証し, (リソースオーナーに確認することによって, または他の手段によって承認を確立することによって) 認可の判定を得る.
          </t>
          <!--
          <t>
            If the request is valid, the authorization server authenticates the resource owner and
            obtains an authorization decision (by asking the resource owner or by establishing
            approval via other means).
          </t>
          -->
          <t>
            判定が成立すると, 認可サーバーはHTTPリダイレクトレスポンスまたはユーザーエージェントを介したその他の利用可能な手段を用いて, 与えられたリダイレクトURIにユーザーエージェントを送る.
          </t>
          <!--
          <t>
            When a decision is established, the authorization server directs the user-agent to the
            provided client redirection URI using an HTTP redirection response, or by other means
            available to it via the user&nbhy;agent.
          </t>
          -->
        </section>

        <section title='アクセストークンレスポンス' anchor="implicit-authz-resp">
        <!-- <section title='Access Token Response' anchor="implicit-authz-resp"> -->
          <t>
            リソースオーナーがアクセスリクエストを許可した場合, 認可サーバーはアクセストークンを発行し, <xref target="urlencoded"/> に従い <spanx style='verb'>application/x-www-form-urlencoded</spanx> フォーマットを用いてリダイレクトURIのフラグメントコンポーネントに次のパラメーターを付与してクライアントに送る.
          </t>
          <!--
          <t>
            If the resource owner 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,
            per <xref target="urlencoded"/>:
          </t>
          -->
          <t>
            <list style='hanging' hangIndent='6'>
              <t hangText='access_token'>
                <vspace />
                必須 (REQUIRED).
                認可サーバーによって発行されたアクセストークン.
              </t>
              <t hangText='token_type'>
                <vspace />
                必須 (REQUIRED).
                詳細は <xref target='token-types' /> を参照のこと.
                大文字・小文字は区別しない.
              </t>
              <t hangText='expires_in'>
                <vspace />
                推奨 (RECOMMENDED).
                アクセストークンの有効期間を秒で表したもの.
                例えばこの値が <spanx style='verb'>3600</spanx> であれば, そのアクセストークンは発行から1時間後に期限切れとなる.
                省略された場合, 認可サーバは他の手段を用いて終了時間を提供するか初期値を明記すべきである (SHOULD).
              </t>
              <t hangText='scope'>
                <vspace />
                クライアントによって要求された scope と同一の場合は任意 (OPTIONAL). その他の場合は必須 (REQUIRED).
                詳細は <xref target='scope' /> を参照のこと.
              </t>
              <t hangText='state'>
                <vspace />
                クライアントの認可リクエストに <spanx style='verb'>state</spanx> が含まれていた場合は必須 (REQUIRED).
                クライアントから受け取った値をそのまま返す.
              </t>
              <!--
              <t hangText='access_token'>
                <vspace />
                REQUIRED. The access token issued by the authorization server.
              </t>
              <t hangText='token_type'>
                <vspace />
                REQUIRED. The type of the token issued as described in
                <xref target='token-types' />. Value is case insensitive.
              </t>
              <t hangText='expires_in'>
                <vspace />
                RECOMMENDED. The lifetime in seconds of the access token. For example, the value
                <spanx style='verb'>3600</spanx> denotes that the access token will expire in one
                hour from the time the response was generated. If omitted, the authorization server
                SHOULD provide the expiration time via other means or document the default value.
              </t>
              <t hangText='scope'>
                <vspace />
                OPTIONAL, if identical to the scope requested by the client; otherwise, REQUIRED. The
                scope of the access token as described by <xref target='scope' />.
              </t>
              <t hangText='state'>
                <vspace />
                REQUIRED if the <spanx style='verb'>state</spanx> parameter was present in the
                client authorization request. The exact value received from the client.
              </t>
              -->
            </list>
          </t>
          <t>
            認可サーバーはリフレッシュトークンを発行してはならない (MUST NOT).
          </t>
          <!--
          <t>
            The authorization server MUST NOT issue a refresh token.
          </t>
          -->
          <figure>
            <preamble>
              例えば, 認可サーバーは次のようなHTTPレスポンスをユーザーエージェントに返し, ユーザーエージェントをリダイレクトさせる (改行は掲載上の都合による).
            </preamble>
            <!--
            <preamble>
              For example, the authorization server redirects the user-agent by sending the
              following HTTP response (with extra line breaks for display purposes only):
            </preamble>
            -->
            <artwork><![CDATA[
  HTTP/1.1 302 Found
  Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
            &state=xyz&token_type=example&expires_in=3600
]]></artwork>
            <postamble>
              開発者は, いくつかのユーザーエージェントが, HTTP <spanx style='verb'>Location</spanx> レスポンスヘッダーフィールドをサポートしないことに注意するべきである.
              このようなクライアントは3xxリダイレクトレスポンス以外でクライアントを向け直すための方法が必要になるだろう.
              例えば, リダイレクトURI先にリンクするような"続行"ボタンを含むHTMLページを返却するなどである.
            </postamble>
            <!--
            <postamble>
              Developers should note that some user-agents do not support the inclusion of a
              fragment component in the HTTP <spanx style='verb'>Location</spanx> response header
              field. Such clients will require using other methods for redirecting the client than
              a 3xx redirection response -- for example, returning an HTML page that includes a
              'continue' button with an action linked to the redirection URI.
            </postamble>
            -->
          </figure>
          <t>
            クライアントは認識できないレスポンスパラメーターを無視しなくてはならない (MUST).
            アクセストークンの文字列長は本仕様では定義しない.
            クライアントは値のサイズについてなんらかの仮定をすべきではない.
            認可サーバーは自身が発行するあらゆる値のサイズについてドキュメントに明記すべきである (SHOULD).
          </t>
          <!--
          <t>
            The client MUST ignore unrecognized response parameters. The access token string size
            is left undefined by this specification. The client should avoid making assumptions
            about value sizes. The authorization server SHOULD document the size of any value it
            issues.
          </t>
          -->

          <section title='エラーレスポンス' anchor='implicit-authz-error'>
          <!-- <section title='Error Response' anchor='implicit-authz-error'> -->
            <t>
              リクエストが, リダイレクトURIの欠落 / 不正 / ミスマッチによって失敗した場合, もしくはクライアント識別子が不正な場合は, 認可サーバーはリソースオーナーにエラーを通知すべきである (SHOULD).
              不正なリダイレクトURIに対してユーザーエージェントを自動的にリダイレクトさせてはならない (MUST NOT).
            </t>
            <!--
            <t>
              If the request fails due to a missing, invalid, or mismatching redirection URI, or if
              the client identifier is missing or invalid, the authorization server SHOULD inform
              the resource owner of the error and MUST NOT automatically redirect the user-agent
              to the invalid redirection URI.
            </t>
            -->
            <t>
              リソースオーナーがアクセス要求を拒否した場合, もしくはリダイレクトURIの欠落 / 不正以外でリクエストが失敗した場合は, 認可サーバーは <xref target="urlencoded"/> に従い <spanx style='verb'>application/x-www-form-urlencoded</spanx> フォーマットを用いてリダイレクトURIのフラグメントコンポーネントに次のようなパラメーターを付与してクライアントに返却する.
            </t>
            <!--
            <t>
              If the resource owner denies the access request or if the request fails for reasons
              other than a missing or invalid redirection URI, the authorization server informs 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,
              per <xref target="urlencoded"/>:
            </t>
            -->
            <t>
              <list style='hanging' hangIndent='6'>
                <t hangText='error'>
                  <vspace />
                  必須 (REQUIRED).
                  次の中の1つのアスキー <xref target="USASCII" /> エラーコード:
                  <!-- REQUIRED. A single ASCII <xref target="USASCII" /> error code from the following: -->

                  <list style='hanging' hangIndent='6'>
                    <t hangText='invalid_request'>
                      <vspace />
                      リクエストに必要なパラメーターが含まれていない.
                      不正なパラメーターが付与されていた場合や, パラメータが複数回指定されていた場合, その他不正な形式であった場合もこれに含まれる.
                    </t>
                    <!--
                    <t hangText='invalid_request'>
                      <vspace />
                      The request is missing a required parameter, includes an invalid
                      parameter value, includes a parameter more than once, or is otherwise malformed.
                    </t>
                    -->
                    <t hangText='unauthorized_client'>
                      <vspace />
                      クライアントは現在の方法でアクセストークンを取得することを認可されていない.
                    </t>
                    <!--
                    <t hangText='unauthorized_client'>
                      <vspace />
                      The client is not authorized to request an access token using this method.
                    </t>
                    -->
                    <t hangText='access_denied'>
                      <vspace />
                      リソースオーナーまたは認可サーバーがリクエストを拒否した.
                    </t>
                    <!--
                    <t hangText='access_denied'>
                      <vspace />
                      The resource owner or authorization server denied the request.
                    </t>
                    -->
                    <t hangText='unsupported_response_type'>
                      <vspace />
                      認可サーバーは現在の方法によるアクセストークン取得をサポートしていない.
                    </t>
                    <!--
                    <t hangText='unsupported_response_type'>
                      <vspace />
                      The authorization server does not support obtaining an access token using
                      this method.
                    </t>
                    -->
                    <t hangText='invalid_scope'>
                      <vspace />
                      リクエストスコープが不正, 未知, もしくはその他の不当な形式である.
                    </t>
                    <!--
                    <t hangText='invalid_scope'>
                      <vspace />
                      The requested scope is invalid, unknown, or malformed.
                    </t>
                    -->
                    <t hangText='server_error'>
                      <vspace />
                      認可サーバーがリクエストの処理ができないような予期しない状況に遭遇した.
                      (このエラーコードはHTTPステータスコード500 Internal Server ErrorがHTTPリダイレクトではクライアントへ返されないため必要である)
                    </t>
                    <!--
                    <t hangText='server_error'>
                      <vspace />
                      The authorization server encountered an unexpected condition that prevented
                      it from fulfilling the request.
                      (This error code is needed because a 500 Internal Server Error
                      HTTP status code cannot be returned to the client
                      via an HTTP redirect.)
                    </t>
                    -->
                    <t hangText='temporarily_unavailable'>
                      <vspace />
                      認可サーバーが一時的な過負荷やメンテナンスによってリクエストを扱うことが出来ない.
                      (このエラーコードはHTTPステータスコード503 Service UnavailabeがHTTPリダイレクトではクライアントへ返されないため必要である)
                    </t>
                    <!--
                    <t hangText='temporarily_unavailable'>
                      <vspace />
                      The authorization server is currently unable to handle the request due to a
                      temporary overloading or maintenance of the server.
                      (This error code is needed because a 503 Service Unavailable
                      HTTP status code cannot be returned to the client
                      via an HTTP redirect.)
                    </t>
                    -->
                  </list>

                  <spanx style='verb'>error</spanx> パラメータの値は %x20-21 / %x23-5B / %x5D-7E 以外の文字を含んではならない (MUST NOT).
                  <!-- Values for the <spanx style='verb'>error</spanx> parameter MUST NOT include
                  characters outside the set %x20-21 / %x23-5B / %x5D-7E. -->
                </t>
                <t hangText='error_description'>
                  <vspace />
                  任意 (OPTIONAL).
                  クライアント開発者が発生したエラーを理解する際の手助けとなる, ASCII <xref target="USASCII" /> の可読性のある追加情報.
                  <vspace/>
                  <spanx style='verb'>error_description</spanx> パラメータの値は %x20-21 / %x23-5B / %x5D-7E 以外の文字を含んではならない (MUST NOT).
                </t>
                <!--
                <t hangText='error_description'>
                  <vspace />
                  OPTIONAL. Human-readable ASCII <xref target="USASCII" /> text providing additional information,
                  used to assist the client developer in understanding the error that occurred.
                  <vspace/>
                  Values for the <spanx style='verb'>error_description</spanx> parameter MUST NOT include
                  characters outside the set %x20-21 / %x23-5B / %x5D-7E.
                </t>
                -->
                <t hangText='error_uri'>
                  <vspace />
                  任意 (OPTIONAL).
                  クライアント開発者が発生したエラーに関する追加の情報を得ることができるWebページのURI.
                  <vspace/>
                  <spanx style='verb'>error_uri</spanx> パラメータの値は%x21 / %x23-5B / %x5D-7E 以外の文字を含んではならない (MUST NOT).
                </t>
                <!--
                <t hangText='error_uri'>
                  <vspace />
                  OPTIONAL. A URI identifying a human-readable web page with information about the
                  error, used to provide the client developer with additional information about the
                  error.
                  <vspace/>
                  Values for the <spanx style='verb'>error_uri</spanx> parameter
                  MUST conform to the URI&nbhy;reference syntax and thus MUST NOT include
                  characters outside the set %x21 / %x23-5B / %x5D-7E.
                </t>
                -->
                <t hangText='state'>
                  <vspace />
                  もし <spanx style='verb'>state</spanx> パラメーターがクライアントからの認可リクエストに含めれている場合は必須 (REQUIRED).
                  クライアントから受け取った値をそのまま返す.
                </t>
                <!--
                <t hangText='state'>
                  <vspace />
                  REQUIRED if a <spanx style='verb'>state</spanx> parameter was present in the
                  client authorization request. The exact value received from the client.
                </t>
                -->
              </list>
            </t>
            <figure>
              <preamble>
                例えば, 認可サーバーは次のようなHTTPレスポンスをユーザーエージェントに返却する.
              </preamble>
              <!--
              <preamble>
                For example, the authorization server redirects the user-agent by sending the
                following HTTP response:
              </preamble>
              -->
              <artwork><![CDATA[
  HTTP/1.1 302 Found
  Location: https://client.example.com/cb#error=access_denied&state=xyz
]]></artwork>
            </figure>
          </section>

        </section>

      </section>

      <section title='リソースオーナーパスワードクレデンシャルグラント' anchor='grant-password'>
      <!-- <section title='Resource Owner Password Credentials Grant' anchor='grant-password'> -->
        <t>
          リソースオーナーパスワードクレデンシャルグラントタイプは, リソースオーナーがクライアントと信頼関係にある場合, 例えばリソースオーナーの所有するデバイスOSや特別許可されたアプリケーションなどに適している.
          認可サーバーはこのグラントタイプを有効にする際は特に注意するべきである.
          また他のフローが利用できない場合にのみ許可するべきである.
        </t>
        <!--
        <t>
          The resource owner password credentials grant type is suitable in cases where the
          resource owner has a trust relationship with the client, such as the device operating
          system or a highly privileged application. The authorization server should take special
          care when enabling this grant type and only allow it when other flows are not viable.
        </t>
        -->
        <t>
          このグラントタイプは, リソースオーナーのクレデンシャル (通常は対話型入力フォームにて取得するユーザー名とパスワード) を取得できるクライアントに適している.
          また, 保存済みのクレデンシャルをアクセストークンへ変換できるため, Basic認証やDigest認証のような直接的な認証スキームを利用している既存のクライアントをOAuthへ移行する際にも利用できる.
        </t>
        <!--
        <t>
          This grant type is suitable for clients capable of obtaining the resource owner's
          credentials (username and password, typically using an interactive form). It is also used
          to migrate existing clients using direct authentication schemes such as HTTP Basic or
          Digest authentication to OAuth by converting the stored credentials to an access token.
        </t>
        -->
        <figure title='リソースオーナーパスワードクレデンシャルフロー' anchor='Figure-5'>
        <!-- <figure title='Resource Owner Password Credentials Flow' anchor='Figure-5'> -->
          <artwork><![CDATA[
  +----------+
  | Resource |
  |  Owner   |
  |          |
  +----------+
       v
       |    Resource Owner
      (A) Password Credentials
       |
       v
  +---------+                                  +---------------+
  |         |>--(B)---- Resource Owner ------->|               |
  |         |         Password Credentials     | Authorization |
  | Client  |                                  |     Server    |
  |         |<--(C)---- Access Token ---------<|               |
  |         |    (w/ Optional Refresh Token)   |               |
  +---------+                                  +---------------+
]]></artwork>
        </figure>
        <t>
          <xref target='Figure-5' /> のフローは以下の通りである.
        </t>
        <!--
        <t>
          The flow illustrated in <xref target='Figure-5' /> includes the following steps:
        </t>
        -->
        <t>
          <list style='format (%C)'>
            <t>
              リソースオーナーはクライアントにユーザー名とパスワードを提供する.
            </t>
            <!--
            <t>
              The resource owner provides the client with its username and password.
            </t>
            -->
            <t>
              クライアントは認可サーバーのトークンエンドポイントにリソースオーナーから取得したクレデンシャルを含めることでアクセストークンを要求する.
              リクエストを生成する際に, クライアントは認可サーバーによって認証される.
            </t>
            <!--
            <t>
              The client requests an access token from the authorization server's token endpoint by
              including the credentials received from the resource owner. When making the request,
              the client authenticates with the authorization server.
            </t>
            -->
            <t>
              認可サーバーはクライアントを認証し, リソースオーナーのクレデンシャルを検証する.
              もし有効であればアクセストークンを発行する.
            </t>
            <!--
            <t>
              The authorization server authenticates the client and validates the resource owner
              credentials, and if valid, issues an access token.
            </t>
            -->
          </list>
        </t>

        <section title='認可リクエストとレスポンス'>
        <!-- <section title='Authorization Request and Response'> -->
          <t>
            クライアントがリソースオーナーのクレデンシャルを取得する方法は, 本仕様の範囲外である.
            クライアントはアクセストークン取得直後にクレデンシャルを破棄しなければならない (MUST).
          </t>
          <!--
          <t>
            The method through which the client obtains the resource owner credentials is beyond
            the scope of this specification. The client MUST discard the credentials once an access
            token has been obtained.
          </t>
          -->
        </section>

        <section title='アクセストークンリクエスト' anchor="password-tok-req">
        <!-- <section title='Access Token Request' anchor="password-tok-req"> -->
          <t>
            クライアントは, 下記のパラメーターを <xref target="urlencoded"/> に従い <spanx style='verb'>application/x-www-form-urlencoded</spanx> フォーマットでHTTPリクエストボディーに含め, UTF-8でエンコードして, リクエストを構築する.
          </t>
          <!--
          <t>
            The client makes a request to the token endpoint by adding the following parameters
            using the <spanx style='verb'>application/x-www-form-urlencoded</spanx> format
            per <xref target="urlencoded"/> with a character encoding of UTF-8
            in the HTTP request entity-body:
          </t>
          -->
          <t>
            <list style='hanging' hangIndent='6'>
              <t hangText='grant_type'>
                <vspace />
                必須 (REQUIRED).
                値には <spanx style='verb'>password</spanx> を指定しなければならない (MUST).
                <!-- REQUIRED. Value MUST be set to <spanx style='verb'>password</spanx>. -->
              </t>
              <t hangText='username'>
                <vspace />
                必須 (REQUIRED).
                リソースオーナーのユーザーネーム.
                <!-- REQUIRED. The resource owner username. -->
              </t>
              <t hangText='password'>
                <vspace />
                必須 (REQUIRED).
                リソースオーナーのパスワード.
                <!-- REQUIRED. The resource owner password. -->
              </t>
              <t hangText='scope'>
                <vspace />
                任意 (OPTIONAL).
                詳細は <xref target='scope' /> を参照のこと.
                <!-- OPTIONAL. The scope of the access request as described by <xref target='scope' />. -->
              </t>
            </list>
          </t>
          <t>
            クライアントタイプがコンフィデンシャルである場合, あるいはクライアントクレデンシャルが発行された (もしくはその他の認証が要求された) クライアントは, <xref target='token-endpoint-auth' /> に示すとおり認可サーバーにより認証されなければならない (MUST).
          </t>
          <!--
          <t>
            If the client type is confidential or the client was issued client credentials (or
            assigned other authentication requirements), the client MUST authenticate with the
            authorization server as described in <xref target='token-endpoint-auth' />.
          </t>
          -->
          <figure>
            <preamble>
              例えば, クライアントは以下のHTTPリクエストをセキュリティ保護されたトランスポート層から送信する (改行は掲載上の都合による).
            </preamble>
            <!--
            <preamble>
              For example, the client makes the following HTTP request using transport-layer
              security (with extra line breaks for display purposes only):
            </preamble>
            -->
            <artwork><![CDATA[
  POST /token HTTP/1.1
  Host: server.example.com
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
  Content-Type: application/x-www-form-urlencoded

  grant_type=password&username=johndoe&password=A3ddj3w
]]></artwork>
          </figure>
          <t>
            認可サーバーは次のことを実施しなければならない (MUST):
          </t>
          <!--
          <t>
            The authorization server MUST:
          </t>
          -->
          <t>
            <list style='symbols'>
              <t>
                コンフィデンシャルクライアント, あるいはクライアントクレデンシャルが発行された (もしくはその他の認証が要求された) クライアントにクライアント認証を要求し,
              </t>
              <!--
              <t>
                require client authentication for confidential clients or for any client that was
                issued client credentials (or with other authentication requirements),
              </t>
              -->
              <t>
                クライアントの認証情報が含まれていた場合はクライアントを認証し,
              </t>
              <!--
              <t>
                authenticate the client if client authentication is included, and
              </t>
              -->
              <t>
                既存のパスワード確認のアルゴリズムを用いてリソースオーナーパスワードクレデンシャルの妥当性を確認する
              </t>
              <!--
              <t>
                validate the resource owner password credentials using its existing password
                validation algorithm.
              </t>
              -->
            </list>
          </t>
          <t>
            このアクセストークンリクエストにはリソースオーナーのパスワードが含まれるため, 認可サーバーはブルートフォース攻撃からこのエンドポイントを保護しなければならない (MUST). (例えば, 閾値による制限やアラートの生成を行う)
          </t>
          <!--
          <t>
            Since this access token request utilizes the resource owner's password, the
            authorization server MUST protect the endpoint against brute force attacks (e.g., using
            rate-limitation or generating alerts).
          </t>
          -->
        </section>

        <section title='アクセストークンレスポンス'>
        <!-- <section title='Access Token Response'> -->
          <t>
            アクセストークンリクエストが正当かつ認可された場合, 認可サーバーは <xref target='token-response' /> に示すとおりアクセストークンと任意でリフレッシュトークンを発行する.
            クライアント認証に失敗, もしくはリクエストが不正であった場合, 認可サーバーは <xref target='token-errors' /> に示すとおりエラーレスポンスを返却する.
          </t>
          <!--
          <t>
            If the access token request is valid and authorized, the authorization server issues an
            access token and optional refresh token as described in <xref target='token-response' />.
            If the request failed client authentication or is invalid, the authorization server returns
            an error response as described in <xref target='token-errors' />.
          </t>
          -->
          <figure>
            <preamble>
              成功レスポンス例を以下に示す.
            </preamble>
            <!--
            <preamble>
              An example successful response:
            </preamble>
            -->
            <artwork><![CDATA[
  HTTP/1.1 200 OK
  Content-Type: application/json;charset=UTF-8
  Cache-Control: no-store
  Pragma: no-cache

  {
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"example",
    "expires_in":3600,
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
    "example_parameter":"example_value"
  }
]]></artwork>
          </figure>
        </section>

      </section>

      <section title='クライアントクレデンシャルグラント' anchor='grant-client'>
      <!-- <section title='Client Credentials Grant' anchor='grant-client'> -->
        <t>
          クライアント自身のコントロール下にある保護リソースまたは認可サーバーとの間で調整済みの保護リソースにアクセスする場合, クライアントはクライアントクレデンシャル (あるいはサポートされているその他の認証方式) のみでアクセストークンをリクエストすることができる.
        </t>
        <!--
        <t>
          The client can request an access token using only its client credentials (or other
          supported means of authentication) when the client is requesting access to the
          protected resources under its control, or those of another resource owner that have been
          previously arranged with the authorization server (the method of which is beyond the
          scope of this specification).
        </t>
        -->
        <t>
          コンフィデンシャルクライアントのみが, クライアントクレデンシャルグラントタイプを利用できる (MUST).
        </t>
        <!--
        <t>
          The client credentials grant type MUST only be used by confidential clients.
        </t>
        -->
        <figure title='クライアントクレデンシャルフロー' anchor='Figure-6'>
        <!-- <figure title='Client Credentials Flow' anchor='Figure-6'> -->
          <artwork><![CDATA[
  +---------+                                  +---------------+
  |         |                                  |               |
  |         |>--(A)- Client Authentication --->| Authorization |
  | Client  |                                  |     Server    |
  |         |<--(B)---- Access Token ---------<|               |
  |         |                                  |               |
  +---------+                                  +---------------+
]]></artwork>
        </figure>
        <t>
          <xref target='Figure-6' /> のフローは以下の通りである.
        </t>
        <!--
        <t>
          The flow illustrated in <xref target='Figure-6' /> includes the following steps:
        </t>
        -->
        <t>
          <list style='format (%C)'>
            <t>
              クライアントは自身の認証情報を含めてトークンエンドポイントにアクセストークンリクエストを送る.
            </t>
            <!--
            <t>
              The client authenticates with the authorization server and requests an access token
              from the token endpoint.
            </t>
            -->
            <t>
              認可サーバーはクライアントを認証し, 認証に成功すればアクセストークンを発行する.
            </t>
            <!--
            <t>
              The authorization server authenticates the client, and if valid, issues an access
              token.
            </t>
            -->
          </list>
        </t>

        <section title='認可リクエストとレスポンス'>
        <!-- <section title='Authorization Request and Response'> -->
          <t>
            クライアント認証が認可グラントとして利用されるため, 追加の認可リクエストは必要ない.
          </t>
          <!--
          <t>
            Since the client authentication is used as the authorization grant, no additional
            authorization request is needed.
          </t>
          -->
        </section>

        <section title='アクセストークンリクエスト' anchor="client-req">
        <!-- <section title='Access Token Request' anchor="client-req"> -->
          <t>
            クライアントは, HTTPリクエストボディーに <xref target="urlencoded"/> に従い <spanx style='verb'>application/x-www-form-urlencoded</spanx> フォーマットで下記のパラメーターを追加し, UTF-8でエンコードして, トークンエンドポイントにリクエストを送る.
          </t>
          <!--
          <t>
            The client makes a request to the token endpoint by adding the following parameters
            using the <spanx style='verb'>application/x-www-form-urlencoded</spanx> format
            per <xref target="urlencoded"/> with a character encoding of UTF-8
            in the HTTP request entity-body:
          </t>
          -->
          <t>
            <list style='hanging' hangIndent='6'>
              <t hangText='grant_type'>
                <vspace />
                必須 (REQUIRED).
                <spanx style='verb'>client_credentials</spanx> を指定しなければならない (MUST).
                <!-- REQUIRED. Value MUST be set to <spanx style='verb'>client_credentials</spanx>. -->
              </t>
              <t hangText='scope'>
                <vspace />
                任意 (OPTIONAL).
                詳細は <xref target='scope' /> を参照のこと.
                <!-- OPTIONAL. The scope of the access request as described by <xref target='scope' />. -->
              </t>
            </list>
          </t>
          <t>
            クライアントは認可サーバーに対して認証を行わなければならない (MUST).
            詳細は <xref target='token-endpoint-auth' /> を参照のこと.
          </t>
          <!--
          <t>
            The client MUST authenticate with the authorization server as described in
            <xref target='token-endpoint-auth' />.
          </t>
          -->
          <figure>
            <preamble>
              例えば, クライアントは以下のHTTPリクエストをセキュリティ保護されたトランスポート層から送信する (改行は掲載上の都合による).
            </preamble>
            <!--
            <preamble>
              For example, the client makes the following HTTP request using transport-layer
              security (with extra line breaks for display purposes only):
            </preamble>
            -->
          <artwork><![CDATA[
  POST /token HTTP/1.1
  Host: server.example.com
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
  Content-Type: application/x-www-form-urlencoded

  grant_type=client_credentials
]]></artwork>
          </figure>
          <t>
            認可サーバーはクライアントを認証しなければならない (MUST).
          </t>
          <!--
          <t>
            The authorization server MUST authenticate the client.
          </t>
          -->
        </section>

        <section title='アクセストークンレスポンス'>
        <!-- <section title='Access Token Response'> -->
          <t>
            アクセストークンリクエストが正当かつ認可された場合, 認可サーバーは <xref target='token-response' /> に示すとおりアクセストークンを発行する.
            リフレッシュトークンは含むべきでない (SHOULD NOT).
            クライアント認証に失敗, もしくはリクエストが不正であった場合, 認可サーバーは <xref target='token-errors' /> に示すとおりエラーレスポンスを返す.
          </t>
          <!--
          <t>
            If the access token request is valid and authorized, the authorization server issues an
            access token as described in <xref target='token-response' />. A refresh token SHOULD
            NOT be included. If the request failed client authentication or is invalid, the
            authorization server returns an error response as described in
            <xref target='token-errors' />.
          </t>
          -->
          <figure>
            <preamble>
              成功レスポンス例を以下に示す.
            </preamble>
            <!--
            <preamble>
              An example successful response:
            </preamble>
            -->
            <artwork><![CDATA[
  HTTP/1.1 200 OK
  Content-Type: application/json;charset=UTF-8
  Cache-Control: no-store
  Pragma: no-cache

  {
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"example",
    "expires_in":3600,
    "example_parameter":"example_value"
  }
]]></artwork>
          </figure>
        </section>

      </section>

      <section title='拡張グラント' anchor="ext-grant">
      <!-- <section title='Extension Grants' anchor="ext-grant"> -->
        <t>
          クライアントはトークンエンドポイントの <spanx style='verb'>grant_type</spanx> パラメーターの値に (認可サーバーによって定義された) 絶対URIを指定し, 追加の必須パラメーターを付与することによって, 拡張グラントタイプを利用できる.
        </t>
        <!--
        <t>
          The client uses an extension grant type by specifying the grant type using an
          absolute URI (defined by the authorization server) as the value of the
          <spanx style='verb'>grant_type</spanx> parameter of the token endpoint, and by
          adding any additional parameters necessary.
        </t>
        -->
        <figure>
          <preamble>
            例えば, <xref target='OAuth-SAML2' /> で定義されている Security Assertion Markup Language (SAML) 2.0アサーショングラントタイプを利用してアクセストークンを要求するために, クライアントはTLSを用いて次のようなHTTPリクエストを行う. (改行は掲載上の都合による)
          </preamble>
          <!--
          <preamble>
            For example, to request an access token using a Security Assertion
Markup Language (SAML) 2.0 assertion grant type as
            defined by <xref target='OAuth-SAML2' />, the client could make the
            following HTTP request using TLS (with extra line breaks for display purposes only):
          </preamble>
          -->
          <artwork><![CDATA[
  POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded

  grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-
  bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU
  [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
]]></artwork>
        </figure>
        <t>
          アクセストークンリクエストが正当かつ認可されている場合, 認可サーバーは <xref target='token-response' /> に示すとおりアクセストークンとオプションでリフレッシュトークンを発行する.
          クライアント認証に失敗, もしくはリクエストが不正であった場合, 認可サーバーは <xref target='token-errors' /> に示すとおりエラーレスポンスを返す.
        </t>
        <!--
        <t>
          If the access token request is valid and authorized, the authorization server issues an
          access token and optional refresh token as described in <xref target='token-response' />.
          If the request failed client authentication or is invalid, the authorization server returns
          an error response as described in <xref target='token-errors' />.
        </t>
        -->
      </section>

    </section>

    <section title='アクセストークンの発行<!-- Issuing an Access Token -->' anchor='token-issue'>
      <t>
        アクセストークンリクエストが正当であり認可済であれば, 認可サーバーは <xref target='token-response' /> に述べる形式でアクセストークン (および任意でリフレッシュトークン) を発行する.
        クライアント認証に失敗, もしくはリクエストが不正であった場合, 認可サーバーは <xref target='token-errors' /> に述べる形式でエラーレスポンスを返す.
        <!--
        If the access token request is valid and authorized, the authorization server issues an
        access token and optional refresh token as described in <xref target='token-response' />.
        If the request failed client authentication or is invalid, the authorization server returns
        an error response as described in <xref target='token-errors' />.
        -->
      </t>

      <section title='成功レスポンス<!-- Successful Response -->' anchor='token-response'>
        <t>
          認可サーバーはアクセストークン (および任意でリフレッシュトークン) を発行する.
          このレスポンスはエンティティーボディーに以下のパラメーターを含み, HTTP ステータスコード 200 (OK) で返される.
          <!--
          The authorization server issues an access token and optional refresh token, and
          constructs the response by adding the following parameters to the entity body of the HTTP
          response with a 200 (OK) status code:
          -->
        </t>
        <t>
          <list style='hanging' hangIndent='6'>
            <t hangText='access_token'>
              <vspace />
              必須 (REQUIRED).
              認可サーバーが発行するアクセストークン.
              <!--
              REQUIRED. The access token issued by the authorization server.
              -->
            </t>
            <t hangText='token_type'>
              <vspace />
              必須 (REQUIRED).
              トークンのタイプ.
              値は大文字・小文字を区別しない.
              詳細は <xref target='token-types' /> を参照のこと.
              <!--
              REQUIRED. The type of the token issued as described in <xref target='token-types' />.
              Value is case insensitive.
              -->
            </t>
            <t hangText='expires_in'>
              <vspace />
              推奨 (RECOMMENDED).
              アクセストークンの有効期間を表す秒数.
              例えばこの値が <spanx style='verb'>3600</spanx> であれば, そのアクセストークンは発行から1時間後に期限切れとなる.
              省略された場合, 認可サーバはドキュメントまたは他の手段によってデフォルトの有効期間を提示すべきである (SHOULD).
              <!--
              RECOMMENDED. The lifetime in seconds of the access token. For example, the value
              <spanx style='verb'>3600</spanx> denotes that the access token will expire in one
              hour from the time the response was generated. If omitted, the authorization server
              SHOULD provide the expiration time via other means or document the default value.
              -->
            </t>
            <t hangText='refresh_token'>
              <vspace />
              任意 (OPTIONAL).
              リフレッシュトークン.
              同じ認可グラントを用いて新しいアクセストークンを取得するのに利用される.
              詳細は <xref target='token-refresh' /> を参照のこと.
              <!--
              OPTIONAL. The refresh token which can be used to obtain new access tokens using the
              same authorization grant as described in <xref target='token-refresh' />.
              -->
            </t>
            <t hangText='scope'>
              <vspace />
              クライアントから全く同一のスコープが要求された場合は任意 (OPTIONAL).
              その他は必須 (REQUIRED).
              アクセストークンのスコープ.
              詳細は <xref target='scope' /> を参照のこと.
              <!--
              OPTIONAL, if identical to the scope requested by the client; otherwise, REQUIRED. The
              scope of the access token as described by <xref target='scope' />.
              -->
            </t>
          </list>
        </t>
        <t>
          これらのパラメーターは, <xref target='RFC4627' /> で定義されているメディアタイプ <spanx style='verb'>application/json</spanx> 形式で, HTTPレスポンスボディーに含まれる.
          JavaScript Object Notation (JSON) へのシリアライゼーションは, 各パラメーターをJSONオブジェクトの最上位要素とする形式で行う.
          パラメーター名と文字列値はJSON文字列, 数値はJSON数値となる.
          パラメーターの順序は問わず, 多様であり得る.
          <!--
          The parameters are included in the entity-body of the HTTP response using the
          <spanx style='verb'>application/json</spanx> media type as defined by
          <xref target='RFC4627' />. The parameters are serialized into a JavaScript Object Notation (JSON) structure by
          adding each parameter at the highest structure level. Parameter names and string values
          are included as JSON strings. Numerical values are included as JSON numbers. The order of
          parameters does not matter and can vary.
          -->
        </t>
        <t>
          認可サーバーは, トークン, クレデンシャル, その他センシティブな情報を含むいかなる HTTP レスポンスにおいても, <spanx style='verb'>Cache-Control</spanx> (<xref target='RFC2616' />) ヘッダーに <spanx style='verb'>no-store</spanx> を, <spanx style='verb'>Pragma</spanx> (<xref target='RFC2616' />) ヘッダーに <spanx style='verb'>no-cache</spanx> を指定しなければならない (MUST).
          <!--
          The authorization server MUST include the HTTP
          <spanx style='verb'>Cache-Control</spanx> response header field <xref target='RFC2616' />
          with a value of <spanx style='verb'>no-store</spanx> in any response containing tokens,
          credentials, or other sensitive information, as well as the
          <spanx style='verb'>Pragma</spanx> response header field <xref target='RFC2616' /> with a
          value of <spanx style='verb'>no-cache</spanx>.
          -->
        </t>
        <figure>
          <preamble>
            例:
            <!--
            For example:
            -->          </preamble>
          <artwork><![CDATA[
  HTTP/1.1 200 OK
  Content-Type: application/json;charset=UTF-8
  Cache-Control: no-store
  Pragma: no-cache

  {
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"example",
    "expires_in":3600,
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
    "example_parameter":"example_value"
  }
]]></artwork>
        </figure>
        <t>
          クライアントはレスポンスに含まれる認識できない名前の値を無視しなければならない (MUST).
          トークンや認可サーバーから受けとるその他の値のサイズは定義しない.
          クライアントは値のサイズについてなんらかの仮定をすべきではない.
          認可サーバーは自身が発行するあらゆる値のサイズについてドキュメントに明記すべきである (SHOULD).
          <!--
          The client MUST ignore unrecognized value names in the response. The sizes of tokens and
          other values received from the authorization server are left undefined. The client should
          avoid making assumptions about value sizes. The authorization server SHOULD document the
          size of any value it issues.
          -->
        </t>
      </section>

      <section title='エラーレスポンス<!-- Error Response -->' anchor='token-errors'>
        <t>
          認可サーバーは(特に指定が無い限りは)HTTP ステータスコード 400 (Bad Request) を返す.
          このレスポンスには以下のパラメーターが含まれる.
          <!--
          The authorization server responds with an HTTP 400 (Bad Request) status code (unless
          specified otherwise) and includes the following parameters with the response:
          -->
        </t>
        <t>
          <list style='hanging' hangIndent='6'>
            <t hangText='error'>
              <vspace />
              必須 (REQUIRED).
              以下のASCII <xref target="USASCII" /> エラーコードより1つを設定する.
              <!--
              REQUIRED. A single ASCII <xref target="USASCII" /> error code from the following:
              -->

              <list style='hanging' hangIndent='6'>
                <t hangText='invalid_request'>
                  <vspace />
                  リクエストに必要なパラメーターが含まれていない, サポートされない(グラントタイプ以外の)パラメーター値が含まれている, パラメーターが重複している, 複数のクレデンシャルが含まれている, クライアント認証のための複数のメカニズムが利用されている, もしくは異常値が設定されている.
                  <!--
                  The request is missing a required parameter, includes an unsupported
                  parameter value (other than grant type), repeats a parameter, includes multiple
                  credentials, utilizes more than one mechanism for authenticating the client,
                  or is otherwise malformed.
                  -->
                </t>
                <t hangText='invalid_client'>
                  <vspace />
                  クライアント認証に失敗した (例: 未知のクライアントである, クライアント認証情報が含まれていない, サポートされない認証方式が利用されている).
                  認可サーバーはどのHTTP認証スキームがサポートされているかを示すためにHTTP ステータスコード 401 (Unauthorized) を返してもよい (MAY).
                  もしクライアントが <spanx style='verb'>Authorization</spanx> リクエストヘッダー経由で認証を試みた場合, 認可サーバーはHTTP ステータスコード 401 (Unauthorized) と共に, <spanx style='verb'>WWW-Authenticate</spanx> レスポンスヘッダーにクライアントが利用すべき認証スキームを含めなければならない (MUST).
                  <!--
                  Client authentication failed (e.g., unknown client, no client authentication
                  included, or unsupported authentication method). The authorization server MAY
                  return an HTTP 401 (Unauthorized) status code to indicate which HTTP
                  authentication schemes are supported. If the client attempted to authenticate via
                  the <spanx style='verb'>Authorization</spanx> request header field,
                  the authorization server MUST respond with an HTTP 401 (Unauthorized) status
                  code and include the <spanx style='verb'>WWW-Authenticate</spanx> response
                  header field matching the authentication scheme used by the client.
                  -->
                </t>
                <t hangText='invalid_grant'>
                  <vspace />
                  提供された認可グラント (例えば認可コード, リソースオーナークレデンシャル)またはリフレッシュトークン が不正, 有効期限切れ, 失効している, 認可リクエストで用いられたリダイレクトURIとマッチしていない, 他のクライアントに対して発行されたものである.
                  <!--
                  The provided authorization grant (e.g., authorization code, resource owner
                  credentials) or refresh token is invalid, expired, revoked, does not match the
                  redirection URI used in the authorization request, or was issued to another
                  client.
                  -->
                </t>
                <t hangText='unauthorized_client'>
                  <vspace />
                  認証されたクライアントが当該のグラントタイプを利用する様に認可されていない.
                  <!--
                  The authenticated client is not authorized to use this authorization grant type.
                  -->
                </t>
                <t hangText='unsupported_grant_type'>
                  <vspace />
                  グラントタイプが認可サーバーによってサポートされていない.
                  <!--
                  The authorization grant type is not supported by the authorization server.
                  -->
                </t>
                <t hangText='invalid_scope'>
                  <vspace />
                  要求されたスコープが不正, 未知, 異常, リソースオーナーによって与えられた範囲を超えている.
                  <!--
                  The requested scope is invalid, unknown, malformed, or exceeds the scope granted
                  by the resource owner.
                  -->
                </t>
              </list>

              <spanx style='verb'>error</spanx> パラメータの値は %x20-21 / %x23-5B / %x5D-7E 以外の文字を含んではならない (MUST NOT).
              <!--
              Values for the <spanx style='verb'>error</spanx> parameter MUST NOT include
              characters outside the set %x20-21 / %x23-5B / %x5D-7E.
              -->
            </t>
            <t hangText='error_description'>
              <vspace />
              任意 (OPTIONAL).
              クライアント開発者が発生したエラーを理解する際の手助けとなる, 可読性のあるASCII <xref target="USASCII" />テキストの追加情報.
              <!--
              OPTIONAL.  Human-readable ASCII <xref target="USASCII" /> text providing additional information,
              used to assist the client developer in understanding the error that occurred.
              -->
              <vspace/>
              <spanx style='verb'>error_description</spanx> パラメータの値は %x20-21 / %x23-5B / %x5D-7E 以外の文字を含んではならない (MUST NOT).
              <!--
              Values for the <spanx style='verb'>error_description</spanx> parameter MUST NOT include
              characters outside the set %x20-21 / %x23-5B / %x5D-7E.
              -->
            </t>
            <t hangText='error_uri'>
              <vspace />
              任意 (OPTIONAL).
              クライアント開発者が発生したエラーに関する追加の情報を得ることができるWebページのURI.
              <!--
              OPTIONAL. A URI identifying a human-readable web page with information about the
              error, used to provide the client developer with additional information about the
              error.
              -->
              <vspace/>
              <spanx style='verb'>error_uri</spanx> パラメータの値はURI参照でなければならない(MUST).
              また, それ故に%x21 / %x23-5B / %x5D-7E 以外の文字を含んではならない (MUST NOT).
              <!--
              Values for the <spanx style='verb'>error_uri</spanx> parameter
              MUST conform to the URI&nbhy;reference syntax and thus MUST NOT include
              characters outside the set %x21 / %x23-5B / %x5D-7E.
              -->
            </t>
          </list>
        </t>
        <t>
          これらのパラメーターは, <xref target='RFC4627' /> で定義されているメディアタイプ <spanx style='verb'>application/json</spanx> 形式で, HTTPレスポンスボディーに含まれる.
          JSONへのシリアライゼーションは, 各パラメーターをJSONオブジェクトの最上位要素とする形式で行う.
          パラメーター名と文字列値はJSON文字列, 数値はJSON数値となる.
          パラメーターの順序は問わず, 多様であり得る.
          <!--
          The parameters are included in the entity-body of the HTTP response using the
          <spanx style='verb'>application/json</spanx> media type as defined by
          <xref target='RFC4627' />. The parameters are serialized into a JSON structure by
          adding each parameter at the highest structure level. Parameter names and string values
          are included as JSON strings. Numerical values are included as JSON numbers. The order of
          parameters does not matter and can vary.
          -->
        </t>
        <figure>
          <preamble>
            例:
            <!--
            For example:
            -->
          </preamble>
          <artwork><![CDATA[
  HTTP/1.1 400 Bad Request
  Content-Type: application/json;charset=UTF-8
  Cache-Control: no-store
  Pragma: no-cache

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

    </section>

    <section title='アクセストークンの更新<!--Refreshing an Access Token-->' anchor='token-refresh'>
      <t>
        認可サーバーがクライアントにリフレッシュトークンを発行していれば, クライアントはトークンエンドポイントに更新リクエストを送ることができる.
        以下のパラメーターが <xref target="urlencoded"/>による<spanx style='verb'>application/x-www-form-urlencoded</spanx> 形式で, UTF-8エンコードされてHTTPリクエストエンティティーボディーに加えられる.
        <!--
        If the authorization server issued a refresh token to the client, the client makes a
        refresh request to the token endpoint by adding the following parameters using the
        <spanx style='verb'>application/x-www-form-urlencoded</spanx> format
        per <xref target="urlencoded"/> with a character encoding of UTF-8
        in the HTTP request entity-body:
        -->
      </t>
      <t>
        <list style='hanging' hangIndent='6'>
          <t hangText='grant_type'>
            <vspace />
            必須 (REQUIRED).
            値には <spanx style='verb'>refresh_token</spanx> がセットされなければならない (MUST).
            <!--
            REQUIRED. Value MUST be set to <spanx style='verb'>refresh_token</spanx>.
            -->
          </t>
          <t hangText='refresh_token'>
            <vspace />
            必須 (REQUIRED).
            クライアントに発行されたリフレッシュトークン.
            <!--
            REQUIRED. The refresh token issued to the client.
            -->
          </t>
          <t hangText='scope'>
            <vspace />
            任意 (OPTIONAL).
            アクセス要求のスコープ.
            詳細は <xref target='scope' /> を参照のこと.
            要求されたスコープはリソースオーナーがもともと許可していない値を含んではならない (MUST NOT).
            もし指定されなかった場合は, もともと許可された値が用いられる.
            <!--
            OPTIONAL. The scope of the access request as described by <xref target='scope' />.
            The requested scope MUST NOT include any scope not originally granted by the resource
            owner, and if omitted is treated as equal to the scope originally granted by the
            resource owner.
            -->
          </t>
        </list>
      </t>
      <t>
        リフレッシュトークンは, 一般的に有効期間の長い追加のアクセストークンを要求するためのクレデンシャルであるため, 発行されたクライアントと紐づく.
        クライアントタイプがコンフィデンシャルである場合, あるいはクライアントクレデンシャルが発行された (もしくはその他の認証が要求された) クライアントは, <xref target='token-endpoint-auth' /> に示すとおり認可サーバーにより認証されなければならない (MUST).
        <!--
        Because refresh tokens are typically long-lasting credentials used to request additional
        access tokens, the refresh token is bound to the client to which it was issued. If the client type
        is confidential or the client was issued client credentials (or assigned other
        authentication requirements), the client MUST authenticate with the authorization server as
        described in <xref target='token-endpoint-auth' />.
        -->
      </t>
      <figure>
        <preamble>
          例えば, クライアントはTLSを用いて次のようなHTTPリクエストを送信する (改行は掲載上の都合による).
          <!--
          For example, the client makes the following HTTP request using transport-layer
          security (with extra line breaks for display purposes only):
          -->
        </preamble>
        <artwork><![CDATA[
  POST /token HTTP/1.1
  Host: server.example.com
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
  Content-Type: application/x-www-form-urlencoded

  grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
]]></artwork>
      </figure>
      <t>
        認可サーバーは次のことを実施しなければならない (MUST):
        <!--
        The authorization server MUST:
        -->
      </t>
      <t>
        <list style='symbols'>
          <t>
            コンフィデンシャルクライアント, あるいはクライアントクレデンシャルが発行された (もしくはその他の認証が要求された) クライアントにクライアント認証を要求し,
            <!--
            require client authentication for confidential clients or for any client that was
            issued client credentials (or with other authentication requirements),
            -->
          </t>
          <t>
            クライアントの認証情報が含まれていた場合はクライアントを認証し, リフレッシュトークンが確かにそのクライアントに対して発行されたものであることを確認し,
            <!--
            authenticate the client if client authentication is included and ensure that the
            refresh token was issued to the authenticated client, and
            -->
          </t>
          <t>
            リフレッシュトークンを検証する.
            <!--
            validate the refresh token.
            -->
          </t>
        </list>
      </t>
      <t>
        リクエストが有効で認可されている場合, 認可サーバーはアクセストークンを発行する.
        レスポンスの詳細は <xref target='token-response' /> を参照のこと.
        リクエストの検証に失敗もしくはリクエストが無効な場合, 認可サーバーはエラーレスポンスを返す.
        エラーレスポンスの詳細は <xref target='token-errors' /> を参照のこと.
        <!--
        If valid and authorized, the authorization server issues an access token as described in
        <xref target='token-response' />. If the request failed verification or is invalid, the
        authorization server returns an error response as described in
        <xref target='token-errors' />.
        -->
      </t>
      <t>
        認可サーバーは新しいリフレッシュトークンを返してもよい (MAY).
        その場合, クライアントは古いリフレッシュトークンを破棄し, 新しいリフレッシュトークンに取り替えなければならない (MUST).
        認可サーバーは新しいリフレッシュトークンを発行した後, 古いリフレッシュトークンを無効化してもよい (MAY).
        新しいリフレッシュトークンが発行された時, リフレッシュトークンのスコープはクライアントによってリクエストに含まれたリフレッシュトークンのスコープと同一でなければならない (MUST).
        <!--
        The authorization server MAY issue a new refresh token, in which case the client MUST
        discard the old refresh token and replace it with the new refresh token. The authorization
        server MAY revoke the old refresh token after issuing a new refresh token to the client. If
        a new refresh token is issued, the refresh token scope MUST be identical to that of the
        refresh token included by the client in the request.
        -->
      </t>
    </section>

    <section title='保護されたリソースへのアクセス<!-- Accessing Protected Resources -->' anchor='access-resource'>
      <t>
        クライアントはリソースサーバー上の保護されたリソースにアクセストークンを用いてアクセスする.
        リソースサーバーはアクセストークンの検証を行い, 有効期間が切れていないこと, 要求されているリソースがスコープ範囲内であることを確認しなければならない (MUST).
        アクセストークンを検証する具体的な方法 (およびエラーレスポンス) は本仕様の対象外だが, 一般的に検証はリソースサーバーと認可サーバーで協調して実行される.
        <!--
        The client accesses protected resources by presenting the access token to the resource
        server. The resource server MUST validate the access token and ensure that it has not expired
        and that its scope covers the requested resource. The methods used by the resource server
        to validate the access token (as well as any error responses) are beyond the scope of this
        specification but generally involve an interaction or coordination between the resource
        server and the authorization server.
        -->
      </t>
      <t>
        クライアントがリソースサーバーの認証を受けるためにどのようにアクセストークンを用いるかは, リソースサーバーから払い出されたアクセストークンのタイプに依存する.
        一般的には, <xref target="RFC6750"/>のようなアクセストークンタイプの仕様に定義される認証スキームに従ってHTTPの <spanx style='verb'>Authorization</spanx> ヘッダフィールド <xref target='RFC2617' /> が利用される.
        <!--
        The method in which the client utilizes the access token to authenticate with the resource
        server depends on the type of access token issued by the authorization server. Typically,
        it involves using the HTTP <spanx style='verb'>Authorization</spanx> request header field
        <xref target='RFC2617' /> with an authentication scheme defined by the
      specification of the access token type used, such as <xref target="RFC6750"/>.
        -->
      </t>

      <section title='アクセストークンタイプ<!-- Access Token Types -->' anchor='token-types'>
        <t>
          アクセストークンタイプは, タイプ特有の属性とともに, クライアントが保護されたリソースにリクエストする際アクセストークンを適切に用いるために必要な情報を提供する.
          クライアントはトークンタイプが想定外のものであるとき, そのアクセストークンを利用してはならない (MUST NOT).
          <!--
          The access token type provides the client with the information required to successfully
          utilize the access token to make a protected resource request (along with type-specific
          attributes). The client MUST NOT use an access token if it does not understand the token
          type.
          -->
        </t>
        <figure>
          <preamble>
            例えば, <xref target='RFC6750' /> に定義される <spanx style='verb'>bearer</spanx> トークンタイプでは, 単にリクエストにアクセストークンを含めるだけでよい.
            <!--
            For example, the <spanx style='verb'>bearer</spanx> token type defined in
            <xref target='RFC6750' /> is utilized by simply including the access
            token string in the request:
            -->
          </preamble>
          <artwork><![CDATA[
  GET /resource/1 HTTP/1.1
  Host: example.com
  Authorization: Bearer mF_9.B5f-4.1JqM
]]></artwork>
        </figure>
        <figure>
          <preamble>
            一方, <xref target='OAuth-HTTP-MAC' /> に定義される <spanx style='verb'>mac</spanx> トークンタイプでは, アクセストークンと共にMessage Authentication Code (MAC)キーを発行する.
            このMACキーはHTTPリクエストの一部分を署名するのに利用される.
            <!--
            while the <spanx style='verb'>mac</spanx> token type defined in
            <xref target='OAuth-HTTP-MAC' /> is utilized by issuing a
            Message Authentication Code (MAC) key
            together with the access token that is used to sign certain components of the HTTP
            requests:
            -->
          </preamble>
          <artwork><![CDATA[
  GET /resource/1 HTTP/1.1
  Host: example.com
  Authorization: MAC id="h480djs93hd8",
                     nonce="274312:dj83hs9s",
                     mac="kDZvddkndxvhGRXZhvuDjEWhGeE="
]]></artwork>
        </figure>
        <t>
          尚, 上記はあくまで参考例であり, 開発者は利用前に <xref target='RFC6750' /> や <xref target='OAuth-HTTP-MAC' /> を参照することが推奨される.
          <!--
          The above examples are provided for illustration purposes only. Developers are advised to
          consult the <xref target='RFC6750' /> and
          <xref target='OAuth-HTTP-MAC' /> specifications before use.
          -->
        </t>
        <t>
          各アクセストークンタイプ定義は, <spanx style='verb'>access_token</spanx> レスポンスパラメーターとともにクライアントへ送付される追加属性 (もしあれば) を指定する.
          また, 保護されたリソースへのリクエストにアクセストークンを含めるために利用されるHTTP認証方式も定義する.
          <!--
          Each access token type definition specifies the additional attributes (if any) sent to
          the client together with the <spanx style='verb'>access_token</spanx> response parameter.
          It also defines the HTTP authentication method used to include the access token when
          making a protected resource request.
          -->
        </t>
      </section>

      <section title='エラーレスポンス<!-- Error Response -->' anchor='resource-errors'>
        <t>
          リソースアクセスに失敗した場合, リソースサーバーはクライアントにエラーを通知すべきである (SHOULD).
          このようなエラーに関する詳細については本仕様の範疇外であるが, エラーの値はOAuthトークン認証スキームで共有されるため, 本ドキュメントでは<xref target='error-registry' />で共有レジストリを設置している.
          <!--
          If a resource access request fails, the resource server SHOULD inform
          the client of the error.  While the specifics of such error responses
          are beyond the scope of this specification, this document establishes
          a common registry in <xref target='error-registry' /> for error values
          to be shared among OAuth token authentication schemes.
          -->
        </t>
        <t>
          主にOAuthトークン認証のために設計された新しい認証スキームでは, エラーの値を本仕様によって設置されているエラーレジストリに登録することを考慮した上で, エラーステータスコードをクライアントに提示するためのメカニズムを定義すべきである (SHOULD).
          そのようなスキームは有効なエラーコードのセットを登録されている値のサブセットに制限してもよい (MAY).
          エラーコードが名前付きパラメータで返却された場合, そのパラメータ名は<spanx style='verb'>error</spanx>にすべきである(SHOULD).
          <!--
          New authentication schemes designed primarily for OAuth token
          authentication SHOULD define a mechanism for providing an
          error status code to the client, in which the error values allowed are
          registered in the error registry established by this specification. Such
          schemes MAY limit the set of valid error codes to a subset of the
          registered values. If the error code is returned using a named parameter,
          the parameter name SHOULD be <spanx style='verb'>error</spanx>.
          -->
        </t>
        <t>
          OAuthトークン認証にも使えるが, 主とする目的のためには設計されていない他のスキームについては, 同様の方法でエラーの値を登録してもよい(MAY).
          <!--
          Other schemes capable of being used for OAuth token authentication, but
          not primarily designed for that purpose, MAY bind their error values to the
          registry in the same manner.
          -->
        </t>
        <t>
          新しい認証スキームは, 本仕様と同様の方法によって, エラー情報を返却するために<spanx style='verb'>error_description</spanx>と<spanx style='verb'>error_uri</spanx>パラメータを選択してもよい(MAY).
          <!--
          New authentication schemes MAY choose to also specify the use of the
          <spanx style='verb'>error_description</spanx> and
          <spanx style='verb'>error_uri</spanx>
          parameters to return error information in a manner parallel
          to their usage in this specification.
          -->
        </t>
      </section>
    </section>

    <section title='仕様の拡張性<!-- Extensibility -->' anchor='extensions'>

      <section title='アクセストークンタイプの定義<!-- Defining Access Token Types -->' anchor='new-types'>
        <t>
          アクセストークンタイプを定義する方法は, <xref target='type-registry' /> に示す手順でアクセストークンタイプレジストリーへの登録を行う方法と, 重複しない絶対 URI をタイプ名として用いる方法の2通りが存在する.
          <!--
          Access token types can be defined in one of two ways: registered in the Access Token Types
          registry (following the procedures in <xref target='type-registry' />), or by using a
          unique absolute URI as its name.
          -->
        </t>
        <t>
          URI をタイプ名として用いるトークンタイプは, ベンダー固有の実装に限定されるべきであり (SHOULD), 広く一般に適用されるものではない.
          またこれらのトークンタイプは, それが用いられるリソースサーバーの実装詳細に固有のものである.
          <!--
          Types utilizing a URI name SHOULD be limited to vendor-specific implementations that are
          not commonly applicable, and are specific to the implementation details of the resource
          server where they are used.
          -->
        </t>
        <t>
          上記以外のすべてのトークンタイプは, レジストリーへの登録が必須である (MUST).
          タイプ名は type-name ABNF に従わなければならない (MUST).
          またトークンタイプが新しい HTTP 認証スキームを定義する場合, そのタイプ名には (<xref target='RFC2617' /> に定義されるように) HTTP 認証スキームと同一のものを用いるべきである (SHOULD).
          なおトークンタイプ <spanx style='verb'>example</spanx> は, 例示のために予約済である.
          <!--
          All other types MUST be registered. Type names MUST conform to the type-name ABNF. If the
          type definition includes a new HTTP authentication scheme, the type name SHOULD be
          identical to the HTTP authentication scheme name (as defined by <xref target='RFC2617' />).
          The token type <spanx style='verb'>example</spanx> is reserved for use in examples.
          -->
        </t>
        <figure>
          <artwork><![CDATA[
  type-name  = 1*name-char
  name-char  = "-" / "." / "_" / DIGIT / ALPHA
]]></artwork>
        </figure>
      </section>

      <section title='新たなエンドポイントパラメーターの定義<!-- Defining New Endpoint Parameters -->' anchor="endpoint-params">
        <t>
          認可エンドポイントおよびトークンエンドポイントで用いられる新たなリクエストないしレスポンスパラメーターは, <xref target='parameters-registry' /> に示す手順に従って定義され, OAuthパラメーターレジストリーに登録される.
          <!--
          New request or response parameters for use with the authorization endpoint or the token
          endpoint are defined and registered in the OAuth Parameters registry following the procedure in
          <xref target='parameters-registry' />.
          -->
        </t>
        <t>
          パラメーター名は param-name ABNF に従わなければならず (MUST), パラメーター値は (ABNF や既存パラメーターのシンタックスを参照するなどの方法で) 明確に定義する必要がある (MUST).
          <!--
          Parameter names MUST conform to the param-name ABNF, and parameter values syntax MUST be
          well-defined (e.g., using ABNF, or a reference to the syntax of an existing parameter).
          -->
        </t>
        <figure>
          <artwork><![CDATA[
  param-name  = 1*name-char
  name-char   = "-" / "." / "_" / DIGIT / ALPHA
]]></artwork>
        </figure>
        <t>
          ベンダー固有の未登録拡張パラメーターは, 広く一般には適用されず, それが用いられる認可サーバーの実装詳細に固有のものである.
          これらの拡張パラメーターには, その他の登録済みの値と衝突しないようなベンダー固有のプレフィックスを用いるべきである (SHOULD). (例: パラメーター名を 'companyname_' で始める)
          <!--
          Unregistered vendor-specific parameter extensions that are not
commonly applicable and that
          are specific to the implementation details of the authorization server where they are
          used SHOULD utilize a vendor-specific prefix that is not likely to conflict with other
          registered values (e.g., begin with 'companyname_').
          -->
        </t>
      </section>

      <section title='新たな認可グラントタイプの定義<!-- Defining New Authorization Grant Types -->'>
        <t>
          新たな認可グラントタイプは <spanx style='verb'>grant_type</spanx> パラメーター値として用いる重複の無い絶対 URI を用いることで定義される.
          拡張グラントタイプを用いるために新たなトークンエンドポイントパラメーターが必要な場合は, それらのパラメーターを <xref target='parameters-registry' /> に述べるように OAuth パラメーターレジストリーに登録する必要がある (MUST).
          <!--
          New authorization grant types can be defined by assigning them a unique absolute URI for
          use with the <spanx style='verb'>grant_type</spanx> parameter. If the extension grant
          type requires additional token endpoint parameters, they MUST be registered in the OAuth
          Parameters registry as described by <xref target='parameters-registry' />.
          -->
        </t>
      </section>

      <section title='新たな認可エンドポイントレスポンスタイプの定義<!-- Defining New Authorization Endpoint Response Types -->' anchor='response-type-ext'>
        <t>
          認可エンドポイントで利用される新しいレスポンスタイプは認可エンドポイントレスポンスタイプレジストリーに <xref target='response-type-registry' /> の手順で定義され登録される.
          レスポンスタイプ名は response-type ABNF に従って定義する必要がある (MUST).
          <!--
          New response types for use with the authorization endpoint are defined and registered in
          the Authorization Endpoint Response Types registry following the procedure in
          <xref target='response-type-registry' />. Response type names MUST conform to the
          response-type ABNF.
          -->
        </t>
        <figure>
          <artwork><![CDATA[
  response-type  = response-name *( SP response-name )
  response-name  = 1*response-char
  response-char  = "_" / DIGIT / ALPHA
]]></artwork>
        </figure>
        <t>
          レスポンスタイプが一つ以上の空白文字 (%x20) を含む場合, それは空白で区切られた順不同の値のリストとして扱われる.
          値の順番は一通りだけ登録でき, 同じ値の組の順番を変えた他のすべての組み合わせを網羅する.
          <!--
          If a response type contains one or more space characters (%x20), it is compared as a
          space-delimited list of values in which the order of values does not matter. Only one
          order of values can be registered, which covers all other arrangements of the same set of
          values.
          -->
        </t>
        <t>
          例えば, 本仕様ではレスポンスタイプ <spanx style='verb'>token code</spanx> を定義しないが, 拡張仕様として <spanx style='verb'>token code</spanx> レスポンスタイプを定義し登録することは可能である.
          一旦登録されると同じ組み合わせは <spanx style='verb'>code token</spanx> としては登録することはできないが, 両方の値は同じレスポンスタイプを示すために使うことが出来る.
          <!--
          For example, the response type <spanx style='verb'>token code</spanx> is left undefined
          by this specification. However, an extension can define and register the
          <spanx style='verb'>token code</spanx> response type. Once registered, the same
          combination cannot be registered as <spanx style='verb'>code token</spanx>, but both
          values can be used to denote the same response type.
          -->
        </t>
      </section>

      <section title='追加のエラーコードの定義<!-- Defining Additional Error Codes -->' anchor='new-errors'>
        <t>
          プロトコルの拡張 (例えば, アクセストークンタイプ, 拡張パラメーター, 拡張グラントタイプ) が認可コードグラントエラーレスポンス (<xref target='code-authz-error' />), インプリシットグラントエラーレスポンス (<xref target='implicit-authz-error' />), トークンエラーレスポンス (<xref target='token-errors' />), リソースアクセスエラーレスポンス(<xref target='resource-errors' />) と一緒に使われる追加のエラーコードを必要とする場合, そのようなエラーコードを定義してもよい (MAY).
          <!--
          In cases where protocol extensions (i.e., access token types, extension parameters, or
          extension grant types) require additional error codes to be used with the authorization
          code grant error response (<xref target='code-authz-error' />), the implicit grant error
          response (<xref target='implicit-authz-error' />), the token error response
          (<xref target='token-errors' />),
          or the resource access error response (<xref target='resource-errors' />),
          such error codes MAY be defined.
          -->
        </t>
        <t>
          拡張エラーコードは登録されたアクセストークンタイプ, エンドポイントパラメーター, 拡張グラントタイプと共に利用する場合は (<xref target='error-registry' /> の手順に従って) 登録されなければならない (MUST).
          登録されていない拡張と共に利用するエラーコードは登録してもよい (MAY).
          <!--
          Extension error codes MUST be registered (following the procedures in
          <xref target='error-registry' />) if the extension they are used in conjunction with is
          a registered access token type, a registered endpoint parameter, or an extension grant
          type. Error codes used with unregistered extensions MAY be registered.
          -->
        </t>
        <t>
          エラーコードは error-code ABNF に従う必要があり (MUST), 可能な場合は識別名をプレフィックスとして付与するべきである (SHOULD).
          例えば, 不正な値が拡張パラメーター  <spanx style='verb'>example</spanx> に設定されたことを示すエラーは <spanx style='verb'>example_invalid</spanx> と命名されるべきである.
          <!--
          Error codes MUST conform to the error ABNF and SHOULD be prefixed by an identifying
          name when possible. For example, an error identifying an invalid value set to the
          extension parameter <spanx style='verb'>example</spanx> SHOULD be named
          <spanx style='verb'>example_invalid</spanx>.
          -->
        </t>
        <figure>
          <artwork><![CDATA[
  error      = 1*error-char
  error-char = %x20-21 / %x23-5B / %x5D-7E
]]></artwork>
        </figure>
      </section>

    </section>

    <section title='ネイティブアプリケーション<!--Native Applications-->' anchor="NativeApps">
      <t>
        ネイティブアプリケーションはリソースオーナーが利用する端末にインストールされ, 実行されるクライアントである (例えば, デスクトップアプリケーション, ネイティブモバイルアプリケーション).
        ネイティブアプリケーションではセキュリティ, プラットフォーム性能と全体的なエンドユーザー体験に関する特別な考慮を必要とするかもしれない (MAY).
        <!--
        Native applications are clients installed and executed on the device used by the resource
        owner (i.e., desktop application, native mobile application). Native applications require
        special consideration related to security, platform capabilities, and overall end-user
        experience.
        -->
      </t>
      <t>
        認可エンドポイントはクライアントとリソースオーナーのユーザーエージェントによるインタラクションを要求する.
        ネイティブアプリケーションは外部のユーザーエージェントを起動もしくはアプリケーション内にユーザーエージェントを埋め込むことができる.
        <!--
        The authorization endpoint requires interaction between the client and the resource
        owner's user-agent. Native applications can invoke an external user-agent or embed a
        user-agent within the application. For example:
        -->
      </t>
      <t>
        <list style='symbols'>
          <t>
            外部のユーザーエージェント - ネイティブアプリケーションは, クライアントを起動するためのハンドラとしてオペレーションシステムに登録したスキームをリダイレクトURIにして利用する, クレデンシャルをコピーアンドペーストする, ローカルのWebサーバーを利用する, ユーザーエクステンションをインストールする, クライアントの管理下にあるサーバー上のリソースをリダイレクトURIとして利用するなど, ネイティブアプリケーションがレスポンスにアクセスすることを可能にする手段を用いて, 認可サーバーからのレスポンスを取得することができる.
            <!--
            External user-agent - the native application can capture the response from the
            authorization server using a redirection URI with a scheme registered with the
            operating system to invoke the client as the handler, manual copy-and-paste of the
            credentials, running a local web server, installing a user-agent extension, or by
            providing a redirection URI identifying a server-hosted resource under the client's
            control, which in turn makes the response available to the native application.
            -->
          </t>
          <t>
            埋め込まれたユーザーエージェント - ネイティブアプリケーションは, リソースを読み込んでいる間に発生した状態変更の監視やユーザーエージェントのクッキーストレージへのアクセスなど, 埋め込まれたユーザーエージェントとの直接通信によりレスポンスを受け取ることができる.
            <!--
            Embedded user-agent - the native application obtains the response by directly
            communicating with the embedded user-agent by monitoring state changes emitted during
            the resource load, or accessing the user-agent's cookies storage.
            -->
          </t>
        </list>
      </t>
      <t>
        外部のユーザーエージェントか埋め込みのユーザーエージェントかを選択するとき, 開発者は次のことを考慮すべきである.
        <!--
        When choosing between an external or embedded user-agent, developers
should consider the following:
        -->
      </t>
      <t>
        <list style='symbols'>
          <t>
            認可サーバーが再認証を要求しない仕様になっており, かつリソースオーナーがアクティブセッションを保有している場合, 外部のユーザーエージェントは完了率をあげるかもしれない.
            それは慣れ親しんだエンドユーザー体験と機能性を提供する.
            リソースオーナーはまた認証を手助けするユーザーエージェントの機能や拡張 (パスワードマネージャ, 2要素のリーダー装置) に頼ることができる.
            <!--
            An external user-agent may improve completion rate, as the resource owner may already have
            an active session with the authorization server, removing the need to re-authenticate. It
            provides a familiar end-user experience and functionality. The resource owner may also
            rely on user-agent features or extensions to assist with authentication (e.g., password
            manager, 2-factor device reader).
            -->
          </t>
          <t>
            埋め込みのユーザーエージェントはコンテキストの切り替えと新しいウィンドウオープンを取り除くことで, ユーザービリティを向上させることができるかもしれない.
            <!--
            An embedded user-agent may offer improved usability, as it removes the need to switch
            context and open new windows.
            -->
          </t>
          <t>
            リソースオーナーはほとんどの外部ユーザーエージェントで見られる視覚的な保護機能にアクセスすることなく未確認のウィンドウ内で認証するため, 埋め込みのユーザーエージェントはセキュリティ問題を引き起こす.
            埋め込みのユーザーエージェントは (フィッシング攻撃が簡単に実行できる) 未確認の認証要求を信用するようエンドユーザーに刷り込んでしまう.
            <!--
            An embedded user-agent poses a security challenge because resource owners are
            authenticating in an unidentified window without access to the visual protections found
            in most external user-agents. An embedded user-agent educates end-users to trust
            unidentified requests for authentication (making phishing attacks easier to execute).
            -->
          </t>
        </list>
      </t>
      <t>
        インプリシットグラントタイプと認可コードグラントタイプを選択するとき, 以下について考慮すべきである.
        <!--
        When choosing between the implicit grant type and the authorization code grant type, the
        following should be considered:
        -->
      </t>
      <t>
        <list style='symbols'>
          <t>
            ネイティブアプリケーションはその性質上クライアントクレデンシャルを秘匿に保てないため, 認可コードグラントタイプを利用するネイティブアプリケーションはクライアントクレデンシャルを使うべきではない (SHOULD).
            <!--
            Native applications that use the authorization code grant type SHOULD do so without
            using client credentials, due to the native application's inability to keep client
            credentials confidential.
            -->
          </t>
          <t>
            インプリシットグラントタイプのフローを利用すると, リフレッシュトークンは返されないため, アクセストークンの期限が切れるたびに認可プロセスを繰り返す必要がある.
            <!--
            When using the implicit grant type flow, a refresh token is not returned, which requires
            repeating the authorization process once the access token expires.
            -->
          </t>
        </list>
      </t>
    </section>
    <section title='Security Considerations'>
      <t>
        柔軟で拡張可能なフレームワークであるため, OAuthのセキュリティに関して配慮すべき点は多くの因子によって決まる.
        以下のセクションでは実装者に <xref target='client-types' /> にある, Webアプリケーション, ユーザーエージェントベースのアプリケーション, ネイティブアプリケーションの3つのクライアントプロファイルにフォーカスを当てたセキュリティーガイドラインを提供する.
        <!--
        As a flexible and extensible framework, OAuth's security considerations depend on many
        factors. The following sections provide implementers with security guidelines focused on
        the three client profiles described in <xref target='client-types' />: web application,
        user&nbhy;agent&nbhy;based application, and native application.
        -->
      </t>
      <t>
        より包括的なOAuthのセキュリティーモデルとその分析は, プロトコルデザインの背景と共に <xref target='OAuth-THREATMODEL' /> で提供される.
        <!--
        A comprehensive OAuth security model and analysis, as well as background for the protocol
        design, is provided by <xref target='OAuth-THREATMODEL' />.
        -->
      </t>

      <section title='クライアント認証<!--Client Authentication-->'>
        <t>
          認可サーバーはクライアント認証の目的でWebアプリケーションとの間でクレデンシャルを確立する.
          認可サーバーはクライアントパスワードより強度の高い認証手段を検討することが推奨される.
          Webアプリケーションはクライアントパスワードやその他のクレデンシャルの機密性を保持しなければならない (MUST).
          <!--
          The authorization server establishes client credentials with web application clients for
          the purpose of client authentication. The authorization server is encouraged to consider
          stronger client authentication means than a client password. Web application clients MUST
          ensure confidentiality of client passwords and other client credentials.
          -->
        </t>
        <t>
          認可サーバーはクライアント認証の目的でネイティブアプリケーションやユーザーエージェントベースのアプリケーションにパスワードやその他のクレデンシャルを発行してはいけない (MUST NOT).
          認可サーバーは特定デバイス上に特定の方法でインストールされたネイティブアプリケーションに対しては, クライアントパスワード, もしくはその他のクレデンシャルを発行してもよい (MAY).
          <!--
          The authorization server MUST NOT issue client passwords or other client credentials to
          native application or user-agent-based application clients for the purpose of client
          authentication. The authorization server MAY issue a client password or other credentials
          for a specific installation of a native application client on a specific device.
          -->
        </t>
        <t>
          クライアント認証が不可能な時には, 認可サーバーはクライアントのアイデンティティ検証のために他の手段を採用すべきである (SHOULD).
          例えば, クライアントのリダイレクトURIの登録要求やリソースオーナーによるアイデンティティ確認が考えられる.
          有効なリダイレクトURIは, それ単体でリソース所有者の認可時にクライアントのアイデンティティを証明するには至らないが, リソースオーナーの認可取得後に偽のクライアントにクレデンシャルを配布するのを回避するのに利用することができる.
          <!--
          When client authentication is not possible, the authorization server SHOULD employ other
          means to validate the client's identity -- for example, by requiring the registration of
          the client redirection URI or enlisting the resource owner to confirm identity. A valid
          redirection URI is not sufficient to verify the client's identity when asking for
          resource owner authorization but can be used to prevent delivering credentials to a
          counterfeit client after obtaining resource owner authorization.
          -->
        </t>
        <t>
          認可サーバーは認証されていないクライアントとの通信によるセキュリティ上の影響を考慮しなけれならない.
          そして, そのようなクライアントに対するリフレッシュトークンなどの他のクレデンシャルの開示を制限するための措置をとらなければならない.
          <!--
          The authorization server must consider the security implications of interacting with
          unauthenticated clients and take measures to limit the potential exposure of other
          credentials (e.g., refresh tokens) issued to such clients.
          -->
        </t>
      </section>

      <section title='クライアント偽装<!-- Client Impersonation -->'>
        <t>
          もし正当なクライアントがクライアントクレデンシャルを秘匿に保てない場合, 悪意あるクライアントがそのクライアントになりすまし, 保護されたリソースへのアクセスを取得することができる.
          <!--
          A malicious client can impersonate another client and obtain access to protected
          resources if the impersonated client fails to, or is unable to, keep its client
          credentials confidential.
          -->
        </t>
        <t>
          認可サーバーはクライアントが認証可能である場合は, 常にクライアント認証を実行しなければならない (MUST).
          クライアントが本質的に認証不可能な場合は, 認可サーバーは認可レスポンス時に用いられる全リダイレクト URI の登録を要求しなければならず (MUST), また上記のような悪意あるクライアントからリソースオーナーを保護する何らかの方策を取るべきである (SHOULD).
          そのような方策の例としては, リソースオーナー自身がクライアントの身元を確認するように認可サーバーが促すことなどが考えられる.
          <!--
          The authorization server MUST authenticate the client whenever possible. If the
          authorization server cannot authenticate the client due to the client's nature, the
          authorization server MUST require the registration of any redirection URI used for
          receiving authorization responses and SHOULD utilize other means to protect resource
          owners from such potentially malicious clients. For example, the authorization server
          can engage the resource owner to assist in identifying the client and its origin.
          -->
        </t>
        <t>
          認可サーバーは明示的にリソースオーナーに認証を要求し, クライアントと要求される認可スコープおよび有効期間についての情報を提供するべきである (SHOULD).
          その時点でのクライアントのコンテキスト内の情報を評価し, リクエストの認可/拒否を行うことは, リソースオーナー自身の判断にゆだねられる.
          <!--
          The authorization server SHOULD enforce explicit resource owner authentication and
          provide the resource owner with information about the client and the requested
          authorization scope and lifetime. It is up to the resource owner to review the
          information in the context of the current client and to authorize or deny the request.
          -->
        </t>
        <t>
          認可サーバーは, クライアント認証やその他の判断基準によって, リクエストが同一のクライアントから送られておりクライアント偽装が行われていないことを確認できない限り, 二度目以降の認可リクエストを (リソースオーナーの能動的なインタラクション無しに) 自動的に処理すべきではない (SHOULD NOT).
          <!--
          The authorization server SHOULD NOT process repeated authorization requests
          automatically (without active resource owner interaction) without authenticating the
          client or relying on other measures to ensure that the repeated request comes from the
          original client and not an impersonator.
          -->
        </t>
      </section>

      <section title='アクセストークン<!-- Access Tokens -->' anchor="AccessTokenSecurity">
        <t>
          アクセストークンクレデンシャル (およびあらゆる秘匿アクセストークン属性) は, 通信経路・ストレージ上ともに機密に保たれなければならない (MUST).
          またそれらの情報は, 認可サーバー, アクセストークンが通用するリソースサーバー, およびアクセストークンを発行されたクライアントの間でのみ共有される (MUST).
          アクセストークンクレデンシャルは <xref target='tls' /> にあるTLSを用いて <xref target='RFC2818' /> で定義されているサーバー認証をした上で送信されなければならない (MUST).
          <!--
          Access token credentials (as well as any confidential access token attributes) MUST be
          kept confidential in transit and storage, and only shared among the authorization server,
          the resource servers the access token is valid for, and the client to whom the access
          token is issued. Access token credentials MUST only be transmitted using TLS as described
          in <xref target='tls' /> with server authentication as defined by
          <xref target='RFC2818' />.
          -->
        </t>
        <t>
          インプリシットグラントを利用する場合, アクセストークンは URI フラグメント経由で送信されるため, 認可されていない何者かに漏洩する可能性がある.
          <!--
          When using the implicit grant type, the access token is transmitted in the URI fragment,
          which can expose it to unauthorized parties.
          -->
        </t>
        <t>
          認可サーバーは, 認可されていない何者かがトークンの有効性を保持したままアクセストークンを生成・変更したり, トークンの生成方法を推測したりできないことを保証しなければならない (MUST).
          <!--
          The authorization server MUST ensure that access tokens cannot be generated, modified, or
          guessed to produce valid access tokens by unauthorized parties.
          -->
        </t>
        <t>
          クライアントは, 必要最小限のスコープのアクセストークンを要求すべきである (SHOULD).
          認可サーバーは, 要求されたスコープをどのように受け入れるかを判断する際, クライアントのアイデンティティを考慮すべきであり (SHOULD), 場合によっては要求よりも狭い権限しか持たないアクセストークンを発行することもある (MAY).
          <!--
          The client SHOULD request access tokens with the minimal scope necessary. The
          authorization server SHOULD take the client identity into account when choosing how
          to honor the requested scope and MAY issue an access token with less rights than
          requested.
          -->
        </t>
        <t>
          この仕様は, 提示されたアクセストークンが認可サーバーから提示元のクライアントに発行されたことを確認するいかなる方法もリソースサーバーに提供しない.
          <!--
          This specification does not provide any methods for the resource server to ensure that an
          access token presented to it by a given client was issued to that client by the
          authorization server.
          -->
        </t>
      </section>

      <section title='リフレッシュトークン<!-- Refresh Tokens -->'>
        <t>
          認可サーバーはWebアプリケーションクライアントおよびネイティブアプリケーションクライアントに対してリフレッシュトークンを発行してもよい (MAY).
          <!--
          Authorization servers MAY issue refresh tokens to web application clients and native
          application clients.
          -->
        </t>
        <t>
          リフレッシュトークンは通信経路・ストレージ上ともに機密に保たれ, 認可サーバーとリフレッシュトークン発行先クライアントの間のみで共有されなければならない (MUST).
          認可サーバーは, どのリフレッシュトークンがどのクライアントに発行されたかを記録しておかなくてはならない (MUST).
          リフレッシュトークンは <xref target='tls' /> にあるTLSを用いて <xref target='RFC2818' /> で定義されているサーバー認証をした上で送信されなければならない (MUST).
          <!--
          Refresh tokens MUST be kept confidential in transit and storage, and shared only among
          the authorization server and the client to whom the refresh tokens were issued. The
          authorization server MUST maintain the binding between a refresh token and the client to
          whom it was issued. Refresh tokens MUST only be transmitted using TLS as described in
          <xref target='tls' /> with server authentication as defined by <xref target='RFC2818' />.
          -->
        </t>
        <t>
          認可サーバーはクライアントのアイデンティティを認証出来る場合は常に, リフレッシュトークンとクライアントのアイデンティティとの間の紐付けを検証しなければならない (MUST).
          クライアント認証が不可能な場合は, 認可サーバーはリフレッシュトークンの悪用を防ぐための他の手段を展開すべきである (SHOULD).
          <!--
          The authorization server MUST verify the binding between the refresh token and client
          identity whenever the client identity can be authenticated. When client authentication is
          not possible, the authorization server SHOULD deploy other means to detect refresh token
          abuse.
          -->
        </t>
        <t>
          例えば, 認可サーバーはアクセストークンリフレッシュレスポンスの都度新しいリフレッシュトークンを発行するリフレッシュトークンローテーションを採用することができる.
          前回のリフレッシュトークンは無効にされるが, 認可サーバーには残される.
          もしリフレッシュトークンが漏洩しアタッカーと正当なクライアントの両方によって引き続き利用された場合, それらの内の一つは無効なリフレッシュトークンを提示し, 認可サーバーへ違反の発生を知らせることとなる.
          <!--
          For example, the authorization server could employ refresh token rotation in which a new
          refresh token is issued with every access token refresh response. The previous refresh
          token is invalidated but retained by the authorization server. If a refresh token is
          compromised and subsequently used by both the attacker and the legitimate client, one of
          them will present an invalidated refresh token, which will inform the authorization server
          of the breach.
          -->
        </t>
        <t>
          認可サーバーは, 認可対象外の何者かがトークンの有効性を保持したままリフレッシュトークンを生成・変更したり, トークンの生成方法を推測したりできないことを保証しなければならない (MUST).
          <!--
          The authorization server MUST ensure that refresh tokens cannot be generated, modified,
          or guessed to produce valid refresh tokens by unauthorized parties.
          -->
        </t>
      </section>

      <section title='認可コード<!-- Authorization Codes -->'>
        <t>
          認可コードの伝送経路はセキュアなチャネル上で実施されるべき (SHOULD) であり, クライアントはリダイレクトURIがネットワーク上のリソースを指している場合, そのURIを利用するためにTLSを導入すべきである (SHOULD).
          なぜなら認可コードはユーザーエージェントリダイレクトによって伝送されるため, ユーザーエージェントの履歴とHTTPリファラーヘッダーを通して公開されてしまう可能性があるためである.
          <!--
          The transmission of authorization codes SHOULD be made over a secure channel, and the
          client SHOULD require the use of TLS with its redirection URI if the URI identifies a
          network resource. Since authorization codes are transmitted via user-agent redirections,
          they could potentially be disclosed through user-agent history and HTTP referrer headers.
          -->
        </t>
        <t>
          認可コードはプロセスを完了するために, 認可サーバーで権限を付与したリソースオーナーがクライアントへ返却されるリソースオーナーと同じであることを確認するために利用されるプレーンテキストの可搬クレデンシャルとして動作する.
          したがって, もしクライアントが自身のリソースオーナー認証を認可コードに依存する場合は, クライアントのリダイレクトエンドポイントはTLSの利用を必須としなければならない (MUST).
          <!--
          Authorization codes operate as plaintext bearer credentials, used to verify that the
          resource owner who granted authorization at the authorization server is the same
          resource owner returning to the client to complete the process. Therefore, if the client
          relies on the authorization code for its own resource owner authentication, the client
          redirection endpoint MUST require the use of TLS.
          -->
        </t>
        <t>
          認可コードの有効期間は短く, かつ一度限りしか利用されてはならない (MUST).
          もし認可サーバーが単一の認可コードをアクセストークンへ交換しようとする複数の試行を検出したならば, 認可サーバーはその認可コードに基づき既に付与されたすべてのアクセストークンを無効化することを試みるべきである (SHOULD).
          <!--
          Authorization codes MUST be short lived and single-use. If the authorization server
          observes multiple attempts to exchange an authorization code for an access token, the
          authorization server SHOULD attempt to revoke all access tokens already granted based on
          the compromised authorization code.
          -->
        </t>
        <t>
          もしクライアントが認証可能であれば, 認可サーバーはその認可コードが同じクライアントに対して発行されたことを確認するためにそのクライアントを認証しなければならない (MUST).
          <!--
          If the client can be authenticated, the authorization servers MUST authenticate the
          client and ensure that the authorization code was issued to the same client.
          -->
        </t>
      </section>

      <section title='認可コードリダイレクトURIの操作<!--Authorization Code Redirection URI Manipulation-->'>
        <t>
          認可要求に認可コードグラントタイプを用いるとき, クライアントは <spanx style='verb'>redirect_uri</spanx> パラメーターによりリダイレクトURIを指定できる.
          攻撃者がリダイレクトURIの値を操作可能であるとき, 認可サーバーによってリソースオーナーのユーザーエージェントを攻撃者の管理下にあるURIに認可コードを含んだ状態でリダイレクトさせることができる.
          <!--
          When requesting authorization using the authorization code grant type, the client can
          specify a redirection URI via the <spanx style='verb'>redirect_uri</spanx> parameter.
          If an attacker can manipulate the value of the redirection URI, it can cause the
          authorization server to redirect the resource owner user-agent to a URI under the control
          of the attacker with the authorization code.
          -->
        </t>
        <t>
          攻撃者は, 正しいクライアントにおいてアカウントを作成し, 認可フローを開始することができる.
          攻撃者のユーザーエージェントがアクセス許可のために認可サーバーに送られたとき, 攻撃者は正当なクライアントにより提供された認可URIを取得し, クライアントのリダイレクトURIを攻撃者の管理下にあるURIに交換する.
          攻撃者はその後, 正当なクライアントに向けた操作された認可アクセスリンクをたどるよう被害者を騙す.
          <!--
          An attacker can create an account at a legitimate client and initiate the authorization
          flow. When the attacker's user-agent is sent to the authorization server to grant access,
          the attacker grabs the authorization URI provided by the legitimate client and replaces
          the client's redirection URI with a URI under the control of the attacker. The attacker
          then tricks the victim into following the manipulated link to authorize access to the
          legitimate client.
          -->
        </t>
        <t>
          認可サーバーにおいて, 被害者は正当で信頼できるクライアントによる正常で有効なリクエストを促され, そのリクエストを認可する.
          被害者はその後, 認可コードとともに攻撃者の管理下にあるエンドポイントにリダイレクトされる.
          攻撃者は, クライアントにより提供されたオリジナルのリダイレクトURIを用いて,　認可コードを送ることにより認可フローを完了する.
          クライアントは認可コードとアクセストークンを交換し, それを攻撃者のクライアントのアカウントと紐づけることで, 被害者により (クライアント経由で) 認可された保護されたリソースへのアクセス権を獲得できる.
          <!--
          Once at the authorization server, the victim is prompted with a normal, valid request on
          behalf of a legitimate and trusted client, and authorizes the request. The victim is
          then redirected to an endpoint under the control of the attacker with the authorization
          code. The attacker completes the authorization flow by sending the authorization code to
          the client using the original redirection URI provided by the client. The client
          exchanges the authorization code with an access token and links it to the attacker's
          client account, which can now gain access to the protected resources authorized by the
          victim (via the client).
          -->
        </t>
        <t>
          このような攻撃を防ぐため, 認可サーバーは認可コードの取得に用いたリダイレクトURIと, 認可コードとアクセストークンの交換時に提供されたリダイレクトURIが同一であることを確認しなければならない (MUST).
          認可サーバーはパブリッククライアントに対してリダイレクトURIの登録を要求しなければならず (MUST), コンフィデンシャルクライアントに対してもリダイレクトURIの登録を要求すべきである (SHOULD).
          リダイレクトURIがリクエストにより提供されたとき, 認可サーバーは登録された値を用いてそれを検証しければならない (MUST).
          <!--
          In order to prevent such an attack, the authorization server MUST ensure that the
          redirection URI used to obtain the authorization code is identical to the redirection URI
          provided when exchanging the authorization code for an access token. The authorization
          server MUST require public clients and SHOULD require confidential clients to register
          their redirection URIs. If a redirection URI is provided in the request, the
          authorization server MUST validate it against the registered value.
          -->
        </t>
      </section>

      <section title='リソースオーナーパスワードクレデンシャル<!--Resource Owner Password Credentials-->'>
        <t>
          リソースオーナーパスワードクレデンシャルグラントタイプはレガシーシステム, もしくは移行のために利用される.
          これはクライアントがユーザー名とパスワードを保管するリスク全般を軽減する.
          しかし特権のあるクレデンシャルをクライアントにさらす必要性を取り除くことはできない.
          <!--
          The resource owner password credentials grant type is often used for legacy or migration
          reasons. It reduces the overall risk of storing usernames and passwords by the client but
          does not eliminate the need to expose highly privileged credentials to the client.
          -->
        </t>
        <t>
          このグラントタイプは, 本プロトコルで回避するよう努力してきたパスワードアンチパターンを維持しているので, 他のグラントタイプより高いリスクを含んでいる.
          クライアントがパスワードを濫用することや, (例えば, ログファイルやクライアントが保持している他のリソースから) パスワードが意図せず攻撃者に公開されることがありえる.
          <!--
          This grant type carries a higher risk than other grant types because it maintains the
          password anti-pattern this protocol seeks to avoid. The client could abuse the password,
          or the password could unintentionally be disclosed to an attacker (e.g., via log files or
          other records kept by the client).
          -->
        </t>
        <t>
          加えてリソースオーナーは認可プロセスをコントロールできない (クレデンシャルをクライアントに提示した時点でリソースオーナーの関与は終了する) ので, クライアントはリソースオーナーの要求より有効範囲が広いアクセストークンを取得することができる.
          認可サーバーはこのグラントタイプで発行されたアクセストークンについての有効範囲と有効期間をよく検討すべきである.
          <!--
          Additionally, because the resource owner does not have control over the authorization
          process (the resource owner's involvement ends when it hands over its credentials to the
          client), the client can obtain access tokens with a broader scope than desired by the
          resource owner. The authorization server should consider the scope and lifetime of
          access tokens issued via this grant type.
          -->
        </t>
        <t>
          認可サーバーとクライアントはこのグラントタイプの利用を最小限に抑え, 可能であれば極力他のグラントタイプを利用すべきである (SHOULD).
          <!--
          The authorization server and client SHOULD minimize use of this grant type and utilize
          other grant types whenever possible.
          -->
        </t>
      </section>

      <section title='リクエストの機密性<!--Request Confidentiality-->'>
        <t>
          アクセストークン, リフレッシュトークン, リソースオーナーのパスワード, そしてクライアントのクレデンシャルは平文で伝送してはならない (MUST NOT).
          認可コードは平文で伝送するべきではない (SHOULD NOT).
          <!--
          Access tokens, refresh tokens, resource owner passwords, and client credentials MUST NOT
          be transmitted in the clear. Authorization codes SHOULD NOT be transmitted in the clear.
          -->
        </t>
        <t>
          <spanx style='verb'>state</spanx>, <spanx style='verb'>scope</spanx> パラメータは安全ではないチャンネル上で伝送される, もしくは安全ではない方法でに保存されることがあるため, クライアントやリソースオーナーのセンシティブな情報をプレインテキスト内に含むべきではない (SHOULD NOT).
          <!--
          The <spanx style='verb'>state</spanx> and <spanx style='verb'>scope</spanx> parameters
          SHOULD NOT include sensitive client or resource owner information in plain text, as they
          can be transmitted over insecure channels or stored insecurely.
          -->
        </t>
      </section>

      <section title='エンドポイントの真正性確保<!-- Ensuring Endpoint Authenticity -->'>

        <t>
          man-in-the-middle アタックを防ぐため, 認可サーバーは TLS を導入し, <xref target='RFC2818' /> に従って認可エンドポイントおよびトークンエンドポイントへのすべてのリクエストで TLS を利用したサーバー認証を必須としなければならない (MUST).
          クライアントはサーバー身元認証の要件に従い, <xref target='RFC6125' /> で定義されている認可サーバーのTLS 証明書の検証を行わなければならない (MUST).
          <!--
          In order to prevent man-in-the-middle attacks, the authorization server MUST require the
          use of TLS with server authentication as defined by <xref target='RFC2818' /> for
          any request sent to the authorization and token endpoints. The client MUST validate the
          authorization server's TLS certificate as defined by <xref target='RFC6125' /> and in
          accordance with its requirements for server identity authentication.
          -->
        </t>
      </section>

      <section title='クレデンシャルゲッシングアタック<!-- Credentials Guessing Attacks -->' anchor='anthropy'>
        <t>
          認可サーバーは, 攻撃者にアクセストークン, 認可コード, リフレッシュトークン, リソースオーナーパスワードおよびクライアントクレデンシャルを推測されないようにしなければならない (MUST).
          <!--
          The authorization server MUST prevent attackers from guessing access tokens,
          authorization codes, refresh tokens, resource owner passwords, and client credentials.
          -->
        </t>
        <t>
          攻撃者が生成されたトークン (とエンドユーザーにより扱われないその他のクレデンシャル) を推測する可能性は 2^(-128) 以下にしなければならず (MUST), 2^(-160) 以下にすべきである (SHOULD).
          <!--
          The probability of an attacker guessing generated tokens (and other credentials not
          intended for handling by end-users) MUST be less than or equal to 2^(-128) and SHOULD be
          less than or equal to 2^(-160).
          -->
        </t>
        <t>
          エンドユーザーが扱うクレデンシャルについては, 認可サーバーはその他の保護対策を行わなければならない (MUST).
          <!--
          The authorization server MUST utilize other means to protect credentials intended for
          end-user usage.
          -->
        </t>
      </section>

      <section title='フィッシングアタック<!-- Phishing Attacks -->'>
        <t>
          本仕様や類似プロトコルを実際に広く運用するにつれ, エンドユーザーはパスワード入力を求める Web サイトにリダイレクトされるという慣習になじんでゆくであろう.
          もしエンドユーザーがそういった Web サイトでパスワードを入力する際にそのサイトの真正性検証を怠った場合, この慣習がアタッカーに悪用され, リソースオーナーのパスワードを盗まれる可能性もある.
          <!--
          Wide deployment of this and similar protocols may cause end-users to become inured
          to the practice of being redirected to websites where they are asked to enter their
          passwords. If end-users are not careful to verify the authenticity of these websites
          before entering their credentials, it will be possible for attackers to exploit this
          practice to steal resource owners' passwords.
          -->
        </t>
        <t>
          サービスプロバイダーはエンドユーザーに対してフィッシングアタックにより引き起こされるリスクに関して教育し, エンドユーザーが簡単にサイトの真正性を確認できるメカニズムを提供するべきである.
          クライアントデベロッパーは, ユーザーエージェントとのインタラクション方式 (外部エージェント / 埋め込みエージェントのどちらを利用するかなど) とセキュリティーとの関係に加え, エンドユーザーによる認可サーバーの真正性検証能力についても熟考すべきである.
          <!--
          Service providers should attempt to educate end-users about the risks phishing attacks
          pose and should provide mechanisms that make it easy for end-users to confirm the
          authenticity of their sites. Client developers should consider the security implications
          of how they interact with the user-agent (e.g., external, embedded), and the ability of
          the end-user to verify the authenticity of the authorization server.
          -->
        </t>
        <t>
          フィッシングアタックのリスクを低減するため, 認可サーバーはエンドユーザーとのインタラクションを行うすべてのエンドポイントで TLS を利用しなければならない (MUST).
          <!--
          To reduce the risk of phishing attacks, the authorization servers MUST require the use of
          TLS on every endpoint used for end-user interaction.
          -->
        </t>
      </section>

      <section title='クロスサイトリクエストフォージェリ<!-- Cross-Site Request Forgery -->' anchor='CSRF'>
        <t>
          クロスサイトリクエストフォージェリ (CSRF) は, 攻撃者が犠牲となるエンドユーザーのユーザーエージェントに (例えば, ユーザーエージェントに誤解を招きやすいリンクやイメージ, 転送によって) 悪意のあるURIを閲覧させることにより (通常, 有効なセッションクッキーの存在によって) 信頼が確立されたサーバーへ接続させる手法である.
          <!--
          Cross-site request forgery (CSRF) is an exploit in which an attacker causes the
          user-agent of a victim end-user to follow a malicious URI (e.g., provided to the
          user-agent as a misleading link, image, or redirection) to a trusting server (usually
          established via the presence of a valid session cookie).
          -->
        </t>
        <t>
          クライアントのリダイレクトURIに対するCSRF攻撃は, 攻撃者が自身の認可コードやアクセストークンを紛れ込ませることを可能とし, クライアントに犠牲者の保護されたリソースではなく, 攻撃者のリソースに紐付いたアクセストークンを使わせることが出来てしまう (例えば, 犠牲者の銀行口座情報を攻撃者の管理しているリソースへ保存してしまう, といったことも可能となる).
          <!--
          A CSRF attack against the client's redirection URI allows an attacker to inject its own
          authorization code or access token, which can result in the client using an access token
          associated with the attacker's protected resources rather than the victim's (e.g., save
          the victim's bank account information to a protected resource controlled by the
          attacker).
          -->
        </t>
        <t>
          クライアントは自身のリダイレクトURIに対してCSRF保護対策を導入しなければならない (MUST).
          一般的に保護対策は, リダイレクトURIのエンドポイントへ送られたすべての要求に対して, 要求とユーザーエージェントの認証状態を紐付けるための値を含めることにより実現する (例えば, ユーザーエージェントを認証するために使うセッションクッキーのハッシュなど).
          クライアントは認可要求の発行時, この値を認可サーバーへ伝搬するために <spanx style='verb'>state</spanx> リクエストパラメーターを利用すべきである (SHOULD).
          <!--
          The client MUST implement CSRF protection for its redirection URI. This is typically
          accomplished by requiring any request sent to the redirection URI endpoint to include a
          value that binds the request to the user-agent's authenticated state (e.g., a hash of the
          session cookie used to authenticate the user-agent). The client SHOULD utilize the
          <spanx style='verb'>state</spanx> request parameter to deliver this value to the
          authorization server when making an authorization request.
          -->
        </t>
        <t>
          一旦エンドユーザーの認可が得られると, 認可サーバーはエンドユーザーのユーザーエージェントを <spanx style='verb'>state</spanx> パラメーターに含まれる要求されたバインド値と共にクライアントへリダイレクトする.
          クライアントはバインド値とユーザーエージェントの認証状態を突合することによりリクエストの正当性を確認することが出来る.
          CSRFを防ぐために使用されるバインド値は ( <xref target='anthropy' /> にて説明されている) 推測不能な値を含まねばならず (MUST), ユーザーエージェントの認証状態 (例えば, セッションクッキーやHTML5のローカルストレージ) はクライアントおよびユーザーエージェントのみがアクセスできる状態に保たれなければならない (つまり, 同一起源ポリシーによる保護) (MUST).
          <!--
          Once authorization has been obtained from the end-user, the authorization server
          redirects the end-user's user-agent back to the client with the required binding value
          contained in the <spanx style='verb'>state</spanx> parameter. The binding value enables
          the client to verify the validity of the request by matching the binding value to the
          user&nbhy;agent's authenticated state. The binding value used for CSRF protection MUST contain
          a non-guessable value (as described in <xref target='anthropy' />), and the user-agent's
          authenticated state (e.g., session cookie, HTML5 local storage) MUST be kept in a location
          accessible only to the client and the user-agent (i.e., protected by same-origin policy).
          -->
        </t>
        <t>
          認可サーバーの認可エンドポイントへのCSRF攻撃はエンドユーザーに知られることなく, 攻撃者が悪意のあるクライアントへのエンドユーザー認可を取得可能にしてしまう.
          <!--
          A CSRF attack against the authorization server's authorization endpoint can result in an
          attacker obtaining end-user authorization for a malicious client without involving or
          alerting the end-user.
          -->
        </t>
        <t>
          認可サーバーは認可エンドポイントにCSRF保護を実装せねばならず, 悪意あるクライアントがリソースオーナーへの通知と明確な同意なく認可を取得出来ないことを保証せねばならない (MUST).
          <!--
          The authorization server MUST implement CSRF protection for its authorization endpoint
          and ensure that a malicious client cannot obtain authorization without the awareness and
          explicit consent of the resource owner.
          -->
        </t>
      </section>

      <section title='クリックジャッキング<!--Clickjacking-->'>
        <t>
          クリックジャッキング攻撃において, 攻撃者は正当なクライアントを登録し,その後悪意のあるサイトを構築する.
          そのサイトは, 透明なiframe内に認可サーバーの認可エンドポイントのWebページをロードし, その認可ページの重要なボタンの直下に置かれるように
丁寧に配置されたダミーボタンの上に重ねられる.
          エンドユーザーが誤解し目に見えるボタンをクリックするとき, 実際は認可ページ内の (認可ボタンのような) 目に見えないボタンをクリックしている.
          これは, 攻撃者にリソースオーナーを騙し, 知らないうちにそのクライアントアクセスを許可することを許す.
          <!--
          In a clickjacking attack, an attacker registers a legitimate client and then constructs a
          malicious site in which it loads the authorization server's authorization endpoint web
          page in a transparent iframe overlaid on top of a set of dummy buttons, which are
          carefully constructed to be placed directly under important buttons on the authorization
          page. When an end-user clicks a misleading visible button, the end-user is actually
          clicking an invisible button on the authorization page (such as an "Authorize" button).
          This allows an attacker to trick a resource owner into granting its client access without
          the end-user's knowledge.
          -->
        </t>
        <t>
          この攻撃形式を防ぐため, ネイティブアプリケーションはエンドユーザーの認可を要求するとき, 埋め込みのブラウザの代わりに外部ブラウザを使用すべきである (SHOULD).
          ほとんどの最新ブラウザは, 認可サーバーが非標準の <spanx style='verb'>x-frame-options</spanx> ヘッダーを利用することにより強制的にiframeを回避することができる.
          このヘッダーは <spanx style='verb'>deny</spanx> と <spanx style='verb'>sameorigin</spanx> の2つの値を持つことができ, それぞれすべてのフレーミング, originが異なるサイトからのフレーミングを防ぐ.
          古いブラウザはJavaScriptのフレームバースティング技術を利用できるが, すべてのブラウザに有効ではないかもしれない.
          <!--
          To prevent this form of attack, native applications SHOULD use external browsers instead
          of embedding browsers within the application when requesting end-user authorization. For
          most newer browsers, avoidance of iframes can be enforced by the authorization server
          using the (non-standard) <spanx style='verb'>x-frame-options</spanx> header. This header
          can have two values, <spanx style='verb'>deny</spanx> and
          <spanx style='verb'>sameorigin</spanx>, which will block any framing, or framing by sites
          with a different origin, respectively. For older browsers, JavaScript frame-busting
          techniques can be used but may not be effective in all browsers.
          -->
        </t>
      </section>

      <section title='コードインジェクションとインプットバリデーション<!--Code Injection and Input Validation-->'>
        <t>
          入力値もしくはそれ以外の外部変数がアプリケーションによってサニタイズされずに使用されるとき, コードインジェクション攻撃が発生し, アプリケーションロジックの改ざんを引き起こす.
          これは攻撃者にアプリケーションデバイスもしくはそのデータへのアクセスを許可し, サービス不能もしくは広範囲な悪意のある副作用の導入を引き起こすかもしれない.
          <!--
          A code injection attack occurs when an input or otherwise external variable is used by an
          application unsanitized and causes modification to the application logic. This may allow
          an attacker to gain access to the application device or its data, cause denial of
          service, or introduce a wide range of malicious side-effects.
          -->
        </t>
        <t>
          認可サーバーとクライアントは受け取ったどの値も, 特に <spanx style='verb'>state</spanx>, <spanx style='verb'>redirect_uri</spanx> パラメーターはサニタイズ (と可能であれば検証) をしなければならない (MUST).
          <!--
          The authorization server and client MUST sanitize (and validate when possible) any value
          received -- in particular, the value of the <spanx style='verb'>state</spanx> and
          <spanx style='verb'>redirect_uri</spanx> parameters.
          -->
        </t>
      </section>

      <section title='オープンリダイレクタ<!--Open Redirectors-->' anchor='open-redirect'>
        <t>
          認可サーバーの認可エンドポイントとクライアントのリダイレクトエンドポイントは不適切な設定によりオープンリダイレクタとして動作しうる.
          オープンリダイレクタとは正当性の確認をせずにパラメーターで指定されたURLにユーザーエージェントを自動でリダイレクトするエンドポイントである.
          <!--
          The authorization server, authorization endpoint, and client redirection endpoint can
          be improperly configured and operate as open redirectors. An open redirector is an
          endpoint using a parameter to automatically redirect a user-agent to the location
          specified by the parameter value without any validation.
          -->
        </t>
        <t>
          オープンリダイレクタは, フィッシング攻撃, もしくはURIのオーソリティ部を見慣れた信頼できる通信先とする事で攻撃者がエンドユーザーを悪意のあるサイトに誘導するのに利用される.
          加えて認可サーバーがクライアントにリダイレクトURIの一部のみでの登録を許可した場合, 攻撃者は, 認可サーバーの正当性確認を通過し, 認可コード, アクセストークンを攻撃者が管理するエンドポイントに送信するリダイレクトURIの作成にクライアントの運営しているオープンリダイレクタを利用できる.
          <!--
          Open redirectors can be used in phishing attacks, or by an attacker to get end-users to
          visit malicious sites by using the URI authority component of a
          familiar and trusted destination.
 In addition, if the authorization server allows the client to register only
          part of the redirection URI, an attacker can use an open redirector operated by the
          client to construct a redirection URI that will pass the authorization server validation
          but will send the authorization code or access token to an endpoint under the control of
          the attacker.
          -->
        </t>
      </section>

      <section title='インプリシットフローにおけるリソースオーナーなりすましのためのアクセストークン不正利用<!--Misuse of Access Token to Impersonate Resource Owner in Implicit Flow-->'
               anchor="ImplicitImpersonation">
        <t>
          インプリシットフローを利用するパブリッククライアントについて, この仕様はアクセストークンがどのクライアントに発行されたかを特定する方法をクライアントに提供しない.
          <!--
          For public clients using implicit flows, this specification does not provide any
          method for the client to determine what client an access token was issued to.
          -->
        </t>
        <t>
          リソースオーナーは攻撃者の悪意のあるクライアントにアクセストークンを許可することにより, 進んでリソースへのアクセスを委任するかもしれない.
          これはフィッシングまたは何か他の詐欺が原因となるかもしれない.
          攻撃者はまた, なんらかのメカニズムでトークンを盗むかもしれない.
          それから, 攻撃者は正当なパブリッククライアントへのアクセストークンを提供することでリソースオーナーへのなりすましを試みるかもしれない.
          <!--
          A resource owner may willingly delegate access to a resource by granting an access token
          to an attacker's malicious client.  This may be due to phishing or some other pretext.
          An attacker may also steal a token via some other mechanism.
          An attacker may then attempt to impersonate the resource owner by providing the
          access token to a legitimate public client.
          -->
        </t>
        <t>
          インプリシットフロー (response_type=token) では, 攻撃者は認可サーバーからのレスポンスに含まれるトークンを簡単に変更し, 以前攻撃者自身に発行された実際のアクセストークンに置き換えることができる.
          <!--
          In the implicit flow (response_type=token), the attacker can easily switch the token
          in the response from the authorization server,
          replacing the real access token with the one previously issued to the attacker.
          -->
        </t>
        <t>
          アクセストークンを差し込める信用できないアプリケーションを作成する攻撃者により, クライアントのユーザーを特定するためにネイティブアプリケーションと通信しバックチャネルでアクセストークンを受け取っているサーバーは同様の危険性を持つ.
          <!--
          Servers communicating with native applications that rely on being passed
          an access token in the back channel to identify the user of the client may
          be similarly compromised by an attacker creating a compromised application
          that can inject arbitrary stolen access tokens.
          -->
        </t>
        <t>
          リソースオーナーだけがそのリソースに対する有効なアクセストークンを提示できると仮定されるいかなるパブリッククライアントも, このタイプの攻撃に対して脆弱である.
          <!--
          Any public client that makes the assumption that only the resource owner
          can present it with a valid access token for the resource
          is vulnerable to this type of attack.
          -->
        </t>
        <t>
          このタイプの攻撃は正当なクライアントでリソースオーナーの情報を攻撃者 (悪意のあるクライアント) に公開するかもしれない.
          これはまた, 合法なクライアントにて攻撃者にもともとアクセストークンもしくは認可コードを与えられたリソースオーナーと同等の資格で活動することを許可する.
          <!--
          This type of attack may expose information about the resource owner
          at the legitimate client to the attacker (malicious client).
          This will also allow the attacker to perform operations
          at the legitimate client with the same permissions as the resource owner
          who originally granted the access token or authorization code.
          -->
        </t>
        <t>
          クライアントへのリソースオーナー認証方法はこの仕様の範囲外である.
          ユーザー認証をクライアント (3rdパーティーサインインサービスなど) に委任する認可プロセスを使用するどんな仕様でも, アクセストークンがその使用のために発行されたかどうか特定するためのセキュリティメカニズム (オーディエンス制限のあるアクセストークン) の追加なしにインプリシットフローを利用してはならない (MUST NOT).
          <!--
          Authenticating resource owners to clients is out of scope for this
          specification. Any specification that uses the authorization process
          as a form of delegated end-user authentication to the client (e.g.,
          third-party sign-in service) MUST NOT use the implicit flow without
          additional security mechanisms that would enable the client to
          determine if the access token was issued for its use (e.g.,
          audience-restricting the access token).
          -->
        </t>
      </section>

    </section>

    <section title='IANA Considerations'>

      <section title='OAuth アクセストークンタイプレジストリー<!-- OAuth Access Token Type Registry -->' anchor='type-registry'>
        <t>
          本仕様では, OAuth アクセストークンタイプレジストリーを定める.
        <!--
          This specification establishes the OAuth Access Token Types registry.
        -->
        </t>

        <t>
          アクセストークンのタイプは, 1名以上の Designated Experts の勧告に従い, oauth-ext-review@ietf.org のメーリングリストで14日間の審査期間を経て, Specification Required <xref target='RFC5226' /> な状態で登録される.
          しかしながら, 発行に先立ってそのトークンタイプを用いることができるように, Designated Experts はそのトークンタイプが公開できる状態になった時点で登録を許可することもありうる.
          <!--
          Access token types are registered with a Specification Required
          (<xref target='RFC5226' />) after a two-week review period on the oauth-ext-review@ietf.org mailing
          list, on the advice of one or more Designated Experts. However, to allow for the
          allocation of values prior to publication, the Designated Expert(s) may approve
          registration once they are satisfied that such a specification will be published.
          -->
        </t>
        <t>
          登録要請は, 適切な件名 (例: "Request for access token type: example") で oauth-ext-review@ietf.org のメーリングリストに通知すべきであり, そこでレビューとコメントが行われる.
          <!--
          Registration requests must be sent to the oauth-ext-review@ietf.org mailing list for review and
          comment, with an appropriate subject (e.g., "Request for access token type: example").
          -->
        </t>
        <t>
          Designated Experts は審査期間内に登録を承認または拒否し, レビューが行われるメーリングリストおよび IANA へその決定を告げる.
          要請が拒否された場合は, その理由が通知され, 可能な場合は承認に向けた提案が行われるべきである.
          <!--
          Within the review period, the Designated Expert(s) will either approve or
          deny the registration request, communicating this decision to the review list and IANA.
          Denials should include an explanation and, if applicable, suggestions as to how to make
          the request successful.
          -->
        </t>
        <t>
          IANA は, Designated Experts によるすべてのレジストリー更新要請を承認し, すべての登録要請をレビューメーリングリストに送信しなければならない.
          <!--
          IANA must only accept registry updates from the Designated Expert(s) and should direct
          all requests for registration to the review mailing list.
          -->
        </t>

        <section title='レジストリーテンプレート<!-- Registration Template -->'>
          <t>
            <list style='hanging'>
              <t hangText='Type name:'>
                <vspace />
                名称 (例: "example").
                <!--
                The name requested (e.g., "example").
                -->
              </t>
              <t hangText='Additional Token Endpoint Response Parameters:'>
                <vspace />
                <spanx style='verb'>access_token</spanx> と同時に返される追加のレスポンスパラメーター.
                新規パラメーターは別個 <xref target='parameters-registry' /> に従って OAuth パラメーターレジストリーに登録すること (MUST).
                <!--
                Additional response parameters returned together with the
                <spanx style='verb'>access_token</spanx> parameter. New parameters MUST be
                separately registered in the OAuth Parameters registry as described by
                <xref target='parameters-registry' />.
                -->
              </t>
              <t hangText='HTTP Authentication Scheme(s):'>
                <vspace />
                登録トークンタイプのアクセストークンによるリソースリクエスト認証に用いられる HTTP Authentication スキーマ (もしあれば).
                <!--
                The HTTP authentication scheme name(s), if any, used to authenticate protected
                resource requests using access tokens of this type.
                -->
              </t>
              <t hangText='Change controller:'>
                <vspace />
                RFC の標準に従う際は, "IETF" と記載する.
                それ以外の場合は, 責任ある団体の名称を記載する.
                その他の詳細 (例えば, 郵便番号, メールアドレス, ホームページの URL) も記載してもよい.
                <!--
                For Standards Track RFCs, state "IETF". For others, give the name of the
                responsible party. Other details (e.g., postal address, email address, home page
                URI) may also be included.
                -->
              </t>
              <t hangText='Specification document(s):'>
                <vspace />
                パラメーター仕様を記載したドキュメントへの参照を記載する.
                ドキュメントを取得することのできる URI が記載されていることが望ましい.
                明確な記載箇所への参照が含まれることが望ましいが必須ではない.
                <!--
                Reference to the document(s) that specify the parameter, preferably including a URI that
                can be used to retrieve a copy of the document(s). An indication of the relevant
                sections may also be included but is not required.
                -->
              </t>
            </list>
          </t>
        </section>

      </section>

      <section title='OAuth パラメーターレジストリー<!-- OAuth Parameters Registry -->' anchor='parameters-registry'>
        <t>
          本仕様では, OAuth パラメーターレジストリーを定める.
          <!--
          This specification establishes the OAuth Parameters registry.
          -->
        </t>
        <t>
          認可エンドポイントリクエスト, 認可エンドポイントレスポンス, トークンエンドポイントリクエスト, トークンエンドポイントレスポンスに含める追加のパラメーターは, 1名以上の Designated Experts の勧告に従い, oauth-ext-review@ietf.org のメーリングリストで14日間の審査期間を経て, Specification Required <xref target='RFC5226' /> な状態で登録される.
          しかしながら, 発行に先立ってそれらの値を割り当てることができるように, Designated Experts はそれらの値が公開できる状態になった時点で登録を許可することもありうる.
          <!--
          Additional parameters for inclusion in the authorization endpoint request, the
          authorization endpoint response, the token endpoint request, or the token endpoint
          response are registered with a Specification Required
          (<xref target='RFC5226' />) after a two-week review period on the oauth-ext-review@ietf.org mailing
          list, on the advice of one or more Designated Experts. However, to allow for the
          allocation of values prior to publication, the Designated Expert(s) may approve
          registration once they are satisfied that such a specification will be published.
          -->
        </t>
        <t>
          登録要請は, 適切な件名 (例: "Request for parameter: example") で oauth-ext-review@ietf.org のメーリングリストに通知すべきであり, そこでレビューとコメントが行われる.
          <!--
          Registration requests must be sent to the oauth-ext-review@ietf.org mailing list for review and
          comment, with an appropriate subject (e.g., "Request for parameter: example").
          -->
        </t>
        <t>
          Designated Experts は審査期間内に登録を承認または拒否し, レビューが行われるメーリングリストおよび IANA へその決定を告げる.
          要請が拒否された場合は, その理由が通知され, 可能な場合は承認に向けた提案が行われるべきである.
          <!--
          Within the review period, the Designated Expert(s) will either approve or
          deny the registration request, communicating this decision to the review list and IANA.
          Denials should include an explanation and, if applicable, suggestions as to how to make
          the request successful.
          -->
        </t>
        <t>
          IANA は, Designated Experts によるすべてのレジストリー更新要請を承認し, すべての登録要請をレビューメーリングリストに送信しなければならない.
          <!--
          IANA must only accept registry updates from the Designated Expert(s) and should direct
          all requests for registration to the review mailing list.
          -->
        </t>

        <section title='レジストリーテンプレート<!-- Registration Template -->'>
          <t>
            <list style='hanging'>
              <t hangText='Parameter name:'>
                <vspace />
                名称 (例: "example").
                <!--
                The name requested (e.g., "example").
                -->
              </t>
              <t hangText='Parameter usage location:'>
                <vspace />
                パラメーターが利用できる箇所.
                想定される箇所は以下の通り: 認可リクエスト, 認可レスポンス, トークンリクエスト, トークンリクエスト.
                <!--
                The location(s) where parameter can be used. The possible locations are
                authorization request, authorization response, token request, or token response.
                -->
              </t>
              <t hangText='Change controller:'>
                <vspace />
                RFCの標準に従う際は, "IETF"と記載する.
                それ以外の場合は, 責任ある団体の名称を記載する.
                その他の詳細 (例えば, 郵便番号, メールアドレス, ホームページのURL) も記載してもよい.
                <!--
                For Standards Track RFCs, state "IETF". For others, give the name of the
                responsible party. Other details (e.g., postal address, email address, home page
                URI) may also be included.
                -->
              </t>
              <t hangText='Specification document(s):'>
                <vspace />
                パラメーター仕様を記載したドキュメントへの参照を記載する.
                ドキュメントを取得することのできる URI が記載されていることが望ましい.
                明確な記載箇所への参照が含まれることが望ましいが必須ではない.
                <!--
                Reference to the document(s) that specify the parameter, preferably including a URI that
                can be used to retrieve a copy of the document(s). An indication of the relevant
                sections may also be included but is not required.
                -->
              </t>
            </list>
          </t>
        </section>

        <section title='初期レジストリーコンテンツ<!-- Initial Registry Contents -->'>
          <t>
            OAuth パラメーターレジストリーの初期コンテンツは以下の通りである:
            <!--
            The OAuth Parameters registry's initial contents are:
            -->
          </t>
          <t>  <?rfc subcompact="yes"?>
            <list style='symbols'>
              <t>
                Parameter name: client_id
              </t>
              <t>
                Parameter usage location: authorization request, token request
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Parameter name: client_secret
              </t>
              <t>
                Parameter usage location: token request
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Parameter name: response_type
              </t>
              <t>
                Parameter usage location: authorization request
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Parameter name: redirect_uri
              </t>
              <t>
                Parameter usage location: authorization request, token request
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Parameter name: scope
              </t>
              <t>
                Parameter usage location: authorization request, authorization response, token
                request, token response
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Parameter name: state
              </t>
              <t>
                Parameter usage location: authorization request, authorization response
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Parameter name: code
              </t>
              <t>
                Parameter usage location: authorization response, token request
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Parameter name: error_description
              </t>
              <t>
                Parameter usage location: authorization response, token response
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Parameter name: error_uri
              </t>
              <t>
                Parameter usage location: authorization response, token response
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Parameter name: grant_type
              </t>
              <t>
                Parameter usage location: token request
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Parameter name: access_token
              </t>
              <t>
                Parameter usage location: authorization response, token response
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Parameter name: token_type
              </t>
              <t>
                Parameter usage location: authorization response, token response
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Parameter name: expires_in
              </t>
              <t>
                Parameter usage location: authorization response, token response
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Parameter name: username
              </t>
              <t>
                Parameter usage location: token request
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Parameter name: password
              </t>
              <t>
                Parameter usage location: token request
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Parameter name: refresh_token
              </t>
              <t>
                Parameter usage location: token request, token response
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
        </section>
       <?rfc subcompact="no"?>

      </section>

      <section title='OAuth 認可エンドポイントレスポンスタイプレジストリー<!-- OAuth Authorization Endpoint Response Type Registry-->' anchor='response-type-registry'>
        <t>
          本仕様では, OAuth 認可エンドポイントレスポンスタイプレジストリーを定める.
          <!--
          This specification establishes the OAuth Authorization Endpoint Response Types registry.
          -->
        </t>
        <t>
            認可エンドポイントで利用される追加のレスポンスタイプは,
            1名以上の Designated Experts の勧告に従い, oauth-ext-review@ietf.org のメーリングリストで14日間の審査期間を経て, Specification Required <xref target='RFC5226' /> な状態で登録される.
            しかしながら, 発行に先立ってそれらの値を割り当てることができるように, Designated Experts はそれらの値が公開できる状態になった時点で登録を許可することもありうる.
            <!--
            Additional response types for use with the authorization endpoint are registered with a
            Specification Required (<xref target='RFC5226' />) after a two-week review period on
            the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts.
            However, to allow for the allocation of values prior to publication, the Designated
            Expert(s) may approve registration once they are satisfied that such a specification
            will be published.
            -->
          </t>
          <t>
            登録要請は, 適切な件名 (例: "Request for response type: example") で [TBD]@ietf.org のメーリングリストに通知すべきであり, そこでレビューとコメントが行われる.
            <!--
            Registration requests must be sent to the oauth-ext-review@ietf.org mailing list for review and
            comment, with an appropriate subject (e.g., "Request for response type: example").
            -->
          </t>
          <t>
            Designated Experts は審査期間内に登録を承認または拒否し, レビューが行われるメーリングリストおよび IANA へその決定を告げる.
            要請が拒否された場合は, その理由が通知され, 可能な場合は承認に向けた提案が行われるべきである.
            <!--
            Within the review period, the Designated Expert(s) will either approve or
            deny the registration request, communicating this decision to the review list and IANA.
            Denials should include an explanation and, if applicable, suggestions as to how to make
            the request successful.
            -->
          </t>
          <t>
            IANA は, Designated Experts によるすべてのレジストリー更新要請を承認し, すべての登録要請をレビューメーリングリストに送信しなければならない.
            <!--
            IANA must only accept registry updates from the Designated Expert(s) and should direct
            all requests for registration to the review mailing list.
            -->
          </t>


          <section title='レジストリーテンプレート<!--Registration Template-->'>
          <t>
            <list style='hanging'>
              <t hangText='Response type name:'>
                <vspace />
                名称 (例: "example").
                <!--
                The name requested (e.g., "example").
                -->
              </t>
              <t hangText='Change controller:'>
                <vspace />
                RFCの標準に従う際は, "IETF"と記載する.
                それ以外の場合は, 責任ある団体の名称を記載する.
                その他の詳細 (例えば, 郵便番号, メールアドレス, ホームページのURL) も記載してもよい.
                <!--
                For Standards Track RFCs, state "IETF". For others, give the name of the
                responsible party. Other details (e.g., postal address, email address, home page
                URI) may also be included.
                -->
              </t>
              <t hangText='Specification document(s):'>
                <vspace />
                パラメーター仕様を記載したドキュメントへの参照を記載する.
                ドキュメントを取得することのできるURIが記載されていることが望ましい.
                明確な記載箇所への参照が含まれることが望ましいが必須ではない.
                <!--
                Reference to the document(s) that specify the type, preferably including a URI that
                can be used to retrieve a copy of the document(s). An indication of the relevant
                sections may also be included but is not required.
                -->
              </t>
            </list>
          </t>
        </section>

        <section title='初期レジストリーコンテンツ<!--Initial Registry Contents-->'>
          <t>
            OAuth 認可エンドポイントレスポンスタイプレジストリーの初期コンテンツは以下の通りである:
            <!--
            The OAuth Authorization Endpoint Response Types registry's initial contents are:
            -->
          </t>
          <t>  <?rfc subcompact="yes"?>
            <list style='symbols'>
              <t>
                Response type name: code
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Response type name: token
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Specification document(s): RFC 6749
              </t>
            </list>
          </t>
        </section>
       <?rfc subcompact="no"?>

      </section>

      <section title='OAuth拡張エラーレジストリー<!-- OAuth Extensions Error Registry-->' anchor='error-registry'>
        <t>
          本仕様では, OAuth拡張エラーレジストリーを定める.
          <!--
          This specification establishes the OAuth Extensions Error registry.
          -->
        </t>
        <t>
          他のプロトコル拡張 (例えば, 拡張グラントタイプ, アクセストークンタイプ, もしくは拡張パラメーター) で利用される追加のエラーコードは, 1名以上の Designated Experts の勧告に従い, oauth-ext-review@ietf.org のメーリングリストで14日間の審査期間を経て, Specification Required <xref target='RFC5226' /> な状態で登録される.
          しかしながら, 発行に先立ってそれらの値を割り当てることができるように, Designated Experts はそれらの値が公開できる状態になった時点で登録を許可することもありうる.
          <!--
          Additional error codes used together with other protocol extensions (i.e., extension grant
          types, access token types, or extension parameters) are registered with a Specification
          Required (<xref target='RFC5226' />) after a two-week review period on the
          oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to
          allow for the allocation of values prior to publication, the Designated Expert(s) may
          approve registration once they are satisfied that such a specification will be published.
          -->
        </t>
        <t>
          登録要請は, 適切な件名 (例: "Request for error code: example") で oauth-ext-review@ietf.org のメーリングリストに通知すべきであり, そこでレビューとコメントが行われる.
          <!--
          Registration requests must be sent to the oauth-ext-review@ietf.org mailing list for review and
          comment, with an appropriate subject (e.g., "Request for error code: example").
          -->
        </t>
        <t>
          Designated Experts は審査期間内に登録を承認または拒否し, レビューが行われるメーリングリストおよび IANA へその決定を告げる.
          要請が拒否された場合は, その理由が通知され, 可能な場合は承認に向けた提案が行われるべきである.
          <!--
          Within the review period, the Designated Expert(s) will either approve or
          deny the registration request, communicating this decision to the review list and IANA.
          Denials should include an explanation and, if applicable, suggestions as to how to make
          the request successful.
          -->
        </t>
        <t>
          IANA は, Designated Experts によるすべてのレジストリー更新要請を承認し, すべての登録要請をレビューメーリングリストに送信されなければならない.
          <!--
          IANA must only accept registry updates from the Designated Expert(s) and should direct
          all requests for registration to the review mailing list.
          -->
        </t>

        <section title='レジストリーテンプレート<!--Registration Template-->'>
          <t>
            <list style='hanging'>
              <t hangText='Error name:'>
                <vspace />
                名称 (例: "example").
                エラーの名称の値には %x20-21 / %x23-5B / %x5D-7E 以外の文字を含んではいけない.
                <!--
                The name requested (e.g., "example").
                Values for the error name MUST NOT include
                characters outside the set %x20-21 / %x23-5B / %x5D-7E.
                -->
              </t>
              <t hangText='Error usage location:'>
                <vspace />
                エラーが利用できる箇所.
                想定される箇所は以下の通り: 認可コード付与エラーレスポンス (<xref target='code-authz-error' />), インプリシット付与エラーレスポンス (<xref target='implicit-authz-error' />), トークンエラーレスポンス (<xref target='token-errors' />), リソースアクセスエラーレスポンス (<xref target='resource-errors' />).
                <!--
                The location(s) where the error can be used. The possible locations are
                authorization code grant error response (<xref target='code-authz-error' />),
                implicit grant error response (<xref target='implicit-authz-error' />),
                token error response (<xref target='token-errors' />), or
                resource access error response (<xref target='resource-errors' />).
                -->
              </t>
              <t hangText='Related protocol extension:'>
                <vspace />
                エラーコードと共に用いられる拡張グラントタイプ名, アクセストークンタイプ名, もしくは拡張パラメーター名を記載する.
                <!--
                The name of the extension grant type, access token type, or
extension parameter that
                the error code is used in conjunction with.
                -->
              </t>
              <t hangText='Change controller:'>
                <vspace />
                RFCの標準に従う際は, "IETF"と記載する.
                それ以外の場合は, 責任ある団体の名称を記載する.
                その他の詳細 (例えば, 郵便番号, メールアドレス, ホームページのURL) も記載してもよい.
                <!--
                For Standards Track RFCs, state "IETF". For others, give the name of the
                responsible party. Other details (e.g., postal address, email address, home page
                URI) may also be included.
                -->
              </t>
              <t hangText='Specification document(s):'>
                <vspace />
                エラーコード仕様を記載したドキュメントへの参照を記載する.
                ドキュメントを取得することのできるURIが記載されていることが望ましい.
                明確な記載箇所への参照が含まれることが望ましいが必須ではない.
                <!--
                Reference to the document(s) that specify the error code, preferably including a URI
                that can be used to retrieve a copy of the document(s). An indication of the relevant
                sections may also be included but is not required.
                -->
              </t>
            </list>
          </t>
        </section>

      </section>

    </section>

  </middle>

  <back>

  <?rfc rfcedstyle="no"?>
    <references title='Normative References'>

      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119"?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2246.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2616.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2617.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2818.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4627.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6125.xml' ?>

<reference anchor='W3C.REC-html401-19991224'
           target='http://www.w3.org/TR/1999/REC-html401-19991224'>
<front>
<title>HTML 4.01 Specification</title>
<author initials='D.' surname='Raggett' fullname='David Raggett'>
    <organization />
</author>
<author initials='A.' surname='Le Hors' fullname='Arnaud Le Hors'>
    <organization />
</author>
<author initials='I.' surname='Jacobs' fullname='Ian Jacobs'>
    <organization />
</author>
<date month='December' year='1999' />
</front>
<seriesInfo name='World Wide Web Consortium Recommendation'
value='REC-html401-19991224' />
</reference>

<reference anchor='W3C.REC-xml-20081126'
           target='http://www.w3.org/TR/2008/REC-xml-20081126'>
<front>
<title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<author initials='T.' surname='Bray' fullname='Tim Bray'>
    <organization />
</author>
<author initials='J.' surname='Paoli' fullname='Jean Paoli'>
    <organization />
</author>
<author initials='C.' surname='Sperberg-McQueen'
fullname='C. M. Sperberg-McQueen'>
    <organization />
</author>
<author initials='E.' surname='Maler' fullname='Eve Maler'>
    <organization />
</author>
<author initials='F.' surname='Yergeau' fullname='Francois Yergeau'>
    <organization />
</author>
<date month='November' year='2008' />
</front>
<seriesInfo name='World Wide Web Consortium Recommendation'
value='REC-xml-20081126' />
</reference>

      <reference anchor="USASCII">
        <front>
          <title>Coded Character Set -- 7-bit American Standard Code for Information Interchange</title>
          <author>
            <organization>American National Standards Institute</organization>
          </author>
          <date year="1986"/>
        </front>
        <seriesInfo name="ANSI" value="X3.4"/>
      </reference>

    </references>

    <references title='Informative References'>

      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5849.xml' ?>

<reference anchor='RFC6750'>
<front>
<title>The OAuth 2.0 Authorization Framework: Bearer Token Usage</title>
<author initials='M' surname='Jones' fullname='Michael Jones'>
    <organization />
</author>
<author initials='D' surname='Hardt' fullname='Dick Hardt'>
    <organization />
</author>
<date month='October' year='2012' />
</front>
<seriesInfo name='RFC' value='6750' />
</reference>

<!-- draft-ietf-oauth-saml2-bearer ("I-D Exists") -->
<reference anchor='OAuth-SAML2'>
<front>
<title>SAML 2.0 Bearer Assertion Profiles for OAuth 2.0</title>
<author initials='B' surname='Campbell' fullname='Brian Campbell'>
    <organization />
</author>
<author initials='C' surname='Mortimore' fullname='Chuck Mortimore'>
    <organization />
</author>
<date month='July' year='2012' />
</front>
<seriesInfo name='Work in' value='Progress' />
</reference>

<!-- draft-ietf-oauth-v2-http-mac (Expired) -->
<reference anchor='OAuth-HTTP-MAC'>
<front>
<title>HTTP Authentication: MAC Access Authentication</title>
<author initials='E' surname='Hammer-Lahav' fullname='Eran Hammer-Lahav' role="editor">
    <organization />
</author>
<date month='February' year='2012' />
</front>
<seriesInfo name='Work in' value='Progress' />
</reference>

<!-- draft-ietf-oauth-v2-threatmodel ("IESG Evaluation") -->
<reference anchor='OAuth-THREATMODEL'>
<front>
<title>OAuth 2.0 Threat Model and Security Considerations</title>
<author initials='T' surname='Lodderstedt' fullname='Torsten Lodderstedt' role="editor">
    <organization />
</author>
<author initials='M' surname='McGloin' fullname='Mark McGloin'>
    <organization />
</author>
<author initials='P' surname='Hunt' fullname='Phil Hunt'>
    <organization />
</author>
<date month='August' year='2012' />
</front>
<seriesInfo name='Work in' value='Progress' />
</reference>

<!-- draft-hardt-oauth (Expired) -->
      <reference anchor="OAuth-WRAP">
        <front>
          <title>OAuth Web Resource Authorization Profiles</title>
          <author initials="D" surname="Hardt" fullname="Dick Hardt" role="editor" />
          <author initials="A" surname="Tom" fullname="Allen Tom" />
          <author initials="B" surname="Eaton" fullname="Brian Eaton" />
          <author initials="Y" surname="Goland" fullname="Yaron Goland" />
          <date month="January" year="2010" />
        </front>
       <seriesInfo name='Work in' value='Progress' />
      </reference>

    </references>

    <references title='翻訳プロジェクト'>
      <reference anchor="oidfj">
        <front>
          <title>OpenIDファウンデーションジャパン</title>
          <author>
            <organization>OpenIDファウンデーションジャパン</organization>
          </author>
        </front>
        <format type='html' target='http://www.openid.or.jp/' />
      </reference>
      <reference anchor="oidfj-trans">
        <front>
          <title>翻訳・教育ワーキンググループ</title>
          <author>
            <organization>OpenIDファウンデーションジャパン</organization>
          </author>
        </front>
        <format type='html' target='http://openid-foundation-japan.github.com/' />
      </reference>
      <reference anchor="oidfj-github">
        <front>
          <title>Githubレポジトリー</title>
          <author>
            <organization>OpenIDファウンデーションジャパン</organization>
          </author>
        </front>
        <format type='html' target='https://github.com/openid-foundation-japan' />
      </reference>
    </references>
  <?rfc rfcedstyle="yes"?>

    <section title="Augmented Backus-Naur Form (ABNF) Syntax">
      <t>
        This section provides Augmented Backus-Naur Form (ABNF) syntax
        descriptions for the elements defined in this specification
        using the notation of <xref target='RFC5234' />.
        The ABNF below is defined in terms of
        Unicode code points <xref target="W3C.REC-xml-20081126"/>;
        these characters are typically encoded in UTF-8.
        Elements are presented in the order first defined.
      </t>
      <t>
        Some of the definitions that follow use the
        <spanx style='verb'>URI-reference</spanx>
        definition from <xref target="RFC3986"/>.
      </t>

      <figure>
        <preamble>
          Some of the definitions that follow use these common definitions:
        </preamble>
        <artwork><![CDATA[
  VSCHAR     = %x20-7E
  NQCHAR     = %x21 / %x23-5B / %x5D-7E
  NQSCHAR    = %x20-21 / %x23-5B / %x5D-7E
  UNICODECHARNOCRLF = %x09 /%x20-7E / %x80-D7FF /
                      %xE000-FFFD / %x10000-10FFFF
]]></artwork>
      </figure>
      <t>
        (The UNICODECHARNOCRLF definition is based upon the Char definition in
        Section 2.2 of <xref target="W3C.REC-xml-20081126"/>, but omitting the
        Carriage Return and Linefeed characters.)
      </t>

      <section title='"client_id" Syntax'>

        <figure>
          <preamble>
            The <spanx style='verb'>client_id</spanx> element is defined in
            <xref target="client-password"/>:
          </preamble>
          <artwork><![CDATA[
  client-id     = *VSCHAR
]]></artwork>
        </figure>
      </section>

      <section title='"client_secret" Syntax'>

        <figure>
          <preamble>
            The <spanx style='verb'>client_secret</spanx> element is defined in
            <xref target="client-password"/>:
          </preamble>
          <artwork><![CDATA[
  client-secret = *VSCHAR
]]></artwork>
        </figure>
      </section>

      <section title='"response_type" Syntax'>

        <figure>
          <preamble>
            The <spanx style='verb'>response_type</spanx> element is defined in
            Sections <xref target="response-type" format="counter"/> and
            <xref target="response-type-ext" format="counter"/>:
          </preamble>
          <artwork><![CDATA[
  response-type = response-name *( SP response-name )
  response-name = 1*response-char
  response-char = "_" / DIGIT / ALPHA
]]></artwork>
        </figure>
      </section>

      <section title='"scope" Syntax'>

        <figure>
          <preamble>
            The <spanx style='verb'>scope</spanx> element is defined in
            <xref target="scope"/>:
          </preamble>
          <artwork><![CDATA[
  scope       = scope-token *( SP scope-token )
  scope-token = 1*NQCHAR
]]></artwork>
        </figure>
      </section>

      <section title='"state" Syntax'>

        <figure>
          <preamble>
            The <spanx style='verb'>state</spanx> element is defined in
            Sections <xref target="code-authz-req" format="counter"/>,
            <xref target="code-authz-resp" format="counter"/>,
            <xref target="code-authz-error" format="counter"/>,
            <xref target="implicit-authz-req" format="counter"/>,
            <xref target="implicit-authz-resp" format="counter"/>, and
            <xref target="implicit-authz-error" format="counter"/>:
          </preamble>
          <artwork><![CDATA[
  state      = 1*VSCHAR
]]></artwork>
        </figure>
      </section>

      <section title='"redirect_uri" Syntax'>

        <figure>
          <preamble>
            The <spanx style='verb'>redirect_uri</spanx> element is defined in
            Sections <xref target="code-authz-req" format="counter"/>,
            <xref target="token-req" format="counter"/>,
            and&nbsp;<xref target="implicit-authz-req" format="counter"/>:
          </preamble>
          <artwork><![CDATA[
  redirect-uri      = URI-reference
]]></artwork>
        </figure>
      </section>

      <section title='"error" Syntax'>

        <figure>
          <preamble>
            The <spanx style='verb'>error</spanx> element is defined in
            Sections <xref target="code-authz-error" format="counter"/>,
            <xref target='implicit-authz-error' format="counter"/>,
            <xref target='token-errors' format="counter"/>,
            <xref target='resource-errors' format="counter"/>, and
            <xref target="new-errors" format="counter"/>:
          </preamble>
          <artwork><![CDATA[
  error             = 1*NQSCHAR
]]></artwork>
        </figure>
      </section>

      <section title='"error_description" Syntax'>

        <figure>
          <preamble>
            The <spanx style='verb'>error_description</spanx> element is
            defined in Sections
            <xref target="code-authz-error" format="counter"/>,
            <xref target='implicit-authz-error' format="counter"/>,
            <xref target='token-errors' format="counter"/>, and
            <xref target='resource-errors' format="counter"/>:
          </preamble>
          <artwork><![CDATA[
  error-description = 1*NQSCHAR
]]></artwork>
        </figure>
      </section>

      <section title='"error_uri" Syntax'>

        <figure>
          <preamble>
            The <spanx style='verb'>error_uri</spanx> element is defined in
            Sections <xref target="code-authz-error" format="counter"/>,
            <xref target='implicit-authz-error' format="counter"/>,
            <xref target='token-errors' format="counter"/>,
            and&nbsp;<xref target='resource-errors' format="counter"/>:
          </preamble>
          <artwork><![CDATA[
  error-uri         = URI-reference
]]></artwork>
        </figure>
      </section>

      <section title='"grant_type" Syntax'>

        <figure>
          <preamble>
            The <spanx style='verb'>grant_type</spanx> element is defined in
            Sections <xref target="token-req" format="counter"/>,
            <xref target='password-tok-req' format="counter"/>,
            <xref target='client-req' format="counter"/>,
            <xref target='ext-grant' format="counter"/>, and
            <xref target="token-refresh" format="counter"/>:
          </preamble>
          <artwork><![CDATA[
  grant-type = grant-name / URI-reference
  grant-name = 1*name-char
  name-char  = "-" / "." / "_" / DIGIT / ALPHA
]]></artwork>
        </figure>
      </section>

      <section title='"code" Syntax'>

        <figure>
          <preamble>
            The <spanx style='verb'>code</spanx> element is defined in
            <xref target="token-req"/>:
          </preamble>
          <artwork><![CDATA[
  code       = 1*VSCHAR
]]></artwork>
        </figure>
      </section>

      <section title='"access_token" Syntax'>

        <figure>
          <preamble>
            The <spanx style='verb'>access_token</spanx> element is defined in
            Sections <xref target="implicit-authz-resp" format="counter"/> and
            <xref target="token-response" format="counter"/>:
          </preamble>
          <artwork><![CDATA[
  access-token = 1*VSCHAR
]]></artwork>
        </figure>
      </section>

      <section title='"token_type" Syntax'>

        <figure>
          <preamble>
            The <spanx style='verb'>token_type</spanx> element is defined in
            Sections <xref target="implicit-authz-resp" format="counter"/>,
            <xref target="token-response" format="counter"/>, and
            <xref target="new-types" format="counter"/>:
          </preamble>
          <artwork><![CDATA[
  token-type = type-name / URI-reference
  type-name  = 1*name-char
  name-char  = "-" / "." / "_" / DIGIT / ALPHA
]]></artwork>
        </figure>
      </section>

      <section title='"expires_in" Syntax'>

        <figure>
          <preamble>
            The <spanx style='verb'>expires_in</spanx> element is defined in
            Sections <xref target="implicit-authz-resp" format="counter"/> and
            <xref target="token-response" format="counter"/>:
          </preamble>
          <artwork><![CDATA[
  expires-in = 1*DIGIT
]]></artwork>
        </figure>
      </section>

      <section title='"username" Syntax'>

        <figure>
          <preamble>
            The <spanx style='verb'>username</spanx> element is defined in
            <xref target="password-tok-req"/>:
          </preamble>
          <artwork><![CDATA[
  username = *UNICODECHARNOCRLF
]]></artwork>
        </figure>
      </section>

      <section title='"password" Syntax'>

        <figure>
          <preamble>
            The <spanx style='verb'>password</spanx> element is defined in
            <xref target="password-tok-req"/>:
          </preamble>
          <artwork><![CDATA[
  password = *UNICODECHARNOCRLF
]]></artwork>
        </figure>
      </section>

      <section title='"refresh_token" Syntax'>

        <figure>
          <preamble>
            The <spanx style='verb'>refresh_token</spanx> element is defined in
            Sections <xref target="token-response" format="counter"/> and
            <xref target="token-refresh" format="counter"/>:
          </preamble>
          <artwork><![CDATA[
  refresh-token = 1*VSCHAR
]]></artwork>
        </figure>
      </section>

      <section title='Endpoint Parameter Syntax'>

        <figure>
          <preamble>
            The syntax for new endpoint parameters is defined in
            <xref target="endpoint-params"/>:
          </preamble>
          <artwork><![CDATA[
  param-name = 1*name-char
  name-char  = "-" / "." / "_" / DIGIT / ALPHA
]]></artwork>
        </figure>
      </section>

    </section>

    <section title="Use of application/x-www-form-urlencoded Media Type" anchor="urlencoded">


      <t>
        At the time of publication of this specification, the
        <spanx style='verb'>application/x-www-form-urlencoded</spanx>
        media type was defined in Section&nbsp;17.13.4 of
        <xref target='W3C.REC-html401-19991224'/> but not
        registered in the IANA MIME Media Types registry
        (&lt;http://www.iana.org/assignments/media-types&gt;).
        Furthermore, that definition is incomplete, as it does not
        consider non-US-ASCII characters.
      </t>
      <t>
        To address this shortcoming when generating payloads using
        this media type, names and values MUST be encoded using the
        UTF-8 character encoding scheme <xref target="RFC3629"/> first;
        the resulting octet sequence then needs to be further encoded using
        the escaping rules defined in <xref target='W3C.REC-html401-19991224'/>.
      </t>
      <t>
        When parsing data from a payload using this media type, the
        names and values resulting from reversing the name/value
        encoding consequently need to be treated as octet sequences,
        to be decoded using the UTF-8 character encoding scheme.
      </t>
      <t>
        For example, the value consisting of the six Unicode code points
        (1)&nbsp;U+0020 (SPACE), (2) U+0025 (PERCENT SIGN),
        (3)&nbsp;U+&wj;0026&nbsp;(AMPERSAND), (4) U+002B (PLUS SIGN),
        (5)&nbsp;U+&wj;00A3&nbsp;(POUND&nbsp;SIGN),
        and (6) U+20AC (EURO SIGN) would be encoded into the octet
        sequence below (using hexadecimal notation):
      </t>
      <figure><artwork><![CDATA[
  20 25 26 2B C2 A3 E2 82 AC
]]></artwork></figure>
      <t>
        and then represented in the payload as:
      </t>
      <figure><artwork><![CDATA[
  +%25%26%2B%C2%A3%E2%82%AC
]]></artwork></figure>
    </section>

    <section title='Acknowledgements'>
      <t>
        The initial OAuth 2.0 protocol specification was edited by David Recordon, based on two
        previous publications: the OAuth 1.0 community specification <xref target='RFC5849' />, and
        OAuth WRAP (OAuth Web Resource Authorization Profiles)
        <xref target='OAuth-WRAP' />. Eran Hammer then
   edited many of the intermediate drafts that evolved into this RFC.
        The Security Considerations section was drafted
        by Torsten Lodderstedt, Mark McGloin, Phil Hunt, Anthony Nadalin, and John Bradley.
        The section on use of the "application/x-www-form-urlencoded" media type
        was drafted by Julian Reschke.
        The ABNF section was drafted by Michael B. Jones.
      </t>
      <t>
        The OAuth 1.0 community specification was edited by Eran Hammer and authored by
        Mark Atwood, Dirk Balfanz, Darren Bounds, Richard M. Conlan, Blaine Cook, Leah Culver,
        Breno de Medeiros, Brian Eaton, Kellan Elliott-McCrea, Larry Halff, Eran Hammer,
        Ben Laurie, Chris Messina, John Panzer, Sam Quigley, David Recordon, Eran Sandler,
        Jonathan Sergent, Todd Sieling, Brian Slesinsky, and Andy Smith.
      </t>
      <t>
        The OAuth WRAP specification was edited by Dick Hardt and authored by Brian Eaton,
        Yaron Y. Goland, Dick Hardt, and Allen Tom.
      </t>
      <t>
        This specification is the work of the OAuth Working Group, which includes dozens of active
        and dedicated participants. In particular, the following individuals contributed ideas,
        feedback, and wording that shaped and formed the final specification:
      </t>
      <t>
        Michael Adams, Amanda Anganes, Andrew Arnott, Dirk Balfanz, Aiden Bell,
John Bradley, Marcos Caceres, Brian Campbell,
        Scott Cantor, Blaine Cook, Roger Crew, Leah Culver,
        Bill de hOra, Andre DeMarre, Brian Eaton, Wesley Eddy, Wolter Eldering, Brian Ellin, Igor Faynberg,
        George Fletcher, Tim Freeman, Luca Frosini, Evan Gilbert, Yaron Y. Goland, Brent Goldman,
        Kristoffer Gronowski, Eran Hammer, Dick Hardt, Justin Hart, Craig Heath, Phil Hunt, Michael B. Jones,
        Terry Jones, John Kemp, Mark Kent, Raffi Krikorian, Chasen Le Hara, Rasmus Lerdorf,
        Torsten Lodderstedt, Hui-Lan Lu, Casey Lucas, Paul Madsen, Alastair Mair, Eve Maler,
        James Manger, Mark McGloin, Laurence Miao, William Mills, Chuck Mortimore, Anthony Nadalin,
        Julian Reschke, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre,
        Marius Scurtescu, Naitik Shah, Luke Shepard, Vlad Skvortsov, Justin Smith, Haibin Song,
        Niv Steingarten, Christian Stuebner, Jeremy Suriel, Paul Tarjan, Christopher Thomas,
        Henry S. Thompson, Allen Tom, Franklin Tse, Nick Walker, Shane Weeden, and Skylar Woodward.
      </t>
      <t>
        This document was produced under the chairmanship of Blaine Cook, Peter Saint-Andre,
        Hannes Tschofenig, Barry Leiba, and Derek Atkins. The area directors included Lisa Dusseault,
        Peter Saint-Andre, and Stephen Farrell.
      </t>
    </section>

    <section title="翻訳者">
      <t>
        本仕様の翻訳は, <xref target='oidfj'>OpenIDファウンデーションジャパン</xref> <xref target='oidfj-trans'>翻訳・教育ワーキンググループ</xref>を主体として, 有志のメンバーによって行われました.
        質問や修正依頼などについては, <xref target='oidfj-github'>Githubレポジトリー</xref> にご連絡ください.
      </t>
      <t>
        <list style='symbols'>
          <t>
            Boku Kihara (Lepidum)
          </t>
          <t>
            Kazuki Shimizu (Lepidum)
          </t>
          <t>
            Masaru Kurahayashi (Yahoo! Japan)
          </t>
          <t>
            Naohiro Fujie (Itochu Techno Solutions)
          </t>
          <t>
            Noboru Kurumai (Fujitsu)
          </t>
          <t>
            Nov Matake
          </t>
          <t>
            Ryo Ito (mixi, Inc.)
          </t>
          <t>
            Tatsuya Katsuhara (NRI)
          </t>
          <t>
            Yusuke Kondo (Yahoo! Japan)
          </t>
        </list>
      </t>
    </section>
  </back>

</rfc>