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

Revision 8200, 163.9 kB (checked in by koshigoe, 7 years ago)

docs/openid/specs/authentication/2.0/trunk: add translation of "5.2.1 HTTP Redirect"

  • 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="Dec" 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>には、
251            User-Agentを介してRPにUser-Supplied Identifierを提示します。
252          </t>
253          <t>
254            <!--
255              After <xref target="normalization">normalizing</xref> the
256              User-Supplied Identifier, the Relying Party <xref
257              target="discovery">performs discovery</xref> on it and
258              establishes the OP Endpoint URL that the end user uses for
259              authentication.  It should be noted that the User-Supplied
260              Identifier may be an OP Identifier, as discussed in <xref
261              target="discovered_info" />, which allows selection of a
262              Claimed Identifier at the OP or for the protocol to
263              proceed without a Claimed Identifier if something else
264              useful is being done via an <xref
265              target="extensions">extension</xref>.
266            -->
267            User-Supplied Identifierが<xref target="normalization">正規化</xref>されると、RP は<xref target="discovery">探索を行い</xref>、エンドユーザーが認証に使うOP Endpoint URLを確立します。注意点: <xref target="discovered_info" /> で述べていますが、User-Supplied IdentifierはOP Identifierであるかもしれません。その場合、OPのClaimed Identifierを用いるか、用いずに何か他の便利な<xref target="extensions">拡張</xref>手段を使ってプロトコルを処理するか、という選択肢があります。
268          </t>
269          <t>
270            <!--
271              (optional)
272
273              The Relying Party and the OP establish an <xref
274              target="associations">association</xref> - a shared
275              secret established using <xref
276              target="RFC2631">Diffie-Hellman Key Exchange</xref>. The
277              OP uses an association to sign subsequent messages and the
278              Relying Party to verify those messages; this removes the
279              need for subsequent direct requests to verify the
280              signature after each authentication request/response.
281            -->
282            (オプション)
283
284            RPとOPは、<xref target="associations">関連づけ (association)</xref>をつくります。
285            関連づけは<xref target="RFC2631">Diffie-Hellman 鍵共有法 (DH 法)</xref>を用いた
286            共有暗号鍵 (shared secret)です。
287            以降のメッセージは、この関連づけを使ってOPに署名され、RPに検証されます。
288            こうすることで、いちいち署名を検証するよう要求を出すという手間が省けるというわけです。
289          </t>
290          <t>
291            <!--
292              The Relying Party redirects the end user's User-Agent to
293              the OP with an OpenID <xref
294              target="requesting_authentication">Authentication
295              request</xref>.
296            -->
297            RPは、OpenIDの<xref target="requesting_authentication">認証要求</xref>
298            をつけて、エンドユーザーの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認証を行うことがエンドユーザーに認められているかどうかを、
309            OPは(認められていることを期待しつつ)確認します。
310            エンドユーザーがどうやってOPに自身を本物であると証明するか、
311            またその証明の手段はどうするか、といった点については、
312            この文書の範囲外とします。
313          </t>
314          <t>
315            <!--
316              The OP redirects the end user's User-Agent back to the
317              Relying Party with either an assertion that <xref
318              target="positive_assertions">authentication is
319              approved</xref> or a message that <xref
320              target="negative_assertions">authentication failed</xref>.
321            -->
322            OPはエンドユーザのUser-Agentを、次のいずれかの結果をつけて
323            RPにリダイレクトして戻します:
324            <xref target="positive_assertions">認証が承認された</xref>か、
325            <xref target="negative_assertions">認証に失敗した</xref>か。
326          </t>
327          <t>
328            <!--
329              The Relying Party <xref target="verification">verifies
330              </xref> the information received from the OP including
331              checking the Return URL, verifying the discovered
332              information, checking the nonce, and verifying the
333              signature by using either the shared key established
334              during the association or by sending a direct request
335              to the OP.
336            -->
337            RPはOPから受けとった情報を<xref target="verification">検証</xref>します。
338            検証するものには、戻りURL、見つかった情報、nonce、そして署名といった
339            ものがあります。
340            署名の検証には、関連づけのときに使った共有鍵を使うか、OPに対して直接
341            検証の要求を送るか、のいずれかの方法がとられます。
342          </t>
343        </list>
344      </t>
345    </section>
346
347
348    <section title="Data Formats - データ書式">
349
350      <section title="Protocol Messages - プロトコルメッセージ">
351
352        <!--
353        <t>
354          The OpenID Authentication protocol messages are
355          mappings of plain-text keys to plain-text values. The keys and
356          values permit the full Unicode character set (UCS). When the
357          keys and values need to be converted to/from bytes, they
358          MUST be encoded using <xref target="RFC3629">UTF-8</xref>.
359        </t>
360        -->
361
362        <t>
363          OpenID認証プロトコルのメッセージは複数のプレインテキストのキーと複数のプレインテキストの値のマッピングになっています。その複数のキーと値は完全なUnicodeキャラクタセット(UCS)をサポートします。その複数のキーと値がバイト列へ変換される、あるいはバイト列から変換される必要があるとき、それらは<xref target="RFC3629">UTF-8</xref>にエンコード「しなければなりません」(MUST)。
364        </t>
365
366        <!--
367        <t>
368          Messages MUST NOT contain multiple parameters with the same name.
369        </t>
370        -->
371
372        <t>
373          メッセージには同じ名前で複数のパラメタを含むことを「してはなりません」(MUST NOT)。
374        </t>
375
376        <!--
377        <t>
378          Throughout this document, all OpenID message parameters are
379          REQUIRED, unless specifically marked as OPTIONAL.
380        </t>
381        -->
382
383        <t>
384          このドキュメント中を通して、全てのOpenIDメッセージパラメタは、「オプションです」(OPTIONAL)と特に明記されていない場合以外は、「必要とされています」(REQUIRED)。
385        </t>
386
387        <section title="Key-Value Form Encoding - キーと値のフォームエンコーディング" anchor="kvform">
388          <!--
389          <t>
390            A message in Key-Value form is a sequence of lines.  Each
391            line begins with a key, followed by a colon, and the value
392            associated with the key.  The line is terminated by a
393            single newline (UCS codepoint 10, "\n"). A key or value
394            MUST NOT contain a newline and a key also MUST NOT contain
395            a colon.
396          </t>
397          -->
398          <t>
399            キーと値によるメッセージは複数行に順番に並ぶフォームです。それぞれの行はキーから始まり、コロンを続け、そしてそのキーに対応する値を続けます。行は1つの改行(UCSのコードポイントで10、"\n"の事)で区切られます。キーまたは値は改行を含む事を「してはなりません」(MUST NOT)、さらにキーはコロンを含む事も「してはなりません」。
400          </t>
401          <!--
402          <t>
403            Additional characters, including whitespace, MUST NOT be
404            added before or after the colon or newline. The message
405            MUST be encoded in UTF-8 to produce a byte string.
406          </t>
407          -->
408          <t>
409            ホワイトスペースを含む文字列の追加はコロンまたは改行の前後に追加「してはなりません」(MUST NOT)。メッセージはバイト文字とする為にUTF-8でエンコード「しなければなりません」(MUST)。
410          </t>
411          <!--
412          <t>
413            Key-Value Form encoding is used for signature calculation
414            and for <xref target="direct_response">direct
415            responses</xref> to Relying Parties.
416          </t>
417          -->
418          <t>
419            キーと値のフォームエンコーディングは署名の計算とRelying Partyへの<xref target="direct_response">直接的なレスポンス</xref>に使われます。
420          </t>
421        </section>
422
423        <section title="HTTP Encoding - HTTPエンコーディング" anchor="http_encoding">
424                  <!--
425          <t>
426            When a message is sent to an HTTP server, it MUST be encoded
427            using a form encoding specified in Section 17.13.4 of
428            <xref target="HTML401" />. Likewise, if the "Content-Type"
429            header is included in the request headers, its value MUST
430            also be such an encoding.
431          </t>
432                  -->
433                  <t>
434                        HTTPサーバーにメッセージを送信した際に、<xref target="HTML401" />の17.13.4節の中で定義されたフォームエンコーディングを使ってエンコードされて「いなければなりません」(MUST)。同様にして、"Content-Type"ヘッダーがリクエストパラメータの中に含まれている場合は、その値も同じようにエンコード「されなければなりません」(MUST)。
435                  </t>
436                  <!--
437          <t>
438            All of the keys in the request message MUST be prefixed
439            with "openid.". This prefix prevents interference with
440            other parameters that are passed along with the OpenID
441            Authentication message. When a message is sent as a POST,
442            OpenID parameters MUST only be sent in, and extracted
443            from, the POST body.
444          </t>
445                  -->
446                  <t>
447                        リクエストメッセージ中の全てのキーは"openid."を接頭辞と「しなければなりません」(MUST)。この接頭辞はOpenID Authenticationメッセージに沿って渡される他のパラメータによる干渉を防ぎます。メッセージがPOSTメソッドとして送信される際に、OpenIDパラメータはPOSTの本文として送信されなければならず、またPOSTの本文から展開されなければなりません。
448                  </t>
449          <t>
450            <!--
451            All messages that are sent as HTTP requests (GET or POST)
452            MUST contain the following fields:
453            -->
454            HTTPリクエスト(GETかPOST)として送られる全てのメッセージは、以下の項目を含んで「いなければなりません」(MUST)。
455
456            <list style='symbols'>
457              <t>
458                openid.ns
459                <list style='empty'>
460                  <t>
461                    値: "http://specs.openid.net/auth/2.0"
462                  </t>
463                  <t>
464                    <!--
465                    This particular value MUST be present for the
466                    request to be a valid OpenID Authentication 2.0
467                    request. Future versions of the specification may
468                    define different values in order to allow message
469                    recipients to properly interpret the request.
470                    -->
471                    リクエストが有効なOpenID認証2.0のリクエストであるためには、
472                    この特定の値が存在「しなければなりません」(MUST)。
473                    メッセージの受信者がリクエストを適切に解釈することを許容するために、
474                    仕様の将来のバージョンでは異なる値が定義されるかもしれません。
475                  </t>
476                  <t>
477                    <!--
478                    If this value is absent or set to one of
479                    "http://openid.net/signon/1.1" or
480                    "http://openid.net/signon/1.0", then this message
481                    SHOULD be interpreted using <xref
482                    target="compat_mode">OpenID Authentication 1.1
483                    Compatibility mode</xref>.
484                    -->
485                    もしこの値が存在しないか "http://openid.net/signon/1.1",
486                    "http://openid.net/signon/1.0"のいずれかであれば、
487                    このメッセージは<xref target="compat_mode">OpenID
488                    Authentication 1.1互換モード</xref>として解釈「されるべきです」(SHOULD)。
489                  </t>
490                </list>
491              </t>
492              <t>
493                openid.mode
494                <list style='empty'>
495                  <t>
496                    <!--
497                    Value: Specified individually for each message
498                    type.
499                    -->
500                    値: それぞれのメッセージについて個別に示される。
501                  </t>
502                  <t>
503                    <!--
504                    The "openid.mode" parameter allows the recipient
505                    of the message to know what kind of message it is
506                    processing. If "openid.mode" is absent, the party
507                    processing the message SHOULD assume that the
508                    request is not an OpenID message.
509                    -->
510                    "openid.mode"パラメタは、メッセージの受信者が処理
511                    しているメッセージの種類を知る事を可能にします。
512                    もし"openid.mode"が存在しないなら、メッセージを処理
513                    しているパーティはリクエストがOpenIDメッセージでは
514                    ないと仮定「すべきです」(SHOULD)。
515                  </t>
516                </list>
517              </t>
518            </list>
519          </t>
520
521          <t>
522            <!--
523            This model applies to messages from the User-Agent to both
524            the Relying Party and the OP, as well as messages from the
525            Relying Party to the OP.
526            -->
527            このモデルは、User-AgentからRelying PartyとOPの両方への
528            メッセージに加えて、Relying PartyからOPへのメッセージ
529            に対して適用します。
530          </t>
531        </section>
532        <section title="Example - 例">
533          <t>
534            <!--
535            Non-normative
536            -->
537            参考
538          </t>
539          <figure>
540            <preamble>
541              <!--
542              The following examples encode the following information:
543              -->
544              下記の例は以下の情報をエンコードします:
545            </preamble>
546            <artwork><![CDATA[
547Key     | Value
548--------+---------------------------
549mode    | error
550error   | This is an example message
551]]>
552            </artwork>
553          </figure>
554
555          <figure>
556            <preamble>
557              <!--
558              Key-Value Form encoded:
559              -->
560              キーと値のフォームエンコーディング:
561            </preamble>
562            <artwork><![CDATA[
563mode:error
564error:This is an example message
565            ]]>
566            </artwork>
567          </figure>
568
569          <figure>
570            <preamble>
571              <!--
572              x-www-urlencoded, as in a HTTP POST body or in a URL's
573              query string (<xref target="RFC3986" /> section 3):
574              -->
575              HTTP POSTのボディかURLのクエリ文字列におけるx-www-urlencoded(<xref target="RFC3986" /> section 3):
576            </preamble>
577            <artwork>openid.mode=error&amp;openid.error=This%20is%20an%20example%20message</artwork>
578          </figure>
579        </section>
580      </section>
581
582      <section title="Integer Representations - 整数の表現" anchor="btwoc">
583        <!--
584        <t>
585          Arbitrary precision integers MUST be encoded as big-endian
586          signed two's complement binary strings. Henceforth, "btwoc"
587          is a function that takes an arbitrary precision integer and
588          returns its shortest big-endian two's complement
589          representation. All integers that are used with
590          Diffie-Hellman Key Exchange are positive. This means that
591          the left-most bit of the two's complement representation
592          MUST be zero. If it is not, implementations MUST add a zero
593          byte at the front of the string.
594        </t>
595        -->
596        <t>
597          任意精度整数は、ビッグエンディアンの符号付き2の補数の
598          バイナリ文字列としてエンコード「されなければなりません」(MUST)。
599          以降、"btwoc"は任意精度整数を扱い最短のビッグエンディアンの
600          2の補数表現を返す関数とします。Diffie-Hellman 鍵共有法 (DH 法)
601          で使われる全ての整数は正です。これは2の補数表現の最も左の
602          ビットがゼロで「なければならない」(MUST)事を意味します。
603          もしそうでないなら、実装は文字列の先頭に"0"を意味するバイト
604          文字を付け加え「なければなりません」(MUST)。
605        </t>
606        <figure>
607          <!--
608          <preamble>Non-normative example:</preamble>
609          -->
610          <preamble>参考例:</preamble>
611          <artwork><![CDATA[
612Base 10 number | btwoc string representation
613---------------+----------------------------
6140              | "\x00"
615127            | "\x7F"
616128            | "\x00\x80"
617255            | "\x00\xFF"
61832768          | "\x00\x80\x00"
619          ]]></artwork>
620        </figure>
621      </section>
622    </section>
623
624    <section title="Communication Types - コミュニケーションタイプ">
625      <section title="Direct Communication - 直接的なコミュニケーション"
626               anchor="direct_comm">
627        <!--
628        <t>
629              Direct communication is initiated by a Relying Party to an
630              OP endpoint URL.  It is used for <xref
631              target="associations">establishing associations</xref> and
632              <xref target="check_auth">verifying authentication
633              assertions</xref>.
634        </t>
635        -->
636        <t>
637          直接的なコミュニケーションは、Relying PartyからOPのendpoint URLに対して始められます 。
638          これは、<xref target="associations">関連付けを確立するため</xref>と<xref target="check_auth">
639          認証アサーション</xref>を検証するために使います。
640        </t>
641
642        <section title="Direct Request - 直接的なリクエスト" anchor="direct_request">
643          <!--
644          <t>
645            The message MUST be encoded as a POST body, as specified
646            by <xref target="http_encoding" />.
647          </t>
648          -->
649          <t>
650            メッセージは<xref target="http_encoding" />で示したように、
651            POSTボディとしてエンコードされなければなりません(MUST)。
652          </t>
653
654          <!--
655          <t>
656            All direct requests are HTTP POSTs, and so
657            contain the required fields listed in <xref
658            target="http_encoding" />.
659          </t>
660          -->
661          <t>
662            すべての直接的なリクエストはHTTP POSTであり、<xref target="http_encoding" />で
663            列挙したリクエストフィールドを含みます。
664          </t>
665
666        </section>
667        <section title="Direct Response - 直接的なレスポンス" anchor="direct_response">
668          <!--
669          <t>
670            The body of a response to a <xref
671            target="direct_request">Direct Request</xref> consists of
672            an HTTP Response body in <xref target="kvform">Key-Value
673            Form</xref>. The content-type of the response SHOULD be
674            "text/plain".
675          </t>
676          -->
677          <t>
678            <xref target="direct_request">直接的なリクエスト</xref>への応答のボディは、
679            <xref target="kvform">キーと値のフォーム</xref>によるHTTPレスポンスボディで
680            構成されます。応答のcontent-typeは"text/plain"であるべきです(SHOULD)。
681          </t>
682
683          <t>
684            キーと値のフォームのメッセージの全てに、以下の項目を含まなければなりません(MUST)。
685            <!--
686            All Key-Value form message MUST contain the following field:
687            -->
688
689            <list style='symbols'>
690              <t>
691                ns
692                <list style='empty'>
693                  <t>
694                    Value: "http://specs.openid.net/auth/2.0"
695                  </t>
696                  <!--
697                  <t>
698                    This particular value MUST be present for the
699                    response to be a valid OpenID 2.0 response. Future
700                    versions of the specification may define different
701                    values in order to allow message recipients to
702                    properly interpret the request.
703                  </t>
704                  -->
705                  <t>
706                    レスポンスが有効なOpenID 2.0のレスポンスであるためには、
707                    この特定の値が存在しれなければなりません(MUST)。
708                    メッセージの受信者がリクエストを適切に解釈することを許容するために、
709                    仕様の将来のバージョンでは異なる値が定義されるかもしれません。
710                  </t>
711                  <!--
712                  <t>
713                    If this value is absent or set to one of
714                    "http://openid.net/signon/1.1" or
715                    "http://openid.net/signon/1.0", then this message
716                    SHOULD be interpreted using <xref
717                    target="compat_mode">OpenID Authentication 1.1
718                    Compatibility mode</xref>.
719                  </t>
720                  -->
721                  <t>
722                    もしこの値が存在しないか "http://openid.net/signon/1.1",
723                    "http://openid.net/signon/1.0"のいずれかであれば、
724                    このメッセージは<xref target="compat_mode">OpenID
725                    Authentication 1.1互換モード</xref>として解釈されるべきです(SHOULD)。
726                  </t>
727                </list>
728              </t>
729            </list>
730          </t>
731
732          <section title="Successful Responses - 正常レスポンス">
733            <!--
734            <t>
735              A server receiving a valid request MUST send a
736              response with an HTTP status code of 200.
737            </t>
738            -->
739            <t>
740              有効なリクエストを受信したサーバは、ステータスコード200とともに
741              応答を送信しなければなりません(MUST)。
742            </t>
743          </section>
744
745          <section title="Error Responses - エラーレスポンス">
746            <!--
747            <t>
748              If a request is malformed or contains invalid arguments,
749              the server MUST send a response with a status code of
750              400. The response body MUST be a <xref
751              target="kvform">Key-Value Form</xref> message with the
752              following fields:
753            </t>
754            -->
755            <t>
756              リクエストが異常もしくは不正な値を含んでいる場合は、
757              サーバはステータスコード400とともに応答を
758              送信しなければなりません(MUST)。
759              レスポンスボディは以下の項目を含んだ<xref target="kvform">
760              キーと値のフォーム</xref>でなければなりません(MUST)。
761            </t>
762            <t>
763              <list style='symbols'>
764                <t>
765                  ns
766                  <list style='empty'>
767                    <!--
768                    <t>
769                      As specified in <xref target="direct_response" />.
770                    </t>
771                    -->
772                    <t>
773                      <xref target="direct_response" />で示したとおり。
774                    </t>
775                  </list>
776                </t>
777
778                <t>
779                  error
780                  <list style='empty'>
781                    <!--
782                    <t>
783                      Value: A human-readable message indicating the cause
784                      of the error.
785                    </t>
786                    -->
787                    <t>
788                      値: エラーの原因を示す、人間が読むことができるメッセージ。
789                    </t>
790                  </list>
791                </t>
792
793                <t>
794                  contact
795                  <list style='empty'>
796                    <!--
797                    <t>
798                      Value: (optional) Contact address for the
799                      administrator of the sever. The contact address
800                      may take any form, as it is intended to be
801                      displayed to a person.
802                    </t>
803                    -->
804                    <t>
805                      値: (optional) サーバ管理者の連絡先。
806                      人に表示することを意図したものであれば、
807                      連絡先はどんな形式でもよい。
808                    </t>
809                  </list>
810                </t>
811
812                <t>
813                  reference
814                  <list style='empty'>
815                    <!--
816                    <t>
817                      Value: (optional) A reference token, such
818                      as a support ticket number or a URL to a news
819                      blog, etc.
820                    </t>
821                    -->
822                    <t>
823                      値: (optional) サポートチケット番号、ニュースBlogのURLなどの参照先。
824                    </t>
825                  </list>
826                </t>
827              </list>
828              OPはこの応答に追加の項目を加えてもよい(MAY)。
829              <!--
830              The OP MAY add additional fields to this response.
831              -->
832            </t>
833          </section>
834        </section>
835      </section>
836      <section title="Indirect Communication - 間接的な通信"
837               anchor="indirect_comm">
838        <!--
839        <t>
840          In indirect communication, messages are passed through the
841          User-Agent.  This can be initiated by either the Relying
842          Party or the OP.  Indirect communication is used for <xref
843          target="requesting_authentication">authentication
844          requests</xref> and <xref
845          target="responding_to_authentication">authentication
846          responses</xref>.
847        </t>
848        -->
849        <t>
850          間接的な通信では、メッセージはUser-Agentを通過します。
851          Relying PartyかOPのどちらからでも始める事が出来ます。
852          間接的な通信は<xref target="requesting_authentication">認証要求</xref>と
853          <xref target="responding_to_authentication">認証応答</xref>
854          のために使われます。
855        </t>
856        <!--
857        <t>
858          There are two methods for indirect communication: HTTP
859          redirects and HTML form submission.
860          Both form submission and redirection require that the sender
861          know a recipient URL and that the recipient URL expect
862          indirect messages, as specified in <xref target="http_encoding"
863          />. The initiator of the communication chooses which method
864          of indirect communication is appropriate depending on
865          capabilities, message size, or other external factors.
866        </t>
867        -->
868        <t>
869          間接的な通信のための2つの方法: HTTPリダイレクトとHTMLフォーム送信。
870          フォーム送信とリダイレクションの両方は、送信者が受信者のURLを
871          知っている事と、受信者のURLが<xref target="http_encoding" />で示される
872          ような間接的なメッセージを期待している事を要求します。
873          通信の開始側は、性能, メッセージサイズ, 他の外部要因によって決まる
874          ふさわしい間接的な通信の方法を選びます。
875        </t>
876        <!--
877        <t>
878          All indirect messages arrive as HTTP requests, and so
879          contain the required fields listed in <xref
880          target="http_encoding" />.
881        </t>
882        -->
883        <t>
884          全ての間接的なメッセージはHTTPリクエストとして到着するので、
885          <xref target="http_encoding" />で列挙した必須フィールドを含みます。
886        </t>
887
888        <section title="HTTP Redirect - HTTPリダイレクト">
889          <!--
890          <t>
891            Data can be transferred by issuing a 302, 303, or 307 HTTP
892            Redirect to the end user's User-Agent. The redirect URL is
893            the URL of the receiver with the OpenID Authentication
894            message appended to the query string, as specified in
895            <xref target="http_encoding" />.
896          </t>
897          -->
898          <t>
899            302, 303, 307のHTTPリダイレクトをエンドユーザーの
900            User-Agentに対して発行する事で、データの転送が出来ます。
901            リダイレクトURLは、<xref target="http_encoding" />で示される
902            OpenID認証メッセージをクエリ文字列に追加した、受信者のURLです。
903          </t>
904        </section>
905
906        <section title="HTML FORM Redirection - HTMLフォームリダイレクション">
907          <t>
908            A mapping of keys to values can be transferred by
909            returning an HTML page to the User-Agent that contains an
910            HTML form element. Form submission MAY be automated,
911            for example by using JavaScript.
912          </t>
913          <t>
914            The &lt;form&gt; element's "action" attribute value MUST
915            be the URL of the receiver. Each Key-Value pair MUST be
916            included in the form as an &lt;input&gt; element. The key
917            MUST be encoded as the "name" attribute and the value as
918            the "value" attribute, such that the User-Agent will
919            generate a message as specified in <xref
920            target="http_encoding"/> when the form is submitted. The
921            form MUST include a submit button.
922          </t>
923        </section>
924        <section title="Indirect Error Responses - 間接エラーメッセージ" anchor="indirect_error">
925          <t>
926            In the case of a malformed request, or one that contains
927            invalid arguments, the OpenID Provider MUST redirect the
928            User-Agent to the "openid.return_to" URL value if the
929            value is present and it is a valid URL.
930          </t>
931          <t>
932            <list style='symbols'>
933              <t>
934                openid.ns
935                <list style='empty'>
936                  <t>
937                    As specified in <xref target="http_encoding" />.
938                  </t>
939                </list>
940              </t>
941
942              <t>
943                openid.mode
944                <list style='empty'>
945                  <t>
946                    Value: "error"
947                  </t>
948                </list>
949              </t>
950              <t>
951                openid.error
952                <list style='empty'>
953                  <t>
954                    Value: A human-readable message indicating the cause
955                    of the error.
956                  </t>
957                </list>
958              </t>
959              <t>
960                openid.contact
961                <list style='empty'>
962                  <t>
963                    Value: (optional) Contact address for the
964                    administrator of the sever. The contact address
965                    may take any form, as it is intended to be
966                    displayed to a person.
967                  </t>
968                </list>
969              </t>
970
971              <t>
972                openid.reference
973                <list style='empty'>
974                  <t>
975                    Value: (optional) A reference token, such as a
976                    support ticket number or a URL to a news blog,
977                    etc.
978                  </t>
979                </list>
980              </t>
981            </list>
982
983            The server MAY add additional keys to this response.
984          </t>
985          <t>
986            If the malformed or invalid message is received by the Relying
987            Party, or "openid.return_to" is not present or its value is not
988            a valid URL, the server SHOULD return a response to the
989            end user indicating the error and that it is unable to continue.
990          </t>
991        </section>
992      </section>
993    </section>
994
995    <section title="Generating Signatures - 署名の生成" anchor="generating_signatures">
996      <!--
997      <t>
998        The most common usage of an association is as a Message
999        Authentication Code (MAC) key used to sign OpenID
1000        Authentication messages.
1001      </t>
1002      -->
1003      <t>
1004        関連づけ (association) の主な用途は,メッセージ認証コードキー
1005        (MACキー) を使って OpenID 認証メッセージに署名することです.
1006      </t>
1007
1008      <!--
1009      <t>
1010        When generating MAC keys, the recommendations in <xref
1011        target="RFC1750" /> SHOULD be followed.
1012      </t>
1013      -->
1014      <t>
1015        MACキーを生成するときは,<xref target="RFC1750" />
1016        で推奨されている方法に従うべき (SHOULD) です.
1017      </t>
1018
1019      <section title="Procedure - プロシージャ (手順)">
1020        <t>
1021          メッセージ署名を生成する手順:
1022          <!--
1023          To generate a message signature:
1024          -->
1025
1026          <list style="numbers">
1027            <!--
1028            <t>
1029              Determine the list of keys to be signed, according to
1030              the message to be signed (See <xref
1031              target="positive_assertions" />). The list of keys to be
1032              signed MUST be part of the message. The list is stored
1033              with the key "openid.signed". The value is a
1034              comma-separated list of keys, with the "openid." prefix
1035              stripped. This algorithm is only capable of signing keys
1036              that start with "openid."
1037            </t>
1038            -->
1039            <t>
1040              署名するメッセージから,署名対象となるキーのリストを抜き出します
1041              (<xref target="positive_assertions" /> 参照).
1042              この署名対象キーはメッセージの一部でなければなりません (MUST).
1043              署名対象キーはカンマで区切って "openid.signed" というキーに格納されます.
1044              このとき,各キーの "openid." という接頭辞は外してください.
1045              このアルゴリズムは,"openid." で始まるキーにしか
1046              署名できません.
1047            </t>
1048
1049            <!--
1050            <t>
1051              Iterate through the list of keys to be signed in the
1052              order they appear in "openid.signed" list.  For each
1053              key, find the value in the message whose key is equal to
1054              the signed list key prefixed with "openid."
1055            </t>
1056            -->
1057            <t>
1058              "openid.signed" に列挙されている順に従い,
1059              署名対象キーそれぞれに対して次の処理を行います.
1060              メッセージから一致するキーを見つけ ("opneid." 接頭辞の有無に注意),
1061              その値を取得します.
1062            </t>
1063
1064            <!--
1065            <t>
1066              Convert the list of key/value pairs to be signed to an
1067              octet string by encoding with <xref
1068              target="kvform">Key-Value Form Encoding</xref>.
1069            </t>
1070            -->
1071            <t>
1072              <xref target="kvform">キーと値のフォームエンコーディング</xref>
1073              を用いて,署名対象キーと値のペアをオクテット文字列に変換します.
1074            </t>
1075
1076            <!--
1077            <t>
1078              Determine the signature algorithm from the <xref
1079              target="associations">association type</xref>.  Apply
1080              the <xref target="sign_algos">signature algorithm</xref>
1081              to the octet string.
1082            </t>
1083            -->
1084            <t>
1085              <xref target="associations">関連づけの種類</xref> に応じて
1086              署名アルゴリズムを決定し,オクテット文字列に
1087              <xref target="sign_algos">署名アルゴリズム</xref>を適用します.
1088            </t>
1089          </list>
1090        </t>
1091      </section>
1092
1093      <section title="Signature Algorithms - 署名アルゴリズム" anchor="sign_algos">
1094        <t>
1095          OpenID 認証では次の2つの署名アルゴリズムをサポートします:
1096          <!--
1097          OpenID Authentication supports two signature algorithms:
1098          -->
1099
1100          <list style="symbols">
1101            <t>HMAC-SHA1 - 160 bit key length (<xref target="RFC2104" /> and <xref
1102            target="RFC3174" />)</t>
1103            <t>HMAC-SHA256 - 256 bit key length (<xref target="RFC2104" /> and <xref
1104            target="FIPS180-2" /></t>
1105          </list>
1106
1107          HMAC-SHA256 がサポートされているときは,そちらを使ってください.
1108          <!--
1109          If supported, the use of HMAC-SHA256 is RECOMMENDED.
1110          -->
1111        </t>
1112      </section>
1113    </section>
1114
1115    <section title="Initiation and Discovery - 初期化とディスカバリー">
1116
1117      <section title="Initiation - 初期化" anchor="initiation">
1118        <!--
1119        <t>
1120          To initiate OpenID Authentication, the Relying Party SHOULD
1121          present the end user with a form that has a field for
1122          entering a User-Supplied Identifier.
1123        </t>
1124        -->
1125        <t>
1126          OpenID認証の初期化時に、Relying PartyはUser-Supplied Identifierを入力するためのフィールドを持つフォームをエンドユーザーに表示すべきです。(SHOULD)
1127        </t>
1128
1129        <!--
1130        <t>
1131          The form field's "name" attribute SHOULD have the value
1132          "openid_identifier", so that User-Agents can automatically
1133          determine that this is an OpenID form. Browser extensions or
1134          other software that support OpenID Authentication may not
1135          detect a Relying Party's support if this attribute is not
1136          set appropriately.
1137        </t>
1138        -->
1139
1140        <t>
1141          そのフォームフィールドの "name" 属性は "openid_identifier" と言う値を持つべきです。(SHOULD)
1142          と言うのもUser-Agentはその入力フィールドがOpenIDのフォームであることを自動的に判別できるからです。
1143          OpenID認証に対応したブラウザ拡張や他のソフトウェアはこの属性が適切に設定されていない場合、Relying Partyを正しく判別する事が出来ないでしょう。
1144        </t>
1145      </section>
1146
1147      <section title="Normalization - 正規化" anchor="normalization">
1148        <!--
1149        <t>
1150          The end user's input MUST be normalized into an
1151          Identifier, as follows:
1152        </t>
1153        -->
1154
1155        <t>
1156          エンドユーザーの入力は下記に従って正規化されたIdentifierとしなければなりません。(MUST)
1157        </t>
1158
1159        <t>
1160          <list style="numbers">
1161            <!--
1162            <t>
1163              If the user's input starts with the "xri://" prefix,
1164              it MUST be stripped off, so that XRIs are used in the
1165              canonical form.
1166            </t>
1167            -->
1168            <t>
1169              ユーザーが "xri://" と言う接頭辞から始まる入力を行った場合、その接頭辞は捨てなければなりません。(MUST)
1170              と言うのはXRIは特定の基準に則った形式で使われるものだからです。
1171            </t>
1172
1173            <!--
1174            <t>
1175              If the first character of the resulting string is an
1176              XRI Global Context Symbol ("=", "@", "+", "$", "!") or "(", as
1177              defined in Section 2.2.1 of <xref target="XRI_Syntax_2.0" />,
1178              then the input SHOULD be treated as an XRI.
1179            </t>
1180            -->
1181
1182            <t>
1183              結果文字列の最初の文字が<xref target="XRI_Syntax_2.0" />の2.2.1節で定義されているXRI Global Context Symbol ("=", "@", "+", "$", "!") または "(" であるならば、その入力はXRIとして扱われるべきです。(SHOULD)
1184            </t>
1185
1186            <!--
1187            <t>
1188              Otherwise, the input SHOULD be treated as an http URL; if it
1189              does not include a "http" or "https" scheme, the Identifier
1190              MUST be prefixed with the string "http://". If the URL
1191              contains a fragment part, it MUST be stripped off
1192              together with the fragment delimiter character "#". See
1193              <xref target='http_s_identifiers' /> for more information.
1194            </t>
1195            -->
1196
1197            <t>
1198              そのいずれでもなければ、その入力はhttpのURLとして扱われるべきです。(SHOULD)
1199              その入力が "http" または "https" スキーマを含んでいなかった場合は、そのIdentifierは"http://"と言う文字列を接頭辞としてつけなければなりません。(MUST)
1200              URLにフラグメントパートが含まれている場合は、フラグメントの区切り文字列である "#" と共に除去されなければなりません。(MUST)
1201              より詳しくは<xref target='http_s_identifiers' />を見て下さい。
1202            </t>
1203
1204            <!--
1205            <t>
1206              URL Identifiers MUST then be further normalized by both
1207              following redirects when retrieving their content and
1208              finally applying the rules in Section 6 of <xref
1209              target='RFC3986' /> to the final destination URL. This
1210              final URL MUST be noted by the Relying Party as the
1211              Claimed Identifier and be used when <xref
1212              target="requesting_authentication">requesting
1213              authentication</xref>.
1214            </t>
1215            -->
1216
1217            <t>
1218              URL Identifierはそれらの内容を取得した際のリダイレクトに従うと言う事と、<xref target='RFC3986' />の6節で定義された正規化ルールを最終的な目的URLに対して最後まで適用すると言う事の両方によって正規化された物でなくてはなりません。(MUST)
1219              この最終的なURLはRelying PartyによってClaimed Identifierとして記録され、<xref target="requesting_authentication">認証要求</xref>において使用されなければなりません。(MUST)
1220             
1221            </t>
1222          </list>
1223
1224          <!--
1225          See <xref target="normalization_example">normalization
1226          example</xref>.
1227          -->
1228          <xref target="normalization_example">正規化の例</xref>を見て下さい。
1229
1230        </t>
1231      </section>
1232
1233      <section title="Discovery - ディスカバリー" anchor="discovery">
1234
1235        <!--
1236        <t>
1237          Discovery is the process where the Relying Party uses the
1238          Identifier to look up ("discover") the necessary information
1239          for initiating requests. OpenID Authentication has three
1240          paths through which to do discovery:
1241        </t>
1242        -->
1243
1244        <t>
1245          ディスカバリーとはRelying Partyが認証要求の始める際に必須の情報を探し出す("ディスカバリー")時にIdentifierを使用する際のプロセスです。OpenID認証はディスカバリーを行う方法として3つの経路があります。
1246        </t>
1247
1248        <t>
1249          <list style="numbers">
1250            <!--
1251            <t>
1252              If the identifier is an XRI, <xref
1253              target="XRI_Resolution_2.0" />
1254              will yield an XRDS document that
1255              contains the necessary information.  It should also be
1256              noted that Relying Parties can take advantage of
1257              XRI Proxy Resolvers, such as the one provided by
1258              XDI.org at http://www.xri.net. This will remove the need for the RPs to
1259              perform XRI Resolution locally.
1260            </t>
1261            -->
1262
1263            <t>
1264              IdentifierがXRI<xref target="XRI_Resolution_2.0" />ならば、XRIは必須の情報を含んだXRDS文書を生成するでしょう。
1265              Relying Partyがその一つはXDI.org(http://www.xri.net)によって提供されているようなXRIプロキシリゾルバよりも優れた物になりうると言う事に注意すべきです。
1266              これはRPが自分達でXRI解決を行う必要を取り去るでしょう。
1267            </t>
1268
1269            <!--
1270            <t>
1271              If it is a URL, the <xref target="Yadis">Yadis
1272              protocol</xref> SHALL be first attempted. If it
1273              succeeds, the result is again an XRDS document.
1274            </t>
1275            -->
1276
1277            <t>
1278              IdentifierがURLならば、<xref target="Yadis">Yadis protocol</xref>を最初に試みる事とします。
1279              それが成功した場合、結果は再びXRDS文書です。
1280            </t>
1281
1282            <!--
1283            <t>
1284              If the Yadis protocol fails and no valid XRDS document
1285              is retrieved, or no <xref
1286              target="service_elements">Service Elements</xref> are
1287              found in the XRDS document, the URL is retrieved and
1288              <xref target="html_disco">HTML-Based discovery</xref>
1289              SHALL be attempted.
1290            </t>
1291            -->
1292
1293            <t>
1294              Yadisプロトコルで失敗したり、妥当でないXRDS文書が取得されたり、<xref target="service_elements">Service Elements</xref>がXRDS文書に存在しない場合、そのURLを取得して<xref target="html_disco">HTML-Based discovery</xref>を試みられるとします。
1295            </t>
1296          </list>
1297        </t>
1298
1299        <section title="Discovered Information - 発見された情報" anchor="discovered_info">
1300          <t>
1301            Upon successful completion of discovery, the Relying Party
1302            will have one or more sets of the following information
1303            (see the <xref target="terminology">Terminology
1304            section</xref> for definitions).  If more than one set of
1305            the following information has been discovered, the
1306            precedence rules defined in <xref target="XRI_Resolution_2.0" />
1307            are to be applied.
1308
1309            <list style="symbols">
1310              <t>OP Endpoint URL</t>
1311              <t>Protocol Version</t>
1312            </list>
1313
1314            If the end user did not enter an OP Identifier, the
1315            following information will also be present:
1316
1317            <list style="symbols">
1318              <t>Claimed Identifier</t>
1319              <t>OP-Local Identifier</t>
1320            </list>
1321
1322            If the end user entered an OP Identifier, there is no
1323            Claimed Identifier. For the purposes of making OpenID
1324            Authentication requests, the value
1325            "http://specs.openid.net/auth/2.0/identifier_select"
1326            MUST be used as both the Claimed Identifier and the
1327            OP-Local Identifier when an OP Identifier is entered.
1328          </t>
1329        </section>
1330
1331        <section title="XRDS-Based Discovery - XRDSを用いたディスカバリー">
1332          <t>
1333            If XRI or Yadis discovery was used, the result will be an
1334            XRDS Document.  This is an XML document with entries for
1335            services that are related to the Identifier.  It is
1336            defined in <xref target="XRI_Resolution_2.0">Section 3
1337            of</xref>.  See <xref target="XRDS_Sample" /> for an
1338            example XRDS document.
1339          </t>
1340
1341
1342          <section title="OpenID Service Elements - OpenIDサービス要素" anchor="service_elements">
1343
1344            <section title="OP Identifier Element - OP Identifier 要素">
1345              <t>
1346                An OP Identifier Element is an &lt;xrd:Service&gt;
1347                element with the following information:
1348
1349                <list style="hanging">
1350                  <t>
1351                    An &lt;xrd:Type&gt; tag whose text content is
1352                    "http://specs.openid.net/auth/2.0/server".
1353                  </t>
1354
1355                  <t>
1356                    An &lt;xrd:URI&gt; tag whose text content is the
1357                    OP Endpoint URL
1358                  </t>
1359                </list>
1360              </t>
1361            </section>
1362
1363            <section title="Claimed Identifier Element - Claimed Identifier要素">
1364              <t>
1365                A Claimed Identifier Element is an
1366                &lt;xrd:Service&gt; element with the following
1367                information:
1368
1369                <list style="hanging">
1370                  <t>
1371                    An &lt;xrd:Type&gt; tag whose text content is
1372                    "http://specs.openid.net/auth/2.0/signon".
1373                  </t>
1374
1375                  <t>
1376                    An &lt;xrd:URI&gt; tag whose text content is the
1377                    OP Endpoint URL.
1378                  </t>
1379
1380                  <t>
1381                    An &lt;xrd:LocalID&gt; tag (optional) whose text
1382                    content is the OP-Local Identifier.
1383                  </t>
1384                </list>
1385              </t>
1386            </section>
1387          </section>
1388
1389          <section title="Extracting Authentication Data"
1390                   anchor="extracting_auth">
1391            <t>
1392              Once the Relying Party has obtained an XRDS document, it
1393              MUST first search the document (following the rules
1394              described in <xref target="XRI_Resolution_2.0" />) for
1395              an OP Identifier Element. If none is found, the RP will search
1396              for a Claimed Identifier Element.
1397            </t>
1398          </section>
1399
1400          <section title="XRI and the CanonicalID Element" anchor="canonicalid"
1401                   toc="exclude">
1402            <t>
1403              When the Identifier is an XRI, the &lt;xrd:XRD&gt;
1404              element that contains the OpenID Authentication
1405              &lt;xrd:Service&gt; element MUST also contain a
1406              &lt;CanonicalID&gt; element. The content of this element
1407              MUST be used as the Claimed Identifier (see <xref
1408              target="identifying" />).  This is a vital security
1409              consideration because a primary purpose of the
1410              &lt;CanonicalID&gt; element is to assert a persistent
1411              identifier that will never be reassigned, thus
1412              preventing the possibility of an XRI being ("taken
1413              over") by a new registrant.
1414            </t>
1415
1416            <t>
1417              The Relying Party MUST confirm that the provider of the
1418              XRD that contains the &lt;CanonicalID&gt; element is
1419              authoritative for that Canonical ID and that this XRDS
1420              document is authoritative for the OpenID Service
1421              Element. Relying Parties should either do this manually
1422              or ensure that their resolver does this.
1423            </t>
1424
1425            <t>
1426              When using XRI resolution, the Canonical ID MUST be
1427              used as the Claimed Identifier. For an XRI to be a
1428              valid Identifier, both the &lt;ProviderID&gt; and
1429              &lt;CanonicalID&gt; MUST be present in the discovered
1430              XRDS document.
1431            </t>
1432
1433            <t>
1434              When using URL Identifiers, the CanonicalID
1435              element MUST be ignored if present.
1436            </t>
1437          </section>
1438
1439          <section title="Additional Information">
1440            <t>
1441              The "openid" namespace is no longer used as of OpenID
1442              Authentication 2.0.  The "xrd" namespace is
1443              "xri://$xrd*($v*2.0)".
1444            </t>
1445
1446            <t>
1447              For compatibility with deployed code, it is RECOMMENDED
1448              that Relying Parties also accept
1449              "http://openid.net/signon/1.0" or
1450              "http://openid.net/signon/1.1" for the value of
1451              &lt;xrd:Type&gt;, as described in the <xref
1452              target="compat_mode">OpenID Authentication 1.1
1453              Compatibility mode</xref> section. It is RECOMMENDED
1454              that Relying Parties supporting OpenID Authentication
1455              2.0 choose to use, if available, endpoints with the type
1456              "http://specs.openid.net/auth/2.0/server" and
1457              "http://specs.openid.net/auth/2.0/signon", in
1458              this order, as specified in <xref
1459              target="extracting_auth" />
1460            </t>
1461
1462            <t>
1463              If an OP supports extensions (<xref target="extensions"
1464              />), the extensions SHOULD be listed as additional
1465              &lt;xrd:Type&gt; child elements of the
1466              &lt;xrd:Service&gt; element.
1467            </t>
1468
1469          </section>
1470
1471        </section>
1472
1473        <section anchor="html_disco" title="HTML-Based Discovery">
1474          <t>
1475            HTML-Based discovery MUST be supported by Relying
1476            Parties. HTML-Based discovery is only usable for discovery
1477            of Claimed Identifiers. OP Identifiers must be XRIs or
1478            URLs that support XRDS discovery.
1479          </t>
1480
1481          <t>
1482            To use HTML-Based discovery, an HTML document MUST be
1483            available at the URL of the Claimed Identifier. Within the
1484            HEAD element of the document:
1485
1486            <list>
1487              <t>
1488                A LINK element MUST be included with attributes
1489                "rel" set to "openid2.provider" and "href" set to an OP
1490                Endpoint URL
1491              </t>
1492              <t>
1493                A LINK element MAY be included with attributes
1494                "rel" set to "openid2.local_id" and "href" set to the
1495                end user's OP-Local Identifier
1496              </t>
1497            </list>
1498          </t>
1499
1500          <t>
1501            The protocol version when HTML discovery is performed is
1502            "http://specs.openid.net/auth/2.0/signon".
1503          </t>
1504
1505          <t>
1506            The host of the HTML document MAY be different from the
1507            end user's OP's host.
1508          </t>
1509
1510          <t>
1511            The "openid2.provider" and "openid2.local_id" URLs MUST NOT
1512            include entities other than "&amp;amp;", "&amp;lt;",
1513            "&amp;gt;", and "&amp;quot;". Other characters that would
1514            not be valid in the HTML document or that cannot be
1515            represented in the document's character encoding MUST be
1516            escaped using the percent-encoding (%xx) mechanism
1517            described in <xref target='RFC3986' />.
1518          </t>
1519
1520          <t>
1521            As discussed in the <xref
1522            target="compat_mode">OpenID Authentication 1.1
1523            Compatibility mode</xref> section, these discovery tags
1524            are not the same as in previous versions of the protocol.
1525            While the same data is conveyed, the names have changed which
1526            allows a Relying Party to determine the protocol version
1527            being used.  A Relying Party MAY encounter a Claimed Identifier
1528            which uses HTML-Based Discovery to advertise both version 1.1
1529            and 2.0 Providers.
1530          </t>
1531        </section>
1532      </section>
1533    </section>
1534
1535
1536    <section title="Establishing Associations" anchor="associations">
1537      <t>
1538        An association between the Relying Party and the OpenID Provider
1539        establishes a shared secret between them, which is used to verify
1540        subsequent protocol messages and reduce round trips.
1541      </t>
1542
1543      <t>
1544        It is RECOMMENDED that a Relying Party form associations if it
1545        is possible for it to do so.  If a Relying Party is incapable
1546        of creating or storing associations, <xref target="check_auth" />
1547        provides an alternate verification mechanism referred to as
1548        Stateless Mode.
1549      </t>
1550
1551      <section title="Association Session Request">
1552        <t>
1553          An association session is initiated by a <xref
1554          target="direct_comm">direct request</xref> from a Relying
1555          Party to an OP Endpoint URL with the "openid.mode" key
1556          having the value of "associate".
1557        </t>
1558
1559        <section title="Common Request Parameters" toc="exclude">
1560          <t>
1561            These parameters are common to all association requests:
1562          </t>
1563          <t>
1564            <list style="symbols">
1565              <t>openid.ns
1566              <list style='empty'>
1567                <t>
1568                  As specified in <xref target="http_encoding" />.
1569                </t>
1570              </list>
1571              </t>
1572              <t>openid.mode
1573              <list style="empty">
1574                <t> Value: "associate"</t>
1575              </list>
1576              </t>
1577
1578              <t>openid.assoc_type
1579              <list style="empty">
1580                <t> The preferred association type.  The association
1581                type defines the algorithm to be used to sign
1582                subsequent messages.</t>
1583                <t> Value: A valid association type from <xref
1584                target="assoc_types"/></t>
1585              </list>
1586              </t>
1587
1588              <t>openid.session_type
1589              <list style='empty'>
1590                <t>
1591                  The preferred association session type.  This
1592                  defines the method used to encrypt the association's
1593                  MAC key in transit.
1594                </t>
1595                <t>
1596                  Value: A valid association session type from
1597                  <xref target="assoc_sess_types"/>.
1598                </t>
1599                <t>
1600                  Note: Unless using transport layer encryption,
1601                  "no-encryption" MUST NOT be used.
1602                </t>
1603              </list>
1604              </t>
1605            </list>
1606          </t>
1607        </section>
1608
1609        <section title="Diffie-Hellman Request Parameters" toc="exclude">
1610          <t>
1611            The following parameters are common to requests whose
1612            requested association session type is "DH-SHA1" or
1613            "DH-SHA256":
1614          </t>
1615          <t>
1616            <list style="symbols">
1617              <t>
1618                openid.dh_modulus
1619                <list style='empty'>
1620                  <t>Value: base64(btwoc(p))</t>
1621                  <t>Default: See <xref target='pvalue' /></t>
1622                </list>
1623              </t>
1624              <t>
1625                openid.dh_gen
1626                <list style='empty'>
1627                  <t>Value: base64(btwoc(g))</t>
1628                  <t>Default: g = 2</t>
1629                </list>
1630              </t>
1631              <t>
1632                openid.dh_consumer_public
1633                <list style='empty'>
1634                  <t>Value: base64(btwoc(g ^ xa mod p))</t>
1635                </list>
1636              </t>
1637            </list>
1638          </t>
1639          <t>
1640            See <xref target="dh_sessions"/> for more information on
1641            these parameters.
1642          </t>
1643          <t>
1644            NOTE: The 'btwoc' function is defined in <xref
1645            target="btwoc"/>.
1646          </t>
1647        </section>
1648      </section>
1649
1650      <section title="Association Session Response">
1651        <t>
1652          An association session response is a direct response from the
1653          OP to the Relying Party in <xref target="kvform">Key-Value
1654          Form</xref>.
1655        </t>
1656
1657        <section title="Common Response Parameters">
1658          <t>
1659            <list style="symbols">
1660              <t>
1661                ns
1662                <list style="empty">
1663                  <t>
1664                    As specified in <xref target="direct_response" />.
1665                  </t>
1666                </list>
1667              </t>
1668              <t>
1669                assoc_handle
1670                <list style="empty">
1671                  <t>
1672                    The association handle is used as a key to refer
1673                    to this association in subsequent messages.
1674                  </t>
1675                  <t>
1676                    Value: A string 255 characters or less in length.
1677                    It MUST consist only of ASCII characters in the
1678                    range 33-126 inclusive (printable non-whitespace
1679                    characters).
1680                  </t>
1681                </list>
1682              </t>
1683              <t>
1684                session_type
1685                <list style="empty">
1686                  <t>
1687                    The value of the "openid.session_type" parameter
1688                    from the request.  If the OP is unwilling or
1689                    unable to support this association type, it MUST
1690                    return an <xref target="refuse_assoc">unsuccessful
1691                    response</xref>.
1692                  </t>
1693                </list>
1694              </t>
1695              <t>
1696                assoc_type
1697                <list style="empty">
1698                  <t>
1699                    The value of the "openid.assoc_type" parameter
1700                    from the request.  If the OP is unwilling or
1701                    unable to support this association type, it MUST
1702                    return an <xref target="refuse_assoc">unsuccessful
1703                    response</xref>.
1704                  </t>
1705                </list>
1706              </t>
1707              <t>
1708                expires_in
1709                <list style="empty">
1710                  <t>
1711                    The lifetime, in seconds, of this association.
1712                    The Relying Party MUST NOT use the association
1713                    after this time has passed.
1714                  </t>
1715                  <t>
1716                    Value: An integer, represented in base 10 ASCII.
1717                  </t>
1718                </list>
1719              </t>
1720            </list>
1721          </t>
1722        </section>
1723
1724        <section title="Unencrypted Response Parameters">
1725          <t>
1726            <list style="symbols">
1727              <t>
1728                mac_key
1729                <list style='empty'>
1730                  <t>
1731                    The MAC key (shared secret) for this
1732                    association, <xref target="RFC3548">Base 64</xref>
1733                    encoded.
1734                  </t>
1735                </list>
1736              </t>
1737            </list>
1738          </t>
1739        </section>
1740
1741
1742        <section title='Diffie-Hellman Response Parameters' toc="exclude">
1743          <t>
1744            <list style="symbols">
1745              <t>
1746                dh_server_public
1747                <list style='empty'>
1748                  <t>
1749                    Value: base64(btwoc(g ^ xb mod p))
1750                  </t>
1751                  <t>
1752                    Description: The OP's Diffie-Hellman public key.
1753                  </t>
1754                </list>
1755              </t>
1756              <t>
1757                enc_mac_key
1758                <list style='empty'>
1759                  <t>
1760                    Value: base64(H(btwoc(g ^ (xa * xb) mod p)) XOR MAC key)
1761                  </t>
1762                  <t>
1763                    Description: The MAC key (shared secret),
1764                    encrypted with the secret Diffie-Hellman value. H
1765                    is either "SHA1" or "SHA256" depending on the
1766                    session type.
1767                  </t>
1768                </list>
1769              </t>
1770            </list>
1771          </t>
1772          <t>
1773            NOTE: The 'btwoc' function is defined in <xref
1774            target="btwoc"/>
1775          </t>
1776        </section>
1777
1778        <section anchor="refuse_assoc"
1779                 title="Unsuccessful Response Parameters">
1780          <t>
1781            If the OP does not support a session type or association
1782            type, it MUST respond with a direct error message
1783            indicating that the association request failed. If there
1784            is another association session type or association type
1785            that is supported, the OP SHOULD include that information
1786            in the response.
1787          </t>
1788          <t>
1789            <list style='symbols'>
1790              <t>
1791                ns
1792                <list style="empty">
1793                  <t>
1794                    As specified in <xref target="direct_response" />.
1795                  </t>
1796                </list>
1797              </t>
1798              <t>
1799                error
1800                <list style='empty'>
1801                  <t>
1802                    Value: A human-readable message indicating why the
1803                    association request failed.
1804                  </t>
1805                </list>
1806              </t>
1807              <t>
1808                error_code
1809                <list style='empty'>
1810                  <t>
1811                    Value: "unsupported-type"
1812                  </t>
1813                </list>
1814              </t>
1815              <t>
1816                session_type
1817                <list style='empty'>
1818                  <t>
1819                    Value: (optional) A valid association session type
1820                    from <xref target="assoc_sess_types" /> that the
1821                    OP supports.
1822                  </t>
1823                </list>
1824              </t>
1825              <t>
1826                assoc_type
1827                <list style='empty'>
1828                  <t>
1829                    Value: (optional) An association type supported by
1830                    the OP from <xref target="assoc_types" />.
1831                  </t>
1832                </list>
1833              </t>
1834            </list>
1835          </t>
1836          <t>
1837            Upon receipt of an "unsupported-type" response, the
1838            Relying Party MAY make another request with the specified
1839            association session type and association type. If no
1840            association is established, the Relying Party MAY continue
1841            the authentication process in <xref target="check_auth">
1842            Direct Verification</xref>.
1843          </t>
1844        </section>
1845      </section>
1846
1847      <section title="Association Types" anchor="assoc_types">
1848        <section title="HMAC-SHA1">
1849          <t>
1850            An association of type "HMAC-SHA1" uses the <xref
1851            target="sign_algos">HMAC-SHA1</xref> signature algorithm.
1852          </t>
1853        </section>
1854
1855        <section title="HMAC-SHA256">
1856          <t>
1857            An association of type "HMAC-256" uses the <xref
1858            target="sign_algos">HMAC-SHA256</xref> signature
1859            algorithm.
1860          </t>
1861        </section>
1862      </section>
1863
1864      <section title="Association Session Types" anchor="assoc_sess_types">
1865        <t>
1866          OpenID Authentication defines three valid association
1867          session types: "no-encryption", "DH-SHA1", and "DH-SHA256".
1868        </t>
1869
1870        <section title="No-Encryption Association Sessions"
1871                 toc="exclude">
1872          <t>
1873            In a "no-encryption" association session, the OP sends
1874            the association MAC key in plain-text to the Relying Party.
1875            This makes it possible for an eavesdropper to intercept
1876            the key, and forge messages to this Relying Party when not
1877            using transport layer encryption.  Therefore, "no-encryption"
1878            association sessions MUST NOT be used unless the messages
1879            are using transport layer encryption. See <xref target="preventing_eavesdropping" />
1880            for more information.
1881          </t>
1882
1883          <t>
1884            The MAC key sent by the OP MUST be the length specified
1885            for the requested association type, as specified in <xref
1886            target="sign_algos" />.
1887          </t>
1888
1889        </section>
1890
1891        <section title="Diffie-Hellman Association Sessions"
1892                 anchor="dh_sessions" toc="exclude">
1893          <t>
1894            The "DH-SHA1" and "DH-SHA256" association types use
1895            Diffie-Hellman Key Exchange to securely transmit the
1896            shared secret.
1897          </t>
1898          <t>
1899            The MAC key MUST be the same length as the output of H,
1900            the hash function - 160 bits (20 bytes) for DH-SHA1 or 256
1901            bits (32 bytes) for DH-SHA256, as well as the output of
1902            the signature algorithm of this association.
1903          </t>
1904
1905          <t>
1906            The Relying Party specifies a modulus, p, and a generator,
1907            g. The Relying Party chooses a random private key xa and
1908            OpenID Provider chooses a random private key xb, both in
1909            the range [1 .. p-1]. The shared secret used to encrypt
1910            the MAC key is thus g ^ (xa * xb) mod p = (g ^ xa) ^ xb
1911            mod p = (g ^ xb) ^ xa mod p. For more information, see
1912            <xref target='RFC2631' />. For information on the
1913            selection of random values, see <xref target="RFC1750" />.
1914          </t>
1915        </section>
1916      </section>
1917    </section>
1918
1919    <section title="Requesting Authentication"
1920             anchor="requesting_authentication">
1921      <t>
1922        Once the Relying Party has successfully performed discovery
1923        and (optionally) created an association with the discovered
1924        OP Endpoint URL, it can send an authentication request to the
1925        OP to obtain an assertion. An authentication request is an
1926        <xref target="indirect_comm">indirect request</xref>.
1927      </t>
1928
1929      <section title="Request Parameters">
1930        <t>
1931          <list style='symbols'>
1932            <t>
1933              openid.ns
1934              <list style='empty'>
1935                <t>
1936                  As specified in <xref target="http_encoding" />.
1937                </t>
1938              </list>
1939            </t>
1940
1941            <t>
1942              openid.mode
1943              <list style='empty'>
1944                <t>
1945                  Value: "checkid_immediate" or "checkid_setup"
1946                </t>
1947                <t>
1948                  Note: If the Relying Party wishes the end user to be
1949                  able to interact with the OP, "checkid_setup"
1950                  should be used. An example of a situation where
1951                  interaction between the end user and the OP is not
1952                  desired is when the authentication request is
1953                  happening asynchronously in JavaScript.
1954                </t>
1955              </list>
1956            </t>
1957
1958            <t>
1959              openid.claimed_id
1960              <list style='empty'>
1961                <t>
1962                  Value: (optional) The Claimed Identifier.
1963                </t>
1964                <t>
1965                  "openid.claimed_id" and "openid.identity" SHALL
1966                  be either both present or both absent. If neither
1967                  value is present, the assertion is not about an
1968                  identifier, and will contain other information in
1969                  its payload, using
1970                  <xref target="extensions">extensions</xref>.
1971                </t>
1972                <t>
1973                  It is RECOMMENDED that OPs accept XRI identifiers
1974                  with or without the "xri://" prefix, as specified
1975                  in the <xref target="normalization">Normalization
1976                  </xref> section.
1977                </t>
1978              </list>
1979            </t>
1980
1981            <t>
1982              openid.identity
1983              <list style='empty'>
1984                <t>
1985                  Value: (optional) The OP-Local Identifier.
1986                </t>
1987                <t>
1988                  If a different OP-Local Identifier is not specified,
1989                  the claimed identifier MUST be used as the value for
1990                  openid.identity.
1991                </t>
1992                <t>
1993                  Note: If this is set to the special value
1994                  "http://specs.openid.net/auth/2.0/identifier_select"
1995                  then the OP SHOULD choose an Identifier that belongs
1996                  to the end user. This parameter MAY be omitted if
1997                  the request is not about an identifier (for instance
1998                  if an extension is in use that makes the request
1999                  meaningful without it; see openid.claimed_id above).
2000                </t>
2001              </list>
2002            </t>
2003
2004            <t>
2005              openid.assoc_handle
2006              <list style='empty'>
2007                <t>
2008                  Value: (optional) A handle for an association
2009                  between the Relying Party and the OP that SHOULD be
2010                  used to sign the response.
2011                </t>
2012                <t>
2013                  Note: If no association handle is sent, the
2014                  transaction will take place in <xref target="check_auth">
2015                  Stateless Mode</xref>.
2016                </t>
2017              </list>
2018            </t>
2019
2020            <t>
2021              openid.return_to
2022              <list style='empty'>
2023                <t>
2024                  Value: (optional) URL to which the OP SHOULD return
2025                  the User-Agent with the response indicating the
2026                  status of the request.
2027                </t>
2028                <t>
2029                  Note: If this value is not sent in the request it
2030                  signifies that the Relying Party does not wish
2031                  for the end user to be returned.
2032                </t>
2033                <t>
2034                  Note: The return_to URL MAY be used as a mechanism
2035                  for the Relying Party to attach context about the
2036                  authentication request to the authentication
2037                  response. This document does not define a mechanism
2038                  by which the RP can ensure that query parameters are
2039                  not modified by outside parties; such a mechanism
2040                  can be defined by the RP itself.
2041                </t>
2042              </list>
2043            </t>
2044
2045            <t>
2046              openid.realm
2047              <list style='empty'>
2048                <t>
2049                  Value: (optional) URL pattern the OP SHOULD ask the
2050                  end user to trust. See <xref target="realms" />.
2051                  This value MUST be sent if openid.return_to is
2052                  omitted.
2053                </t>
2054                <t>
2055                  Default: return_to URL
2056                </t>
2057              </list>
2058            </t>
2059          </list>
2060        </t>
2061      </section>
2062
2063      <section title="Realms" anchor="realms">
2064        <t>
2065          A "realm" is a pattern that represents the part of URL-space
2066          for which an OpenID Authentication request is valid. A realm
2067          is designed to give the end user an indication of the scope
2068          of the authentication request. OPs SHOULD present the realm
2069          when requesting the end user's approval for an authentication
2070          request. The realm SHOULD be used by OPs to uniquely identify
2071          Relying Parties. For example, OPs MAY use the realm to allow
2072          the end user to automate approval of authentication requests.
2073        </t>
2074
2075        <t>
2076          A realm pattern is a URL, with the following changes:
2077          <list style="symbols">
2078            <t>
2079              A realm MUST NOT contain a URI fragment
2080            </t>
2081            <t>
2082              A realm MAY contain a wild-card at the beginning of the
2083              URL authority section.  A wild-card consists of the
2084              characters "*." prepended to the DNS name in the
2085              authority section of the URL.
2086            </t>
2087          </list>
2088        </t>
2089
2090        <t>
2091          A URL matches a realm if:
2092
2093          <list style="symbols">
2094            <t>
2095              The URL scheme and port of the URL are identical to those
2096              in the realm.  See <xref target="RFC3986">RFC
2097              3986</xref>, section 3.1 for rules about URI matching.
2098            </t>
2099
2100            <t>
2101              The URL's path is equal to or a sub-directory of the
2102              realm's path.
2103            </t>
2104
2105            <t>
2106              Either:
2107              <list style="numbers">
2108                <t>
2109                  The realm's domain contains the wild-card characters
2110                  "*.", and the trailing part of the URL's domain is
2111                  identical to the part of the realm following the
2112                  "*." wildcard, or
2113                </t>
2114                <t>
2115                  The URL's domain is identical to the realm's domain
2116                </t>
2117              </list>
2118            </t>
2119          </list>
2120
2121          When present, the "openid.return_to" URL MUST match the
2122          "openid.realm", or the OP MUST return an <xref
2123          target="indirect_error">indirect error response</xref>.
2124        </t>
2125
2126        <t>
2127          It is RECOMMENDED that OPs protect their users from making
2128          assertions with overly-general realms, like http://*.com/ or
2129          http://*.co.uk/. Overly general realms can be dangerous when
2130          the realm is used for identifying a particular Relying
2131          Party. Whether a realm is overly-general is at the
2132          discretion of the OP.
2133        </t>
2134
2135        <section title="Using the Realm for Return URL Verification"
2136                 anchor="return_to_verification">
2137          <t>
2138            OpenID providers SHOULD verify that the return_to URL
2139            specified in the request is an OpenID relying party
2140            endpoint. To verify a return_to URL, obtain the relying
2141            party endpoints for the realm by performing <xref
2142            target="rp_discovery">discovery on the relying
2143            party</xref>. As always when performing discovery, the
2144            discovered URL is the URL of the last HTTP response,
2145            following redirects. If any redirects are followed when
2146            performing discovery on the realm, verification has
2147            failed. If discovery has successfuly completed, check to
2148            make sure that the return_to URL matches one of the
2149            relying party endpoints.
2150          </t>
2151          <t>
2152            A realm may contain a wildcard, and so may not be a valid
2153            URL. In that case, perform discovery on the URL obtained
2154            by substituting "www" for the wildcard in the realm.
2155          </t>
2156          <t>
2157            To match a return_to URL against a relying party endpoint,
2158            use the same rules as for matching the return_to URL
2159            against the realm, treating the relying party's endpoint
2160            URL as the realm. Relying party endpoint URLs MUST NOT
2161            contain a domain wildcard, and SHOULD be as specific as
2162            possible.
2163          </t>
2164          <t>
2165            If verification is attempted and fails, the provider
2166            SHOULD NOT send a positive assertion to that return_to
2167            URL.
2168          </t>
2169          <t>
2170            Providers MAY cache verified return_to URLs.
2171          </t>
2172        </section>
2173      </section>
2174
2175      <section title="Immediate Requests">
2176        <t>
2177          When requesting authentication, the Relying Party MAY
2178          request that the OP not interact with the end user.  In
2179          this case the OP MUST respond immediately with either an
2180          assertion that authentication is successful, or a response
2181          indicating that the request cannot be completed without
2182          further user interaction.  This is accomplished by an
2183          authentication request with "openid.mode" set to
2184          "checkid_immediate".
2185        </t>
2186      </section>
2187    </section>
2188
2189    <section title="Responding to Authentication Requests"
2190             anchor="responding_to_authentication">
2191      <t>
2192        When an authentication request comes from the User-Agent via
2193        <xref target="indirect_comm">indirect communication</xref>,
2194        the OP SHOULD determine that an authorized end user wishes to
2195        complete the authentication.  If an authorized end user wishes
2196        to complete the authentication, the OP SHOULD send a <xref
2197        target="positive_assertions">positive assertion</xref> to the
2198        Relying Party.
2199      </t>
2200      <t>
2201        Methods of identifying authorized end users and obtaining
2202        approval to return an OpenID Authentication assertion are
2203        beyond the scope of this specification.  See <xref
2204        target="rp_mitm_proxy" /> for OpenID Provider security
2205        considerations.
2206      </t>
2207      <t>
2208        If the relying party requested OP-driven identifier selection
2209        by setting "openid.identity" to
2210        "http://specs.openid.net/auth/2.0/identifier_select"
2211        and there are Identifiers for which the end user is authorized
2212        to issue authentication responses, the OP SHOULD allow the end
2213        user to choose which Identifier to use.
2214      </t>
2215      <t>
2216        If the Relying Party supplied an association handle with the
2217        authentication request, the OP SHOULD attempt to look up an
2218        association based on that handle.  If the association is
2219        missing or expired, the OP SHOULD send the
2220        "openid.invalidate_handle" parameter as part of the response
2221        with the value of the request's "openid.assoc_handle"
2222        parameter, and SHOULD proceed as if no association handle was
2223        specified.
2224      </t>
2225      <t>
2226        If no association handle is specified, the OP SHOULD use a
2227        private association for signing the response.  The OP MUST
2228        store this association and MUST respond to later requests to
2229        check the signature of the response via <xref
2230        target="check_auth">Direct Verification</xref>.
2231      </t>
2232      <t>
2233        Relying Parties SHOULD accept and verify assertions about
2234        Identifiers for which they have not requested authentication.
2235        OPs SHOULD use private associations for signing unsolicited
2236        positive assertions.
2237      </t>
2238      <t>
2239        If the "openid.return_to" value is omitted in the request, the
2240        Relying Party does not wish to receive an authentication
2241        assertion from the OP. This can be useful when using
2242        extensions to transfer data from the Relying Party to the OP.
2243      </t>
2244
2245      <section title="Positive Assertions" anchor="positive_assertions">
2246        <t>
2247          Positive assertions are <xref target="indirect_comm">
2248          indirect responses</xref> with the following fields:
2249        </t>
2250        <t>
2251          <list style='symbols'>
2252            <t>
2253              openid.ns
2254              <list style='empty'>
2255                <t>
2256                  As specified in <xref target="http_encoding" />.
2257                </t>
2258              </list>
2259            </t>
2260
2261            <t>
2262              openid.mode
2263              <list style='empty'>
2264                <t>Value: "id_res"</t>
2265              </list>
2266            </t>
2267
2268            <t>
2269              openid.op_endpoint
2270              <list style='empty'>
2271                <t>
2272                  The OP Endpoint URL.
2273                </t>
2274              </list>
2275            </t>
2276
2277            <t>
2278              openid.claimed_id
2279              <list style='empty'>
2280                <t>
2281                  Value: (optional) The Claimed Identifier.
2282                  "openid.claimed_id" and "openid.identity" SHALL
2283                  be either both present or both absent.
2284                </t>
2285                <t>
2286                  Note: The end user MAY choose to use an OP-Local
2287                  Identifier as a Claimed Identifier.
2288                </t>
2289                <t>
2290                  Note: If neither Identifier is present in the assertion,
2291                  it is not about an identifier, and will contain
2292                  other information in its payload, using <xref
2293                  target="extensions">extensions</xref>.
2294                </t>
2295              </list>
2296            </t>
2297
2298            <t>
2299              openid.identity
2300              <list style='empty'>
2301                <t>
2302                  Value: (optional) The OP-Local Identifier
2303                </t>
2304                <t>
2305                  Note: OpenID Providers MAY assist the end user in
2306                  selecting the Claimed and OP-Local Identifiers about
2307                  which the assertion is made. The openid.identity
2308                  field MAY be omitted if an extension is in use that
2309                  makes the response meaningful without it
2310                  (see openid.claimed_id above).
2311                </t>
2312              </list>
2313            </t>
2314
2315            <t>
2316              openid.return_to
2317              <list style='empty'>
2318                <t>
2319                  Value: Verbatim copy of the return_to URL parameter
2320                  sent in the request.
2321                </t>
2322              </list>
2323            </t>
2324
2325            <t>
2326              openid.response_nonce
2327              <list style='empty'>
2328                <t>
2329                  Value: A string 255 characters or less in length,
2330                  that MUST be unique to this particular successful
2331                  authentication response. The nonce MUST start with the
2332                  current time on the server, and MAY contain additional
2333                  ASCII characters in the range 33-126 inclusive
2334                  (printable non-whitespace characters), as necessary to
2335                  make each response unique. The date and time MUST be
2336                  formatted as specified in section 5.6 of
2337                  <xref target="RFC3339" />, with the following restrictions:
2338
2339                  <list style="symbols">
2340                    <t>
2341                      All times must be in the UTC
2342                      timezone, indicated with a "Z".
2343                    </t>
2344                    <t>
2345                      No fractional seconds are allowed
2346                    </t>
2347                  </list>
2348
2349                  For example: 2005-05-15T17:11:51ZUNIQUE
2350                </t>
2351              </list>
2352            </t>
2353
2354            <t>
2355              openid.invalidate_handle
2356              <list style='empty'>
2357                <t>
2358                  Value: (optional) If the Relying Party sent an
2359                  invalid association handle with the request, it
2360                  SHOULD be included here.
2361                </t>
2362              </list>
2363            </t>
2364
2365            <t>
2366              openid.assoc_handle
2367              <list style='empty'>
2368                <t>
2369                  Value: The handle for the association that was used
2370                  to sign this assertion.
2371                </t>
2372              </list>
2373            </t>
2374
2375            <t>
2376              openid.signed
2377              <list style='empty'>
2378                <t>
2379                  Value: Comma-separated list of signed fields.
2380                </t>
2381                <t>
2382                  Note: This entry consists of the fields without the
2383                  "openid." prefix that the signature covers. This
2384                  list MUST contain at least "op_endpoint",
2385                  "return_to" "response_nonce" and "assoc_handle", and
2386                  if present in the response, "claimed_id" and
2387                  "identity". Additional keys MAY be signed as part of
2388                  the message. See <xref
2389                  target="generating_signatures">Generating
2390                  Signatures</xref>.
2391                </t>
2392                <t>
2393                  For example,
2394                  "op_endpoint,identity,claimed_id,return_to,assoc_handle,response_nonce".
2395                </t>
2396              </list>
2397            </t>
2398
2399            <t>
2400              openid.sig
2401              <list style='empty'>
2402                <t>
2403                  Value: Base 64 encoded signature calculated as
2404                  specified in <xref target="generating_signatures"/>.
2405                </t>
2406              </list>
2407            </t>
2408
2409          </list>
2410
2411        </t>
2412      </section>
2413
2414      <section title="Negative Assertions" anchor="negative_assertions">
2415        <t>
2416          If the OP is unable to identify the end user or the end
2417          user does not or cannot approve the authentication request,
2418          the OP SHOULD send a negative assertion to the Relying
2419          Party as an <xref target="indirect_comm">indirect
2420          response</xref>.
2421        </t>
2422
2423        <t>
2424          When receiving a negative assertion in response to a
2425          "checkid_immediate" mode request, Relying Parties SHOULD
2426          construct a new authentication request using "checkid_setup"
2427          mode. Details about how this differs from OpenID
2428          Authentication 1.1 can be found in <xref
2429          target="compat_mode" />.
2430        </t>
2431
2432        <section title="In Response to Immediate Requests">
2433          <t>
2434            If the request was an immediate request, there is no chance
2435            for the end user to interact with pages on the OP to provide
2436            identifying credentials or approval of a request.
2437            A negative assertion of an immediate request takes the
2438            following form:
2439            <list style='symbols'>
2440              <t>
2441                openid.ns
2442                <list style='empty'>
2443                  <t>
2444                    As specified in <xref target="http_encoding" />.
2445                  </t>
2446                </list>
2447              </t>
2448              <t>
2449                openid.mode
2450                <list style='empty'>
2451                  <t>Value: "setup_needed"</t>
2452                </list>
2453              </t>
2454            </list>
2455          </t>
2456        </section>
2457
2458        <section title="In Response to Non-Immediate Requests">
2459          <t>
2460            Since the OP may display pages to the end user and
2461            request credentials from the end user, a negative response
2462            to a request that is not immediate is definitive.  It
2463            takes the following form:
2464
2465            <list style='symbols'>
2466              <t>
2467                openid.ns
2468                <list style='empty'>
2469                  <t>
2470                    As specified in <xref target="http_encoding" />.
2471                  </t>
2472                </list>
2473              </t>
2474              <t>
2475                openid.mode
2476                <list style='empty'>
2477                  <t>
2478                    Value: "cancel"
2479                  </t>
2480                </list>
2481              </t>
2482            </list>
2483          </t>
2484
2485          <t>
2486            Often, if the user does not wish to or cannot complete the
2487            authentication request, the OpenID authentication process
2488            will be aborted and the Relying Party will not get a
2489            cancel mode response (the end user may quit or press the
2490            back button in their User-Agent instead of continuing).
2491            If a RP receives the "cancel" response, authentication was
2492            unsuccessful and the RP MUST treat the end user as
2493            non-authenticated.
2494          </t>
2495        </section>
2496      </section>
2497    </section>
2498
2499    <section title="Verifying Assertions" anchor="verification">
2500      <t>
2501        When the Relying Party receives a positive assertion, it MUST
2502        verify the following before accepting the assertion:
2503
2504        <list style="symbols">
2505          <t>
2506            The value of "openid.return_to" matches the URL of the
2507            current request (<xref target="verify_return_to" />)
2508          </t>
2509          <t>
2510            Discovered information matches the information in the
2511            assertion (<xref target="verify_disco" />)
2512          </t>
2513          <t>
2514            An assertion has not yet been accepted from this OP with
2515            the same value for "openid.response_nonce" (<xref
2516            target="verify_nonce" />)
2517          </t>
2518          <t>
2519            The signature on the assertion is valid and all fields
2520            that are required to be signed are signed (<xref
2521            target="verifying_signatures" />)
2522          </t>
2523        </list>
2524
2525        If all four of these conditions are met, assertion is now
2526        verified. If the assertion contained a Claimed Identifier, the
2527        user is now authenticated with that identifier.
2528      </t>
2529
2530      <section title="Verifying the Return URL" anchor="verify_return_to">
2531        <t>
2532          To verify that the "openid.return_to" URL matches the URL
2533          that is processing this assertion:
2534
2535          <list style="symbols">
2536            <t>
2537              The URL scheme, authority, and path MUST be the same
2538              between the two URLs.
2539            </t>
2540            <t>
2541              Any query parameters that are present in the
2542              "openid.return_to" URL MUST also be present with the
2543              same values in the URL of the HTTP request the RP
2544              received.
2545            </t>
2546          </list>
2547        </t>
2548      </section>
2549
2550      <section title="Verifying Discovered Information" anchor="verify_disco">
2551        <t>
2552          If the Claimed Identifier in the assertion is a URL and
2553          contains a fragment, the fragment part and the fragment
2554          delimiter character "#" MUST NOT be used for the purposes
2555          of verifying the discovered information.
2556        </t>
2557
2558        <t>
2559          If the Claimed Identifier is included in the assertion, it
2560          MUST have been <xref target="discovery">discovered</xref> by
2561          the Relying Party and the information in the assertion MUST
2562          be present in the discovered information. The Claimed
2563          Identifier MUST NOT be an OP Identifier.
2564        </t>
2565
2566        <t>
2567          If the Claimed Identifier was not previously discovered
2568          by the Relying Party (the "openid.identity" in the request
2569          was "http://specs.openid.net/auth/2.0/identifier_select" or
2570          a different Identifier, or if the OP is sending an unsolicited
2571          positive assertion), the Relying Party MUST perform discovery
2572          on the Claimed Identifier in the response to make sure that
2573          the OP is authorized to make assertions about the Claimed
2574          Identifier.
2575        </t>
2576
2577        <t>
2578          If no Claimed Identifier is present in the response, the
2579          assertion is not about an identifier and the RP MUST NOT use
2580          the User-supplied Identifier associated with the current
2581          OpenID authentication transaction to identify the user.
2582          Extension information in the assertion MAY still be used.
2583        </t>
2584
2585        <texttable title="Discovered Information to Authentication Response Mapping">
2586          <ttcol align='left'>Discovered Value</ttcol>
2587          <ttcol align='left'>Response Field</ttcol>
2588
2589          <c>Claimed Identifier</c>
2590          <c>openid.claimed_id</c>
2591
2592          <c>OP-Local Identifier</c>
2593          <c>openid.identity</c>
2594
2595          <c>OP Endpoint URL</c>
2596          <c>openid.op_endpoint</c>
2597
2598          <c>Protocol Version</c>
2599          <c>openid.ns</c>
2600          <postamble>
2601            This table shows the mapping of <xref
2602            target="discovered_info">discovered information</xref>
2603            into fields in the <xref
2604            target="positive_assertions">OpenID Authentication 2.0
2605            "id_res" response</xref>
2606          </postamble>
2607        </texttable>
2608
2609        <t>
2610          If using a discovery mechanism that yields an XRDS document,
2611          the protocol version, OP Endpoint URL and the OP-Local
2612          Identifier (if different than the Claimed Identifier) MUST
2613          be present in one &lt;xrd:Service&gt; element. There MAY be
2614          unused fields in that &lt;xrd:Service&gt; element.
2615        </t>
2616
2617        <figure>
2618          <preamble>Non-normative example:</preamble>
2619          <artwork><![CDATA[
2620<Service xmlns="xri://$xrd*($v*2.0)">
2621  <Type>http://specs.openid.net/auth/2.0/signon</Type>
2622  <URI>http://provider.example.com/openid</URI>
2623  <URI>https://provider.example.com/openid</URI>
2624</Service>
2625          ]]></artwork>
2626          <postamble>
2627            In this example XRDS snippet, the &lt;xrd:Service&gt;
2628            element has two &lt;xrd:URI&gt; elements, which map to OP
2629            Endpoint URLs as per <xref target="discovered_info" />. If
2630            an assertion has either value for "openid.op_endpoint",
2631            then that field matches this &lt;xrd:Service&gt;
2632            element. The other &lt;xrd:URI&gt; element is unused.
2633          </postamble>
2634        </figure>
2635
2636      </section>
2637
2638      <section title="Checking the Nonce" anchor="verify_nonce">
2639        <t>
2640          To prevent replay attacks, the agent checking the signature
2641          keeps track of the nonce values included in positive
2642          assertions and never accepts the same value more than once
2643          for the same OP Endpoint URL.
2644        </t>
2645        <t>
2646          <list style="symbols">
2647            <t>
2648              When using "check_authentication", the OP MUST NOT issue
2649              more than one successful response to a request with the
2650              same value for "openid.response_nonce".
2651            </t>
2652            <t>
2653              When the Relying Party checks the signature on an
2654              assertion, the Relying Party SHOULD ensure that an
2655              assertion has not yet been accepted with the same value
2656              for "openid.response_nonce" from the same OP Endpoint
2657              URL.
2658            </t>
2659          </list>
2660        </t>
2661        <t>
2662          The time-stamp MAY be used to reject responses that are too
2663          far away from the current time, limiting the amount of time
2664          that nonces must be stored to prevent attacks. The
2665          acceptable range is out of the scope of this
2666          specification. A larger range requires storing more nonces
2667          for a longer time. A shorter range increases the chance that
2668          clock-skew and transaction time will cause a spurious
2669          rejection.
2670        </t>
2671      </section>
2672
2673      <section title="Verifying Signatures"
2674               anchor="verifying_signatures">
2675        <t>
2676          If the Relying Party has stored an association with the
2677          association handle specified in the assertion, it MUST check
2678          the signature on the assertion itself. If it does not have
2679          an association stored, it MUST request that the OP verify
2680          the signature via <xref target="check_auth">Direct
2681          Verification</xref>.
2682        </t>
2683
2684        <section title="Verifying with an Association" toc="exclude">
2685          <t>
2686            The Relying Party follows the same procedure that the
2687            OP followed in <xref target= "generating_signatures">
2688            generating the signature</xref>, and then compares the
2689            signature in the response to the signature it
2690            generated. If the signatures do not match, the assertion
2691            is invalid.
2692          </t>
2693
2694          <t>
2695            If an authentication request included an association
2696            handle for an association between the OP and the Relying
2697            party, and the OP no longer wishes to use that handle
2698            (because it has expired or the secret has been
2699            compromised, for instance), the OP will send a response
2700            that must be verified directly with the OP, as specified
2701            in <xref target="check_auth" />. In that instance, the OP
2702            will include the field "openid.invalidate_handle" set to
2703            the association handle that the Relying Party included
2704            with the original request.
2705          </t>
2706        </section>
2707
2708        <section title="Verifying Directly with the OpenID Provider"
2709                 toc="exclude" anchor="check_auth">
2710          <t>
2711            To have the signature verification performed by the OP,
2712            the Relying Party sends a <xref target="direct_request">
2713            direct request</xref> to the OP. To verify the signature,
2714            the OP uses a private association that was generated when
2715            it issued the <xref target="positive_assertions">
2716            positive assertion</xref>.
2717          </t>
2718
2719          <section title='Request Parameters' toc="exclude">
2720            <t>
2721              <list style='symbols'>
2722                <t>
2723                  openid.mode
2724                  <list style='empty'>
2725                    <t>Value: "check_authentication"</t>
2726                  </list>
2727                </t>
2728
2729                <t>
2730                  Exact copies of all fields from the authentication
2731                  response, except for "openid.mode".
2732                </t>
2733              </list>
2734            </t>
2735
2736            <t>
2737              For verifying signatures an OP MUST only use private
2738              associations and MUST NOT use associations that have
2739              shared keys. If the verification request contains a
2740              handle for a shared association, it means the Relying
2741              Party no longer knows the shared secret, or an entity
2742              other than the RP (e.g. an attacker) has established
2743              this association with the OP.
2744            </t>
2745
2746            <t>
2747              To prevent replay attacks, the OP MUST NOT issue more
2748              than one verification response for each authentication
2749              response it had previously issued. An authentication
2750              response and its matching verification request may
2751              be identified by their "openid.response_nonce" values.
2752            </t>
2753
2754          </section>
2755
2756          <section title='Response Parameters' toc="exclude">
2757            <t>
2758              <list style='symbols'>
2759                <t>
2760                  ns
2761                  <list style='empty'>
2762                    <t>
2763                      As specified in <xref target="direct_response" />.
2764                    </t>
2765                  </list>
2766                </t>
2767
2768                <t>
2769                  is_valid
2770                  <list style='empty'>
2771                    <t>
2772                      Value: "true" or "false"; asserts whether the
2773                      signature of the verification request is valid.
2774                    </t>
2775                  </list>
2776                </t>
2777
2778                <t>
2779                  invalidate_handle
2780                  <list style='empty'>
2781                    <t>
2782                      Value: (optional) The "invalidate_handle" value
2783                      sent in the verification request, if the OP confirms
2784                      it is invalid.
2785                    </t>
2786                    <t>
2787                      Description: If present in a verification response
2788                      with "is_valid" set to "true", the Relying Party
2789                      SHOULD remove the corresponding association from its
2790                      store and SHOULD NOT send further authentication
2791                      requests with this handle.
2792                    </t>
2793                    <t>
2794                      Note: This two-step process for invalidating
2795                      associations is necessary to prevent an attacker
2796                      from invalidating an association at will by adding
2797                      "invalidate_handle" parameters to an authentication
2798                      response.
2799                    </t>
2800                  </list>
2801                </t>
2802              </list>
2803            </t>
2804          </section>
2805        </section>
2806      </section>
2807
2808      <section title="Identifying the end user" anchor="identifying">
2809        <t>
2810          The Claimed Identifier in a successful authentication
2811          response SHOULD be used by the Relying Party as a key for
2812          local storage of information about the user. The Claimed
2813          Identifier MAY be used as a user-visible Identifier. When
2814          displaying URL Identifiers, the fragment MAY be omitted.
2815        </t>
2816
2817        <section title="Identifier Recycling" anchor="identifier_recycling">
2818          <t>
2819            OpenID Providers with large user bases can use fragments
2820            to recycle URL Identifiers if it is so desired. When
2821            reassigning a URL Identifier to a new end user OPs should
2822            generate a new, unique fragment part.
2823          </t>
2824          <t>
2825            The full URL with the fragment part constitutes the Claimed
2826            Identifier in positive assertions, therefore Relying Parties
2827            will distinguish between the current and previous owners of
2828            the fragment-less URL.
2829          </t>
2830          <t>
2831            This mechanism allows the (presumably short, memorable)
2832            recycled URL Identifiers without the fragment to be used by
2833            end users at login time and by Relying Parties for display
2834            purposes.
2835          </t>
2836        </section>
2837
2838        <section title="HTTP and HTTPS URL Identifiers" anchor="http_s_identifiers">
2839          <t>
2840            Relying Parties MUST differentiate between URL Identifiers
2841            that have different schemes. When end user input is
2842            processed into a URL, it is processed into a HTTP URL. If
2843            the same end user controls the same URL, differing only by
2844            scheme, and it is desired that the Identifier be the HTTPS
2845            URL, it is RECOMMENDED that a redirect be issued from the
2846            HTTP URL to the HTTPS URL. Because the HTTP and HTTPS URLs
2847            are not equivalent and the Identifier that is used is the
2848            URL after following redirects, there is no foreseen
2849            reduction in security when using this scheme. If an
2850            attacker could gain control of the HTTP URL, it would have
2851            no effect on the HTTPS URL, since the HTTP URL is not ever
2852            used as an Identifier except to initiate the discovery
2853            process.
2854          </t>
2855        </section>
2856      </section>
2857    </section>
2858
2859    <section title="Extensions" anchor="extensions">
2860      <t>
2861        An Extension to OpenID Authentication is a protocol that
2862        "piggybacks" on the authentication request and response. Extensions
2863        are useful for providing extra information about an
2864        authentication request or response as well as providing extra
2865        information about the subject of the authentication response.
2866      </t>
2867
2868      <t>
2869        OpenID extensions are identified by a Type URI. The Type URI
2870        MAY be used as the value of an &lt;xrd:Type&gt; element of an
2871        OpenID &lt;xrd:Service&gt; element in an XRDS document
2872        associated with a Claimed Identifier.  The Type URI is also
2873        used to associate key-value pairs in messages with the extension.
2874      </t>
2875
2876      <t>
2877        <!-- XXX: openid. only for indirect messages -->
2878        To associate keys and values in a message with an extension,
2879        the key MUST be associated with the Type URI. To associate
2880        keys with a Type URI, establish an alias by adding a key
2881        prefixed with "openid.ns." and ending with the alias text
2882        whose value is the Type URI. Once an alias has been
2883        established, all pairs in the message whose keys start with
2884        "openid." followed by the alias text, followed by a period or
2885        the end of the key are associated with that extension.
2886        This mechanism is similar to the XML namespaces.
2887      </t>
2888
2889      <t>
2890        A namespace alias MUST NOT contain a period and MUST NOT be
2891        the same as another namespace alias in the same message. A
2892        namespace alias also MUST NOT be in the following list of
2893        disallowed aliases:
2894
2895        <list style="symbols">
2896          <t>assoc_handle</t>
2897          <t>assoc_type</t>
2898          <t>claimed_id</t>
2899          <t>contact</t>
2900          <t>delegate</t>
2901          <t>dh_consumer_public</t>
2902          <t>dh_gen</t>
2903          <t>dh_modulus</t>
2904          <t>error</t>
2905          <t>identity</t>
2906          <t>invalidate_handle</t>
2907          <t>mode</t>
2908          <t>ns</t>
2909          <t>op_endpoint</t>
2910          <t>openid</t>
2911          <t>realm</t>
2912          <t>reference</t>
2913          <t>response_nonce</t>
2914          <t>return_to</t>
2915          <t>server</t>
2916          <t>session_type</t>
2917          <t>sig</t>
2918          <t>signed</t>
2919          <t>trust_root</t>
2920        </list>
2921
2922        A namespace MUST NOT be assigned more than one alias in the
2923        same message. If a message is a response to another message,
2924        the response MAY use a different alias to refer to the same
2925        namespace.
2926      </t>
2927
2928      <t>Non-normative example:</t>
2929      <t>An extension's type URI is
2930      "&lt;http://example.com/ext/1.0&gt;".
2931
2932      <list style="empty">
2933        <t>openid.ns.x=http://example.com/ext/1.0</t>
2934        <t>openid.x=example</t>
2935        <t>openid.x.foo=bar</t>
2936        <t>openid.xx=notx</t>
2937      </list>
2938
2939      In this example, the keys "openid.x" and "openid.x.foo" are
2940      associated with the extension; the "openid.xx" key is not.
2941      </t>
2942
2943      <t>
2944        Extensions MUST NOT define multiple parameters with the same name.
2945        Extensions that need to send multiple values for the same parameter
2946        name must define their own conventions for doing so.
2947      </t>
2948    </section>
2949
2950    <section title="Discovering OpenID Relying Parties" anchor="rp_discovery">
2951      <t>
2952        Relying Party discovery allows for software agents to discover
2953        sites that support OpenID. It also allows OpenID providers to
2954        automatically verify that a return_to URL in an OpenID request
2955        is an OpenID relying party endpoint for the specified realm.
2956      </t>
2957
2958      <t>
2959        Relying Parties SHOULD use the Yadis protocol to publish their
2960        valid return_to URLs. The relying party MAY publish this
2961        information at any URL, and SHOULD publish it under the realm
2962        so that providers can verify return_to URLs.
2963      </t>
2964
2965      <t>
2966        A Relying Party discovery XRDS document MUST contain one or more
2967        &lt;xrd:Service&gt; elements:
2968
2969        <list style="symbols">
2970          <t>
2971            Containing at least one &lt;xrd:URI&gt; element.
2972          </t>
2973          <t>
2974            Where all &lt;xrd:URI&gt; tags contain a URL that accepts
2975            OpenID 2.0 Authentication responses.
2976          </t>
2977          <t>
2978            Containing a &lt;xrd:Type&gt; tag whose content is
2979            "http://specs.openid.net/auth/2.0/return_to".
2980          </t>
2981        </list>
2982      </t>
2983
2984      <figure>
2985        <preamble>Non-normative example:</preamble>
2986        <artwork><![CDATA[
2987<Service xmlns="xri://$xrd*($v*2.0)">
2988  <Type>http://specs.openid.net/auth/2.0/return_to</Type>
2989  <URI>http://consumer.example.com/return</URI>
2990</Service>
2991        ]]></artwork>
2992      </figure>
2993    </section>
2994
2995    <section title="OpenID Authentication 1.1 Compatibility"
2996             anchor="compat_mode">
2997
2998      <t>
2999        This section describes how to interact with OpenID
3000        Authentication 1.1 Relying Parties and OPs. OpenID
3001        Authentication 2.0 implementations SHOULD support OpenID
3002        Authentication 1.1 compatibility, unless security
3003        considerations make it undesirable.
3004      </t>
3005
3006      <section title="Changes from OpenID Authentication 1.1" >
3007        <t>
3008          (non-normative)
3009        </t>
3010        <t>
3011          This specification is based on the original specification for
3012          OpenID Authentication as written by Brad Fitzpatrick. That
3013          specification did not have a version number, but was called
3014          OpenID 1.0, and then OpenID 1.1 when it was revised.  The
3015          protocol outlined in this specification is intended to be
3016          backwards-compatible with the revised OpenID protocol.  The
3017          changes to the specification are outlined in this section.
3018        </t>
3019
3020        <section title="Updated Initiation and Discovery">
3021          <t>
3022            <list style="symbols">
3023              <t>
3024                Supports OP Identifiers. This new variation of the
3025                protocol flow is initiated by an end user entering an OP
3026                Identifier instead of their own Identifier.  This allows
3027                the OP to assist the end user in selecting an
3028                Identifier.
3029              </t>
3030              <t>
3031                Supports the use of XRIs as Identifiers. XRIs may be
3032                used as Identifiers for both end users and OPs, and
3033                provide automatic mapping from one or more reassignable
3034                i-names to a synonymous persistent Canonical ID that
3035                will never be reassigned.
3036              </t>
3037              <t>
3038                When URLs are used as Identifiers, they are normalized
3039                according to the guidelines in <xref target='RFC3986' />,
3040                for better compatibility with the existing Web infrastructure.
3041              </t>
3042              <t>
3043                Uses the Yadis protocol for discovery. This allows for
3044                using multiple OPs for a single Identifier, for
3045                load-balancing and fallback in the case of OP
3046                failure. Additionally, it allows for discovery of
3047                supported extensions and other associated services.
3048              </t>
3049            </list>
3050          </t>
3051        </section>
3052
3053        <section title="Security improvements">
3054          <t>
3055            A nonce is now part of the protocol for built-in protection
3056            against replay attacks, which was previously implemented
3057            out-of-band by each library or application.
3058          </t>
3059          <t>
3060            A new association type, HMAC-SHA256, and a new association
3061            session type, DH-SHA256, allow for stronger signatures on
3062            authentication assertions.
3063          </t>
3064          <t>
3065            An actual <xref target="security_considerations">Security
3066            Considerations section</xref> which looks at protecting
3067            the protocol from end-to-end.
3068          </t>
3069        </section>
3070
3071        <section title="Extensions">
3072          <t>
3073            Extensions are now an officially supported mechanism to
3074            support data exchange and other Relying Party-OP
3075            communication along with the authentication
3076            exchange. Extensions allow for the exchange of arbitrary
3077            attributes, as well as for protocol extensions,
3078            such as the inclusion of additional information about the
3079            Relying Party in the authentication request.
3080          </t>
3081          <t>
3082            Because extensions can transfer arbitrary data, the
3083            Identifier is now optional in authentication messages.
3084          </t>
3085        </section>
3086      </section>
3087
3088      <section title="Implementing OpenID Authentication 1.1 Compatibility">
3089        <t>
3090          All messages in OpenID Authentication 1.1 omit the
3091          "openid.ns" parameter, which is an easy way for an RP to
3092          determine if the message is from an OpenID Authentication
3093          1.1 endpoint. OpenID Authentication 1.1 supports only
3094          HMAC-SHA1 associations.
3095        </t>
3096
3097        <t>
3098          Error responses in OpenID Authentication 1.1 did not define
3099          "contact" or "reference". OpenID Authentication 1.1 did
3100          allow for the addition of extra fields in error
3101          responses. It is RECOMMENDED for contact and reference to be
3102          sent even when using OpenID Authentication 1.1, since they
3103          may be useful for debugging and do not affect compatibility.
3104        </t>
3105
3106        <section title="Relying Parties">
3107          <t>
3108            <list style="symbols">
3109              <t>
3110                When HTML discovery is performed, the OP endpoint URL
3111                is marked by the link relationship "openid.server"
3112                rather than "openid2.provider". The end user's
3113                OP-Local Identifier is marked by the link relationship
3114                "openid.delegate" rather than "openid2.local_id".  The
3115                protocol version is in this case
3116                "http://openid.net/signon/1.1". HTML allows multiple
3117                link relationships to be specified for a single link,
3118                so if an OP provides both OpenID Authentication 1.1
3119                and OpenID Authentication 2.0, "openid2.provider" and
3120                "openid.server" may appear in the same "rel"
3121                attribute.
3122              </t>
3123
3124              <t>
3125                When XRDS-based discovery is performed, the end user's
3126                OP-Local Identifier appears in the
3127                &lt;openid:Delegate&gt; tag of the OpenID
3128                &lt;xrd:Service&gt; element rather than in the
3129                &lt;xrd:LocalID&gt; tag. In order to support
3130                currently-deployed discovery code, both tags MAY
3131                appear in the &lt;xrd:Service&gt; element.
3132              </t>
3133
3134              <t>
3135                Relying Parties SHOULD extract and use OpenID
3136                Authentication 1.x service elements from XRDS
3137                documents, if Yadis succeeds on an URL
3138                Identifier. Such service elements are identified by
3139                &lt;xrd:Type&gt; tags whose text contents are
3140                "http://openid.net/server/1.0" or
3141                "http://openid.net/server/1.1".  Although this is not
3142                specified in the previous version of the protocol, it
3143                is a generally accepted practice of advertising OpenID
3144                Authentication 1.x services through Yadis.
3145              </t>
3146
3147              <t>
3148                "openid.claimed_id" is not defined by OpenID
3149                Authentication 1.1. Relying Parties MAY send the value
3150                when making requests, but MUST NOT depend on the value
3151                being present in authentication responses. When the
3152                OP-Local Identifier ("openid.identity") is
3153                different from the Claimed Identifier, the Relying
3154                Party MUST keep track of what Claimed Identifier was
3155                used to discover the OP-Local Identifier, for
3156                example by keeping it in session state. Although the
3157                Claimed Identifier will not be present in the
3158                response, it MUST be used as the identifier for the
3159                user.
3160              </t>
3161
3162              <t>
3163                "openid.identity" MUST be sent in a <xref
3164                target="responding_to_authentication">authentication
3165                request</xref>.
3166              </t>
3167
3168              <t>
3169                Relying Parties MUST send a blank session_type parameter
3170                in "no-encryption" association requests.
3171              </t>
3172
3173              <t>
3174                In OpenID Authentication 1.1, the "no-encryption"
3175                association session type is represented by a blank or
3176                missing "openid.session_type" parameter. Relying
3177                Parties MUST NOT send requests with
3178                "openid.session_type" set to "no-encryption".
3179              </t>
3180
3181              <t>
3182                In <xref
3183                target="requesting_authentication">authentication
3184                requests</xref>, the "openid.identity" parameter
3185                SHOULD NOT be the special value
3186                "http://specs.openid.net/auth/2.0/identifier_select",
3187                because OpenID Authentication 1.1 does not support the
3188                use of OP Identifiers.
3189              </t>
3190
3191              <t>
3192                The "openid.realm" parameter in authentication requests
3193                was known as "openid.trust_root". The syntax and meaning
3194                are identical.
3195              </t>
3196
3197              <t>
3198                When responding with a negative assertion to a
3199                "checkid_immediate" mode authentication request, the
3200                "user_setup_url" parameter MUST be returned. This is a
3201                URL that the end user may visit to complete the
3202                request. The OP MAY redirect the end user to
3203                this URL, or provide the end user with a link that
3204                points to this URL.
3205              </t>
3206
3207              <t>
3208                The Relying Party MUST accept an <xref
3209                target="positive_assertions">authentication
3210                response</xref> that is missing the
3211                "openid.response_nonce" parameter.  It SHOULD
3212                implement a method for preventing replay attacks.
3213              </t>
3214
3215              <t>
3216                Relying Parties MUST accept
3217                <xref target="positive_assertions">authentication responses
3218                </xref> that are missing the "openid.op_endpoint" parameter.
3219              </t>
3220            </list>
3221          </t>
3222        </section>
3223
3224        <section title="OpenID Providers">
3225          <t>
3226            <list style="symbols">
3227              <t>
3228                "openid.identity" MUST be sent in a <xref
3229                target="positive_assertions">positive authentication
3230                assertion</xref>.
3231              </t>
3232
3233              <t>
3234                In OpenID Authentication 1.1, the "no-encryption"
3235                association session type is represented by a blank or
3236                missing "openid.session_type" parameter.  OPs MUST NOT
3237                send responses with "openid.session_type" set to
3238                "no-encryption".
3239              </t>
3240
3241              <t>
3242                OPs MAY choose to return a successful "no-encryption"
3243                response to any association request. As above, the
3244                "openid.session_type" parameter MUST be blank or
3245                omitted from the response.
3246              </t>
3247
3248              <t>
3249                OPs MUST accept association requests with no assoc_type
3250                parameter, and assume them to be of type HMAC-SHA1.
3251              </t>
3252
3253              <t>
3254                Unsuccessful association attempts MAY be responded with
3255                direct error messages or with "no-encryption" positive
3256                association responses.
3257              </t>
3258
3259              <t>
3260                The "openid.realm" parameter in authentication requests
3261                was known as "openid.trust_root". The syntax and meaning
3262                are identical.
3263              </t>
3264
3265              <t>
3266                When responding with a negative assertion to a
3267                "checkid_immediate" mode authentication request, the
3268                "user_setup_url" parameter MUST be returned. This is a URL
3269                that the end user may visit to complete the request. The
3270                Relying Party may redirect the end user to this URL, or
3271                provide the end user with a link that points to this
3272                URL.
3273              </t>
3274
3275              <t>
3276                OPs MUST NOT send the "openid.op_endpoint" parameter in
3277                <xref target="positive_assertions">authentication responses
3278                </xref>, since it is not part of the OpenID Authentication
3279                1.1 protocol.
3280              </t>
3281            </list>
3282          </t>
3283        </section>
3284      </section>
3285    </section>
3286
3287    <section title="Security Considerations - セキュリティ上の問題" anchor="security_considerations">
3288      <section title="Preventing Attacks - 攻撃を防ぐ方法">
3289        <section title="Eavesdropping Attacks - 盗聴攻撃"
3290                 anchor="preventing_eavesdropping">
3291          <!--
3292              <t>
3293              There is one place in this protocol that is vulnerable
3294              to eavesdropping attacks.
3295              <list style="symbols">
3296              <t>
3297              If the nonce were not checked, an eavesdropper could also
3298              intercept a successful authentication assertion and re-use it.
3299              </t>
3300              </list>
3301              </t>
3302          -->
3303
3304          <t>
3305            このプロトコルには盗聴攻撃を受けやすい場所が一ヵ所あります。
3306            <list style="symbols">
3307              <t>
3308                もしチェックしておかないならば、盗聴者は成功した認証情報を
3309                横取りして、それを再利用します。
3310              </t>
3311            </list>
3312          </t>
3313
3314          <!--
3315              <t>
3316              This attack can be prevented by using transport layer encryption
3317              for these connections to prevent eavesdropping. In addition,
3318              if not using TLS this attack can still be prevented by
3319              checking the nonce while performing message verification.
3320              When doing so, the positive authentication assertion cannot
3321              be re-used.
3322              </t>
3323          -->
3324
3325          <t>
3326            これらの接続の盗聴されないようにTLSでトランスポート層を暗号化
3327            すれば、この攻撃を防ぐことができます。
3328            TLSによって暗号化しない場合は、メッセージ検証をその都度行う
3329            ことで盗聴攻撃を防ぐことができます。ただし、その場合は
3330            positive authentication assertionを再利用することはできません。
3331          </t>
3332
3333        </section>
3334
3335        <section title="Man-in-the-Middle Attacks">
3336          <t>
3337            Associations prevent tampering of signed fields by a man
3338            in the middle except during discovery, association
3339            sessions and <xref target="check_auth">Direct
3340            Verification</xref>. Altering signed fields without the
3341            shared secret requires breaking the MAC. Currently no
3342            tractable attack is known on the MACs used in this
3343            protocol. The quality of the protection provided by the
3344            MAC depends on the randomness of the shared MAC key, so it
3345            is important that an unguessable value be used.
3346          </t>
3347
3348          <t>
3349            If DNS resolution or the transport layer is compromised
3350            signatures on messages are not adequate, since the
3351            attacker can impersonate the OP and issue its own
3352            associations, or its own decisions in Stateless Mode. If
3353            an attacker can tamper with the discovery process they can
3354            specify any OP, and so does not have to impersonate the
3355            OP.  Additionally, if an attacker can compromise the
3356            integrity of the information returned during the discovery
3357            process, by altering the XRDS document, the need for a man
3358            in the middle is removed.  One method to prevent this sort
3359            of attack is by digitally signing the XRDS file as per
3360            <xref target="RFC3275">XMLDSIG</xref>. The keying material
3361            is not specified, since the RP ultimately needs to make
3362            its own decision whether to trust keys used for such
3363            signature.
3364          </t>
3365
3366          <t>
3367            Using SSL with certificates signed by a trusted authority
3368            prevents these kinds of attacks by verifying the results
3369            of the DNS look-up against the certificate. Once the
3370            validity of the certificate has been established,
3371            tampering is not possible. Impersonating an SSL server
3372            requires forging or stealing a certificate, which is
3373            significantly harder than the network based attacks.
3374          </t>
3375
3376          <t>
3377            In order to get protection from SSL, SSL must be used for
3378            all parts of the interaction, including interaction with
3379            the end user through the User-Agent.  While the protocol
3380            does not require SSL be used, its use is strongly
3381            RECOMMENDED.  Current best practices dictate that an OP
3382            SHOULD use SSL, with a certificate signed by a trusted
3383            authority, to secure its Endpoint URL as well as the
3384            interactions with the end user's User-Agent.  In addition,
3385            SSL, with a certificate signed by a trusted authority,
3386            SHOULD be used so that a Relying Party can fetch the end
3387            user's URL in a secure manner.  Following its own security
3388            policies, a Relying Party MAY choose to not complete, or
3389            even begin, a transaction if SSL is not being correctly
3390            used at these various endpoints.
3391          </t>
3392
3393          <section title="Rogue Relying Party Proxying" anchor="rp_mitm_proxy">
3394            <t>
3395              A special type of man-in-the-middle attack is one where
3396              the Relying Party is a rogue party acting as a MITM.  The
3397              RP would perform discovery on the End User's Claimed
3398              Identifier and instead of redirecting the User Agent to
3399              the OP, would instead proxy the OP through itself.  This
3400              would thus allow the RP to capture credentials the End
3401              User provides to the OP.  While there are multiple ways to
3402              prevent this sort of attack, the specifics are outside the
3403              scope of this document.  Each method of prevention
3404              requires that the OP establish a secure channel with the
3405              End User.
3406            </t>
3407          </section>
3408        </section>
3409      </section>
3410
3411      <section title="User-Agents">
3412        <t>
3413          Since this protocol is intended to be used interactively,
3414          User-Agents will primarily be common Web browsers. Web
3415          browsers or their hosts may be infected with spyware or
3416          other malware, which limits the strength of the
3417          authentication assertion, since untrusted software makes it
3418          impossible to know whether the authentication decision has
3419          been made with the end user's approval. With that said, many
3420          web applications and protocols today rely on the security of
3421          the Web browser and their hosts.
3422        </t>
3423
3424        <t>
3425          Cross-site-scripting attacks against OPs may be used to the
3426          same effect. For the best security, OPs should not depend
3427          on scripting.  This enables User-Agents that do not support
3428          scripting, or have scripting disabled, to still employ the
3429          protocol.
3430        </t>
3431      </section>
3432
3433      <section title="User Interface Considerations">
3434        <t>
3435          The Relying Party SHOULD redirect the end user to the OP
3436          Endpoint URL in a top-level browser window with all controls
3437          visible. This allows better protection for the end user
3438          against OP look-alike sites (phishing).
3439        </t>
3440
3441        <t>
3442          OpenID Providers SHOULD educate their end users about the
3443          potential for OpenID phishing attacks and SHOULD equip their
3444          end users with the tools to defeat such attacks, for example
3445          browser plug-ins that verify the authenticity of the OP's
3446          Authentication Service Endpoint URL.
3447        </t>
3448      </section>
3449
3450      <section title="HTTP and HTTPS URL Identifiers">
3451        <t>
3452          While these types of Identifiers have been <xref
3453          target='http_s_identifiers'>previously discussed</xref>,
3454          they are worth mentioning again.  As previously stated, the
3455          RECOMMENDED method of an End User expressing control over a
3456          URL differing only be scheme is to setup a redirect from the
3457          HTTP URL to the HTTPS URL.  Relying Parties will never store
3458          the HTTP URL as during the discovery and initiation phase
3459          will follow the redirect and use the HTTPS URL as the
3460          Claimed Identifier.
3461        </t>
3462
3463        <t>
3464          End users with concerns over this recommendation should
3465          directly enter their HTTPS URL at each Relying Party.  This
3466          thus removes the step where the Relying Party follows the
3467          redirect to the HTTPS URL.  The single security
3468          consideration currently seen is if an attacker were to
3469          compromise the integrity of the HTTP URL by removing the
3470          redirect and pointing the Identifier at a rogue OP.  This
3471          however will alter the user experience, is detectable by
3472          anti-phishing technologies, and the security of the
3473          Identifier itself is a fundamental principle within OpenID.
3474        </t>
3475      </section>
3476
3477      <section title="Denial of Service Attacks">
3478        <t>
3479          Within the protocol there are places where a rogue RP could
3480          launch a denial of service attack against an OP since there
3481          is nothing in OpenID protocol messages that allows the OP to
3482          quickly check that it is a genuine request.  This can be
3483          done by the RP repeatedly requesting associations,
3484          authentication, or verification of a signature.
3485        </t>
3486
3487        <t>
3488          The potentially most severe attack is during the association
3489          phase as each message requires the OP to execute a discrete
3490          exponentiation.  Since the RP has the ability to specify
3491          modulus and generator per message, an attacker can even
3492          force the OP to perform this exponentiation in real time
3493          prior to responding for each message.
3494        </t>
3495
3496        <t>
3497          While this could be particularly harmful, OpenID Providers
3498          can easily use generic IP based rate-limiting and banning
3499          techniques to help combat these sorts of attacks.  OPs can
3500          also look at banning requests based on the "openid.realm"
3501          and "openid.return_to" values.
3502        </t>
3503      </section>
3504
3505      <section title="Protocol Variants">
3506        <t>
3507          The following are known variations in the protocol which may
3508          or may not directly affect the security of the use of the
3509          protocol.  It is imagined that these values could be used in
3510          the creation of security profiles for this protocol.  The
3511          following list of variants are from the perspective of an
3512          OpenID Provider.
3513        </t>
3514
3515        <texttable>
3516          <ttcol align='left'>Number</ttcol>
3517          <ttcol align='left'>Variant</ttcol>
3518          <ttcol align='left'>Values</ttcol>
3519
3520          <c>1.</c>
3521          <c>
3522            Are wildcards allowed in realms?
3523          </c>
3524          <c>
3525            One of Yes/No
3526          </c>
3527
3528          <c>2.</c>
3529          <c>
3530            Require prior association?  Does the OP require the RP
3531            first create an association before requesting
3532            authentication?
3533          </c>
3534          <c>
3535            One of Yes/No
3536          </c>
3537
3538          <c>3.</c>
3539          <c>
3540            Types of claimed identifiers accepted.
3541          </c>
3542          <c>
3543            Set of HTTP/HTTPS/XRI
3544          </c>
3545
3546          <c>4.</c>
3547          <c>
3548            Are self-issued certificates allowed for authentication?
3549            This applies to all SSL traffic. If 'no' here, then OP
3550            *probably* requires all HTTPS identifiers to chain up to
3551            known trust roots, but that's intentionally not implied.
3552          </c>
3553          <c>
3554            One of Yes/No
3555          </c>
3556
3557          <c>5.</c>
3558          <c>
3559            Must the XRDS file be signed? Signature on the XRDS as per
3560            XMLDSIG. Keying material not specified, since the RP
3561            ultimately needs to make own decision whether to trust
3562            keys used for such signature.
3563          </c>
3564          <c>
3565            One of Yes/No
3566          </c>
3567
3568          <c>6.</c>
3569          <c>
3570            Must the XRDS file be retrieved over secure channel? This does not
3571            imply SSL?
3572          </c>
3573          <c>
3574            One of Yes/No
3575          </c>
3576
3577          <c>7.</c>
3578          <c>
3579            What types of session types can be used when creating
3580            associations?
3581          </c>
3582          <c>
3583            Set of no-encryption/DH-SHA1/DH-SHA256
3584          </c>
3585
3586          <c>8.</c>
3587          <c>
3588            Must the RP have an XRDS document?
3589          </c>
3590          <c>
3591            One of Yes/No
3592          </c>
3593
3594          <c>9.</c>
3595          <c>
3596            What association types the OP agrees to use for
3597            signatures?
3598          </c>
3599          <c>
3600            Set of HMAC-SHA1/HMAC-SHA256
3601          </c>
3602
3603          <c>10.</c>
3604          <c>
3605            Must the association request take place over secure channel?
3606          </c>
3607          <c>
3608            One of Yes/No
3609          </c>
3610
3611          <postamble>
3612            Identified security variants.
3613          </postamble>
3614        </texttable>
3615      </section>
3616    </section>
3617
3618    <appendix title="Examples">
3619      <t>Non-normative</t>
3620
3621      <appendix title="Normalization" anchor="normalization_example">
3622        <t>
3623          See section 6 of <xref target="RFC3986" /> for
3624          textual URL normalization details and more examples.
3625        </t>
3626        <texttable title="User's Input to Identifier Normalization">
3627          <ttcol align="left">User's Input</ttcol>
3628          <ttcol align="left">Identifier</ttcol>
3629          <ttcol align="left">Type</ttcol>
3630          <ttcol align="left">Discussion</ttcol>
3631
3632          <c>example.com</c>
3633          <c>http://example.com/</c>
3634          <c>URL</c>
3635          <c>A URI with a missing scheme is normalized to a http URI</c>
3636
3637          <c>http://example.com</c>
3638          <c>http://example.com/</c>
3639          <c>URL</c>
3640          <c>An empty path component is normalized to a slash</c>
3641
3642          <c>https://example.com/</c>
3643          <c>https://example.com/</c>
3644          <c>URL</c>
3645          <c>https URIs remain https URIs</c>
3646
3647          <c>http://example.com/user</c>
3648          <c>http://example.com/user</c>
3649          <c>URL</c>
3650          <c>No trailing slash is added to non-empty path components</c>
3651
3652          <c>http://example.com/user/</c>
3653          <c>http://example.com/user/</c>
3654          <c>URL</c>
3655          <c>Trailing slashes are preserved on non-empty path components</c>
3656
3657          <c>http://example.com/</c>
3658          <c>http://example.com/</c>
3659          <c>URL</c>
3660          <c>Trailing slashes are preserved when the path is empty</c>
3661
3662          <c>=example</c>
3663          <c>=example</c>
3664          <c>XRI</c>
3665          <c>Normalized XRIs start with a global context symbol</c>
3666
3667          <c>xri://=example</c>
3668          <c>=example</c>
3669          <c>XRI</c>
3670          <c>Normalized XRIs start with a global context symbol</c>
3671        </texttable>
3672      </appendix>
3673
3674      <appendix title="OP-Local Identifiers">
3675        <t>
3676          An end user wants to use "http://www.example.com/" as their
3677          Claimed Identifier. The end user has an account with
3678          Example Provider, which functions as an OpenID Provider.  The
3679          end user's OP-Local Identifier is
3680          "https://exampleuser.exampleprovider.com/".
3681        </t>
3682
3683        <t>
3684          In this scenario, with the proper configuration of Yadis or
3685          HTML-Based Discovery (see <xref target="discovery" /> and
3686          <xref target="XRDS_Sample" /> below), a Relying Party will
3687          discover the following information about the end user:
3688
3689          <list style="hanging">
3690            <t hangText="Claimed Identifier">
3691              http://www.example.com/
3692            </t>
3693            <t hangText="OP-Local Identifier">
3694              https://exampleuser.exampleprovider.com/
3695            </t>
3696          </list>
3697        </t>
3698      </appendix>
3699
3700      <appendix title="XRDS" anchor="XRDS_Sample">
3701        <figure>
3702          <preamble>
3703            For an end user to use "http://www.example.com/" as
3704            their Identifier, but have Relying Parties actually
3705            verify "https://exampleuser.exampleprovider.com/" with the OP
3706            Endpoint URL
3707            "https://www.exampleprovider.com/endpoint/", the
3708            following XML snippet should be present in the final XRD
3709            element in the XRDS file when discovery is preformed on
3710            "http://www.example.com/":
3711          </preamble>
3712          <artwork><![CDATA[
3713<Service xmlns="xri://$xrd*($v*2.0)">
3714  <Type>http://specs.openid.net/auth/2.0/signon</Type>
3715  <URI>https://www.exampleprovider.com/endpoint/</URI>
3716  <LocalID>https://exampleuser.exampleprovider.com/</LocalID>
3717</Service>
3718          ]]></artwork>
3719        </figure>
3720      </appendix>
3721
3722      <appendix title="HTML Identifier Markup">
3723        <figure>
3724          <preamble>
3725            To use "http://www.example.com/" as their Identifier, but have
3726            Relying Parties actually verify
3727            "http://exampleuser.livejournal.com/" with the OpenID
3728            Provider located at
3729            "http://www.livejournal.com/openid/server.bml", the
3730            following markup should be present in the &lt;head&gt;
3731            of the HTML document located by the identifier URL:
3732          </preamble>
3733          <artwork><![CDATA[
3734<link rel="openid2.provider openid.server"
3735  href="http://www.livejournal.com/openid/server.bml"/>
3736<link rel="openid2.local_id openid.delegate"
3737  href="http://exampleuser.livejournal.com/"/>
3738          ]]></artwork>
3739        </figure>
3740      </appendix>
3741
3742      <appendix title="XRI CanonicalID">
3743        <t>
3744          For example, if the XRI i-names =example and =exmpl both
3745          yield an XRDS document with the CanonicalID
3746          xri://(example)!1234 then those Identifiers should be
3747          treated as equivalent. For applications with user accounts,
3748          the persistent Canonical ID xri://(example)!1234 should be
3749          used the primary key for the account.  Although the
3750          i-names =example and =exmpl may also be stored for reference
3751          as display names, they are reassignable identifiers and
3752          should not be used as persistent keys.
3753        </t>
3754      </appendix>
3755    </appendix>
3756
3757    <appendix title='Diffie-Hellman Key Exchange Default Value' anchor="pvalue">
3758      <figure>
3759        <preamble>
3760          This is a confirmed-prime number, used as the default
3761          modulus for Diffie-Hellman Key Exchange. In hexadecimal:
3762        </preamble>
3763        <artwork><![CDATA[
3764DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61E
3765F75A2E27898B057F9891C2E27A639C3F29B60814581CD3B2CA3986D268370557
37667D45C2E7E52DC81C7A171876E5CEA74B1448BFDFAF18828EFD2519F14E45E382
37676634AF1949E5B535CC829A483B8A76223E5D490A257F05BDFF16F2FB22C583AB
3768        ]]></artwork>
3769      </figure>
3770    </appendix>
3771
3772    <!-- XXX: An example for Generating Signatures might be nice. -->
3773
3774    <appendix title="Acknowledgements">
3775      <t>
3776        The OpenID Community would like to thank the following people
3777        for the work they've done in the drafting and editing of this
3778        specification.  If you want to know the nitty gritty of who
3779        actually wrote what, feel free to look at our SVN repository
3780        or even use "svn blame". :)
3781        http://openid.net/svn/specifications/authentication/2.0/
3782      </t>
3783
3784      <t>
3785        <list style='empty'>
3786          <t>Barry Ferg (barry@sxip.com)</t>
3787          <t>Brad Fitzpatrick (brad@danga.com) &lt;author&gt;</t>
3788          <t>Carl Howells (chowells@janrain.com)</t>
3789          <t>David Recordon (david@sixapart.com) &lt;author/editor&gt;</t>
3790          <t>Dick Hardt (dick@sxip.com) &lt;author&gt;</t>
3791          <t>Drummond Reed (drummond.reed@cordance.net)</t>
3792          <t>Hans Granqvist (hgranqvist@verisign.com)</t>
3793          <t>Johannes Ernst (jernst@netmesh.us)</t>
3794          <t>Johnny Bufu (johnny@sxip.com) &lt;editor&gt;</t>
3795          <t>Josh Hoyt (josh@janrain.com) &lt;author/editor&gt;</t>
3796          <t>Kevin Turner (kevin@janrain.com)</t>
3797          <t>Marius Scurtescu (marius@sxip.com)</t>
3798          <t>Martin Atkins (mart@degeneration.co.uk)</t>
3799          <t>Mike Glover (mpg4@janrain.com)</t>
3800        </list>
3801      </t>
3802    </appendix>
3803  </middle>
3804
3805  <back>
3806    <references title='Normative References'>
3807      <reference anchor='RFC3629'>
3808        <front>
3809          <title>
3810            UTF-8, a transformation format of Unicode and ISO 10646
3811          </title>
3812          <author initials='F.Y' surname='Yergeau' fullname='Francois Yergeau'>
3813            <organization />
3814          </author>
3815        </front>
3816        <seriesInfo name="RFC" value="3629" />
3817      </reference>
3818      <reference anchor='RFC2119'>
3819        <front>
3820          <title>
3821            Key words for use in RFCs to Indicate Requirement Levels
3822          </title>
3823          <author initials='B.S' surname='Bradner' fullname='Scott Bradner'>
3824            <organization>Alis Technologies</organization>
3825          </author>
3826        </front>
3827        <seriesInfo name="RFC" value="2119" />
3828      </reference>
3829      <reference anchor='RFC3986'>
3830        <front>
3831          <title>Uniform Resource Identifiers (URI): Generic Syntax</title>
3832          <author initials='T.L' surname='Berners-Lee'
3833                  fullname='T. Berners-Lee'>
3834            <organization />
3835          </author>
3836        </front>
3837        <seriesInfo name="RFC" value="3986" />
3838      </reference>
3839      <reference anchor='RFC1750'>
3840        <front>
3841          <title>Randomness Recommendations for Security</title>
3842          <author initials='D.E' surname='Eastlake'
3843                  fullname='Donald E. Eastlake, 3rd'>
3844            <organization>Digital Equipment Corporation</organization>
3845          </author>
3846          <author initials='S.C' surname='Crocker'
3847                  fullname='Stephen D. Crocker'>
3848            <organization>CyberCash, Inc.</organization>
3849          </author>
3850          <author initials='J.S' surname='Schiller'
3851                  fullname='Jeffery I. Schiller'>
3852            <organization>Massachusetts Institute of Technology</organization>
3853          </author>
3854        </front>
3855        <seriesInfo name="RFC" value="1750" />
3856      </reference>
3857      <reference anchor='RFC2631'>
3858        <front>
3859          <title>Diffie-Hellman Key Agreement Method</title>
3860          <author initials='E.R' surname='Rescorla'
3861                  fullname='Eric Rescorla'>
3862            <organization />
3863          </author>
3864        </front>
3865        <seriesInfo name="RFC" value="2631" />
3866      </reference>
3867      <reference anchor='RFC3548'>
3868        <front>
3869          <title>The Base16, Base32, and Base64 Data Encodings</title>
3870          <author initials='S.J' surname='Josefsson'
3871                  fullname='Simon Josefsson'>
3872            <organization />
3873          </author>
3874        </front>
3875        <seriesInfo name="RFC" value="3548" />
3876      </reference>
3877      <reference anchor='RFC2104'>
3878        <front>
3879          <title>HMAC: Keyed-Hashing for Message Authentication</title>
3880          <author initials='H.K' surname='Krawczyk' fullname='Hugo Krawczyk'>
3881            <organization>IBM</organization>
3882          </author>
3883          <author initials='M.B' surname='Bellare' fullname='Mihir Bellare'>
3884            <organization>UCSD</organization>
3885          </author>
3886          <author initials='R.C' surname='Canetti' fullname='Ran Canetti'>
3887            <organization>IBM</organization>
3888          </author>
3889        </front>
3890        <seriesInfo name="RFC" value="2104" />
3891      </reference>
3892      <reference anchor='FIPS180-2'>
3893        <front>
3894          <title>Secure Hash Signature Standard</title>
3895          <author>
3896            <organization>U.S. Department of Commerce</organization>
3897          </author>
3898          <author>
3899            <organization>National Institute of Standards
3900            and Technology</organization>
3901          </author>
3902        </front>
3903        <seriesInfo name="FIPS" value="180-2" />
3904        <format type="PDF" target="http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf" />
3905        <annotation>Defines Secure Hash Algorithm 256 (SHA256)</annotation>
3906      </reference>
3907      <reference anchor='HTML401'>
3908        <front>
3909          <title>HTML 4.01 Specification</title>
3910          <author>
3911            <organization>W3C</organization>
3912          </author>
3913        </front>
3914        <format type="HTML" target="http://www.w3.org/TR/html401" />
3915      </reference>
3916      <reference anchor='RFC2616'>
3917        <front>
3918          <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
3919          <author initials='R.F' surname='Fielding' fullname='R. Fielding'>
3920            <organization>UC Irvine</organization>
3921          </author>
3922          <author initials='J.G' surname='Gettys' fullname='J. Gettys'>
3923            <organization>Compaq/W3C</organization>
3924          </author>
3925          <author initials='J.M' surname='Mogul' fullname='J. Mogul'>
3926            <organization>Compaq</organization>
3927          </author>
3928          <author initials='H.F' surname='Frystyk' fullname='H. Frystyk'>
3929            <organization>W3C/MIT</organization>
3930          </author>
3931          <author initials='L.M' surname='Masinter' fullname='L. Masinter'>
3932            <organization>Xerox</organization>
3933          </author>
3934          <author initials='P.L' surname='Leach' fullname='P. Leach'>
3935            <organization>Microsoft</organization>
3936          </author>
3937          <author initials='T.L' surname='Berners-Lee'
3938                  fullname='T. Berners-Lee'>
3939            <organization>W3C/MIT</organization>
3940          </author>
3941        </front>
3942        <seriesInfo name="RFC" value="2616" />
3943      </reference>
3944      <reference anchor='RFC3174'>
3945        <front>
3946          <title>US Secure Hash Algorithm 1 (SHA1)</title>
3947          <author initials='D.E' surname='Eastlake'
3948                  fullname='Donald E. Eastlake, 3rd'>
3949            <organization>Motorola</organization>
3950          </author>
3951          <author initials='P.J' surname='Jones' fullname='Paul E. Jones'>
3952            <organization>Cisco Systems, Inc.</organization>
3953          </author>
3954        </front>
3955        <seriesInfo name="RFC" value="3174" />
3956      </reference>
3957      <reference anchor='RFC3339'>
3958        <front>
3959          <title>Date and Time on the Internet: Timestamps</title>
3960          <author initials='G.K' surname='Klyne' fullname='Graham Klyne'>
3961            <organization>Clearswift Corporation</organization>
3962          </author>
3963          <author initials='C.N' surname='Newman'
3964                  fullname='Chris Newman'>
3965            <organization>Sun Microsystems</organization>
3966          </author>
3967        </front>
3968        <seriesInfo name="RFC" value="3339" />
3969      </reference>
3970
3971      <reference anchor="RFC3275">
3972        <front>
3973          <title>(Extensible Markup Language) XML-Signature Syntax and
3974          Processing</title>
3975          <author initials='D.E.' surname='Eastlake 3rd'
3976                  fullname='Donald E. Eastlake 3rd'>
3977            <organization>Motorola</organization>
3978          </author>
3979          <author initials='J.R.' surname='Reagle Jr.' fullname='Joseph M. Reagle Jr.'>
3980            <organization>Massachusetts Institute of
3981            Technology</organization>
3982          </author>
3983          <author initials='D.S.' surname='Solo' fullname='David
3984                                                           Solo'>
3985            <organization>Citigroup</organization>
3986          </author>
3987        </front>
3988        <seriesInfo name="RFC" value="3275" />
3989      </reference>
3990
3991      <reference anchor="XRI_Syntax_2.0"
3992                 target="http://www.oasis-open.org/committees/download.php/15376" >
3993
3994        <front>
3995          <title>Extensible Resource Identifier (XRI) Syntax V2.0</title>
3996          <author initials='D.R' surname='Reed' fullname="Drummond Reed">
3997            <organization>Cordance</organization>
3998          </author>
3999          <author initials='D.M' surname='McAlpin' fullname="Dave McAlpin">
4000            <organization>Epok</organization>
4001          </author>
4002        </front>
4003        <format type="HTML" target=
4004                "http://www.oasis-open.org/committees/download.php/15376" />
4005        <format type="PDF" target=
4006                "http://www.oasis-open.org/committees/download.php/15377" />
4007      </reference>
4008
4009      <reference anchor="XRI_Resolution_2.0"
4010                 target="http://www.oasis-open.org/committees/download.php/17293" >
4011        <front>
4012          <title>Extensible Resource Identifier (XRI) Resolution V2.0
4013          - Committee Draft 02</title>
4014          <author initials='G.W' surname='Wachob' fullname="Gabe Wachob">
4015            <organization>Visa International</organization>
4016          </author>
4017          <author initials='D.R' surname='Reed' fullname="Drummond Reed">
4018            <organization>Cordance</organization>
4019          </author>
4020          <author initials='L.C' surname='Chasen' fullname="Les Chasen">
4021            <organization>NeuStar</organization>
4022          </author>
4023          <author initials='W.T' surname='Tan' fullname="William Tan">
4024            <organization>NeuStar</organization>
4025          </author>
4026          <author initials='S.C' surname='Churchill' fullname="Steve Churchill">
4027            <organization>XDI.ORG</organization>
4028          </author>
4029        </front>
4030        <format type="HTML" target=
4031                "http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.html" />
4032        <format type="PDF" target=
4033                "http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.pdf" />
4034      </reference>
4035
4036      <reference anchor="Yadis">
4037        <front>
4038          <title>Yadis Specification 1.0</title>
4039          <author initials='J.M' surname='Miller' fullname="Joaquin Miller">
4040            <organization>NetMesh</organization>
4041          </author>
4042        </front>
4043        <format type='PDF' target="http://yadis.org/papers/yadis-v1.0.pdf" />
4044        <format type='ODT' target="http://yadis.org/papers/yadis-v1.0.odt" />
4045      </reference>
4046    </references>
4047  </back>
4048</rfc>
Note: See TracBrowser for help on using the browser.