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

Revision 6069, 157.5 kB (checked in by zigorou, 7 years ago)

Add translation of Normalize section

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