root/docs/openid/specs/authentication/2.0/trunk/openid-authentication.xml @ 9589

Revision 9589, 223.3 kB (checked in by drry, 7 years ago)

docs/openid/specs/authentication/2.0/trunk/openid-authentication.xml:

  • 「関連付いた」
  • 「ディスカバリー」
  • Property svn:mime-type set to text/xml; charset=utf-8
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
3<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
4
5<rfc category="info" ipr="full3978" docName="openid-authentication-2_0.xml" xml:lang="ja">
6
7  <?rfc toc="yes"?>
8  <?rfc tocdepth="2"?>
9  <?rfc symrefs="yes"?>
10  <?rfc sortrefs="yes"?>
11  <?rfc strict="yes"?>
12  <?rfc iprnotified="no"?>
13  <?rfc private="Final"?>
14
15  <front>
16    <title>OpenID Authenticaion 2.0 - 最終版</title>
17
18    <author initials="" surname="specs@openid.net" fullname="specs@openid.net">
19      <organization/>
20    </author>
21
22    <date month="December" year="2007"/>
23
24    <abstract>
25      <!--
26          <t>
27          OpenID Authentication provides a way to prove that an end user
28          controls an Identifier. It does this without the Relying Party
29          needing access to end user credentials such as a password or
30          to other sensitive information such as an email address.
31          </t>
32      -->
33
34      <t>
35        OpenID AuthenticationはエンドユーザーがIdentifierを取り扱う際に信頼できる方法を提供します。その方法とはRelying Partyがパスワードのようなエンドユーザーのクレデンシャルやメールアドレスのような他のセンシティブな情報にアクセスする必要のないものです。
36      </t>
37
38      <!--
39          <t>
40          OpenID is decentralized. No central authority must approve or
41          register Relying Parties or OpenID Providers. An end user
42          can freely choose which OpenID Provider to use, and can
43          preserve their Identifier if they switch OpenID Providers.
44          </t>
45      -->
46
47      <t>
48        OpenIDは中央集権的ではありません。Relying PartyやOpenIDプロバイダを承認したり登録したりする中心となる権威も存在しません。エンドユーザーは利用するOpenIDプロバイダを自由に選択する事ができ、さらにOpenIDプロバイダを変えたとしても自分達のIdentifierを保つ事が可能です。
49      </t>
50
51      <!--
52          <t>
53          While nothing in the protocol requires JavaScript or modern
54          browsers, the authentication scheme plays nicely with
55          "AJAX"-style setups. This means an end user can prove their
56          Identity to a Relying Party without having to leave their
57          current Web page.
58          </t>
59      -->
60
61      <t>
62        このプロトコルではJavaScriptやモダンブラウザを必要とはしませんが、この認証スキーマは"AJAX"スタイルのセットアップで上手く動作します。この事が意味するのはエンドユーザーが現在居るページから離れる事無く、自分達のアイデンティティをRelying Partyに信用させる事が可能だと言う事です。
63      </t>
64
65      <!--
66          <t>
67          OpenID Authentication uses only standard HTTP(S) requests and
68          responses, so it does not require any special capabilities of
69          the User-Agent or other client software. OpenID is not tied to
70          the use of cookies or any other specific mechanism of Relying
71          Party or OpenID Provider session management. Extensions to
72          User-Agents can simplify the end user interaction, though are
73          not required to utilize the protocol.
74          </t>
75      -->
76
77      <t>
78        OpenID Authenticationは標準的なHTTP(S)リクエストとレスポンスのみを利用しているので、User-Agentに対して如何なる特別な機能も要求しなければ、他のクライアントソフトウェアを必要とすることもありません。OpenIDはCookieの使用や、Relying PartyやOpenIDプロバイダのセッション管理で、如何なる他の特別なメカニズムにも縛られません。
79      </t>
80
81      <!--
82          <t>
83          The exchange of profile information, or the exchange of other
84          information not covered in this specification, can be addressed
85          through additional service types built on top of this
86          protocol to create a framework. OpenID Authentication is
87          designed to provide a base service to enable portable,
88          user-centric digital identity in a free and decentralized manner.
89          </t>
90      -->
91
92      <t>
93        プロフィール情報の交換や、この仕様の中で規定されていない他の情報の交換はフレームワークを作る為のこのプロトコルの上で作られる追加されたサービス型を通して示されることが出来るでしょう。OpenID Authenticationは移植が可能になるようなサービスのベースとユーザー中心の自由で分散化された方法の中のデジタルアイデンティティ提供する為に設計されています。
94      </t>
95    </abstract>
96
97  </front>
98
99  <middle>
100    <section title="Requirements Notation and Conventions - 要求する表記法と慣習">
101      <!--
102           See RFC2119 Japanese translation.
103           http://www.t-net.ne.jp/~cyfis/rfc/format/rfc2119_ja.html
104      -->
105
106      <!--
107          <t>
108          The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
109          "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
110          and "OPTIONAL" in this document are to be interpreted as
111          described in <xref target="RFC2119"/>.
112          </t>
113      -->
114
115      <t>
116        この文書の中のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、<xref target="RFC2119"/>中で示された物として解釈されることになっています。
117      </t>
118
119      <!--
120          <t>
121          Throughout this document, values are quoted to indicate that
122          they are to be taken literally. When using these values in
123          protocol messages, the quotes MUST NOT be used as part of the
124          value.
125          </t>
126      -->
127
128      <t>
129        このドキュメントの至るところで忠実に導かれた物を指し示す為に値がクォートされています。プロトコルメッセージ中にこれらの値が使われた場合は、値の一部として使用「してはなりません」(MUST NOT)。
130      </t>
131
132    </section>
133
134    <section title="Terminology - 用語" anchor="terminology">
135      <t>
136        <list style="hanging">
137          <t hangText="Identifier:">
138            <!--
139                An Identifier is either a "http" or "https" URI, (commonly
140                referred to as a "URL" within this document), or an <xref
141                target="XRI_Syntax_2.0">XRI</xref>. This document defines
142                various kinds of Identifiers, designed for use in different
143                contexts.
144            -->
145            Identifierは「http」または「https」のURI(共通的にこの文書の中で「URL」として関連するもの)、または<xref
146            target="XRI_Syntax_2.0">XRI</xref>の事です。この文書は異なるコンテキストの中で使われる為に設計された様々な種類のIdentifierを定義しています。
147          </t>
148
149          <t hangText="User-Agent:">
150            <!--
151                 The end user's Web browser which implements HTTP/1.1 <xref target="RFC2616"/>.
152            -->
153            HTTP/1.1 <xref target="RFC2616"/>を実装したエンドユーザーのウェブブラウザの事です。
154          </t>
155
156          <t hangText="Relying Party:">
157            <!--
158                 RP. A Web application that wants proof that the end user
159                 controls an Identifier.
160            -->
161            RPと略します。エンドユーザーが取り扱うIdentifierの証明を希望しているウェブアプリケーションの事です。
162          </t>
163
164          <t hangText="OpenID Provider:">
165            <!--
166                 OP. An OpenID Authentication server on which a Relying
167                 Party relies for an assertion that the end user controls
168                 an Identifier.
169            -->
170            OPと略します。Relying Partyがエンドユーザーが扱うIdentifierのアサーションに関して当てにされているOpenID認証サーバの事です。
171          </t>
172
173          <t hangText="OP Endpoint URL:">
174            <!--
175                The URL which accepts OpenID Authentication protocol messages,
176                obtained by performing discovery on the User-Supplied
177                Identifier. This value MUST be an absolute HTTP or HTTPS URL.
178            -->
179            OpenID認証プロトコルのメッセージを受け付けるURLの事で、User-Supplied Identifier上で探索を実行することによって得られる。この値はHTTPまたはHTTPSの絶対URLと「しなければならない」(MUST)。
180          </t>
181
182          <t hangText="OP Identifier:">
183            <!--
184                An Identifier for an OpenID Provider.
185            -->
186            OpenIDプロバイダの為のIdentifierの事。
187          </t>
188
189          <t hangText="User-Supplied Identifier:">
190            <!--
191                An Identifier that was presented by the end user to the
192                Relying Party, or selected by the user at the OpenID
193                Provider. During the initiation phase of the protocol,
194                an end user may enter either their own Identifier or an OP
195                Identifier. If an OP Identifier is used, the OP may then
196                assist the end user in selecting an Identifier to share with
197                the Relying Party.
198            -->
199            Relying Partyに対してエンドユーザーによって示された、あるいはOpenIDプロバイダーにおいてユーザーによって選択されたIdentifierの事。プロトコルの初期化フェーズの時に、エンドユーザーは自身の所有するIdentifier、あるいはOP Identifierのいずれかを入力するでしょう。もしOP Identifierを使用した場合、OPはRelying Partyと共有するためのIdentifierの選択を助けなければならないでしょう。
200          </t>
201
202          <t hangText="Claimed Identifier:">
203            <!--
204                An Identifier that the end user claims to own; the overall
205                aim of the protocol is verifying this claim. The Claimed
206                Identifier is either:
207            -->
208            エンドユーザーが自分の物であると主張するIdentifierの事。全般的なこのプロトコルの目的はこの主張を検証する事である。そのClaimed Identifierは以下のいずれかである。
209            <list style="symbols">
210              <t>
211                <!--
212                    The Identifier obtained by <xref target="normalization">
213                    normalizing</xref> the User-Supplied Identifier, if it
214                    was an URL.
215                -->
216                そのIdentifierがURLであったならば、User-Supplied Identifierを<xref target="normalization">正規化</xref>した物によって得られる。
217              </t>
218              <t>
219                <!--
220                    The <xref target="canonicalid">CanonicalID</xref>, if it
221                    was an XRI.
222                -->
223                そのIdentifierがXRIであったならば、それは<xref target="canonicalid">CanonicalID</xref>である。
224              </t>
225            </list>
226          </t>
227
228          <t hangText="OP-Local Identifier:">
229            <!--
230                An alternate Identifier for an end user that is local to a
231                particular OP and thus not necessarily under the end user's
232                control.
233            -->
234            特定のOPの固有のエンドユーザーの為の別のIdentifierの事です。従ってエンドユーザーの管理下にある必要性はありません。
235          </t>
236        </list>
237      </t>
238    </section>
239
240    <section title="Protocol Overview - プロトコル概要">
241
242      <t>
243        <list style="numbers">
244          <t>
245            <!--
246              The end user <xref target="initiation">initiates
247              authentication</xref> by presenting a User-Supplied Identifier
248              to the Relying Party via their User-Agent.
249            -->
250            エンドユーザーが<xref target="initiation">認証を始める</xref>には、User-Agentを介してRPにUser-Supplied Identifierを提示します。
251          </t>
252          <t>
253            <!--
254              After <xref target="normalization">normalizing</xref> the
255              User-Supplied Identifier, the Relying Party <xref
256              target="discovery">performs discovery</xref> on it and
257              establishes the OP Endpoint URL that the end user uses for
258              authentication. It should be noted that the User-Supplied
259              Identifier may be an OP Identifier, as discussed in <xref
260              target="discovered_info"/>, which allows selection of a
261              Claimed Identifier at the OP or for the protocol to
262              proceed without a Claimed Identifier if something else
263              useful is being done via an <xref
264              target="extensions">extension</xref>.
265            -->
266            User-Supplied Identifierが<xref target="normalization">正規化</xref>されると、RP は<xref
267            target="discovery">探索を行い</xref>、エンドユーザーが認証に使うOP Endpoint URLを確立します。注意点: <xref
268            target="discovered_info"/> で述べていますが、User-Supplied IdentifierはOP
269            Identifierであるかもしれません。その場合、OPのClaimed Identifierを用いるか、用いずに何か他の便利な<xref
270            target="extensions">拡張</xref>手段を使ってプロトコルを処理するか、という選択肢があります。
271          </t>
272          <t>
273            <!--
274              (optional)
275
276              The Relying Party and the OP establish an <xref
277              target="associations">association</xref> - a shared
278              secret established using <xref
279              target="RFC2631">Diffie-Hellman Key Exchange</xref>. The
280              OP uses an association to sign subsequent messages and the
281              Relying Party to verify those messages; this removes the
282              need for subsequent direct requests to verify the
283              signature after each authentication request/response.
284            -->
285            (オプション)
286
287            RPとOPは、<xref target="associations">関連付け (association)</xref>をつくります。関連付けは<xref
288            target="RFC2631">Diffie-Hellman 鍵共有法 (DH 法)</xref>を用いた共有暗号鍵
289            (shared secret)です。以降のメッセージは、この関連付けを使ってOPに署名され、RPに検証されます。こうすることで、いちいち署名を検証するよう要求を出すという手間が省けるというわけです。
290          </t>
291          <t>
292            <!--
293              The Relying Party redirects the end user's User-Agent to
294              the OP with an OpenID <xref
295              target="requesting_authentication">Authentication
296              request</xref>.
297            -->
298            RPは、OpenIDの<xref target="requesting_authentication">認証要求</xref>をつけて、エンドユーザーのUser-AgentをOPにリダイレクトします。
299          </t>
300          <t>
301            <!--
302              The OP establishes whether the end user is authorized to
303              perform OpenID Authentication and wishes to do so. The
304              manner in which the end user authenticates to their OP and
305              any policies surrounding such authentication is out of
306              scope for this document.
307            -->
308            OpenID認証を行うことがエンドユーザーに認められているかどうかを、OPは(認められていることを期待しつつ)確認します。エンドユーザーがどうやってOPに自身を本物であると証明するか、またその証明の手段はどうするか、といった点については、この文書の範囲外とします。
309          </t>
310          <t>
311            <!--
312              The OP redirects the end user's User-Agent back to the
313              Relying Party with either an assertion that <xref
314              target="positive_assertions">authentication is
315              approved</xref> or a message that <xref
316              target="negative_assertions">authentication failed</xref>.
317            -->
318            OPはエンドユーザーのUser-Agentを、次のいずれかの結果をつけてRPにリダイレクトして戻します:
319            <xref target="positive_assertions">認証が承認された</xref>か、<xref
320            target="negative_assertions">認証に失敗した</xref>か。
321          </t>
322          <t>
323            <!--
324              The Relying Party <xref target="verification">verifies
325              </xref> the information received from the OP including
326              checking the Return URL, verifying the discovered
327              information, checking the nonce, and verifying the
328              signature by using either the shared key established
329              during the association or by sending a direct request
330              to the OP.
331            -->
332            RPはOPから受けとった情報を<xref target="verification">検証</xref>します。検証するものには、戻りURL、見つかった情報、nonce、そして署名といったものがあります。署名の検証には、関連付けのときに使った共有鍵を使うか、OPに対して直接検証の要求を送るか、のいずれかの方法がとられます。
333          </t>
334        </list>
335      </t>
336    </section>
337
338
339    <section title="Data Formats - データ書式">
340
341      <section title="Protocol Messages - プロトコルメッセージ">
342
343        <!--
344        <t>
345          The OpenID Authentication protocol messages are
346          mappings of plain-text keys to plain-text values. The keys and
347          values permit the full Unicode character set (UCS). When the
348          keys and values need to be converted to/from bytes, they
349          MUST be encoded using <xref target="RFC3629">UTF-8</xref>.
350        </t>
351        -->
352
353        <t>
354          OpenID認証プロトコルのメッセージは複数のプレインテキストのキーと複数のプレインテキストの値のマッピングになっています。その複数のキーと値は完全なUnicodeキャラクタセット(UCS)をサポートします。その複数のキーと値がバイト列へ変換される、あるいはバイト列から変換される必要があるとき、それらは<xref
355          target="RFC3629">UTF-8</xref>にエンコード「しなければなりません」(MUST)。
356        </t>
357
358        <!--
359        <t>
360          Messages MUST NOT contain multiple parameters with the same name.
361        </t>
362        -->
363
364        <t>
365          メッセージには同じ名前で複数のパラメータを含むことを「してはなりません」(MUST NOT)。
366        </t>
367
368        <!--
369        <t>
370          Throughout this document, all OpenID message parameters are
371          REQUIRED, unless specifically marked as OPTIONAL.
372        </t>
373        -->
374
375        <t>
376          このドキュメント中を通して、全てのOpenIDメッセージパラメータは、「オプションです」(OPTIONAL)と特に明記されていない場合以外は、「必要とされています」(REQUIRED)。
377        </t>
378
379        <section title="Key-Value Form Encoding - キーと値のフォームエンコーディング" anchor="kvform">
380          <!--
381          <t>
382            A message in Key-Value form is a sequence of lines. Each
383            line begins with a key, followed by a colon, and the value
384            associated with the key. The line is terminated by a
385            single newline (UCS codepoint 10, "\n"). A key or value
386            MUST NOT contain a newline and a key also MUST NOT contain
387            a colon.
388          </t>
389          -->
390          <t>
391            キーと値によるメッセージは複数行に順番に並ぶフォームです。それぞれの行はキーから始まり、コロンを続け、そしてそのキーに対応する値を続けます。行は1つの改行(UCSのコードポイントで10、"\n"の事)で区切られます。キーまたは値は改行を含む事を「してはなりません」(MUST NOT)、さらにキーはコロンを含む事も「してはなりません」。
392          </t>
393          <!--
394          <t>
395            Additional characters, including whitespace, MUST NOT be
396            added before or after the colon or newline. The message
397            MUST be encoded in UTF-8 to produce a byte string.
398          </t>
399          -->
400          <t>
401            ホワイトスペースを含む文字列の追加はコロンまたは改行の前後に追加「してはなりません」(MUST NOT)。メッセージはバイト文字とする為にUTF-8でエンコード「しなければなりません」(MUST)。
402          </t>
403          <!--
404          <t>
405            Key-Value Form encoding is used for signature calculation
406            and for <xref target="direct_response">direct
407            responses</xref> to Relying Parties.
408          </t>
409          -->
410          <t>
411            キーと値のフォームエンコーディングは署名の計算とRelying
412            Partyへの<xref target="direct_response">直接的なレスポンス</xref>に使われます。
413          </t>
414        </section>
415
416        <section title="HTTP Encoding - HTTPエンコーディング" anchor="http_encoding">
417          <!--
418          <t>
419            When a message is sent to an HTTP server, it MUST be encoded
420            using a form encoding specified in Section 17.13.4 of
421            <xref target="HTML401"/>. Likewise, if the "Content-Type"
422            header is included in the request headers, its value MUST
423            also be such an encoding.
424          </t>
425          -->
426          <t>
427            HTTPサーバにメッセージを送信した際に、<xref target="HTML401"/>の17.13.4節の中で定義されたフォームエンコーディングを使ってエンコードされて「いなければなりません」(MUST)。同様にして、"Content-Type"ヘッダーがリクエストパラメータの中に含まれている場合は、その値も同じようにエンコード「されなければなりません」(MUST)。
428          </t>
429          <!--
430          <t>
431            All of the keys in the request message MUST be prefixed
432            with "openid.". This prefix prevents interference with
433            other parameters that are passed along with the OpenID
434            Authentication message. When a message is sent as a POST,
435            OpenID parameters MUST only be sent in, and extracted
436            from, the POST body.
437          </t>
438          -->
439          <t>
440            リクエストメッセージ中の全てのキーは"openid."を接頭辞と「しなければなりません」(MUST)。この接頭辞はOpenID Authenticationメッセージに沿って渡される他のパラメータによる干渉を防ぎます。メッセージがPOSTメソッドとして送信される際に、OpenIDパラメータはPOSTの本文として送信されなければならず、またPOSTの本文から展開されなければなりません。
441          </t>
442          <t>
443            <!--
444            All messages that are sent as HTTP requests (GET or POST)
445            MUST contain the following fields:
446            -->
447            HTTPリクエスト(GETかPOST)として送られる全てのメッセージは、以下の項目を含んで「いなければなりません」(MUST)。
448
449            <list style="symbols">
450              <t>
451                openid.ns
452                <list style="empty">
453                  <t>
454                    値: "http://specs.openid.net/auth/2.0"
455                  </t>
456                  <t>
457                    <!--
458                    This particular value MUST be present for the
459                    request to be a valid OpenID Authentication 2.0
460                    request. Future versions of the specification may
461                    define different values in order to allow message
462                    recipients to properly interpret the request.
463                    -->
464                    リクエストが有効なOpenID認証2.0のリクエストであるためには、
465                    この特定の値が存在「しなければなりません」(MUST)。
466                    メッセージの受信者がリクエストを適切に解釈することを許容するために、
467                    仕様の将来のバージョンでは異なる値が定義されるかもしれません。
468                  </t>
469                  <t>
470                    <!--
471                    If this value is absent or set to one of
472                    "http://openid.net/signon/1.1" or
473                    "http://openid.net/signon/1.0", then this message
474                    SHOULD be interpreted using <xref
475                    target="compat_mode">OpenID Authentication 1.1
476                    Compatibility mode</xref>.
477                    -->
478                    もしこの値が存在しないか "http://openid.net/signon/1.1",
479                    "http://openid.net/signon/1.0"のいずれかであれば、
480                    このメッセージは<xref target="compat_mode">OpenID
481                    Authentication 1.1互換モード</xref>として解釈「されるべきです」(SHOULD)。
482                  </t>
483                </list>
484              </t>
485              <t>
486                openid.mode
487                <list style="empty">
488                  <t>
489                    <!--
490                    Value: Specified individually for each message
491                    type.
492                    -->
493                    値: それぞれのメッセージについて個別に示される。
494                  </t>
495                  <t>
496                    <!--
497                    The "openid.mode" parameter allows the recipient
498                    of the message to know what kind of message it is
499                    processing. If "openid.mode" is absent, the party
500                    processing the message SHOULD assume that the
501                    request is not an OpenID message.
502                    -->
503                    "openid.mode"パラメータは、メッセージの受信者が処理しているメッセージの種類を知る事を可能にします。
504                    もし"openid.mode"が存在しないなら、メッセージを処理しているパーティはリクエストがOpenIDメッセージではないと仮定「すべきです」(SHOULD)。
505                  </t>
506                </list>
507              </t>
508            </list>
509          </t>
510
511          <t>
512            <!--
513            This model applies to messages from the User-Agent to both
514            the Relying Party and the OP, as well as messages from the
515            Relying Party to the OP.
516            -->
517            このモデルは、User-AgentからRelying PartyとOPの両方へのメッセージに加えて、Relying
518            PartyからOPへのメッセージに対して適用します。
519          </t>
520        </section>
521        <section title="Example - 例">
522          <t>
523            <!--
524            Non-normative
525            -->
526            参考
527          </t>
528          <figure>
529            <preamble>
530              <!--
531              The following examples encode the following information:
532              -->
533              下記の例は以下の情報をエンコードします:
534            </preamble>
535            <artwork><![CDATA[Key     | Value
536--------+---------------------------
537mode    | error
538error   | This is an example message]]></artwork>
539          </figure>
540
541          <figure>
542            <preamble>
543              <!--
544              Key-Value Form encoded:
545              -->
546              キーと値のフォームエンコーディング:
547            </preamble>
548            <artwork><![CDATA[mode:error
549error:This is an example message]]></artwork>
550          </figure>
551
552          <figure>
553            <preamble>
554              <!--
555              x-www-urlencoded, as in a HTTP POST body or in a URL's
556              query string (<xref target="RFC3986"/> section 3):
557              -->
558              HTTP POSTのボディかURLのクエリ文字列におけるx-www-urlencoded(<xref target="RFC3986"/> section 3):
559            </preamble>
560            <artwork>openid.mode=error&amp;openid.error=This%20is%20an%20example%20message</artwork>
561          </figure>
562        </section>
563      </section>
564
565      <section title="Integer Representations - 整数の表現" anchor="btwoc">
566        <!--
567        <t>
568          Arbitrary precision integers MUST be encoded as big-endian
569          signed two's complement binary strings. Henceforth, "btwoc"
570          is a function that takes an arbitrary precision integer and
571          returns its shortest big-endian two's complement
572          representation. All integers that are used with
573          Diffie-Hellman Key Exchange are positive. This means that
574          the left-most bit of the two's complement representation
575          MUST be zero. If it is not, implementations MUST add a zero
576          byte at the front of the string.
577        </t>
578        -->
579        <t>
580          任意精度整数は、ビッグエンディアンの符号付き2の補数の
581          バイナリ文字列としてエンコード「されなければなりません」(MUST)。
582          以降、"btwoc"は任意精度整数を扱い最短のビッグエンディアンの
583          2の補数表現を返す関数とします。Diffie-Hellman 鍵共有法 (DH 法)
584          で使われる全ての整数は正です。これは2の補数表現の最も左の
585          ビットがゼロで「なければならない」(MUST)事を意味します。
586          もしそうでないなら、実装は文字列の先頭に"0"を意味するバイト
587          文字を付け加え「なければなりません」(MUST)。
588        </t>
589        <figure>
590          <!--
591          <preamble>Non-normative example:</preamble>
592          -->
593          <preamble>参考例:</preamble>
594          <artwork><![CDATA[Base 10 number | btwoc string representation
595---------------+----------------------------
5960              | "\x00"
597127            | "\x7F"
598128            | "\x00\x80"
599255            | "\x00\xFF"
60032768          | "\x00\x80\x00"]]></artwork>
601        </figure>
602      </section>
603    </section>
604
605    <section title="Communication Types - コミュニケーションタイプ">
606      <section title="Direct Communication - 直接的なコミュニケーション"
607               anchor="direct_comm">
608        <!--
609        <t>
610              Direct communication is initiated by a Relying Party to an
611              OP endpoint URL. It is used for <xref
612              target="associations">establishing associations</xref> and
613              <xref target="check_auth">verifying authentication
614              assertions</xref>.
615        </t>
616        -->
617        <t>
618          直接的なコミュニケーションは、Relying PartyからOPのendpoint URLに対して始められます。
619          これは、<xref target="associations">関連付けを確立するため</xref>と<xref target="check_auth">
620          認証アサーション</xref>を検証するために使います。
621        </t>
622
623        <section title="Direct Request - 直接的なリクエスト" anchor="direct_request">
624          <!--
625          <t>
626            The message MUST be encoded as a POST body, as specified
627            by <xref target="http_encoding"/>.
628          </t>
629          -->
630          <t>
631            メッセージは<xref target="http_encoding"/>で示したように、
632            POSTボディとしてエンコードされなければなりません(MUST)。
633          </t>
634
635          <!--
636          <t>
637            All direct requests are HTTP POSTs, and so
638            contain the required fields listed in <xref
639            target="http_encoding"/>.
640          </t>
641          -->
642          <t>
643            すべての直接的なリクエストはHTTP POSTであり、<xref target="http_encoding"/>で
644            列挙したリクエストフィールドを含みます。
645          </t>
646
647        </section>
648        <section title="Direct Response - 直接的なレスポンス" anchor="direct_response">
649          <!--
650          <t>
651            The body of a response to a <xref
652            target="direct_request">Direct Request</xref> consists of
653            an HTTP Response body in <xref target="kvform">Key-Value
654            Form</xref>. The content-type of the response SHOULD be
655            "text/plain".
656          </t>
657          -->
658          <t>
659            <xref target="direct_request">直接的なリクエスト</xref>への応答のボディは、
660            <xref target="kvform">キーと値のフォーム</xref>によるHTTPレスポンスボディで
661            構成されます。応答のcontent-typeは"text/plain"であるべきです(SHOULD)。
662          </t>
663
664          <t>
665            キーと値のフォームのメッセージの全てに、以下の項目を含まなければなりません(MUST)。
666            <!--
667            All Key-Value form message MUST contain the following field:
668            -->
669
670            <list style="symbols">
671              <t>
672                ns
673                <list style="empty">
674                  <t>
675                    Value: "http://specs.openid.net/auth/2.0"
676                  </t>
677                  <!--
678                  <t>
679                    This particular value MUST be present for the
680                    response to be a valid OpenID 2.0 response. Future
681                    versions of the specification may define different
682                    values in order to allow message recipients to
683                    properly interpret the request.
684                  </t>
685                  -->
686                  <t>
687                    レスポンスが有効なOpenID 2.0のレスポンスであるためには、
688                    この特定の値が存在しれなければなりません(MUST)。
689                    メッセージの受信者がリクエストを適切に解釈することを許容するために、
690                    仕様の将来のバージョンでは異なる値が定義されるかもしれません。
691                  </t>
692                  <!--
693                  <t>
694                    If this value is absent or set to one of
695                    "http://openid.net/signon/1.1" or
696                    "http://openid.net/signon/1.0", then this message
697                    SHOULD be interpreted using <xref
698                    target="compat_mode">OpenID Authentication 1.1
699                    Compatibility mode</xref>.
700                  </t>
701                  -->
702                  <t>
703                    もしこの値が存在しないか "http://openid.net/signon/1.1",
704                    "http://openid.net/signon/1.0"のいずれかであれば、
705                    このメッセージは<xref target="compat_mode">OpenID
706                    Authentication 1.1互換モード</xref>として解釈されるべきです(SHOULD)。
707                  </t>
708                </list>
709              </t>
710            </list>
711          </t>
712
713          <section title="Successful Responses - 正常レスポンス">
714            <!--
715            <t>
716              A server receiving a valid request MUST send a
717              response with an HTTP status code of 200.
718            </t>
719            -->
720            <t>
721              有効なリクエストを受信したサーバは、ステータスコード200とともに
722              応答を送信しなければなりません(MUST)。
723            </t>
724          </section>
725
726          <section title="Error Responses - エラーレスポンス">
727            <!--
728            <t>
729              If a request is malformed or contains invalid arguments,
730              the server MUST send a response with a status code of
731              400. The response body MUST be a <xref
732              target="kvform">Key-Value Form</xref> message with the
733              following fields:
734            </t>
735            -->
736            <t>
737              リクエストが異常もしくは不正な値を含んでいる場合は、
738              サーバはステータスコード400とともに応答を
739              送信しなければなりません(MUST)。
740              レスポンスボディは以下の項目を含んだ<xref target="kvform">
741              キーと値のフォーム</xref>でなければなりません(MUST)。
742            </t>
743            <t>
744              <list style="symbols">
745                <t>
746                  ns
747                  <list style="empty">
748                    <!--
749                    <t>
750                      As specified in <xref target="direct_response"/>.
751                    </t>
752                    -->
753                    <t>
754                      <xref target="direct_response"/>で示したとおり。
755                    </t>
756                  </list>
757                </t>
758
759                <t>
760                  error
761                  <list style="empty">
762                    <!--
763                    <t>
764                      Value: A human-readable message indicating the cause
765                      of the error.
766                    </t>
767                    -->
768                    <t>
769                      値: エラーの原因を示す、人間が読むことができるメッセージ。
770                    </t>
771                  </list>
772                </t>
773
774                <t>
775                  contact
776                  <list style="empty">
777                    <!--
778                    <t>
779                      Value: (optional) Contact address for the
780                      administrator of the sever. The contact address
781                      may take any form, as it is intended to be
782                      displayed to a person.
783                    </t>
784                    -->
785                    <t>
786                      値: (optional) サーバ管理者の連絡先。
787                      人に表示することを意図したものであれば、
788                      連絡先はどんな形式でもよい。
789                    </t>
790                  </list>
791                </t>
792
793                <t>
794                  reference
795                  <list style="empty">
796                    <!--
797                    <t>
798                      Value: (optional) A reference token, such
799                      as a support ticket number or a URL to a news
800                      blog, etc.
801                    </t>
802                    -->
803                    <t>
804                      値: (optional) サポートチケット番号、ニュースBlogのURLなどの参照先。
805                    </t>
806                  </list>
807                </t>
808              </list>
809              OPはこの応答に追加の項目を加えてもよい(MAY)。
810              <!--
811              The OP MAY add additional fields to this response.
812              -->
813            </t>
814          </section>
815        </section>
816      </section>
817      <section title="Indirect Communication - 間接的な通信"
818               anchor="indirect_comm">
819        <!--
820        <t>
821          In indirect communication, messages are passed through the
822          User-Agent. This can be initiated by either the Relying
823          Party or the OP. Indirect communication is used for <xref
824          target="requesting_authentication">authentication
825          requests</xref> and <xref
826          target="responding_to_authentication">authentication
827          responses</xref>.
828        </t>
829        -->
830        <t>
831          間接的な通信では、メッセージはUser-Agentを通過します。
832          Relying PartyかOPのどちらからでも始める事が出来ます。
833          間接的な通信は<xref target="requesting_authentication">認証要求</xref>と
834          <xref target="responding_to_authentication">認証応答</xref>
835          のために使われます。
836        </t>
837        <!--
838        <t>
839          There are two methods for indirect communication: HTTP
840          redirects and HTML form submission.
841          Both form submission and redirection require that the sender
842          know a recipient URL and that the recipient URL expect
843          indirect messages, as specified in <xref target="http_encoding"/>.
844          The initiator of the communication chooses which method
845          of indirect communication is appropriate depending on
846          capabilities, message size, or other external factors.
847        </t>
848        -->
849        <t>
850          間接的な通信のための2つの方法: HTTPリダイレクトとHTMLフォーム送信。
851          フォーム送信とリダイレクションの両方は、送信者が受信者のURLを
852          知っている事と、受信者のURLが<xref target="http_encoding"/>で示される
853          ような間接的なメッセージを期待している事を要求します。
854          通信の開始側は、性能, メッセージサイズ, 他の外部要因によって決まる
855          ふさわしい間接的な通信の方法を選びます。
856        </t>
857        <!--
858        <t>
859          All indirect messages arrive as HTTP requests, and so
860          contain the required fields listed in <xref
861          target="http_encoding"/>.
862        </t>
863        -->
864        <t>
865          全ての間接的なメッセージはHTTPリクエストとして到着するので、
866          <xref target="http_encoding"/>で列挙した必須フィールドを含みます。
867        </t>
868
869        <section title="HTTP Redirect - HTTPリダイレクト">
870          <!--
871          <t>
872            Data can be transferred by issuing a 302, 303, or 307 HTTP
873            Redirect to the end user's User-Agent. The redirect URL is
874            the URL of the receiver with the OpenID Authentication
875            message appended to the query string, as specified in
876            <xref target="http_encoding"/>.
877          </t>
878          -->
879          <t>
880            302, 303, 307のHTTPリダイレクトをエンドユーザーの
881            User-Agentに対して発行する事で、データの転送が出来ます。
882            リダイレクトURLは、<xref target="http_encoding"/>で示される
883            OpenID認証メッセージをクエリ文字列に追加した、受信者のURLです。
884          </t>
885        </section>
886
887        <section title="HTML FORM Redirection - HTMLフォームリダイレクション">
888          <!--
889          <t>
890            A mapping of keys to values can be transferred by
891            returning an HTML page to the User-Agent that contains an
892            HTML form element. Form submission MAY be automated,
893            for example by using JavaScript.
894          </t>
895          -->
896          <t>
897            HTMLのフォーム要素を含むHTMLページをUser-Agentに返す事によって、
898            キーと値の対応付けを転送する事が出来ます。
899            フォーム送信は、例えばJavaScriptを使う事で自動化される
900            「かもしれません」(MAY)。
901          </t>
902          <!--
903          <t>
904            The &lt;form&gt; element's "action" attribute value MUST
905            be the URL of the receiver. Each Key-Value pair MUST be
906            included in the form as an &lt;input&gt; element. The key
907            MUST be encoded as the "name" attribute and the value as
908            the "value" attribute, such that the User-Agent will
909            generate a message as specified in <xref
910            target="http_encoding"/> when the form is submitted. The
911            form MUST include a submit button.
912          </t>
913          -->
914          <t>
915            &lt;form&gt;要素の"action"属性値は受信者のURL
916            「でなければなりません」(MUST)。
917            それぞれのキーと値のペアは&lt;input&gt;要素として
918            フォームの中に含まれて「いなければなりません」(MUST)。
919            フォームが送信されたときに、User-Agentが
920            <xref target="http_encoding"/>で示されるようなメッセージを
921            生成できるように、キーを"name"属性として、値を"value"属性
922            としてエンコード「されなければなりません」(MUST)。
923          </t>
924        </section>
925        <section title="Indirect Error Responses - 間接エラーメッセージ" anchor="indirect_error">
926          <!--
927          <t>
928            In the case of a malformed request, or one that contains
929            invalid arguments, the OpenID Provider MUST redirect the
930            User-Agent to the "openid.return_to" URL value if the
931            value is present and it is a valid URL.
932          </t>
933          -->
934          <t>
935            リクエストが異常もしくは不正な値を含んでいる場合、
936            "openid.return_to"が存在してその値が有効なURLであるなら、
937            OpenID ProviderはUser-AgentをそのURLにリダイレクト
938            「しなければなりません」(MUST)。
939          </t>
940          <t>
941            <list style="symbols">
942              <t>
943                openid.ns
944                <list style="empty">
945                  <!--
946                  <t>
947                    As specified in <xref target="http_encoding"/>.
948                  </t>
949                  -->
950                  <t>
951                    <xref target="http_encoding"/>で示される通り。
952                  </t>
953                </list>
954              </t>
955
956              <t>
957                openid.mode
958                <list style="empty">
959                  <!--
960                  <t>
961                    Value: "error"
962                  </t>
963                  -->
964                  <t>
965                    値: "error"
966                  </t>
967                </list>
968              </t>
969              <t>
970                openid.error
971                <list style="empty">
972                  <!--
973                  <t>
974                    Value: A human-readable message indicating the cause
975                    of the error.
976                  </t>
977                  -->
978                  <t>
979                    値: エラーの原因を示す、人間が読むことができるメッセージ。
980                  </t>
981                </list>
982              </t>
983              <t>
984                openid.contact
985                <list style="empty">
986                  <!--
987                  <t>
988                    Value: (optional) Contact address for the
989                    administrator of the sever. The contact address
990                    may take any form, as it is intended to be
991                    displayed to a person.
992                  </t>
993                  -->
994                  <t>
995                    値: (optional) サーバ管理者の連絡先。
996                    人に表示することを意図したものであれば、
997                    連絡先はどんな形式でもよい。
998                  </t>
999                </list>
1000              </t>
1001
1002              <t>
1003                openid.reference
1004                <list style="empty">
1005                  <!--
1006                  <t>
1007                    Value: (optional) A reference token, such as a
1008                    support ticket number or a URL to a news blog,
1009                    etc.
1010                  </t>
1011                  -->
1012                  <t>
1013                    値: (optional) サポートチケット番号、ニュースBlogのURLなどの参照先。
1014                  </t>
1015                </list>
1016              </t>
1017            </list>
1018
1019            <!--
1020            The server MAY add additional keys to this response.
1021            -->
1022            サーバはこの応答に追加のキーを加え「てもよい」(MAY)。
1023          </t>
1024          <!--
1025          <t>
1026            If the malformed or invalid message is received by the Relying
1027            Party, or "openid.return_to" is not present or its value is not
1028            a valid URL, the server SHOULD return a response to the
1029            end user indicating the error and that it is unable to continue.
1030          </t>
1031          -->
1032          <t>
1033            Relying Partyから異常か不正なメッセージを受け取ったり、
1034            "openid.return_to"が存在しないか値が有効なURLでないなら、
1035            サーバはエラーと継続不可能である事を示すレスポンスを
1036            エンドユーザーに返す「べきです」(SHOULD)。
1037          </t>
1038        </section>
1039      </section>
1040    </section>
1041
1042    <section title="Generating Signatures - 署名の生成" anchor="generating_signatures">
1043      <!--
1044      <t>
1045        The most common usage of an association is as a Message
1046        Authentication Code (MAC) key used to sign OpenID
1047        Authentication messages.
1048      </t>
1049      -->
1050      <t>
1051        関連付け (association) の主な用途は,メッセージ認証コードキー
1052        (MACキー) を使って OpenID 認証メッセージに署名することです.
1053      </t>
1054
1055      <!--
1056      <t>
1057        When generating MAC keys, the recommendations in <xref
1058        target="RFC1750"/> SHOULD be followed.
1059      </t>
1060      -->
1061      <t>
1062        MACキーを生成するときは,<xref target="RFC1750"/>
1063        で推奨されている方法に従うべき (SHOULD) です.
1064      </t>
1065
1066      <section title="Procedure - プロシージャ (手順)">
1067        <t>
1068          メッセージ署名を生成する手順:
1069          <!--
1070          To generate a message signature:
1071          -->
1072
1073          <list style="numbers">
1074            <!--
1075            <t>
1076              Determine the list of keys to be signed, according to
1077              the message to be signed (See <xref
1078              target="positive_assertions"/>). The list of keys to be
1079              signed MUST be part of the message. The list is stored
1080              with the key "openid.signed". The value is a
1081              comma-separated list of keys, with the "openid." prefix
1082              stripped. This algorithm is only capable of signing keys
1083              that start with "openid."
1084            </t>
1085            -->
1086            <t>
1087              署名するメッセージから,署名対象となるキーのリストを抜き出します
1088              (<xref target="positive_assertions"/> 参照).
1089              この署名対象キーはメッセージの一部でなければなりません (MUST).
1090              署名対象キーはカンマで区切って "openid.signed" というキーに格納されます.
1091              このとき,各キーの "openid." という接頭辞は外してください.
1092              このアルゴリズムは,"openid." で始まるキーにしか
1093              署名できません.
1094            </t>
1095
1096            <!--
1097            <t>
1098              Iterate through the list of keys to be signed in the
1099              order they appear in "openid.signed" list. For each
1100              key, find the value in the message whose key is equal to
1101              the signed list key prefixed with "openid."
1102            </t>
1103            -->
1104            <t>
1105              "openid.signed" に列挙されている順に従い,
1106              署名対象キーそれぞれに対して次の処理を行います.
1107              メッセージから一致するキーを見つけ ("opneid." 接頭辞の有無に注意),
1108              その値を取得します.
1109            </t>
1110
1111            <!--
1112            <t>
1113              Convert the list of key/value pairs to be signed to an
1114              octet string by encoding with <xref
1115              target="kvform">Key-Value Form Encoding</xref>.
1116            </t>
1117            -->
1118            <t>
1119              <xref target="kvform">キーと値のフォームエンコーディング</xref>
1120              を用いて,署名対象キーと値のペアをオクテット文字列に変換します.
1121            </t>
1122
1123            <!--
1124            <t>
1125              Determine the signature algorithm from the <xref
1126              target="associations">association type</xref>. Apply
1127              the <xref target="sign_algos">signature algorithm</xref>
1128              to the octet string.
1129            </t>
1130            -->
1131            <t>
1132              <xref target="associations">関連付けの種類</xref> に応じて
1133              署名アルゴリズムを決定し,オクテット文字列に
1134              <xref target="sign_algos">署名アルゴリズム</xref>を適用します.
1135            </t>
1136          </list>
1137        </t>
1138      </section>
1139
1140      <section title="Signature Algorithms - 署名アルゴリズム" anchor="sign_algos">
1141        <t>
1142          OpenID 認証では次の2つの署名アルゴリズムをサポートします:
1143          <!--
1144          OpenID Authentication supports two signature algorithms:
1145          -->
1146
1147          <list style="symbols">
1148            <t>HMAC-SHA1 - 160 bit key length (<xref target="RFC2104"/> and
1149            <xref target="RFC3174"/>)</t>
1150            <t>HMAC-SHA256 - 256 bit key length (<xref target="RFC2104"/> and
1151            <xref target="FIPS180-2"/></t>
1152          </list>
1153
1154          HMAC-SHA256 がサポートされているときは,そちらを使ってください.
1155          <!--
1156          If supported, the use of HMAC-SHA256 is RECOMMENDED.
1157          -->
1158        </t>
1159      </section>
1160    </section>
1161
1162    <section title="Initiation and Discovery - 初期化とディスカバリー">
1163
1164      <section title="Initiation - 初期化" anchor="initiation">
1165        <!--
1166        <t>
1167          To initiate OpenID Authentication, the Relying Party SHOULD
1168          present the end user with a form that has a field for
1169          entering a User-Supplied Identifier.
1170        </t>
1171        -->
1172        <t>
1173          OpenID認証の初期化時に、Relying PartyはUser-Supplied Identifierを入力するためのフィールドを持つフォームをエンドユーザーに表示すべきです。(SHOULD)
1174        </t>
1175
1176        <!--
1177        <t>
1178          The form field's "name" attribute SHOULD have the value
1179          "openid_identifier", so that User-Agents can automatically
1180          determine that this is an OpenID form. Browser extensions or
1181          other software that support OpenID Authentication may not
1182          detect a Relying Party's support if this attribute is not
1183          set appropriately.
1184        </t>
1185        -->
1186
1187        <t>
1188          そのフォームフィールドの "name" 属性は "openid_identifier" と言う値を持つべきです。(SHOULD)
1189          と言うのもUser-Agentはその入力フィールドがOpenIDのフォームであることを自動的に判別できるからです。
1190          OpenID認証に対応したブラウザ拡張や他のソフトウェアはこの属性が適切に設定されていない場合、Relying Partyを正しく判別する事が出来ないでしょう。
1191        </t>
1192      </section>
1193
1194      <section title="Normalization - 正規化" anchor="normalization">
1195        <!--
1196        <t>
1197          The end user's input MUST be normalized into an
1198          Identifier, as follows:
1199        </t>
1200        -->
1201
1202        <t>
1203          エンドユーザーの入力は下記に従って正規化されたIdentifierとしなければなりません。(MUST)
1204        </t>
1205
1206        <t>
1207          <list style="numbers">
1208            <!--
1209            <t>
1210              If the user's input starts with the "xri://" prefix,
1211              it MUST be stripped off, so that XRIs are used in the
1212              canonical form.
1213            </t>
1214            -->
1215            <t>
1216              ユーザーが "xri://" と言う接頭辞から始まる入力を行った場合、その接頭辞は捨てなければなりません。(MUST)
1217              と言うのはXRIは特定の基準に則った形式で使われるものだからです。
1218            </t>
1219
1220            <!--
1221            <t>
1222              If the first character of the resulting string is an
1223              XRI Global Context Symbol ("=", "@", "+", "$", "!") or "(", as
1224              defined in Section 2.2.1 of <xref target="XRI_Syntax_2.0"/>,
1225              then the input SHOULD be treated as an XRI.
1226            </t>
1227            -->
1228
1229            <t>
1230              結果文字列の最初の文字が<xref target="XRI_Syntax_2.0"/>の2.2.1節で定義されているXRI Global Context Symbol ("=", "@", "+", "$", "!") または "(" であるならば、その入力はXRIとして扱われるべきです。(SHOULD)
1231            </t>
1232
1233            <!--
1234            <t>
1235              Otherwise, the input SHOULD be treated as an http URL; if it
1236              does not include a "http" or "https" scheme, the Identifier
1237              MUST be prefixed with the string "http://". If the URL
1238              contains a fragment part, it MUST be stripped off
1239              together with the fragment delimiter character "#". See
1240              <xref target="http_s_identifiers"/> for more information.
1241            </t>
1242            -->
1243
1244            <t>
1245              そのいずれでもなければ、その入力はhttpのURLとして扱われるべきです。(SHOULD)
1246              その入力が "http" または "https" スキーマを含んでいなかった場合は、そのIdentifierは"http://"と言う文字列を接頭辞としてつけなければなりません。(MUST)
1247              URLにフラグメントパートが含まれている場合は、フラグメントの区切り文字列である "#" と共に除去されなければなりません。(MUST)
1248              より詳しくは<xref target="http_s_identifiers"/>を見て下さい。
1249            </t>
1250
1251            <!--
1252            <t>
1253              URL Identifiers MUST then be further normalized by both
1254              following redirects when retrieving their content and
1255              finally applying the rules in Section 6 of <xref
1256              target="RFC3986"/> to the final destination URL. This
1257              final URL MUST be noted by the Relying Party as the
1258              Claimed Identifier and be used when <xref
1259              target="requesting_authentication">requesting
1260              authentication</xref>.
1261            </t>
1262            -->
1263
1264            <t>
1265              URL Identifierはそれらの内容を取得した際のリダイレクトに従うと言う事と、<xref target="RFC3986"/>の6節で定義された正規化ルールを最終的な目的URLに対して最後まで適用すると言う事の両方によって正規化された物でなくてはなりません。(MUST)
1266              この最終的なURLはRelying PartyによってClaimed Identifierとして記録され、<xref target="requesting_authentication">認証要求</xref>において使用されなければなりません。(MUST)
1267            </t>
1268          </list>
1269
1270          <!--
1271          See <xref target="normalization_example">normalization
1272          example</xref>.
1273          -->
1274          <xref target="normalization_example">正規化の例</xref>を見て下さい。
1275
1276        </t>
1277      </section>
1278
1279      <section title="Discovery - ディスカバリー" anchor="discovery">
1280
1281        <!--
1282        <t>
1283          Discovery is the process where the Relying Party uses the
1284          Identifier to look up ("discover") the necessary information
1285          for initiating requests. OpenID Authentication has three
1286          paths through which to do discovery:
1287        </t>
1288        -->
1289
1290        <t>
1291          ディスカバリーとはRelying Partyが認証要求の始める際に必須の情報を探し出す("ディスカバリー")時にIdentifierを使用する際のプロセスです。OpenID認証はディスカバリーを行う方法として3つの経路があります。
1292        </t>
1293
1294        <t>
1295          <list style="numbers">
1296            <!--
1297            <t>
1298              If the identifier is an XRI, <xref
1299              target="XRI_Resolution_2.0"/>
1300              will yield an XRDS document that
1301              contains the necessary information. It should also be
1302              noted that Relying Parties can take advantage of
1303              XRI Proxy Resolvers, such as the one provided by
1304              XDI.org at http://www.xri.net. This will remove the need for the RPs to
1305              perform XRI Resolution locally.
1306            </t>
1307            -->
1308
1309            <t>
1310              IdentifierがXRI<xref target="XRI_Resolution_2.0"/>ならば、XRIは必須の情報を含んだXRDS文書を生成するでしょう。
1311              Relying Partyがその一つはXDI.org(http://www.xri.net)によって提供されているようなXRIプロキシリゾルバよりも優れた物になりうると言う事に注意すべきです。
1312              これはRPが自分達でXRI解決を行う必要を取り去るでしょう。
1313            </t>
1314
1315            <!--
1316            <t>
1317              If it is a URL, the <xref target="Yadis">Yadis
1318              protocol</xref> SHALL be first attempted. If it
1319              succeeds, the result is again an XRDS document.
1320            </t>
1321            -->
1322
1323            <t>
1324              IdentifierがURLならば、<xref target="Yadis">Yadis protocol</xref>を最初に試みる事とします。
1325              それが成功した場合、結果は再びXRDS文書です。
1326            </t>
1327
1328            <!--
1329            <t>
1330              If the Yadis protocol fails and no valid XRDS document
1331              is retrieved, or no <xref
1332              target="service_elements">Service Elements</xref> are
1333              found in the XRDS document, the URL is retrieved and
1334              <xref target="html_disco">HTML-Based discovery</xref>
1335              SHALL be attempted.
1336            </t>
1337            -->
1338
1339            <t>
1340              Yadisプロトコルで失敗したり、妥当でないXRDS文書が取得されたり、<xref target="service_elements">Service Elements</xref>がXRDS文書に存在しない場合、そのURLを取得して<xref target="html_disco">HTML-Based discovery</xref>を試みられるとします。
1341            </t>
1342          </list>
1343        </t>
1344
1345        <section title="Discovered Information - 発見された情報" anchor="discovered_info">
1346          <!--
1347          <t>
1348            Upon successful completion of discovery, the Relying Party
1349            will have one or more sets of the following information
1350            (see the <xref target="terminology">Terminology
1351            section</xref> for definitions). If more than one set of
1352            the following information has been discovered, the
1353            precedence rules defined in <xref target="XRI_Resolution_2.0"/>
1354            are to be applied.
1355
1356            <list style="symbols">
1357              <t>OP Endpoint URL</t>
1358              <t>Protocol Version</t>
1359            </list>
1360
1361            If the end user did not enter an OP Identifier, the
1362            following information will also be present:
1363
1364            <list style="symbols">
1365              <t>Claimed Identifier</t>
1366              <t>OP-Local Identifier</t>
1367            </list>
1368
1369            If the end user entered an OP Identifier, there is no
1370            Claimed Identifier. For the purposes of making OpenID
1371            Authentication requests, the value
1372            "http://specs.openid.net/auth/2.0/identifier_select"
1373            MUST be used as both the Claimed Identifier and the
1374            OP-Local Identifier when an OP Identifier is entered.
1375          </t>
1376          -->
1377          <t>
1378            発見が成功裏に完了したとき、Relying Partyは次に述べる
1379            情報を1つ以上持っているでしょう(定義に関しては
1380            <xref target="terminology">用語セクション</xref>を参照)。
1381            もし次に述べる情報の1つ以上が発見されたなら、
1382            <xref target="XRI_Resolution_2.0"/>で定義される優先規則が
1383            適用されます。
1384
1385            <list style="symbols">
1386              <t>OP Endpoint URL</t>
1387              <t>Protocol Version</t>
1388            </list>
1389
1390            もしエンドユーザーがOP Identifierを入力しなかったなら、
1391            さらに以下の情報が存在するでしょう:
1392
1393            <list style="symbols">
1394              <t>Claimed Identifier</t>
1395              <t>OP-Local Identifier</t>
1396            </list>
1397
1398            もしエンドユーザーがOP Identifierを入力したなら、
1399            Claimed Identifierはありません。
1400            OP Identifierが入力されるとき、OpenID認証リクエストを
1401            作る目的のために、
1402            "http://specs.openid.net/auth/2.0/identifier_select"の値は
1403            Claimed IdentifierとOP-Local Identifierの両方として
1404            使われ「なければなりません」(MUST)。
1405          </t>
1406        </section>
1407
1408        <section title="XRDS-Based Discovery - XRDSを用いたディスカバリー">
1409          <!--
1410          <t>
1411            If XRI or Yadis discovery was used, the result will be an
1412            XRDS Document. This is an XML document with entries for
1413            services that are related to the Identifier. It is
1414            defined in <xref target="XRI_Resolution_2.0">Section 3
1415            of</xref>. See <xref target="XRDS_Sample"/> for an
1416            example XRDS document.
1417          </t>
1418          -->
1419          <t>
1420            もしXRIかYadisディスカバリーが使われた場合、その結果は
1421            XRDSドキュメントでしょう。これは、Identifierに関連する
1422            サービスについてのエントリーを含むXMLドキュメントです。
1423            <xref target="XRI_Resolution_2.0">XRI_Resolution_2.0のセクション3</xref>で
1424            定義されます。XRDSドキュメントの例については<xref target="XRDS_Sample"/>を参照。
1425          </t>
1426
1427
1428          <section title="OpenID Service Elements - OpenIDサービス要素" anchor="service_elements">
1429
1430            <section title="OP Identifier Element - OP Identifier 要素">
1431              <!--
1432              <t>
1433                An OP Identifier Element is an &lt;xrd:Service&gt;
1434                element with the following information:
1435
1436                <list style="hanging">
1437                  <t>
1438                    An &lt;xrd:Type&gt; tag whose text content is
1439                    "http://specs.openid.net/auth/2.0/server".
1440                  </t>
1441
1442                  <t>
1443                    An &lt;xrd:URI&gt; tag whose text content is the
1444                    OP Endpoint URL
1445                  </t>
1446                </list>
1447              </t>
1448              -->
1449              <t>
1450                OP Identifier要素は以下の情報を含む&lt;xrd:Service&gt;要素です:
1451
1452                <list style="hanging">
1453                  <t>
1454                    テキストコンテンツが"http://specs.openid.net/auth/2.0/server"である&lt;xrd:Type&gt;タグです。
1455                  </t>
1456
1457                  <t>
1458                    テキストコンテンツがOP Endpoint URLである&lt;xrd:URI&gt;タグです。
1459                  </t>
1460                </list>
1461              </t>
1462            </section>
1463
1464            <section title="Claimed Identifier Element - Claimed Identifier要素">
1465              <!--
1466              <t>
1467                A Claimed Identifier Element is an
1468                &lt;xrd:Service&gt; element with the following
1469                information:
1470
1471                <list style="hanging">
1472                  <t>
1473                    An &lt;xrd:Type&gt; tag whose text content is
1474                    "http://specs.openid.net/auth/2.0/signon".
1475                  </t>
1476
1477                  <t>
1478                    An &lt;xrd:URI&gt; tag whose text content is the
1479                    OP Endpoint URL.
1480                  </t>
1481
1482                  <t>
1483                    An &lt;xrd:LocalID&gt; tag (optional) whose text
1484                    content is the OP-Local Identifier.
1485                  </t>
1486                </list>
1487              </t>
1488              -->
1489              <t>
1490                Claimed Identifier要素は以下の情報を含む&lt;xrd:Service&gt;要素です:
1491
1492                <list style="hanging">
1493                  <t>
1494                    テキストコンテンツが"http://specs.openid.net/auth/2.0/signon"である&lt;xrd:Type&gt;タグです。
1495                  </t>
1496
1497                  <t>
1498                    テキストコンテンツがOP Endpoint URLである&lt;xrd:URI&gt;タグです。
1499                  </t>
1500
1501                  <t>
1502                    (optional) テキストコンテンツがOP-Local Identifierである&lt;xrd:LocalID&gt;タグです。
1503                  </t>
1504                </list>
1505              </t>
1506            </section>
1507          </section>
1508
1509          <section title="Extracting Authentication Data"
1510                   anchor="extracting_auth">
1511            <!--
1512            <t>
1513              Once the Relying Party has obtained an XRDS document, it
1514              MUST first search the document (following the rules
1515              described in <xref target="XRI_Resolution_2.0"/>) for
1516              an OP Identifier Element. If none is found, the RP will search
1517              for a Claimed Identifier Element.
1518            </t>
1519            -->
1520            <t>
1521              Relying PartyがXRDSドキュメントを得たとき、Relying Partyは
1522              まずOP Identifier要素について(<xref target="XRI_Resolution_2.0"/>で示された規則に従って)
1523              ドキュメントを検索「しなければなりません」(MUST)。
1524              もし何も見つからなかったなら、RPはClaimed Identifier要素
1525              について検索するでしょう。
1526            </t>
1527          </section>
1528
1529          <section title="XRI and the CanonicalID Element" anchor="canonicalid"
1530                   toc="exclude">
1531            <!--
1532            <t>
1533              When the Identifier is an XRI, the &lt;xrd:XRD&gt;
1534              element that contains the OpenID Authentication
1535              &lt;xrd:Service&gt; element MUST also contain a
1536              &lt;CanonicalID&gt; element. The content of this element
1537              MUST be used as the Claimed Identifier (see <xref
1538              target="identifying"/>). This is a vital security
1539              consideration because a primary purpose of the
1540              &lt;CanonicalID&gt; element is to assert a persistent
1541              identifier that will never be reassigned, thus
1542              preventing the possibility of an XRI being ("taken
1543              over") by a new registrant.
1544            </t>
1545            -->
1546            <t>
1547              IdentifierがXRIであるとき、OpenID認証の
1548              &lt;xrd:Service&gt;要素を含む&lt;xrd:XRD&gt;要素は
1549              &lt;CanonicalID&gt;要素も含ま「なければなりません」
1550              (MUST)。
1551              この要素のコンテンツはClaimed Identifier
1552              (<xref target="identifying"/>参照)として使われ「なけ
1553              ればなりません」(MUST)。
1554              &lt;CanonicalID&gt;要素の第一の目的は決して再登録
1555              されない永続的なIdentifierを主張することであり、
1556              それゆえにXRIが新しい登録者によって引き継がれる
1557              ("taken over")可能性を防ぐためにも、これはきわめ
1558              て重大なセキュリティ上の配慮です。
1559            </t>
1560
1561            <!--
1562            <t>
1563              The Relying Party MUST confirm that the provider of the
1564              XRD that contains the &lt;CanonicalID&gt; element is
1565              authoritative for that Canonical ID and that this XRDS
1566              document is authoritative for the OpenID Service
1567              Element. Relying Parties should either do this manually
1568              or ensure that their resolver does this.
1569            </t>
1570            -->
1571            <t>
1572              Relying Partyは、&lt;CanonicalID&gt;要素を含むXRDの
1573              プロバイダがCanonical IDに関して信頼でき、この
1574              XRDSドキュメントがOpenID Service要素に関して信頼
1575              できる事を、確認「しなければなりません」(MUST)。
1576              Relying Partyはこれを手動で行うか、リゾルバが
1577              行う事を保証するか、いずれかをすべきです。
1578            </t>
1579
1580            <!--
1581            <t>
1582              When using XRI resolution, the Canonical ID MUST be
1583              used as the Claimed Identifier. For an XRI to be a
1584              valid Identifier, both the &lt;ProviderID&gt; and
1585              &lt;CanonicalID&gt; MUST be present in the discovered
1586              XRDS document.
1587            </t>
1588            -->
1589            <t>
1590              XRI解決を利用するとき、Canonical IDはClaimed Identifier
1591              として使われ「なければなりません」(MUST)。
1592              あるXRIが有効なIdentifierとなるために、&lt;ProviderID&gt;と
1593              &lt;CanonicalID&gt;が発見したXRDSドキュメントの中に
1594              存在「しなければなりません」(MUST)。
1595            </t>
1596
1597            <!--
1598            <t>
1599              When using URL Identifiers, the CanonicalID
1600              element MUST be ignored if present.
1601            </t>
1602            -->
1603            <t>
1604              URL Identifierを利用するとき、CanonicalID要素が
1605              もし存在していても無視「されなければなりません」(MUST)。
1606            </t>
1607          </section>
1608
1609          <section title="Additional Information">
1610            <!--
1611            <t>
1612              The "openid" namespace is no longer used as of OpenID
1613              Authentication 2.0. The "xrd" namespace is
1614              "xri://$xrd*($v*2.0)".
1615            </t>
1616            -->
1617            <t>
1618              "openid"名前空間はOpenID認証2.0のものとしては使われません。
1619              "xrd"名前空間は"xri://$xrd*($v*2.0)"です。
1620            </t>
1621
1622            <!--
1623            <t>
1624              For compatibility with deployed code, it is RECOMMENDED
1625              that Relying Parties also accept
1626              "http://openid.net/signon/1.0" or
1627              "http://openid.net/signon/1.1" for the value of
1628              &lt;xrd:Type&gt;, as described in the <xref
1629              target="compat_mode">OpenID Authentication 1.1
1630              Compatibility mode</xref> section. It is RECOMMENDED
1631              that Relying Parties supporting OpenID Authentication
1632              2.0 choose to use, if available, endpoints with the type
1633              "http://specs.openid.net/auth/2.0/server" and
1634              "http://specs.openid.net/auth/2.0/signon", in
1635              this order, as specified in <xref
1636              target="extracting_auth"/>
1637            </t>
1638            -->
1639            <t>
1640              使われているコードの互換性のために、Relying Partyは
1641              <xref target="compat_mode">OpenID認証1.1互換モード</xref>
1642              セクションで示される様に、
1643              "http://openid.net/signon/1.0"や"http://openid.net/signon/1.1"も
1644              &lt;xrd:Type&gt;の値として受け入れる事が「推奨されます」(RECOMMENDED)。
1645              <xref target="extracting_auth"/>で示される様に、
1646              "http://specs.openid.net/auth/2.0/server"と
1647              "http://specs.openid.net/auth/2.0/signon"という種類の
1648              エンドポイント(順同)が使用可能なら、
1649              OpenID認証2.0をサポートするRelying Partyを使う事を
1650              選ぶ事が推奨されます(RECOMMENDED)。
1651            </t>
1652
1653            <!--
1654            <t>
1655              If an OP supports extensions (<xref target="extensions"
1656              />), the extensions SHOULD be listed as additional
1657              &lt;xrd:Type&gt; child elements of the
1658              &lt;xrd:Service&gt; element.
1659            </t>
1660            -->
1661            <t>
1662              もしOPが拡張(<xref target="extensions"/>)をサポートするなら、
1663              拡張は
1664              &lt;xrd:Service&gt;要素の付加された&lt;xrd:Type&gt;子要素として
1665              列挙される「べきです」(SHOULD)。
1666            </t>
1667
1668          </section>
1669
1670        </section>
1671
1672        <section anchor="html_disco" title="HTML-Based Discovery">
1673          <!--
1674          <t>
1675            HTML-Based discovery MUST be supported by Relying
1676            Parties. HTML-Based discovery is only usable for discovery
1677            of Claimed Identifiers. OP Identifiers must be XRIs or
1678            URLs that support XRDS discovery.
1679          </t>
1680          -->
1681          <t>
1682            HTML-Based discoveryはRelying Partyによってサポート
1683            「されなければなりません」(MUST)。
1684            HTML-Based discoveryはClaimed Identifierの発見のために
1685            のみ利用できます。
1686            OP IdentifierはXRIかXRDS discoveryをサポートするURL
1687            「でなければなりません」(MUST)。
1688          </t>
1689
1690          <!--
1691          <t>
1692            To use HTML-Based discovery, an HTML document MUST be
1693            available at the URL of the Claimed Identifier. Within the
1694            HEAD element of the document:
1695
1696            <list>
1697              <t>
1698                A LINK element MUST be included with attributes
1699                "rel" set to "openid2.provider" and "href" set to an OP
1700                Endpoint URL
1701              </t>
1702              <t>
1703                A LINK element MAY be included with attributes
1704                "rel" set to "openid2.local_id" and "href" set to the
1705                end user's OP-Local Identifier
1706              </t>
1707            </list>
1708          </t>
1709          -->
1710
1711          <t>
1712            HTML-Based discoveryを使う為に、HTMLドキュメントは
1713            Claimed IdentifierのURLで入手でき「なければなりません」(MUST)。
1714            ドキュメントのHEAD要素の中に:
1715            <list>
1716              <t>
1717                "rel"属性の値が"openid2.provider"で"href"属性の値が
1718                OP Endpoint URLな1つのLINK要素を含「まなければならない」(MUST)
1719              </t>
1720              <t>
1721                "rel"属性の値が"openid2.local_id"で"href"属性の値が
1722                エンドユーザーのOP-Local Identifierな1つのLINK要素を
1723                含む「かもしれません」(MAY)
1724              </t>
1725            </list>
1726          </t>
1727
1728          <!--
1729          <t>
1730            The protocol version when HTML discovery is performed is
1731            "http://specs.openid.net/auth/2.0/signon".
1732          </t>
1733          -->
1734          <t>
1735            HTML discoveryが行われたときのプロトコルバージョンは
1736            "http://specs.openid.net/auth/2.0/signon"です。
1737          </t>
1738
1739          <!--
1740          <t>
1741            The host of the HTML document MAY be different from the
1742            end user's OP's host.
1743          </t>
1744          -->
1745          <t>
1746            HTMLドキュメントのホストはエンドユーザーのOPのホスト
1747            とは異なる「かもしれません」(MAY)。
1748          </t>
1749
1750          <!--
1751          <t>
1752            The "openid2.provider" and "openid2.local_id" URLs MUST NOT
1753            include entities other than "&amp;amp;", "&amp;lt;",
1754            "&amp;gt;", and "&amp;quot;". Other characters that would
1755            not be valid in the HTML document or that cannot be
1756            represented in the document's character encoding MUST be
1757            escaped using the percent-encoding (%xx) mechanism
1758            described in <xref target="RFC3986"/>.
1759          </t>
1760          -->
1761          <t>
1762            "openid2.provider"と"openid2.local_id"のURLは"&amp;amp;",
1763            "&amp;lt;", "&amp;gt;", "&amp;quot;"以外のエンティティを
1764            含んでは「なりません」(MUST NOT)。
1765            HTMLドキュメント中で妥当でないかドキュメントの
1766            エンコーディング中で表現できないような他の文字は、
1767            <xref target="RFC3986"/>で示されるパーセントエンコーディング
1768            (%xx)メカニズムを使ってエスケープ「されなければなりません」(MUST)。
1769          </t>
1770
1771          <!--
1772          <t>
1773            As discussed in the <xref
1774            target="compat_mode">OpenID Authentication 1.1
1775            Compatibility mode</xref> section, these discovery tags
1776            are not the same as in previous versions of the protocol.
1777            While the same data is conveyed, the names have changed which
1778            allows a Relying Party to determine the protocol version
1779            being used. A Relying Party MAY encounter a Claimed Identifier
1780            which uses HTML-Based Discovery to advertise both version 1.1
1781            and 2.0 Providers.
1782          </t>
1783          -->
1784          <t>
1785            <xref target="compat_mode">OpenID認証1.1互換モード</xref>
1786            セクションで議論される様に、これらのディスカバリータグは
1787            プロトコルの前バージョンと同じではありません。
1788            同じデータが伝達される間、名前を変えることで、
1789            Relying Partyに利用するプロトコルバージョンを決定することを
1790            許可します。
1791            Relying Partyはバージョン1.1と2.0のプロバイダの両方を
1792            通知するためにHTML-Based Discoveryを使うClaimed Identifierに
1793            出会う「かもしれません」(MAY)。
1794          </t>
1795        </section>
1796      </section>
1797    </section>
1798
1799
1800    <section title="Establishing Associations" anchor="associations">
1801      <!--
1802      <t>
1803        An association between the Relying Party and the OpenID Provider
1804        establishes a shared secret between them, which is used to verify
1805        subsequent protocol messages and reduce round trips.
1806      </t>
1807      -->
1808      <t>
1809        Relying PartyとOpenID Providerの間の関連付けは、それらの間で
1810        共有暗号鍵 (shared secret)を確立し、続くプロトコルメッセージ
1811        を検証したりラウンドトリップを減らすために使われます。
1812      </t>
1813
1814      <!--
1815      <t>
1816        It is RECOMMENDED that a Relying Party form associations if it
1817        is possible for it to do so. If a Relying Party is incapable
1818        of creating or storing associations, <xref target="check_auth"/>
1819        provides an alternate verification mechanism referred to as
1820        Stateless Mode.
1821      </t>
1822      -->
1823      <t>
1824        可能であればRelying Partyが関連付けをつくることが推奨されます(RECOMMENDED)。
1825        もしRelying Partyが関連付けを作るか記憶できないなら、<xref target="check_auth"/>は
1826        ステートレスモードの様な代わりの検証メカニズムを提供するために参照されます。
1827      </t>
1828
1829      <section title="Association Session Request">
1830        <!--
1831        <t>
1832          An association session is initiated by a <xref
1833          target="direct_comm">direct request</xref> from a Relying
1834          Party to an OP Endpoint URL with the "openid.mode" key
1835          having the value of "associate".
1836        </t>
1837        -->
1838        <t>
1839          関連付けセッションは、Relying Partyから値が"associate"の
1840          "openid.mode"キーをつけたOP Endpoint URLへの
1841          <xref target="direct_comm">直接リクエスト</xref>によって開始されます。
1842        </t>
1843
1844        <section title="Common Request Parameters" toc="exclude">
1845          <!--
1846          <t>
1847            These parameters are common to all association requests:
1848          </t>
1849          -->
1850          <t>
1851            これらのパラメーターは全ての関連付けリクエストで共通です:
1852          </t>
1853          <t>
1854            <list style="symbols">
1855              <t>openid.ns
1856              <list style="empty">
1857                <!--
1858                <t>
1859                  As specified in <xref target="http_encoding"/>.
1860                </t>
1861                -->
1862                <t>
1863                  <xref target="http_encoding"/>で示される通り。
1864                </t>
1865              </list>
1866              </t>
1867              <t>openid.mode
1868              <list style="empty">
1869                <!--
1870                <t> Value: "associate"</t>
1871                -->
1872                <t>値: "associate"</t>
1873              </list>
1874              </t>
1875
1876              <t>openid.assoc_type
1877              <list style="empty">
1878                <!--
1879                <t> The preferred association type. The association
1880                type defines the algorithm to be used to sign
1881                subsequent messages.</t>
1882                -->
1883                <t>
1884                  望ましい関連付けタイプ。関連付けタイプは
1885                  続くメッセージに署名するために使われるアルゴリズムを
1886                  定義します。
1887                </t>
1888                <!--
1889                <t> Value: A valid association type from <xref
1890                target="assoc_types"/></t>
1891                -->
1892                <t>値: <xref target="assoc_types"/>にある有効な関連付けタイプ。</t>
1893              </list>
1894              </t>
1895
1896              <t>openid.session_type
1897              <list style="empty">
1898                <!--
1899                <t>
1900                  The preferred association session type. This
1901                  defines the method used to encrypt the association's
1902                  MAC key in transit.
1903                </t>
1904                -->
1905                <t>
1906                  望ましい関連付けセッションタイプ。これは
1907                  トランジットのMACキーの関連付けを暗号化する事に使われる
1908                  方法を定義します。
1909                </t>
1910                <!--
1911                <t>
1912                  Value: A valid association session type from
1913                  <xref target="assoc_sess_types"/>.
1914                </t>
1915                -->
1916                <t>
1917                  値: <xref target="assoc_sess_types"/>にある有効な関連付けセッションタイプ。
1918                </t>
1919                <!--
1920                <t>
1921                  Note: Unless using transport layer encryption,
1922                  "no-encryption" MUST NOT be used.
1923                </t>
1924                -->
1925                <t>
1926                  注: トランスポート層暗号化を使わない場合、
1927                  "no-encryption"を使っては「いけません」(MUST NOT)。
1928                </t>
1929              </list>
1930              </t>
1931            </list>
1932          </t>
1933        </section>
1934
1935        <section title="Diffie-Hellman Request Parameters" toc="exclude">
1936          <!--
1937          <t>
1938            The following parameters are common to requests whose
1939            requested association session type is "DH-SHA1" or
1940            "DH-SHA256":
1941          </t>
1942          -->
1943          <t>
1944            以降のパラメータは関連付けセッションタイプに
1945            "DH-SHA1"か"DH-SHA256"を要求したリクエストで共通です:
1946          </t>
1947          <t>
1948            <list style="symbols">
1949              <t>
1950                openid.dh_modulus
1951                <list style="empty">
1952                  <!--
1953                  <t>Value: base64(btwoc(p))</t>
1954                  -->
1955                  <t>値: base64(btwoc(p))</t>
1956                  <!--
1957                  <t>Default: See <xref target="pvalue"/></t>
1958                  -->
1959                  <t>デフォルト: <xref target="pvalue"/>参照</t>
1960                </list>
1961              </t>
1962              <t>
1963                openid.dh_gen
1964                <list style="empty">
1965                  <!--
1966                  <t>Value: base64(btwoc(g))</t>
1967                  -->
1968                  <t>値: : base64(btwoc(g))</t>
1969                  <!--
1970                  <t>Default: g = 2</t>
1971                  -->
1972                  <t>デフォルト: g = 2</t>
1973                </list>
1974              </t>
1975              <t>
1976                openid.dh_consumer_public
1977                <list style="empty">
1978                  <!--
1979                  <t>Value: base64(btwoc(g ^ xa mod p))</t>
1980                  -->
1981                  <t>値: base64(btwoc(g ^ xa mod p))</t>
1982                </list>
1983              </t>
1984            </list>
1985          </t>
1986          <!--
1987          <t>
1988            See <xref target="dh_sessions"/> for more information on
1989            these parameters.
1990          </t>
1991          -->
1992          <t>
1993            これらのパラメータの更なる情報は<xref target="dh_sessions"/>を参照。
1994          </t>
1995          <!--
1996          <t>
1997            NOTE: The 'btwoc' function is defined in <xref
1998            target="btwoc"/>.
1999          </t>
2000          -->
2001          <t>
2002            注: 'btwoc'関数は<xref target="btwoc"/>で定義されています。
2003          </t>
2004        </section>
2005      </section>
2006
2007      <section title="Association Session Response">
2008        <t>
2009          An association session response is a direct response from the
2010          OP to the Relying Party in <xref target="kvform">Key-Value
2011          Form</xref>.
2012        </t>
2013
2014        <section title="Common Response Parameters">
2015          <t>
2016            <list style="symbols">
2017              <t>
2018                ns
2019                <list style="empty">
2020                  <!--
2021                  <t>
2022                    As specified in <xref target="direct_response"/>.
2023                  </t>
2024                  -->
2025                  <t>
2026                    <xref target="direct_response"/>で示される通り。
2027                  </t>
2028                </list>
2029              </t>
2030              <t>
2031                assoc_handle
2032                <list style="empty">
2033                  <!--
2034                  <t>
2035                    The association handle is used as a key to refer
2036                    to this association in subsequent messages.
2037                  </t>
2038                  -->
2039                  <t>
2040                    関連付けハンドルは続くメッセージでの関連付け
2041                    を参照するキーとして使われます。
2042                  </t>
2043                  <!--
2044                  <t>
2045                    Value: A string 255 characters or less in length.
2046                    It MUST consist only of ASCII characters in the
2047                    range 33-126 inclusive (printable non-whitespace
2048                    characters).
2049                  </t>
2050                  -->
2051                  <t>
2052                    値: 255文字以内の文字列。33-126の範囲のASCII文字
2053                    (印字可能な非空白文字)から構成「されなければなりません」(MUST)。
2054                  </t>
2055                </list>
2056              </t>
2057              <t>
2058                session_type
2059                <list style="empty">
2060                  <!--
2061                  <t>
2062                    The value of the "openid.session_type" parameter
2063                    from the request. If the OP is unwilling or
2064                    unable to support this association type, it MUST
2065                    return an <xref target="refuse_assoc">unsuccessful
2066                    response</xref>.
2067                  </t>
2068                  -->
2069                  <t>
2070                    リクエストからの"openid.session_type"パラメータの値。
2071                    もしOPがこの関連付けタイプを望まないか利用できないなら、
2072                    <xref target="refuse_assoc">不成功のレスポンス</xref>
2073                    を返「さなければなりません」(MUST)。
2074                  </t>
2075                </list>
2076              </t>
2077              <t>
2078                assoc_type
2079                <list style="empty">
2080                  <!--
2081                  <t>
2082                    The value of the "openid.assoc_type" parameter
2083                    from the request. If the OP is unwilling or
2084                    unable to support this association type, it MUST
2085                    return an <xref target="refuse_assoc">unsuccessful
2086                    response</xref>.
2087                  </t>
2088                  -->
2089                  <t>
2090                    リクエストからの"openid.assoc_type"パラメータの値。
2091                    もしOPがこの関連付けタイプを望まないか利用できないなら、
2092                    <xref target="refuse_assoc">不成功のレスポンス</xref>
2093                    を返「さなければなりません」(MUST)。
2094                  </t>
2095                </list>
2096              </t>
2097              <t>
2098                expires_in
2099                <list style="empty">
2100                  <!--
2101                  <t>
2102                    The lifetime, in seconds, of this association.
2103                    The Relying Party MUST NOT use the association
2104                    after this time has passed.
2105                  </t>
2106                  -->
2107                  <t>
2108                    秒で表されるこの関連付けのライフタイム。
2109                    Relying Partyはこの時間が過ぎた後でその
2110                    関連付けを使っては「なりません」(MUST NOT)。
2111                  </t>
2112                  <!--
2113                  <t>
2114                    Value: An integer, represented in base 10 ASCII.
2115                  </t>
2116                  -->
2117                  <t>
2118                    値: 10進数のASCII文字で表現される整数。
2119                  </t>
2120                </list>
2121              </t>
2122            </list>
2123          </t>
2124        </section>
2125
2126        <section title="Unencrypted Response Parameters">
2127          <t>
2128            <list style="symbols">
2129              <t>
2130                mac_key
2131                <list style="empty">
2132                  <!--
2133                  <t>
2134                    The MAC key (shared secret) for this
2135                    association, <xref target="RFC3548">Base 64</xref>
2136                    encoded.
2137                  </t>
2138                  -->
2139                  <t>
2140                    <xref target="RFC3548">Base 64</xref>エンコードした
2141                    この関連付けの為のMACキー(共有暗号鍵)です。
2142                  </t>
2143                </list>
2144              </t>
2145            </list>
2146          </t>
2147        </section>
2148
2149
2150        <section title="Diffie-Hellman Response Parameters" toc="exclude">
2151          <t>
2152            <list style="symbols">
2153              <t>
2154                dh_server_public
2155                <list style="empty">
2156                  <!--
2157                  <t>
2158                    Value: base64(btwoc(g ^ xb mod p))
2159                  </t>
2160                  -->
2161                  <t>
2162                    値: base64(btwoc(g ^ xb mod p))
2163                  </t>
2164                  <!--
2165                  <t>
2166                    Description: The OP's Diffie-Hellman public key.
2167                  </t>
2168                  -->
2169                  <t>
2170                    概要: OPのDiffie-Hellman公開鍵。
2171                  </t>
2172                </list>
2173              </t>
2174              <t>
2175                enc_mac_key
2176                <list style="empty">
2177                  <!--
2178                  <t>
2179                    Value: base64(H(btwoc(g ^ (xa * xb) mod p)) XOR MAC key)
2180                  </t>
2181                  -->
2182                  <t>
2183                    値: base64(H(btwoc(g ^ (xa * xb) mod p)) XOR MAC key)
2184                  </t>
2185                  <!--
2186                  <t>
2187                    Description: The MAC key (shared secret),
2188                    encrypted with the secret Diffie-Hellman value. H
2189                    is either "SHA1" or "SHA256" depending on the
2190                    session type.
2191                  </t>
2192                  -->
2193                  <t>
2194                    概要: Diffie-Hellmanの秘密の値で暗号化したMACキー
2195                    (共有暗号鍵)。Hはセッションタイプに依存する
2196                    "SHA1"か"SHA256"のどちらかです。
2197                  </t>
2198                </list>
2199              </t>
2200            </list>
2201          </t>
2202          <!--
2203          <t>
2204            NOTE: The 'btwoc' function is defined in <xref
2205            target="btwoc"/>
2206          </t>
2207          -->
2208          <t>
2209            注: 'btwoc'関数は<xref target="btwoc"/>で定義されています。
2210          </t>
2211        </section>
2212
2213        <section anchor="refuse_assoc"
2214                 title="Unsuccessful Response Parameters">
2215          <!--
2216          <t>
2217            If the OP does not support a session type or association
2218            type, it MUST respond with a direct error message
2219            indicating that the association request failed. If there
2220            is another association session type or association type
2221            that is supported, the OP SHOULD include that information
2222            in the response.
2223          </t>
2224          -->
2225          <t>
2226            もしOPがセッションタイプか関連付けタイプをサポートしないなら、
2227            関連付けリクエストが失敗した事を示す直接のエラーメッセージで
2228            応答「しなければなりません」(MUST)。
2229            もし別の関連付けセッションタイプか関連付けタイプをサポートするなら、
2230            OPはその情報をレスポンスにふくめる「べきです」(SHOULD)。
2231          </t>
2232          <t>
2233            <list style="symbols">
2234              <t>
2235                ns
2236                <list style="empty">
2237                  <!--
2238                  <t>
2239                    As specified in <xref target="direct_response"/>.
2240                  </t>
2241                  -->
2242                  <t>
2243                    <xref target="direct_response"/>で示される通り。
2244                  </t>
2245                </list>
2246              </t>
2247              <t>
2248                error
2249                <list style="empty">
2250                  <!--
2251                  <t>
2252                    Value: A human-readable message indicating why the
2253                    association request failed.
2254                  </t>
2255                  -->
2256                  <t>
2257                    値: 関連付けリクエストが失敗した原因を示す
2258                    人間が読むことができるメッセージ。
2259                  </t>
2260                </list>
2261              </t>
2262              <t>
2263                error_code
2264                <list style="empty">
2265                  <!--
2266                  <t>
2267                    Value: "unsupported-type"
2268                  </t>
2269                  -->
2270                  <t>
2271                    値: "unsupported-type"
2272                  </t>
2273                </list>
2274              </t>
2275              <t>
2276                session_type
2277                <list style="empty">
2278                  <!--
2279                  <t>
2280                    Value: (optional) A valid association session type
2281                    from <xref target="assoc_sess_types"/> that the
2282                    OP supports.
2283                  </t>
2284                  -->
2285                  <t>
2286                    値: (optional) OPがサポートする、<xref target="assoc_sess_types"/>
2287                    にある有効な関連付けセッションタイプ
2288                  </t>
2289                </list>
2290              </t>
2291              <t>
2292                assoc_type
2293                <list style="empty">
2294                  <!--
2295                  <t>
2296                    Value: (optional) An association type supported by
2297                    the OP from <xref target="assoc_types"/>.
2298                  </t>
2299                  -->
2300                  <t>
2301                    値: (optional) OPがサポートする、<xref target="assoc_types"/>
2302                    にある関連付けタイプ。
2303                  </t>
2304                </list>
2305              </t>
2306            </list>
2307          </t>
2308          <!--
2309          <t>
2310            Upon receipt of an "unsupported-type" response, the
2311            Relying Party MAY make another request with the specified
2312            association session type and association type. If no
2313            association is established, the Relying Party MAY continue
2314            the authentication process in <xref target="check_auth">
2315            Direct Verification</xref>.
2316          </t>
2317          -->
2318          <t>
2319            "unsupported-type"レスポンスを受け取ったとき、
2320            Relying Partyは関連付けセッションタイプと関連付けタイプ
2321            を指定する別のリクエストをつくる「かもしれません」(MAY)。
2322            もし関連付けが確立されなかったなら、Relying Partyは
2323            <xref target="check_auth">直接検証</xref>で認証手続きを
2324            継続する「かもしれません」(MAY)。
2325          </t>
2326        </section>
2327      </section>
2328
2329      <section title="Association Types" anchor="assoc_types">
2330        <section title="HMAC-SHA1">
2331          <!--
2332          <t>
2333            An association of type "HMAC-SHA1" uses the <xref
2334            target="sign_algos">HMAC-SHA1</xref> signature algorithm.
2335          </t>
2336          -->
2337          <t>
2338            タイプが"HMAC-SHA1"の関連付けは<xref target="sign_algos">HMAC-SHA1</xref>
2339            署名アルゴリズムを使います。
2340          </t>
2341        </section>
2342
2343        <section title="HMAC-SHA256">
2344          <!--
2345          <t>
2346            An association of type "HMAC-256" uses the <xref
2347            target="sign_algos">HMAC-SHA256</xref> signature
2348            algorithm.
2349          </t>
2350          -->
2351          <t>
2352            タイプが"HMAC-SHA256"の関連付けは<xref target="sign_algos">HMAC-SHA256</xref>
2353            署名アルゴリズムを使います。
2354          </t>
2355        </section>
2356      </section>
2357
2358      <section title="Association Session Types" anchor="assoc_sess_types">
2359        <!--
2360        <t>
2361          OpenID Authentication defines three valid association
2362          session types: "no-encryption", "DH-SHA1", and "DH-SHA256".
2363        </t>
2364        -->
2365        <t>
2366          OpenID認証は3つの有効な関連付けセッションタイプを定義します:
2367          "no-encryption", "DH-SHA1", "DH-SHA256"
2368        </t>
2369
2370        <section title="No-Encryption Association Sessions"
2371                 toc="exclude">
2372          <!--
2373          <t>
2374            In a "no-encryption" association session, the OP sends
2375            the association MAC key in plain-text to the Relying Party.
2376            This makes it possible for an eavesdropper to intercept
2377            the key, and forge messages to this Relying Party when not
2378            using transport layer encryption. Therefore, "no-encryption"
2379            association sessions MUST NOT be used unless the messages
2380            are using transport layer encryption. See <xref target="preventing_eavesdropping"/>
2381            for more information.
2382          </t>
2383          -->
2384          <t>
2385            "no-encryption"関連付けセッションで、OPはRelying Partyに関連付けの
2386            MACキーをプレインテキストで送ります。
2387            この事は、トランスポート層暗号化を使わないRelying Partyに対して、
2388            盗聴者がキーを傍受したりメッセージを偽造する事を可能にします。
2389            ゆえに、"no-encryption"関連付けセッションはトランスポート層暗号化
2390            を使ったメッセージ以外で使っては「なりません」(MUST NOT)。
2391            詳しい情報は<xref target="preventing_eavesdropping"/>を参照。
2392          </t>
2393
2394          <!--
2395          <t>
2396            The MAC key sent by the OP MUST be the length specified
2397            for the requested association type, as specified in <xref
2398            target="sign_algos"/>.
2399          </t>
2400          -->
2401          <t>
2402            OPによって送られるMACキーは、<xref target="sign_algos"/>で示される様に、
2403            要求された関連付けタイプで指定される長さ「でなければなりません」(MUST)。
2404          </t>
2405
2406        </section>
2407
2408        <section title="Diffie-Hellman Association Sessions"
2409                 anchor="dh_sessions" toc="exclude">
2410          <!--
2411          <t>
2412            The "DH-SHA1" and "DH-SHA256" association types use
2413            Diffie-Hellman Key Exchange to securely transmit the
2414            shared secret.
2415          </t>
2416          -->
2417          <t>
2418            "DH-SHA1"と"DH-SHA256"の関連付けタイプは、共有暗号鍵
2419            (shared secret)を安全に渡す為にDiffie-Hellman鍵共有法
2420            (DH 法)を使います。
2421          </t>
2422          <!--
2423          <t>
2424            The MAC key MUST be the same length as the output of H,
2425            the hash function - 160 bits (20 bytes) for DH-SHA1 or 256
2426            bits (32 bytes) for DH-SHA256, as well as the output of
2427            the signature algorithm of this association.
2428          </t>
2429          -->
2430          <t>
2431            この関連付けの署名アルゴリズムの出力同様に、
2432            MACキーは、DH-SHA1の160ビット(20バイト)か
2433            DH-SHA256の256ビット(32バイト)であるハッシュ関数Hの
2434            出力と同じ長さ「でなければなりません」(MUTS)。
2435          </t>
2436
2437          <!--
2438          <t>
2439            The Relying Party specifies a modulus, p, and a generator,
2440            g. The Relying Party chooses a random private key xa and
2441            OpenID Provider chooses a random private key xb, both in
2442            the range [1 .. p-1]. The shared secret used to encrypt
2443            the MAC key is thus g ^ (xa * xb) mod p = (g ^ xa) ^ xb
2444            mod p = (g ^ xb) ^ xa mod p. For more information, see
2445            <xref target="RFC2631"/>. For information on the
2446            selection of random values, see <xref target="RFC1750"/>.
2447          </t>
2448          -->
2449          <t>
2450            Relying Partyは係数pとジェネレータgを指定します。
2451            範囲 [1 .. p-1]で、Relying Partyはランダムなプライベートキーxaを選び、
2452            OpenID Providerはランダムなプライベートキーxbを選びます。
2453            MACキーを暗号化する為に使われる共有暗号鍵は
2454            g ^ (xa * xb) mod p = (g ^ xa) ^ xb mod p = (g ^ xb) ^ xa mod p
2455            で求めます。更なる情報については、<xref target="RFC2631"/>を参照。
2456            ランダム値の選択に関する情報は、<xref target="RFC1750"/>を参照。
2457          </t>
2458        </section>
2459      </section>
2460    </section>
2461
2462    <section title="Requesting Authentication"
2463             anchor="requesting_authentication">
2464      <!--
2465      <t>
2466        Once the Relying Party has successfully performed discovery
2467        and (optionally) created an association with the discovered
2468        OP Endpoint URL, it can send an authentication request to the
2469        OP to obtain an assertion. An authentication request is an
2470        <xref target="indirect_comm">indirect request</xref>.
2471      </t>
2472      -->
2473      <t>
2474        Relying Partyがディスカバリーを成功させ、見つけた
2475        OP Endpoint URLとの関連付けを作った(任意)とき、
2476        アサーションを獲得するためにOPに認証リクエストを
2477        送る事ができます。
2478        認証リクエストは<xref target="indirect_comm">間接リクエスト</xref>です。
2479      </t>
2480
2481      <section title="Request Parameters">
2482        <t>
2483          <list style="symbols">
2484            <t>
2485              openid.ns
2486              <list style="empty">
2487                <!--
2488                <t>
2489                  As specified in <xref target="http_encoding"/>.
2490                </t>
2491                -->
2492                <t>
2493                  <xref target="http_encoding"/>で示される通り。
2494                </t>
2495              </list>
2496            </t>
2497
2498            <t>
2499              openid.mode
2500              <list style="empty">
2501                <!--
2502                <t>
2503                  Value: "checkid_immediate" or "checkid_setup"
2504                </t>
2505                -->
2506                <t>
2507                  値: "checkid_immediate"か"checkid_setup"
2508                </t>
2509                <!--
2510                <t>
2511                  Note: If the Relying Party wishes the end user to be
2512                  able to interact with the OP, "checkid_setup"
2513                  should be used. An example of a situation where
2514                  interaction between the end user and the OP is not
2515                  desired is when the authentication request is
2516                  happening asynchronously in JavaScript.
2517                </t>
2518                -->
2519                <t>
2520                  注: もしRelying PartyがエンドユーザーにOPと
2521                  対話できるよう望むなら、"checkid_setup"を
2522                  使う「べきです」(SHOULD)。
2523                  エンドユーザーとOPの間の対話が望まれない
2524                  状況の例は、JavaScriptで非同期に認証リクエ
2525                  ストが発生するときです。
2526                </t>
2527              </list>
2528            </t>
2529
2530            <t>
2531              openid.claimed_id
2532              <list style="empty">
2533                <!--
2534                <t>
2535                  Value: (optional) The Claimed Identifier.
2536                </t>
2537                -->
2538                <t>
2539                  値: (optional) Claimed Identifier
2540                </t>
2541                <!--
2542                <t>
2543                  "openid.claimed_id" and "openid.identity" SHALL
2544                  be either both present or both absent. If neither
2545                  value is present, the assertion is not about an
2546                  identifier, and will contain other information in
2547                  its payload, using
2548                  <xref target="extensions">extensions</xref>.
2549                </t>
2550                -->
2551                <t>
2552                  "openid.claimed_id"と"openid.identity"は両方存在
2553                  するか両方存在しないかのどちらか「とします」(SHALL)。
2554                  もしどちらの値もなければ、アサーションはIdentifier
2555                  に関するものではなく、<xref target="extensions">拡張</xref>
2556                  を使ってそのペイロードに他の情報を含めるでしょう。
2557                </t>
2558                <!--
2559                <t>
2560                  It is RECOMMENDED that OPs accept XRI identifiers
2561                  with or without the "xri://" prefix, as specified
2562                  in the <xref target="normalization">Normalization
2563                  </xref> section.
2564                </t>
2565                -->
2566                <t>
2567                  <xref target="normalization">正規化</xref>セクション
2568                  で示される様に、OPが"xri://"接頭辞なしのXRI Identifier
2569                  を受け入れる事が「推奨されます」(RECOMMENDED)。
2570                </t>
2571              </list>
2572            </t>
2573
2574            <t>
2575              openid.identity
2576              <list style="empty">
2577                <!--
2578                <t>
2579                  Value: (optional) The OP-Local Identifier.
2580                </t>
2581                -->
2582                <t>
2583                  値: (optional) OP-Local Identifier
2584                </t>
2585                <!--
2586                <t>
2587                  If a different OP-Local Identifier is not specified,
2588                  the claimed identifier MUST be used as the value for
2589                  openid.identity.
2590                </t>
2591                -->
2592                <t>
2593                  もし異なるOP-Local Identifierが指定されなければ、
2594                  Claimed Identifierがopenid.identityの値として使わ
2595                  れ「なければなりません」(MUST)。
2596                </t>
2597                <!--
2598                <t>
2599                  Note: If this is set to the special value
2600                  "http://specs.openid.net/auth/2.0/identifier_select"
2601                  then the OP SHOULD choose an Identifier that belongs
2602                  to the end user. This parameter MAY be omitted if
2603                  the request is not about an identifier (for instance
2604                  if an extension is in use that makes the request
2605                  meaningful without it; see openid.claimed_id above).
2606                </t>
2607                -->
2608                <t>
2609                  注: もし特別な値"http://specs.openid.net/auth/2.0/identifier_select"
2610                  であれば、OPはエンドユーザーに所属するIdentifierを選ぶ「べきです」(SHOULD)。
2611                </t>
2612              </list>
2613            </t>
2614
2615            <t>
2616              openid.assoc_handle
2617              <list style="empty">
2618                <!--
2619                <t>
2620                  Value: (optional) A handle for an association
2621                  between the Relying Party and the OP that SHOULD be
2622                  used to sign the response.
2623                </t>
2624                -->
2625                <t>
2626                  値: (optional) レスポンスに署名する為に使われる
2627                  「べきである」(SHOULD)、Relying PartyとOPの間の
2628                  関連付けに関するハンドルです。
2629                </t>
2630                <!--
2631                <t>
2632                  Note: If no association handle is sent, the
2633                  transaction will take place in <xref target="check_auth">
2634                  Stateless Mode</xref>.
2635                </t>
2636                -->
2637                <t>
2638                  注: もし関連付けハンドルが送られないなら、
2639                  トランザクションは<xref target="check_auth">
2640                  ステートレスモード</xref>で行われます。
2641                </t>
2642              </list>
2643            </t>
2644
2645            <t>
2646              openid.return_to
2647              <list style="empty">
2648                <!--
2649                <t>
2650                  Value: (optional) URL to which the OP SHOULD return
2651                  the User-Agent with the response indicating the
2652                  status of the request.
2653                </t>
2654                -->
2655                <t>
2656                  値: (optional) OPがリクエストのステータスを示す
2657                  レスポンスとともにUser-Agentに返すべきURLです。
2658                </t>
2659                <!--
2660                <t>
2661                  Note: If this value is not sent in the request it
2662                  signifies that the Relying Party does not wish
2663                  for the end user to be returned.
2664                </t>
2665                -->
2666                <t>
2667                  注: もしこの値がリクエストで送られないなら、
2668                  Relying Partyがエンドユーザーのために返される
2669                  事を望まなかったことの現れです。
2670                </t>
2671                <!--
2672                <t>
2673                  Note: The return_to URL MAY be used as a mechanism
2674                  for the Relying Party to attach context about the
2675                  authentication request to the authentication
2676                  response. This document does not define a mechanism
2677                  by which the RP can ensure that query parameters are
2678                  not modified by outside parties; such a mechanism
2679                  can be defined by the RP itself.
2680                </t>
2681                -->
2682                <t>
2683                  注: return_toのURLは認証リクエストに関する
2684                  コンテキストを認証レスポンスに添えるための
2685                  メカニズムとして使われる「かもしれません」(MAY)。
2686                </t>
2687              </list>
2688            </t>
2689
2690            <t>
2691              openid.realm
2692              <list style="empty">
2693                <!--
2694                <t>
2695                  Value: (optional) URL pattern the OP SHOULD ask the
2696                  end user to trust. See <xref target="realms"/>.
2697                  This value MUST be sent if openid.return_to is
2698                  omitted.
2699                </t>
2700                -->
2701                <t>
2702                  値: (optional) OPがエンドユーザーを信用する
2703                  ために尋ねる「べき」(SHOULD)URLパターンです。
2704                </t>
2705                <!--
2706                <t>
2707                  Default: return_to URL
2708                </t>
2709                -->
2710                <t>
2711                  デフォルト: return_toのURL
2712                </t>
2713              </list>
2714            </t>
2715          </list>
2716        </t>
2717      </section>
2718
2719      <section title="Realms" anchor="realms">
2720        <!--
2721        <t>
2722          A "realm" is a pattern that represents the part of URL-space
2723          for which an OpenID Authentication request is valid. A realm
2724          is designed to give the end user an indication of the scope
2725          of the authentication request. OPs SHOULD present the realm
2726          when requesting the end user's approval for an authentication
2727          request. The realm SHOULD be used by OPs to uniquely identify
2728          Relying Parties. For example, OPs MAY use the realm to allow
2729          the end user to automate approval of authentication requests.
2730        </t>
2731        -->
2732        <t>
2733          "realm"はOpenID認証リクエストが有効であるためのURL空間
2734          の一部を表すパターンです。
2735          realmは認証リクエストの範囲の目安をエンドユーザーに
2736          与えるために設計されています。
2737          OPは認証リクエストについてエンドユーザーの承認を要求
2738          するとき、realmを提示「すべき」です(SHOULD)。
2739          realmはRelying Partyをユニークに識別するために、OP
2740          によって使われる「べき」(SHOULD)です。
2741          例えば、OPは認証リクエストの承認を自動化する事をエン
2742          ドユーザーに許可するために、realmを使う「かもしれません」(MAY)。
2743        </t>
2744
2745        <!--
2746        <t>
2747          A realm pattern is a URL, with the following changes:
2748          <list style="symbols">
2749            <t>
2750              A realm MUST NOT contain a URI fragment
2751            </t>
2752            <t>
2753              A realm MAY contain a wild-card at the beginning of the
2754              URL authority section. A wild-card consists of the
2755              characters "*." prepended to the DNS name in the
2756              authority section of the URL.
2757            </t>
2758          </list>
2759        </t>
2760        -->
2761        <t>
2762          realmパターンはURLですが、以下の違いがあります:
2763          <list style="symbols">
2764            <t>
2765              realmはURI fragmentを含んでは「いけません」(MUST NOT)
2766            </t>
2767            <t>
2768              realmはURL authorityセクションの始まりにワイルドカード
2769              を含む「かもしれません」(MAY)。ワイルドカードは文字
2770              "*."から構成され、URL authorityセクションのDNS名の前に
2771              つけられます。
2772            </t>
2773          </list>
2774        </t>
2775
2776        <!--
2777        <t>
2778          A URL matches a realm if:
2779
2780          <list style="symbols">
2781            <t>
2782              The URL scheme and port of the URL are identical to those
2783              in the realm. See <xref target="RFC3986">RFC
2784              3986</xref>, section 3.1 for rules about URI matching.
2785            </t>
2786
2787            <t>
2788              The URL's path is equal to or a sub-directory of the
2789              realm's path.
2790            </t>
2791
2792            <t>
2793              Either:
2794              <list style="numbers">
2795                <t>
2796                  The realm's domain contains the wild-card characters
2797                  "*.", and the trailing part of the URL's domain is
2798                  identical to the part of the realm following the
2799                  "*." wildcard, or
2800                </t>
2801                <t>
2802                  The URL's domain is identical to the realm's domain
2803                </t>
2804              </list>
2805            </t>
2806          </list>
2807
2808          When present, the "openid.return_to" URL MUST match the
2809          "openid.realm", or the OP MUST return an <xref
2810          target="indirect_error">indirect error response</xref>.
2811        </t>
2812        -->
2813        <t>
2814          以下の場合にURLはrealmとマッチします:
2815
2816          <list style="symbols">
2817            <t>
2818              URLのschemeとportがrealmのものと同一である。
2819              URIマッチングに関する規則に関しては、
2820              <xref target="RFC3986">RFC 3986</xref>のセクション3.1を参照。
2821            </t>
2822
2823            <t>
2824              URLのpathがrealmのものと同じかサブディレクトリに位置
2825              する。
2826            </t>
2827
2828            <t>
2829              どちらか:
2830              <list style="numbers">
2831                <t>
2832                  realmのドメインがワイルドカード文字"*."を含み、
2833                  URLのドメインの続く部分がrealmの"*."ワイルドカード
2834                  以降の部分と同一であるか、
2835                </t>
2836                <t>
2837                  URLのドメインがrealmのドメインと同一
2838                </t>
2839              </list>
2840            </t>
2841          </list>
2842
2843          "openid.return_to"が存在するとき、そのURLは"openid.realm"
2844          にマッチ「しなければならず」(MUST)、そうでないならOPは
2845          <xref target="indirect_error">間接エラーレスポンス</xref>
2846          を返さ「なければなりません」(MUST)。
2847        </t>
2848
2849        <!--
2850        <t>
2851          It is RECOMMENDED that OPs protect their users from making
2852          assertions with overly-general realms, like http://*.com/ or
2853          http://*.co.uk/. Overly general realms can be dangerous when
2854          the realm is used for identifying a particular Relying
2855          Party. Whether a realm is overly-general is at the
2856          discretion of the OP.
2857        </t>
2858        -->
2859        <t>
2860          OPはhttp://*.com/やhttp://*.co.uk/の様なあまりに一般的な
2861          realmによるアサーション作成から、ユーザーを保護する事
2862          が「推奨されます」(RECOMMENDED)。
2863          realmが個々のRelying Partyを識別する為に使われるとき、
2864          あまりに一般的なrealmは危険です。
2865          realmがあまりに一般的であるかどうかは、OPの自由裁量です。
2866        </t>
2867
2868        <section title="Using the Realm for Return URL Verification"
2869                 anchor="return_to_verification">
2870          <!--
2871          <t>
2872            OpenID providers SHOULD verify that the return_to URL
2873            specified in the request is an OpenID relying party
2874            endpoint. To verify a return_to URL, obtain the relying
2875            party endpoints for the realm by performing <xref
2876            target="rp_discovery">discovery on the relying
2877            party</xref>. As always when performing discovery, the
2878            discovered URL is the URL of the last HTTP response,
2879            following redirects. If any redirects are followed when
2880            performing discovery on the realm, verification has
2881            failed. If discovery has successfuly completed, check to
2882            make sure that the return_to URL matches one of the
2883            relying party endpoints.
2884          </t>
2885          -->
2886          <t>
2887            OpenID Providerはリクエストで指定されるreturn_to URL
2888            がOpenIDのRelying Partyのエンドポイントである事を
2889            検証「すべき」(SHOULD)です。
2890            return_to URLを検証するために、
2891            <xref target="rp_discovery">Relying Partyのディスカバリー</xref>
2892            を行う事によってrealmに関するRelying Partyのエンドポイント
2893            を得ます。
2894            ディスカバリーを行うときはいつもどおり、発見された
2895            URLはリダイレクトに従った最後のHTTPレスポンスのURLです。
2896            ディスカバリーを行うときにrealmから外れるリダイレクト
2897            がされたとき、検証は失敗します。
2898            もしディスカバリーが成功裏に終わったなら、return_to URL
2899            がRelying Partyのエンドポイントの1つにマッチする事を
2900            念を押して確認します。
2901          </t>
2902          <!--
2903          <t>
2904            A realm may contain a wildcard, and so may not be a valid
2905            URL. In that case, perform discovery on the URL obtained
2906            by substituting "www" for the wildcard in the realm.
2907          </t>
2908          -->
2909          <t>
2910            realmはワイルドカードを含むかもしれず、有効なURLで
2911            ないかもしれません。その場合、realmのワイルドカード
2912            を"www"で代用する事によって得たURLに対してディスカバリー
2913            を行います。
2914          </t>
2915          <!--
2916          <t>
2917            To match a return_to URL against a relying party endpoint,
2918            use the same rules as for matching the return_to URL
2919            against the realm, treating the relying party's endpoint
2920            URL as the realm. Relying party endpoint URLs MUST NOT
2921            contain a domain wildcard, and SHOULD be as specific as
2922            possible.
2923          </t>
2924          -->
2925          <t>
2926            Relying Partyのエンドポイントに対してreturn_to URLを
2927            マッチさせる為に、Relying Partyのエンドポイントを
2928            realmとして扱い、realmに対してreturn_to URlをマッチ
2929            させるための同じルールを使います。
2930          </t>
2931          <!--
2932          <t>
2933            If verification is attempted and fails, the provider
2934            SHOULD NOT send a positive assertion to that return_to
2935            URL.
2936          </t>
2937          -->
2938          <t>
2939            もし検証が試みられて失敗するなら、プロバイダは
2940            return_to URLに肯定のアサーションを送る「べきではありません」(SHOULD NOT)。
2941          </t>
2942          <!--
2943          <t>
2944            Providers MAY cache verified return_to URLs.
2945          </t>
2946          -->
2947          <t>
2948            プロバイダは検証したreturn_to URLをキャッシュする
2949            「かもしれません」(MAY)。
2950          </t>
2951        </section>
2952      </section>
2953
2954      <section title="Immediate Requests">
2955        <!--
2956        <t>
2957          When requesting authentication, the Relying Party MAY
2958          request that the OP not interact with the end user. In
2959          this case the OP MUST respond immediately with either an
2960          assertion that authentication is successful, or a response
2961          indicating that the request cannot be completed without
2962          further user interaction. This is accomplished by an
2963          authentication request with "openid.mode" set to
2964          "checkid_immediate".
2965        </t>
2966        -->
2967        <t>
2968          認証を要求するとき、Relying PartyはOPがエンドユーザーと
2969          対話的でない事を要求する「かもしれません」(MAY)。
2970          この場合OPは直接に認証が成功である事のアサーションか、
2971          要求が更なるユーザーとの対話なしに完了できない事を
2972          示すレスポンスを返さ「なければなりません」(MUST)。
2973          これは"openid.mode"に"checkid_immediate"をセットした
2974          認証リクエストによって遂行されます。
2975        </t>
2976      </section>
2977    </section>
2978
2979    <section title="Responding to Authentication Requests"
2980             anchor="responding_to_authentication">
2981      <!--
2982      <t>
2983        When an authentication request comes from the User-Agent via
2984        <xref target="indirect_comm">indirect communication</xref>,
2985        the OP SHOULD determine that an authorized end user wishes to
2986        complete the authentication. If an authorized end user wishes
2987        to complete the authentication, the OP SHOULD send a <xref
2988        target="positive_assertions">positive assertion</xref> to the
2989        Relying Party.
2990      </t>
2991      -->
2992      <t>
2993        認証リクエストが<xref target="indirect_comm">間接通信</xref>を使ってUser-Agentからくるとき、
2994        OPは認可されたエンドユーザーが認証を完了することを望むか決めさせる「べき」(SHOULD)です。
2995        もし認可されたエンドユーザーが認証を完了することを望むなら、OPは<xref
2996        target="positive_assertions">肯定のアサーション</xref>をRelying Partyに送る「べき」(SHOULD)です。
2997      </t>
2998      <!--
2999      <t>
3000        Methods of identifying authorized end users and obtaining
3001        approval to return an OpenID Authentication assertion are
3002        beyond the scope of this specification. See <xref
3003        target="rp_mitm_proxy"/> for OpenID Provider security
3004        considerations.
3005      </t>
3006      -->
3007      <t>
3008        認可されたエンドユーザーを識別する方法とOpenID認証アサーションを返す事の承認を得る方法は、
3009        この仕様の範囲外です。
3010        OpenID Providerのセキュリティ上の配慮に関しては<xref target="rp_mitm_proxy"/>を参照。
3011      </t>
3012      <!--
3013      <t>
3014        If the relying party requested OP-driven identifier selection
3015        by setting "openid.identity" to
3016        "http://specs.openid.net/auth/2.0/identifier_select"
3017        and there are Identifiers for which the end user is authorized
3018        to issue authentication responses, the OP SHOULD allow the end
3019        user to choose which Identifier to use.
3020      </t>
3021      -->
3022      <t>
3023        もしRelying Partyが"openid.identity"に"http://specs.openid.net/auth/2.0/identifier_select"をセットする事で
3024        OP主導のIdentifierの選択を要求し、認証レスポンスを発行するために認証されたエンドユーザーのIdentifier
3025        が複数あるなら、OPはどのIdentifierを使うかを選ぶ事をエンドユーザーに許可する「べき」(SHOULD)です。
3026      </t>
3027      <!--
3028      <t>
3029        If the Relying Party supplied an association handle with the
3030        authentication request, the OP SHOULD attempt to look up an
3031        association based on that handle. If the association is
3032        missing or expired, the OP SHOULD send the
3033        "openid.invalidate_handle" parameter as part of the response
3034        with the value of the request's "openid.assoc_handle"
3035        parameter, and SHOULD proceed as if no association handle was
3036        specified.
3037      </t>
3038      -->
3039      <t>
3040        もしRelying Partyが認証リクエストで関連付けハンドルを与えたなら、
3041        OPはそのハンドルに基づく関連付けを探す事を試みる「べき」(SHOULD)です。
3042        もし関連付けがないか期限切れなら、OPはレスポンスの一部として
3043        リクエストの"openid.assoc_handle"パラメータの値とともに "openid.invalidate_handle"
3044        パラメータを送る「べき」(SHOULD)で、関連付けハンドルが指定されなかったとして
3045        続行す「べき」(SHOULD)です。
3046      </t>
3047      <!--
3048      <t>
3049        If no association handle is specified, the OP SHOULD use a
3050        private association for signing the response. The OP MUST
3051        store this association and MUST respond to later requests to
3052        check the signature of the response via <xref
3053        target="check_auth">Direct Verification</xref>.
3054      </t>
3055      -->
3056      <t>
3057        もし関連付けハンドルが指定されないなら、OPはレスポンスの署名に関してプライベートな関連付けを使う「べき」(SHOULD)です。
3058        OPはこの関連付けを記憶「しなければならず」(MUST)、<xref target="check_auth">直接検証</xref>を使ってレスポンスの署名を確認する
3059        ための後のリクエストに応答「しなければなりません」(MUST)。
3060      </t>
3061      <!--
3062      <t>
3063        Relying Parties SHOULD accept and verify assertions about
3064        Identifiers for which they have not requested authentication.
3065        OPs SHOULD use private associations for signing unsolicited
3066        positive assertions.
3067      </t>
3068      -->
3069      <t>
3070        Relying Partyは要求していない認証のためのIdentifierに関するアサーションを受け入れて検証す「べき」(SHOULD)です。
3071        OPは勝手な肯定のアサーションを署名する為にプライベートな関連付けを使う「べき」(SHOULD)です。
3072      </t>
3073      <!--
3074      <t>
3075        If the "openid.return_to" value is omitted in the request, the
3076        Relying Party does not wish to receive an authentication
3077        assertion from the OP. This can be useful when using
3078        extensions to transfer data from the Relying Party to the OP.
3079      </t>
3080      -->
3081      <t>
3082        もしリクエストの"openid.return_to"の値が省略されるなら、Relying PartyはOPから認証アサーションを受け取る事を望みません。
3083        これはRelying PartyからOPにデータを転送する為に拡張を使うときに役立ちます。
3084      </t>
3085
3086      <section title="Positive Assertions" anchor="positive_assertions">
3087        <!--
3088        <t>
3089          Positive assertions are <xref target="indirect_comm">
3090          indirect responses</xref> with the following fields:
3091        </t>
3092        -->
3093        <t>
3094          肯定のアサーションは以下のフィールドを持つ<xref target="indirect_comm">間接レスポンス</xref>です:
3095        </t>
3096        <t>
3097          <list style="symbols">
3098            <t>
3099              openid.ns
3100              <list style="empty">
3101                <!--
3102                <t>
3103                  As specified in <xref target="http_encoding"/>.
3104                </t>
3105                -->
3106                <t>
3107                  <xref target="http_encoding"/>で示される通り。
3108                </t>
3109              </list>
3110            </t>
3111
3112            <t>
3113              openid.mode
3114              <list style="empty">
3115                <!--
3116                <t>Value: "id_res"</t>
3117                -->
3118                <t>値: "id_res"</t>
3119              </list>
3120            </t>
3121
3122            <t>
3123              openid.op_endpoint
3124              <list style="empty">
3125                <!--
3126                <t>
3127                  The OP Endpoint URL.
3128                </t>
3129                -->
3130                <t>
3131                  OP Endpoint URL
3132                </t>
3133              </list>
3134            </t>
3135
3136            <t>
3137              openid.claimed_id
3138              <list style="empty">
3139                <!--
3140                <t>
3141                  Value: (optional) The Claimed Identifier.
3142                  "openid.claimed_id" and "openid.identity" SHALL
3143                  be either both present or both absent.
3144                </t>
3145                -->
3146                <t>
3147                  値: (optional) Claimed Identifier。
3148                  "openid.claimed_id"と"openid.identity"は両方が存在するか両方とも存在しないかどちらか「とします」(SHALL)。
3149                </t>
3150                <!--
3151                <t>
3152                  Note: The end user MAY choose to use an OP-Local
3153                  Identifier as a Claimed Identifier.
3154                </t>
3155                -->
3156                <t>
3157                  注: エンドユーザーはClaimed IdentifierとしてOP-Local Identifierを使う事を選ぶ「かもしれません」(MAY)。
3158                </t>
3159                <!--
3160                <t>
3161                  Note: If neither Identifier is present in the assertion,
3162                  it is not about an identifier, and will contain
3163                  other information in its payload, using <xref
3164                  target="extensions">extensions</xref>.
3165                </t>
3166                -->
3167                <t>
3168                  注: もしアサーションにどちらのIdentiierも存在しないなら、それはIdentifierに関するものではなく、<xref
3169                  target="extensions">拡張</xref>を使ってそのペイロードに他の情報を含むでしょう。
3170                </t>
3171              </list>
3172            </t>
3173
3174            <t>
3175              openid.identity
3176              <list style="empty">
3177                <!--
3178                <t>
3179                  Value: (optional) The OP-Local Identifier
3180                </t>
3181                -->
3182                <t>
3183                  値: (optional) OP-Local Identifier
3184                </t>
3185                <!--
3186                <t>
3187                  Note: OpenID Providers MAY assist the end user in
3188                  selecting the Claimed and OP-Local Identifiers about
3189                  which the assertion is made. The openid.identity
3190                  field MAY be omitted if an extension is in use that
3191                  makes the response meaningful without it
3192                  (see openid.claimed_id above).
3193                </t>
3194                -->
3195                <t>
3196                  注: OpenID ProviderはClaimed IdentifierとOP-Local Identifierのどちらでアサーションを作るかの選択でエンドユーザーを補助する「かもしれません」(MAY)。拡張を使って意味あるレスポンスを作る場合(上記のopenid.claimed_idを参照)、openid.identityフィールドは省略される「かもしれません」(MAY)。
3197                </t>
3198              </list>
3199            </t>
3200
3201            <t>
3202              openid.return_to
3203              <list style="empty">
3204                <!--
3205                <t>
3206                  Value: Verbatim copy of the return_to URL parameter
3207                  sent in the request.
3208                </t>
3209                -->
3210                <t>
3211                  値: リクエストで送られたreturn_to URLパラメータの全く同じコピーです。
3212                </t>
3213              </list>
3214            </t>
3215
3216            <t>
3217              openid.response_nonce
3218              <list style="empty">
3219                <!--
3220                <t>
3221                  Value: A string 255 characters or less in length,
3222                  that MUST be unique to this particular successful
3223                  authentication response. The nonce MUST start with the
3224                  current time on the server, and MAY contain additional
3225                  ASCII characters in the range 33-126 inclusive
3226                  (printable non-whitespace characters), as necessary to
3227                  make each response unique. The date and time MUST be
3228                  formatted as specified in section 5.6 of
3229                  <xref target="RFC3339"/>, with the following restrictions:
3230
3231                  <list style="symbols">
3232                    <t>
3233                      All times must be in the UTC
3234                      timezone, indicated with a "Z".
3235                    </t>
3236                    <t>
3237                      No fractional seconds are allowed
3238                    </t>
3239                  </list>
3240
3241                  For example: 2005-05-15T17:11:51ZUNIQUE
3242                </t>
3243                -->
3244                <t>
3245                  値: 255文字以内の文字列で、個々の成功の認証レスポンスに関してユニークで「なければなりません」(MUST)。
3246                  nonceはサーバの現在時刻から始まら「なければならず」(MUST)、それぞれのレスポンスを確実にユニークにするために
3247                  33-126の範囲のASCII文字(印字可能な非空白文字)を含める「かもしれません」。
3248                  日付と時間は以下の制限と<xref target="RFC3339"/>のセクション5.6に示される形式で「なければなりません」(MUST):
3249
3250                  <list style="symbols">
3251                    <t>
3252                      全ての時間は"Z"で示されるUTCタイムゾーンでなければなりません。
3253                    </t>
3254                    <t>
3255                      少数の秒は許可されません。
3256                    </t>
3257                  </list>
3258
3259                  例: 2005-05-15T17:11:51ZUNIQUE
3260                </t>
3261              </list>
3262            </t>
3263
3264            <t>
3265              openid.invalidate_handle
3266              <list style="empty">
3267                <!--
3268                <t>
3269                  Value: (optional) If the Relying Party sent an
3270                  invalid association handle with the request, it
3271                  SHOULD be included here.
3272                </t>
3273                -->
3274                <t>
3275                  値: (optional) もしRelying Partyがリクエストで不正な関連付けハンドルを送ったなら、それはここに含まれる「べきです」(SHOULD)。
3276                </t>
3277              </list>
3278            </t>
3279
3280            <t>
3281              openid.assoc_handle
3282              <list style="empty">
3283                <!--
3284                <t>
3285                  Value: The handle for the association that was used
3286                  to sign this assertion.
3287                </t>
3288                -->
3289                <t>
3290                  値: このアサーションに署名する為に使われた関連付けに関するハンドルです。
3291                </t>
3292              </list>
3293            </t>
3294
3295            <t>
3296              openid.signed
3297              <list style="empty">
3298                <!--
3299                <t>
3300                  Value: Comma-separated list of signed fields.
3301                </t>
3302                -->
3303                <t>
3304                  値: 署名フィールドのカンマ区切りリストです。
3305                </t>
3306                <!--
3307                <t>
3308                  Note: This entry consists of the fields without the
3309                  "openid." prefix that the signature covers. This
3310                  list MUST contain at least "op_endpoint",
3311                  "return_to" "response_nonce" and "assoc_handle", and
3312                  if present in the response, "claimed_id" and
3313                  "identity". Additional keys MAY be signed as part of
3314                  the message. See <xref
3315                  target="generating_signatures">Generating
3316                  Signatures</xref>.
3317                </t>
3318                -->
3319                <t>
3320                  注: このエントリーは署名が含む"openid."接頭辞なしのフィールドから成ります。
3321                  このリストは少なくとも、"op_endpoint", "return_to", "response_nonce", "assoc_handle"を含ま「なければならず」(MUST)、
3322                  レスポンスに存在するなら"claimed_id"と"identity"も含みます。
3323                  追加キーはメッセージの一部として署名される「かもしれません」(MAY)。
3324                  <xref
3325                  target="generating_signatures">署名の生成</xref>を参照。
3326                </t>
3327                <!--
3328                <t>
3329                  For example,
3330                  "op_endpoint,identity,claimed_id,return_to,assoc_handle,response_nonce".
3331                </t>
3332                -->
3333                <t>
3334                  例: "op_endpoint,identity,claimed_id,return_to,assoc_handle,response_nonce"
3335                </t>
3336              </list>
3337            </t>
3338
3339            <t>
3340              openid.sig
3341              <list style="empty">
3342                <!--
3343                <t>
3344                  Value: Base 64 encoded signature calculated as
3345                  specified in <xref target="generating_signatures"/>.
3346                </t>
3347                -->
3348                <t>
3349                  値: <xref target="generating_signatures"/>で示される様に計算した署名をBase 64でエンコードしたものです。
3350                </t>
3351              </list>
3352            </t>
3353
3354          </list>
3355
3356        </t>
3357      </section>
3358
3359      <section title="Negative Assertions" anchor="negative_assertions">
3360        <!--
3361        <t>
3362          If the OP is unable to identify the end user or the end
3363          user does not or cannot approve the authentication request,
3364          the OP SHOULD send a negative assertion to the Relying
3365          Party as an <xref target="indirect_comm">indirect
3366          response</xref>.
3367        </t>
3368        -->
3369        <t>
3370          もしOPがエンドユーザーを識別できないか、エンドユーザーが認証リクエストを承認しないかできないなら、
3371          OPは<xref target="indirect_comm">間接レスポンス</xref>でRelying Partyに否定のアサーションを送る「べき」(SHOULD)です。
3372        </t>
3373
3374        <!--
3375        <t>
3376          When receiving a negative assertion in response to a
3377          "checkid_immediate" mode request, Relying Parties SHOULD
3378          construct a new authentication request using "checkid_setup"
3379          mode. Details about how this differs from OpenID
3380          Authentication 1.1 can be found in <xref
3381          target="compat_mode"/>.
3382        </t>
3383        -->
3384        <t>
3385          "checkid_immediate"モードのリクエストに対するレスポンスで否定のアサーションを受け取るとき、
3386          Relying Partyは"checkid_setup"モードを使った新しい認証リクエストを作る「べき」(SHOULD)です。
3387          OpenID認証1.1からの違いについての詳細は<xref target="compat_mode"/>を参照。
3388        </t>
3389
3390        <section title="In Response to Immediate Requests">
3391          <!--
3392          <t>
3393            If the request was an immediate request, there is no chance
3394            for the end user to interact with pages on the OP to provide
3395            identifying credentials or approval of a request.
3396            A negative assertion of an immediate request takes the
3397            following form:
3398            <list style="symbols">
3399              <t>
3400                openid.ns
3401                <list style="empty">
3402                  <t>
3403                    As specified in <xref target="http_encoding"/>.
3404                  </t>
3405                </list>
3406              </t>
3407              <t>
3408                openid.mode
3409                <list style="empty">
3410                  <t>Value: "setup_needed"</t>
3411                </list>
3412              </t>
3413            </list>
3414          </t>
3415          -->
3416          <t>
3417            もしリクエストが直接的なリクエストだったなら、
3418            クレデンシャルの識別やリクエストの承認のために
3419            OPのページでエンドユーザーと対話する機会はありません。
3420            直接的なリクエストの否定のアサーションは以下の形をとります:
3421            <list style="symbols">
3422              <t>
3423                openid.ns
3424                <list style="empty">
3425                  <t>
3426                    <xref target="http_encoding"/>で示される通り。
3427                  </t>
3428                </list>
3429              </t>
3430              <t>
3431                openid.mode
3432                <list style="empty">
3433                  <t>値: "setup_needed"</t>
3434                </list>
3435              </t>
3436            </list>
3437          </t>
3438        </section>
3439
3440        <section title="In Response to Non-Immediate Requests">
3441          <!--
3442          <t>
3443            Since the OP may display pages to the end user and
3444            request credentials from the end user, a negative response
3445            to a request that is not immediate is definitive. It
3446            takes the following form:
3447
3448            <list style="symbols">
3449              <t>
3450                openid.ns
3451                <list style="empty">
3452                  <t>
3453                    As specified in <xref target="http_encoding"/>.
3454                  </t>
3455                </list>
3456              </t>
3457              <t>
3458                openid.mode
3459                <list style="empty">
3460                  <t>
3461                    Value: "cancel"
3462                  </t>
3463                </list>
3464              </t>
3465            </list>
3466          </t>
3467          -->
3468          <t>
3469            OPがエンドユーザーにページを表示してクレデンシャルをエンドユーザーから要求するまでの間、
3470            直接的でないリクエストに対する否定のレスポンスは最も確実です。
3471            以下の形式をとります:
3472
3473            <list style="symbols">
3474              <t>
3475                openid.ns
3476                <list style="empty">
3477                  <t>
3478                    <xref target="http_encoding"/>で示される通り。
3479                  </t>
3480                </list>
3481              </t>
3482              <t>
3483                openid.mode
3484                <list style="empty">
3485                  <t>
3486                    値: "cancel"
3487                  </t>
3488                </list>
3489              </t>
3490            </list>
3491          </t>
3492
3493          <!--
3494          <t>
3495            Often, if the user does not wish to or cannot complete the
3496            authentication request, the OpenID authentication process
3497            will be aborted and the Relying Party will not get a
3498            cancel mode response (the end user may quit or press the
3499            back button in their User-Agent instead of continuing).
3500            If a RP receives the "cancel" response, authentication was
3501            unsuccessful and the RP MUST treat the end user as
3502            non-authenticated.
3503          </t>
3504          -->
3505          <t>
3506            しばしば、エンドユーザーが認証リクエストの完了を望まないか完了できない場合に、
3507            OpenID認証プロセスは中止されるでしょうし、Relying Partyはキャンセルモードのレスポンスを
3508            取得しないでしょう(エンドユーザーは継続せずに、User-Agentの戻るボタンを押したり終了させたりするかもしれません)。
3509            もしRPが"cancel"レスポンスを受け取るなら認証は失敗で、RPはエンドユーザーを
3510            認証されていないものとして扱わ「なければなりません」(MUST)。
3511          </t>
3512        </section>
3513      </section>
3514    </section>
3515
3516    <section title="Verifying Assertions" anchor="verification">
3517      <!--
3518      <t>
3519        When the Relying Party receives a positive assertion, it MUST
3520        verify the following before accepting the assertion:
3521
3522        <list style="symbols">
3523          <t>
3524            The value of "openid.return_to" matches the URL of the
3525            current request (<xref target="verify_return_to"/>)
3526          </t>
3527          <t>
3528            Discovered information matches the information in the
3529            assertion (<xref target="verify_disco"/>)
3530          </t>
3531          <t>
3532            An assertion has not yet been accepted from this OP with
3533            the same value for "openid.response_nonce" (<xref
3534            target="verify_nonce"/>)
3535          </t>
3536          <t>
3537            The signature on the assertion is valid and all fields
3538            that are required to be signed are signed (<xref
3539            target="verifying_signatures"/>)
3540          </t>
3541        </list>
3542
3543        If all four of these conditions are met, assertion is now
3544        verified. If the assertion contained a Claimed Identifier, the
3545        user is now authenticated with that identifier.
3546      </t>
3547      -->
3548      <t>
3549        Relying Partyが肯定のアサーションを受け取るとき、そのアサーションを受け入れる前に
3550        以下の検証を「しなければなりません」(MUST):
3551
3552        <list style="symbols">
3553          <t>
3554            "openid.return_to"の値が現在のリクエストのURLとマッチする(<xref target="verify_return_to"/>)
3555          </t>
3556          <t>
3557            発見した情報がアサーション内の情報とマッチする(<xref target="verify_disco"/>)
3558          </t>
3559          <t>
3560            同じ値の"openid.response_nonce"についてこのOPからアサーションをまだ受け入れていない(<xref target="verify_nonce"/>)
3561          </t>
3562          <t>
3563            アサーションの署名が有効で署名に必須な全てのフィールドが署名されている(<xref target="verifying_signatures"/>)
3564          </t>
3565        </list>
3566
3567        もしこれら4つの条件全てを満たすなら、アサーションは証明されます。
3568        もし、アサーションがClaimed Identifierを含むなら、そのユーザーはそのIdentifierで認証されます。
3569      </t>
3570
3571      <section title="Verifying the Return URL" anchor="verify_return_to">
3572        <!--
3573        <t>
3574          To verify that the "openid.return_to" URL matches the URL
3575          that is processing this assertion:
3576
3577          <list style="symbols">
3578            <t>
3579              The URL scheme, authority, and path MUST be the same
3580              between the two URLs.
3581            </t>
3582            <t>
3583              Any query parameters that are present in the
3584              "openid.return_to" URL MUST also be present with the
3585              same values in the URL of the HTTP request the RP
3586              received.
3587            </t>
3588          </list>
3589        </t>
3590        -->
3591        <t>
3592          "openid.return_to"のURLがこのアサーションを処理するURLとマッチする事を検証する為に:
3593
3594          <list style="symbols">
3595            <t>
3596              URLのscheme, authority, pathは2つのURLの間で同じで「なければなりません」(MUST)。
3597            </t>
3598            <t>
3599              "openid.return_to"のURLに存在するクエリパラメータはRPが受け取ったHTTPリクエストのURLでも同じ値で存在し「なければなりません」(MUST)。
3600            </t>
3601          </list>
3602        </t>
3603      </section>
3604
3605      <section title="Verifying Discovered Information" anchor="verify_disco">
3606        <!--
3607        <t>
3608          If the Claimed Identifier in the assertion is a URL and
3609          contains a fragment, the fragment part and the fragment
3610          delimiter character "#" MUST NOT be used for the purposes
3611          of verifying the discovered information.
3612        </t>
3613        -->
3614        <t>
3615          もしアサーションのClaimed IdentifierがURLでfragmentを含むなら、fragment部分とデリミタ"#"
3616          は発見した情報を検証する目的のために使われては「なりません」(MUST)。
3617        </t>
3618
3619        <!--
3620        <t>
3621          If the Claimed Identifier is included in the assertion, it
3622          MUST have been <xref target="discovery">discovered</xref> by
3623          the Relying Party and the information in the assertion MUST
3624          be present in the discovered information. The Claimed
3625          Identifier MUST NOT be an OP Identifier.
3626        </t>
3627        -->
3628        <t>
3629          もしアサーションにClaimed Identifierが含まれるなら、それはRelying Partyによって
3630          <xref target="discovery">発見</xref>されて「いなければならず」(MUST)、アサーション
3631          の情報は発見した情報にも含まれて「いなければなりません」(MUST)。
3632          Claimed IdentifierはOP Identifierであっては「なりません」(MUST NOT)。
3633        </t>
3634
3635        <!--
3636        <t>
3637          If the Claimed Identifier was not previously discovered
3638          by the Relying Party (the "openid.identity" in the request
3639          was "http://specs.openid.net/auth/2.0/identifier_select" or
3640          a different Identifier, or if the OP is sending an unsolicited
3641          positive assertion), the Relying Party MUST perform discovery
3642          on the Claimed Identifier in the response to make sure that
3643          the OP is authorized to make assertions about the Claimed
3644          Identifier.
3645        </t>
3646        -->
3647        <t>
3648          もしClaimed IdentifierがRelying Partyによって前もって発見されなかったなら(
3649          リクエストの"openid.identity"が"http://specs.openid.net/auth/2.0/identifier_select"か、
3650          他のIdentifier、もしくはOPが勝手に肯定のアサーションを送った場合)、
3651          Relying PartyはOPがClaimed Identifierに関するアサーションを作る為に認可されている事を確認する為に、
3652          レスポンスのClaimed Identifier上で発見を行わなければ「なりません」(MUST)。
3653        </t>
3654
3655        <!--
3656        <t>
3657          If no Claimed Identifier is present in the response, the
3658          assertion is not about an identifier and the RP MUST NOT use
3659          the User-supplied Identifier associated with the current
3660          OpenID authentication transaction to identify the user.
3661          Extension information in the assertion MAY still be used.
3662        </t>
3663        -->
3664        <t>
3665          もしレスポンスにClaimed Identifierが存在しないなら、
3666          アサーションはIdentifierに関するものでなく、RPは
3667          ユーザーを識別する為に現在のOpenID認証トランザクション
3668          に関連付いたUser-Supplied Identifierを使っては「なりません」(MUST)。
3669        </t>
3670
3671        <texttable title="Discovered Information to Authentication Response Mapping">
3672          <ttcol align="left">Discovered Value</ttcol>
3673          <ttcol align="left">Response Field</ttcol>
3674
3675          <c>Claimed Identifier</c>
3676          <c>openid.claimed_id</c>
3677
3678          <c>OP-Local Identifier</c>
3679          <c>openid.identity</c>
3680
3681          <c>OP Endpoint URL</c>
3682          <c>openid.op_endpoint</c>
3683
3684          <c>Protocol Version</c>
3685          <c>openid.ns</c>
3686          <!--
3687          <postamble>
3688            This table shows the mapping of <xref
3689            target="discovered_info">discovered information</xref>
3690            into fields in the <xref
3691            target="positive_assertions">OpenID Authentication 2.0
3692            "id_res" response</xref>
3693          </postamble>
3694          -->
3695          <postamble>
3696            この表は<xref target="discovered_info">発見した情報</xref>と
3697            <xref target="positive_assertions">OpenID認証2.0の"id_res"レスポンス</xref>
3698            中のフィールドとの対応を表します。
3699          </postamble>
3700        </texttable>
3701
3702        <!--
3703        <t>
3704          If using a discovery mechanism that yields an XRDS document,
3705          the protocol version, OP Endpoint URL and the OP-Local
3706          Identifier (if different than the Claimed Identifier) MUST
3707          be present in one &lt;xrd:Service&gt; element. There MAY be
3708          unused fields in that &lt;xrd:Service&gt; element.
3709        </t>
3710        -->
3711        <t>
3712          もしXRDSドキュメントによるディスカバリーメカニズムを使うなら、
3713          プロトコルバージョン、OP Endpoint URL、OP-Local Identifier
3714          (Claimed Identifierと異なるなら)は&lt;xrd:Service&gt;要素の中に
3715          存在し「なければなりません」(MUST)。
3716        </t>
3717
3718        <figure>
3719          <preamble>Non-normative example:</preamble>
3720          <artwork><![CDATA[<Service xmlns="xri://$xrd*($v*2.0)">
3721  <Type>http://specs.openid.net/auth/2.0/signon</Type>
3722  <URI>http://provider.example.com/openid</URI>
3723  <URI>https://provider.example.com/openid</URI>
3724</Service>]]></artwork>
3725          <!--
3726          <postamble>
3727            In this example XRDS snippet, the &lt;xrd:Service&gt;
3728            element has two &lt;xrd:URI&gt; elements, which map to OP
3729            Endpoint URLs as per <xref target="discovered_info"/>. If
3730            an assertion has either value for "openid.op_endpoint",
3731            then that field matches this &lt;xrd:Service&gt;
3732            element. The other &lt;xrd:URI&gt; element is unused.
3733          </postamble>
3734          -->
3735          <postamble>
3736            この例で、&lt;xrd:Service&gt;要素は、<xref target="discovered_info"/>で示された
3737            OP Endpoint URLに対応する2つの&lt;xrd:URI&gt;要素を持ちます。
3738            もしアサーションが"openid.op_endpoint"についてどちらかの値を持つなら、
3739            そのフィールドはこの&lt;xrd:Service&gt;要素とマッチします。
3740            他の&lt;xrd:URI&gt;要素は使われません。
3741          </postamble>
3742        </figure>
3743
3744      </section>
3745
3746      <section title="Checking the Nonce" anchor="verify_nonce">
3747        <!--
3748        <t>
3749          To prevent replay attacks, the agent checking the signature
3750          keeps track of the nonce values included in positive
3751          assertions and never accepts the same value more than once
3752          for the same OP Endpoint URL.
3753        </t>
3754        -->
3755        <t>
3756          リプレイ攻撃を防ぐ為に、署名を確認するエージェントは肯定のアサーションに含まれるnonce値を覚えておき、
3757          同じOP Endpoint URLに関して同じ値を決して受け入れません。
3758        </t>
3759        <t>
3760          <list style="symbols">
3761            <!--
3762            <t>
3763              When using "check_authentication", the OP MUST NOT issue
3764              more than one successful response to a request with the
3765              same value for "openid.response_nonce".
3766            </t>
3767            -->
3768            <t>
3769              "check_authentication"を使うとき、OPはリクエストに対して"openid.response_nonce"について同じ値で
3770              成功のレスポンスを1度以上発行しては「なりません」(MUST NOT)。
3771            </t>
3772            <!--
3773            <t>
3774              When the Relying Party checks the signature on an
3775              assertion, the Relying Party SHOULD ensure that an
3776              assertion has not yet been accepted with the same value
3777              for "openid.response_nonce" from the same OP Endpoint
3778              URL.
3779            </t>
3780            -->
3781            <t>
3782              Relying Partyがアサーションの署名を確認するとき、Relying Partyはアサーションが
3783              同じOP Endpoint URLから同じ値の"openid.response_nonce"によってまだ受け入れられてない事を保証す「べき」(SHOULD)です。
3784            </t>
3785          </list>
3786        </t>
3787        <!--
3788        <t>
3789          The time-stamp MAY be used to reject responses that are too
3790          far away from the current time, limiting the amount of time
3791          that nonces must be stored to prevent attacks. The
3792          acceptable range is out of the scope of this
3793          specification. A larger range requires storing more nonces
3794          for a longer time. A shorter range increases the chance that
3795          clock-skew and transaction time will cause a spurious
3796          rejection.
3797        </t>
3798        -->
3799        <t>
3800          タイムスタンプは現在の時間から遠すぎるレスポンスを拒否するために使われる「かも」(MAY)しれず、
3801          nonceの制限時間は攻撃を防ぐ為に記憶されなければなりません。
3802          受付可能な範囲はこの仕様の範囲外です。
3803          より大きな範囲はたくさんのnonceを長時間記憶する事を必要とします。
3804          より短い範囲は時計のずれとトランザクションの時間が引き起こすだろう疑似的な拒否の機会を増大します。
3805        </t>
3806      </section>
3807
3808      <section title="Verifying Signatures"
3809               anchor="verifying_signatures">
3810        <!--
3811        <t>
3812          If the Relying Party has stored an association with the
3813          association handle specified in the assertion, it MUST check
3814          the signature on the assertion itself. If it does not have
3815          an association stored, it MUST request that the OP verify
3816          the signature via <xref target="check_auth">Direct
3817          Verification</xref>.
3818        </t>
3819        -->
3820        <t>
3821          もしRelying Partyがアサーションの関連付けハンドルで示された関連付けを記憶しているなら、
3822          自身でアサーションの署名を確認し「なければなりません」(MUST)。
3823          もし関連付けを記憶していないなら、OPに<xref target="check_auth">直接検証</xref>を使った署名の確認を要求し「なければなりません」(MUST)。
3824        </t>
3825
3826        <section title="Verifying with an Association" toc="exclude">
3827          <!--
3828          <t>
3829            The Relying Party follows the same procedure that the
3830            OP followed in <xref target="generating_signatures">
3831            generating the signature</xref>, and then compares the
3832            signature in the response to the signature it
3833            generated. If the signatures do not match, the assertion
3834            is invalid.
3835          </t>
3836          -->
3837          <t>
3838            Relying PartyはOPが従った<xref target="generating_signatures">署名の生成</xref>と同じ手順に従い、
3839            レスポンスの署名と生成した署名とを比較します。
3840            もし署名がマッチしないなら、アサーションは不正です。
3841          </t>
3842
3843          <!--
3844          <t>
3845            If an authentication request included an association
3846            handle for an association between the OP and the Relying
3847            party, and the OP no longer wishes to use that handle
3848            (because it has expired or the secret has been
3849            compromised, for instance), the OP will send a response
3850            that must be verified directly with the OP, as specified
3851            in <xref target="check_auth"/>. In that instance, the OP
3852            will include the field "openid.invalidate_handle" set to
3853            the association handle that the Relying Party included
3854            with the original request.
3855          </t>
3856          -->
3857          <t>
3858            もし認証リクエストがOPとRelying Partyの間の関連付けに関する関連付けハンドルを含み、
3859            OPがすでにそのハンドルの利用を望まないなら(例えば、有効期限切れや秘密鍵が脆弱であるため)、
3860            OPは<xref target="check_auth"/>で示される様にOPによって直接検証されなければならないレスポンスを送るでしょう。
3861            この場合、OPは"openid.invalidate_handle"にRelying Partyがオリジナルのリクエストに含めた関連付けハンドルをセットした
3862            フィールドを含めるでしょう。
3863          </t>
3864        </section>
3865
3866        <section title="Verifying Directly with the OpenID Provider"
3867                 toc="exclude" anchor="check_auth">
3868          <!--
3869          <t>
3870            To have the signature verification performed by the OP,
3871            the Relying Party sends a <xref target="direct_request">
3872            direct request</xref> to the OP. To verify the signature,
3873            the OP uses a private association that was generated when
3874            it issued the <xref target="positive_assertions">
3875            positive assertion</xref>.
3876          </t>
3877          -->
3878          <t>
3879            OPによって行われる署名の検証を得る為に、Relying PartyはOPに<xref target="direct_request">
3880            直接リクエスト</xref>を送ります。
3881            署名を検証する為に、OPは<xref target="positive_assertions">肯定のアサーション</xref>を発行するときに
3882            生成されたプライベートな関連付けを使います。
3883          </t>
3884
3885          <section title="Request Parameters" toc="exclude">
3886            <t>
3887              <list style="symbols">
3888                <t>
3889                  openid.mode
3890                  <list style="empty">
3891                    <!--
3892                    <t>Value: "check_authentication"</t>
3893                    -->
3894                    <t>値: "check_authentication"</t>
3895                  </list>
3896                </t>
3897
3898                <!--
3899                <t>
3900                  Exact copies of all fields from the authentication
3901                  response, except for "openid.mode".
3902                </t>
3903                -->
3904                <t>
3905                  認証レスポンスの"openid.mode"を除いた全てのフィールドの完全なコピー。
3906                </t>
3907              </list>
3908            </t>
3909
3910            <!--
3911            <t>
3912              For verifying signatures an OP MUST only use private
3913              associations and MUST NOT use associations that have
3914              shared keys. If the verification request contains a
3915              handle for a shared association, it means the Relying
3916              Party no longer knows the shared secret, or an entity
3917              other than the RP (e.g. an attacker) has established
3918              this association with the OP.
3919            </t>
3920            -->
3921            <t>
3922              署名を検証する為に、OPはプライベートな関連付けのみを使わ「なければならず」(MUST)、
3923              共有秘密鍵による関連付けを使っては「なりません」(MUST NOT)。
3924              もし検証リクエストが共有した関連付けに関するハンドラを含むなら、
3925              Relying Partyがすでに共有秘密鍵を知らないか、別のRP(例えば攻撃者)がOPとの関連付けを確立しています。
3926            </t>
3927
3928            <!--
3929            <t>
3930              To prevent replay attacks, the OP MUST NOT issue more
3931              than one verification response for each authentication
3932              response it had previously issued. An authentication
3933              response and its matching verification request may
3934              be identified by their "openid.response_nonce" values.
3935            </t>
3936            -->
3937            <t>
3938              リプレイ攻撃を防ぐ為に、OPは前に発行されているそれぞれの認証レスポンスについて
3939              1つ以上の検証レスポンスを発行しては「なりません」(MUST NOT)。
3940              認証レスポンスとそれに対応する検証レスポンスはそれらの"openid.response_nonce"の値によって
3941              識別されるかもしれません。
3942            </t>
3943
3944          </section>
3945
3946          <section title="Response Parameters" toc="exclude">
3947            <t>
3948              <list style="symbols">
3949                <t>
3950                  ns
3951                  <list style="empty">
3952                    <!--
3953                    <t>
3954                      As specified in <xref target="direct_response"/>.
3955                    </t>
3956                    -->
3957                    <t>
3958                      <xref target="direct_response"/>に示される通り。
3959                    </t>
3960                  </list>
3961                </t>
3962
3963                <t>
3964                  is_valid
3965                  <list style="empty">
3966                    <!--
3967                    <t>
3968                      Value: "true" or "false"; asserts whether the
3969                      signature of the verification request is valid.
3970                    </t>
3971                    -->
3972                    <t>
3973                      値: "true"か"false"; 署名の検証リクエストが有効かどうかの主張。
3974                    </t>
3975                  </list>
3976                </t>
3977
3978                <t>
3979                  invalidate_handle
3980                  <list style="empty">
3981                    <!--
3982                    <t>
3983                      Value: (optional) The "invalidate_handle" value
3984                      sent in the verification request, if the OP confirms
3985                      it is invalid.
3986                    </t>
3987                    -->
3988                    <t>
3989                      値: (optional) OPが不正とした場合の、検証リクエストで送られた"invalidate_handle"の値
3990                    </t>
3991                    <!--
3992                    <t>
3993                      Description: If present in a verification response
3994                      with "is_valid" set to "true", the Relying Party
3995                      SHOULD remove the corresponding association from its
3996                      store and SHOULD NOT send further authentication
3997                      requests with this handle.
3998                    </t>
3999                    -->
4000                    <t>
4001                      概要: もし検証レスポンスに"true"がセットされた"is_valid"が存在するなら、
4002                      Relying Partyは対応するアサーションを記憶から削除す「べき」(SHOULD)で、
4003                      このハンドルで更なる認証リクエストを送る「べきではありません」(SHOULD)。
4004                    </t>
4005                    <!--
4006                    <t>
4007                      Note: This two-step process for invalidating
4008                      associations is necessary to prevent an attacker
4009                      from invalidating an association at will by adding
4010                      "invalidate_handle" parameters to an authentication
4011                      response.
4012                    </t>
4013                    -->
4014                    <t>
4015                      注意: この不正なアサーションに関する2ステップのプロセスは、
4016                      認証レスポンスに"invalidate_handle"パラメータを追加する事による
4017                      不正な関連付けからの攻撃者を予防する為に必須です。
4018                    </t>
4019                  </list>
4020                </t>
4021              </list>
4022            </t>
4023          </section>
4024        </section>
4025      </section>
4026
4027      <section title="Identifying the end user" anchor="identifying">
4028        <!--
4029        <t>
4030          The Claimed Identifier in a successful authentication
4031          response SHOULD be used by the Relying Party as a key for
4032          local storage of information about the user. The Claimed
4033          Identifier MAY be used as a user-visible Identifier. When
4034          displaying URL Identifiers, the fragment MAY be omitted.
4035        </t>
4036        -->
4037        <t>
4038          成功の認証レスポンスのClaimed Identifierはユーザーに関する情報のローカルストレージのキーとして
4039          Relying Partyに使われる「べき」(SHOULD)です。
4040          Claimed Identifierはユーザーに見えるIdentifierとして使われる「かも」(MAY)しれません。
4041          URL Identifierを表示する際、fragmentは省略される「かも」(MAY)しれません。
4042        </t>
4043
4044        <section title="Identifier Recycling" anchor="identifier_recycling">
4045          <!--
4046          <t>
4047            OpenID Providers with large user bases can use fragments
4048            to recycle URL Identifiers if it is so desired. When
4049            reassigning a URL Identifier to a new end user OPs should
4050            generate a new, unique fragment part.
4051          </t>
4052          -->
4053          <t>
4054            巨大なユーザーベースを持ったOpenID Providerは、そう望むならURL Identifierを再利用するために
4055            fragmentを使う事が出来ます。
4056            新しいユーザーの為にURL Identifierを再び割り当てるとき、OPは新しいユニークなfragment部分を
4057            生成す「べき」(SHOULD)です。
4058          </t>
4059          <!--
4060          <t>
4061            The full URL with the fragment part constitutes the Claimed
4062            Identifier in positive assertions, therefore Relying Parties
4063            will distinguish between the current and previous owners of
4064            the fragment-less URL.
4065          </t>
4066          -->
4067          <t>
4068            fragment部分を持つ完全なURLは肯定のアサーションのClaimed Identifierを構成するため、
4069            Relying Partyは現在と前のfragmentなしURLの持ち主を見分けるでしょう。
4070          </t>
4071          <!--
4072          <t>
4073            This mechanism allows the (presumably short, memorable)
4074            recycled URL Identifiers without the fragment to be used by
4075            end users at login time and by Relying Parties for display
4076            purposes.
4077          </t>
4078          -->
4079          <t>
4080            このメカニズムはfragmentなしの再利用したURL Identifierをエンドユーザーがログインする時と
4081            Relying Partyが表示目的に使う事を可能にします。
4082          </t>
4083        </section>
4084
4085        <section title="HTTP and HTTPS URL Identifiers" anchor="http_s_identifiers">
4086          <!--
4087          <t>
4088            Relying Parties MUST differentiate between URL Identifiers
4089            that have different schemes. When end user input is
4090            processed into a URL, it is processed into a HTTP URL. If
4091            the same end user controls the same URL, differing only by
4092            scheme, and it is desired that the Identifier be the HTTPS
4093            URL, it is RECOMMENDED that a redirect be issued from the
4094            HTTP URL to the HTTPS URL. Because the HTTP and HTTPS URLs
4095            are not equivalent and the Identifier that is used is the
4096            URL after following redirects, there is no foreseen
4097            reduction in security when using this scheme. If an
4098            attacker could gain control of the HTTP URL, it would have
4099            no effect on the HTTPS URL, since the HTTP URL is not ever
4100            used as an Identifier except to initiate the discovery
4101            process.
4102          </t>
4103          -->
4104          <t>
4105            Relying Partyはschemeが異なるURL Identifierを区別し「なければなりません」(MUST)。
4106            エンドユーザーの入力がURLについて処理されるとき、HTTPのURLについて処理されます。
4107            もし同じエンドユーザーがschemeだけが異なる同じURLを管理していて、IdentifierがHTTPSのURLであると望まれたなら、
4108            HTTPのURLからHTTPSのURLへのリダイレクトを発行する事が「推奨」(RECOMMENDED)されています。
4109            なぜなら、HTTPとHTTPSのURLは等価でなく使われたIdentifierはリダイレクトに従った後のURLだからで、
4110            このschemeを使うときに安全性の減衰は見られません。
4111            もし攻撃者がHTTPのURLの管理を得られたとしても、HTTPのURLはディスカバリープロセスを始めるときを除いて
4112            Identifierとして使われる事は決してないので、HTTPSのURLについて影響がありません。
4113          </t>
4114        </section>
4115      </section>
4116    </section>
4117
4118    <section title="Extensions" anchor="extensions">
4119      <t>
4120        An Extension to OpenID Authentication is a protocol that
4121        "piggybacks" on the authentication request and response. Extensions
4122        are useful for providing extra information about an
4123        authentication request or response as well as providing extra
4124        information about the subject of the authentication response.
4125      </t>
4126
4127      <t>
4128        OpenID extensions are identified by a Type URI. The Type URI
4129        MAY be used as the value of an &lt;xrd:Type&gt; element of an
4130        OpenID &lt;xrd:Service&gt; element in an XRDS document
4131        associated with a Claimed Identifier. The Type URI is also
4132        used to associate key-value pairs in messages with the extension.
4133      </t>
4134
4135      <t>
4136        <!-- XXX: openid. only for indirect messages -->
4137        To associate keys and values in a message with an extension,
4138        the key MUST be associated with the Type URI. To associate
4139        keys with a Type URI, establish an alias by adding a key
4140        prefixed with "openid.ns." and ending with the alias text
4141        whose value is the Type URI. Once an alias has been
4142        established, all pairs in the message whose keys start with
4143        "openid." followed by the alias text, followed by a period or
4144        the end of the key are associated with that extension.
4145        This mechanism is similar to the XML namespaces.
4146      </t>
4147
4148      <t>
4149        A namespace alias MUST NOT contain a period and MUST NOT be
4150        the same as another namespace alias in the same message. A
4151        namespace alias also MUST NOT be in the following list of
4152        disallowed aliases:
4153
4154        <list style="symbols">
4155          <t>assoc_handle</t>
4156          <t>assoc_type</t>
4157          <t>claimed_id</t>
4158          <t>contact</t>
4159          <t>delegate</t>
4160          <t>dh_consumer_public</t>
4161          <t>dh_gen</t>
4162          <t>dh_modulus</t>
4163          <t>error</t>
4164          <t>identity</t>
4165          <t>invalidate_handle</t>
4166          <t>mode</t>
4167          <t>ns</t>
4168          <t>op_endpoint</t>
4169          <t>openid</t>
4170          <t>realm</t>
4171          <t>reference</t>
4172          <t>response_nonce</t>
4173          <t>return_to</t>
4174          <t>server</t>
4175          <t>session_type</t>
4176          <t>sig</t>
4177          <t>signed</t>
4178          <t>trust_root</t>
4179        </list>
4180
4181        A namespace MUST NOT be assigned more than one alias in the
4182        same message. If a message is a response to another message,
4183        the response MAY use a different alias to refer to the same
4184        namespace.
4185      </t>
4186
4187      <t>Non-normative example:</t>
4188      <t>An extension's type URI is
4189      "&lt;http://example.com/ext/1.0&gt;".
4190
4191      <list style="empty">
4192        <t>openid.ns.x=http://example.com/ext/1.0</t>
4193        <t>openid.x=example</t>
4194        <t>openid.x.foo=bar</t>
4195        <t>openid.xx=notx</t>
4196      </list>
4197
4198      In this example, the keys "openid.x" and "openid.x.foo" are
4199      associated with the extension; the "openid.xx" key is not.
4200      </t>
4201
4202      <t>
4203        Extensions MUST NOT define multiple parameters with the same name.
4204        Extensions that need to send multiple values for the same parameter
4205        name must define their own conventions for doing so.
4206      </t>
4207    </section>
4208
4209    <section title="Discovering OpenID Relying Parties" anchor="rp_discovery">
4210      <t>
4211        Relying Party discovery allows for software agents to discover
4212        sites that support OpenID. It also allows OpenID providers to
4213        automatically verify that a return_to URL in an OpenID request
4214        is an OpenID relying party endpoint for the specified realm.
4215      </t>
4216
4217      <t>
4218        Relying Parties SHOULD use the Yadis protocol to publish their
4219        valid return_to URLs. The relying party MAY publish this
4220        information at any URL, and SHOULD publish it under the realm
4221        so that providers can verify return_to URLs.
4222      </t>
4223
4224      <t>
4225        A Relying Party discovery XRDS document MUST contain one or more
4226        &lt;xrd:Service&gt; elements:
4227
4228        <list style="symbols">
4229          <t>
4230            Containing at least one &lt;xrd:URI&gt; element.
4231          </t>
4232          <t>
4233            Where all &lt;xrd:URI&gt; tags contain a URL that accepts
4234            OpenID 2.0 Authentication responses.
4235          </t>
4236          <t>
4237            Containing a &lt;xrd:Type&gt; tag whose content is
4238            "http://specs.openid.net/auth/2.0/return_to".
4239          </t>
4240        </list>
4241      </t>
4242
4243      <figure>
4244        <preamble>Non-normative example:</preamble>
4245        <artwork><![CDATA[<Service xmlns="xri://$xrd*($v*2.0)">
4246  <Type>http://specs.openid.net/auth/2.0/return_to</Type>
4247  <URI>http://consumer.example.com/return</URI>
4248</Service>]]></artwork>
4249      </figure>
4250    </section>
4251
4252    <section title="OpenID Authentication 1.1 Compatibility"
4253             anchor="compat_mode">
4254
4255      <t>
4256        This section describes how to interact with OpenID
4257        Authentication 1.1 Relying Parties and OPs. OpenID
4258        Authentication 2.0 implementations SHOULD support OpenID
4259        Authentication 1.1 compatibility, unless security
4260        considerations make it undesirable.
4261      </t>
4262
4263      <section title="Changes from OpenID Authentication 1.1">
4264        <t>
4265          (non-normative)
4266        </t>
4267        <t>
4268          This specification is based on the original specification for
4269          OpenID Authentication as written by Brad Fitzpatrick. That
4270          specification did not have a version number, but was called
4271          OpenID 1.0, and then OpenID 1.1 when it was revised. The
4272          protocol outlined in this specification is intended to be
4273          backwards-compatible with the revised OpenID protocol. The
4274          changes to the specification are outlined in this section.
4275        </t>
4276
4277        <section title="Updated Initiation and Discovery">
4278          <t>
4279            <list style="symbols">
4280              <t>
4281                Supports OP Identifiers. This new variation of the
4282                protocol flow is initiated by an end user entering an OP
4283                Identifier instead of their own Identifier. This allows
4284                the OP to assist the end user in selecting an
4285                Identifier.
4286              </t>
4287              <t>
4288                Supports the use of XRIs as Identifiers. XRIs may be
4289                used as Identifiers for both end users and OPs, and
4290                provide automatic mapping from one or more reassignable
4291                i-names to a synonymous persistent Canonical ID that
4292                will never be reassigned.
4293              </t>
4294              <t>
4295                When URLs are used as Identifiers, they are normalized
4296                according to the guidelines in <xref target="RFC3986"/>,
4297                for better compatibility with the existing Web infrastructure.
4298              </t>
4299              <t>
4300                Uses the Yadis protocol for discovery. This allows for
4301                using multiple OPs for a single Identifier, for
4302                load-balancing and fallback in the case of OP
4303                failure. Additionally, it allows for discovery of
4304                supported extensions and other associated services.
4305              </t>
4306            </list>
4307          </t>
4308        </section>
4309
4310        <section title="Security improvements">
4311          <t>
4312            A nonce is now part of the protocol for built-in protection
4313            against replay attacks, which was previously implemented
4314            out-of-band by each library or application.
4315          </t>
4316          <t>
4317            A new association type, HMAC-SHA256, and a new association
4318            session type, DH-SHA256, allow for stronger signatures on
4319            authentication assertions.
4320          </t>
4321          <t>
4322            An actual <xref target="security_considerations">Security
4323            Considerations section</xref> which looks at protecting
4324            the protocol from end-to-end.
4325          </t>
4326        </section>
4327
4328        <section title="Extensions">
4329          <t>
4330            Extensions are now an officially supported mechanism to
4331            support data exchange and other Relying Party-OP
4332            communication along with the authentication
4333            exchange. Extensions allow for the exchange of arbitrary
4334            attributes, as well as for protocol extensions,
4335            such as the inclusion of additional information about the
4336            Relying Party in the authentication request.
4337          </t>
4338          <t>
4339            Because extensions can transfer arbitrary data, the
4340            Identifier is now optional in authentication messages.
4341          </t>
4342        </section>
4343      </section>
4344
4345      <section title="Implementing OpenID Authentication 1.1 Compatibility">
4346        <t>
4347          All messages in OpenID Authentication 1.1 omit the
4348          "openid.ns" parameter, which is an easy way for an RP to
4349          determine if the message is from an OpenID Authentication
4350          1.1 endpoint. OpenID Authentication 1.1 supports only
4351          HMAC-SHA1 associations.
4352        </t>
4353
4354        <t>
4355          Error responses in OpenID Authentication 1.1 did not define
4356          "contact" or "reference". OpenID Authentication 1.1 did
4357          allow for the addition of extra fields in error
4358          responses. It is RECOMMENDED for contact and reference to be
4359          sent even when using OpenID Authentication 1.1, since they
4360          may be useful for debugging and do not affect compatibility.
4361        </t>
4362
4363        <section title="Relying Parties">
4364          <t>
4365            <list style="symbols">
4366              <t>
4367                When HTML discovery is performed, the OP endpoint URL
4368                is marked by the link relationship "openid.server"
4369                rather than "openid2.provider". The end user's
4370                OP-Local Identifier is marked by the link relationship
4371                "openid.delegate" rather than "openid2.local_id". The
4372                protocol version is in this case
4373                "http://openid.net/signon/1.1". HTML allows multiple
4374                link relationships to be specified for a single link,
4375                so if an OP provides both OpenID Authentication 1.1
4376                and OpenID Authentication 2.0, "openid2.provider" and
4377                "openid.server" may appear in the same "rel"
4378                attribute.
4379              </t>
4380
4381              <t>
4382                When XRDS-based discovery is performed, the end user's
4383                OP-Local Identifier appears in the
4384                &lt;openid:Delegate&gt; tag of the OpenID
4385                &lt;xrd:Service&gt; element rather than in the
4386                &lt;xrd:LocalID&gt; tag. In order to support
4387                currently-deployed discovery code, both tags MAY
4388                appear in the &lt;xrd:Service&gt; element.
4389              </t>
4390
4391              <t>
4392                Relying Parties SHOULD extract and use OpenID
4393                Authentication 1.x service elements from XRDS
4394                documents, if Yadis succeeds on an URL
4395                Identifier. Such service elements are identified by
4396                &lt;xrd:Type&gt; tags whose text contents are
4397                "http://openid.net/server/1.0" or
4398                "http://openid.net/server/1.1". Although this is not
4399                specified in the previous version of the protocol, it
4400                is a generally accepted practice of advertising OpenID
4401                Authentication 1.x services through Yadis.
4402              </t>
4403
4404              <t>
4405                "openid.claimed_id" is not defined by OpenID
4406                Authentication 1.1. Relying Parties MAY send the value
4407                when making requests, but MUST NOT depend on the value
4408                being present in authentication responses. When the
4409                OP-Local Identifier ("openid.identity") is
4410                different from the Claimed Identifier, the Relying
4411                Party MUST keep track of what Claimed Identifier was
4412                used to discover the OP-Local Identifier, for
4413                example by keeping it in session state. Although the
4414                Claimed Identifier will not be present in the
4415                response, it MUST be used as the identifier for the
4416                user.
4417              </t>
4418
4419              <t>
4420                "openid.identity" MUST be sent in a <xref
4421                target="responding_to_authentication">authentication
4422                request</xref>.
4423              </t>
4424
4425              <t>
4426                Relying Parties MUST send a blank session_type parameter
4427                in "no-encryption" association requests.
4428              </t>
4429
4430              <t>
4431                In OpenID Authentication 1.1, the "no-encryption"
4432                association session type is represented by a blank or
4433                missing "openid.session_type" parameter. Relying
4434                Parties MUST NOT send requests with
4435                "openid.session_type" set to "no-encryption".
4436              </t>
4437
4438              <t>
4439                In <xref
4440                target="requesting_authentication">authentication
4441                requests</xref>, the "openid.identity" parameter
4442                SHOULD NOT be the special value
4443                "http://specs.openid.net/auth/2.0/identifier_select",
4444                because OpenID Authentication 1.1 does not support the
4445                use of OP Identifiers.
4446              </t>
4447
4448              <t>
4449                The "openid.realm" parameter in authentication requests
4450                was known as "openid.trust_root". The syntax and meaning
4451                are identical.
4452              </t>
4453
4454              <t>
4455                When responding with a negative assertion to a
4456                "checkid_immediate" mode authentication request, the
4457                "user_setup_url" parameter MUST be returned. This is a
4458                URL that the end user may visit to complete the
4459                request. The OP MAY redirect the end user to
4460                this URL, or provide the end user with a link that
4461                points to this URL.
4462              </t>
4463
4464              <t>
4465                The Relying Party MUST accept an <xref
4466                target="positive_assertions">authentication
4467                response</xref> that is missing the
4468                "openid.response_nonce" parameter. It SHOULD
4469                implement a method for preventing replay attacks.
4470              </t>
4471
4472              <t>
4473                Relying Parties MUST accept
4474                <xref target="positive_assertions">authentication responses
4475                </xref> that are missing the "openid.op_endpoint" parameter.
4476              </t>
4477            </list>
4478          </t>
4479        </section>
4480
4481        <section title="OpenID Providers">
4482          <t>
4483            <list style="symbols">
4484              <t>
4485                "openid.identity" MUST be sent in a <xref
4486                target="positive_assertions">positive authentication
4487                assertion</xref>.
4488              </t>
4489
4490              <t>
4491                In OpenID Authentication 1.1, the "no-encryption"
4492                association session type is represented by a blank or
4493                missing "openid.session_type" parameter. OPs MUST NOT
4494                send responses with "openid.session_type" set to
4495                "no-encryption".
4496              </t>
4497
4498              <t>
4499                OPs MAY choose to return a successful "no-encryption"
4500                response to any association request. As above, the
4501                "openid.session_type" parameter MUST be blank or
4502                omitted from the response.
4503              </t>
4504
4505              <t>
4506                OPs MUST accept association requests with no assoc_type
4507                parameter, and assume them to be of type HMAC-SHA1.
4508              </t>
4509
4510              <t>
4511                Unsuccessful association attempts MAY be responded with
4512                direct error messages or with "no-encryption" positive
4513                association responses.
4514              </t>
4515
4516              <t>
4517                The "openid.realm" parameter in authentication requests
4518                was known as "openid.trust_root". The syntax and meaning
4519                are identical.
4520              </t>
4521
4522              <t>
4523                When responding with a negative assertion to a
4524                "checkid_immediate" mode authentication request, the
4525                "user_setup_url" parameter MUST be returned. This is a URL
4526                that the end user may visit to complete the request. The
4527                Relying Party may redirect the end user to this URL, or
4528                provide the end user with a link that points to this
4529                URL.
4530              </t>
4531
4532              <t>
4533                OPs MUST NOT send the "openid.op_endpoint" parameter in
4534                <xref target="positive_assertions">authentication responses
4535                </xref>, since it is not part of the OpenID Authentication
4536                1.1 protocol.
4537              </t>
4538            </list>
4539          </t>
4540        </section>
4541      </section>
4542    </section>
4543
4544    <section title="Security Considerations - セキュリティ上の問題" anchor="security_considerations">
4545      <section title="Preventing Attacks - 攻撃を防ぐ方法">
4546        <section title="Eavesdropping Attacks - 盗聴攻撃"
4547                 anchor="preventing_eavesdropping">
4548          <!--
4549              <t>
4550              There is one place in this protocol that is vulnerable
4551              to eavesdropping attacks.
4552              <list style="symbols">
4553              <t>
4554              If the nonce were not checked, an eavesdropper could also
4555              intercept a successful authentication assertion and re-use it.
4556              </t>
4557              </list>
4558              </t>
4559          -->
4560
4561          <t>
4562            このプロトコルには盗聴攻撃を受けやすい場所が一ヵ所あります。
4563            <list style="symbols">
4564              <t>
4565                もしチェックしておかないならば、盗聴者は成功した認証情報を
4566                横取りして、それを再利用します。
4567              </t>
4568            </list>
4569          </t>
4570
4571          <!--
4572              <t>
4573              This attack can be prevented by using transport layer encryption
4574              for these connections to prevent eavesdropping. In addition,
4575              if not using TLS this attack can still be prevented by
4576              checking the nonce while performing message verification.
4577              When doing so, the positive authentication assertion cannot
4578              be re-used.
4579              </t>
4580          -->
4581
4582          <t>
4583            これらの接続の盗聴されないようにTLSでトランスポート層を暗号化
4584            すれば、この攻撃を防ぐことができます。
4585            TLSによって暗号化しない場合は、メッセージ検証をその都度行う
4586            ことで盗聴攻撃を防ぐことができます。ただし、その場合は
4587            positive authentication assertionを再利用することはできません。
4588          </t>
4589
4590        </section>
4591
4592        <section title="Man-in-the-Middle Attacks">
4593          <t>
4594            Associations prevent tampering of signed fields by a man
4595            in the middle except during discovery, association
4596            sessions and <xref target="check_auth">Direct
4597            Verification</xref>. Altering signed fields without the
4598            shared secret requires breaking the MAC. Currently no
4599            tractable attack is known on the MACs used in this
4600            protocol. The quality of the protection provided by the
4601            MAC depends on the randomness of the shared MAC key, so it
4602            is important that an unguessable value be used.
4603          </t>
4604
4605          <t>
4606            If DNS resolution or the transport layer is compromised
4607            signatures on messages are not adequate, since the
4608            attacker can impersonate the OP and issue its own
4609            associations, or its own decisions in Stateless Mode. If
4610            an attacker can tamper with the discovery process they can
4611            specify any OP, and so does not have to impersonate the
4612            OP. Additionally, if an attacker can compromise the
4613            integrity of the information returned during the discovery
4614            process, by altering the XRDS document, the need for a man
4615            in the middle is removed. One method to prevent this sort
4616            of attack is by digitally signing the XRDS file as per
4617            <xref target="RFC3275">XMLDSIG</xref>. The keying material
4618            is not specified, since the RP ultimately needs to make
4619            its own decision whether to trust keys used for such
4620            signature.
4621          </t>
4622
4623          <t>
4624            Using SSL with certificates signed by a trusted authority
4625            prevents these kinds of attacks by verifying the results
4626            of the DNS look-up against the certificate. Once the
4627            validity of the certificate has been established,
4628            tampering is not possible. Impersonating an SSL server
4629            requires forging or stealing a certificate, which is
4630            significantly harder than the network based attacks.
4631          </t>
4632
4633          <t>
4634            In order to get protection from SSL, SSL must be used for
4635            all parts of the interaction, including interaction with
4636            the end user through the User-Agent. While the protocol
4637            does not require SSL be used, its use is strongly
4638            RECOMMENDED. Current best practices dictate that an OP
4639            SHOULD use SSL, with a certificate signed by a trusted
4640            authority, to secure its Endpoint URL as well as the
4641            interactions with the end user's User-Agent. In addition,
4642            SSL, with a certificate signed by a trusted authority,
4643            SHOULD be used so that a Relying Party can fetch the end
4644            user's URL in a secure manner. Following its own security
4645            policies, a Relying Party MAY choose to not complete, or
4646            even begin, a transaction if SSL is not being correctly
4647            used at these various endpoints.
4648          </t>
4649
4650          <section title="Rogue Relying Party Proxying" anchor="rp_mitm_proxy">
4651            <t>
4652              A special type of man-in-the-middle attack is one where
4653              the Relying Party is a rogue party acting as a MITM. The
4654              RP would perform discovery on the End User's Claimed
4655              Identifier and instead of redirecting the User Agent to
4656              the OP, would instead proxy the OP through itself. This
4657              would thus allow the RP to capture credentials the End
4658              User provides to the OP. While there are multiple ways to
4659              prevent this sort of attack, the specifics are outside the
4660              scope of this document. Each method of prevention
4661              requires that the OP establish a secure channel with the
4662              End User.
4663            </t>
4664          </section>
4665        </section>
4666      </section>
4667
4668      <section title="User-Agents">
4669        <t>
4670          Since this protocol is intended to be used interactively,
4671          User-Agents will primarily be common Web browsers. Web
4672          browsers or their hosts may be infected with spyware or
4673          other malware, which limits the strength of the
4674          authentication assertion, since untrusted software makes it
4675          impossible to know whether the authentication decision has
4676          been made with the end user's approval. With that said, many
4677          web applications and protocols today rely on the security of
4678          the Web browser and their hosts.
4679        </t>
4680
4681        <t>
4682          Cross-site-scripting attacks against OPs may be used to the
4683          same effect. For the best security, OPs should not depend
4684          on scripting. This enables User-Agents that do not support
4685          scripting, or have scripting disabled, to still employ the
4686          protocol.
4687        </t>
4688      </section>
4689
4690      <section title="User Interface Considerations">
4691        <t>
4692          The Relying Party SHOULD redirect the end user to the OP
4693          Endpoint URL in a top-level browser window with all controls
4694          visible. This allows better protection for the end user
4695          against OP look-alike sites (phishing).
4696        </t>
4697
4698        <t>
4699          OpenID Providers SHOULD educate their end users about the
4700          potential for OpenID phishing attacks and SHOULD equip their
4701          end users with the tools to defeat such attacks, for example
4702          browser plug-ins that verify the authenticity of the OP's
4703          Authentication Service Endpoint URL.
4704        </t>
4705      </section>
4706
4707      <section title="HTTP and HTTPS URL Identifiers">
4708        <t>
4709          While these types of Identifiers have been <xref
4710          target="http_s_identifiers">previously discussed</xref>,
4711          they are worth mentioning again. As previously stated, the
4712          RECOMMENDED method of an End User expressing control over a
4713          URL differing only be scheme is to setup a redirect from the
4714          HTTP URL to the HTTPS URL. Relying Parties will never store
4715          the HTTP URL as during the discovery and initiation phase
4716          will follow the redirect and use the HTTPS URL as the
4717          Claimed Identifier.
4718        </t>
4719
4720        <t>
4721          End users with concerns over this recommendation should
4722          directly enter their HTTPS URL at each Relying Party. This
4723          thus removes the step where the Relying Party follows the
4724          redirect to the HTTPS URL. The single security
4725          consideration currently seen is if an attacker were to
4726          compromise the integrity of the HTTP URL by removing the
4727          redirect and pointing the Identifier at a rogue OP. This
4728          however will alter the user experience, is detectable by
4729          anti-phishing technologies, and the security of the
4730          Identifier itself is a fundamental principle within OpenID.
4731        </t>
4732      </section>
4733
4734      <section title="Denial of Service Attacks">
4735        <t>
4736          Within the protocol there are places where a rogue RP could
4737          launch a denial of service attack against an OP since there
4738          is nothing in OpenID protocol messages that allows the OP to
4739          quickly check that it is a genuine request. This can be
4740          done by the RP repeatedly requesting associations,
4741          authentication, or verification of a signature.
4742        </t>
4743
4744        <t>
4745          The potentially most severe attack is during the association
4746          phase as each message requires the OP to execute a discrete
4747          exponentiation. Since the RP has the ability to specify
4748          modulus and generator per message, an attacker can even
4749          force the OP to perform this exponentiation in real time
4750          prior to responding for each message.
4751        </t>
4752
4753        <t>
4754          While this could be particularly harmful, OpenID Providers
4755          can easily use generic IP based rate-limiting and banning
4756          techniques to help combat these sorts of attacks. OPs can
4757          also look at banning requests based on the "openid.realm"
4758          and "openid.return_to" values.
4759        </t>
4760      </section>
4761
4762      <section title="Protocol Variants">
4763        <t>
4764          The following are known variations in the protocol which may
4765          or may not directly affect the security of the use of the
4766          protocol. It is imagined that these values could be used in
4767          the creation of security profiles for this protocol. The
4768          following list of variants are from the perspective of an
4769          OpenID Provider.
4770        </t>
4771
4772        <texttable>
4773          <ttcol align="left">Number</ttcol>
4774          <ttcol align="left">Variant</ttcol>
4775          <ttcol align="left">Values</ttcol>
4776
4777          <c>1.</c>
4778          <c>
4779            Are wildcards allowed in realms?
4780          </c>
4781          <c>
4782            One of Yes/No
4783          </c>
4784
4785          <c>2.</c>
4786          <c>
4787            Require prior association? Does the OP require the RP
4788            first create an association before requesting
4789            authentication?
4790          </c>
4791          <c>
4792            One of Yes/No
4793          </c>
4794
4795          <c>3.</c>
4796          <c>
4797            Types of claimed identifiers accepted.
4798          </c>
4799          <c>
4800            Set of HTTP/HTTPS/XRI
4801          </c>
4802
4803          <c>4.</c>
4804          <c>
4805            Are self-issued certificates allowed for authentication?
4806            This applies to all SSL traffic. If 'no' here, then OP
4807            *probably* requires all HTTPS identifiers to chain up to
4808            known trust roots, but that's intentionally not implied.
4809          </c>
4810          <c>
4811            One of Yes/No
4812          </c>
4813
4814          <c>5.</c>
4815          <c>
4816            Must the XRDS file be signed? Signature on the XRDS as per
4817            XMLDSIG. Keying material not specified, since the RP
4818            ultimately needs to make own decision whether to trust
4819            keys used for such signature.
4820          </c>
4821          <c>
4822            One of Yes/No
4823          </c>
4824
4825          <c>6.</c>
4826          <c>
4827            Must the XRDS file be retrieved over secure channel? This does not
4828            imply SSL?
4829          </c>
4830          <c>
4831            One of Yes/No
4832          </c>
4833
4834          <c>7.</c>
4835          <c>
4836            What types of session types can be used when creating
4837            associations?
4838          </c>
4839          <c>
4840            Set of no-encryption/DH-SHA1/DH-SHA256
4841          </c>
4842
4843          <c>8.</c>
4844          <c>
4845            Must the RP have an XRDS document?
4846          </c>
4847          <c>
4848            One of Yes/No
4849          </c>
4850
4851          <c>9.</c>
4852          <c>
4853            What association types the OP agrees to use for
4854            signatures?
4855          </c>
4856          <c>
4857            Set of HMAC-SHA1/HMAC-SHA256
4858          </c>
4859
4860          <c>10.</c>
4861          <c>
4862            Must the association request take place over secure channel?
4863          </c>
4864          <c>
4865            One of Yes/No
4866          </c>
4867
4868          <postamble>
4869            Identified security variants.
4870          </postamble>
4871        </texttable>
4872      </section>
4873    </section>
4874
4875    <appendix title="Examples">
4876      <t>Non-normative</t>
4877
4878      <appendix title="Normalization" anchor="normalization_example">
4879        <t>
4880          See section 6 of <xref target="RFC3986"/> for
4881          textual URL normalization details and more examples.
4882        </t>
4883        <texttable title="User's Input to Identifier Normalization">
4884          <ttcol align="left">User's Input</ttcol>
4885          <ttcol align="left">Identifier</ttcol>
4886          <ttcol align="left">Type</ttcol>
4887          <ttcol align="left">Discussion</ttcol>
4888
4889          <c>example.com</c>
4890          <c>http://example.com/</c>
4891          <c>URL</c>
4892          <c>A URI with a missing scheme is normalized to a http URI</c>
4893
4894          <c>http://example.com</c>
4895          <c>http://example.com/</c>
4896          <c>URL</c>
4897          <c>An empty path component is normalized to a slash</c>
4898
4899          <c>https://example.com/</c>
4900          <c>https://example.com/</c>
4901          <c>URL</c>
4902          <c>https URIs remain https URIs</c>
4903
4904          <c>http://example.com/user</c>
4905          <c>http://example.com/user</c>
4906          <c>URL</c>
4907          <c>No trailing slash is added to non-empty path components</c>
4908
4909          <c>http://example.com/user/</c>
4910          <c>http://example.com/user/</c>
4911          <c>URL</c>
4912          <c>Trailing slashes are preserved on non-empty path components</c>
4913
4914          <c>http://example.com/</c>
4915          <c>http://example.com/</c>
4916          <c>URL</c>
4917          <c>Trailing slashes are preserved when the path is empty</c>
4918
4919          <c>=example</c>
4920          <c>=example</c>
4921          <c>XRI</c>
4922          <c>Normalized XRIs start with a global context symbol</c>
4923
4924          <c>xri://=example</c>
4925          <c>=example</c>
4926          <c>XRI</c>
4927          <c>Normalized XRIs start with a global context symbol</c>
4928        </texttable>
4929      </appendix>
4930
4931      <appendix title="OP-Local Identifiers">
4932        <t>
4933          An end user wants to use "http://www.example.com/" as their
4934          Claimed Identifier. The end user has an account with
4935          Example Provider, which functions as an OpenID Provider. The
4936          end user's OP-Local Identifier is
4937          "https://exampleuser.exampleprovider.com/".
4938        </t>
4939
4940        <t>
4941          In this scenario, with the proper configuration of Yadis or
4942          HTML-Based Discovery (see <xref target="discovery"/> and
4943          <xref target="XRDS_Sample"/> below), a Relying Party will
4944          discover the following information about the end user:
4945
4946          <list style="hanging">
4947            <t hangText="Claimed Identifier">
4948              http://www.example.com/
4949            </t>
4950            <t hangText="OP-Local Identifier">
4951              https://exampleuser.exampleprovider.com/
4952            </t>
4953          </list>
4954        </t>
4955      </appendix>
4956
4957      <appendix title="XRDS" anchor="XRDS_Sample">
4958        <figure>
4959          <preamble>
4960            For an end user to use "http://www.example.com/" as
4961            their Identifier, but have Relying Parties actually
4962            verify "https://exampleuser.exampleprovider.com/" with the OP
4963            Endpoint URL
4964            "https://www.exampleprovider.com/endpoint/", the
4965            following XML snippet should be present in the final XRD
4966            element in the XRDS file when discovery is preformed on
4967            "http://www.example.com/":
4968          </preamble>
4969          <artwork><![CDATA[<Service xmlns="xri://$xrd*($v*2.0)">
4970  <Type>http://specs.openid.net/auth/2.0/signon</Type>
4971  <URI>https://www.exampleprovider.com/endpoint/</URI>
4972  <LocalID>https://exampleuser.exampleprovider.com/</LocalID>
4973</Service>]]></artwork>
4974        </figure>
4975      </appendix>
4976
4977      <appendix title="HTML Identifier Markup">
4978        <figure>
4979          <preamble>
4980            To use "http://www.example.com/" as their Identifier, but have
4981            Relying Parties actually verify
4982            "http://exampleuser.livejournal.com/" with the OpenID
4983            Provider located at
4984            "http://www.livejournal.com/openid/server.bml", the
4985            following markup should be present in the &lt;head&gt;
4986            of the HTML document located by the identifier URL:
4987          </preamble>
4988          <artwork><![CDATA[<link rel="openid2.provider openid.server"
4989  href="http://www.livejournal.com/openid/server.bml" />
4990<link rel="openid2.local_id openid.delegate"
4991  href="http://exampleuser.livejournal.com/" />]]></artwork>
4992        </figure>
4993      </appendix>
4994
4995      <appendix title="XRI CanonicalID">
4996        <t>
4997          For example, if the XRI i-names =example and =exmpl both
4998          yield an XRDS document with the CanonicalID
4999          xri://(example)!1234 then those Identifiers should be
5000          treated as equivalent. For applications with user accounts,
5001          the persistent Canonical ID xri://(example)!1234 should be
5002          used the primary key for the account. Although the
5003          i-names =example and =exmpl may also be stored for reference
5004          as display names, they are reassignable identifiers and
5005          should not be used as persistent keys.
5006        </t>
5007      </appendix>
5008    </appendix>
5009
5010    <appendix title="Diffie-Hellman Key Exchange Default Value" anchor="pvalue">
5011      <figure>
5012        <preamble>
5013          This is a confirmed-prime number, used as the default
5014          modulus for Diffie-Hellman Key Exchange. In hexadecimal:
5015        </preamble>
5016        <artwork><![CDATA[DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61E
5017F75A2E27898B057F9891C2E27A639C3F29B60814581CD3B2CA3986D268370557
50187D45C2E7E52DC81C7A171876E5CEA74B1448BFDFAF18828EFD2519F14E45E382
50196634AF1949E5B535CC829A483B8A76223E5D490A257F05BDFF16F2FB22C583AB]]></artwork>
5020      </figure>
5021    </appendix>
5022
5023    <!-- XXX: An example for Generating Signatures might be nice. -->
5024
5025    <appendix title="Acknowledgements">
5026      <t>
5027        The OpenID Community would like to thank the following people
5028        for the work they've done in the drafting and editing of this
5029        specification. If you want to know the nitty gritty of who
5030        actually wrote what, feel free to look at our SVN repository
5031        or even use "svn blame". :)
5032        http://openid.net/svn/specifications/authentication/2.0/
5033      </t>
5034
5035      <t>
5036        <list style="empty">
5037          <t>Barry Ferg (barry@sxip.com)</t>
5038          <t>Brad Fitzpatrick (brad@danga.com) &lt;author&gt;</t>
5039          <t>Carl Howells (chowells@janrain.com)</t>
5040          <t>David Recordon (david@sixapart.com) &lt;author/editor&gt;</t>
5041          <t>Dick Hardt (dick@sxip.com) &lt;author&gt;</t>
5042          <t>Drummond Reed (drummond.reed@cordance.net)</t>
5043          <t>Hans Granqvist (hgranqvist@verisign.com)</t>
5044          <t>Johannes Ernst (jernst@netmesh.us)</t>
5045          <t>Johnny Bufu (johnny@sxip.com) &lt;editor&gt;</t>
5046          <t>Josh Hoyt (josh@janrain.com) &lt;author/editor&gt;</t>
5047          <t>Kevin Turner (kevin@janrain.com)</t>
5048          <t>Marius Scurtescu (marius@sxip.com)</t>
5049          <t>Martin Atkins (mart@degeneration.co.uk)</t>
5050          <t>Mike Glover (mpg4@janrain.com)</t>
5051        </list>
5052      </t>
5053    </appendix>
5054  </middle>
5055
5056  <back>
5057    <references title="Normative References">
5058      <reference anchor="RFC3629">
5059        <front>
5060          <title>
5061            UTF-8, a transformation format of Unicode and ISO 10646
5062          </title>
5063          <author initials="F.Y" surname="Yergeau" fullname="Francois Yergeau">
5064            <organization/>
5065          </author>
5066        </front>
5067        <seriesInfo name="RFC" value="3629"/>
5068      </reference>
5069      <reference anchor="RFC2119">
5070        <front>
5071          <title>
5072            Key words for use in RFCs to Indicate Requirement Levels
5073          </title>
5074          <author initials="B.S" surname="Bradner" fullname="Scott Bradner">
5075            <organization>Alis Technologies</organization>
5076          </author>
5077        </front>
5078        <seriesInfo name="RFC" value="2119"/>
5079      </reference>
5080      <reference anchor="RFC3986">
5081        <front>
5082          <title>Uniform Resource Identifiers (URI): Generic Syntax</title>
5083          <author initials="T.L" surname="Berners-Lee"
5084                  fullname="T. Berners-Lee">
5085            <organization/>
5086          </author>
5087        </front>
5088        <seriesInfo name="RFC" value="3986"/>
5089      </reference>
5090      <reference anchor="RFC1750">
5091        <front>
5092          <title>Randomness Recommendations for Security</title>
5093          <author initials="D.E" surname="Eastlake"
5094                  fullname="Donald E. Eastlake, 3rd">
5095            <organization>Digital Equipment Corporation</organization>
5096          </author>
5097          <author initials="S.C" surname="Crocker"
5098                  fullname="Stephen D. Crocker">
5099            <organization>CyberCash, Inc.</organization>
5100          </author>
5101          <author initials="J.S" surname="Schiller"
5102                  fullname="Jeffery I. Schiller">
5103            <organization>Massachusetts Institute of Technology</organization>
5104          </author>
5105        </front>
5106        <seriesInfo name="RFC" value="1750"/>
5107      </reference>
5108      <reference anchor="RFC2631">
5109        <front>
5110          <title>Diffie-Hellman Key Agreement Method</title>
5111          <author initials="E.R" surname="Rescorla"
5112                  fullname="Eric Rescorla">
5113            <organization/>
5114          </author>
5115        </front>
5116        <seriesInfo name="RFC" value="2631"/>
5117      </reference>
5118      <reference anchor="RFC3548">
5119        <front>
5120          <title>The Base16, Base32, and Base64 Data Encodings</title>
5121          <author initials="S.J" surname="Josefsson"
5122                  fullname="Simon Josefsson">
5123            <organization/>
5124          </author>
5125        </front>
5126        <seriesInfo name="RFC" value="3548"/>
5127      </reference>
5128      <reference anchor="RFC2104">
5129        <front>
5130          <title>HMAC: Keyed-Hashing for Message Authentication</title>
5131          <author initials="H.K" surname="Krawczyk" fullname="Hugo Krawczyk">
5132            <organization>IBM</organization>
5133          </author>
5134          <author initials="M.B" surname="Bellare" fullname="Mihir Bellare">
5135            <organization>UCSD</organization>
5136          </author>
5137          <author initials="R.C" surname="Canetti" fullname="Ran Canetti">
5138            <organization>IBM</organization>
5139          </author>
5140        </front>
5141        <seriesInfo name="RFC" value="2104"/>
5142      </reference>
5143      <reference anchor="FIPS180-2">
5144        <front>
5145          <title>Secure Hash Signature Standard</title>
5146          <author>
5147            <organization>U.S. Department of Commerce</organization>
5148          </author>
5149          <author>
5150            <organization>National Institute of Standards
5151            and Technology</organization>
5152          </author>
5153        </front>
5154        <seriesInfo name="FIPS" value="180-2"/>
5155        <format type="PDF" target="http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf"/>
5156        <annotation>Defines Secure Hash Algorithm 256 (SHA256)</annotation>
5157      </reference>
5158      <reference anchor="HTML401">
5159        <front>
5160          <title>HTML 4.01 Specification</title>
5161          <author>
5162            <organization>W3C</organization>
5163          </author>
5164        </front>
5165        <format type="HTML" target="http://www.w3.org/TR/html401"/>
5166      </reference>
5167      <reference anchor="RFC2616">
5168        <front>
5169          <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
5170          <author initials="R.F" surname="Fielding" fullname="R. Fielding">
5171            <organization>UC Irvine</organization>
5172          </author>
5173          <author initials="J.G" surname="Gettys" fullname="J. Gettys">
5174            <organization>Compaq/W3C</organization>
5175          </author>
5176          <author initials="J.M" surname="Mogul" fullname="J. Mogul">
5177            <organization>Compaq</organization>
5178          </author>
5179          <author initials="H.F" surname="Frystyk" fullname="H. Frystyk">
5180            <organization>W3C/MIT</organization>
5181          </author>
5182          <author initials="L.M" surname="Masinter" fullname="L. Masinter">
5183            <organization>Xerox</organization>
5184          </author>
5185          <author initials="P.L" surname="Leach" fullname="P. Leach">
5186            <organization>Microsoft</organization>
5187          </author>
5188          <author initials="T.L" surname="Berners-Lee"
5189                  fullname="T. Berners-Lee">
5190            <organization>W3C/MIT</organization>
5191          </author>
5192        </front>
5193        <seriesInfo name="RFC" value="2616"/>
5194      </reference>
5195      <reference anchor="RFC3174">
5196        <front>
5197          <title>US Secure Hash Algorithm 1 (SHA1)</title>
5198          <author initials="D.E" surname="Eastlake"
5199                  fullname="Donald E. Eastlake, 3rd">
5200            <organization>Motorola</organization>
5201          </author>
5202          <author initials="P.J" surname="Jones" fullname="Paul E. Jones">
5203            <organization>Cisco Systems, Inc.</organization>
5204          </author>
5205        </front>
5206        <seriesInfo name="RFC" value="3174"/>
5207      </reference>
5208      <reference anchor="RFC3339">
5209        <front>
5210          <title>Date and Time on the Internet: Timestamps</title>
5211          <author initials="G.K" surname="Klyne" fullname="Graham Klyne">
5212            <organization>Clearswift Corporation</organization>
5213          </author>
5214          <author initials="C.N" surname="Newman"
5215                  fullname="Chris Newman">
5216            <organization>Sun Microsystems</organization>
5217          </author>
5218        </front>
5219        <seriesInfo name="RFC" value="3339"/>
5220      </reference>
5221
5222      <reference anchor="RFC3275">
5223        <front>
5224          <title>(Extensible Markup Language) XML-Signature Syntax and
5225          Processing</title>
5226          <author initials="D.E." surname="Eastlake 3rd"
5227                  fullname="Donald E. Eastlake 3rd">
5228            <organization>Motorola</organization>
5229          </author>
5230          <author initials="J.R." surname="Reagle Jr." fullname="Joseph M. Reagle Jr.">
5231            <organization>Massachusetts Institute of
5232            Technology</organization>
5233          </author>
5234          <author initials="D.S." surname="Solo" fullname="David Solo">
5235            <organization>Citigroup</organization>
5236          </author>
5237        </front>
5238        <seriesInfo name="RFC" value="3275"/>
5239      </reference>
5240
5241      <reference anchor="XRI_Syntax_2.0"
5242                 target="http://www.oasis-open.org/committees/download.php/15376">
5243
5244        <front>
5245          <title>Extensible Resource Identifier (XRI) Syntax V2.0</title>
5246          <author initials="D.R" surname="Reed" fullname="Drummond Reed">
5247            <organization>Cordance</organization>
5248          </author>
5249          <author initials="D.M" surname="McAlpin" fullname="Dave McAlpin">
5250            <organization>Epok</organization>
5251          </author>
5252        </front>
5253        <format type="HTML"
5254                target="http://www.oasis-open.org/committees/download.php/15376"/>
5255        <format type="PDF"
5256                target="http://www.oasis-open.org/committees/download.php/15377"/>
5257      </reference>
5258
5259      <reference anchor="XRI_Resolution_2.0"
5260                 target="http://www.oasis-open.org/committees/download.php/17293">
5261        <front>
5262          <title>Extensible Resource Identifier (XRI) Resolution V2.0
5263          - Committee Draft 02</title>
5264          <author initials="G.W" surname="Wachob" fullname="Gabe Wachob">
5265            <organization>Visa International</organization>
5266          </author>
5267          <author initials="D.R" surname="Reed" fullname="Drummond Reed">
5268            <organization>Cordance</organization>
5269          </author>
5270          <author initials="L.C" surname="Chasen" fullname="Les Chasen">
5271            <organization>NeuStar</organization>
5272          </author>
5273          <author initials="W.T" surname="Tan" fullname="William Tan">
5274            <organization>NeuStar</organization>
5275          </author>
5276          <author initials="S.C" surname="Churchill" fullname="Steve Churchill">
5277            <organization>XDI.ORG</organization>
5278          </author>
5279        </front>
5280        <format type="HTML"
5281                target="http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.html"/>
5282        <format type="PDF"
5283                target="http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.pdf"/>
5284      </reference>
5285
5286      <reference anchor="Yadis">
5287        <front>
5288          <title>Yadis Specification 1.0</title>
5289          <author initials="J.M" surname="Miller" fullname="Joaquin Miller">
5290            <organization>NetMesh</organization>
5291          </author>
5292        </front>
5293        <format type="PDF" target="http://yadis.org/papers/yadis-v1.0.pdf"/>
5294        <format type="ODT" target="http://yadis.org/papers/yadis-v1.0.odt"/>
5295      </reference>
5296    </references>
5297  </back>
5298</rfc>
Note: See TracBrowser for help on using the browser.