draft-hammer-oauth-10.xml

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

<rfc category="info" ipr="trust200902" docName="draft-hammer-oauth-10">

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

  <front>
    
    <title abbrev="OAuth 1.0">The OAuth 1.0 Protocol</title>

    <author initials="E" surname="Hammer-Lahav" fullname="Eran Hammer-Lahav" role="editor">
      <organization />
      <address>
        <email>eran@hueniverse.com</email>
        <uri>http://hueniverse.com</uri>
      </address>
    </author>

    <date year="2010"/>

    <abstract>
      <t>
       OAuth は、リソースオーナー (別のクライアントやエンドユーザー) に代わって、サーバーリソースにアクセスするための方法を、クライアントに提供するものである。また、リダイレクトを利用することで、エンドユーザーはクライアントにユーザ名やパスワードを共有することなく、サーバーリソースへの第三者アクセスを認可することができる。
        <!--
        OAuth provides a method for clients to access server resources on behalf of a resource
        owner (such as a different client or an end-user). It also provides a process for end-users
        to authorize third-party access to their server resources without sharing their credentials
        (typically, a username and password pair), using user-agent redirections.
        -->
      </t>
    </abstract>

  </front>
  <middle>

    <section title="はじめに">
    <!-- section title="Introduction" -->
      <t>
        OAuth は、保護されたリソースに対するアクセス権限を第三者へ委譲する際の共通の問題について、その解決方法を必要としていたさまざまな Web サイトやインターネットサービスの開発者からなるコミュニティから生まれた。その後 OAuth は2007年10月に安定版の version 1.0 となり、2009年9月に改訂され <xref target="OAuth Core 1.0 Revision A" /> となった。
        <!--
        The OAuth protocol was originally created by a small community of web developers from a
        variety of websites and other Internet services, who wanted to solve the common problem of
        enabling delegated access to protected resources.  The resulting OAuth protocol was
        stabilized at version 1.0 in October 2007, revised in June 2009, and published as
        <xref target="OAuth Core 1.0 Revision A" />.
        -->
      </t>
      <t>
        この仕様書では改訂版 <xref target="OAuth Core 1.0 Revision A" /> を OAuth 1.0 として扱い、大幅な文書の明瞭化と同時に改訂後に指摘された誤字修正も行っている。なおこの仕様書の公開をもって、オリジナルの OAuth 仕様の執筆者達の手による OAuth 仕様策定権限は、コミュニティから IETF に移管される。
        <!--
        This specification provides an informational documentation of the OAuth 1.0 protocol as
        revised in <xref target="OAuth Core 1.0 Revision A" />, and includes several errata
        reported since that time, as well as numerous editorial clarifications. The publication
        of this specification represents the transfer of change control from the community to the
        IETF by the authors of the original work.
         -->
      </t>
      <t>
        従来のクライアント・サーバー型認証モデルでは、サーバー上のリソースにアクセスするためにクライアントは自身の認証情報を利用する。分散した Web サービスやクラウドコンピューティングの利用拡大により、ますます多くのサードパーティーアプリケーションがこれらのサーバー上リソースへのアクセス権を必要とすることになる。
        <!--
        In the traditional client-server authentication model, the client uses its credentials to
        access its resources hosted by the server. With the increasing use of distributed web
        services and cloud computing, third-party applications require access to these
        server-hosted resources.
        -->
      </t>
      <t>
        OAuth は従来のクライアント・サーバー型認証モデルに加え、3つめの役割「リソースオーナー」を導入する。OAuth モデルでは、クライアント (リソースオーナーではないが、リソースオーナーの代理として振る舞う) は、リソースオーナーが管理しながらもサーバーにホスティングされているリソースへのアクセス権を要求する。サーバーは、リソースオーナーの認可情報と同時に、リクエスト元であるクライアントの身元も検証することができる。
        <!--
        OAuth introduces a third role to the traditional client-server authentication model: the
        resource owner. In the OAuth model, the client (which is not the resource owner, but
        is acting on its behalf) requests access to resources controlled by the resource owner, but
        hosted by the server. In addition, OAuth allows the server to verify not only the resource
        owner authorization, but also the identity of the client making the request.
        -->
      </t>
      <t>
        OAuth はクライアントがリソースオーナー (異なるクライアントやエンドユーザーなど) の代理としてサーバーリソースにアクセスする方法を提供する。またエンドユーザーが自身の認証情報 (典型例: ユーザ名およびパスワード) を共有することなしに自身のサーバーリソースへのアクセスを許可する一連のプロセスも提供する。このプロセスではユーザーエージェントのリダイレクトを利用する。
        <!--
        OAuth provides a method for clients to access server resources on behalf of a resource
        owner (such as a different client or an end-user). It also provides a process for end-users
        to authorize third-party access to their server resources without sharing their credentials
        (typically, a username and password pair), using user-agent redirections.
        -->
      </t>
      <t>
        例として、ユーザ (リソースオーナー) がプリントサービス (クライアント) に、自身が写真共有サービス (サーバー) 上に保有するプライベートな写真へのアクセス権を与えることを考える。ここではユーザ名とパスワードはプリントサービスに提示しない。その代わりにユーザは写真共有サービス上で直接認証を行い、写真共有サービスがプリントサービスへの委譲専用のユーザー証明書を発行する。
        <!--
        For example, a web user (resource owner) can grant a printing service (client) access to
        her private photos stored at a photo sharing service (server), without sharing her
        username and password with the printing service. Instead, she authenticates directly with
        the photo sharing service which issues the printing service delegation-specific credentials.
        -->
      </t>
      <t>
        リソースアクセスのために、クライアントはまずはじめにリソースオーナーから許可を受ける必要がある。この許可情報はトークンと共有鍵の形で示される。トークンがあることでリソースオーナーはクライアントに自身の認証情報を共有する必要がなくなる。リソースオーナーの認証情報と異なり、トークンは限定的な用途でかつ有効期限付きで発行することが可能であり、個別に破棄することができる。
        <!--
        In order for the client to access resources, it first has to obtain permission from the
        resource owner. This permission is expressed in the form of a token and matching
        shared-secret. The purpose of the token is to make it unnecessary for the resource owner to
        share its credentials with the client. Unlike the resource owner credentials, tokens can be
        issued with a restricted scope and limited lifetime, and revoked independently.
        -->
      </t>
      <t>
        この仕様書は2つの部分からなる。前半部ではエンドユーザーがクライアントにリソースへのアクセス権を認可する際の、リダイレクトベースのユーザーエージェント処理について定義する。後半部では2セットのクレデンシャルを用いて認証済み HTTP <xref target="RFC2616" /> リクエストを行う方法を定義する。この2セットのクレデンシャルは、1つはリクエストを行っているクライアントを識別するために用いられ、もう1つはそのリクエストでクライアントが代理となるリソースオーナーを識別するために用いられる。
        <!--
        This specification consists of two parts. The first part defines a redirection-based
        user-agent process for end-users to authorize client access to their resources, by
        authenticating directly with the server and provisioning tokens to the client for use with
        the authentication method. The second part defines a method for making authenticated HTTP
        <xref target="RFC2616" /> requests using two sets of credentials, one identifying the
        client making the request, and a second identifying the resource owner on whose behalf the
        request is being made.
        -->
      </t>
      <t>
        OAuth を <xref target="RFC2616" /> 以外の転送プロトコル上で用いる方法については定義されていない。
        <!--
        The use of OAuth with any other transport protocol than <xref target="RFC2616" /> is
        undefined.
        -->
      </t>

      <section title="用語定義">
      <!-- section title="Terminology" -->
        <t>
          <list style="hanging" hangIndent="6">
            <t hangText="クライアント (client)">
              <vspace />
              <xref target="requests">OAuth 認証済みリクエスト</xref>を発行可能な HTTP クライアント (<xref target="RFC2616" /> 参照)
            </t>
            <!--
            <t hangText="client">
              <vspace />
              An HTTP client (per <xref target="RFC2616" />) capable of making
              <xref target="requests">OAuth-authenticated requests</xref>.
            </t>
            -->
            <t hangText="サーバー (server)">
              <vspace />
              <xref target="requests">OAuth 認証済みリクエスト</xref>を受入可能な HTTP サーバー (<xref target="RFC2616" /> 参照)
            </t>
            <!--
            <t hangText="server">
              <vspace />
              An HTTP server (per <xref target="RFC2616" />) capable of accepting
              <xref target="requests">OAuth-authenticated requests</xref>.
            </t>
            -->
            <t hangText="保護されたリソース (protected resource)">
              <vspace />
              アクセス制限下にあるリソースで、<xref target="requests">OAuth 認証済みリクエスト</xref>を用いて取得可能なもの。
            </t>
            <!--
            <t hangText="protected resource">
              <vspace />
              An access-restricted resource which can be obtained from the server using an
              <xref target="requests">OAuth-authenticated request</xref>.
            </t>
            -->
            <t hangText="リソースオーナー (resource owner)">
              <vspace />
              サーバーに対して自身の認証情報を用いて認証し、保護されたリソースへのアクセスおよびコントロールを行えるもの。
            </t>
            <!--
            <t hangText="resource owner">
              <vspace />
              An entity capable of accessing and controlling protected resources by using credentials
              to authenticate with the server.
            </t>
            -->
            <t hangText="クレデンシャル (credentials)">
              <vspace />
              ここでいうクレデンシャルとはユニークな識別子と共有鍵のペアを指す。OAuth では「クライアント」「テンポラリ」「トークン」の3種類のクレデンシャルが定義され、リクエストを行うクライアントの識別および認証、認可リクエスト、アクセス権受け渡しの際にそれぞれ用いられる。
            </t>
            <!--
            <t hangText="credentials">
              <vspace />
              Credentials are a pair of a unique identifier and a matching shared secret. OAuth
              defines three classes of credentials: client, temporary, and token, used to identify
              and authenticate the client making the request, the authorization request, and the
              access grant, respectively.
            </t>
            -->
            <t hangText="トークン (token)">
              <vspace />
              サーバーが発行するユニークな識別子。クライアントは認可要求を行ったもしくは認可を受けたリソースオーナーと、認証済みリクエストを結びつけるためにトークンを利用する。トークンには共有鍵がセットになっており、クライアントはトークン所有権およびリソースオーナーの代理権を証明するために共有鍵を用いる。
            </t>
            <!--
            <t hangText="token">
              <vspace />
              An unique identifier issued by the server and used by the client to associate
              authenticated requests with the resource owner whose authorization is requested or
              has been obtained by the client. Tokens have a matching shared-secret that is used
              by the client to establish its ownership of the token, and its authority to represent
              the resource owner.
            </t>
            -->
          </list>
        </t>
        <t>
          オリジナルのコミュニティ仕様書では多少異なる用語が用いられていた。それらはこの仕様書では以下のように表記されている。(左側がオリジナル仕様書)
          <!--
          The original community specification used a somewhat different terminology which maps to
          this specifications as follows (original community terms provided on left):
          -->
          
          <list style="hanging">
            <t hangText="Consumer">クライアント (client)</t>
            <t hangText="Service Provider">サーバー (server)</t>
            <t hangText="User">リソースオーナー (resource owner)</t>
            <t hangText="Consumer Key and Secret">クライアントクレデンシャル (client credentials)</t>
            <t hangText="Request Token and Secret">テンポラリクレデンシャル (temporary credentials)</t>
            <t hangText="Access Token and Secret">トークンクレデンシャル (token credentials)</t>
          </list>
          <!--
          <list style="hanging">
            <t hangText="Consumer:">client</t>
            <t hangText="Service Provider:">server</t>
            <t hangText="User:">resource owner</t>
            <t hangText="Consumer Key and Secret:">client credentials</t>
            <t hangText="Request Token and Secret:">temporary credentials</t>
            <t hangText="Access Token and Secret:">token credentials</t>
          </list>
          -->
        </t>
      </section>

      <section title="例">
      <!-- section title="Example" -->
        <t>
          Jane (リソースオーナー) が写真共有サイト 'photos.example.net' (サーバー) に休暇中の写真 (保護されたリソース) をアップロードしたものとする。彼女は 'printer.example.com' (クライアント) を使って写真を現像したい。通常であれば、Jane は 'photos.example.net' にユーザ名とパスワードを使ってログインするはずである。
        </t>
        <!--t>
          Jane (resource owner) has recently uploaded some private vacation photos (protected
          resources) to her photo sharing site 'photos.example.net' (server). She would like to use
          the 'printer.example.com' website (client) to print one of these photos. Typically, Jane
          signs-into 'photos.example.net' using her username and password.
        </t-->
        <t>
          しかし、Jane は写真を現像するためとはいえ 'printer.example.com' に対してユーザ名とパスワードを提示したくない。そこで 'printer.example.com' では、ユーザによりよいサービスを提供するため、事前に 'photos.example.net' の提供するクライアントクレデンシャルを取得している。
        <!--t>
          However, Jane does not wish to share her username and password with the 'printer.example.com'
          website, which needs to access the photo in order to print it. In order to provide its
          users with better service, 'printer.example.com' has signed-up for a set of 'photos.example.net'
          client credentials ahead of time:
        -->

          <list style="hanging" hangIndent="6">
            <t hangText="クライアント識別子">
              <vspace />
              dpf43f3p2l4k3l03
            </t>
            <!--t hangText="Client Identifier">
              <vspace />
              dpf43f3p2l4k3l03
            </t-->
            <t hangText="クライアント共有鍵">
              <vspace />
              kd94hf93k423kf44
            </t>
            <!--t hangText="Client Shared-Secret:">
              <vspace />
              kd94hf93k423kf44
            </t-->
          </list>

          'printer.example.com' はまた、'photos.example.net' の API ドキュメントに記載された <spanx style="verb">HMAC-SHA1</spanx> 署名方式を用いたプロトコルエンドポイントを使うよう、アプリケーションを設定済みである。
          <!--
          The 'printer.example.com' website has also configured its application to use the protocol
          endpoints listed in the 'photos.example.net' API documentation, which use the
          <spanx style="verb">HMAC-SHA1</spanx> signature method:
          -->

          <list style="hanging" hangIndent="6">
            <t hangText="テンポラリクレデンシャルリクエスト">
              <vspace />
              https://photos.example.net/initiate
            </t>
            <!--t hangText="Temporary Credential Request">
              <vspace />
              https://photos.example.net/initiate
            </t-->
            <t hangText="リソースオーナー認可URI">
              <vspace />
              https://photos.example.net/authorize
            </t>
            <!--t hangText="Resource Owner Authorization URI:">
              <vspace />
              https://photos.example.net/authorize
            </t-->
            <t hangText="トークンリクエストURI">
              <vspace />
              https://photos.example.net/token
            </t>
            <!--t hangText="Token Request URI:">
              <vspace />
              https://photos.example.net/token
            </t-->
          </list>
        </t>
        <t>
          'printer.example.com' が Jane に写真へのアクセス許可を求めるには、まず代理でのリクエストを認識するため、'photos.example.net' に対し、テンポラリクレデンシャルの発行を求めなければならない。これを行うため、クライアントは下記のような HTTPS <xref target="RFC2818" /> リクエストをサーバーに送信する。
        </t>
        <!--t>
          Before 'printer.example.com' can ask Jane to grant it access to the photos, it must
          first establish a set of temporary credentials with 'photos.example.net' to identify
          the delegation request. To do so, the client sends the following HTTPS
          <xref target="RFC2818" /> request to the server:
        </t-->
        <figure>
          <artwork xml:space="preserve"><![CDATA[
  POST /initiate HTTP/1.1
  Host: photos.example.net
  Authorization: OAuth realm="Photos",
     oauth_consumer_key="dpf43f3p2l4k3l03",
     oauth_signature_method="HMAC-SHA1",
     oauth_timestamp="137131200",
     oauth_nonce="wIjqoS",
     oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
     oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"
]]>
          </artwork>
        </figure>
        <t>
          サーバーはリクエストの正当性を確認し、HTTP レスポンスボディ (改行は掲載上の都合による) にテンポラリクレデンシャルを持たせた応答を行う。
        </t>
        <!--t>
          The server validates the request and replies with a set of temporary credentials in the
          body of the HTTP response (line breaks are for display purposes only):
        </t-->
        <figure>
          <artwork xml:space="preserve"><![CDATA[
  HTTP/1.1 200 OK
  Content-Type: application/x-www-form-urlencoded

  oauth_token=hh5s93j4hdidpola&oauth_token_secret=hdhd0244k9j7ao03&
  oauth_callback_confirmed=true
]]>
          </artwork>
        </figure>
        <t>
          クライアントは Jane から彼女のプライベートな写真へのアクセスに関して承認を得るため、彼女のユーザーエージェントをサーバーのリソースオーナー認可エンドポイントにリダイレクトする。
        </t>
        <!--t>
          The client redirects Jane's user-agent to the server's Resource Owner Authorization
          endpoint to obtain Jane's approval for accessing her private photos:
        </t-->
        <figure>
          <artwork xml:space="preserve"><![CDATA[
  https://photos.example.net/authorize?oauth_token=hh5s93j4hdidpola
]]>
        </artwork>
        </figure>
        <t>
          サーバーは Jane にユーザ名とパスワードを使ったログインを要求し、成功した場合は、'printer.example.com' が写真にアクセスしてよいか尋ねる。Jane が承認を行うと、ユーザーエージェントは、先のリクエスト (改行は掲載上の都合による) で提供されたコールバック URI にクライアントをリダイレクトする。
        </t>
        <!--t>
          The server requests Jane to sign-in using her username and password and if successful,
          asks her to approve granting 'printer.example.com' access to her private photos. Jane
          approves the request and her user-agent is redirected to the callback URI provided by
          the client in the previous request (line breaks are for display purposes only):
        </t-->
        <figure>
          <artwork xml:space="preserve"><![CDATA[
  http://printer.example.com/ready?
  oauth_token=hh5s93j4hdidpola&oauth_verifier=hfdp7dh39dks9884
]]>
          </artwork>
        </figure>
        <t>
          コールバックリクエストは、Jane の認可プロセス完了をクライアントに通知する。クライアントはその後、テンポラリクレデンシャルを用いて、(安全な TLS チャネル上で) トークンクレデンシャルを要求する。
        </t>
        <!--t>
          The callback request informs the client that Jane completed the authorization process.
          The client then requests a set of token credentials using its temporary credentials
          (over a secure TLS channel):
        </t-->
        <figure>
          <artwork xml:space="preserve"><![CDATA[
  POST /token HTTP/1.1
  Host: photos.example.net
  Authorization: OAuth realm="Photos",
     oauth_consumer_key="dpf43f3p2l4k3l03",
     oauth_token="hh5s93j4hdidpola",
     oauth_signature_method="HMAC-SHA1",
     oauth_timestamp="137131201",
     oauth_nonce="walatlh",
     oauth_verifier="hfdp7dh39dks9884",
     oauth_signature="gKgrFCywp7rO0OXSjdot%2FIHF7IU%3D"
]]>
          </artwork>
        </figure>
        <t>
          サーバーはリクエストの正当性を確認し、HTTP レスポンスボディにトークンクレデンシャルを持たせた応答を行う。
        </t>
        <!--t>
          The server validates the request and replies with a set of token credentials in the body
          of the HTTP response:
        </t-->
        <figure>
          <artwork xml:space="preserve"><![CDATA[
  HTTP/1.1 200 OK
  Content-Type: application/x-www-form-urlencoded
  
  oauth_token=nnch734d00sl2jdk&oauth_token_secret=pfkkdhi9sl3r4s00
]]>
          </artwork>
        </figure>
        <t>
          トークンクレデンシャルの取得により、クライアントがプライベートな写真を要求するための準備は整う。
        </t>
        <!--t>
          With a set of token credentials, the client is now ready to request the private photo:
        </t-->
        <figure>
          <artwork xml:space="preserve"><![CDATA[
  GET /photos?file=vacation.jpg&size=original HTTP/1.1
  Host: photos.example.net
  Authorization: OAuth realm="Photos",
     oauth_consumer_key="dpf43f3p2l4k3l03",
     oauth_token="nnch734d00sl2jdk",
     oauth_signature_method="HMAC-SHA1",
     oauth_timestamp="137131202",
     oauth_nonce="chapoH",
     oauth_signature="MdpQcU8iPSUjWoN%2FUDMsK2sui9I%3D"
]]>
          </artwork>
        </figure>
        <t>
          'photos.example.net' サーバーはリクエストの正当性を確認し、要求された写真を返す。'printer.example.com' は Jane の認可の有効期間が終了するか、Jane がアクセスを無効にするまで、同じトークンクレデンシャルを使って、Jane の写真にアクセスし続けることができる。
        </t>
        <!--t>
          The 'photos.example.net' server validates the request and responds with the requested
          photo. 'printer.example.com' is able to continue accessing Jane's private photos using
          the same set of token credentials for the duration of Jane's authorization, or until
          Jane revokes access.
        </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" /> で述べられている通りに解釈されるべきものである。
        </t>
        <!--t>
          The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
          "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
          <xref target="RFC2119" />.
        </t-->
      </section>
      
    </section>

    <section title="リダイレクション・ベースの認可" anchor="redirect_workflow">
    <!--section title="Redirection-Based Authorization" anchor="redirect_workflow"-->
      <t>
        OAuth はリソースオーナーがクライアントに認可を与える際にトークンを用いる。一般的にトークンクレデンシャルの発行は、リソースオーナーの要求を受けてサーバーが行う。その際、サーバーはトークン発行前にリソースオーナーのアイデンティティを (通常はユーザー名とパスワードを使用して) 認証する。
      </t>
      <!--t>
        OAuth uses tokens to represent the authorization granted to the client by the resource
        owner. Typically, token credentials are issued by the server at the resource owner's
        request, after authenticating the resource owner's identity (usually using a username and
        password).
      </t-->
      <t>
        サーバーがトークンクレデンシャルの提供を行う方法は複数存在する。このセクションでは、HTTP リダイレクションとリソースオーナーのユーザーエージェントを使った、ひとつの方法を定義している。このリダイレクション・ベースの認可方法には、3つのステップがある。
        <list style="numbers">
          <t>
            クライアントは、サーバーから (識別子と共有鍵の形式で) テンポラリクレデンシャルを取得する。テンポラリクレデンシャルは、認可プロセス中のアクセス要求を識別するために利用される。
          </t>
          <t>
            リソースオーナーは、クライアントからの (テンポラリクレデンシャルによって識別される) アクセス要求をサーバーが許可することについて、承認を行う。
          </t>
          <t>
            クライアントはテンポラリクレデンシャルを用い、サーバーに対してトークンクレデンシャルをリクエストする。これにより、リソースオーナーの保護されたリソースへのアクセスが可能になる。
          </t>
        </list>
      </t>
      <!--t>
        There are many ways in which a server can facilitate the provisioning of token credentials.
        This section defines one such way, using HTTP redirections and the resource owner's
        user-agent. This redirection-based authorization method includes three steps:

        <list style="numbers">
          <t>
            The client obtains a set of temporary credentials from the server (in the form of an
            identifier and shared-secret). The temporary credentials are used to identify the
            access request throughout the authorization process.
          </t>
          <t>
            The resource owner authorizes the server to grant the client's access request
            (identified by the temporary credentials).
          </t>
          <t>
            The client uses the temporary credentials to request a set of token credentials from
            the server, which will enable it to access the resource owner's protected resources.
          </t>
        </list>
      </t-->
      <t>
        サーバーは、トークンクレデンシャル発行後、テンポラリクレデンシャルを破棄しなければならない (MUST)。テンポラリクレデンシャルには有効期限を設けることを推奨する (RECOMMENDED)。サーバーは、クライアントに対して発行済のトークンクレデンシャルを、リソースオーナーが破棄できるようにするべきである (SHOULD)。
      </t>
      <!--t>
        The server MUST revoke the temporary credentials after being used once to obtain the token
        credentials. It is RECOMMENDED that the temporary credentials have a limited lifetime.
        Servers SHOULD enable resource owners to revoke token credentials after they have been
        issued to clients.
      </t-->
      <t>
        クライアントがこれらのステップを行えるように、サーバーは以下の3つのエンドポイント URI を知らせる必要がある。

        <list style="hanging" hangIndent="6">
          <t hangText="テンポラリクレデンシャルリクエスト">
            <vspace />
            テンポラリクレデンシャルを取得するため、クライアントに用いられるエンドポイント。(<xref target="auth_step1" /> 参照)
          </t>
          <t hangText="リソースオーナー認可">
            <vspace />
            認可を与えるため、リソースオーナーがリダイレクトされるエンドポイント。(<xref target="auth_step2" /> 参照)
          </t>
          <t hangText="トークンリクエスト">
            <vspace />
            テンポラリクレデンシャルを使ってトークンクレデンシャルを要求するため、クライアントに用いられるエンドポイント。(<xref target="auth_step3" /> 参照)
          </t>
        </list>
      </t>
      <!--t>
        In order for the client to perform these steps, the server needs to advertise the URIs of
        the following three endpoints:

        <list style="hanging" hangIndent="6">
          <t hangText="Temporary Credential Request">
            <vspace />
            The endpoint used by the client to obtain a set of temporary credentials as described
            in <xref target="auth_step1" />.
          </t>
          <t hangText="Resource Owner Authorization">
            <vspace />
            The endpoint to which the resource owner is redirected to grant authorization as
            described in <xref target="auth_step2" />.
          </t>
          <t hangText="Token Request">
            <vspace />
            The endpoint used by the client to request a set of token credentials using the
            set of temporary credentials as described in <xref target="auth_step3" />.
          </t>
        </list>
      </t-->
      <t>
        通達された3つの URI は、クエリー要素を含んでもよい (MAY)。(<xref target="RFC3986" /> 3節参照) ただし、エンドポイント利用時に URI に追加されるプロトコルパラメータとの競合を防ぐため、クエリーには <spanx style="verb">oauth_</spanx> で始まるパラメータを含んではならない (MUST NOT)。
      </t>
      <!--t>
        The three URIs advertised by the server MAY include a query component as defined by
        <xref target="RFC3986" /> section 3, but if present, the query MUST NOT contain any
        parameters beginning with the <spanx style="verb">oauth_</spanx> prefix, to avoid conflicts
        with the protocol parameters added to the URIs when used.
      </t-->
      <t>
        サーバーが3つのエンドポイントを通達、ドキュメント化する方法は、この仕様の範囲外である。クライアントは、本仕様で未定義な、トークンのサイズや他のサーバーで生成された値について、仮定をすべきではない。プロトコルパラメータは、転送時にエンコードが必要な値を含む場合がある (MAY)。クライアントとサーバーは、値の範囲を仮定してはならない。
      </t>
      <!--t>
        The methods in which the server advertises and documents its three endpoints are beyond the
        scope of this specification. Clients should avoid making assumptions about the size of
        tokens and other server-generated values, which are left undefined by this specification.
        In addition, protocol parameters MAY include values which require encoding when
        transmitted. Clients and servers should not make assumptions about the possible range of
        their values.
      </t-->

      <section title="テンポラリクレデンシャル" anchor="auth_step1">
      <!--section title="Temporary Credentials" anchor="auth_step1"-->
        <t>
          クライアントは、テンポラリクレデンシャルリクエストのエンドポイントに、<xref target="requests">認証済みの</xref> HTTP <spanx style="verb">POST</spanx> リクエストを行うことによって、サーバーからテンポラリクレデンシャルを取得する (サーバーが他の HTTP リクエストメソッドを推奨する場合はこの限りではない)。クライアントは、次の必須 (REQUIRED) パラメータをリクエストに加えることにより、(同じメソッドを利用して、他のパラメータに加えることで) リクエスト URI を構成する。
          <list style="hanging" hangIndent="6">
            <t hangText="oauth_callback">
              リソースオーナー認証手順 (<xref target="auth_step2" />) 完了時に、サーバーがリソースオーナーをリダイレクトさせる絶対 URI。もしクライアントがコールバックを受け取ることができない、もしくはコールバック URI が他の手段を介して確立されたなら、このパラメータを使用しないことを示すために <spanx style="verb">oob</spanx> (大文字小文字を区別) をセットしなければならない (MUST)。
            </t>
            <t hangText="サーバーは、追加パラメータを指定してもよい (MAY)。">
            </t>
          </list>
        </t>
        <!--t>
          The client obtains a set of temporary credentials from the server by making an
          <xref target="requests">authenticated</xref> HTTP <spanx style="verb">POST</spanx>
          request to the Temporary Credential Request endpoint (unless the server advertises
          another HTTP request method for the client to use). The client constructs a request URI
          by adding the following REQUIRED parameter to the request (in addition to the other
          protocol parameters, using the same parameter transmission method):

          <list style="hanging" hangIndent="6">
            <t hangText="oauth_callback:">
              An absolute URI to which the server will redirect the resource owner back when the
              Resource Owner Authorization step (<xref target="auth_step2" />) is completed. If the
              client is unable to receive callbacks or a callback URI has been established via other
              means, the parameter value MUST be set to <spanx style="verb">oob</spanx> (case sensitive),
              to indicate an out-of-band configuration.
            </t>
            <t hangText="Servers MAY specify additional parameters.">
            </t>
          </list>
        </t-->
        <t>
          クライアントは、クライアントクレデンシャルのみを使用して認証要求を行う。クライアントは、空の oauth_token パラメータをリクエストから省略してもよい (MAY)。またその場合は、トークンシークレットパラメータとして、空文字を使用しなければならない (MUST)。
        </t>
        <!--t>
          When making the request, the client authenticates using only the client credentials. The
          client MAY omit the empty <spanx style="verb">oauth_token</spanx> protocol parameter
          from the request and MUST use the empty string as the token secret value.
        </t-->
        <t>
          結果は HTTP レスポンス中にプレーンテキスト形式のクレデンシャルとして返されるため、サーバーは TLS や SSL などのトランスポート層のメカニズム (もしくはそれらに相当するセキュアチャネル) を用いなければならない (MUST)。
        </t>
        <!--t>
          Since the request results in the transmission of plain text credentials in the HTTP
          response, the server MUST require the use of a transport-layer mechanisms such as TLS
          or SSL (or a secure channel with equivalent protections).
        </t-->
        <figure>
          <preamble>
            たとえば、クライアントは以下のような HTTPS リクエストを行う。
          </preamble>
          <!--preamble>
            For example, the client makes the following HTTPS request:
          </preamble-->
          <artwork xml:space="preserve"><![CDATA[
  POST /request_temp_credentials HTTP/1.1
  Host: server.example.com
  Authorization: OAuth realm="Example",
     oauth_consumer_key="jd83jd92dhsh93js",
     oauth_signature_method="PLAINTEXT",
     oauth_callback="http%3A%2F%2Fclient.example.net%2Fcb%3Fx%3D1",
     oauth_signature="ja893SD9%26"
]]>
          </artwork>
        </figure>
        <t>
          サーバーは、必ずリクエストを<xref target="verify_request">検証</xref>しなければならない (MUST)。リクエストが有効な場合、サーバーはクライアントに (識別子と共有鍵の形式で) テンポラリクレデンシャルを返す。テンポラリクレデンシャルは、ステータスコード 200 (OK) とともに、レスポンスボディーに <xref target="W3C.REC-html40-19980424" /> で定義された <spanx style="verb">application/x-www-form-urlencoded</spanx> 形式で含められる。
        </t>
        <!--t>
          The server MUST <xref target="verify_request">verify</xref> the request and if valid,
          respond back to the client with a set of temporary credentials (in the form of an
          identifier and shared-secret). The temporary credentials are included in the HTTP
          response body using the <spanx style="verb">application/x-www-form-urlencoded</spanx>
          content type as defined by <xref target="W3C.REC-html40-19980424" /> with a 200 status
          code (OK).
        </t-->
        <t>
          レスポンスには次の必須 (REQUIRED) パラメータが含まれる。

          <list style="hanging" hangIndent="6">
            <t hangText="oauth_token">
              <vspace />
              テンポラリクレデンシャルの識別子
            </t>
            <t hangText="oauth_token_secret">
              <vspace />
              テンポラリクレデンシャルの共有鍵
            </t>
            <t hangText="oauth_callback_confirmed">
              必ず存在しなければならない (MUST)、かつ <spanx style="verb">true</spanx> に設定する。このパラメータは、以前のバージョンと区別するために使用される。
            </t>
          </list>
        </t>
        <!--t>
          The response contains the following REQUIRED parameters:

          <list style="hanging" hangIndent="6">
            <t hangText="oauth_token">
              <vspace />
              The temporary credentials identifier.
            </t>
            <t hangText="oauth_token_secret">
              <vspace />
              The temporary credentials shared-secret.
            </t>
            <t hangText="oauth_callback_confirmed:">
              MUST be present and set to <spanx style="verb">true</spanx>. The parameter is used
              to differentiate from previous versions of the protocol.
            </t>
          </list>
        </t-->
        <t>
          パラメータ名に 'token' が含まれていても、このクレデンシャルはトークンクレデンシャルではないが、次の2つのステップで、トークンクレデンシャルと同様の使い方がされることに注意。
        </t>
        <!--t>
          Note that even though the parameter names include the term 'token', these credentials are
          not token credentials, but are used in the next two steps in a similar manner to token
          credentials.
        </t-->
        <figure>
          <preamble>
            例 (改行は掲載上の都合による)
          </preamble>
          <!--preamble>
            For example (line breaks are for display purposes only):
          </preamble-->
          <artwork xml:space="preserve"><![CDATA[
  HTTP/1.1 200 OK
  Content-Type: application/x-www-form-urlencoded

  oauth_token=hdk48Djdsa&oauth_token_secret=xyz4992k83j47x0b&
  oauth_callback_confirmed=true
]]>
          </artwork>
        </figure>
      </section>

      <section title="リソースオーナー認可" anchor="auth_step2">
      <!-- section title="Resource Owner Authorization" anchor="auth_step2" -->
        <t>
          クライアントは、サーバーにトークンクレデンシャルを要求する前に、ユーザをサーバーに移動させて要求に対する認可を得なければならない (MUST)。クライアントはリソースオーナー認可エンドポイント URI に以下の必須 (REQUIRED) クエリーパラメータを追加して、リクエスト URI を構成する。
          <!--
          Before the client requests a set of token credentials from the server, it MUST send
          the user to the server to authorize the request. The client constructs a request URI by
          adding the following REQUIRED query parameter to the Resource Owner Authorization
          endpoint URI:
          -->

          <list style="hanging" hangIndent="6">
            <t hangText="oauth_token">
              <vspace />
              <xref target="auth_step1" />で <spanx style="verb">oauth_token</spanx> パラメータの値として得られるテンポラリクレデンシャルの識別子。サーバーはこのパラメータを任意とすることもできるが、その場合はリソースオーナーの識別子を示す代替手段を提供しなければならない (MUST)。
              <!--
              The temporary credentials identifier obtained in <xref target="auth_step1" />
              in the <spanx style="verb">oauth_token</spanx> parameter. Servers MAY declare this
              parameter as OPTIONAL, in which case they MUST provide a way for the resource owner
              to indicate the identifier through other means.
              -->
            </t>
            <t hangText="サーバーはこの他にもパラメータを指定することもできる (MAY)。">
            <!-- t hangText="Servers MAY specify additional parameters." -->
            </t>
          </list>
        </t>
        <t>
          クライアントは、HTTP リダイレクトレスポンスもしくはリソースオーナーのユーザーエージェントがサポートする何らかの代替手段を用いて、リソースオーナーを前述で構成された URI にリダイレクトさせる。このリクエストでは HTTP <spanx style="verb">GET</spanx> メソッドを用いなければならない (MUST)。
          <!--
          The client directs the resource owner to the constructed URI using an HTTP redirection
          response, or by other means available to it via the resource owner's user-agent. The
          request MUST use the HTTP <spanx style="verb">GET</spanx> method.
          -->
        </t>
        <figure>
          <preamble>
            例: クライアントはリソースオーナーのユーザーエージェントをリダイレクトさせ、以下の HTTPS リクエストを実行させる。
            <!--
            For example, the client redirects the resource owner's user-agent to make the following
            HTTPS request:
            -->
          </preamble>
          <artwork xml:space="preserve"><![CDATA[
  GET /authorize_access?oauth_token=hdk48Djdsa HTTP/1.1
  Host: server.example.com
]]>
          </artwork>
        </figure>
        <t>
          サーバーの認可リクエストの処理方法については、TLS や SSL などのセキュアチャネルの利用有無とともにこの仕様の範囲外であるが、サーバーはまず最初にリソースオーナーのアイデンティティを検証しなければならない (MUST)。
          <!--
          The way in which the server handles the authorization request, including whether it uses
          a secure channel such as TLS/SSL is beyond the scope of this specification. However, the
          server MUST first verify the identity of the resource owner.
          -->
        </t>
        <t>
          リソースオーナーに要求されたアクセス権の認可を求める際、サーバーはアクセス権を要求しているクライアントの情報をリソースオーナーに提示するべきである (SHOULD)。その際はクライアント識別子と関連付けられたテンポラリクレデンシャルを利用する。このような情報を表示する際、サーバーはその情報が検証済みかどうか明示するべきである (SHOULD)。
          <!--
          When asking the resource owner to authorize the requested access, the server SHOULD
          present to the resource owner information about the client requesting access based on the
          association of the temporary credentials with the client identity. When displaying any
          such information, the server SHOULD indicate if the information has been verified.
          -->
        </t>
        <t>
          リソースオーナーから認可の可否を受け取った後、コールバック URI が <spanx style="verb">oauth_callback</spanx> パラメータもしくはその他の方法によって提供されている場合、サーバーはリソースオーナーをそのコールバック URI にリダイレクトさせる。
          <!--
          After receiving an authorization decision from the resource owner, the server redirects
          the resource owner to the callback URI if one was provided in the
          <spanx style="verb">oauth_callback</spanx> parameter or by other means.
          -->
        </t>
        <t>
          アクセス権を認可したリソースオーナーが、クライアントに戻されたリソースオーナーと同一であることを確認するため、サーバーは検証コードを生成しなければならない (MUST)。検証コードは推測困難な値であり、リソースオーナーを通じてクライアントに渡され、リソースオーナー認可プロセス完了のために必須となる (REQUIRED)。サーバーはコールバック URI のクエリーパラメータに以下の必須パラメータを追加して、リクエスト URI を構成する。
          <!--
          To make sure that the resource owner granting access is the same resource owner returning
          back to the client to complete the process, the server MUST generate a verification code:
          an unguessable value passed to the client via the resource owner and REQUIRED to complete
          the process. The server constructs the request URI by adding the following REQUIRED
          parameters to the callback URI query component:
          -->

          <list style="hanging" hangIndent="6">
            <t hangText="oauth_token">
              クライアントから受け取ったテンポラリクレデンシャルの識別子。
              <vspace />
              <!--
              The temporary credentials identifier received from the client.
              -->
            </t>
            <t hangText="oauth_verifier">
              <vspace />
              検証コード。
              <!--
              The verification code.
              -->
            </t>
          </list>

          コールバック URI が既にクエリー要素を含む場合、サーバーは既存のクエリーの後ろに OAuth パラメータを追加しなければならない (MUST)。
          <!--
          If the callback URI already includes a query component, the server MUST append the
          OAuth parameters to the end of the existing query.
          -->
        </t>
        <figure>
          <preamble>
            例: サーバーはリソースオーナーのユーザーエージェントをリダイレクトさせ、以下の HTTP リクエストを実行させる。
            <!--
            For example, the server redirects the resource owner's user-agent to make the following
            HTTP request:
            -->
          </preamble>
          <artwork xml:space="preserve"><![CDATA[
  GET /cb?x=1&oauth_token=hdk48Djdsa&oauth_verifier=473f82d3 HTTP/1.1
  Host: client.example.net
]]>
          </artwork>
        </figure>
        <t>
          クライアントがコールバック URI を提示しない場合、サーバーは検証コードを表示し、リソースオーナーに対して手動でクライアントに認可処理の完了を伝えるよう指示すべきである (SHOULD)。クライアントが何らかの制約を持つデバイス上で動作していることを把握している場合、サーバーは検証コードを手入力に適した形式で提供すべきである (SHOULD)。
          <!--
          If the client did not provide a callback URI, the server SHOULD display the value of the
          verification code, and instruct the resource owner to manually inform the client that
          authorization is completed. If the server knows a client to be running on a limited device
          it SHOULD ensure that the verifier value is suitable for manual entry.
          -->
        </t>
      </section>

      <section title="トークンクレデンシャル" anchor="auth_step3">
      <!-- section title="Token Credentials" anchor="auth_step3" -->
        <t>
          クライアントは<xref target="requests">認証済み</xref> HTTP <spanx style="verb">POST</spanx> リクエストをトークンリクエストエンドポイントに送信し、サーバーからトークンクレデンシャルを取得する。(サーバーが他の HTTP リクエストメソッドを推奨する場合はこの限りではない) クライアントは (同じフィールドに格納される他プロトコルのパラメータに加え) 以下の必須 (REQUIRED) パラメータをリクエストに追加してリクエスト URI を構成する。
          <!--
          The client obtains a set of token credentials from the server by making an
          <xref target="requests">authenticated</xref> HTTP <spanx style="verb">POST</spanx>
          request to the Token Request endpoint (unless the server advertises another HTTP
          request method for the client to use). The client constructs a request URI by adding the
          following REQUIRED parameter to the request (in addition to the other protocol
          parameters, using the same parameter transmission method):
          -->

          <list style="hanging" hangIndent="6">
            <t hangText="oauth_verifier">
              <vspace />
              前ステップでサーバーから受け取った検証コード。
              <!--
              The verification code received from the server in the previous step.
              -->
            </t>
          </list>
        </t>
        <t>
          リクエストを行う際、クライアントはテンポラリクレデンシャル同様クライアントクレデンシャルを用いて認証する。テンポラリクレデンシャルは、認証済みリクエスト中でトークンクレデンシャルの代わりに用いられ、<spanx style="verb">oauth_token</spanx> パラメータの値として渡される。
          <!--
          When making the request, the client authenticates using the client credentials as well as
          the temporary credentials. The temporary credentials are used as a substitute for token
          credentials in the authenticated request and transmitted using the
          <spanx style="verb">oauth_token</spanx> parameter.
          -->
        </t>
        <t>
          リクエスト結果は HTTP レスポンス中のプレーンテキストとして返されるため、サーバーは TLS や SSL などのトランスポート層のメカニズム (もしくはそれらに相当するセキュアチャネル) を用いなければならない (MUST)。
          <!--
          Since the request results in the transmission of plain text credentials in the HTTP
          response, the server MUST require the use of a transport-layer mechanisms such as TLS
          or SSL (or a secure channel with equivalent protections).
          -->
        </t>
        <figure>
          <preamble>
            例: クライアントは以下の HTTPS リクエストを行う。
            <!--
            For example, the client makes the following HTTPS request:
            -->
          </preamble>
          <artwork xml:space="preserve"><![CDATA[
  POST /request_token HTTP/1.1
  Host: server.example.com
  Authorization: OAuth realm="Example",
     oauth_consumer_key="jd83jd92dhsh93js",
     oauth_token="hdk48Djdsa",
     oauth_signature_method="PLAINTEXT",
     oauth_verifier="473f82d3",
     oauth_signature="ja893SD9%26xyz4992k83j47x0b"
]]>
          </artwork>
        </figure>
        <t>
          サーバーはリクエストの妥当性を<xref target="verify_request">検証</xref>し、リソースオーナーがクライアントにトークンクレデンシャルを提供することを認可していることを確認し、テンポラリクレデンシャルが期限切れおよび使用済みでないことを確認しなければならない (MUST)。サーバーはさらにクライアントから受け取った検証コードも検証しなければならない (MUST)。リクエストが有効で認可済みの場合は、ステータスコード 200 (OK) とともにレスポンスボディーに <xref target="W3C.REC-html40-19980424" /> で定義された <spanx style="verb">application/x-www-form-urlencoded</spanx> 形式でトークンクレデンシャルを含める。
          <!--
          The server MUST <xref target="verify_request">verify</xref> the validity of the request,
          ensure that the resource owner has authorized the provisioning of token credentials to
          the client, and ensure that the temporary credentials have not expired or been used
          before. The server MUST also verify the verification code received from the client. If
          the request is valid and authorized, the token credentials are included in the HTTP
          response body using the <spanx style="verb">application/x-www-form-urlencoded</spanx>
          content type as defined by <xref target="W3C.REC-html40-19980424" /> with a 200 status
          code (OK).
          -->
        </t>
        <t>
          レスポンスは以下の必須 (REQUIRED) パラメータを含む。
          <!--
          The response contains the following REQUIRED parameters:
          -->

          <list style="hanging" hangIndent="6">
            <t hangText="oauth_token">
              <vspace />
              トークン識別子
              <!--
              The token identifier.
              -->
            </t>
            <t hangText="oauth_token_secret">
              <vspace />
              トークン共有鍵
              <!--
              The token shared-secret.
              -->
            </t>
          </list>
        </t>
        <figure>
          <preamble>
            例:
            <!--
            For example:
            -->
          </preamble>
          <artwork xml:space="preserve"><![CDATA[
  HTTP/1.1 200 OK
  Content-Type: application/x-www-form-urlencoded
  
  oauth_token=j49ddk933skd9dks&oauth_token_secret=ll399dj47dskfjdk
]]>
          </artwork>
        </figure>
        <t>
          サーバーはスコープ、有効期間、およびリソースオーナーが承認したその他の属性を保持し、クライアントが発行済トークンクレデンシャルを用いてリクエストを行う際にそれらの制限を実施しなければならない。
          <!--
          The server must retain the scope, duration, and other attributes approved by the resource
          owner, and enforce these restrictions when receiving a client request made with the token
          credentials issued.
          -->
        </t>
        <t>
          ひとたびトークンクレデンシャルを受け取ると、クライアントはリソースオーナーの代理として、<xref target="requests">認証済みリクエスト</xref>により保護されたリソースにアクセスし続けることができる。その際、取得したトークンクレデンシャルとともにクライアントクレデンシャルを用いる。
          <!--
          Once the client receives and stores the token credentials, it can proceed to access
          protected resources on behalf of the resource owner by making
          <xref target="requests">authenticated requests</xref> using the client credentials
          together with the token credentials received.
          -->
        </t>
      </section>

    </section>
    
    <section title="認証済みリクエスト" anchor="requests">
    <!-- section title="Authenticated Requests" anchor="requests" -->
      <t>
        クライアントは <xref target="RFC2617" /> で定義されている HTTP 認証メソッドにより、認証済み HTTP リクエストを行うことができる。これらのメソッドを使うクライアントは、クレデンシャル (ユーザ名とパスワード等) を使うことで、保護されたリソースへのアクセスが可能となり、サーバーはその権限の妥当性を検証することができる。代理リクエストとしてこれらのメソッドを利用する場合、クライアントはリソースオーナーの役割を担うものと仮定される必要がある。
      </t>
      <!--t>
        The HTTP authentication methods defined by <xref target="RFC2617" />, enable clients
        to make authenticated HTTP requests. Clients using these methods gain access to protected
        resources by using their credentials (typically a username and password pair), which
        allow the server to verify their authenticity. Using these methods for delegation requires
        the client to assume the role of the resource owner.
      </t-->
      <t>
        OAuth は各リクエストに際し、クライアントを識別するものと、リソースオーナーを識別するもの、2つのクレデンシャルを含むようにデザインされたメソッドを提供する。クライアントは、リソースオーナーの代理として認証済みリクエストを行う前に、まずリソースオーナーによって認可済みのトークンを取得しなければならない。<xref target="redirect_workflow" /> は、クライアントがリソースオーナーにより認可されたトークンを取得するひとつの方法である。
      </t>
      <!--t>
        OAuth provides a method designed to include two sets of credentials with each request, one
        to identify the client, and another to identify the resource owner. Before a client can
        make authenticated requests on behalf of the resource owner, it must obtain a token
        authorized by the resource owner. <xref target="redirect_workflow" /> provides one such
        method through which the client can obtain a token authorized by the resource owner.
      </t-->
      <t>
        クライアントクレデンシャルはユニークな識別子および、識別子に紐付けられた共有鍵、もしくは RSA 鍵ペアの形式をとる。認証済みリクエストを送信するに先立ち、クライアントはサーバーとのクレデンシャルを確立する。ただし、その手順や要件については、本仕様の範囲外のため論じない。実装者は、クライアントの認証情報を使うセキュリティ上の影響をよく考えるべきである。いくつかの懸念点については <xref target="client_cred_sec" /> に記載している。
      </t>
      <!--t>
        The client credentials take the form of a unique identifier, and an associated shared-secret
        or RSA key pair. Prior to making authenticated requests, the client establishes a set of
        credentials with the server. The process and requirements for provisioning these are
        outside the scope of this specification. Implementers are urged to consider the security
        ramifications of using client credentials, some of which are described in
        <xref target="client_cred_sec" />.
      </t-->
      <t>
        認証済みリクエストを送信するに当たり、サーバーの設定に関する知識が必要となる。OAuth ではリクエスト上でプロトコルパラメータを送信するメソッド (<xref target="param_include" />) と、クライアントがクレデンシャルの所有権を証明するために利用する方法 (<xref target="signature" />) が、それぞれ複数存在する。クライアントがこれらの設定を検知する方法については、本仕様の範囲外とする。
      </t>
      <!--t>
        Making authenticated requests requires prior knowledge of the server's configuration.
        OAuth includes multiple methods for transmitting protocol parameters with requests
        (<xref target="param_include" />), as well as multiple methods for the client to
        prove its rightful ownership of the credentials used (<xref target="signature" />).
        The way in which clients discover the required configuration is outside the scope of
        this specification.
      </t-->

      <section title="リクエストの実行">
      <!-- section title="Making Requests" -->
        <t>
          認証済みリクエストには、いくつかのプロトコルパラメータが含まれる。各パラメータ名は <spanx style="verb">oauth_</spanx> で始まり、パラメータ名は大文字小文字を区別する。クライアントは、一連のプロトコルパラメータ値を計算し、下記のようにして HTTP リクエストに追加することで、認証済みリクエストを行う。
          <!--
          An authenticated request includes several protocol parameters. Each parameter name
          begins with the <spanx style="verb">oauth_</spanx> prefix, and the parameter names and
          values are case sensitive. Clients make authenticated requests by calculating the values
          of a set of protocol parameters and adding them to the HTTP request as follows:
          -->

          <list style="numbers">
            <t>
              クライアントは下記の (特に指定されていない限り) 必須な (REQUIRED) プロトコルパラメータに、それぞれ値を割り当てる。
              <!--
              The client assigns value to each of these REQUIRED (unless specified otherwise)
              protocol parameters:
              -->

              <list style="hanging" hangIndent="6">
                <t hangText="oauth_consumer_key">
                  <vspace />
                  クライアントクレデンシャルの識別子部分 (ユーザ名に当たる)。パラメータ名は本仕様の以前のバージョンで使用されていた用語 (Consumer Key) を反映しており、後方互換のためにそのまま使用する。
                </t>
                <!--t hangText="oauth_consumer_key">
                  <vspace />
                  The identifier portion of the client credentials (equivalent to a username). The
                  parameter name reflects a deprecated term (Consumer Key) used in previous
                  revisions of the specification, and has been retained to maintain backward
                  compatibility.
                </t-->
                <t hangText="oauth_token">
                  <vspace />
                  リソースオーナーとリクエストを関連付けるトークン値。リクエストがリソースオーナーと関連付けられていない場合 (トークンが利用できない場合)、パラメータを省略することができる。
                </t>
                <!--t hangText="oauth_token">
                  <vspace />
                  The token value used to associate the request with the resource owner. If the
                  request is not associated with a resource owner (no token available), clients
                  MAY omit the parameter.
                </t-->
                <t hangText="oauth_signature_method">
                  <vspace />
                  <xref target="signature" /> で定義されている、クライアントがリクエストに署名するために使用する署名メソッドの名前。
                </t>
                <!--t hangText="oauth_signature_method">
                  <vspace />
                  The name of the signature method used by the client to sign the request,
                  as defined in <xref target="signature" />.
                </t-->
                <t hangText="oauth_timestamp">
                  <vspace />
                  <xref target="nonce" /> で定義されているタイムスタンプ値。署名メソッドとして <spanx style="verb">PLAINTEXT</spanx> を使用している場合、省略することができる。
                </t>
                <!--t hangText="oauth_timestamp">
                  <vspace />
                  The timestamp value as defined in <xref target="nonce" />. The parameter MAY
                  be omitted when using the <spanx style="verb">PLAINTEXT</spanx> signature method.
                </t-->
                <t hangText="oauth_nonce">
                  <vspace />
                  <xref target="nonce" /> で定義されているノンス値。署名メソッドとして <spanx style="verb">PLAINTEXT</spanx> を使用している場合、省略することができる。
                </t>
                <!--t hangText="oauth_nonce">
                  <vspace />
                  The nonce value as defined in <xref target="nonce" />. The parameter MAY be
                  omitted when using the <spanx style="verb">PLAINTEXT</spanx> signature method.
                </t-->
                <t hangText="oauth_version">
                  <vspace />
                  オプション (OPTIONAL)。追加する場合、<spanx style="verb">1.0</spanx>でなければならない。本仕様で定義された認可手順のバージョンを示す。
                </t>
                <!--t hangText="oauth_version">
                  <vspace />
                  OPTIONAL. If present, MUST be set to <spanx style="verb">1.0</spanx>. Provides
                  the version of the authentication process as defined in this specification.
                </t-->
              </list>
            </t>
            <t>
              プロトコルパラメータは <xref target="param_include" /> に記載された転送メソッドのいずれかを使い、リクエストに追加される。各パラメータはリクエストにつき、二度以上含まれてはならない。
            </t>
            <!--t>
              The protocol parameters are added to the request using one of the transmission
              methods listed in <xref target="param_include" />. Each parameter MUST NOT appear
              more than once per request.
            </t-->
            <t>
              クライアントは <xref target="signature" /> に記載されている通り、<spanx style="verb">oauth_signature</spanx> パラメータの値を計算し、割り当てる。このパラメータは前のステップと同じ方法で、リクエストに追加する。
            </t>
            <!--t>
              The client calculates and assigns the value of the <spanx style="verb">oauth_signature</spanx>
              parameter as described in <xref target="signature" /> and adds the parameter to the
              request using the same method used in the previous step.
            </t-->
            <t>
              クライアントが認証済みリクエストをサーバーに送信する。
            </t>
            <!--t>
              The client sends the authenticated HTTP request to the server.
            </t-->
          </list>
        </t>
        <figure>
          <preamble>
            例えば、下記のような HTTP リクエストを認証付きで実行するとする (<spanx style="verb">c2&amp;a3=2+q</spanx> はフォームエンコードされたエンティティボディを強調するために使用)
          </preamble>
          <!--preamble>
            For example, to make the following HTTP request authenticated (the
            <spanx style="verb">c2&amp;a3=2+q</spanx> string in the following examples is used to
            illustrate the impact of a form-encoded entity-body) :
          </preamble-->
          <artwork xml:space="preserve"><![CDATA[
  GET /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
  Host: example.com
  Content-Type: application/x-www-form-urlencoded

  c2&a3=2+q
  ]]>
          </artwork>
        </figure>
        <figure>
          <preamble>
            クライアントはクライアントクレデンシャル、トークンクレデンシャル、現在のタイムスタンプ、ユニークなノンス、署名メソッドとして <spanx style="verb">HMAC-SHA1</spanx> を使用することを示し、プロトコルパラメータに値を割り当てる。
          </preamble>
          <!--preamble>
            The client assigns values to the following protocol parameters using its client
            credentials, token credentials, the current timestamp, a uniquely generated nonce, and
            indicates it will use the <spanx style="verb">HMAC-SHA1</spanx> signature method:
          </preamble-->
          <artwork xml:space="preserve"><![CDATA[
  oauth_consumer_key:     9djdj82h48djs9d2
  oauth_token:            kkk9d7dh3k39sjv7
  oauth_signature_method: HMAC-SHA1
  oauth_timestamp:        137131201
  oauth_nonce:            7d8f3e4a
  ]]>
          </artwork>
        </figure>
        <figure>
          <preamble>
            クライアントが OAuth HTTP Authorization ヘッダーフィールドを使って、リクエストにプロトコルパラメータを追加する。
          </preamble>
          <!--preamble>
            The client adds the protocol parameters to the request using the OAuth HTTP
            Authorization header field:
          </preamble-->
          <artwork xml:space="preserve"><![CDATA[
  Authorization: OAuth realm="Example",
                 oauth_consumer_key="9djdj82h48djs9d2",
                 oauth_token="kkk9d7dh3k39sjv7",
                 oauth_signature_method="HMAC-SHA1",
                 oauth_timestamp="137131201",
                 oauth_nonce="7d8f3e4a"
]]>
          </artwork>
        </figure>
        <figure>
          <preamble>
            その後 <spanx style="verb">oauth_signature</spanx> パラメータの値を計算し、リクエストに追加。そして HTTP リクエストをサーバーに送信する。
          </preamble>
          <!--preamble>
            Then calculates the value of the <spanx style="verb">oauth_signature</spanx> parameter,
            adds it to the request, and sends the HTTP request to the server:
          </preamble-->
          <artwork xml:space="preserve"><![CDATA[
  GET /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
  Host: example.com
  Content-Type: application/x-www-form-urlencoded
  Authorization: OAuth realm="Example",
                 oauth_consumer_key="9djdj82h48djs9d2",
                 oauth_token="kkk9d7dh3k39sjv7",
                 oauth_signature_method="HMAC-SHA1",
                 oauth_timestamp="137131201",
                 oauth_nonce="7d8f3e4a",
                 oauth_signature="djosJKDKJSD8743243%2Fjdk33klY%3D"

  c2&a3=2+q
  ]]>
          </artwork>
        </figure>
      </section>
      
      <section title="リクエストの妥当性検証" anchor="verify_request">
      <!--section title="Verifying Requests" anchor="verify_request"-->
        <t>
          認証済みリクエストを受け取ったサーバーは、以下のようにその妥当性を検証しなければならない (MUST)。

          <list style="symbols">
            <t>
              リクエスト署名を独自に再計算し (<xref target="signature" />)、<spanx style="verb">ooauth_signature</spanx> パラメータとしてクライアントから受け取った値と比較を行う。
            </t>
            <t>
              <spanx style="verb">HMAC-SHA1</spanx> または <spanx style="verb">RSA-SHA1</spanx> 署名方式を使用している場合、クライアントから受け取ったノンス値 / タイムスタンプ / トークン (存在する場合のみ) の組合せが以前のリクエストで使用されたものではないことを検証すること。(サーバーはタイムスタンプが古いままのリクエストを拒否してもよい (MAY) (<xref target="nonce" />))
            </t>
            <t>
              トークンが存在する場合、トークンの示すクライアントの認可情報の範囲とステータスを検証すること。(サーバーは トークンの使用を、発行対象となったクライアントのみに制限してもよい (MAY))
            </t>
            <t>
              <spanx style="verb">oauth_version</spanx> パラメータが存在する場合、その値が <spanx style="verb">1.0</spanx> であるか検証すること。
            </t>
          </list>
        </t>
        <!--t>
          Servers receiving an authenticated request MUST validate it by:

          <list style="symbols">
            <t>
              Recalculate the request signature independently as described in
              <xref target="signature" /> and compare it to the value received from the client via
              the <spanx style="verb">oauth_signature</spanx> parameter.
            </t>
            <t>
              If using the <spanx style="verb">HMAC-SHA1</spanx> or
              <spanx style="verb">RSA-SHA1</spanx> signature methods, ensure that the combination
              of nonce/timestamp/token (if present) received from the client has not been used
              before in a previous request (the server MAY reject requests with stale timestamps as
              described in <xref target="nonce" />).
            </t>
            <t>
              If a token is present, verify the scope and status of the client authorization as
              represented by the token (the server MAY choose to restrict token usage to the client
              to which it was issued).
            </t>
            <t>
              If the <spanx style="verb">oauth_version</spanx> parameter is present, ensure its
              value is <spanx style="verb">1.0</spanx>.
            </t>
          </list>
        </t-->
        <t>
          リクエストの妥当性検証に失敗した場合、サーバーは適切な HTTP ステータスコードを返すべきである (SHOULD)。その際、リクエストボディーで詳細なリクエスト拒否理由を通知してもよい (MAY)。
        </t>
        <!--t>
          If the request fails verification, the server SHOULD respond with the appropriate HTTP
          response status code. The server MAY include further details about why the request was
          rejected in the response body.
        </t-->
        <t>
          サーバーは、サポート外のパラメータ、サポート外の署名方式、パラメータ不足、重複したプロトコルパラメータを持ったリクエストを受け取った場合、ステータスコード 400 (Bad Request) を返すべきである (SHOULD)。サーバーは、不正なクライアントクレデンシャル、不正または期限切れのトークン、不正または使用済みのノンス値を含むリクエストを受け取った場合、ステータスコード 401 (Unauthorized) を返すべきである (SHOULD)。
        </t>
        <!--t>
          The server SHOULD return a 400 (bad request) status code
          when receiving a request with unsupported parameters, unsupported signature method,
          missing parameters, or duplicated protocol parameters. The server SHOULD return a 401
          (unauthorized) status code when receiving a request with invalid client credentials,
          invalid or expired token, invalid signature, or invalid or used nonce.
        </t-->
      </section>

      <section title="ノンス値とタイムスタンプ" anchor="nonce">
      <!--section title="Nonce and Timestamp" anchor="nonce"-->
        <t>
          タイムスタンプは正の整数でなければならない (MUST)。サーバーのドキュメントで規定されていない限り、タイムスタンプは 1970/01/01 00:00:00 GMT を起点にした経過秒数で表される。
        </t>
        <!--t>
          The timestamp value MUST be a positive integer. Unless otherwise specified by the
          server's documentation, the timestamp is expressed in the number of seconds since
          January 1, 1970 00:00:00 GMT.
        </t-->
        <t>
          ノンス値はクライアントによってユニークに生成されたランダムな文字列である。ノンス値があることでサーバーは、リクエストが過去に実行されていないことの検証や、安全でない通信チャネルを使ってリクエストされた場合の再現攻撃を防ぐことができる。ノンス値は同じタイムスタンプ、クライアントクレデンシャル、トークンの組み合わせを持ったすべてのリクエストに対し、ユニークでなければならない (MUST)。
        </t>
        <!--t>
          A nonce is a random string, uniquely generated by the client to allow the server to
          verify that a request has never been made before and helps prevent replay attacks when
          requests are made over a non-secure channel. The nonce value MUST be unique across all
          requests with the same timestamp, client credentials, and token combinations.
        </t-->
        <t>
          サーバーは、チェック目的でノンス値を永久に保持しておく必要がないよう、タイムスタンプの古いリクエストを拒否する期間的制限を設けてもよい (MAY)。ただし、この制限はクライアントとサーバーのクロック同期が一定の水準にある前提であることに注意すること。サーバーはクライアントがサーバーのクロックと同期する方法を提供してもよいし (MAY)、別途、信頼の置けるタイムサービスを利用して双方のシステムを同期させてもよい。クロック同期方式の詳細については、この仕様書の範囲外とする。
        </t>
        <!--t>
          To avoid the need to retain an infinite number of nonce values for future checks, servers
          MAY choose to restrict the time period after which a request with an old timestamp is
          rejected. Note that this restriction implies a level of synchronization between the
          client's and server's clocks. Servers applying such a restriction MAY provide a way for
          the client to sync with the server's clock; alternatively both systems could synchronize
          with a trusted time service. Details of clock synchronization strategies are beyond the
          scope of this specification.
        </t-->
      </section>
      
      <section title="署名" anchor="signature">
      <!--section title="Signature" anchor="signature"-->
        <t>
          OAuth 認証済みリクエストは、<spanx style="verb">oauth_consumer_key</spanx> と <spanx style="verb">oauth_token</spanx> という2つのクレデンシャル情報を持つことができる。サーバーがリクエストの正当性を検証し、認可されていないアクセスを阻止するため、クライアントはクレデンシャルの正当なオーナーであることを証明する必要がある。これはクレデンシャルの共有鍵 (または RSA 鍵) 部分を使用することにより実現される。
        </t>
        <!--t>
          OAuth-authenticated requests can have two sets of credentials: those passed via the
          <spanx style="verb">oauth_consumer_key</spanx> parameter and those in the
          <spanx style="verb">oauth_token</spanx> parameter. In order for the server to
          verify the authenticity of the request and prevent unauthorized access, the client needs
          to prove that it is the rightful owner of the credentials. This is accomplished using the
          shared-secret (or RSA key) part of each set of credentials.
        </t-->
        <t>
          OAuth はクライアントがクレデンシャルの正当なオーナーであることを証明する方法として <spanx style="verb">HMAC-SHA</spanx>、<spanx style="verb">RSA-SHA1</spanx>、<spanx style="verb">PLAINTEXT</spanx> の3つを提供する。<spanx style="verb">PLAINTEXT</spanx> に署名は含まれないが、これらは一般的に署名方式とみなされている。加えて、<spanx style="verb">RSA-SHA1</spanx> では、クライアントクレデンシャルにおける共有鍵の代替として、RSA 鍵が利用される。
        </t>
        <!--t>
          OAuth provides three methods for the client to prove its rightful ownership of the
          credentials: <spanx style="verb">HMAC-SHA1</spanx>, <spanx style="verb">RSA-SHA1</spanx>,
          and <spanx style="verb">PLAINTEXT</spanx>. These methods are generally referred to as
          signature methods, even though <spanx style="verb">PLAINTEXT</spanx> does not involve a
          signature. In addition, <spanx style="verb">RSA-SHA1</spanx> utilizes an RSA key instead
          of the shared-secrets associated with the client credentials.
        </t-->
        <t>
          各実装がそれぞれの要件を保てるよう、OAuth では特定の署名方式を強制しない。サーバーは独自の方式を実装したり、規定することができる。本仕様の範囲外であるため、特定の方式の推奨はしない。実装者はサポートする方式を決定する前に、<xref target="Security">セキュリティに関する考慮事項</xref>を精査するべきである。
        </t>
        <!--t>
          OAuth does not mandate a particular signature method, as each implementation can have its
          own unique requirements. Servers are free to implement and document their own custom
          methods. Recommending any particular method is beyond the scope of this specification.
          Implementers should review the <xref target="Security">Security Considerations section</xref>
          before deciding on which method to support.
        </t-->
        <t>
          クライアントは、どの署名方式を使用するかを <spanx style="verb">oauth_signature_method</spanx> パラメータを用いて宣言する。生成した署名 (またはそれと等価なもの) は、<spanx style="verb">oauth_signature</spanx> パラメータに含める。サーバーは各方式で規定されている方法で署名を検証する。
        </t>
        <!--t>
          The client declares which signature method is used via the
          <spanx style="verb">oauth_signature_method</spanx> parameter. It then generates a signature
          (or a string of an equivalent value), and includes it in the
          <spanx style="verb">oauth_signature</spanx> parameter. The server verifies the signature
          as specified for each method.
        </t-->
        <t>
          <spanx style="verb">oauth_signature</spanx> パラメータを除き、署名のプロセスでリクエストやパラメータが変更されることはない。
        </t>
        <!--t>
          The signature process does not change the request or its parameters, with the exception of
          the <spanx style="verb">oauth_signature</spanx> parameter.
        </t-->

        <section title="シグニチャベースストリング">
        <!-- section title="Signature Base String" -->
          <t>
            シグニチャベースストリングは、いくつかの HTTP リクエストの構成要素を、一貫し、かつ再現可能な形で連結した単一の文字列である。この文字列は <spanx style="verb">HMAC-SHA1</spanx> および <spanx style="verb">RSA-SHA1</spanx> 署名方式への入力値となる。
            <!--
            The signature base string is a consistent, reproducible concatenation of several
            of the HTTP request elements into a single string. The string is used as an input to
            the <spanx style="verb">HMAC-SHA1</spanx> and <spanx style="verb">RSA-SHA1</spanx>
            signature methods.
            -->
          </t>
          <t>
            シグニチャベースストリングは HTTP リクエストにおける以下の構成要素を含む。
            <!--
            The signature base string includes the following components of the HTTP request:
            -->
            
            <list style="symbols">
              <t>
                HTTP リクエストメソッド (例: <spanx style="verb">GET</spanx>、<spanx style="verb">POST</spanx> 等)
                <!--
                The HTTP request method (e.g. <spanx style="verb">GET</spanx>,
                <spanx style="verb">POST</spanx>, etc.).
                -->
              </t>
              <t>
                リクエストの HTTP <spanx style="verb">Host</spanx> ヘッダーで示されるオーソリティ。
                <!--
                The authority as declared by the HTTP <spanx style="verb">Host</spanx> request
                header field.
                -->
              </t>
              <t>
                リクエスト URI 中のパスとクエリー要素。
                <!--
                The path and query components of the request resource URI.
                -->
              </t>
              <t>
                <spanx style="verb">oauth_signature</spanx> を除くプロトコルパラメータ。
                <!--
                The protocol parameters excluding the
                <spanx style="verb">oauth_signature</spanx>.
                -->
              </t>
              <t>
                リクエストのエンティティボディーに含まれる、<xref target="collect_param" /> で定義された厳格な制約を満たすパラメータ。
                <!--
                Parameters included in the request entity-body if they comply with the strict
                restrictions defined in <xref target="collect_param" />.
                -->
              </t>
            </list>
          </t>
          <t>
            シグニチャベースストリングは HTTP リクエスト全体をカバーするものではない。特に注意すべきは、多くのリクエストにおいて、エンティティボディーや HTTP エンティティヘッダーが含まれないことである。よって、サーバーが SSL や TLS およびその他の防衛策を施さない限り、シグニチャベースストリングに含まれないリクエストコンポーネントの信憑性は検証不可能であることに留意すること。
            <!--
            The signature base string does not cover the entire HTTP request. Most notably, it
            does not include the entity-body in most requests, nor does it include most HTTP
            entity-headers. It is important to note that the server cannot verify the authenticity
            of the excluded request components without using additional protections such as SSL/TLS or
            other methods.
            -->
          </t>
          
          <section title="シグニチャベースストリングの構築" anchor="base_string">
          <!-- section title="String Construction" anchor="base_string" -->
            <t>
              シグニチャベースストリングは以下の HTTP リクエスト要素を順番に連結して構築される。
              <!--
              The signature base string is constructed by concatenating together, in order, the
              following HTTP request elements:
              -->

              <list style="numbers">
                <t>
                  HTTP リクエストメソッド (大文字)。例: <spanx style="verb">HEAD</spanx>、<spanx style="verb">GET</spanx>、<spanx style="verb">POST</spanx> 等。独自の HTTP メソッドを利用する場合は、<xref target="encoding">エンコード</xref>しなければならない (MUST)。
                  <!--
                  The HTTP request method in uppercase. For example: <spanx style="verb">HEAD</spanx>,
                  <spanx style="verb">GET</spanx>, <spanx style="verb">POST</spanx>, etc. If the
                  request uses a custom HTTP method, it MUST be <xref target="encoding">encoded</xref>.
                  -->
                </t>
                <t>
                  文字 <spanx style="verb">&amp;</spanx> (ASCII code 38)
                  <!--
                  An <spanx style="verb">&amp;</spanx> character (ASCII code 38).
                  -->
                </t>
                <t>
                  <xref target="sig_uri" /> に示されるベースストリング URI を<xref target="encoding">エンコード</xref>した文字列。
                  <!--
                  The base string URI from <xref target="sig_uri" />, after being
                  <xref target="encoding">encoded</xref>.
                  -->
                </t>
                <t>
                  文字 <spanx style="verb">&amp;</spanx> (ASCII code 38)
                  <!--
                  An <spanx style="verb">&amp;</spanx> character (ASCII code 38).
                  -->
                </t>
                <t>
                  <xref target="sig_norm_param" /> に示されるノーマライズされたリクエストパラメータを<xref target="encoding">エンコード</xref>した文字列。
                  <!--
                  The request parameters as normalized in <xref target="sig_norm_param" />, after
                  being <xref target="encoding">encoded</xref>.
                  -->
                </t>
              </list>
            </t>
            <figure>
              <preamble>
                例えば、以下のような HTTP リクエストがあったとする。
                <!--
                For example, the HTTP request:
                -->
              </preamble>
              <artwork xml:space="preserve"><![CDATA[
  GET /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
  Host: example.com
  Content-Type: application/x-www-form-urlencoded
  Authorization: OAuth realm="Example",
                 oauth_consumer_key="9djdj82h48djs9d2",
                 oauth_token="kkk9d7dh3k39sjv7",
                 oauth_signature_method="HMAC-SHA1",
                 oauth_timestamp="137131201",
                 oauth_nonce="7d8f3e4a",
                 oauth_signature="djosJKDKJSD8743243%2Fjdk33klY%3D"

  c2&a3=2+q
  ]]>
              </artwork>
            </figure>
            <figure>
              <preamble>
                この時、このリクエストに対するシグニチャベースストリングは以下のようになる。(改行は掲載上の都合による)
                <!--
                Is represented by the following signature base string (line breaks are for display
                purposes only):
                -->
              </preamble>
              <artwork xml:space="preserve"><![CDATA[
  GET&http%3A%2F%2Fexample.com%2Frequest&a2%3Dr%2520b%26a3%3D2%2520q%
  26a3%3Da%26b5%3D%253D%25253D%26c%2540%3D%26c2%3D%26oauth_consumer_k
  ey%3D9djdj82h48djs9d2%26oauth_nonce%3D7d8f3e4a%26oauth_signature_me
  thod%3DHMAC-SHA1%26oauth_timestamp%3D137131201%26oauth_token%3Dkkk9
  d7dh3k39sjv7
  ]]>
              </artwork>
            </figure>
          </section>

          <section title="ベースストリング URI" anchor="sig_uri">
          <!-- section title="Base String URI" anchor="sig_uri" -->
            <t>
              ベースストリング URI には、リクエスト対象リソースを示す <spanx style="verb">http</spanx> もしくは <spanx style="verb">https</spanx> URI を構築した上で、リクエスト URI のスキーマ、オーソリティおよびパス <xref target="RFC3986" /> を以下のように含める。
              <!--
              The scheme, authority, and path of the request resource URI <xref target="RFC3986" />
              are included by constructing an <spanx style="verb">http</spanx> or
              <spanx style="verb">https</spanx> URI representing the request resource (without the
              query or fragment) as follows:
              -->

              <list style="numbers">
                <t>
                  スキーマおよびホストは小文字でなければならない (MUST)。
                  <!--
                  The scheme and host MUST be in lowercase.
                  -->
                </t>
                <t>
                  ホストとポート番号はリクエスト中の HTTP <spanx style="verb">Host</spanx> ヘッダーの値と同一でなければならない (MUST)。
                  <!--
                  The host and port values MUST match the content of the HTTP request
                  <spanx style="verb">Host</spanx> header field.
                  -->
                </t>
                <t>
                  ポート番号がそのスキーマのデフォルトポートでない場合、必ずポート番号を含めなければならない (MUST)。またデフォルトの場合はポート番号を除外しなければならない (MUST)。特に、HTTP リクエスト <xref target="RFC2616" /> の場合にはポート80、HTTPS リクエスト <xref target="RFC2818" /> の場合にはポート443を除外しなければならない (MUST)。その他のデフォルト値以外のポート番号は全て含めなければならない (MUST)。
                  <!--
                  The port MUST be included if it is not the default port for the scheme, and MUST
                  be excluded if it is the default. Specifically, the port MUST be excluded when
                  making an HTTP request <xref target="RFC2616" /> to port 80 or when making an
                  HTTPS request <xref target="RFC2818" /> to port 443. All other non-default port
                  numbers MUST be included.
                  -->
                </t>
              </list>
            </t>
            <figure>
              <preamble>
                例えば、以下のような HTTP リクエストがあったとする。
                <!--
                For example, the HTTP request:
                -->
              </preamble>
              <artwork xml:space="preserve"><![CDATA[
  GET /r%20v/X?id=123 HTTP/1.1
  Host: EXAMPLE.COM:80
]]>
              </artwork>
              <postamble>
                このときベースストリング URI は次のようになる。
                <!--
                is represented by the base string URI:
                -->
                <spanx style="verb">http://example.com/r%20v/X</spanx>
              </postamble>
            </figure>
            <figure>
              <preamble>
                また以下のような HTTPS リクエストがあったとする。
                <!--
                In another example, the HTTPS request:
                -->
              </preamble>
              <artwork xml:space="preserve"><![CDATA[
  GET /?q=1 HTTP/1.1
  Host: www.example.net:8080
]]>
              </artwork>
              <postamble>
                この場合のベースストリング URI は次のようになる。
                <!--
                is represented by the base string URI:
                -->
                <spanx style="verb">https://www.example.net:8080/</spanx>
              </postamble>
            </figure>
          </section>
            
          <section title="リクエストパラメータ" anchor="collect_param">
          <!--section title="Request Parameters" anchor="collect_param"-->
            <t>
              リクエストパラメータの一貫性と再現性を保証するため、パラメータは集められ、元の形式にデコードされる。その後ソートを行い、元のエンコード方式と異なる場合のある方法でエンコードされ、ひとつの文字列に連結される。
            </t>
            <!--t>
              In order to guarantee a consistent and reproducible representation of the request
              parameters, the parameters are collected and decoded to their original decoded form.
              They are then sorted and encoded in a particular manner which is often different from
              their original encoding scheme, and concatenated into a single string.
            </t-->

            <section title="Parameter Sources">
              <t>
                下記に含まれるパラメータ群は、名前と値のペアのリストにまとめられる。
              <!--t>
                The parameters from the following sources are collected into a single list of
                name/value pairs:
                -->

                <list style="symbols">
                  <t>
                    <xref target="RFC3986" /> 3.4節で定義されている HTTP リクエスト URI のクエリー要素。クエリー要素は <spanx style="verb">application/x-www-form-urlencoded</spanx> 文字列として名前と値が分割され、<xref target="W3C.REC-html40-19980424" /> 17.13.4節で定義された方法でデコードし、名前と値のペアのリストに分解される。
                  </t>
                  <!--t>
                    The query component of the HTTP request URI as defined by <xref target="RFC3986" />
                    section 3.4. The query component is parsed into a list of name/value pairs by
                    treating it as an <spanx style="verb">application/x-www-form-urlencoded</spanx>
                    string, separating the names and values and decoding them as defined by
                    <xref target="W3C.REC-html40-19980424" /> section 17.13.4.
                  </t-->
                  <t>
                    OAuth HTTP Authorization ヘッダフィールド (<xref target="auth_header" />) が存在する場合はその値。ヘッダーのコンテンツは <spanx style="verb">realm</spanx> パラメータを除き、すべて名前と値のペアに分解される。パラメータ値は <xref target="auth_header" /> で定義された方法でデコードされる。
                  </t>
                  <!--t>
                    The OAuth HTTP Authorization header field (<xref target="auth_header" />) if
                    present. The header's content is parsed into a list of name/value pairs
                    excluding the <spanx style="verb">realm</spanx> parameter if present. The
                    parameter values are decoded as defined by <xref target="auth_header" />.
                  </t-->
                  <t>
                    以下の条件を満たす場合のみ、HTTP リクエストエンティティボディ。
                  <!--t>
                    The HTTP request entity-body, but only if all of the following conditions are met:
                    -->

                    <list style="symbols">
                      <t>
                        エンティティボディがシングルパートである。
                      </t>
                      <!--t>
                        The entity-body is single-part.
                      </t-->
                      <t>
                        エンティティボディが <xref target="W3C.REC-html40-19980424" /> で定義されたコンテンツタイプ <spanx style="verb">application/x-www-form-urlencoded</spanx> のエンコード要件を満たしている。
                      </t>
                      <!--t>
                        The entity-body follows the encoding requirements of the
                        <spanx style="verb">application/x-www-form-urlencoded</spanx> content-type as
                        defined by <xref target="W3C.REC-html40-19980424" />.
                      </t-->
                      <t>
                        HTTP リクエストエンティティヘッダが <spanx style="verb">application/x-www-form-urlencoded</spanx> 形式の <spanx style="verb">Content-Type</spanx> ヘッダーフィールドセットを含む。
                      </t>
                      <!--t>
                        The HTTP request entity-header includes the <spanx style="verb">Content-Type</spanx>
                        header field set to <spanx style="verb">application/x-www-form-urlencoded</spanx>.
                      </t-->
                    </list>

                    エンティティボディは <xref target="W3C.REC-html40-19980424" /> 17.13.4節の方法でデコードされた名前と値のペアのリストに分解される。
                    <!--
                    The entity-body is parsed into a list of decoded name/value pairs as described in
                    <xref target="W3C.REC-html40-19980424" /> section 17.13.4.
                    -->
                  </t>
                </list>
              </t>
              <t>
                <spanx style="verb">oauth_signature</spanx> パラメータが存在した場合は、それをシグニチャベースストリングから除外しなければならない。明示的にリクエストに含まれたパラメータ以外は、シグニチャベースストリングから除外されなければならない (<spanx style="verb">oauth_version</spanx> パラメータが省略された場合等)。
              </t>
              <!--t>
                The <spanx style="verb">oauth_signature</spanx> parameter MUST be excluded from the
                signature base string if present. Parameters not explicitly included in the request
                MUST be excluded from the signature base string (e.g. the
                <spanx style="verb">oauth_version</spanx> parameter when omitted).
              </t-->
              <figure>
                <preamble>
                  例えば下記のような HTTP リクエストの場合
                </preamble>
                <!--preamble>
                  For example, the HTTP request:
                </preamble-->
                <artwork xml:space="preserve"><![CDATA[
    GET /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
    Host: example.com
    Content-Type: application/x-www-form-urlencoded
    Authorization: OAuth realm="Example",
                   oauth_consumer_key="9djdj82h48djs9d2",
                   oauth_token="kkk9d7dh3k39sjv7",
                   oauth_signature_method="HMAC-SHA1",
                   oauth_timestamp="137131201",
                   oauth_nonce="7d8f3e4a",
                   oauth_signature="djosJKDKJSD8743243%2Fjdk33klY%3D"

    c2&a3=2+q
  ]]>
                </artwork>
                <postamble>
                  下記の (デコード済み) パラメータがシグニチャベースストリングに含まれる。
                </postamble>
                <!--postamble>
                  Contains the following (fully decoded) parameters used in the signature base
                  sting:
                </postamble-->
              </figure>
              <texttable>
                <ttcol align='center'>名前</ttcol>
                <!--ttcol align='center'>Name</ttcol-->
                <ttcol align='center'>値</ttcol>
                <!--ttcol align='center'>Value</ttcol-->
                <c>b5</c><c>=%3D</c>
                <c>a3</c><c>a</c>
                <c>c@</c><c></c>
                <c>a2</c><c>r b</c>
                <c>oauth_consumer_key</c><c>9djdj82h48djs9d2</c>
                <c>oauth_token</c><c>kkk9d7dh3k39sjv7</c>
                <c>oauth_signature_method</c><c>HMAC-SHA1</c>
                <c>oauth_timestamp</c><c>137131201</c>
                <c>oauth_nonce</c><c>7d8f3e4a</c>
                <c>c2</c><c></c>
                <c>a3</c><c>2 q</c>
              </texttable>
              <t>
                <spanx style="verb">b5</spanx> の値は <spanx style="verb">=%3D</spanx> であり、 <spanx style="verb">==</spanx> ではないことに注意。<spanx style="verb">c@</spanx> と <spanx style="verb">c2</spanx> の値は空である。本仕様で定義しているシグニチャベースストリングの構築を目的としたエンコードルールでは、エンコードされたスペース (ASCII コード 32) を表す <spanx style="verb">+</spanx> 文字 (ASCII コード 43) を除外しているが、これは <spanx style="verb">application/x-www-form-urlencoded</spanx> でエンコードされた値では広く利用されており、<spanx style="verb">a3</spanx> パラメータインスタンスのひとつで示されるように (このリクエストでは <spanx style="verb">a3</spanx> は2回登場する)、正しくデコードされなければならない。
              </t>
              <!--t>
                Note that the value of <spanx style="verb">b5</spanx> is <spanx style="verb">=%3D</spanx>
                and not <spanx style="verb">==</spanx>. Both <spanx style="verb">c@</spanx> and
                <spanx style="verb">c2</spanx> have empty values. While the encoding rules
                specified in this specification for the purpose of constructing the signature base
                string exclude the use of a <spanx style="verb">+</spanx> character (ASCII code 43)
                to represent an encoded space character (ASCII code 32), this practice is widely
                used in <spanx style="verb">application/x-www-form-urlencoded</spanx> encoded
                values, and MUST be properly decoded, as demonstrated by one of the
                <spanx style="verb">a3</spanx> parameter instances (the <spanx style="verb">a3</spanx>
                parameter is used twice in this request).
              </t-->
            </section>

            <section title="パラメータのノーマライゼーション" anchor="sig_norm_param">
            <!--section title="Parameters Normalization" anchor="sig_norm_param"-->
              <t>
                <xref target="collect_param" /> で集められたパラメータは、以下のようにひとつの文字列にノーマライズされる。
                <!--
                The parameters collected in <xref target="collect_param" /> are normalized into a
                single string as follows:
                -->

                <list style="numbers">
                  <t>
                    まず、各パラメータの名前と値を<xref target="encoding">エンコード</xref>する。
                  </t>
                  <!--t>
                    First, the name and value of each parameter are <xref target="encoding">encoded</xref>.
                  </t-->
                  <t>
                    パラメータはバイト値昇順を使い、名前でソートされる。2つ以上のパラメータが同じ名前を持つ場合、値でソートされる。
                  </t>
                  <!--t>
                    The parameters are sorted by name, using ascending byte value ordering. If
                    two or more parameters share the same name, they are sorted by their value.
                  </t-->
                  <t>
                    各パラメータの名前は <spanx style="verb">=</spanx> 文字 (ASCII コード 61) をセパレータとして、対応する値と (値が空であっても) 連結される。
                  </t>
                  <!--t>
                    The name of each parameter is concatenated to its corresponding value using an
                    <spanx style="verb">=</spanx> character (ASCII code 61) as separator, even if the
                    value is empty.
                  </t-->
                  <t>
                    ソート済みの名前と値のペアは、<spanx style="verb">&amp;</spanx> 文字 (ASCII コード 38) をセパレータとして、ひとつの文字列に連結される。
                  </t>
                  <!--t>
                    The sorted name/value pairs are concatenated together into a single string by
                    using an <spanx style="verb">&amp;</spanx> character (ASCII code 38) as separator.
                  </t-->
                </list>
              </t>
              <t>
                例えば前節から引き継いだパラメータは、以下のようにノーマライズされる。
              </t>
              <!--t>
                For example, the list of parameters from the previous section would be normalized as
                follows:
              </t-->
              <texttable>
                <preamble>
                  エンコード済み
                </preamble>
                <!--preamble>
                  Encoded:
                </preamble-->
                <ttcol align='center'>名前</ttcol>
                <!--ttcol align='center'>Name</ttcol-->
                <ttcol align='center'>値</ttcol>
                <!--ttcol align='center'>Value</ttcol-->
                <c>b5</c><c>%3D%253D</c>
                <c>a3</c><c>a</c>
                <c>c%40</c><c></c>
                <c>a2</c><c>r%20b</c>
                <c>oauth_consumer_key</c><c>9djdj82h48djs9d2</c>
                <c>oauth_token</c><c>kkk9d7dh3k39sjv7</c>
                <c>oauth_signature_method</c><c>HMAC-SHA1</c>
                <c>oauth_timestamp</c><c>137131201</c>
                <c>oauth_nonce</c><c>7d8f3e4a</c>
                <c>c2</c><c></c>
                <c>a3</c><c>2%20q</c>
              </texttable>
              <texttable>
                <preamble>
                  ソート済み
                </preamble>
                <!--preamble>
                  Sorted:
                </preamble-->
                <ttcol align='center'>名前</ttcol>
                <!--ttcol align='center'>Name</ttcol-->
                <ttcol align='center'>値</ttcol>
                <!--ttcol align='center'>Value</ttcol-->
                <c>a2</c><c>r%20b</c>
                <c>a3</c><c>2%20q</c>
                <c>a3</c><c>a</c>
                <c>b5</c><c>%3D%253D</c>
                <c>c%40</c><c></c>
                <c>c2</c><c></c>
                <c>oauth_consumer_key</c><c>9djdj82h48djs9d2</c>
                <c>oauth_nonce</c><c>7d8f3e4a</c>
                <c>oauth_signature_method</c><c>HMAC-SHA1</c>
                <c>oauth_timestamp</c><c>137131201</c>
                <c>oauth_token</c><c>kkk9d7dh3k39sjv7</c>
              </texttable>
              <texttable>
                <preamble>
                  連結されたペア
                </preamble>
                <!--preamble>
                  Concatenated Pairs:
                </preamble-->
                <ttcol align='center'>名前=値</ttcol>
                <!--ttcol align='center'>Name=Value</ttcol-->
                <c>a2=r%20b</c>
                <c>a3=2%20q</c>
                <c>a3=a</c>
                <c>b5=%3D%253D</c>
                <c>c%40=</c>
                <c>c2=</c>
                <c>oauth_consumer_key=9djdj82h48djs9d2</c>
                <c>oauth_nonce=7d8f3e4a</c>
                <c>oauth_signature_method=HMAC-SHA1</c>
                <c>oauth_timestamp=137131201</c>
                <c>oauth_token=kkk9d7dh3k39sjv7</c>
              </texttable>
              <figure>
                <preamble>
                  その後、これらのパラメータを連結し、単一文字列とする。(改行は掲載上の都合による)
                </preamble>
                <!--preamble>
                  And concatenated together into a single string (line breaks are for display
                  purposes only):
                </preamble-->
                <artwork xml:space="preserve"><![CDATA[
  a2=r%20b&a3=2%20q&a3=a&b5=%3D%253D&c%40=&c2=&oauth_consumer_key=9dj
  dj82h48djs9d2&oauth_nonce=7d8f3e4a&oauth_signature_method=HMAC-SHA1
  &oauth_timestamp=137131201&oauth_token=kkk9d7dh3k39sjv7
]]>
                </artwork>
              </figure>
            </section>

          </section>
          
        </section>

        <section title="HMAC-SHA1">
          <t>
            <spanx style="verb">HMAC-SHA1</spanx> 署名方式は、<xref target="RFC2104" /> で規定される、HMAC-SHA1 署名アルゴリズムを使用する。

            <figure>
              <artwork xml:space="preserve"><![CDATA[
  digest = HMAC-SHA1 (key, text)
]]>
              </artwork>
            </figure>
          </t>
          <!--t>
            The <spanx style="verb">HMAC-SHA1</spanx> signature method uses the HMAC-SHA1 signature
            algorithm as defined in <xref target="RFC2104" />:

            <figure>
              <artwork xml:space="preserve"><![CDATA[
  digest = HMAC-SHA1 (key, text)
]]>
              </artwork>
            </figure>
          </t-->
          <t>
            HMAC-SHA1 関数の変数は、次のように使用される。

            <list style="hanging" hangIndent="6">
              <t hangText="text">
                <vspace />
                シグニチャベースストリング (<xref target="base_string" /> 参照) の値に設定。
              </t>
              <t hangText="key">
                <vspace />
                下記を連結した値に設定。

                <list style="numbers">
                  <t>
                    <xref target="encoding">エンコード</xref>されたクライアント共有鍵。
                  </t>
                  <t>
                    <spanx style="verb">&amp;</spanx> (ASCII コード 38) (どちらの共有鍵が空の場合でも含まなければならない (MUST))
                  </t>
                  <t>
                    <xref target="encoding">エンコード</xref>済みのトークン共有鍵。
                  </t>
                </list>
              </t>
              <t hangText="digest">
                <vspace />
                結果のバイト文字列を base64 エンコード (<xref target="RFC2045" /> 6.8節参照) した、<spanx style="verb">oauth_signature</spanx> プロトコルパラメータを設定。
              </t>
            </list>
          </t>
          <!--t>
            The HMAC-SHA1 function variables are used in following way:

            <list style="hanging" hangIndent="6">
              <t hangText="text">
                <vspace />
                is set to the value of the signature base string from <xref target="base_string" />.
              </t>
              <t hangText="key">
                <vspace />
                is set to the concatenated values of:

                <list style="numbers">
                  <t>
                    The client shared-secret, after being <xref target="encoding">encoded</xref>.
                  </t>
                  <t>
                    An <spanx style="verb">&amp;</spanx> character (ASCII code 38), which MUST be
                    included even when either secret is empty.
                  </t>
                  <t>
                    The token shared-secret, after being <xref target="encoding">encoded</xref>.
                  </t>
                </list>
              </t>
              <t hangText="digest">
                <vspace />
                is used to set the value of the <spanx style="verb">oauth_signature</spanx>
                protocol parameter, after the result octet string is base64-encoded per
                <xref target="RFC2045" /> section 6.8.
              </t>
            </list>
          </t-->
        </section>

        <section title="RSA-SHA1">
          <t>
            <spanx style="verb">RSA-SHA1</spanx> 署名方式は、<xref target="RFC3447" /> 8.2節 (別名 : PKCS#1) で規定されている、RSASSA-PKCS1-v1_5 署名アルゴリズムを使用しており、SHA-1 は EMSA-PKCS1-v1_5 のハッシュ化関数として利用される。この方式を使用するために、クライアントは、サーバーに RSA 公開鍵 (この仕様では範囲外) を含むクライアントクレデンシャルを発行してもらわなければならない (MUST)。
          </t>
          <!--t>
            The <spanx style="verb">RSA-SHA1</spanx> signature method uses the RSASSA-PKCS1-v1_5
            signature algorithm as defined in <xref target="RFC3447" /> section 8.2 (also known as
            PKCS#1), using SHA-1 as the hash function for EMSA-PKCS1-v1_5. To use this method, the
            client MUST have established client credentials with the server which included its RSA
            public key (in a manner which is beyond the scope of this specification).
          </t-->
          <t>
            シグニチャベースストリングは、<xref target="RFC3447" /> 8.2.1節に基づき、RSA 秘密鍵を使用して署名される。

            <figure>
              <artwork xml:space="preserve"><![CDATA[
  S = RSASSA-PKCS1-V1_5-SIGN (K, M)
]]>
              </artwork>
            </figure>

            <list style="hanging" hangIndent="6">
              <t hangText="K">
                <vspace />
                クライアントの RSA 秘密鍵を設定。
              </t>
              <t hangText="M">
                <vspace />
                シグニチャベースストリング (<xref target="base_string" /> 参照) の値に設定。
              </t>
              <t hangText="S">
                <vspace />
                結果のバイト文字列を base64 エンコード (<xref target="RFC2045" /> 6.8節参照) した、<spanx style="verb">oauth_signature</spanx> プロトコルパラメータを設定。
              </t>
            </list>
          </t>
          <!--t>
            The signature base string is signed using the client's RSA private key per
            <xref target="RFC3447" /> section 8.2.1:

            <figure>
              <artwork xml:space="preserve"><![CDATA[
  S = RSASSA-PKCS1-V1_5-SIGN (K, M)
]]>
              </artwork>
            </figure>

            Where:

            <list style="hanging" hangIndent="6">
              <t hangText="K">
                <vspace />
                is set to the client's RSA private key,
              </t>
              <t hangText="M">
                <vspace />
                is set to the value of the signature base string from <xref target="base_string" />, and
              </t>
              <t hangText="S">
                <vspace />
                is the result signature used to set the value of the <spanx style="verb">oauth_signature</spanx>
                protocol parameter, after the result octet string is base64-encoded per <xref target="RFC2045" />
                section 6.8.
              </t>
            </list>
          </t-->
          <t>
            サーバーは、<xref target="RFC3447" /> 8.2.2節 に基づき、シグニチャの妥当性を検証する。

            <figure>
              <artwork xml:space="preserve"><![CDATA[
  RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S)
]]>
              </artwork>
            </figure>

            <list style="hanging" hangIndent="6">
              <t hangText="(n, e)">
                <vspace />
                クライアントの RSA 公開鍵を設定。
              </t>
              <t hangText="M">
                <vspace />
                シグニチャベースストリング (<xref target="base_string" /> 参照) の値に設定。
              </t>
              <t hangText="S">
                <vspace />
                クライアントから受け取った、<spanx style="verb">oauth_signature</spanx> プロトコルパラメータのバイト文字列を設定。
              </t>
            </list>
          </t>
          <!--t>
            The server verifies the signature per <xref target="RFC3447" /> section 8.2.2:

            <figure>
              <artwork xml:space="preserve"><![CDATA[
  RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S)
]]>
              </artwork>
            </figure>

            Where:

            <list style="hanging" hangIndent="6">
              <t hangText="(n, e)">
                <vspace />
                is set to the client's RSA public key,
              </t>
              <t hangText="M">
                <vspace />
                is set to the value of the signature base string from <xref target="base_string" />, and
              </t>
              <t hangText="S">
                <vspace />
                is set to the octet string value of the <spanx style="verb">oauth_signature</spanx>
                protocol parameter received from the client.
              </t>
            </list>
          </t-->
        </section>

        <section title="PLAINTEXT">
          <t>
            <spanx style="verb">PLAINTEXT</spanx> 方式は、署名アルゴリズムを使用しない。この方式はトランスポート層のメカニズムとして、TLS や SSL (もしくはこれらと同等のセキュアチャネル) を使用しなければならない (MUST)。この方式はシグニチャベースストリングや、<spanx style="verb">oauth_timestamp</spanx>、<spanx style="verb">oauth_nonce</spanx> パラメータを使用しない。
          </t>
          <!--t>
            The <spanx style="verb">PLAINTEXT</spanx> method does not employ a signature algorithm.
            It MUST be used with a transport-layer mechanism such as TLS or SSL (or sent over a secure
            channel with equivalent protections). It does not utilize the signature base string nor
            the <spanx style="verb">oauth_timestamp</spanx> and <spanx style="verb">oauth_nonce</spanx>
            parameters.
          </t-->
          <t>
            <spanx style="verb">oauth_signature</spanx> プロトコルパラメータは、下記を連結した値に設定する。

            <list style="numbers">
              <t>
                <xref target="encoding">エンコード</xref>済みのクライアント共有鍵
              </t>
              <t>
                <spanx style="verb">&amp;</spanx> (ASCII コード 38) (どちらの共有鍵が空の場合でも含まなければならない (MUST))
              </t>
              <t>
                <xref target="encoding">エンコード</xref>済みのトークン共有鍵
              </t>
            </list>
          </t>
          <!--t>
            The <spanx style="verb">oauth_signature</spanx> protocol parameter is set to the
            concatenated value of:

            <list style="numbers">
              <t>
                The client shared-secret, after being <xref target="encoding">encoded</xref>.
              </t>
              <t>
                An <spanx style="verb">&amp;</spanx> character (ASCII code 38), which MUST be
                included even when either secret is empty.
              </t>
              <t>
                The token shared-secret, after being <xref target="encoding">encoded</xref>.
              </t>
            </list>
          </t-->
        </section>

      </section>
      
      <section title="パラメータの送信" anchor="param_include">  
      <!-- section title="Parameter Transmission" anchor="param_include" -->
        <t>
          OAuth 認可リクエストを行う際、プロトコルパラメータおよび <spanx style="verb">oauth_</spanx> プレフィックスを含むその他全てのパラメータは、リクエスト中の、以下好ましい順に挙げたいずれか一カ所に含まれる (SHALL)。
          <!--
          When making an OAuth-authenticated request, protocol parameters as well as any other
          parameter using the <spanx style="verb">oauth_</spanx> prefix SHALL be included in the
          request using one and only one of the following locations, listed in order of decreasing
          preference:
          -->

          <list style="numbers">
            <t>
              HTTP <spanx style="verb">Authorization</spanx> ヘッダーフィールド。(<xref target="auth_header" /> 参照)
              <!--
              The HTTP <spanx style="verb">Authorization</spanx> header field as described in
              <xref target="auth_header" />.
              -->
            </t>
            <t>
              HTTP リクエストエンティティボディー。(<xref target="auth_body" /> 参照)
              <!--
              The HTTP request entity-body as described in <xref target="auth_body" />.
              -->
            </t>
            <t>
              HTTP リクエスト URI クエリー。（<xref target="auth_query" /> 参照)
              <!--
              The HTTP request URI query as described in <xref target="auth_query" />.
              -->
            </t>
          </list>
        </t>
        <t>
          これら3つの方法に加え、プロトコルパラメータをリクエストに含める別の方法が、今後の拡張仕様で定義される場合がある (MAY)。
          <!--
          In addition to these three methods, future extensions MAY define other methods for
          including protocol parameters in the request.
          -->
        </t>

        <section title="Authorization ヘッダー" anchor="auth_header">
        <!-- section title="Authorization Header" anchor="auth_header" -->
          <t>
            プロトコルパラメータは、<xref target="RFC2617" /> で定義される HTTP <spanx style="verb">Authorization</spanx> ヘッダーフィールドを用いて送信される。その際 auth-scheme 名を <spanx style="verb">OAuth</spanx> (大文字/小文字を区別) とする。
            <!--
            Protocol parameters can be transmitted using the HTTP
            <spanx style="verb">Authorization</spanx> header field as defined by <xref target="RFC2617" />
            with the auth-scheme name set to <spanx style="verb">OAuth</spanx> (case-insensitive).
            -->
          </t>
          <figure>
            <preamble>
              例:
              <!--
              For example:
              -->
            </preamble>
            <artwork xml:space="preserve"><![CDATA[
  Authorization: OAuth realm="Example",
     oauth_consumer_key="0685bd9184jfhq22",
     oauth_token="ad180jjd733klru7",
     oauth_signature_method="HMAC-SHA1",
     oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",
     oauth_timestamp="137131200",
     oauth_nonce="4572616e48616d6d65724c61686176",
     oauth_version="1.0"
]]>
            </artwork>
          </figure>
          <t>
            プロトコルパラメータは以下のように <spanx style="verb">Authorization</spanx> ヘッダーフィールドに含まれるものとする (SHALL)。
            <!--
            Protocol parameters SHALL be included in the <spanx style="verb">Authorization</spanx>
            header field as follows:
            -->

            <list style="numbers">
              <t>
                パラメータ名と値は<xref target="encoding">パラメータエンコーディング</xref>に従いエンコーディングされる。
                <!--
                Parameter names and values are encoded per
                <xref target="encoding">Parameter Encoding</xref>.
                -->
              </t>
              <t>
                各パラメータ名の直後には、<spanx style="verb">=</spanx> (ASCII code 61)、<spanx style="verb">"</spanx> (ASCII code 34)、パラメータ値 (空白も可 (MAY))、そして <spanx style="verb">"</spanx> (ASCII code 34) が続く。
                <!--
                Each parameter's name is immediately followed by an <spanx style="verb">=</spanx>
                character (ASCII code 61), a <spanx style="verb">"</spanx> character (ASCII code 34),
                the parameter value (MAY be empty), and another <spanx style="verb">"</spanx> character
                (ASCII code 34).
                -->
              </t>
              <t>
                パラメータは <spanx style="verb">,</spanx> (ASCII code 44) で区切られる。この際オプションとして <xref target="RFC2617" /> にある "linear whitespace" を用いることもできる (OPTIONAL)。
                <!--
                Parameters are separated by a <spanx style="verb">,</spanx> character (ASCII code 44)
                and OPTIONAL linear whitespace per <xref target="RFC2617" />.
                -->
              </t>
              <t>
                オプションで <spanx style="verb">realm</spanx> パラメータを追加することができる (OPTIONAL)。(<xref target="RFC2617" /> セクション1.2参照)
                <!--
                The OPTIONAL <spanx style="verb">realm</spanx> parameter MAY be added and
                interpreted per <xref target="RFC2617" /> section 1.2.
                -->
              </t>
            </list>
          </t>
          <t>
            サーバーは、クライアントからの保護されたリソースへのリクエストに対して HTTP <spanx style="verb">WWW-Authenticate</spanx> レスポンスヘッダーフィールドを返すことで、 <spanx style="verb">OAuth</spanx> auth-scheme をサポートしていることを示すことができる (MAY)。<xref target="RFC2617" /> にあるように、そのようなレスポンスは HTTP <spanx style="verb">WWW-Authenticate</spanx> ヘッダーフィールドを含むことができる (MAY)。
            <!--
            Servers MAY indicate their support for the <spanx style="verb">OAuth</spanx>
            auth-scheme by returning the HTTP <spanx style="verb">WWW-Authenticate</spanx>
            response header field upon client requests for protected resources. As per
            <xref target="RFC2617" /> such a response MAY include additional HTTP
            <spanx style="verb">WWW-Authenticate</spanx> header fields:
            -->
          </t>
          <figure>
            <preamble>
              例:
              <!--
              For example:
              -->
            </preamble>
            <artwork xml:space="preserve"><![CDATA[
  WWW-Authenticate: OAuth realm="http://server.example.com/"
]]>
            </artwork>
          </figure>
          <t>
            この realm パラメータは保護領域を示す。(<xref target="RFC2617" /> セクション1.2参照)
            <!--
            The realm parameter defines a protection realm per <xref target="RFC2617" />
            section 1.2.
            -->
          </t>
        </section>

        <section title="フォームエンコードボディー" anchor="auth_body">
        <!-- section title="Form-Encoded Body" anchor="auth_body" -->
          <t>
            プロトコルパラーメータは HTTP リクエストエンティティボディーを用いて送信することもできる。ただしその場合は以下の条件を満たす必要がある (REQUIRED)。
            <!--
            Protocol parameters can be transmitted in the HTTP request entity-body, but only if the
            following REQUIRED conditions are met:
            -->

            <list style="symbols">
              <t>
                エンティティボディーがシングルパートである。
                <!--
                The entity-body is single-part.
                -->
              </t>
              <t>
                エンティティボディーが <xref target="W3C.REC-html40-19980424" /> で定義される <spanx style="verb">application/x-www-form-urlencoded</spanx> コンテントタイプのエンコーディング条件を満たす。
                <!--
                The entity-body follows the encoding requirements of the
                <spanx style="verb">application/x-www-form-urlencoded</spanx> content-type as
                defined by <xref target="W3C.REC-html40-19980424" />.
                -->
              </t>
              <t>
                HTTP リクエストエンティティヘッダーが <spanx style="verb">Content-Type</spanx> ヘッダーフィールドを含み、その値が <spanx style="verb">application/x-www-form-urlencoded</spanx> である。
                <!--
                The HTTP request entity-header includes the <spanx style="verb">Content-Type</spanx>
                header field set to <spanx style="verb">application/x-www-form-urlencoded</spanx>.
                -->
              </t>
            </list>

            <figure>
              <preamble>
                例 (改行は掲載上の都合による)
                <!--
                For example (line breaks are for display purposes only):
                -->
              </preamble>
              <artwork xml:space="preserve"><![CDATA[
  oauth_consumer_key=0685bd9184jfhq22&oauth_token=ad180jjd733klr
  u7&oauth_signature_method=HMAC-SHA1&oauth_signature=wOJIO9A2W5
  mFwDgiDvZbTSMK%2FPY%3D&oauth_timestamp=137131200&oauth_nonce=4
  572616e48616d6d65724c61686176&oauth_version=1.0
]]>
              </artwork>
            </figure>
            
            エンティティボディーは他のリクエスト固有のパラメータを含む可能性がある (MAY)。その場合、プロトコルパラメータは適切に <spanx style="verb">&amp;</spanx> (ASCII code 38) で分割され、リクエスト固有パラメータの後に付加されるべきである (SHOULD)。
            <!--
            The entity-body MAY include other request-specific parameters, in which case, the
            protocol parameters SHOULD be appended following the request-specific parameters,
            properly separated by an <spanx style="verb">&amp;</spanx> character (ASCII code 38).
            -->
          </t>
        </section>

        <section title="リクエスト URI クエリー" anchor="auth_query">
        <!-- section title="Request URI Query" anchor="auth_query" -->
          <t>
            プロトコルパラメータは、HTTP リクエスト URI に <xref target="RFC3986" /> セクション3で定義されるクエリーパラメータとして付与し、送信することができる。
            <!--
            Protocol parameters can be transmitted by being added to the HTTP request URI as a
            query parameter as defined by <xref target="RFC3986" /> section 3.
            -->

            <figure>
              <preamble>
                例 (改行は掲載上の都合による)
                <!--
                For example (line breaks are for display purposes only):
                -->
              </preamble>
              <artwork xml:space="preserve"><![CDATA[
  GET /example/path?oauth_consumer_key=0685bd9184jfhq22&
  oauth_token=ad180jjd733klru7&oauth_signature_method=HM
  AC-SHA1&oauth_signature=wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%
  3D&oauth_timestamp=137131200&oauth_nonce=4572616e48616
  d6d65724c61686176&oauth_version=1.0 HTTP/1.1
]]>
              </artwork>
            </figure>

            リクエスト URI は他のリクエスト固有のクエリーパラメータを含む可能性がある (MAY)。その場合、プロトコルパラメータは適切に <spanx style="verb">&amp;</spanx> (ASCII code 38) で分割され、リクエスト固有パラメータの後に付加されるべきである (SHOULD)。
            <!--
            The request URI MAY include other request-specific query parameters, in which case,
            the protocol parameters SHOULD be appended following the request-specific parameters,
            properly separated by an <spanx style="verb">&amp;</spanx> character (ASCII code 38).
            -->
          </t>
        </section>

      </section>
      
      <section title="パーセントエンコーディング" anchor="encoding">
      <!-- section title="Percent Encoding" anchor="encoding" -->
        <t>
          既存のパーセントエンコーディング手法では、一貫したシグニチャベースストリングの構成は保証されない。以下に示すパーセントエンコーディング手法は <xref target="RFC3986" /> および <xref target="W3C.REC-html40-19980424" /> で定義されたパーセントエンコーディング手法を置き換えるために定義されたものではない。この手法はシグニチャベースストリングおよび <xref target="auth_header">authorization ヘッダーフィールド</xref>のエンコーディングにのみ用いられるものである。
          <!--
          Existing percent-encoding methods do not guarantee a consistent construction of the
          signature base string. The following percent-encoding method is not defined to replace
          the existing encoding methods defined by <xref target="RFC3986" /> and
          <xref target="W3C.REC-html40-19980424" />. It is used only in the construction of the
          signature base string and the <xref target="auth_header">authorization header field</xref>.
          -->
        </t>
        <t>
          この仕様書では以下のようにパーセントエンコーディング手法を定義する。
          <!--
          This specification defines the following method for percent-encoding strings:
          -->

          <list style="numbers">
            <t>
              テキスト値がまだ <xref target="RFC3629" /> で定義される UTF-8 オクテットにエンコードされていない場合は、そのようにエンコードする。人間に利用されないバイナリ値は、この行程をスキップする。
              <!--
              Text values are first encoded as UTF-8 octets per <xref target="RFC3629" /> if they are
              not already. This does not include binary values which are not intended for human
              consumption.
              -->
            </t>
            <t>
              値を以下の <xref target="RFC3986" /> で定義されたパーセントエンコーディング手法に従ってエスケープする。
              <!--
              The values are then escaped using the <xref target="RFC3986" /> percent-encoding
              (%XX) mechanism as follows:
              -->

              <list style="symbols">
                <t>
                  <xref target="RFC3986" /> のセクション2.3で定義された予約済みでない文字　(アルファベット, 数字, "-", ".", "_", "~")　はエンコードしてはならない (MUST NOT)。
                  <!--
                  Characters in the unreserved character set as defined by <xref target="RFC3986" />
                  section 2.3 (ALPHA, DIGIT, "-", ".", "_", "~") MUST NOT be encoded.
                  -->
                </t>
                <t>
                  その他の文字は全てエンコードしなければならない (MUST)。
                  <!--
                  All other characters MUST be encoded.
                  -->
                </t>
                <t>
                  エンコード文字を示す2文字の16進数値は大文字でなければならない (MUST)。
                  <!--
                  The two hexadecimal characters used to represent encoded characters MUST be
                  upper case.
                  -->
                </t>
              </list>
            </t>
          </list>
        </t>
        <t>
          この手法は <spanx style="verb">application/x-www-form-urlencoded</spanx> で用いられるエンコード方式とは異なる。(例えばこの手法ではスペースは <spanx style="verb">+</spanx> ではなく <spanx style="verb">%20</spanx> とエンコードされる) この手法は Web デベロップメントフレームワークが提供するパーセントエンコーディングとも異なる可能性がある (MAY)。(異なる文字をエンコードしたり、小文字の16進数文字を使うことなどが想定される)
          <!--
          This method is different from the encoding scheme used by the
          <spanx style="verb">application/x-www-form-urlencoded</spanx> content-type (for example,
          it encodes space characters as <spanx style="verb">%20</spanx> and not using the 
          <spanx style="verb">+</spanx> character). It MAY be different from the
          percent-encoding functions provided by web development frameworks (e.g. encode different
          characters, use lower case hexadecimal characters).
          -->
        </t>
      </section>

    </section>

    <!--
      NOTICE:
        For some reason, xml2rfc requires the section exactly titled "Security Considerations".
        "missing Security Considerations" error will happen when translate it :(
    -->
    <!-- section title="セキュリティに関する考慮事項 " anchor="Security" -->
    <section title="Security Considerations" anchor="Security">
      <t>
        <xref target="RFC2617" /> にあるように、一般的に最大のリスク要因は、プロトコルの本質ではなくそのプロトコルを利用する際のポリシーや手続きにあることが多い。実装者には、このプロトコルがどの程度自らのセキュリティ用件を満たすかを評価することが推奨される。
        <!--
        As stated in <xref target="RFC2617" />, the greatest sources of risks are usually found not
        in the core protocol itself but in policies and procedures surrounding its use. Implementers
        are strongly encouraged to assess how this protocol addresses their security requirements.
        -->
      </t>

      <section title="RSA-SHA1 署名方式">
      <!-- section title="RSA-SHA1 Signature Method" -->
        <t>
          <spanx style="verb">RSA-SHA1</spanx> 署名を用いた認可リクエストでは、トークン共有鍵やクライアント共有鍵は利用されない。そのためこのリクエストは、完全にクライアントが署名生成に使用する秘密鍵の秘匿性に依存する。
          <!--
          Authenticated requests made with <spanx style="verb">RSA-SHA1</spanx> signatures do not
          use the token shared-secret, or any provisioned client shared-secret. This means the request
          relies completely on the secrecy of the private key used by the client to sign requests.
          -->
        </t>
      </section>

      <section title="リクエストの機密性">
      <!-- section title="Confidentiality of Requests" -->
        <t>
          このプロトコルはリクエストの正当性検証のメカニズムを提供するが、リクエストの機密性は保証されない。その他の予防策が施されていない場合、盗聴者はリクエストコンテンツ全体を傍受することができる。サーバーはリクエスト中で送信されているデータの性質を熟慮し、機密情報を含むリソースを保護するために TLS メカニズムを採用するべきである。
          <!--
          While this protocol provides a mechanism for verifying the integrity of requests, it
          provides no guarantee of request confidentiality. Unless further precautions are taken,
          eavesdroppers will have full access to request content. Servers should carefully consider
          the kinds of data likely to be sent as part of such requests, and should employ
          transport-layer security mechanisms to protect sensitive resources.
          -->
        </t>
      </section>

      <section title="サーバーのなりすまし">
      <!-- section title="Spoofing by Counterfeit Servers" -->
        <t>
          このプロトコルはサーバーの信憑性を検証するものではない。敵意を持つ第三者がこの点を悪用し、クライアントのリクエストを傍受して改竄もしくは不正なレスポンスを返す可能性がある。サービスプロバイダーはサービス構築時にこのような攻撃を想定し、サーバーやリクエストレスポンスの信憑性が求められるリクエストでは TLS を採用するべきである。
          <!--
          This protocol makes no attempt to verify the authenticity of the server. A hostile party
          could take advantage of this by intercepting the client's requests and returning
          misleading or otherwise incorrect responses. Service providers should consider such
          attacks when developing services using this protocol, and should require transport-layer
          security for any requests where the authenticity of the server or of request responses is
          an issue.
          -->
        </t>
      </section>

      <section title="要認証コンテンツに対するプロキシおよびキャッシュ">
      <!-- section title="Proxying and Caching of Authenticated Content" -->
        <t>
          <xref target="auth_header">HTTP Authorization スキーム</xref>はオプションであるが、<xref target="RFC2616" /> は <spanx style="verb">Authorization</spanx> および <spanx style="verb">WWW-Authenticate</spanx> ヘッダーフィールドを元に要認証コンテンツの識別を行う。特にこれらのヘッダーフィールドを用いない場合、プロキシやキャッシュが原因となりリクエストの保護が機能しなくなる可能性がある。
          <!--
          The <xref target="auth_header">HTTP Authorization scheme</xref> is optional. However,
          <xref target="RFC2616" /> relies on the <spanx style="verb">Authorization</spanx> and
          <spanx style="verb">WWW-Authenticate</spanx> header fields to distinguish authenticated content
          so that it can be protected. Proxies and caches, in particular, may fail to adequately
          protect requests not using these header fields.
          -->
        </t>
        <t>
          例えば、プライベートな要認証コンテンツは公開アクセスできる形でキャッシュされる可能性がある。<xref target="auth_header">HTTP Authorization ヘッダーフィールド</xref>を用いないサーバーは、<spanx style="verb">Cache-Control</spanx> ヘッダーフィールドなどの他の手段を用いて、要認証コンテンツの保護を保証するべきである。
          <!--
          For example, private authenticated content may be stored in (and thus retrievable from)
          publicly-accessible caches. Servers not using the
          <xref target="auth_header">HTTP Authorization header field</xref> should take care to use other
          mechanisms, such as the <spanx style="verb">Cache-Control</spanx> header field, to ensure that
          authenticated content is protected.
          -->
        </t>
      </section>

      <section title="認証情報のプレインテキストストレージ">
      <!--section title="Plaintext Storage of Credentials"-->
        <t>
          クライアント共有鍵およびトークン共有鍵は、従来の認証システムにおけるパスワードと同様の機能を持つ。<spanx style="verb">RSA-SHA1</spanx> 以外の方法で使用される署名を計算するには、サーバーがそれらの鍵にプレインテキスト形式でアクセスできなければならない。最近の OS がユーザーの認証情報を不可逆なハッシュでのみ保存するのと比べると、これは対照的である。
        </t>
        <!--t>
          The client shared-secret and token shared-secret function the same way passwords do in
          traditional authentication systems. In order to compute the signatures used in methods
          other than <spanx style="verb">RSA-SHA1</spanx>, the server must have access to these
          secrets in plaintext form. This is in contrast, for example, to modern operating systems,
          which store only a one-way hash of user credentials.
        </t-->
        <t>
          もし攻撃者がこれらの鍵のアクセス権、もしくはサーバーの持つすべての鍵データベースへのアクセス権を奪い取った場合、攻撃者はリソースオーナーを装い、あらゆるアクションを起こすことが可能となる。そのため、サーバーはこれらの鍵を権限のない者から厳重に守らなければならない。
        </t>
        <!--t>
          If an attacker were to gain access to these secrets - or worse, to the server's database
          of all such secrets - he or she would be able to perform any action on behalf of any
          resource owner. Accordingly, it is critical that servers protect these secrets from
          unauthorized access.
        </t-->
      </section>

      <section title="クライアントクレデンシャルの秘匿性" anchor="client_cred_sec">
      <!--section title="Secrecy of the Client Credentials" anchor="client_cred_sec"-->
        <t>
          クライアントアプリケーションが信頼性の低い組織の管理下に置かれるケースは少なくない。例えばクライアントがデスクトップアプリケーションで、ソースコードや実行形式のバイナリが公開されている場合、攻撃者が分析のためにコピーをダウンロードし、クライアントクレデンシャルを見付けてしまう可能性がある。
        </t>
        <!--t>
          In many cases, the client application will be under the control of potentially untrusted
          parties. For example, if the client is a desktop application with freely available
          source code or an executable binary, an attacker may be able to download a copy for
          analysis. In such cases, attackers will be able to recover the client credentials.
        </t-->
        <t>
          そういった場合、サーバーはクライアントのアイデンティティを検証する際、クライアントクレデンシャルのみを使うべきではない。可能であれば、IP アドレスのような他の要素も用いるべきである。
        </t>
        <!--t>
          Accordingly, servers should not use the client credentials alone to verify the identity
          of the client. Where possible, other factors such as IP address should be used as well.
        </t-->
      </section>

      <section title="フィッシング攻撃">
      <!--section title="Phishing Attacks"-->
        <t>
          本仕様や類似したプロトコルが広く実用化されると、リソースオーナーがパスワードを入力するウェブサイトにリダイレクトされることに慣れてくる可能性がある。これらのウェブサイトの信頼性を注意深く検証せず、リソースオーナーが認証情報を入力してしまうと、リソースオーナーのパスワードが攻撃者に盗まれてしまう可能性もある。
        </t>
        <!--t>
          Wide deployment of this and similar protocols may cause resource owners to become inured
          to the practice of being redirected to websites where they are asked to enter their
          passwords. If resource owners 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>
          サーバーは、リソースオーナーにフィッシング攻撃のリスクについて情報提供を行い、簡単にウェブサイトの信頼性を検証できる手段を提供すべきである。クライアント開発者はユーザーエージェントとのやりとり (別窓や埋め込み等) におけるセキュリティ上の影響と、エンドユーザーがサーバーウェブサイトの信頼性を検証する能力について考慮すべきである。
        </t>
        <!--t>
          Servers should attempt to educate resource owners about the risks phishing attacks pose,
          and should provide mechanisms that make it easy for resource owners to confirm the
          authenticity of their sites. Client developers should consider the security implications
          of how they interact with a user-agent (e.g. separate window, embedded), and the ability
          of the end-user to verify the authenticity of the server website.
        </t-->
      </section>

      <section title="アクセスリクエストのスコープ">
      <!--section title="Scoping of Access Requests"-->
        <t>
          このプロトコルは、それ自体ではクライアントに許可するアクセス権限のスコープを定める方法を提供していない。しかし、ほとんどのアプリケーションは、アクセス権の細分化を必要としている。例えば、サーバーが特定の保護されたリソースへのアクセスを許可しても、他を許可しなかったり、制限のあるアクセス (読み取り専用等) のみ許可したい場合がある。
        </t>
        <!--t>
          By itself, this protocol does not provide any method for scoping the access rights
          granted to a client. However, most applications do require greater granularity of access
          rights. For example, servers may wish to make it possible to grant access to some
          protected resources but not others, or to grant only limited access (such as read-only
          access) to those protected resources.
        </t-->
        <t>
          このプロトコルを実装する際、サーバーは、リソースオーナーがクライアントに対して許可したいアクセスの形式について考慮し、それを実現する機構を提供すべきである。サーバーは、リソースオーナーが自分の許可しようとしているアクセス権と、それがどんなリスクを持っているかについて理解していることを、注意深く確認すべきである。
        </t>
        <!--t>
          When implementing this protocol, servers should consider the types of access resource
          owners may wish to grant clients, and should provide mechanisms to do so. Servers should
          also take care to ensure that resource owners understand the access they are granting, as
          well as any risks that may be involved.
        </t-->
      </section>

      <section title="認証情報のエントロピー">
      <!--section title="Entropy of Secrets"-->
        <t>
          トランスポート層のセキュリティプロトコルを使用しない場合、盗聴者は認証済みリクエストとシグニチャにアクセスし、クレデンシャルを暴くためにブルートフォース攻撃を仕掛けられる可能性がある。サーバーは、そのような攻撃に対して、少なくとも有効期間中は共有鍵が暴かれないよう、十分な長さでランダムな共有鍵にすべきである。
        </t>
        <!--t>
          Unless a transport-layer security protocol is used, eavesdroppers will have full access
          to authenticated requests and signatures, and will thus be able to mount offline brute-force
          attacks to recover the credentials used. Servers should be careful to assign
          shared-secrets which are long enough, and random enough, to resist such attacks for at
          least the length of time that the shared-secrets are valid.
        </t-->
        <t>
          例えば、2週間共有鍵を有効にした場合、サーバーは、2週間以内にブルートフォース攻撃が共有鍵を暴くことが不可能であることを確認すべきである。勿論、サーバーは、十分な長さの鍵を用いて対処すべきである。
        </t>
        <!--t>
          For example, if shared-secrets are valid for two weeks, servers should ensure that it is
          not possible to mount a brute force attack that recovers the shared-secret in less than
          two weeks. Of course, servers are urged to err on the side of caution, and use the longest
          secrets reasonable.
        </t-->
        <t>
          鍵を生成する Pseudo-Random Number Generator (疑似乱数生成器) が高い品質であることは重要である。ランダムな数列を生成していても、暗号解読やブルートフォース攻撃を容易にするようなパターンや脆弱性を持つ PRNG 実装は多い。実装者はこうした問題の無い安全な PRNG を使用すべきである。
        </t>
        <!--t>
          It is equally important that the pseudo-random number generator (PRNG) used to generate
          these secrets be of sufficiently high quality. Many PRNG implementations generate number
          sequences that may appear to be random, but which nevertheless exhibit patterns or other
          weaknesses which make cryptanalysis or brute force attacks easier. Implementers should be
          careful to use cryptographically secure PRNGs to avoid these problems.
        </t-->
      </section>

      <section title="DoS 攻撃 / リソース枯渇攻撃">
      <!--section title="Denial of Service / Resource Exhaustion Attacks"-->
        <t>
          この仕様には、サーバーリソースを枯渇させる攻撃を可能にする特徴が多くある。例えば、サーバーにノンス値が使用済みかを検査するよう要求している。攻撃者が瞬時に多数のノンス値を使用できる場合、それらを検査するのにサーバーはリソースを枯渇させてしまうだろう。更に、リクエストの署名を検証するためにサーバーに高い計算能力を要求している。攻撃者は、不正なリクエストを大量に送る DoS 攻撃でこの計算能力を使い尽くそうとするだろう。
        </t>
        <!--t>
          This specification includes a number of features which may make resource exhaustion
          attacks against servers possible. For example, this protocol requires servers to track
          used nonces. If an attacker is able to use many nonces quickly, the resources required to
          track them may exhaust available capacity. And again, this protocol can require servers
          to perform potentially expensive computations in order to verify the signature on
          incoming requests. An attacker may exploit this to perform a denial of service attack by
          sending a large number of invalid requests to the server.
        </t-->
        <t>
          リソース枯渇攻撃は決してこの仕様だけの特有のものではないが、実装者はこの仕様が枯渇攻撃の方法を顕在化させていることに考慮し十分な設計を行うべきである。例えば、エントロピーの不足は、得てして、新たなエントロピーを待つ間に DoS や弱い (推測しやすい) 鍵をもたらすことになる。実装に当たりサーバーは、これらがアプリケーションに深刻なリスクをもたらすことを考慮して十分に設計すべきである。
        </t>
        <!--t>
          Resource Exhaustion attacks are by no means specific to this specification. However,
          implementers should be careful to consider the additional avenues of attack that this
          protocol exposes, and design their implementations accordingly. For example, entropy
          starvation typically results in either a complete denial of service while the system
          waits for new entropy or else in weak (easily guessable) secrets. When implementing this
          protocol, servers should consider which of these presents a more serious risk for their
          application and design accordingly.
        </t-->
      </section>

      <section title="SHA-1 攻撃">
      <!--section title="SHA-1 Cryptographic Attacks"-->
        <t>
          <spanx style="verb">HMAC-SHA1</spanx> 署名方式、<spanx style="verb">RSA-SHA1</spanx> 署名方式で使用されている SHA-1 はコリジョン攻撃に対して多くの脆弱性を持つことが分かっている。この脆弱性は、<spanx style="verb">HMAC-SHA1</spanx> 署名方式の利用には影響無いようであるが、<spanx style="verb">RSA-SHA1</spanx> 署名方式には影響がある。NIST は、電子署名として SHA-1 を用いることを 2010 年までに段階的に廃止していくよう案内している。<xref target="NIST SHA-1 Comments" />
        </t>
        <!--t>
          SHA-1, the hash algorithm used in <spanx style="verb">HMAC-SHA1</spanx> and
          <spanx style="verb">RSA-SHA1</spanx> signature methods, has been shown to have a number
          of cryptographic weaknesses that significantly reduce its resistance to collision
          attacks. While these weaknesses do not seem to affect the use of SHA-1 with the
          Hash-based Message Authentication Code (HMAC) and should not affect the
          <spanx style="verb">HMAC-SHA1</spanx> signature method, it may affect the use of the
          <spanx style="verb">RSA-SHA1</spanx> signature method. NIST has announced that it will
          phase out use of SHA-1 in digital signtures by 2010 <xref target="NIST SHA-1 Comments" />.
        </t-->
        <t>
          実際のところ、この脆弱性を利用するのは難しく、利用者に重大なリスクをもたらすことはないが、より効率的な攻撃が可能になるかも知れず、サーバーは、SHA-1 が十分なレベルのセキュリティをアプリケーションにもたらすかを考える時、このことを留意しておくべきである。
        </t>
        <!--t>
          Practically speaking, these weaknesses are difficult to exploit, and by themselves do not
          pose a significant risk to users of this protocol. They may, however, make more efficient
          attacks possible, and  Servers should take this into account when considering whether
          SHA-1 provides an adequate level of security for their applications.
        </t-->
      </section>

      <section title="シグニチャベースストリングの制約">
      <!-- section title="Signature Base String Limitations" -->
        <t>
          シグニチャベースストリングはこの仕様で定義された署名方式をサポートするために設計された。今後署名方式を追加する設計者は、シグニチャベースストリングの互換性、および設計におけるセキュリティ要件を評価すべきである。
          <!--
          The signature base string has been designed to support the signature methods defined in
          this specification. Those designing additional signature methods, should evaluated the
          compatibility of the signature base string with their security requirements.
          -->
        </t>
        <t>
          多くのリクエストエンティティボディーおよびエンティティヘッダー、パラメータの出現順序などの情報は、シグニチャベースストリングには含まれない。このようにシグニチャベースストリングは HTTP リクエスト全体をカバーするものではないため、サーバーはシグニチャベースストリングに含まれない要素を保護するメカニズムを追加導入すべきである。
          <!--
          Since the signature base string does not cover the entire HTTP request, such as most
          request entity-body, most entity-headers, and the order in which parameters are sent,
          servers should employ additional mechanisms to protect such elements.
          -->
        </t>
      </section>

      <section title="Cross-Site Request Forgery (CSRF)">
        <t>
          Cross-Site Request Forgery (CSRF) は HTTP リクエストが信頼されたもしくは認証済みのユーザから送信される Web ベースの攻撃である。認可取得時に攻撃者が CSRF 攻撃をしかけることで、攻撃者はユーザの同意無しに保護されたリソースへの認可を得ることができる。サーバーはすべてのプロトコル認可エンドポイントにおいて、CSRF 対策のベストプラクティスを熟慮するべきである (SHOULD)。
          <!--
          Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are
          transmitted from a user that the website trusts or has authenticated. CSRF attacks on
          authorization approvals can allow an attacker to obtain authorization to protected
          resources without the consent of the User. Servers SHOULD strongly consider best
          practices in CSRF prevention at all the protocol authorization endpoints.
          -->
        </t>
        <t>
          CSRF 攻撃は、クライアントの OAuth コールバック URI においても可能である。クライアントは OAuth コールバック URI で、クライアントサイトにおけるリソースオーナーがサーバーと OAuth 通信を完了させる意思のあることを検証することで、CSRF 攻撃を防ぐべきである。この種の CSRF 攻撃の防御策はこの仕様の範囲外である。
          <!--
          CSRF attacks on OAuth callback URIs hosted by clients are also possible. Clients should
          prevent CSRF attacks on OAuth callback URIs by verifying that the resource owner at the
          client site intended to complete the OAuth negotiation with the server. The methods for
          preventing such CSRF attacks are beyond the scope of this specification.
          -->
        </t>
      </section>

      <section title="User Interface Redress">
        <t>
          サーバーは認可プロセスにおける UI Redress 攻撃 ("クリックジャッキング" としても知られる) を防ぐべきである。この仕様執筆時においては、完全な UI redress の対策法は存在しない。サーバーは以下の技術により UI redress のリスクを軽減することができる。
          <!--
          Servers should protect the authorization process against UI Redress attacks (also known
          as "clickjacking"). As of the time of this writing, no complete defenses against UI
          redress are available. Servers can mitigate the risk of UI redress attacks through the
          following techniques:
          -->

          <list style="symbols">
            <t>
              Javascript によるフレーム解除。
              <!--
              Javascript frame busting.
              -->
            </t>
            <t>
              Javascript によるフレーム解除、および認可ページでブラウザの Javascript を有効にすることを要求。
              <!--
              Javascript frame busting, and requiring that browsers have javascript enabled on the
              authorization page.
              -->
            </t>
            <t>
              ブラウザ固有のフレーム対策技術。
              <!--
              Browser-specific anti-framing techniques.
              -->
            </t>
            <t>
              OAuth token 発行前にパスワード再入力を要求。
              <!--
              Requiring password reentry before issuing OAuth tokens.
              -->
            </t>
          </list>
        </t>
      </section>

      <section title="再認可の自動処理">
      <!-- section title="Automatic Processing of Repeat Authorizations" -->
        <t>
          サーバーは既にリソースオーナーの認可を得たクライアントからの認可リクエスト (<xref target="auth_step2" />) を自動的に処理することを望むかもしれない。リソースオーナーがアクセス承認のためにサーバーにリダイレクトされる時、サーバーはリソースーオーナーが既にそのクライアントからのアクセスを承認していることを検知したとする。その場合サーバーはリソースオーナーに承認を求める代わりに、リソースオーナーを自動的にクライアントにリダイレクトさせる。
          <!--
          Servers may wish to automatically process authorization requests
          (<xref target="auth_step2" />) from clients which have been previously
          authorized by the resource owner. When the resource owner is redirected to the server
          to grant access, the server detects that the resource owner has already granted
          access to that particular client. Instead of prompting the resource owner for approval,
          the server automatically redirects the resource owner back to the client.
          -->
        </t>
        <t>
          クライアントクレデンシャルが漏洩している場合、自動処理はさらなるセキュリティリスクを生み出す。攻撃者は漏洩したクライアントクレデンシャルを使ってリソースオーナーをサーバーにリダイレクトさせ、認可リクエストを行うことができる。そうするとサーバーはリソースオーナーに承認を求めずに、リソースオーナーへのアクセスを承認することになる。もちろん攻撃への注意喚起なども行わない。自動承認が実装されていなければ、攻撃者はリソースオーナーにアクセスを承認させるためにソーシャルエンジニアリングを用いなければならなくなる。
          <!--
          If the client credentials are compromised, automatic processing creates additional
          security risks. An attacker can use the stolen client credentials to redirect
          the resource owner to the server with an authorization request. The server
          will then grant access to the resource owner's data without the resource owner's
          explicit approval, or even awareness of an attack. If no automatic approval is
          implemented, an attacker must use social engineering to convince the resource owner to
          approve access.
          -->
        </t>
        <t>
          サーバーは自動処理に由来するリスクを軽減するため、自動承認プロセスを通じて発行されるトークンクレデンシャルのスコープを限定することができる。リソースオーナーの同意を得て発行されたトークンクレデンシャルに対して影響を与える必要はない。クライアントはクライアントクレデンシャルを保護することで、自動処理に由来するリスクを軽減することができる。
          <!--
          Servers can mitigate the risks associated with automatic processing by
          limiting the scope of token credentials obtained through automated approvals. Tokens
          credentials obtained through explicit resource owner consent can remain unaffected. Clients
          can mitigate the risks associated with automatic processing by protecting their client
          credentials.
          -->
        </t>
      </section>

    </section>

    <section title="IANA に関する考察" anchor="IANA">
    <!--section title="IANA Considerations" anchor="IANA"-->
      <t>
        このメモは IANA へのリクエストを含まない。
      </t>
      <!--t>
        This memo includes no request to IANA.
      </t-->
    </section>

    <section title="謝辞">
    <!--section title="Acknowledgments"-->
      <t>
        この仕様は、複数の企業により個別に実装された、既存の独自プロトコルおよびベストプラクティスを元にして作成された、コミュニティ仕様 OAuth Core 1.0 Revision A に、直接的に基づくものである。
      </t>
      <!--t>
        This specification is directly based on the OAuth Core 1.0 Revision A community
        specification which in turn was modeled after existing proprietary protocols and best
        practices that have been independently implemented by various companies.
      </t-->
      <t>
        コミュニティ仕様は Eran Hammer-Lahav による編集、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-Lahav、Ben Laurie、Chris Messina、John Panzer、Sam Quigley、David Recordon、Eran Sandler、Jonathan Sergent、Todd Sieling、Brian Slesinsky、Andy Smith による著作である。
      </t>
      <!--t>
        The community specification was edited by Eran Hammer-Lahav 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-Lahav,
        Ben Laurie, Chris Messina, John Panzer, Sam Quigley, David Recordon, Eran Sandler,
        Jonathan Sergent, Todd Sieling, Brian Slesinsky, and Andy Smith.
      </t-->
      <t>
        編集者は、本エディションの公開について、多大な貢献を行った次の人々に感謝する。Lisa Dusseault、Justin Hart、Avshalom Houri、Chris Messina、Mark Nottingham、Tim Polk、Peter Saint-Andre、Joseph Smarr、Paul Walker。
      </t>
      <!--t>
        The editor would like to thank the following individuals for their invaluable contribution
        to the publication of this edition of the protocol: Lisa Dusseault, Justin Hart,
        Avshalom Houri, Chris Messina, Mark Nottingham, Tim Polk, Peter Saint-Andre, Joseph Smarr,
        and Paul Walker.
      </t-->
    </section>
    
    <appendix title="コミュニティ版との違い">
    <!--appendix title="Differences from the Community Edition"-->
      <t>
        本仕様は、元のコミュニティ仕様 <xref target="OAuth Core 1.0 Revision A" /> が公開されてから発見された、以下の間違いや欠落を修正するための変更点を含む。
        <!--
        This specification includes the following changes made to the original community document
        <xref target="OAuth Core 1.0 Revision A" /> in order to correct mistakes and omissions
        identified since the document has been published:
        -->
        
        <list style="symbols">
          <t>
            プレインテキストクレデンシャル送信時の TLS/SSL 利用を SHOULD から MUST に変更。この変更により<xref target="auth_step1">テンポラリクレデンシャルのリクエスト</xref>および<xref target="auth_step3">トークンクレデンシャルの取得</xref>だけでなく、<spanx style="verb">PLAINTEXT</spanx> 署名方式の利用が影響を受ける。
          </t>
          <!--t>
            Changed using TLS/SSL when sending or requesting plain text credentials from SHOULD
            to MUST. This change affects any use of the <spanx style="verb">PLAINTEXT</spanx>
            signature method, as well as <xref target="auth_step1">requesting temporary credentials</xref>
            and <xref target="auth_step3">obtaining token credentials</xref>.
          </t-->
          <t>
            トークン／タイムスタンプ／クライアントの組み合わせごとにユニークになるよう、ノンスの表現を調整。
          </t>
          <!--t>
            Adjusted nonce language to indicate it is unique per token/timestamp/client combination.
          </t-->
          <t>
            タイムスタンプが、前回のリクエストで利用されたものよりも大きいか、同等である必要がある旨を削除。
          </t>
          <!--t>
            Removed the requirement for timestamps to be equal to or greater than the timestamp
            used in the previous request.
          </t-->
          <t>
            <spanx style="verb">PLAINTEXT</spanx> 署名方式利用時のノンスおよびタイムスタンプパラメータを、オプションに変更。
          </t>
          <!--t>
            Changed the nonce and timestamp parameters to OPTIONAL when using the
            <spanx style="verb">PLAINTEXT</spanx> signature method.
          </t-->
          <t>
            利用される HTTP メソッドが <spanx style="verb">POST</spanx> 以外の場合の <spanx style="verb">application/x-www-form-urlencoded</spanx> エンティティボディパラメータを含むシグニチャベースストリングを拡張。また、HTTP メソッドが <spanx style="verb">GET</spanx> 以外の場合の URI クエリパラメータを拡張。
          </t>
          <!--t>
            Extended signature base string coverage which includes <spanx style="verb">application/x-www-form-urlencoded</spanx>
            entity-body parameters when the HTTP method used is other than <spanx style="verb">POST</spanx> and URI query
            parameters when the HTTP method used is other than <spanx style="verb">GET</spanx>.
          </t-->
          <t>
            二重エンコードによるエラーを防ぐため、各署名方式の解説に、<spanx style="verb">oauth_signature</spanx> パラメータにシグニチャ値を挿入する前に、エンコードする旨を追加。
          </t>
          <!--t>
            incorporated corrections to the instructions in each signature method to encode the signature
            value before inserting it into the <spanx style="verb">oauth_signature</spanx> parameter,
            removing errors which would have caused double-encoded values.
          </t-->
          <t>
            <spanx style="verb">oauth_token</spanx> パラメータが空の場合、省略可能とした。
          </t>
          <!--t>
            allowed omitting the <spanx style="verb">oauth_token</spanx> parameter when empty.
          </t-->
          <t>
            空の <spanx style="verb">oauth_token</spanx> パラメータを使ったテンポラリクレデンシャルのリクエスト送信を許可。
          </t>
          <!--t>
            Permitted sending requests for temporary credentials with an empty
            <spanx style="verb">oauth_token</spanx> parameter.
          </t-->
          <t>
            <spanx style="verb">oauth_</spanx> パラメータの追加定義を制限する記述を削除。
          </t>
          <!--t>
            Removed the restrictions from defining additional <spanx style="verb">oauth_</spanx>
            parameters.
          </t-->
        </list>
      </t>
    </appendix>

    <appendix title="Document History" anchor="history">
      <t>
        [[ To be removed by the RFC editor before publication as an RFC. ]]
      </t>
      <t>
        -10
        <list style="symbols">
          <t>
            Added missing 'oauth_token' in exmaple.
          </t>
          <t>
            Changed realm values from URI to string to make them more generic (since
            the protocol does not define any internal structure for them).
          </t>
        </list>
      </t>
      <t>
        -09
        <list style="symbols">
          <t>
            Added 'with a 200 status code (OK)' in two places.
          </t>
          <t>
            Missing comma in example.
          </t>
          <t>
            Corrected typos.
          </t>
          <t>
            Changed the use of TLS/SSL when sending or receiving plain text credentials to a MUST.
          </t>
          <t>
            Clarified text about change control moving from the community to the IETF.
          </t>
        </list>
      </t>
      <t>
        -08
        <list style="symbols">
          <t>
            Adjusted timestamp language to allow use of time servers for clock sync.
          </t>
          <t>
            Revised security language for SHA-1 weakness and applicability.
          </t>
          <t>
            Added link to the community specification.
          </t>
          <t>
            Minor editorial changes.
          </t>
        </list>
      </t>
      <t>
        -07
        
        <list style="symbols">
          <t>
            Corrected typos.
          </t>
          <t>
            Changed examples to use HTTPS in authorization step.
          </t>
          <t>
            Clarified the use of 'oauth_' tokens in the three static endpoint URIs.
          </t>
          <t>
            Edited abstract and introduction.
          </t>
        </list>
      </t>
      <t>
        -06

        <list style="symbols">
          <t>
            Moved parameter section into client instructions.
          </t>
          <t>
            Added more examples in the delegation section, including more complete HTTP responses.
          </t>
          <t>
            Removed language about restricting the use of the 'oauth_' prefix.
          </t>
          <t>
            Changed the nonce and timestamp parameters to optional when using PLAINTEXT.
          </t>
          <t>
            Allowed empty token in temporary credentials requests.
          </t>
        </list>
      </t>
      <t>
        -05
        
        <list style="symbols">
          <t>
            Replaced the word 'lexicographical' with 'ascending' in sorting instructions.
          </t>
          <t>
            Added note that the 'a3' parameter appears twice in the example.
          </t>
          <t>
            Made the note about the encoding scheme being different from most common implementations
            more explicit.
          </t>
          <t>
            Moved and cleaned up the example from appendix to introduction. Removed crypto details
            from the example.
          </t>
        </list>
      </t>
      <t>
        -04
        
        <list style="symbols">
          <t>
            Corrected typo and other minor editorial changes.
          </t>
          <t>
            Added warning about token sizes.
          </t>
          <t>
            Clarified that all 'oauth_' parameters must be transmitted using the same method.
          </t>
          <t>
            Added explicit requirement to exclude parameters not transmitted in a request in the
            signature base string (for example oauth_version when omitted).
          </t>
          <t>
            Explicitly set OAuth to use HTTP 1.1.
          </t>
          <t>
            Rearranged the signature base string section to provide a better narrative of how the
            HTTP request is normalized. Added the protocol parameters to the examples to better
            demonstrate how they are incorporated in practice.
          </t>
          <t>
            Flipped the document order between authentication and authorization.
          </t>
          <t>
            Removed the requirement for timestamps to be equal or greater than previous timestamps.
          </t>
        </list>
      </t>
      <t>
        -03

        <list style="symbols">
          <t>
            Updated draft with changes from OAuth Core 1.0 Revision A to fix a session fixation exploit.
          </t>
          <t>
            Small editorial corrections.
          </t>
          <t>
            Removed confusing language from 'Denial of Service / Resource Exhaustion Attacks'.
          </t>
          <t>
            Added new 'Differences from the Community Edition' appendix.
          </t>
          <t>
            Updated acknowledgements section.
          </t>
        </list>
      </t>
      <t>
        -02

        <list style="symbols">
          <t>
            Corrected mistake in parameter sorting order (c%40 comes before c2).
          </t>
          <t>
            Added requirement to normalize empty paths as '/'.
          </t>
        </list>
      </t>
      <t>
        -01

        <list style="symbols">
          <t>
            Complete rewrite of the entire specification from scratch. Separated the spec structure
            into two parts and flipped their order.
          </t>
          <t>
            Corrected errors in instructions to encode the signature base string by some methods. The
            signature value is encoded using the transport rules, not the spec method for encoding.
          </t>
          <t>
            Replaced the entire terminology.
          </t>
        </list>
      </t>
      <t>
        -00

        <list style="symbols">
          <t>
            Initial draft based on the OAuth Core 1.0 community specification
            with the following changes.
          </t>
          <t>
            Various changes required to accommodate the strict format requirements of the IETF,
            such as moving sections around (Security, Contributors, Introduction, etc.), cleaning
            references, adding IETF specific text, etc.
          </t>
          <t>
            Moved the Parameter Encoding sub-section from section 5 (Parameters) to section 9.1
            (Signature Base String) to make it clear it only applies to the signature base string.
          </t>
          <t>
            Nonce language adjusted to indicate it is unique per token/timestamp/consumer
            combination.
          </t>
          <t>
            Added security language regarding lack of token secrets in RSA-SHA1.
          </t>
          <t>
            Fixed the bug in the Normalize Request Parameters section. Removed the
            <spanx style="verb">GET</spanx> limitation from the third bullet (query parameters).
          </t>
          <t>
            Removed restriction of only signing application/x-www-form-urlencoded in
            <spanx style="verb">POST</spanx> requests, allowing the entity-body to be used with all
            HTTP request methods.
          </t>
        </list>
      </t>
    </appendix>

  </middle>

  <back>

    <references title="Normative References">

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2104.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3447.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-html40-19980424.xml"?>
      
    </references>

    <references title="Informative References">

      <reference anchor="OAuth Core 1.0 Revision A">
        <front>
          <title>OAuth Core 1.0 Revision A</title>
          <author initials="OAuth Community" surname="OAuth" fullname="OAuth Community">
            <organization />
          </author>
        </front>
        <format type="HTML" target="http://oauth.net/core/1.0a" />
      </reference>

      <reference anchor="NIST SHA-1 Comments">
        <front>
          <title>NIST Comments on Cryptanalytic Attacks on SHA-1</title>
          <author initials="W.E.B" surname="Burr" fullname="William E. Burr">
            <organization>NIST</organization>
          </author>
        </front>
        <format type="html" target="http://csrc.nist.gov/groups/ST/hash/statement.html" />
      </reference>

    </references>
  </back>

</rfc>