OpenID认证2.0——最终版

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 去访问用户的凭据比如密码或者其他的敏感信息比如电子邮件地址等。

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 Parties 或 OpenID Providers。 最终用户可以自由地选择使用哪个 OpenID Provider，并能在他们更换 OpenID Providers 时维护自己的 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”样式的设置。 这就意味着用户可以不离开当前网页就能向 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 不和 cookies 的使用或者 Relying Party 的其他任何具体机制或 OpenID Provider 的会话管理挂钩。 虽然使用该协议没有必要扩展 User-Agents，但可以简化用户操作。

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.

用户信息或者其他信息的交换不包括在该规范中，在此协议上附加协议形成一个框架可解决此问题。 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 创建Associations
    8.1.  Association Session Request Association会话请求
    8.2.  Association Session Response Association会话响应
    8.3.  Association Types 创建Associations类型
    8.4.  Association Session Types Association会话类型
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
    11.2.  Verifying Discovered Information
    11.3.  Checking the Nonce
    11.4.  Verifying Signatures
    11.5.  Identifying the end user
12.  Extensions
13.  Discovering OpenID Relying Parties
14.  OpenID Authentication 1.1 Compatibility
    14.1.  Changes from OpenID Authentication 1.1
    14.2.  Implementing OpenID Authentication 1.1 Compatibility
15.  Security Considerations
    15.1.  Preventing Attacks
    15.2.  User-Agents
    15.3.  User Interface Considerations
    15.4.  HTTP and HTTPS URL Identifiers
    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

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,” .).

本文的关键词“必须”、“不能”、“必需的”、“将”、“将不”、“应该”、 “不应该”、“建议”、“可以”和“可选的”将由 [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.

在整个文档中，值用引号标出以精确表示。当在协议消息中使用这些值时，引号不能作为值的一部分。

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]。 本文档定义了多种形式的标识，用来使用在不同的环境下。

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。要证明用户对某个标识拥有控制权的 Web 应用程序。

OpenID Provider:

OP. An OpenID Authentication server on which a Relying Party relies for an assertion that the end user controls an Identifier.

OpenID 提供方：

OP。 一个 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.

OpenID 提供方终点 URL：

接受 OpenID 认证协议消息的 URL， 它是通过对用户提供的标识执行自动发现时找到的。 这个值必须是一个绝对的 HTTP 或 HTTPS URL。

OP Identifier:

An Identifier for an OpenID Provider.

OpenID 提供方标识：

OpenID 提供方的标识。

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.

User-Supplied 标识：

由用户出示给依赖方的标识，或者是用户在 OpenID 提供方那里选择的标识。 在协议开始阶段，用户输入他们自己的标识或一个 OpenID 提供方标识。 如果是一个 OpenID 提供方标识，OpenID 提供方将协助用户来选择一个标识给依赖方。

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:

• The Identifier obtained by normalizing (Normalization 规格化) the User-Supplied Identifier, if it was an URL.
• The CanonicalID (XRI and the CanonicalID Element XRI和CanonicalID元素), if it was an XRI.

声称的标识：

用户声称自己拥有的标识；本协议的目标就是验证这个说法。 声称的标识可以是下面的任意一个：

• 如果它是一个 URL，则是从用户提供的标识 规格化 (Normalization 规格化)而来的标识。
• 如果是一个 XRI，则是 CanonicalID (XRI and the CanonicalID Element XRI和CanonicalID元素)。

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-Local 标识：

为用户提供的一个候补标识，定位到某一个 OpenID 提供方，因此不一定是在用户控制之下的。

3.  Protocol Overview 协议概述

1. The end user initiates authentication (Initiation 初始化) by presenting a User-Supplied Identifier to the Relying Party via their User-Agent.
2. 用户通过他们的用户代理向依赖方提供一个 User-Supplied 标识 初始化认证过程 (Initiation 初始化)。
3. 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).
4. 在规格化 (Normalization 规格化)了 User-Supplied 标识后，依赖方 执行自动发现 (Discovery 自动发现)来确定用户所使用的 OpenID 提供方终点 URL。需要注意的是，User-Supplied 标识也可以是一个 OpenID 提供方标识，
5. (optional) The Relying Party and the OP establish an association (Establishing Associations 创建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.
6. （可选的） 依赖方和OpenID提供方建立一个association (Establishing Associations 创建Associations)──使用Diffie-Hellman Key Exchange (Rescorla, E., “Diffie-Hellman Key Agreement Method,” .) [RFC2631] 密钥交换协议协商一个共享密钥。OpenID提供方用association对消息签名， 同时依赖方验证这些消息； 这就可以省略每次认证请求/响应的后续验证签名的直接请求。
7. The Relying Party redirects the end user's User-Agent to the OP with an OpenID Authentication request (Requesting Authentication 请求认证).
8. 依赖方让用户的用户代理带着认证请求 (Requesting Authentication 请求认证) 参数重定向到OpenID提供方。
9. 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.
10. OpenID 提供方确定用户是否有权并愿意接受OpenID认证。 至于用户如何向他们的OpenID提供方验证自己和其它的鉴别策略已超出本文档所描述的范围。
11. 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).
12. OpenID提供方让用户的用户代理重定向回依赖方，参数中指明是认证通过 (Positive Assertions)还是认证失败 (Negative Assertions)。
13. 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.
14. 依赖方校验 (Verifying Assertions)从OpenID提供方接受到的信息， 包括检查返回URL（Return URL），验证自动发现信息，检查nonce， 并用在association阶段建立的共享密钥或发送一个直接请求给OpenID提供方来验证签名。

4.  Data Formats 数据格式

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 Authentication（OpenID认证）协议消息全部是纯文本的键和值的映射形式。 这些键和值允许是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.

在这篇文档中，所有的OpenID消息参数都是必须的，除非特别指出为可选的。

4.1.1.  Key-Value Form Encoding 键值表单编码

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.

键值表单中的一个消息是由一系列的行组成。每行由一个键名开始，后跟一个冒号，然后是该键的值， 结束于一个换行符（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.

键值表单编码用于签名计算和给依赖方的直接响应 (Direct Response 直接响应)中。

4.1.2.  HTTP Encoding HTTP编码

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,” .)中第 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.”作为前缀。这样可防止和认证消息 中的其它参数冲突。当消息以POST方式发送时，OpenID参数必须仅在POST 报文中。

All messages that are sent as HTTP requests (GET or POST) MUST contain the following fields: 所有的消息请求（GET或POST）都必须包含下面这些字段：

• openid.ns

  值：“http://specs.openid.net/auth/2.0”

  This particular value MUST be present for the request to be a valid OpenID Authentication 2.0 request. Future versions of the specification may define different values in order to allow message recipients to properly interpret the request.

  对于一个OpenID认证2.0请求，该值必须在请求中存在。这个规范的 将来的版本可能会定义其它的值来让消息接受者正确地理解这一请求。

  If this value is absent or set to one of "http://openid.net/signon/1.1" or "http://openid.net/signon/1.0", then this message SHOULD be interpreted using OpenID Authentication 1.1 Compatibility mode (OpenID Authentication 1.1 Compatibility).

  如果这个值不存在或者被设置成“http://openid.net/signon/1.1” 或“http://openid.net/signon/1.0”，那么这个消息应该被解释为 使用OpenID认证1.1兼容模式 (OpenID Authentication 1.1 Compatibility)

• openid.mode

  值：不同的消息类型指定为不同的值。

  The "openid.mode" parameter allows the recipient of the message to know what kind of message it is processing. If "openid.mode" is absent, the party processing the message SHOULD assume that the request is not an OpenID message.

  参数“openid.mode”让消息接受者知道正在处理的是什么类型的消息。 如果没有“openid.mode”参数，我们处理消息时应该认为这个请求不是 一个OpenID消息。

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.

该模型可用于从用户代理发送消息给依赖方和OpenID提供方，也可用于从依赖方 发送给OpenID提供方。

4.1.3.  Example 例子

Non-normative

The following examples encode the following information: 下面的例子将编码下面的消息：

键      | 值
--------+---------------------------
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): 在HTTP POST报文体或在URL查询字符串 （[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .)第3节）中用x-www-urlencoded形式：

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

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.

任意精度的整数必须被表示为big-endian的补码。换句话说，“btwoc”是一个函数， 输入任意精度的整数，返回其最短的big-endian补码。所有用于Diffie-Hellman 密钥交换（Diffie-Hellman Key Exchange）的整数均为正数。这意味着补码的最 左边一位必须为零。如果不是，本协议的实现程序必须在这个串的前面添加一个零.

Non-normative example:非正式例子：

10进制数        | btwoc字符串表示
---------------+----------------------------
0              | "\x00"
127            | "\x7F"
128            | "\x00\x80"
255            | "\x00\xFF"
32768          | "\x00\x80\x00"

5.  Communication Types 通信类型

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 创建Associations) and verifying authentication assertions (Verifying Directly with the OpenID Provider).

直接通信由依赖方初始化，用于向OP终点URL提出申请。这用于 建立associations (Establishing Associations 创建Associations)和 验证认证断言 (Verifying Directly with the OpenID Provider)

5.1.1.  Direct Request 直接请求

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

消息必须被编码为POST报文体，参见Section 4.1.2 (HTTP Encoding HTTP编码)。

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

所有直接请求都是HTTP POST请求，并且包含Section 4.1.2 (HTTP Encoding HTTP编码)中列出的必需的字段。

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 直接请求)的响应报文， 由键值对组成。响应的content-type应该设置为“text/plain”。

All Key-Value form message MUST contain the following field: 所有键值对消息必须包含下面的字段：

• ns

  值： "http://specs.openid.net/auth/2.0"

  This particular value MUST be present for the response to be a valid OpenID 2.0 response. Future versions of the specification may define different values in order to allow message recipients to properly interpret the request.

  对于一个OpenID认证2.0响应，该值必须在响应中存在。这个规范的 将来的版本可能会定义其它的值来让消息接受者正确地理解这一请求。

  If this value is absent or set to one of "http://openid.net/signon/1.1" or "http://openid.net/signon/1.0", then this message SHOULD be interpreted using OpenID Authentication 1.1 Compatibility mode (OpenID Authentication 1.1 Compatibility).

  如果这个值不存在或者被设置为"http://openid.net/signon/1.1"或 "http://openid.net/signon/1.0"，那么这个消息应该被解释为使用 OpenID认证1.1兼容模式 (OpenID Authentication 1.1 Compatibility)

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的响应。

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 Encoding 键值表单编码)消息：

• ns

  As specified in Section 5.1.2 (Direct Response 直接响应).

  参见Section 5.1.2 (Direct Response 直接响应)。

• error

  值： A human-readable message indicating the cause of the error.人可理解的消息，用来指出错误原因。

• contact

  值：(optional) Contact address for the administrator of the sever. The contact address may take any form, as it is intended to be displayed to a person. （可选）服务器管理员联系地址。该地址可以是任意形式，因为它是 显示给人看的。

• reference

  值：(optional) A reference token, such as a support ticket number or a URL to a news blog, etc. （可选）参考标记，如支持代码或者新闻blog的URL地址等。

The OP MAY add additional fields to this response. OP可以给这个响应添加额外的字段。

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 响应认证请求).

在间接通信中，消息通过用户代理来传递。依赖方和OP都可以初始化间接通信。 间接通信用于认证请求 (Requesting Authentication 请求认证)和认证响应 (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 HTTP编码). The initiator of the communication chooses which method of indirect communication is appropriate depending on capabilities, message size, or other external factors.

间接通信有两种方法：HTTP重定向和HTML表单提交。 两种方法都需要发送者知道接受方的URL， 并且这个接受方的URL可接受一个间接通信消息。 参见Section 4.1.2 (HTTP Encoding HTTP编码)。 通信发起者选择使用哪种方法，取决于其能力、消息大小或其他外在因素。

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

所有间接消息以HTTP请求形式传送，并且包含Section 4.1.2 (HTTP Encoding HTTP编码)中列出的必需的字段。

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 HTTP编码).

数据可以通过发出302、303或307HTTP重定向给用户代理来进行数据传输。 重定向URL是接受者的URL，并在查询字符串中附加OpenID认证消息，参见 Section 4.1.2 (HTTP Encoding HTTP编码)。

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页面来进行传输。 表单提交可以是自动的，比如使用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 HTTP编码) when the form is submitted. The form MUST include a submit button.

<form>元素的“action”属性值必须是接受方的URL。每个键-值对必须 以<input>元素包含在表单中。键必须编码为“name”属性，值必须编码为 “value”属性，这样当表单被提交时，用户代理将产生一个如Section 4.1.2 (HTTP Encoding HTTP编码)所指定的消息。这个表单必须包含一个提交按钮。

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.

如果请求格式不正确，或者包含无效参数，OpenID提供方必须重定向用户代理 到“openid.return_to”的值所指的URL，前提是该值已给定并且是一个有效的URL。

• openid.ns

  As specified in Section 4.1.2 (HTTP Encoding HTTP编码).

  参见Section 4.1.2 (HTTP Encoding HTTP编码)。

• openid.mode

  值：“error”

• openid.error

  值：A human-readable message indicating the cause of the error.人可理解的消息，用来指出错误原因。

• openid.contact

  值：(optional) Contact address for the administrator of the sever. The contact address may take any form, as it is intended to be displayed to a person. （可选）服务器管理员联系地址。该地址可以是任意形式，因为它是显示给人看的。

• openid.reference

  值：(optional) A reference token, such as a support ticket number or a URL to a news blog, etc. （可选）参考标记，如支持代码或者新闻blog的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.

如果依赖方接受到一个错误格式或者无效信息，或者“openid.return_to”未指定或者 它的值不是一个正确的URL，服务器应该返回一个响应给用户，指出这个错误并使通信无法继续。

6.  Generating Signatures 产生签名

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

Association常以消息认证码（MAC）密钥的形式，来签署OpenID认证消息。

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,” .)来产生。

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." 根据需要签名的消息（参见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 键值表单编码)， 转换待签名的键-值为字节串。
4. Determine the signature algorithm from the association type (Establishing Associations 创建Associations). Apply the signature algorithm (Signature Algorithms 签名算法) to the octet string. 根据association类型 (Establishing Associations 创建Associations)选择签名算法。 对已转换的字节串执行该签名算法 (Signature Algorithms 签名算法)。

6.2.  Signature Algorithms 签名算法

OpenID Authentication supports two signature algorithms: OpenID认证支持两种签名算法：

• HMAC-SHA1 - 160位（[RFC2104] (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” .)和[RFC3174] (Eastlake, D. and P. Jones, “US Secure Hash Algorithm 1 (SHA1),” .)）
• HMAC-SHA256 - 256位（[RFC2104] (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” .)和[FIPS180‑2] (U.S. Department of Commerce and National Institute of Standards and Technology, “Secure Hash Signature Standard,” .)）

If supported, the use of HMAC-SHA256 is RECOMMENDED. 如果支持，建议使用HMAC-SHA256。

7.  Initiation and Discovery 初始化及自动发现

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认证，依赖方应该呈现给用户一个表单，该表单包含一个可以输入User-Supplied标识的字段。

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”属性应该为“openid_identifier”，这样用户代理可以自动识别这是一个OpenID表单。 如果该属性没有被恰当地设置，即使是支持OpenID认证的浏览器扩展或者其它软件，也可能检测不到该依赖方是支持OpenID认证的。

7.2.  Normalization 规格化

The end user's input MUST be normalized into an Identifier, as follows: 用户的输入必须被规格化为如下所示的标识：

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能够以标准型使用。
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,” .) 的2.2.1节定义的XRI全局上下文符号（“=”、“@”、“+”、“$”、“!”）或“(”， 那么输入应该当作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”，则必须添加“http://”前缀。 如果URL含有一个片断（#后的部分），则必须连同“#”一起除去。查看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标识必须通过下面2个方法进一步规格化，一是在获取其内容时跟随其重定向，二是最后应用[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .)第6节所提的规则来得到其最终的目的URL地址。 最终URL必须经依赖方记录为Claimed标识，并用于请求认证 (Requesting Authentication 请求认证)。

See normalization example (Normalization). 参见规格化示例 (Normalization)。

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: 自动发现是指依赖方使用标识来查寻（“发现”）初始化请求所必需的信息的过程。 OpenID认证有三种途径来实现自动发现：

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. 如果标识是一个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文档，该文档中包含了必要的信息。 需要指出的是，依赖方可以利用XRI代理解释器，如XDI.org在http://www.xri.net提供的一个。 这样依赖方就不用本地解析XRI了。
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协议 (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 OpenID服务元素) are found in the XRDS document, the URL is retrieved and HTML-Based discovery (HTML-Based Discovery 基于HTML的自动发现) SHALL be attempted. 如果Yadis协议失败并没有得到有效的XRDS文档，或者在XRDS文档中没有找到服务条目 (OpenID Service Elements OpenID服务元素)，将尝试通过URL进行基于HTML的自动发现 (HTML-Based Discovery 基于HTML的自动发现)。

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. 在成功完成自动发现后，依赖方会得到下面的一个或多个信息集合（参见术语 (Terminology 术语)中的定义）。 如果下面的多个信息集合被自动发现，需应用[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,” .)中定义的优先级规则。

• OP Endpoint URL OP终点URL
• Protocol Version 协议版本

If the end user did not enter an OP Identifier, the following information will also be present: 如果用户没有输入OP标识，也会给出下面的信息：

• Claimed Identifier Claimed标识
• OP-Local Identifier OP-Local标识

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标识，则没有Claimed标识。为了产生OpenID认证请求，当输入了OP标识时，必须把值 “http://specs.openid.net/auth/2.0/identifier_select”赋给Claimed标识和OP-Local标识。

7.3.2.  XRDS-Based Discovery 基于XRDS的自动发现

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文档。 这是一种XML文档，它包含标识中相关的服务条目。定义参见第三节 (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]。 参见Appendix A.3 (XRDS)中的XRDS文档示例。

7.3.2.1.  OpenID Service Elements OpenID服务元素

7.3.2.1.1.  OP Identifier Element OP标识元素

An OP Identifier Element is an <xrd:Service> element with the following information: 一个OP标识元素是一个包含了下列信息的<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终点URL的<xrd:URI>标签。

7.3.2.1.2.  Claimed Identifier Element Claimed标识元素

A Claimed Identifier Element is an <xrd:Service> element with the following information: 一个Claimed标识元素是一个包含下列信息的<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终点URL的<xrd:URI>标签。

An <xrd:LocalID> tag (optional) whose text content is the OP-Local Identifier. 内容为OP-Local标识的<xrd:LocalID>标签（可选的）。

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. 一旦依赖方获得了一个XRDS文档，它必须先从文档搜索（按照[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,” .)中描述的规则）OP标识元素。 如果没有找到，RP将搜索Claimed标识元素。

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. 当标识是一个XRI时，包含了OpenID认证<xrd:Service>元素的 <xrd:XRD>元素必须也包含一个<CanonicalID>元素。 元素的值必须被用作Claimed标识（参见Section 11.5 (Identifying the end user)）。这是出于安全考虑的， 因为<CanonicalID>元素的主要目的是断言一个不会被重新分配的持久标识， 这样可以阻止XRI被新注册者接管的可能。

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. 依赖方必须确认包含了<CanonicalID>元素的XRD提供者对于Canonical ID具有权威性， 并且XRDS文档对于OpenID服务元素具有权威性。 依赖方应该手动确认或者保证他们的解释器做这件事。

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标识。 要使XRI成为一个有效的标识，<ProviderID>和 <CanonicalID>必须在自动发现的XRDS文档中存在。

When using URL Identifiers, the CanonicalID element MUST be ignored if present. 当使用URL标识时，CanonicalID元素如果存在则必须被忽略。

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认证2.0中，“openid”命名空间不再被使用。 而“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 抽取认证数据) 考虑到已部署的代码的兼容性， 建议依赖方也接受<xrd:Type>的值是“http://openid.net/signon/1.0” 或“http://openid.net/signon/1.1”，正如OpenID认证1.1兼容模式 (OpenID Authentication 1.1 Compatibility)部分所描述的。 建议支持OpenID认证2.0的依赖方选择使用类型为 “http://specs.openid.net/auth/2.0/server” 和“http://specs.openid.net/auth/2.0/signon” 的终点（endpoints），如果这些终点可用的话。

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:Type>元素，列于<xrd:Service>中。

7.3.3.  HTML-Based Discovery 基于HTML的自动发现

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的自动发现必须被依赖方支持。它只有在发现了Claimed标识时有用。 OP标识必须是支持自动发现的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的自动发现，作为Claimed标识的URL所指的HTML文档必须可访问。 文档的HEAD元素中需：

A LINK element MUST be included with attributes "rel" set to "openid2.provider" and "href" set to an OP Endpoint URL 包含一个LINK元素，必须带有属性“rel”设置为“openid2.provider”，“href”设置为OP终点URL。

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元素，带有属性“rel”设置为“openid2.local_id”，“href”设置为用户的OP-Local标识。

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)章节所讨论的， 这里提到的自动发现标签不同于以前版本的协议。 即使表达相同的数据，名字却改变了，这样就可以允许依赖方来决定所使用的协议的版本。 依赖方可能会遇到这样一个Claimed标识，这个标识使用基于HTML的自动发现来同时告知其1.1和2.0的提供方。

8.  Establishing Associations 创建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. 依赖方和OpenID提供方之间的association建立一个共享密钥，用来验证随后的协议消息并减少交互次数。

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. 如果可能，建议依赖方形成association。如果依赖方没有创建和存储association的能力， Section 11.4.2 (Verifying Directly with the OpenID Provider)提供了一个候补的验证机制，即无状态模式。

8.1.  Association Session Request Association会话请求

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". 一个association会话由从依赖方到OP终点URL的直接请求 (Direct Communication 直接通信)初始化，在该请求中带有一个键“openid.mode”，其值为“associate”。

8.1.1.  Common Request Parameters 通用的请求参数

These parameters are common to all association requests: 这些参数为所有association请求所通用：

• openid.ns

  As specified in Section 4.1.2 (HTTP Encoding HTTP编码). 参见Section 4.1.2 (HTTP Encoding HTTP编码)。

• openid.mode

  值：“associate”

• openid.assoc_type

  The preferred association type. The association type defines the algorithm to be used to sign subsequent messages. 首选的association类型。 Association类型定义了后续消息的签名算法

  值：A valid association type from Section 8.3 (Association Types 创建Associations类型) 一个有效的association类型（Section 8.3 (Association Types 创建Associations类型)）

• openid.session_type

  The preferred association session type. This defines the method used to encrypt the association's MAC key in transit. 首选的association会话类型。定义传输中使用的加密association的MAC密钥的方法。

  值：A valid association session type from Section 8.4 (Association Session Types Association会话类型). 一个有效的association会话类型（Section 8.4 (Association Session Types Association会话类型)）。

  Note: Unless using transport layer encryption, "no-encryption" MUST NOT be used. 注：除非使用了传输层加密，否则不能使用“no-encryption”。

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": association会话类型是“DH-SHA1”或“DH-SHA256”的请求，下面的参数都通用：

• openid.dh_modulus

  值：base64(btwoc(p))

  默认值：参见Appendix B (Diffie-Hellman Key Exchange Default Value)

• openid.dh_gen

  值：base64(btwoc(g))

  默认值：g = 2

• openid.dh_consumer_public

  值：base64(btwoc(g ^ xa mod p))

See Section 8.4.2 (Diffie-Hellman Association Sessions Diffie-Hellman Association会话) for more information on these parameters. 查看Section 8.4.2 (Diffie-Hellman Association Sessions Diffie-Hellman Association会话)获得这些参数的更多信息。

NOTE: The 'btwoc' function is defined in Section 4.2 (Integer Representations整数的表示). 注：“btwoc”函数定义在Section 4.2 (Integer Representations整数的表示)。

8.2.  Association Session Response Association会话响应

An association session response is a direct response from the OP to the Relying Party in Key-Value Form (Key-Value Form Encoding 键值表单编码). 一个association会话响应是一个从OP到依赖方的直接响应， 响应形式为键值对形式 (Key-Value Form Encoding 键值表单编码)。

8.2.1.  Common Response Parameters 通用响应参数

• ns

  As specified in Section 5.1.2 (Direct Response 直接响应). 参见Section 5.1.2 (Direct Response 直接响应)。

• assoc_handle

  The association handle is used as a key to refer to this association in subsequent messages. association handle作为后续消息中检索该association的关键词。

  Value: A string 255 characters or less in length. It MUST consist only of ASCII characters in the range 33-126 inclusive (printable non-whitespace characters). 值：长度为255或小于255个字符的字符串。必须仅由在33-126之间的ASCII字符（可打印的非空白字符）组成。

• session_type

  The value of the "openid.session_type" parameter from the request. If the OP is unwilling or unable to support this association type, it MUST return an unsuccessful response (Unsuccessful Response Parameters 不成功的响应的参数). 请求中的“openid.session_type”的值。 如果OP不愿意或者不支持这个association类型，它必须返回一个未成功的响应 (Unsuccessful Response Parameters 不成功的响应的参数)。

• assoc_type

  The value of the "openid.assoc_type" parameter from the request. If the OP is unwilling or unable to support this association type, it MUST return an unsuccessful response (Unsuccessful Response Parameters 不成功的响应的参数). 请求中的“openid.assoc_type”的值。 如果OP不愿意或者不支持这个association类型，它必须返回一个未成功的响应 (Unsuccessful Response Parameters 不成功的响应的参数)。

• expires_in

  The lifetime, in seconds, of this association. The Relying Party MUST NOT use the association after this time has passed. 该association的生命周期，单位秒。 过了这个时间，依赖方不能再使用这个association。

  Value: An integer, represented in base 10 ASCII. 值：用10进制的ASCII表示的一个整数。

8.2.2.  Unencrypted Response Parameters 非加密的响应参数

• mac_key

  The MAC key (shared secret) for this association, Base 64 (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” .) [RFC3548] encoded. 该association的MAC密钥（共享密钥），用Base 64 (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” .) [RFC3548]编码。

8.2.3.  Diffie-Hellman Response Parameters Diffie-Hellman响应参数

• dh_server_public

  值：base64(btwoc(g ^ xb mod p))

  Description: The OP's Diffie-Hellman public key. 描述：OP的Diffie-Hellman公钥。

• enc_mac_key

  值：base64(H(btwoc(g ^ (xa * xb) mod p)) XOR MAC key)

  Description: The MAC key (shared secret), encrypted with the secret Diffie-Hellman value. H is either "SHA1" or "SHA256" depending on the session type. 描述：MAC密钥（共享密钥），用机密的Diffie-Hellman值加密。 由会话类型决定H是“SHA1”还是“SHA256”。

NOTE: The 'btwoc' function is defined in Section 4.2 (Integer Representations整数的表示) 注：“btwoc”函数定义在Section 4.2 (Integer Representations整数的表示)。

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不支持会话类型或者association类型，它必须返回一个直接的错误消息， 指出association请求失败。 如果有其它支持的association会话类型或association类型，OP应该在响应中包含这些信息。

• ns

  As specified in Section 5.1.2 (Direct Response 直接响应). 参见Section 5.1.2 (Direct Response 直接响应)。

• error

  Value: A human-readable message indicating why the association request failed. 值：人可理解的消息，指出为什么association请求失败。

• error_code

  Value: "unsupported-type" 值：“unsupported-type”

• session_type

  Value: (optional) A valid association session type from Section 8.4 (Association Session Types Association会话类型) that the OP supports. 值：（可选的）OP支持的有效的association会话类型（Section 8.4 (Association Session Types Association会话类型)）。

• assoc_type

  Value: (optional) An association type supported by the OP from Section 8.3 (Association Types 创建Associations类型). 值：（可选的）OP支持的有效的association类型（Section 8.3 (Association Types 创建Associations类型)）。

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”响应时， 依赖方可以用指定的association会话类型和association类型发送另一个请求。 如果没有association被创建，依赖方可以使用直接验证 (Verifying Directly with the OpenID Provider)继续认证过程。

8.3.  Association Types 创建Associations类型

8.3.1.  HMAC-SHA1

An association of type "HMAC-SHA1" uses the HMAC-SHA1 (Signature Algorithms 签名算法) signature algorithm. 类型为“HMAC-SHA1”的association，使用 HMAC-SHA1 (Signature Algorithms 签名算法)签名算法。

8.3.2.  HMAC-SHA256

An association of type "HMAC-SHA256" uses the HMAC-SHA256 (Signature Algorithms 签名算法) signature algorithm. 类型为“HMAC-SHA256”的association，使用HMAC-SHA256 (Signature Algorithms 签名算法)签名算法。

8.4.  Association Session Types Association会话类型

OpenID Authentication defines three valid association session types: "no-encryption", "DH-SHA1", and "DH-SHA256". OpenID认证定义了3个有效的association会话类型："no-encryption"、"DH-SHA1"和"DH-SHA256"。

8.4.1.  No-Encryption Association Sessions No-Encryption Association会话

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”association会话中，OP以纯文本形式发送association MAC密钥给依赖方。 这使得在没有使用传输层加密时，监听者截取密钥，伪造消息给依赖方成为可能。 因此，“no-encryption”association会话不能使用，除非消息使用传输层加密。 查看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密钥的长度必须是请求的association类型中指定的，参见Section 6.2 (Signature Algorithms 签名算法)。

8.4.2.  Diffie-Hellman Association Sessions Diffie-Hellman Association会话

The "DH-SHA1" and "DH-SHA256" association types use Diffie-Hellman Key Exchange to securely transmit the shared secret. “DH-SHA1”和“DH-SHA256”association类型使用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字节）， 也即该association的签名算法的输出值。

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,” .). 依赖方指定一个模数p和一个产生因子g。 依赖方选择一个随机密钥xa，OpenID提供方选择一个随机密钥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,” .)。

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 间接通信). 一旦依赖方成功地执行了自动发现， 并且（可选）和自动发现得到的OP终点URL创建了一个association， 它就可以发送一个认证请求给OP去获得一个断言。 一个认证请求是一个间接请求 (Indirect Communication 间接通信)。

9.1.  Request Parameters 请求参数

• openid.ns

  As specified in Section 4.1.2 (HTTP Encoding HTTP编码). 参见Section 4.1.2 (HTTP Encoding HTTP编码)。

• openid.mode

  Value: "checkid_immediate" or "checkid_setup" 值：“checkid_immediate”或“checkid_setup”

  Note: If the Relying Party wishes the end user to be able to interact with the OP, "checkid_setup" should be used. An example of a situation where interaction between the end user and the OP is not desired is when the authentication request is happening asynchronously in JavaScript. 注意：如果依赖方希望用户能和OP交互，应该使用“checkid_setup”。 有一种情况是用户和OP之间没有交互请求，例如认证请求是在JavaScript中以异步的方式进行。

• openid.claimed_id

  Value: (optional) The Claimed Identifier. 值：（可选的）Claimed标识。

  "openid.claimed_id" and "openid.identity" SHALL be either both present or both absent. If neither value is present, the assertion is not about an identifier, and will contain other information in its payload, using extensions (Extensions). “openid.claimed_id”和“openid.identity”应该成对出现或者都不出现。 如果两者都没有出现，那么断言则不是关于一个标识的， 而会在它的请求中使用扩展 (Extensions)包含其它信息。

  It is RECOMMENDED that OPs accept XRI identifiers with or without the "xri://" prefix, as specified in the Normalization (Normalization 规格化) section. 推荐OP接受所有的XRI标识，不论是否有“xri://”前缀，参看规格化 (Normalization 规格化)一节。

• openid.identity

  Value: (optional) The OP-Local Identifier. 值：（可选的）OP-Local标识。

  If a different OP-Local Identifier is not specified, the claimed identifier MUST be used as the value for openid.identity. 如果没有指定一个和claimed标识不同的标识，那么claimed标识就必须作为openid.identity的值使用。

  Note: If this is set to the special value "http://specs.openid.net/auth/2.0/identifier_select" then the OP SHOULD choose an Identifier that belongs to the end user. This parameter MAY be omitted if the request is not about an identifier (for instance if an extension is in use that makes the request meaningful without it; see openid.claimed_id above). 注意：如果该值被设置为“http://specs.openid.net/auth/2.0/identifier_select”， 那么OP应该选择一个属于用户自己的标识。 如果请求不是关于一个标识的，那么这个参数可以忽略 （例如，使用扩展建立请求，使得即使没有这个参数，请求也是有意义的；参见上面的openid.claimed_id）。

• openid.assoc_handle

  Value: (optional) A handle for an association between the Relying Party and the OP that SHOULD be used to sign the response. 值：（可选的）依赖方和OP之间的association的句柄，OP应该使用它来对响应进行签名。

  Note: If no association handle is sent, the transaction will take place in Stateless Mode (Verifying Directly with the OpenID Provider). 注意：如果没有发送association句柄，处理将会以无状态模式 (Verifying Directly with the OpenID Provider)进行。

• openid.return_to

  Value: (optional) URL to which the OP SHOULD return the User-Agent with the response indicating the status of the request. 值：（可选的）OP应该返回给User-Agent的URL，响应表明了请求的状态。

  Note: If this value is not sent in the request it signifies that the Relying Party does not wish for the end user to be returned. 注意：如果请求中没有这个值，意味着依赖方不希望用户被返回。

  Note: The return_to URL MAY be used as a mechanism for the Relying Party to attach context about the authentication request to the authentication response. This document does not define a mechanism by which the RP can ensure that query parameters are not