TOC 
Final specs@openid.net
 December 5, 2007


OpenID Authentication 2.0 - Final

Abstract (概要)

OpenID Authentication provides a way to prove that an end user controls an Identifier. It does this without the Relying Party needing access to end user credentials such as a password or to other sensitive information such as an email address.

OpenID認証は、エンドユーザが管理する任意のIdentifierを証明する方法を提供します。Relying Partyがエンドユーザのパスワードのようなクレデンシャルや他のE-Mailアドレス等のセンシティブな情報にアクセスする必要がありません。

OpenID is decentralized. No central authority must approve or register Relying Parties or OpenID Providers. An end user can freely choose which OpenID Provider to use, and can preserve their Identifier if they switch OpenID Providers.

OpenIDは分散的です。中央の証明機関の承認やRelying PartyやOpenID Providerを登録する必要がありません。エンドユーザは利用するOpenID Providerを自由に選ぶ事ができ、もしOpenID Providerを切り替えたとしてもそれらのIdentifierを保つ事が出来ます。

While nothing in the protocol requires JavaScript or modern browsers, the authentication scheme plays nicely with "AJAX"-style setups. This means an end user can prove their Identity to a Relying Party without having to leave their current Web page.

その手順の中ではJavaScriptやモダンブラウザを要求しませんが、認証スキームはAJAXスタイルの機構でうまくいきます。これは、エンドユーザが現在のWebページを離れる事なく、Relying PartyにIdentityを証明出来る事を意味します。

OpenID Authentication uses only standard HTTP(S) requests and responses, so it does not require any special capabilities of the User-Agent or other client software. OpenID is not tied to the use of cookies or any other specific mechanism of Relying Party or OpenID Provider session management. Extensions to User-Agents can simplify the end user interaction, though are not required to utilize the protocol.

OpenID認証は標準的なHTTP(S)リクエストとレスポンスのみを使うので、User-Agentの特別な能力や他のクライアントソフトウェアを要求しません。OpenIDはRelyng PartyやOpenID Providerのセッション管理について、Cookieや他の仕組みで束縛する事をしません。User-Agentの為の拡張ははエンドユーザの相互作用を単純にしますが、プロトコルの利用に置いて必須ではありません。

The exchange of profile information, or the exchange of other information not covered in this specification, can be addressed through additional service types built on top of this protocol to create a framework. OpenID Authentication is designed to provide a base service to enable portable, user-centric digital identity in a free and decentralized manner.

プロフィール情報の交換や、この仕様書の中で扱われない他の情報の交換は、フレームワークを作る為にこnプロトコルの上に組まれる追加サービスタイプを通して行う事が出来ます。OpenID認証は、自由で分散的な方法によるユーザ中心のデジタルアイデンティティを、移植しやすい基本サービスを提供する為に設計されています。



Table of Contents

1.  Requirements Notation and Conventions(要求される表記法と慣習)
2.  Terminology(用語)
3.  Protocol Overview(プロトコル概観)
4.  Data Formats(データ形式)
    4.1.  Protocol Messages(プロトコルメッセージ)
    4.2.  Integer Representations(整数表現)
5.  Communication Types(通信タイプ)
    5.1.  Direct Communication(直接通信)
    5.2.  Indirect Communication(間接通信)
6.  Generating Signatures(署名の生成)
    6.1.  Procedure(手順)
    6.2.  Signature Algorithms(署名アルゴリズム)
7.  Initiation and Discovery(開始と発見)
    7.1.  Initiation(開始)
    7.2.  Normalization(正規化)
    7.3.  Discovery(発見)
8.  Establishing Associations(関連付けの確立)
    8.1.  Association Session Request(関連づけセッション要求)
    8.2.  Association Session Response(関連づけセッション応答)
    8.3.  Association Types(関連づけタイプ)
    8.4.  Association Session Types(関連づけセッションタイプ)
9.  Requesting Authentication(認証の要求)
    9.1.  Request Parameters(要求のパラメータ)
    9.2.  Realms(レルム)
    9.3.  Immediate Requests(直接の要求)
10.  Responding to Authentication Requests(認証リクエストへの応答)
    10.1.  Positive Assertions(肯定表明)
    10.2.  Negative Assertions(否定表明)
11.  Verifying Assertions(表明の照合)
    11.1.  Verifying the Return URL(戻りURLの照合)
    11.2.  Verifying Discovered Information(発見した情報の照合)
    11.3.  Checking the Nonce(Nonceの確認)
    11.4.  Verifying Signatures(署名の照合)
    11.5.  Identifying the end user(エンドユーザの身元確認)
12.  Extensions(拡張)
13.  Discovering OpenID Relying Parties(OpenID Relying Partyの発見)
14.  OpenID Authentication 1.1 Compatibility(OpenID認証 1.1 互換)
    14.1.  Changes from OpenID Authentication 1.1(OpenID認証 1.1からの変更)
    14.2.  Implementing OpenID Authentication 1.1 Compatibility(OpenID認証 1.1互換の実装)
15.  Security Considerations(セキュリティ考察)
    15.1.  Preventing Attacks(攻撃の防止)
    15.2.  User-Agents
    15.3.  User Interface Considerations(ユーザインターフェースの考察)
    15.4.  HTTP and HTTPS URL Identifiers(HTTPとHTTPSのURL Identifier)
    15.5.  Denial of Service Attacks(サービス拒否攻撃)
    15.6.  Protocol Variants
Appendix A.  Examples
Appendix A.1.  Normalization
Appendix A.2.  OP-Local Identifiers
Appendix A.3.  XRDS
Appendix A.4.  HTML Identifier Markup
Appendix A.5.  XRI CanonicalID
Appendix B.  Diffie-Hellman Key Exchange Default Value
Appendix C.  Acknowledgements
16.  Normative References
§  Author's Address




 TOC 

1.  Requirements Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .).

Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.



 TOC 

2.  Terminology (用語)

Identifier:
An Identifier is either a "http" or "https" URI, (commonly referred to as a "URL" within this document), or an XRI (Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” .) [XRI_Syntax_2.0]. This document defines various kinds of Identifiers, designed for use in different contexts.
Identifierは"http"か"https"のURI(このドキュメント中では"URL"として参照されます)か、XRI (Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” .) [XRI_Syntax_2.0]です。このドキュメントは、異なる文脈の中で使う為に設計された様々な種類のIdentifierを定義します。
User-Agent:
The end user's Web browser which implements HTTP/1.1 [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” .).
HTTP/1.1 [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” .)を実装しているエンドユーザのウェブブラウザです。
Relying Party:
RP. A Web application that wants proof that the end user controls an Identifier.
RPと呼びます。エンドユーザが管理するIdentifierの証明を望むウェブアプリケーションの事です。
OpenID Provider:
OP. An OpenID Authentication server on which a Relying Party relies for an assertion that the end user controls an Identifier.
OPと呼びます。エンドユーザが管理するIdentifierの表明の為にRelying Partyが信頼するOpenID認証サーバです。
OP Endpoint URL:
The URL which accepts OpenID Authentication protocol messages, obtained by performing discovery on the User-Supplied Identifier. This value MUST be an absolute HTTP or HTTPS URL.
User-Supplied Identifier上での発見行為によって獲得された、OpenID認証のプロトコルメッセージを受け取るURLです。
OP Identifier:
An Identifier for an OpenID Provider.
OPのためのIdentifierです。
User-Supplied Identifier:
An Identifier that was presented by the end user to the Relying Party, or selected by the user at the OpenID Provider. During the initiation phase of the protocol, an end user may enter either their own Identifier or an OP Identifier. If an OP Identifier is used, the OP may then assist the end user in selecting an Identifier to share with the Relying Party.
エンドユーザによってRPに与えられたか、OPでエンドユーザに選ばれたIdentifierです。プロトコルの開始段階の間、エンドユーザは自身のIdentifierかOP Identifierのどちらか一方を記入するかもしれません。もしOP Identifierが使われたなら、OPはRPと共有する為にIdentifierを選択する事についてエンドユーザを助けるかもしれなません。
Claimed Identifier:
An Identifier that the end user claims to own; the overall aim of the protocol is verifying this claim. The Claimed Identifier is either:
エンドユーザが自分のものであると主張するIdentifierです。このプロトコルの全体にわたる狙いは、この主張が真実である事を証明する事です。Claimed Identifierは以下のいずれか一方となります。
OP-Local Identifier:
An alternate Identifier for an end user that is local to a particular OP and thus not necessarily under the end user's control.
個々のOPで局所的なエンドユーザの為の代替Identifierで、エンドユーザの管理下にある必要はありません。



 TOC 

3.  Protocol Overview (プロトコル概観)

  1. The end user initiates authentication (Initiation) by presenting a User-Supplied Identifier to the Relying Party via their User-Agent.

    エンドユーザは、User-Agentを介してRPにUser-Supplied Identifierを与える事で、認証を開始します(initiates authentication) (Initiation)

  2. After normalizing (Normalization) the User-Supplied Identifier, the Relying Party performs discovery (Discovery) on it and establishes the OP Endpoint URL that the end user uses for authentication. It should be noted that the User-Supplied Identifier may be an OP Identifier, as discussed in Section 7.3.1 (Discovered Information), which allows selection of a Claimed Identifier at the OP or for the protocol to proceed without a Claimed Identifier if something else useful is being done via an extension (Extensions).

    User-Supplied Identifierの正規化(normalizing) (Normalization)後、Rlying PartyはUser-Supplied Identifier上で発見を行い(performs discovery) (Discovery)、エンドユーザの認証に使うOP Endpoint URLを確立します。Section 7.3.1 (Discovered Information)で論じられている様に、User-Supplied IdentifierがOP Identifierであるかもしれず、OP上でのClaimed Identifierの選択か、Claimed Identifierなしでプロトコルが続行するための拡張(extension) (Extensions)による有用な何かしらが行われる事を許可する、という事に注意すべきです。

  3. (optional) The Relying Party and the OP establish an association (Establishing Associations) -- a shared secret established using Diffie-Hellman Key Exchange (Rescorla, E., “Diffie-Hellman Key Agreement Method,” .) [RFC2631]. The OP uses an association to sign subsequent messages and the Relying Party to verify those messages; this removes the need for subsequent direct requests to verify the signature after each authentication request/response.

    (任意)
    RPとOPは関連づけ(association) (Establishing Associations)を確立します -- 共有秘密鍵はDiffie-Hellman鍵交換(Diffie-Hellman Key Exchange) (Rescorla, E., “Diffie-Hellman Key Agreement Method,” .) [RFC2631]を使って確立されます。OPは以降のメッセージへの署名とRPがメッセージを照合する為に関連付けを使います; 互いの認証リクエスト/レスポンスの後の署名の照合の為に直接リクエストを続ける必要性をなくします。

  4. The Relying Party redirects the end user's User-Agent to the OP with an OpenID Authentication request (Requesting Authentication).

    RPはOpenIDの認証リクエスト(Authentication request) (Requesting Authentication)をつけてエンドユーザのUser-AgentをOPにリダイレクトします。

  5. The OP establishes whether the end user is authorized to perform OpenID Authentication and wishes to do so. The manner in which the end user authenticates to their OP and any policies surrounding such authentication is out of scope for this document.

    OPはそうであろうと期待しながら、エンドユーザがOpenID認証を行う為に正当と認められているか確かめます。OPに対してエンドユーザが信頼できると証明する方法や、そのような認証周辺のいかなる方針は、このドキュメントの範囲外です。

  6. The OP redirects the end user's User-Agent back to the Relying Party with either an assertion that authentication is approved (Positive Assertions) or a message that authentication failed (Negative Assertions).

    OPは、認証が承認された(authentication is approved) (Positive Assertions)という表明か認証が失敗した(authentication failed) (Negative Assertions)というメッセージのいずれか一方をつけて、エンドユーザのUser-AgentをRPにリダイレクトして戻します。

  7. The Relying Party verifies (Verifying Assertions) the information received from the OP including checking the Return URL, verifying the discovered information, checking the nonce, and verifying the signature by using either the shared key established during the association or by sending a direct request to the OP.

    RPはOPから受け取った情報について、Return URLの確認、発見された情報の照合、nonceの確認、関連付けで確立された共有鍵かOPへの直接要求のどちらか一方を使って署名の照合、を含めて照合(verifies) (Verifying Assertions)します。



 TOC 

4.  Data Formats (データ形式)



 TOC 

4.1.  Protocol Messages (プロトコルメッセージ)

The OpenID Authentication protocol messages are mappings of plain-text keys to plain-text values. The keys and values permit the full Unicode character set (UCS). When the keys and values need to be converted to/from bytes, they MUST be encoded using UTF-8 (Yergeau, F., “UTF-8, a transformation format of Unicode and ISO 10646,” .) [RFC3629].

OpenID認証のプロトコルメッセージはplain-textのキーをplain-textの値に対応対応づけています。キーと値は完全なUnicode文字セット(UCS)を許可します。キーと値をバイト列に(バイト列から)変換する必要があるとき、それらはUTF-8 (Yergeau, F., “UTF-8, a transformation format of Unicode and ISO 10646,” .) [RFC3629]を使ってエンコードされなければならない。

Messages MUST NOT contain multiple parameters with the same name.

メッセージは同じ名前による複数のパラメータを含んではいけません。

Throughout this document, all OpenID message parameters are REQUIRED, unless specifically marked as OPTIONAL.

このドキュメント全体で、特別に"OPTIONSL"と明記された場合を除いて、全てのOpenIDメッセージパラメータは必須です。



 TOC 

4.1.1.  Key-Value Form Encoding (Key-Valueフォームエンコーディング)

A message in Key-Value form is a sequence of lines. Each line begins with a key, followed by a colon, and the value associated with the key. The line is terminated by a single newline (UCS codepoint 10, "\n"). A key or value MUST NOT contain a newline and a key also MUST NOT contain a colon.

Key-Valueフォームによるメッセージは行の連続です。それぞれの行は後にコロンが続くキーで始まり、値がキーに関連づけられます。行は1つの改行(UCSコードポイントの10で、"\n"の事)で区切られます。キーと値には改行を含めてはならず、またキーにはコロンを含めてはなりません。

Additional characters, including whitespace, MUST NOT be added before or after the colon or newline. The message MUST be encoded in UTF-8 to produce a byte string.

空白文字を含む特別な文字は、コロンや改行の前後に付け足してはなりません。メッセージはバイト文字列を処置する為にUTF-8によってエンコードされなければなりません。

Key-Value Form encoding is used for signature calculation and for direct responses (Direct Response) to Relying Parties.

Key-Valueフォームエンコーディングは署名計算とRPへの直接レスポンス(direct responses) (Direct Response)のために使われます。



 TOC 

4.1.2.  HTTP Encoding

When a message is sent to an HTTP server, it MUST be encoded using a form encoding specified in Section 17.13.4 of [HTML401] (W3C, “HTML 4.01 Specification,” .). Likewise, if the "Content-Type" header is included in the request headers, its value MUST also be such an encoding.

メッセージがHTTPサーバに送られるとき、[HTML401] (W3C, “HTML 4.01 Specification,” .)のSection 17.13.4で述べられるフォームエンコーディングを使ってエンコードされなければなりません。さらに、もし"Content-Type"ヘッダがリクエストヘッダに含まれるなら、その値もまたそのエンコーディングでなければなりません。

All of the keys in the request message MUST be prefixed with "openid.". This prefix prevents interference with other parameters that are passed along with the OpenID Authentication message. When a message is sent as a POST, OpenID parameters MUST only be sent in, and extracted from, the POST body.

リクエストメッセージの中の全てのキーは"openid."が頭につけられていなければなりません。この接頭辞はOpenID認証メッセージとともに渡された他のパラメータとの衝突を防ぎます。メッセージがPOSTで送られたとき、OpenIDパラメータはPOSTボディの中でのみ送られるか、POSTボディからのみ取り出されなければなりません。

All messages that are sent as HTTP requests (GET or POST) MUST contain the following fields:

HTTPリクエスト(GETかPOST)として送られた全てのメッセージは以下のフィールドを含まなければならない:

This model applies to messages from the User-Agent to both the Relying Party and the OP, as well as messages from the Relying Party to the OP.

このモデルは、User-AgentからRPとOPの両方へのメッセージに加えて、RPからOPへのメッセージに対して適用します。



 TOC 

4.1.3.  Example (例)

Non-normative

The following examples encode the following information:

例では以下の情報をエンコードします:

Key     | Value
--------+---------------------------
mode    | error
error   | This is an example message

Key-Value Form encoded:

mode:error
error:This is an example message

x-www-urlencoded, as in a HTTP POST body or in a URL's query string ([RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) section 3):

x-www-urlencoded(HTTP POSTボディの中か、URLのquery string([RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) section 3)の中):

openid.mode=error&openid.error=This%20is%20an%20example%20message


 TOC 

4.2.  Integer Representations (整数表現)

Arbitrary precision integers MUST be encoded as big-endian signed two's complement binary strings. Henceforth, "btwoc" is a function that takes an arbitrary precision integer and returns its shortest big-endian two's complement representation. All integers that are used with Diffie-Hellman Key Exchange are positive. This means that the left-most bit of the two's complement representation MUST be zero. If it is not, implementations MUST add a zero byte at the front of the string.

任意精度整数は、ビッグエンディアンの符号付き2の補数バイナリ文字列としてエンコードされなければならない。今後、"btwoc"は任意精度整数を扱い最短のビッグエンディアンの2の補数表現を返す関数とする。Diffie-Hellman鍵交換で使われる全ての整数は正です。これは2の補数表現の最も左のビットがゼロでなければならない事を意味します。もしそうでないなら、実装は文字列の先頭に"0"を意味するバイト文字を付け加えなければなりません。

Non-normative example:

Base 10 number | btwoc string representation
---------------+----------------------------
0              | "\x00"
127            | "\x7F"
128            | "\x00\x80"
255            | "\x00\xFF"
32768          | "\x00\x80\x00"


 TOC 

5.  Communication Types (通信タイプ)



 TOC 

5.1.  Direct Communication (直接通信)

Direct communication is initiated by a Relying Party to an OP endpoint URL. It is used for establishing associations (Establishing Associations) and verifying authentication assertions (Verifying Directly with the OpenID Provider).

直接通信はRPによってOP Endpoint URLに向けて開始されます。関連付けの確立(establishing associations) (Establishing Associations)や、認証表明の照合(verifying authentication assertions) (Verifying Directly with the OpenID Provider)のために使われます。



 TOC 

5.1.1.  Direct Request (直接リクエスト)

The message MUST be encoded as a POST body, as specified by Section 4.1.2 (HTTP Encoding).

メッセージは、Section 4.1.2 (HTTP Encoding)によって述べられた様に、POSTボディとしてエンコードされなければなりません。

All direct requests are HTTP POSTs, and so contain the required fields listed in Section 4.1.2 (HTTP Encoding).

全ての直接リクエストはHTTP POSTであり、そのためにSection 4.1.2 (HTTP Encoding)で列挙された必須フィールドを含みます。



 TOC 

5.1.2.  Direct Response (直接レスポンス)

The body of a response to a Direct Request (Direct Request) consists of an HTTP Response body in Key-Value Form (Key-Value Form Encoding). The content-type of the response SHOULD be "text/plain".

直接リクエスト(Direct Request) (Direct Request)へのレスポンスのボディは、Key-Value Form (Key-Value Form Encoding)によるHTTPレスポンスボディで構成されます。

All Key-Value form message MUST contain the following field:

全てのKey-Valueフォームメッセージは以下のフィールドを含みます:



 TOC 

5.1.2.1.  Successful Responses (成功のレスポンス)

A server receiving a valid request MUST send a response with an HTTP status code of 200.

正当なリクエストを受け取ったサーバは、HTTP応答コードの200でレスポンスを送らなければなりません。



 TOC 

5.1.2.2.  Error Responses (エラーレスポンス)

If a request is malformed or contains invalid arguments, the server MUST send a response with a status code of 400. The response body MUST be a Key-Value Form (Key-Value Form Encoding) message with the following fields:

もしリクエストが奇形か不正な引数を含む場合、サーバは応答コードの400でレスポンスを送らなければなりません。レスポンスボディはいかに続くフィールドを付けてKey-Value Form (Key-Value Form Encoding)メッセージでなければなりません。

The OP MAY add additional fields to this response.

OPはこのレスポンスにこれ以上のフィールドを追加するかもしれません。



 TOC 

5.2.  Indirect Communication (間接通信)

In indirect communication, messages are passed through the User-Agent. This can be initiated by either the Relying Party or the OP. Indirect communication is used for authentication requests (Requesting Authentication) and authentication responses (Responding to Authentication Requests).

間接通信では、メッセージはUser-Agentを通じて渡されます。これはRPかOPのいずれか一方によって開始されます。間接通信は 認証リクエスト(authentication requests) (Requesting Authentication)認証レスポンス(authentication responses) (Responding to Authentication Requests)の為に使われます。

There are two methods for indirect communication: HTTP redirects and HTML form submission. Both form submission and redirection require that the sender know a recipient URL and that the recipient URL expect indirect messages, as specified in Section 4.1.2 (HTTP Encoding). The initiator of the communication chooses which method of indirect communication is appropriate depending on capabilities, message size, or other external factors.

間接通信の為に、HTTPリダイレクトとHTMLフォーム送信の2つの方法があります。フォーム送信とリダイレクトの両方は、送信者が受領者URLを知っていて、受領者URLがSection 4.1.2 (HTTP Encoding)で明記されるような間接メッセージを期待する事を要求します。通信の開始者は、可能性、メッセージサイズ、他の外部要因、によって決まる適した間接通信の方法を選びます。

All indirect messages arrive as HTTP requests, and so contain the required fields listed in Section 4.1.2 (HTTP Encoding).

全ての間接メッセージはHTTPリクエストとして届き、Section 4.1.2 (HTTP Encoding)で列挙される必須フィールドを含むみます。



 TOC 

5.2.1.  HTTP Redirect (HTTPリダイレクト)

Data can be transferred by issuing a 302, 303, or 307 HTTP Redirect to the end user's User-Agent. The redirect URL is the URL of the receiver with the OpenID Authentication message appended to the query string, as specified in Section 4.1.2 (HTTP Encoding).

データは、エンドユーザのUser-Agentに対して302か303か307のHTTPリダイレクトを発行する事によって転送する事が出来ます。リダイレクトURLは、Section 4.1.2 (HTTP Encoding)で述べられるように、query stringにOpenID認証メッセージが追加された受領者のURLです。



 TOC 

5.2.2.  HTML FORM Redirection (HTMLフォームリダイレクション)

A mapping of keys to values can be transferred by returning an HTML page to the User-Agent that contains an HTML form element. Form submission MAY be automated, for example by using JavaScript.

キーを値と対応付けはHTMLフォーム要素を含むHTMLページをUser-Agentに返す事によって転送する事が出来ます。フォーム送信は、例えばJavaScriptを使う事で、自動化されるかもしれません。

The <form> element's "action" attribute value MUST be the URL of the receiver. Each Key-Value pair MUST be included in the form as an <input> element. The key MUST be encoded as the "name" attribute and the value as the "value" attribute, such that the User-Agent will generate a message as specified in Section 4.1.2 (HTTP Encoding) when the form is submitted. The form MUST include a submit button.

<form>要素の"action"属性値は受領者のURLでなければなりません。それぞれのKey-Valueペアは<input>要素としてフォームに含まれなければなりません。 フォームが送信されたときにUser-Agentが、Section 4.1.2 (HTTP Encoding)で述べられるように、メッセージを生成できるように、キーは"name"属性で値は"value"属性でなければなりません。



 TOC 

5.2.3.  Indirect Error Responses (間接エラーレスポンス)

In the case of a malformed request, or one that contains invalid arguments, the OpenID Provider MUST redirect the User-Agent to the "openid.return_to" URL value if the value is present and it is a valid URL.

奇形リクエストや不正な引数が含まれる場合に、OPは、User-Agentを"openid.return_to"のURLが与えられていて正当なURLであるなら、そのURLにリダイレクトしなければなりません。

The server MAY add additional keys to this response.

サーバはこのレスポンスにこれ以上のフィールドを追加するかもしれません。

If the malformed or invalid message is received by the Relying Party, or "openid.return_to" is not present or its value is not a valid URL, the server SHOULD return a response to the end user indicating the error and that it is unable to continue.

奇形であるか不正なメッセージがRPによって受け取られるか、"openid.return_to"が与えられないかその値が正当でないURLであるなら、そのサーバはエンドユーザにエラーと継続不可能である事を示すべきです。



 TOC 

6.  Generating Signatures (署名の生成)

The most common usage of an association is as a Message Authentication Code (MAC) key used to sign OpenID Authentication messages.

最も良くある関連付けの慣習は、OpenID認証メッセージの署名にMAC(Message Authentication Code)キーが使われるという事です。

When generating MAC keys, the recommendations in [RFC1750] (Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,” .) SHOULD be followed.

MACキーが生成されるとき、[RFC1750] (Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,” .)の中の勧告に従うべきです。



 TOC 

6.1.  Procedure (手順)

To generate a message signature:

メッセージ署名を生成する為に:

  1. Determine the list of keys to be signed, according to the message to be signed (See Section 10.1 (Positive Assertions)). The list of keys to be signed MUST be part of the message. The list is stored with the key "openid.signed". The value is a comma-separated list of keys, with the "openid." prefix stripped. This algorithm is only capable of signing keys that start with "openid."

    署名されるべきメッセージと対応する署名されるべきキーのリストを決定します(See Section 10.1 (Positive Assertions))。署名されるべきキーのリストはメッセージの一部でなければなりません。そのリストは"openid.signed"キーに対して記憶されます。その値は頭に付く"openid."を取り除いたキーのリストをカンマ区切りにしたものです。このアルゴリズムは"openid."で始まるキーの署名にのみ有効です。

  2. Iterate through the list of keys to be signed in the order they appear in "openid.signed" list. For each key, find the value in the message whose key is equal to the signed list key prefixed with "openid."

    "openid.signed"リストに出現する順番の通りに、署名されるべきキーの一覧の端から端まで繰り返します。それぞれのキーについて、メッセージの中から、署名キーリストのキーに"openid."を前に付けたものと等しいキーの値を探します。

  3. Convert the list of key/value pairs to be signed to an octet string by encoding with Key-Value Form Encoding (Key-Value Form Encoding).

    署名されるべきキーと値のペアのリストをKey-Value Form Encoding (Key-Value Form Encoding)でのエンコーディングによってオクテットストリングに変換します。

  4. Determine the signature algorithm from the association type (Establishing Associations). Apply the signature algorithm (Signature Algorithms) to the octet string.

    関連づけタイプ(association type) (Establishing Associations)から署名アルゴリズムを決定します。署名アルゴリズム(signature algorithm) (Signature Algorithms)をオクテットストリングに適用します。



 TOC 

6.2.  Signature Algorithms (署名アルゴリズム)

OpenID Authentication supports two signature algorithms:

OpenID認証は2つの署名アルゴリズムをサポートします:

If supported, the use of HMAC-SHA256 is RECOMMENDED.

もしサポートされているなら、HMAC-SHA256の利用が推奨されています。



 TOC 

7.  Initiation and Discovery (開始と発見)



 TOC 

7.1.  Initiation (開始)

To initiate OpenID Authentication, the Relying Party SHOULD present the end user with a form that has a field for entering a User-Supplied Identifier.

OpenID認証を開始する為に、RPはUser-Supplied Identifierを記入する為のフィールドを持つフォームをエンドユーザに与えるべきです。

The form field's "name" attribute SHOULD have the value "openid_identifier", so that User-Agents can automatically determine that this is an OpenID form. Browser extensions or other software that support OpenID Authentication may not detect a Relying Party's support if this attribute is not set appropriately.

そのフォームフィールドの"name"属性は、User-Agentは自動的にこれがOpenIDフォームであると判断する事が出来る様に、"openid_identifier"という値であるべきです。ブラウザの拡張やOpenID認証をサポートする他のソフトウェアは、この属性が適切にセットされていないなら、RPのサポートを見つけられないかもしれません。



 TOC 

7.2.  Normalization (正規化)

The end user's input MUST be normalized into an Identifier, as follows:

エンドユーザの入力は以下の様にIdentifierに関して正規化されなければなりません:

  1. If the user's input starts with the "xri://" prefix, it MUST be stripped off, so that XRIs are used in the canonical form.

    ユーザの入力が"xri://"接頭辞から始まるなら、XRIがcanonicalフォームで使われるために、それは除去されなければなりません。

  2. If the first character of the resulting string is an XRI Global Context Symbol ("=", "@", "+", "$", "!") or "(", as defined in Section 2.2.1 of [XRI_Syntax_2.0] (Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” .), then the input SHOULD be treated as an XRI.

    もしその結果の文字列の先頭文字が、[XRI_Syntax_2.0] (Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” .)のSection 2.2.1で定義されるXRI Global Context Symbol("=", "@", "+", "$", "!")か"("なら、入力はXRIとして扱われるべきです。

  3. Otherwise, the input SHOULD be treated as an http URL; if it does not include a "http" or "https" scheme, the Identifier MUST be prefixed with the string "http://". If the URL contains a fragment part, it MUST be stripped off together with the fragment delimiter character "#". See Section 11.5.2 (HTTP and HTTPS URL Identifiers) for more information.

    さもなければ、入力はHTTP URLとして扱われるべきです; もしそれが"http"か"https"スキームを含まないなら、そのIdentifierは文字列"http://"を先頭につけられなければなりません。もしそのURLがfragmentパートを含むなら、それはfragmentを区切る文字"#"と合わせて取り除かれなかればなりません。更なる情報の為にSection 11.5.2 (HTTP and HTTPS URL Identifiers)を読んでください。

  4. URL Identifiers MUST then be further normalized by both following redirects when retrieving their content and finally applying the rules in Section 6 of [RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) to the final destination URL. This final URL MUST be noted by the Relying Party as the Claimed Identifier and be used when requesting authentication (Requesting Authentication).

    URL Identifierは、コンテント取得の時のリダイレクト追跡と、最終的な[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .)のSection 6にある規則の適用、の両方によってさらに正規化されなければなりません。この最終的なURLは、Claimed IdentiferとしてRPによって通達され、認証リクエスト(requesting authentication) (Requesting Authentication)の時に使われなければなりません。

See normalization example (Normalization).



 TOC 

7.3.  Discovery (発見)

Discovery is the process where the Relying Party uses the Identifier to look up ("discover") the necessary information for initiating requests. OpenID Authentication has three paths through which to do discovery:

発見は、RPがIdentifierを使って開始のリクエストの為に必須の情報を探し出す("discover")ための手続きです。OpenID認証は発見を行う為の3つの方針を持っています:

  1. If the identifier is an XRI, [XRI_Resolution_2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .) will yield an XRDS document that contains the necessary information. It should also be noted that Relying Parties can take advantage of XRI Proxy Resolvers, such as the one provided by XDI.org at http://www.xri.net. This will remove the need for the RPs to perform XRI Resolution locally.

    もしIdentifierがXRIなら、[XRI_Resolution_2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .)は必要な情報を含むXRDSドキュメントを与えるでしょう。また、RPが、http://www.xri.netのXDI.orgによって提供される様な、XRI Proxy Resolversの利益を得る事が出来る、という事に注意するべきです。

  2. If it is a URL, the Yadis protocol (Miller, J., “Yadis Specification 1.0,” .) [Yadis] SHALL be first attempted. If it succeeds, the result is again an XRDS document.

    もしURLなら、Yadis protocol (Miller, J., “Yadis Specification 1.0,” .) [Yadis]をはじめに試みるべきです。もし成功したなら、結果はXRDSドキュメントで返されます。

  3. If the Yadis protocol fails and no valid XRDS document is retrieved, or no Service Elements (OpenID Service Elements) are found in the XRDS document, the URL is retrieved and HTML-Based discovery (HTML-Based Discovery) SHALL be attempted.

    もしYadisプロトコルが失敗して妥当でないXRDSドキュメントが取得されたか、XRDSドキュメントの中にサービス要素(Service Elements) (OpenID Service Elements)が見当たらないなら、そのURLのコンテントを取得し、HTML-Based discovery (HTML-Based Discovery)が試みられるべきです。



 TOC 

7.3.1.  Discovered Information (発見された情報)

Upon successful completion of discovery, the Relying Party will have one or more sets of the following information (see the Terminology section (Terminology) for definitions). If more than one set of the following information has been discovered, the precedence rules defined in [XRI_Resolution_2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .) are to be applied.

発見が成功裏に完了したとき、RPは1つ以上の次に述べる情報を持っているでしょう(確認の為に用語のセクション(Terminology section) (Terminology)を読んでください)。もし次に述べる情報の1つ以上が発見されたなら、[XRI_Resolution_2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .)の中で定義される優先ルールが適用されます。

If the end user did not enter an OP Identifier, the following information will also be present:

もしエンドユーザがOP Identifierを記入しなかったなら、次に述べる情報もまた与えられるでしょう:

If the end user entered an OP Identifier, there is no Claimed Identifier. For the purposes of making OpenID Authentication requests, the value "http://specs.openid.net/auth/2.0/identifier_select" MUST be used as both the Claimed Identifier and the OP-Local Identifier when an OP Identifier is entered.

もしエンドユーザがOP Identifierを記入したなら、Claimed Identifierはありません。OpenID認証リクエストの"http://specs.openid.net/auth/2.0/identifier_select"の値を作る目的の為に、OP Identifierが記入されたときにClaimed IdentifierとOP-Local Identifierの両方が使われなければなりません。



 TOC 

7.3.2.  XRDS-Based Discovery

If XRI or Yadis discovery was used, the result will be an XRDS Document. This is an XML document with entries for services that are related to the Identifier. It is defined in Section 3 of (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .) [XRI_Resolution_2.0]. See Appendix A.3 (XRDS) for an example XRDS document.

もしXRIかYadisによる発見が使われたなら、その結果はXRDSドキュメントでしょう。これは、Identifierに関連づけられたサービスのためのエントリを含むXMLドキュメントです。 [XRI_Resolution_2.0]のセクション3(Section 3 of) (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .)で定義されています。XRDSドキュメントの例をAppendix A.3 (XRDS)で見てください。



 TOC 

7.3.2.1.  OpenID Service Elements (OpenIDサービス要素)



 TOC 

7.3.2.1.1.  OP Identifier Element

An OP Identifier Element is an <xrd:Service> element with the following information:

OP Identifier要素は次に述べる情報をもつ<xrd:Service>要素です:

An <xrd:Type> tag whose text content is "http://specs.openid.net/auth/2.0/server".
テキストコンテントが"http://specs.openid.net/auth/2.0/server"である<xrd:Type>タグ。
An <xrd:URI> tag whose text content is the OP Endpoint URL
テキストコンテンツがOP Endpoint URLである<xrd:URI>タグ。



 TOC 

7.3.2.1.2.  Claimed Identifier Element

A Claimed Identifier Element is an <xrd:Service> element with the following information:

Claimed Identifier要素は次に述べる情報をもつ<xrd:Service>要素です:

An <xrd:Type> tag whose text content is "http://specs.openid.net/auth/2.0/signon".
テキストコンテントが"http://specs.openid.net/auth/2.0/signon"である<xrd:Type>タグ。
An <xrd:URI> tag whose text content is the OP Endpoint URL.
テキストコンテントがOP Endpoint URLである<xrd:URI>タグ。
An <xrd:LocalID> tag (optional) whose text content is the OP-Local Identifier.
(optional) テキストコンテントがOP-Local Identifierである<xrd:LocalID>タグ。



 TOC 

7.3.2.2.  Extracting Authentication Data (認証データの抽出)

Once the Relying Party has obtained an XRDS document, it MUST first search the document (following the rules described in [XRI_Resolution_2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .)) for an OP Identifier Element. If none is found, the RP will search for a Claimed Identifier Element.

RPがXRDSドキュメントを取得したとき、はじめにドキュメントからOP Identifier要素を探さなければなりません([XRI_Resolution_2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .)で述べられるルールに従います)。もしなにも見つからなければ、RPはClaimed Identifier要素を探すでしょう。



 TOC 

7.3.2.3.  XRI and the CanonicalID Element (XRIとCanonicalIDの要素)

When the Identifier is an XRI, the <xrd:XRD> element that contains the OpenID Authentication <xrd:Service> element MUST also contain a <CanonicalID> element. The content of this element MUST be used as the Claimed Identifier (see Section 11.5 (Identifying the end user)). This is a vital security consideration because a primary purpose of the <CanonicalID> element is to assert a persistent identifier that will never be reassigned, thus preventing the possibility of an XRI being ("taken over") by a new registrant.

IdentifierがXRIであるとき、OpenID認証の<xrd:Service>要素を含む<xrd:XRD>要素は、<CanonicalID>要素もまた含まなければなりません。この要素のコンテントはClaimed Identifierとして使われなければなりません(see Section 11.5 (Identifying the end user))。<CanonicalID>要素の第一の目的は、新しい登録者によってXRIが引き継がれる可能性を防いで、決して再設定されない永続的なidentifierを主張する事なので、これはきわめて重大なセキュリティ上の配慮です。

The Relying Party MUST confirm that the provider of the XRD that contains the <CanonicalID> element is authoritative for that Canonical ID and that this XRDS document is authoritative for the OpenID Service Element. Relying Parties should either do this manually or ensure that their resolver does this.

RPは<CanonicalID>要素を含むXRDのプロバイダがCanonical IDのために信頼でき、このXRDSドキュメントがOpenIDサービス要素のために信頼できる事を立証しなければなりません。RPはこれを手動で行うかかリゾルバによって行われる様にすべきです。

When using XRI resolution, the Canonical ID MUST be used as the Claimed Identifier. For an XRI to be a valid Identifier, both the <ProviderID> and <CanonicalID> MUST be present in the discovered XRDS document.

XRI解決を使うとき、Canonical IDはClaimed Identifierとして使われなければなりません。XRIを正当なIdentifierとして使う為に、<ProviderID>と<CanonicalID>の両方が発見されたXRDSドキュメントの中に与えられなければなりません。

When using URL Identifiers, the CanonicalID element MUST be ignored if present.

URL Identifierを使うとき、CanonicalID要素は与えられたとしても無視されなければなりません。



 TOC 

7.3.2.4.  Additional Information (追加情報)

The "openid" namespace is no longer used as of OpenID Authentication 2.0. The "xrd" namespace is "xri://$xrd*($v*2.0)".

"openid"名前空間はOpenID認証2.0ではすでに使われていません。"xrd"名前空間は"xri://$xrd*($v*2.0)"です。

For compatibility with deployed code, it is RECOMMENDED that Relying Parties also accept "http://openid.net/signon/1.0" or "http://openid.net/signon/1.1" for the value of <xrd:Type>, as described in the OpenID Authentication 1.1 Compatibility mode (OpenID Authentication 1.1 Compatibility) section. It is RECOMMENDED that Relying Parties supporting OpenID Authentication 2.0 choose to use, if available, endpoints with the type "http://specs.openid.net/auth/2.0/server" and "http://specs.openid.net/auth/2.0/signon", in this order, as specified in Section 7.3.2.2 (Extracting Authentication Data)

運用中のコードの互換性のために、OpenID認証1.1互換モード(OpenID Authentication 1.1 Compatibility mode) (OpenID Authentication 1.1 Compatibility)で述べられる様に、RPは"http://openid.net/signon/1.0"か"http://openid.net/signon/1.1"を<xrd:Type>の値として受け入れる事が推奨されます。OpenID認証2.0をサポートするRPを使う事を選んだとして、もし有効ならば、Section 7.3.2.2 (Extracting Authentication Data)で述べられる様に、"http://specs.openid.net/auth/2.0/server"と"http://specs.openid.net/auth/2.0/signon"という種類のエンドポイントが推奨されます。

If an OP supports extensions (Section 12 (Extensions)), the extensions SHOULD be listed as additional <xrd:Type> child elements of the <xrd:Service> element.

もしOPが拡張(Section 12 (Extensions))をサポートするなら、その拡張は追加の<xrd:Service>要素の子要素の<xrd:Type>として列挙されるべきです。



 TOC 

7.3.3.  HTML-Based Discovery

HTML-Based discovery MUST be supported by Relying Parties. HTML-Based discovery is only usable for discovery of Claimed Identifiers. OP Identifiers must be XRIs or URLs that support XRDS discovery.

HTML-BasedディスカバリはRPによってサポートされなければなりません。HTML-BasedディスカバリはClaimed Identifierの発見の為にのみ使用できるるべきです。OP IdentifierはXRDSディスカバリをサポートするXRIかURLでなければなりません。

To use HTML-Based discovery, an HTML document MUST be available at the URL of the Claimed Identifier. Within the HEAD element of the document:

HTML-Basedディスカバリを使う為に、HTMLドキュメントはClaimed IdentifierのURLとして利用可能でなければなりません。ドキュメントのHEAD要素の内部:

A LINK element MUST be included with attributes "rel" set to "openid2.provider" and "href" set to an OP Endpoint URL

あるLINK要素は"openid2.provider"がセットされた"rel"属性とOP Endpoint URLがセットされた"href"属性を含まなければなりません。

A LINK element MAY be included with attributes "rel" set to "openid2.local_id" and "href" set to the end user's OP-Local Identifier

あるLINK要素は"openid2.local_id"をセットした"rel"属性とエンドユーザのOP-Local Identifierをセットした"href"属性を含まなければなりません。

The protocol version when HTML discovery is performed is "http://specs.openid.net/auth/2.0/signon".

HTMLディスカバリが行われたときのときのプロトコルバージョンは"http://specs.openid.net/auth/2.0/signon"です。

The host of the HTML document MAY be different from the end user's OP's host.

HTMLドキュメントのホストはエンドユーザのOPのホストと異なるかもしれません。

The "openid2.provider" and "openid2.local_id" URLs MUST NOT include entities other than "&amp;", "&lt;", "&gt;", and "&quot;". Other characters that would not be valid in the HTML document or that cannot be represented in the document's character encoding MUST be escaped using the percent-encoding (%xx) mechanism described in [RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .).

"openid2.provider"と"openid2.local_id"のURLは"&amp;"と"&lt;"と"&gt;"と"&quot;"以外のエンティティを含んではなりません。HTMLドキュメント中で妥当でないかドキュメントのエンコーディング中で表現できないような他の文字は、[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .)で述べられている、パーセントエンコーディング(%xx)の仕組みを使ってエスケープされなければなりません。

As discussed in the OpenID Authentication 1.1 Compatibility mode (OpenID Authentication 1.1 Compatibility) section, these discovery tags are not the same as in previous versions of the protocol. While the same data is conveyed, the names have changed which allows a Relying Party to determine the protocol version being used. A Relying Party MAY encounter a Claimed Identifier which uses HTML-Based Discovery to advertise both version 1.1 and 2.0 Providers.

OpenID認証1.1互換モード(OpenID Authentication 1.1 Compatibility mode) (OpenID Authentication 1.1 Compatibility)セクションで議論される様に、これらのディスカバリタグはプロトコルの前のバージョンと同じではありません。 同じデータが運ばれる間、名前が変わり、RPがプロトコルバージョンが使われる事を決定する事を許可します。



 TOC 

8.  Establishing Associations (関連付けの確立)

An association between the Relying Party and the OpenID Provider establishes a shared secret between them, which is used to verify subsequent protocol messages and reduce round trips.

RPとOPの間の関連付けはそれらで共有する秘密鍵を確立し、続くプロトコルメッセージの照合とラウンドトリップを減らすために使われます。

It is RECOMMENDED that a Relying Party form associations if it is possible for it to do so. If a Relying Party is incapable of creating or storing associations, Section 11.4.2 (Verifying Directly with the OpenID Provider) provides an alternate verification mechanism referred to as Stateless Mode.

もしそうする事が可能であるならばRPが関連付けを作る事が推奨されています。もしRPが関連付けを作る事が出来ないか記憶できないなら、Section 11.4.2 (Verifying Directly with the OpenID Provider)がステートレスモードとして参照される代替の照合メカニズムを提供します。



 TOC 

8.1.  Association Session Request (関連づけセッションリクエスト)

An association session is initiated by a direct request (Direct Communication) from a Relying Party to an OP Endpoint URL with the "openid.mode" key having the value of "associate".

関連づけセッションはRPから"associate"がセットされた"openid.mode"キーをつけたOP Endpoint URLに対する直接リクエスト(direct request) (Direct Communication)によって開始されます。



 TOC 

8.1.1.  Common Request Parameters (共通のリクエストパラメータ)

These parameters are common to all association requests:

これらのパラメータは全ての関連付けリクエストについて共通です:



 TOC 

8.1.2.  Diffie-Hellman Request Parameters (Diffie-Hellmanのリクエストパラメータ)

The following parameters are common to requests whose requested association session type is "DH-SHA1" or "DH-SHA256":

次に述べるパラメータは 関連づけセッションタイプが"DH-SHA1"か"DH-SHA256"として要求されたときに共通です。

See Section 8.4.2 (Diffie-Hellman Association Sessions) for more information on these parameters.

NOTE: The 'btwoc' function is defined in Section 4.2 (Integer Representations).



 TOC 

8.2.  Association Session Response (関連づけセッションレスポンス)

An association session response is a direct response from the OP to the Relying Party in Key-Value Form (Key-Value Form Encoding).

関連付けセッションレスポンスはKey-Value Form (Key-Value Form Encoding)を使ったOPからRPへの直接レスポンスです。



 TOC 

8.2.1.  Common Response Parameters (共通のレスポンスパラメータ)



 TOC 

8.2.2.  Unencrypted Response Parameters (複合したレスポンスパラメータ)



 TOC 

8.2.3.  Diffie-Hellman Response Parameters (Diffie-Hellmanのレスポンスパラメータ)

NOTE: The 'btwoc' function is defined in Section 4.2 (Integer Representations)



 TOC 

8.2.4.  Unsuccessful Response Parameters (失敗のレスポンスパラメータ)

If the OP does not support a session type or association type, it MUST respond with a direct error message indicating that the association request failed. If there is another association session type or association type that is supported, the OP SHOULD include that information in the response.

もしOPがセッションタイプか関連づけタイプをサポートしない場合、関連づけリクエストが失敗した事を示す直接のエラーメッセージを返さなければなりません。もし別のサポートされる関連づけセッションタイプか関連づけタイプがあるなら、OPはそのレスポンスの中にその情報を含めるべきです。

Upon receipt of an "unsupported-type" response, the Relying Party MAY make another request with the specified association session type and association type. If no association is established, the Relying Party MAY continue the authentication process in Direct Verification (Verifying Directly with the OpenID Provider).

"unsupported-type"レスポンスを受け取ったとき、RPは指定された関連付けセッションタイプと関連づけタイプを使って別のリクエストを作るかもしれません。もし関連づけが確立されないなら、RPは直接照合(Direct Verification) (Verifying Directly with the OpenID Provider)によって認証手続きを続けるかもしれません。



 TOC 

8.3.  Association Types



 TOC 

8.3.1.  HMAC-SHA1

An association of type "HMAC-SHA1" uses the HMAC-SHA1 (Signature Algorithms) signature algorithm.

関連づけタイプ"HMAC-SHA1"はHMAC-SHA1 (Signature Algorithms)署名アルゴリズムを使います。



 TOC 

8.3.2.  HMAC-SHA256

An association of type "HMAC-SHA256" uses the HMAC-SHA256 (Signature Algorithms) signature algorithm.

関連づけタイプ"HMAC-SHA256"はHMAC-SHA256 (Signature Algorithms)署名アルゴリズムを使います。



 TOC 

8.4.  Association Session Types

OpenID Authentication defines three valid association session types: "no-encryption", "DH-SHA1", and "DH-SHA256".

OpenID認証は3つの妥当なセッションタイプを定義します: "no-encryption", "DH-SHA1", "DH-SHA256"



 TOC 

8.4.1.  No-Encryption Association Sessions

In a "no-encryption" association session, the OP sends the association MAC key in plain-text to the Relying Party. This makes it possible for an eavesdropper to intercept the key, and forge messages to this Relying Party when not using transport layer encryption. Therefore, "no-encryption" association sessions MUST NOT be used unless the messages are using transport layer encryption. See Section 15.1.1 (Eavesdropping Attacks) for more information.

"no-encryption"関連づけセッションの中で、OPはRPに対してplain-textで関連づけのMACキーを送ります。 トランスポート層の暗号化を使わないときに、盗聴者がキーを盗み見る事とPRへのメッセージを偽造する事を可能となります。したがって、"no-encryption"関連づけセッションはメッセージがトランスポート層暗号化されない場合に使われてはなりません。更なる情報はSection 15.1.1 (Eavesdropping Attacks)を読んでください。

The MAC key sent by the OP MUST be the length specified for the requested association type, as specified in Section 6.2 (Signature Algorithms).

OPによって送信されるMACキーは、Section 6.2 (Signature Algorithms)で述べられる様に、関連づけタイプの為に指定される長さでなければなりません。



 TOC 

8.4.2.  Diffie-Hellman Association Sessions

The "DH-SHA1" and "DH-SHA256" association types use Diffie-Hellman Key Exchange to securely transmit the shared secret.

"DH-SHA1"と"DH-SHA256"の関連づけタイプは共有される秘密鍵を安全に渡す為にDiffie-Hellman鍵交換を使います。

The MAC key MUST be the same length as the output of H, the hash function - 160 bits (20 bytes) for DH-SHA1 or 256 bits (32 bytes) for DH-SHA256, as well as the output of the signature algorithm of this association.

MACキーはハッシュ関数Hの出力(DH-SHA1の160ビット(20バイト)かDH-SHA256の256ビット(32バイト))と同じ長さでなければなりません。この関連づけの署名アルゴリズムの出力も同様です。

The Relying Party specifies a modulus, p, and a generator, g. The Relying Party chooses a random private key xa and OpenID Provider chooses a random private key xb, both in the range [1 .. p-1]. The shared secret used to encrypt the MAC key is thus g ^ (xa * xb) mod p = (g ^ xa) ^ xb mod p = (g ^ xb) ^ xa mod p. For more information, see [RFC2631] (Rescorla, E., “Diffie-Hellman Key Agreement Method,” .). For information on the selection of random values, see [RFC1750] (Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,” .).

RPは係数pと発生機gを指定します。RPはランダムなプライベートキーxaを選び、OPはランダムなプライベートキーxbを選びます。xaとxbの両方ともに[1 .. p-1]の範囲内です。MACキーを暗号化されるために使った共有秘密鍵は、g ^ (xa * xb) mod p = (g ^ xa) ^ xb mod p = (g ^ xb) ^ xa mod pで求められます。更なる情報は[RFC2631] (Rescorla, E., “Diffie-Hellman Key Agreement Method,” .)を読んでください。乱数の選択に関する情報は[RFC1750] (Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,” .)を読んでください。



 TOC 

9.  Requesting Authentication (認証の要求)

Once the Relying Party has successfully performed discovery and (optionally) created an association with the discovered OP Endpoint URL, it can send an authentication request to the OP to obtain an assertion. An authentication request is an indirect request (Indirect Communication).

RPが発見に成功して、(optionally) 発見されたOP Endpoint URLと関連付けを作成したとき、主張を得る為にOPに認証リクエストを送る事が出来ます。認証リクエストは間接リクエスト(indirect request) (Indirect Communication)です。



 TOC 

9.1.  Request Parameters (リクエストパラメータ)



 TOC 

9.2.  Realms (レルム)

A "realm" is a pattern that represents the part of URL-space for which an OpenID Authentication request is valid. A realm is designed to give the end user an indication of the scope of the authentication request. OPs SHOULD present the realm when requesting the end user's approval for an authentication request. The realm SHOULD be used by OPs to uniquely identify Relying Parties. For example, OPs MAY use the realm to allow the end user to automate approval of authentication requests.

"realm"はOpenID認証リクエストが妥当である為のURL空間の一部を表現したパターンです。realmはエンドユーザに認証リクエストの範囲の指示を与える為に設計されました。OPは認証リクエストに関するエンドユーザの同意を求めるときにrealmを与えるべきです。realmはOPによってRPをユニークに識別する為に使われるべきです。例えば、OPは認証リクエストの同意を自動化する為にエンドユーザを認める事にrealmを使うかもしれません。

A realm pattern is a URL, with the following changes:

realmパターンは次に続く変更を伴うURLです:

A URL matches a realm if:

URLがrealmにマッチする条件:

When present, the "openid.return_to" URL MUST match the "openid.realm", or the OP MUST return an indirect error response (Indirect Error Responses).

"openid.return_to"のURLはそれが与えられたなら、"openid.realm"にマッチしなければならず、そうでないならOPは間接エラーレスポンス(indirect error response) (Indirect Error Responses)を返さなければならない。

It is RECOMMENDED that OPs protect their users from making assertions with overly-general realms, like http://*.com/ or http://*.co.uk/. Overly general realms can be dangerous when the realm is used for identifying a particular Relying Party. Whether a realm is overly-general is at the discretion of the OP.

OPはhttp://*.comやhttp://*.co.ukのようなあまりにも一般的なrealmをともなる主張の作成からユーザを保護する事が推奨されます。あまりに一般的なrealmはrealmが特有のRPを識別する為に使われる時に危険となる事が出来ます。realmがあまりに一般的であるかはOPの自由裁量によります。



 TOC 

9.2.1.  Using the Realm for Return URL Verification (戻りURLの照合に関するrealmの利用)

OpenID providers SHOULD verify that the return_to URL specified in the request is an OpenID relying party endpoint. To verify a return_to URL, obtain the relying party endpoints for the realm by performing discovery on the relying party (Discovering OpenID Relying Parties). As always when performing discovery, the discovered URL is the URL of the last HTTP response, following redirects. If any redirects are followed when performing discovery on the realm, verification has failed. If discovery has successfuly completed, check to make sure that the return_to URL matches one of the relying party endpoints.

OPはリクエストで示されるreturn_toのURLがOpenIDのRPエンドポイントである事を照合すべきです。 return_toのURLを照合する為に、RPの発見(discovery on the relying party) (Discovering OpenID Relying Parties)を行うことによってrealmに関するRPエンドポイントを得ます。いつものように発見が行われるときに、発見されたURLはリダイレクトに従った最終的なHTTPレスポンスのURLです。もしrealm上での発見を行ったときにリダイレクトに従ったなら、照合は失敗です。もし発見が成功裏に完了したなら、return_toのURLがRPエンドポイントの1つにマッチするか確信する為に確認します。

A realm may contain a wildcard, and so may not be a valid URL. In that case, perform discovery on the URL obtained by substituting "www" for the wildcard in the realm.

realmはワイルドカードを含むかもしれないので、妥当なURLではないかもしれません。その場合、 realmの中のワイルドカードを"www"で置き換える事で得られたURL上で発見を行います。

To match a return_to URL against a relying party endpoint, use the same rules as for matching the return_to URL against the realm, treating the relying party's endpoint URL as the realm. Relying party endpoint URLs MUST NOT contain a domain wildcard, and SHOULD be as specific as possible.

RPエンドポイントに対してreturn_toのURLをマッチさせる為に、RPエンドポイントをrealmとして扱って、return_toのURLに対するrealmのマッチングに関するような同じ規則を使います。RPエンドポイントのURLはドメインワイルドカードを含んではならず、可能な限り明確であるべきです。

If verification is attempted and fails, the provider SHOULD NOT send a positive assertion to that return_to URL.

もし照合が試みられて失敗であるなら、プロバイダはreturn_toのURLに肯定の主張を送るべきではありません。

Providers MAY cache verified return_to URLs.

プロバイダは照合したreturn_toのURLをキャッシュするかもしれません。



 TOC 

9.3.  Immediate Requests (直接的なリクエスト)

When requesting authentication, the Relying Party MAY request that the OP not interact with the end user. In this case the OP MUST respond immediately with either an assertion that authentication is successful, or a response indicating that the request cannot be completed without further user interaction. This is accomplished by an authentication request with "openid.mode" set to "checkid_immediate".

認証を要求するとき、RPはOPがエンドユーザと対話しない事を要求するかもしれません。この場合 OPは、認証が成功したという主張か、リクエストがさらなるユーザの対話なしに完了出来ない事を示すレスポンスのいずれか一方を、直接返さなければなりません。これは"openid_immediate"がセットされた"openid.mode"をつけた認証リクエストによって遂行されます。



 TOC 

10.  Responding to Authentication Requests (認証リクエストへの応答)

When an authentication request comes from the User-Agent via indirect communication (Indirect Communication), the OP SHOULD determine that an authorized end user wishes to complete the authentication. If an authorized end user wishes to complete the authentication, the OP SHOULD send a positive assertion (Positive Assertions) to the Relying Party.

間接通信(indirect communication) (Indirect Communication)を使ってUser-Agentから認証リクエストがきたとき、OPは認可されたエンドユーザが認証の完了を望むか明らかにすべきです。もし認可されたエンドユーザが認証を完了する事を望むなら、OPはRPに肯定の主張(positive assertion) (Positive Assertions)を送るべきです。

Methods of identifying authorized end users and obtaining approval to return an OpenID Authentication assertion are beyond the scope of this specification. See Section 15.1.2.1 (Rogue Relying Party Proxying) for OpenID Provider security considerations.

認可されたエンドユーザを識別する方法とOpenID認証の主張を返す事の同意を獲得する事はこの仕様書の範囲外です。OPのセキュリティのためにSection 15.1.2.1 (Rogue Relying Party Proxying)を読んでください。

If the relying party requested OP-driven identifier selection by setting "openid.identity" to "http://specs.openid.net/auth/2.0/identifier_select" and there are Identifiers for which the end user is authorized to issue authentication responses, the OP SHOULD allow the end user to choose which Identifier to use.

もしRPが RPが"http://specs.openid.net/auth/2.0/identifier_select"をセットした"openid.identity"によってOP主導のidentifierの選択を要求したとして、そして認証レスポンスを発行する為に認可されたエンドユーザに関する複数のIdentifierがあるなら、OPはエンドユーザに対してどのIdentifierを使うかを選ぶ事を許可するべきです。

If the Relying Party supplied an association handle with the authentication request, the OP SHOULD attempt to look up an association based on that handle. If the association is missing or expired, the OP SHOULD send the "openid.invalidate_handle" parameter as part of the response with the value of the request's "openid.assoc_handle" parameter, and SHOULD proceed as if no association handle was specified.

もしRPが認証リクエストとともに関連づけハンドルを与えたなら、OPはそのハンドルに基づいて関連づけを探す事を試みるべきです。もし関連付けが失われたか期限切れであるなら、OPはレスポンスの一部としてリクエストの"openid.assoc_handle"の値を付けた"openid.invalidate_handle"パラメータを送るべきで、そして関連づけハンドルが示されなかったとして続けるべきです。

If no association handle is specified, the OP SHOULD use a private association for signing the response. The OP MUST store this association and MUST respond to later requests to check the signature of the response via Direct Verification (Verifying Directly with the OpenID Provider).

もし関連づけハンドルが示されないなら、OPは私的な関連付けをレスポンスの署名に使うべきです。OPはこの関連付けを記憶しなければならず、そして直接照合(Direct Verification) (Verifying Directly with the OpenID Provider)によるレスポンスの署名を確認する為にその後のリクエストに応答しなければなりません。

Relying Parties SHOULD accept and verify assertions about Identifiers for which they have not requested authentication. OPs SHOULD use private associations for signing unsolicited positive assertions.

RPは認証を要求していないIdentifierに関する主張を受け入れて照合するべきです。OPは勝手な肯定の主張への署名に関して私的な関連付けを使うべきです。

If the "openid.return_to" value is omitted in the request, the Relying Party does not wish to receive an authentication assertion from the OP. This can be useful when using extensions to transfer data from the Relying Party to the OP.

もしリクエストの中で"openid.return_to"の値が省略されたなら、RPはOPから認証の主張を受け取る事を望みません。これはRPからOPにデータを転送するために拡張を使うときに役立てる事が出来ます。



 TOC 

10.1.  Positive Assertions (肯定の主張)

Positive assertions are indirect responses (Indirect Communication) with the following fields:

肯定の主張は次に述べるフィールドを含む間接レスポンス(indirect responses) (Indirect Communication)です:



 TOC 

10.2.  Negative Assertions (否定の主張)

If the OP is unable to identify the end user or the end user does not or cannot approve the authentication request, the OP SHOULD send a negative assertion to the Relying Party as an indirect response (Indirect Communication).

もしOPがエンドユーザを識別できないかエンドユーザが認証リクエストに同意しないか出来ないなら、OPは間接レスポンス(indirect response) (Indirect Communication)としてRPに否定の主張を送るべきです。

When receiving a negative assertion in response to a "checkid_immediate" mode request, Relying Parties SHOULD construct a new authentication request using "checkid_setup" mode. Details about how this differs from OpenID Authentication 1.1 can be found in Section 14 (OpenID Authentication 1.1 Compatibility).

"checkid_immediate"モードのリクエストに対するレスポンスで否定の主張を受け取ったとき、RPは"checkid_setup"も度を使って新しい認証リクエストを作るべきです。OpenID認証1.1からどのような違いがあるかの詳細は、Section 14 (OpenID Authentication 1.1 Compatibility)で見つける事が出来ます。



 TOC 

10.2.1.  In Response to Immediate Requests (直接的なリクエストに対するレスポンス)

If the request was an immediate request, there is no chance for the end user to interact with pages on the OP to provide identifying credentials or approval of a request. A negative assertion of an immediate request takes the following form:

もしリクエストが直接的なリクエストだったら、エンドユーザには識別の証明書かリクエストの同意を提供するためにOP上でページを使って対話する機会がありません。直接的なリクエストの否定の主張は次に続く形式をとります:



 TOC 

10.2.2.  In Response to Non-Immediate Requests (非直接的なリクエストに対するレスポンス)

Since the OP may display pages to the end user and request credentials from the end user, a negative response to a request that is not immediate is definitive. It takes the following form:

OPがエンドユーザにページを表示してクレデンシャルをエンドユーザから要求するまでの間、直接的でないリクエストに対する否定のレスポンスは最も確実です。次に述べる形式をとります:

Often, if the user does not wish to or cannot complete the authentication request, the OpenID authentication process will be aborted and the Relying Party will not get a cancel mode response (the end user may quit or press the back button in their User-Agent instead of continuing). If a RP receives the "cancel" response, authentication was unsuccessful and the RP MUST treat the end user as non-authenticated.

しばしば、もしユーザが認証リクエストを望まないか完了できなかった場合、OpenID認証プロセスは中断され、RPは中止モードのレスポンスを取得しないでしょう(エンドユーザは続ける代わりにUser-Agentを終了させるかUser-Agentの戻るボタンを押すかもしれません)。もしRPが"cancel"レスポンスを受け取ったなら、認証は失敗でRPは認証されていないものとしてエンドユーザを扱わなければなりません。



 TOC 

11.  Verifying Assertions (主張の照合)

When the Relying Party receives a positive assertion, it MUST verify the following before accepting the assertion:

RPが肯定の主張を受け取ったとき、主張を受け入れる前に以下の照合をしなければなりません:

If all four of these conditions are met, assertion is now verified. If the assertion contained a Claimed Identifier, the user is now authenticated with that identifier.

もしこれらの条件の4つ全てがマッチしたなら、主張はこの時点で証明されます。もし主張がClaimed Identifierを含むなら、そのユーザはこの時点でそのidentifierについて認証されます。



 TOC 

11.1.  Verifying the Return URL (戻りURLの照合)

To verify that the "openid.return_to" URL matches the URL that is processing this assertion:

"openid.return_to"のURLがこの主張を処理するURLとマッチする事を立証する為に:



 TOC 

11.2.  Verifying Discovered Information (発見された情報の照合)

If the Claimed Identifier in the assertion is a URL and contains a fragment, the fragment part and the fragment delimiter character "#" MUST NOT be used for the purposes of verifying the discovered information.

もし主張の中のClaimed IdentifierがURLでフラグメントを含むなら、そのフラグメント部分とフラグメントのっ区切り文字である"#"は発見された情報を照合する目的の為に使われてはなりません。

If the Claimed Identifier is included in the assertion, it MUST have been discovered (Discovery) by the Relying Party and the information in the assertion MUST be present in the discovered information. The Claimed Identifier MUST NOT be an OP Identifier.

もし主張の中にClaimed Identifierが含まれるなら、RPによって発見(discovered) (Discovery)されていなければならず、そして主張の中の情報は発見された情報の中にも与えられていなければなりません。Claimed IdentifierはOP Identifierであってはなりません。

If the Claimed Identifier was not previously discovered by the Relying Party (the "openid.identity" in the request was "http://specs.openid.net/auth/2.0/identifier_select" or a different Identifier, or if the OP is sending an unsolicited positive assertion), the Relying Party MUST perform discovery on the Claimed Identifier in the response to make sure that the OP is authorized to make assertions about the Claimed Identifier.

もしClaimed IdentifierがRPによってあらかじめ発見されなかったなら(リクエストの中の"openid.identity"が"http://specs.openid.net/auth/2.0/identifier_select"か別のIdentifierであるか、もしもOPが余計な肯定の主張を送っているなら)、RPはOPがそのClaimed Identifierに関して主張を作る為に認可されている事を確かめる為にレスポンスの中のClaimed Identifier上で発見を行わなければなりません。

If no Claimed Identifier is present in the response, the assertion is not about an identifier and the RP MUST NOT use the User-supplied Identifier associated with the current OpenID authentication transaction to identify the user. Extension information in the assertion MAY still be used.

もしレスポンスの中にClaimed Identifierが与えられていないなら、その主張はidentifierに関する物ではなく、RPはそのユーザを識別する為に関連づけられたUser-Supplied Identifierを使ってはなりません。主張の中の拡張の情報はまだ使われるかもしれません。



Discovered ValueResponse Field
Claimed Identifier openid.claimed_id
OP-Local Identifier openid.identity
OP Endpoint URL openid.op_endpoint
Protocol Version openid.ns

This table shows the mapping of discovered information (Discovered Information) into fields in the OpenID Authentication 2.0 "id_res" response (Positive Assertions)

この表はOpenID認証2.0の"id_res"レスポンス(OpenID Authentication 2.0 "id_res" response) (Positive Assertions)の中のフィールドに関する発見された情報(discovered information) (Discovered Information)とのマッピングを示しています。

 Discovered Information to Authentication Response Mapping 

If using a discovery mechanism that yields an XRDS document, the protocol version, OP Endpoint URL and the OP-Local Identifier (if different than the Claimed Identifier) MUST be present in one <xrd:Service> element. There MAY be unused fields in that <xrd:Service> element.

もしXRDSドキュメントをもたらす発見のメカニズムを使うなら、プロトコルバージョンとOP Endpoint URLとOP-Local Identifier(Claimed Identifierと違うなら)はある<xrd:Service>要素の中に与えられなければなりません。<xrd:Service>要素の中で使われないフィールドがあるかもしれません。

Non-normative example:

<Service xmlns="xri://$xrd*($v*2.0)">
  <Type>http://specs.openid.net/auth/2.0/signon</Type>
  <URI>http://provider.example.com/openid</URI>
  <URI>https://provider.example.com/openid</URI>
</Service>

In this example XRDS snippet, the <xrd:Service> element has two <xrd:URI> elements, which map to OP Endpoint URLs as per Section 7.3.1 (Discovered Information). If an assertion has either value for "openid.op_endpoint", then that field matches this <xrd:Service> element. The other <xrd:URI> element is unused.

このXRDSの断片の例の中で、<xrd:Service>要素は、Section 7.3.1 (Discovered Information)に従ったOP Endpoint URLに結びつく、2つの<xrd:URI>要素を持ちます。もし主張が"openid.op_endpoint"についてどちらかの値を持つなら、フィールドはこの<xrd:Service>要素とマッチします。他の<xrd:URI>要素は使われません。



 TOC 

11.3.  Checking the Nonce (nonceの確認)

To prevent replay attacks, the agent checking the signature keeps track of the nonce values included in positive assertions and never accepts the same value more than once for the same OP Endpoint URL.

リプレイ攻撃を防ぐ為に、署名を確認するエージェントが肯定の主張の中に含まれるnonce値を見失わず、同じOP Endpoint URLに関して1度以上同じ値を決して受け入れません。

The time-stamp MAY be used to reject responses that are too far away from the current time, limiting the amount of time that nonces must be stored to prevent attacks. The acceptable range is out of the scope of this specification. A larger range requires storing more nonces for a longer time. A shorter range increases the chance that clock-skew and transaction time will cause a spurious rejection.

タイムスタンプは現在時刻から離れすぎたレスポンスを拒否する為に使われるかもしれず、nonceの時間の総計の制限は攻撃を予防する為に記憶されなければなりません。受付可能な範囲はこの仕様書の範囲外です。 より大きな範囲は多くのnonceを長時間記憶する事を要求します。より短い範囲は時間のずれとトランザクションタイムが引き起こすだろう疑似的な排除の機会を増加させます。



 TOC 

11.4.  Verifying Signatures (署名の照合)

If the Relying Party has stored an association with the association handle specified in the assertion, it MUST check the signature on the assertion itself. If it does not have an association stored, it MUST request that the OP verify the signature via Direct Verification (Verifying Directly with the OpenID Provider).

もしRPが主張の中で示される関連付けハンドルによる関連付けを記憶しているなら、主張の署名をRP自身で確認しなければなりません。もし関連付けを記憶していないなら、OPが直接照合(Direct Verification) (Verifying Directly with the OpenID Provider)によって署名を照合する事を要求しなければなりません。



 TOC 

11.4.1.  Verifying with an Association (関連付けによる照合)

The Relying Party follows the same procedure that the OP followed in generating the signature (Generating Signatures), and then compares the signature in the response to the signature it generated. If the signatures do not match, the assertion is invalid.

RPは署名の生成(generating the signature) (Generating Signatures)についてOPが従った同じ手順に従い、そしてレスポンスの中の署名と生成した署名とを比較します。もし署名がマッチしないなら、その主張は不正です。

If an authentication request included an association handle for an association between the OP and the Relying party, and the OP no longer wishes to use that handle (because it has expired or the secret has been compromised, for instance), the OP will send a response that must be verified directly with the OP, as specified in Section 11.4.2 (Verifying Directly with the OpenID Provider). In that instance, the OP will include the field "openid.invalidate_handle" set to the association handle that the Relying Party included with the original request.

もし認証リクエストがOPとRPとの関連付けに関するの関連づけハンドルを含み、そしてOPがもう そのハンドルを使う事を望まないなら(インスタンスについて、期限切れか秘密鍵が信用できない)、OPは Section 11.4.2 (Verifying Directly with the OpenID Provider)で述べられる様に、OPで直接照合されるべきであるというレスポンスを送るでしょう。そのインスタンスの中で、OPはRPがオリジナルリクエストに含めたものを"openid.invalidate_handle"フィールドを含めるでしょう。



 TOC 

11.4.2.  Verifying Directly with the OpenID Provider (OPによる直接照合)

To have the signature verification performed by the OP, the Relying Party sends a direct request (Direct Request) to the OP. To verify the signature, the OP uses a private association that was generated when it issued the positive assertion (Positive Assertions).

OPによる署名の照合が行われるために、RPは直接リクエスト(direct request) (Direct Request)をOPに送ります。署名を照合する為に、OPは肯定の主張(positive assertion) (Positive Assertions)を発行したときに生成された私的な関連付けを使います。



 TOC 

11.4.2.1.  Request Parameters (リクエストパラメータ)

For verifying signatures an OP MUST only use private associations and MUST NOT use associations that have shared keys. If the verification request contains a handle for a shared association, it means the Relying Party no longer knows the shared secret, or an entity other than the RP (e.g. an attacker) has established this association with the OP.

署名を照合する為にOPは私的な関連付けのみを使わなければならず、共有鍵による関連づけを使ってはなりません。もし照合リクエストが共有された関連付けに関するハンドルを含むなら、それはRPがすでに共有された秘密鍵を知らない事を意味するか、そのRP以外のエンティティ(例えば攻撃者)がOPとこの関連付けを確立している事を意味します。

To prevent replay attacks, the OP MUST NOT issue more than one verification response for each authentication response it had previously issued. An authentication response and its matching verification request may be identified by their "openid.response_nonce" values.

リプレイ攻撃を防ぐ為に、OPは前に照合レスポンスが発行されたそれぞれの認証レスポンスに対してさらなる照合レスポンスを発行してはなりません。認証レスポンスとそのマッチする照合リクエストはそれらの"openid.response_nonce"の値によって識別されるかもしれません。



 TOC 

11.4.2.2.  Response Parameters (レスポンスパラメータ)



 TOC 

11.5.  Identifying the end user (エンドユーザの識別)

The Claimed Identifier in a successful authentication response SHOULD be used by the Relying Party as a key for local storage of information about the user. The Claimed Identifier MAY be used as a user-visible Identifier. When displaying URL Identifiers, the fragment MAY be omitted.

成功の認証レスポンスの中のClaimed Identifierはユーザに関する情報のローカルストレージに関するキーとしてRPに使われるべきです。Claimed Identifierはユーザに見えるものとして使われるかもしれません。URL Identifierが表示されるとき、フラグメントは省略されるかもしれません。



 TOC 

11.5.1.  Identifier Recycling

OpenID Providers with large user bases can use fragments to recycle URL Identifiers if it is so desired. When reassigning a URL Identifier to a new end user OPs should generate a new, unique fragment part.

非常の多くのユーザを抱えるOPは望まれるならばURL Identifierを再利用する為にフラグメントを使う事が出来ます。新しいユーザの為にURL Identifierが再び割り当てられるとき、OPは新しいユニークなフラグメント部分を生成すべきです。

The full URL with the fragment part constitutes the Claimed Identifier in positive assertions, therefore Relying Parties will distinguish between the current and previous owners of the fragment-less URL.

フラグメントパートをつけた完全なURLは肯定の主張の中のClaimed Identifierを構成しまし、したがってRPはフラグメントなしのURLの現在と前の両方の持ち主を見分けるでしょう。

This mechanism allows the (presumably short, memorable) recycled URL Identifiers without the fragment to be used by end users at login time and by Relying Parties for display purposes.

このメカニズムは(おそらく短く、覚えやすい)フラグメントなしの再利用されたURL Identifierが、エンドユーザがログインするときに使われる事とRPによって表示目的に使われる事を許可します。



 TOC 

11.5.2.  HTTP and HTTPS URL Identifiers (HTTPとHTTPSのURL Identifier)

Relying Parties MUST differentiate between URL Identifiers that have different schemes. When end user input is processed into a URL, it is processed into a HTTP URL. If the same end user controls the same URL, differing only by scheme, and it is desired that the Identifier be the HTTPS URL, it is RECOMMENDED that a redirect be issued from the HTTP URL to the HTTPS URL. Because the HTTP and HTTPS URLs are not equivalent and the Identifier that is used is the URL after following redirects, there is no foreseen reduction in security when using this scheme. If an attacker could gain control of the HTTP URL, it would have no effect on the HTTPS URL, since the HTTP URL is not ever used as an Identifier except to initiate the discovery process.

RPは異なるスキームのURL Identifierを区別しなければなりません。エンドユーザの入力がURLについて処理するとき、HTTPのURLについて処理されます。もし同じエンドユーザが、スキームだけが異なる、同じURLを管理して、IdentifierはHTTPSのURLである事が望まれたなら、HTTPのURLからHTTPSのURLへのリダイレクトが発行される事が推奨されます。なぜならHTTPとHTTPSのURLは同等でなくリダイレクトに従った後のURLが使われたIdentiferではこのスキームを使うときのセキュリティの減少が見越せません。もし攻撃者がHTTP URLの管理を獲得できたとして、HTTP URLは発見処理の開始を除いて決してIdentifierとして使われないので、それはHTTPS URLに対して何の影響ももたらさないでしょう。



 TOC 

12.  Extensions (拡張)

An Extension to OpenID Authentication is a protocol that "piggybacks" on the authentication request and response. Extensions are useful for providing extra information about an authentication request or response as well as providing extra information about the subject of the authentication response.

OpenID認証の為の拡張は認証のリクエストとレスポンスの上に乗る("piggybacks")プロトコルです。拡張は認証のリクエストかレスポンスに関する他の情報を提供する事に加えて、認証レスポンスの対象以外n情報を提供する事にも役立ちます。

OpenID extensions are identified by a Type URI. The Type URI MAY be used as the value of an <xrd:Type> element of an OpenID <xrd:Service> element in an XRDS document associated with a Claimed Identifier. The Type URI is also used to associate key-value pairs in messages with the extension.

OpenIDの拡張はType URIによって識別されます。Type URIは Claimed Identifierと関連づけられたXRDSドキュメントの中のOpenIDの<xrd:Service>要素に含まれる<xrd:Type>の値として使われるかもしれません。Type URIはまた拡張によるメッセージの中で関連づけのためのkey-valueペアのために使われます。

To associate keys and values in a message with an extension, the key MUST be associated with the Type URI. To associate keys with a Type URI, establish an alias by adding a key prefixed with "openid.ns." and ending with the alias text whose value is the Type URI. Once an alias has been established, all pairs in the message whose keys start with "openid." followed by the alias text, followed by a period or the end of the key are associated with that extension. This mechanism is similar to the XML namespaces.

拡張によるメッセージの中のキーと値を関連づけるために、キーはType URIによって関連づけられるかもしれません。Type URIによってキーを関連づける為に、"openid.ns."で始まりTYpe URIの値であるエイリアステキストで終わるキーを追加する事でエイリアスを確立します。エイリアスが確立されるとき、キーが"openid."で始まりエイリアステキストで終わるメッセージの中の全てのペアは、ピリオドで終わるかキーの終端は拡張が関連づけられます。このメカニズムはXML名前空間と似ています。

A namespace alias MUST NOT contain a period and MUST NOT be the same as another namespace alias in the same message. A namespace alias also MUST NOT be in the following list of disallowed aliases:

名前空間エイリアスはピリオドを含めてはならず、同じメッセージの中で別の名前空間エイリアスと同じであってはなりません。名前空間エイリアスはまた次ぎに述べる無効なエイリアスのリストの中にあってはなりません:

A namespace MUST NOT be assigned more than one alias in the same message. If a message is a response to another message, the response MAY use a different alias to refer to the same namespace.

名前空間は同じメッセージの中で一つ以上のエイリアスを割り当ててはなりません。もしメッセージが別のメッセージのレスポンスなら、レスポンスは同じ名前空間を参照する為に異なるエイリアスを使うかもしれません。

Non-normative example:

An extension's type URI is "<http://example.com/ext/1.0>".

openid.ns.x=http://example.com/ext/1.0

openid.x=example

openid.x.foo=bar

openid.xx=notx

In this example, the keys "openid.x" and "openid.x.foo" are associated with the extension; the "openid.xx" key is not.

この例の中で、"openid.x"と"openid.x.foo"といったキーは拡張によって関連づけられています; "openid.xx"キーは違います。

Extensions MUST NOT define multiple parameters with the same name. Extensions that need to send multiple values for the same parameter name must define their own conventions for doing so.

拡張は同じ名前で複数のパラメータを定義してはなりません。同じパラメータ名の為に複数の値を送る事が必要な拡張はそうする為に自身でしきたりを定義しなければなりません。



 TOC 

13.  Discovering OpenID Relying Parties (OpenIDのRPの発見)

Relying Party discovery allows for software agents to discover sites that support OpenID. It also allows OpenID providers to automatically verify that a return_to URL in an OpenID request is an OpenID relying party endpoint for the specified realm.

RPの発見はOpenIDをサポートするサイトを発見するためのソフトウェアエージェントを考慮します。それはまた、OpenIDリクエストの中のreturn_toというURLが、示されたrealmに関するRPエンドポイントである事の、自動的な照合をOPに許可します。

Relying Parties SHOULD use the Yadis protocol to publish their valid return_to URLs. The relying party MAY publish this information at any URL, and SHOULD publish it under the realm so that providers can verify return_to URLs.

RPは妥当なreturn_toのURLを発行するためにYadisプロトコルを使うべきです。RPはいかなるURLにもこの情報を発行するかもしれず、プロバイダがreturn_toのURLを照合できるためにrealm下のそれに発行すべきです。

A Relying Party discovery XRDS document MUST contain one or more <xrd:Service> elements:

RPが発見したXRDSドキュメントは1つ以上の<xrd:Service<要素を含まなければなりません:

Non-normative example:

<Service xmlns="xri://$xrd*($v*2.0)">
  <Type>http://specs.openid.net/auth/2.0/return_to</Type>
  <URI>http://consumer.example.com/return</URI>
</Service>


 TOC 

14.  OpenID Authentication 1.1 Compatibility (OpenID認証1.1互換性)

This section describes how to interact with OpenID Authentication 1.1 Relying Parties and OPs. OpenID Authentication 2.0 implementations SHOULD support OpenID Authentication 1.1 compatibility, unless security considerations make it undesirable.

このセクションはRPとOPがOpenID認証1.1で対話する方法を説明します。OpenID認証2.0の実装は、セキュリティ考察が有害としないならば、OpenID認証1.1互換性をサポートすべきです。



 TOC 

14.1.  Changes from OpenID Authentication 1.1 (OpenID認証1.1からの変更)

(non-normative)

(非標準)

This specification is based on the original specification for OpenID Authentication as written by Brad Fitzpatrick. That specification did not have a version number, but was called OpenID 1.0, and then OpenID 1.1 when it was revised. The protocol outlined in this specification is intended to be backwards-compatible with the revised OpenID protocol. The changes to the specification are outlined in this section.

この仕様書はBrad Fitzpatrickによって書かれたOpenID認証に関する原型の仕様書を基にしています。その仕様書はバージョン番号を持ちませんが、OpenID 1.0と呼ばれ、そしてそれが改修されたときにOpenID 1.1となりました。この仕様書で要点が述べられたプロトコルは改修したOpenIDプロトコルとの後方互換が意図されます。仕様書の変更点はこのセクションの中でおおまかに述べられます。



 TOC 

14.1.1.  Updated Initiation and Discovery (更新した開始と発見)



 TOC 

14.1.2.  Security improvements (セキュリティ向上)

A nonce is now part of the protocol for built-in protection against replay attacks, which was previously implemented out-of-band by each library or application.

nonceは現在ではリプレイ攻撃に備えた組み込みの保護に関するプロトコルの一部で、それは以前にはそれぞれのライブラリやアプリケーションによってout-of-bandとして実装されました。

A new association type, HMAC-SHA256, and a new association session type, DH-SHA256, allow for stronger signatures on authentication assertions.

新しい関連付けタイプのHMAC-SHA256と、新しい関連付けセッションタイプのDH-SHA256は、認証の主張により強い署名を与えます。

An actual Security Considerations section (Security Considerations) which looks at protecting the protocol from end-to-end.

実際のセキュリティ考察のセクション(Security Considerations section) (Security Considerations)はend-to-endからプロトコルを守る事を考察します。



 TOC 

14.1.3.  Extensions (拡張)

Extensions are now an officially supported mechanism to support data exchange and other Relying Party-OP communication along with the authentication exchange. Extensions allow for the exchange of arbitrary attributes, as well as for protocol extensions, such as the inclusion of additional information about the Relying Party in the authentication request.

拡張は現在ではデータ交換と認証の交換と一緒に他のRP-OP通信をサポートする為に公式にサポートされるメカニズムです。拡張は自由裁量による属性の交換のみならず、たとえば認証リクエストの中のRPに関する追加情報の包括などのプロトコル拡張も考慮します。

Because extensions can transfer arbitrary data, the Identifier is now optional in authentication messages.

拡張は自由裁量によるデータを転送できるので、Identiferは現在では認証メッセージについて任意です。



 TOC 

14.2.  Implementing OpenID Authentication 1.1 Compatibility (OpenID認証1.1互換性の実装)

All messages in OpenID Authentication 1.1 omit the "openid.ns" parameter, which is an easy way for an RP to determine if the message is from an OpenID Authentication 1.1 endpoint. OpenID Authentication 1.1 supports only HMAC-SHA1 associations.

OpenID認証1.1の中の全てのメッセージは"openid.ns"パラメータを省略する事が、メッセージがOpenID認証1.1のエンドポイントからきているかを明らかにするためにRPにとって簡単な方法です。

Error responses in OpenID Authentication 1.1 did not define "contact" or "reference". OpenID Authentication 1.1 did allow for the addition of extra fields in error responses. It is RECOMMENDED for contact and reference to be sent even when using OpenID Authentication 1.1, since they may be useful for debugging and do not affect compatibility.

OpenID認証1.1の中のエラーメッセージは"contact"や"reference"を定義しませんでした。OpenID認証1.1はエラーレスポンスの中に他のフィールドの追加を許可していました。連絡先と参照に対してOpenID認証1.1を使う時と同じように送る事が、デバッグの為に役立つかもしれず互換性に作用しないので、推奨されています。



 TOC 

14.2.1.  Relying Parties (RP)



 TOC 

14.2.2.  OpenID Providers (OP)



 TOC 

15.  Security Considerations (セキュリティ考察)



 TOC 

15.1.  Preventing Attacks (攻撃の予防)



 TOC 

15.1.1.  Eavesdropping Attacks (盗聴攻撃)

There is one place in this protocol that is vulnerable to eavesdropping attacks.

このプロトコルには盗聴攻撃の脆弱性に関するある部分があります。

This attack can be prevented by using transport layer encryption for these connections to prevent eavesdropping. In addition, if not using TLS this attack can still be prevented by checking the nonce while performing message verification. When doing so, the positive authentication assertion cannot be re-used.

この攻撃は盗聴を防ぐための通信としてトランスポート層暗号化を使う事によって予防する事が出来ます。さらに、もしTLSを使わないならこの攻撃はメッセージ照合を行う間にnonceを確認する事によってまだ予防する事が出来ます。そうしているとき、その肯定の認証の主張は再利用される事が出来ません。



 TOC 

15.1.2.  Man-in-the-Middle Attacks (中間者攻撃)

Associations prevent tampering of signed fields by a man in the middle except during discovery, association sessions and Direct Verification (Verifying Directly with the OpenID Provider). Altering signed fields without the shared secret requires breaking the MAC. Currently no tractable attack is known on the MACs used in this protocol. The quality of the protection provided by the MAC depends on the randomness of the shared MAC key, so it is important that an unguessable value be used.

関連付けは発見と関連付けセッションと直接照合(Direct Verification) (Verifying Directly with the OpenID Provider)の間を除いて中間者による署名されたフィールドの改ざんを防ぎます。共有秘密鍵なしに署名されたフィールドを変更する事はMACを壊す事を要求します。現在はこのプロトコルにおいて使われるMACに関する扱いやすい攻撃は知られていません。MACによって提供される保護の質は共有されたMACキーの無作為性に依存する為、推測不可能な値が使われる事が重要です。

If DNS resolution or the transport layer is compromised signatures on messages are not adequate, since the attacker can impersonate the OP and issue its own associations, or its own decisions in Stateless Mode. If an attacker can tamper with the discovery process they can specify any OP, and so does not have to impersonate the OP. Additionally, if an attacker can compromise the integrity of the information returned during the discovery process, by altering the XRDS document, the need for a man in the middle is removed. One method to prevent this sort of attack is by digitally signing the XRDS file as per XMLDSIG (Eastlake 3rd, D., Reagle Jr., J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing,” .) [RFC3275]. The keying material is not specified, since the RP ultimately needs to make its own decision whether to trust keys used for such signature.

もしDNS解決かトランスポート層が危うくされるなら、攻撃者はOPを装う事ができ、自身の関連付けかステートレスモードでの自身の解決を発行するので、メッセージの署名は妥当ではありません。もし攻撃者が発見プロセスに干渉できるなら、何かのOPを指定できるので、OPを装う必要がありません。さらに、もし攻撃者が、XRDSドキュメントを変える事によって、発見プロセスの間に返された情報の完全な状態を危うくできるなら、中間者は取り除かれなければなりません。この種類の攻撃を防ぐ為の1つの方法は、XMLDSIG (Eastlake 3rd, D., Reagle Jr., J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing,” .) [RFC3275]に従った、XRDSファイルのデジタル署名です。鍵をかけている材料は、RPが最終的にそのような署名の為に使った鍵を信頼するかどうかを自身で決定する事を必要とするまで、指定されません。

Using SSL with certificates signed by a trusted authority prevents these kinds of attacks by verifying the results of the DNS look-up against the certificate. Once the validity of the certificate has been established, tampering is not possible. Impersonating an SSL server requires forging or stealing a certificate, which is significantly harder than the network based attacks.

信頼された権威機関によって署名された証明書によるSSLの利用は、証明書を考慮したDNSルックアップの結果の照合によってこれらの攻撃の種類を防ぎます。証明書の正当性が確立されているとき、改ざんは不可能です。SSLサーバの偽装は証明書の鍛造や窃盗を要求し、それはネットワークベースの攻撃よりも著しく過酷です。

In order to get protection from SSL, SSL must be used for all parts of the interaction, including interaction with the end user through the User-Agent. While the protocol does not require SSL be used, its use is strongly RECOMMENDED. Current best practices dictate that an OP SHOULD use SSL, with a certificate signed by a trusted authority, to secure its Endpoint URL as well as the interactions with the end user's User-Agent. In addition, SSL, with a certificate signed by a trusted authority, SHOULD be used so that a Relying Party can fetch the end user's URL in a secure manner. Following its own security policies, a Relying Party MAY choose to not complete, or even begin, a transaction if SSL is not being correctly used at these various endpoints.

SSLから保護を得る為に、SSLはUser-Agentを通したエンドユーザとの対話を含む、対話の全てのパートに関して使われなければなりません。プロトコルがSSLが使われる事を要求しない間、その利用が強く推奨されます。現在のベストプラクティスは、そのEndpoint URLのみならずエンドユーザのUser-Agentとの対話を安全にする為にも、OPが信頼された権威機関に署名された証明書とともにSSLを使うべきだと指示します。さらに、 信頼された権威機関に署名された証明書によるSSLは、RPが安全な方法でエンドユーザのURLを取り出す事が出来る様にするために使われるべきです。次に述べるそれ自身のセキュリティポリシーで、SSLがこれらの多くのエンドポイントで正しく使われないなら、RPはトランザクションを完了しないか開始しないかを選ぶかもしれません。



 TOC 

15.1.2.1.  Rogue Relying Party Proxying (RP詐称プロキシ)

A special type of man-in-the-middle attack is one where the Relying Party is a rogue party acting as a MITM. The RP would perform discovery on the End User's Claimed Identifier and instead of redirecting the User Agent to the OP, would instead proxy the OP through itself. This would thus allow the RP to capture credentials the End User provides to the OP. While there are multiple ways to prevent this sort of attack, the specifics are outside the scope of this document. Each method of prevention requires that the OP establish a secure channel with the End User.

中間者攻撃の特別な種類はRPがMITMとしてふるまう詐称者であるものです。RPはエンドユーザのClaimed Identifier上で発見を行い、User-AgentをOPにリダイレクトする代わりに、自身を通るOPの代わりのプロキシとなります。従って、エンドユーザがOPに提供するクレデンシャルをキャプチャする事をRPに許可するでしょう。 この種類の攻撃を防ぐ為の複数の方法があるので、その詳細はこのドキュメントの範囲外です。それぞれの予防の方法はOPがエンドユーザとの安全なチャネルを確立する事を要求します。



 TOC 

15.2.  User-Agents

Since this protocol is intended to be used interactively, User-Agents will primarily be common Web browsers. Web browsers or their hosts may be infected with spyware or other malware, which limits the strength of the authentication assertion, since untrusted software makes it impossible to know whether the authentication decision has been made with the end user's approval. With that said, many web applications and protocols today rely on the security of the Web browser and their hosts.

このプロトコルが対話的に使われる事が意図されるなら、User-Agentはおおむね一般的なウェブブラウザでしょう。ウェブブラウザかそれらのホストはスパイウェアやその他のマルウェアによって汚染されるかもしれず、信頼されないソフトウェアは認証の解決がエンドユーザの承認によるものであるかを知る事を不可能にするので、それは認証の主張の耐久力に限界をもうけます。

Cross-site-scripting attacks against OPs may be used to the same effect. For the best security, OPs should not depend on scripting. This enables User-Agents that do not support scripting, or have scripting disabled, to still employ the protocol.

OPに対するクロスサイトスクリプティング攻撃は同じ影響の為に使われるかもしれません。最良のセキュリティのために、OPはスクリプティングに依存すべきではありません。これは プロトコルを利用する間、スクリプティングをサポートしないかスクリプティングが無効であるUser-Agentを許可します。



 TOC 

15.3.  User Interface Considerations (UI考察)

The Relying Party SHOULD redirect the end user to the OP Endpoint URL in a top-level browser window with all controls visible. This allows better protection for the end user against OP look-alike sites (phishing).

RPは全てのコントロールが目に見える状態のトップレベルのブラウザウィンドウの中でエンドユーザをOP Endpoint URLにリダイレクトすべきです。これはエンドユーザに対してOPの様に見えるサイト(phishing)に備えるより良い保護を与えます。

OpenID Providers SHOULD educate their end users about the potential for OpenID phishing attacks and SHOULD equip their end users with the tools to defeat such attacks, for example browser plug-ins that verify the authenticity of the OP's Authentication Service Endpoint URL.

OPはOpenIDのフィッシング攻撃の可能性について、エンドユーザを教育すべきで、そしてそのような攻撃を無効にする為の、例えばOPの認証サービスエンドポイントURLの信頼性を立証するブラウザプラグインのような、ツールの利用をれらのエンドユーザに身につけさせるべきです。



 TOC 

15.4.  HTTP and HTTPS URL Identifiers

While these types of Identifiers have been previously discussed (HTTP and HTTPS URL Identifiers), they are worth mentioning again. As previously stated, the RECOMMENDED method of an End User expressing control over a URL differing only be scheme is to setup a redirect from the HTTP URL to the HTTPS URL. Relying Parties will never store the HTTP URL as during the discovery and initiation phase will follow the redirect and use the HTTPS URL as the Claimed Identifier.

これらの種類のIdentifierがあらかじめ議論(previously discussed) (HTTP and HTTPS URL Identifiers)いるなら、それらは価値ある言及です。あらかじめ述べた様に、スキームのみが異なるURLに関するエンドユーザの明確なコントロールの推奨される方法はHTTP URLからHTTPS URLへのリダイレクトをセットアップする事です。RPは発見の間のようにHTTP URLを決して記憶しないでしょうし、開始フェイズはリダイレクトに従うでしょうし、Claimed IdentifierとしてHTTPS URLを使います。

End users with concerns over this recommendation should directly enter their HTTPS URL at each Relying Party. This thus removes the step where the Relying Party follows the redirect to the HTTPS URL. The single security consideration currently seen is if an attacker were to compromise the integrity of the HTTP URL by removing the redirect and pointing the Identifier at a rogue OP. This however will alter the user experience, is detectable by anti-phishing technologies, and the security of the Identifier itself is a fundamental principle within OpenID.

この忠告に関して関心をもつエンドユーザはそれぞれのRPでそれらのHTTPS URLを直接記入すべきです。これはしたがってRPがHTTPS URLへのリダイレクトを追いかけるステップを取り除きます。現在目に見えるその単独のセキュリティ考察は、攻撃者がリダイレクトを取り除きする事と詐称OPでIdentifierを示す事によってHTTP URLの完全な状態を危うくする事です。これはしかしながらユーザエクスペリエンスを変えるでしょうし、アンチフィッシング技術によって見破られますし、Identifier自身のセキュリティはOpenIDに関する根本的な本質です。



 TOC 

15.5.  Denial of Service Attacks (サービス拒否攻撃)

Within the protocol there are places where a rogue RP could launch a denial of service attack against an OP since there is nothing in OpenID protocol messages that allows the OP to quickly check that it is a genuine request. This can be done by the RP repeatedly requesting associations, authentication, or verification of a signature.

OPにそれが本物のリクエストである事の素早い確認を許すようなOpenIDメッセージはないので、プロトコルには、はぐれRPがOPに対してサービス拒否攻撃を始める事が出来るだろう機会があります。これは、関連づけや認証や署名の照合をRPが繰り返しリクエストする事によって、行われる事があります。

The potentially most severe attack is during the association phase as each message requires the OP to execute a discrete exponentiation. Since the RP has the ability to specify modulus and generator per message, an attacker can even force the OP to perform this exponentiation in real time prior to responding for each message.

潜在的に最も危険な攻撃は、それぞれのメッセージがOPに離散の累乗を実行する事を要求する際の関連づけフェイズの間にあります。RPがメッセージによって係数(p)とジェネレータ(g)を指定する能力を持つため、攻撃者はOPに、それぞれのメッセージの応答に先立ってリアルタイムでこの累乗を行う事を、いっそう強制する事が出来ます。

While this could be particularly harmful, OpenID Providers can easily use generic IP based rate-limiting and banning techniques to help combat these sorts of attacks. OPs can also look at banning requests based on the "openid.realm" and "openid.return_to" values.

これが著しく有害なのに対し、OPはこれらの種類の攻撃への反抗の助けに、一般的なIPベースのレート制限と追放テクニックを容易に使う事が出来ます。OPはまた、"openid.realm"と"openid.return_to"の値を基に、リクエストの追放を考慮する事も出来ます。



 TOC 

15.6.  Protocol Variants

The following are known variations in the protocol which may or may not directly affect the security of the use of the protocol. It is imagined that these values could be used in the creation of security profiles for this protocol. The following list of variants are from the perspective of an OpenID Provider.

次に述べるものは、プロトコルにおいて、プロトコル利用のセキュリティに直接作用するかもしれないし、しないかもしれない、既知のバリエーションです。これらの評価はこのプロトコルに対するセキュリティ分析表の作成に使われるだろう事が想定されます。次に述べる形態の一覧はOPの視点からです。

NumberVariantValues
1. Are wildcards allowed in realms?

realmでワイルドカードが許可されますか?

One of Yes/No
2. Require prior association? Does the OP require the RP first create an association before requesting authentication?

前もった関連付けが要求されますか?OPはRPが最初に認証を要求する前に関連づけを作る事を要求しますか?

One of Yes/No
3. Types of claimed identifiers accepted.

受け付けられるClaimed Identifierのタイプ。

Set of HTTP/HTTPS/XRI
4. Are self-issued certificates allowed for authentication? This applies to all SSL traffic. If 'no' here, then OP *probably* requires all HTTPS identifiers to chain up to known trust roots, but that's intentionally not implied.

自身で発行した証明書が認証の為に許可されますか?これは全てのSSLトラフィックに適用します。もし'no'なら、OPは全てのHTTPS identifierに既知の信頼するルート証明機関に至までつなぐことを要求する*かもしれません*が、それは意図的にそれとなくほのめかされます。

One of Yes/No
5. Must the XRDS file be signed? Signature on the XRDS as per XMLDSIG. Keying material not specified, since the RP ultimately needs to make own decision whether to trust keys used for such signature.

XRDSファイルは必ず署名されますか?XRDSに対する署名はXMLDSIGに従います。鍵をかけている材料は、RPは結局そのような署名の為に使われるキーを信頼するかどうかは自身での解決を行う必要があるので、指定されません。

One of Yes/No
6. Must the XRDS file be retrieved over secure channel? This does not imply SSL?

XRDSファイルは必ずセキュアチャンネルによって取得されますか?これはSSLを含まないのですか?

One of Yes/No
7. What types of session types can be used when creating associations?

関連漬けを作るときにどんなセッションタイプの種類が使われる事が出来ますか?

Set of no-encryption/DH-SHA1/DH-SHA256
8. Must the RP have an XRDS document?

RPは必ずXRDSドキュメントを持ちますか?

One of Yes/No
9. What association types the OP agrees to use for signatures?

どんな関連づけタイプを署名に使う為にOPは許可しますか?

Set of HMAC-SHA1/HMAC-SHA256
10. Must the association request take place over secure channel?

関連づけリクエストは必ずセキュアチャンネルによって扱われますか?

One of Yes/No

Identified security variants.



 TOC 

Appendix A.  Examples

Non-normative



 TOC 

Appendix A.1.  Normalization (正規化)

See section 6 of [RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) for textual URL normalization details and more examples.

本文のURL正規化の詳細と更なる例に関しては[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .)のsection 6を見てください。



User's InputIdentifierTypeDiscussion
example.com http://example.com/ URL A URI with a missing scheme is normalized to a http URI

スキームなしのURIはhttpのURIに正規化されます。

http://example.com http://example.com/ URL An empty path component is normalized to a slash

空のパスコンポーネントはスラッシュに正規化されます。

https://example.com/ https://example.com/ URL https URIs remain https URIs

httpsのURIはhttpsのURIのままです。

http://example.com/user http://example.com/user URL No trailing slash is added to non-empty path components

空でないパスコンポーネントにはスラッシュは追加されません。

http://example.com/user/ http://example.com/user/ URL Trailing slashes are preserved on non-empty path components

末尾のスラッシュは空でないパスコンポーネントについて保持されます。

http://example.com/ http://example.com/ URL Trailing slashes are preserved when the path is empty

末尾のスラッシュはパスが空のとき保持されます。

=example =example XRI Normalized XRIs start with a global context symbol

正規化されたXRIはグローバルコンテキストシンボルで始まります。

xri://=example =example XRI Normalized XRIs start with a global context symbol

正規化されたXRIはグローバルコンテキストシンボルで始まります。

 User's Input to Identifier Normalization 



 TOC 

Appendix A.2.  OP-Local Identifiers

An end user wants to use "http://www.example.com/" as their Claimed Identifier. The end user has an account with Example Provider, which functions as an OpenID Provider. The end user's OP-Local Identifier is "https://exampleuser.exampleprovider.com/".

エンドユーザがClaimed Identifierとして"http://www.example.com/"を使いたいと欲します。エンドユーザはOPとして機能する例えのプロバイダにアカウントを持っています。エンドユーザのOP-Local Identifierは"https://exampleuser.exampleprovider.com/"です。

In this scenario, with the proper configuration of Yadis or HTML-Based Discovery (see Section 7.3 (Discovery) and Appendix A.3 (XRDS) below), a Relying Party will discover the following information about the end user:

このセクションでは、YadisかHTML-Based Discovery(Section 7.3 (Discovery)Appendix A.3 (XRDS)を読んでください)に適した構成で、RPが次に述べるエンドユーザに関する情報を発見するでしょう。

Claimed Identifier
http://www.example.com/
OP-Local Identifier
https://exampleuser.exampleprovider.com/



 TOC 

Appendix A.3.  XRDS

For an end user to use "http://www.example.com/" as their Identifier, but have Relying Parties actually verify "https://exampleuser.exampleprovider.com/" with the OP Endpoint URL "https://www.exampleprovider.com/endpoint/", the following XML snippet should be present in the final XRD element in the XRDS file when discovery is preformed on "http://www.example.com/":

エンドユーザがそれらのIdentifierとして"http://www.example.com/"を使うために、RPはOP Endpoint URLの"https://www.exampleprovider.com/endpoint/"で"https://exampleuser.exampleprovider.com/"を実際に照合していなければなりませんが、次に述べるXMLの断片が"http://www.example.com/"でディスカバリが行われたときにXRDSファイルの中の最後のXRD要素として表現されるべきです。

<Service xmlns="xri://$xrd*($v*2.0)">
  <Type>http://specs.openid.net/auth/2.0/signon</Type>
  <URI>https://www.exampleprovider.com/endpoint/</URI>
  <LocalID>https://exampleuser.exampleprovider.com/</LocalID>
</Service>


 TOC 

Appendix A.4.  HTML Identifier Markup

To use "http://www.example.com/" as their Identifier, but have Relying Parties actually verify "http://exampleuser.livejournal.com/" with the OpenID Provider located at "http://www.livejournal.com/openid/server.bml", the following markup should be present in the <head> of the HTML document located by the identifier URL:

Identifierとして"http://www.example.com/"を使う為に、ただしRPは実際に"http://www.livejournal.com/openid/server.bml"に置かれたOPで"http://exampleuser.livejournal.com/"を照合していますが、次に述べるマークアップがidentifierのURLに位置するHTMLドキュメントの<head>で表現されるべきです。

<link rel="openid2.provider openid.server"
      href="http://www.livejournal.com/openid/server.bml"/>
<link rel="openid2.local_id openid.delegate"
      href="http://exampleuser.livejournal.com/"/>


 TOC 

Appendix A.5.  XRI CanonicalID

For example, if the XRI i-names =example and =exmpl both yield an XRDS document with the CanonicalID xri://(example)!1234 then those Identifiers should be treated as equivalent. For applications with user accounts, the persistent Canonical ID xri://(example)!1234 should be used the primary key for the account. Although the i-names =example and =exmpl may also be stored for reference as display names, they are reassignable identifiers and should not be used as persistent keys.

例えば、もしXRIのi-namesが=exampleと=exmplの両方でCanonicalIDであるxri://(example)!1234に関するXRDSドキュメントをもたらすなら、これらのIdentifierは同等であるとして扱われるべきです。ユーザアカウントを持つアプリケーションについて、永続的なCanonicalIDであるxri://(example)!1234はそのアカウント為の主要なキーとして使われるべきです。とはいえ、i-namesの=exampleと=exmplはまた表示名称として参照する為に記憶されるかもしれず、それらは再割当可能なidentifierであって永続的なキーとして使われるべきではありません。



 TOC 

Appendix B.  Diffie-Hellman Key Exchange Default Value (Diffie-Hellman鍵交換のデフォルト値)

This is a confirmed-prime number, used as the default modulus for Diffie-Hellman Key Exchange. In hexadecimal:

これは、Diffie-Hellman鍵交換の標準係数として利用した、確認済み素数です。16進法で:

DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61E
F75A2E27898B057F9891C2E27A639C3F29B60814581CD3B2CA3986D268370557
7D45C2E7E52DC81C7A171876E5CEA74B1448BFDFAF18828EFD2519F14E45E382
6634AF1949E5B535CC829A483B8A76223E5D490A257F05BDFF16F2FB22C583AB


 TOC 

Appendix C.  Acknowledgements (謝辞)

The OpenID Community would like to thank the following people for the work they've done in the drafting and editing of this specification. If you want to know the nitty gritty of who actually wrote what, feel free to look at our SVN repository or even use "svn blame". :) http://openid.net/svn/specifications/authentication/2.0/

OpenIDコミュニティは次に述べる人々によるこの仕様書の草案や編集に関する貢献を感謝したいと思います。もしあなたが誰が実際に何を書いたのかの核心を知りたいのなら、我々のSVNレポジトリを自由に 調べるか同様に"svn blame"を使ってください。:)
http://openid.net/svn/specifications/authentication/2.0/

Barry Ferg (barry@sxip.com)

Brad Fitzpatrick (brad@danga.com) <author>

Carl Howells (chowells@janrain.com)

David Recordon (david@sixapart.com) <author/editor>

Dick Hardt (dick@sxip.com) <author>

Drummond Reed (drummond.reed@cordance.net)

Hans Granqvist (hgranqvist@verisign.com)

Johannes Ernst (jernst@netmesh.us)

Johnny Bufu (johnny@sxip.com) <editor>

Josh Hoyt (josh@janrain.com) <author/editor>

Kevin Turner (kevin@janrain.com)

Marius Scurtescu (marius@sxip.com)

Martin Atkins (mart@degeneration.co.uk)

Mike Glover (mpg4@janrain.com)



 TOC 

16. Normative References

[FIPS180-2] U.S. Department of Commerce and National Institute of Standards and Technology, “Secure Hash Signature Standard,” FIPS 180-2.

Defines Secure Hash Algorithm 256 (SHA256)

[HTML401] W3C, “HTML 4.01 Specification.”
[RFC1750] Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,” RFC 1750.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” RFC 2104.
[RFC2119] Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616.
[RFC2631] Rescorla, E., “Diffie-Hellman Key Agreement Method,” RFC 2631.
[RFC3174] Eastlake, D. and P. Jones, “US Secure Hash Algorithm 1 (SHA1),” RFC 3174.
[RFC3275] Eastlake 3rd, D., Reagle Jr., J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing,” RFC 3275.
[RFC3339] Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps,” RFC 3339.
[RFC3548] Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” RFC 3548.
[RFC3629] Yergeau, F., “UTF-8, a transformation format of Unicode and ISO 10646,” RFC 3629.
[RFC3986] Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” RFC 3986.
[XRI_Resolution_2.0] Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02” (HTML, PDF).
[XRI_Syntax_2.0] Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0” (HTML, PDF).
[Yadis] Miller, J., “Yadis Specification 1.0” (PDF, ODT).


 TOC 

Author's Address

  specs@openid.net