OpenID认证2.0——最终版

Abstract

OpenID 认证提供了一种方式，可以让用户证明自己对某个 Identifier 拥有控制权。 它不需要 Relying Party 去访问用户的凭据比如密码或者其他的敏感信息比如电子邮件地址等。

OpenID 是分散的。不需要一个中央官方机构批准或注册 Relying Parties 或 OpenID Providers。 最终用户可以自由地选择使用哪个 OpenID Provider，并能在他们更换 OpenID Providers 时维护自己的 Identifier。

尽管协议中没有提出要求使用 JavaScript 或先进的浏览器， 然而认证方案能很好地使用“AJAX”样式的设置。 这就意味着用户可以不离开当前网页就能向 Relying Party 证明他的身份（Identity）。

OpenID 认证仅仅使用标准的 HTTP(S) 请求和响应， 因此它不需要 User-Agent 具有特殊能力或者其他客户端软件。 OpenID 不和 cookies 的使用或者 Relying Party 的其他任何具体机制或 OpenID Provider 的会话管理挂钩。 虽然使用该协议没有必要扩展 User-Agents，但可以简化用户操作。

用户信息或者其他信息的交换不包括在该规范中，在此协议上附加协议形成一个框架可解决此问题。 OpenID 认证的目的是提供一个基础服务，使它能在自由和分散的方式下携带用户数字标识。

Table of Contents

1.  符号与约定
2.  术语
3.  协议概述
4.  数据格式
    4.1.  协议消息
    4.2.  整数的表示
5.  通信类型
    5.1.  直接通信
    5.2.  间接通信
6.  产生签名
    6.1.  步骤
    6.2.  签名算法
7.  初始化及自动发现
    7.1.  初始化
    7.2.  规格化
    7.3.  自动发现
8.  创建Associations
    8.1.  Association会话请求
    8.2.  Association会话响应
    8.3.  Associations类型
    8.4.  Association会话类型
9.  请求认证
    9.1.  请求参数
    9.2.  域
    9.3.  即时请求
10.  响应认证请求
    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.  符号与约定

本文的关键词“必须”、“不能”、“必需的”、“将”、“将不”、“应该”、 “不应该”、“建议”、“可以”和“可选的”将由 [RFC2119] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .)解释。

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

2.  术语

标识：

一个 Identifier 可以是一个 “http” 或 “https” 的 URI，（本文档中一般称为 “URL”）， 或者一个XRI (Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” .) [XRI_Syntax_2.0]。 本文档定义了多种形式的标识，用来使用在不同的环境下。

用户代理：

用户的浏览器，需实现了 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,” .)的。

依赖方：

RP。要证明用户对某个标识拥有控制权的 Web 应用程序。

OpenID 提供方：

OP。 一个 OpenID 认证服务器，它能为依赖方提供断言，证实用户拥有某个标识。

OpenID 提供方终点 URL：

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

OpenID 提供方标识：

OpenID 提供方的标识。

User-Supplied 标识：

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

声称的标识：

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

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

OP-Local 标识：

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

3.  协议概述

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

4.  数据格式

4.1.  协议消息

OpenID Authentication（OpenID认证）协议消息全部是纯文本的键和值的映射形式。 这些键和值允许是Unicode字符集（UCS）。 当它们需要转换成字节或从字节转换回来时， 必须使用UTF-8 (Yergeau, F., “UTF-8, a transformation format of Unicode and ISO 10646,” .) [RFC3629]编码。

消息不能含有多个同名参数。

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

4.1.1.  键值表单编码

键值表单中的一个消息是由一系列的行组成。每行由一个键名开始，后跟一个冒号，然后是该键的值， 结束于一个换行符（UCS代码是10，“\n”）。键和值必能包含换行符，键也不能包含冒号。

额外的字符，包括空白符，不能出现在冒号或换行符的前后。 消息必须是用UTF-8编码产生的字节串。

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

4.1.2.  HTTP编码

发送给HTTP服务器的消息，必须用规范[HTML401] (W3C, “HTML 4.01 Specification,” .)中第 17.13.4节规定的方式进行编码。类似的，如果请求头信息中包含 “Content-Type”，那么也必须进行这样的编码。

请求消息中的所有键都必须用“openid.”作为前缀。这样可防止和认证消息 中的其它参数冲突。当消息以POST方式发送时，OpenID参数必须仅在POST 报文中。

所有的消息请求（GET或POST）都必须包含下面这些字段：

• openid.ns

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

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

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

• openid.mode

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

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

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

4.1.3.  例子

Non-normative

下面的例子将编码下面的消息：

键      | 值
--------+---------------------------
mode    | error
error   | This is an example message

键值表单编码：

mode:error
error:This is an example message

在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.  整数的表示

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

非正式例子：

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

5.  通信类型

5.1.  直接通信

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

5.1.1.  直接请求

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

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

5.1.2.  直接响应

给直接请求 (直接请求)的响应报文， 由键值对组成。响应的content-type应该设置为“text/plain”。

所有键值对消息必须包含下面的字段：

• ns

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

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

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

5.1.2.1.  成功响应

当服务器收到一个正确的请求是，必须返回一个HTTP状态码为200的响应。

5.1.2.2.  失败响应

如果一个请求的消息格式不正确或者包含无效参数，服务器必须返回一个状 态码为400的响应。响应主体必须包含下列键-值 (键值表单编码)消息：

• ns

  参见Section 5.1.2 (直接响应)。

• error

  值：人可理解的消息，用来指出错误原因。

• contact

  值：（可选的）服务器管理员联系地址。该地址可以是任意形式，因为它是 显示给人看的。

• reference

  值：（可选的）参考标记，如支持代码或者新闻blog的URL地址等。

OP可以给这个响应添加额外的字段。

5.2.  间接通信

在间接通信中，消息通过用户代理来传递。依赖方和OP都可以初始化间接通信。 间接通信用于认证请求 (请求认证)和认证响应 (响应认证请求)。

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

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

5.2.1.  HTTP重定向

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

5.2.2.  HTML表单重定向

键到值的映射可以通过返回给用户代理一个含有HTML表单的HTML页面来进行传输。 表单提交可以是自动的，比如使用JavaScript。

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

5.2.3.  间接通信失败响应

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

• openid.ns

  参见Section 4.1.2 (HTTP编码)。

• openid.mode

  值：“error”

• openid.error

  值：人可理解的消息，用来指出错误原因。

• openid.contact

  值：（可选的）服务器管理员联系地址。该地址可以是任意形式，因为它是显示给人看的。

• openid.reference

  值：（可选的）参考标记，如支持代码或者新闻blog的URL地址等。

服务器可以给这个响应添加额外的字段。

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

6.  产生签名

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

在产生MAC密钥时，应该按照规范[RFC1750] (Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,” .)来产生。

6.1.  步骤

产生消息签名的步骤如下：

1. 根据需要签名的消息（参见Section 10.1 (Positive Assertions)），决定签名的键列表。 签名的键列表必须是消息的一部分。列表存储于键“openid.signed”中。 值是以逗号分隔的键名列表，这些键需去掉前缀“openid.”。 这个算法仅用于以“openid.”开头的签名键。
2. 按照出现在“openid.signed”列表中的顺序， 在消息中找到每个前缀为“openid.”的键所对应的值。
3. 按照键-值表单编码 (键值表单编码)， 转换待签名的键-值为字节串。
4. 根据association类型 (创建Associations)选择签名算法。 对已转换的字节串执行该签名算法 (签名算法)。

6.2.  签名算法

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

如果支持，建议使用HMAC-SHA256。

7.  初始化及自动发现

7.1.  初始化

要初始化OpenID认证，依赖方应该呈现给用户一个表单，该表单包含一个可以输入User-Supplied标识的字段。

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

7.2.  规格化

用户的输入必须被规格化为如下所示的标识：

1. 如果用户的输入以“xri://”开始，则必须去掉该前缀，以便XRI能够以标准型使用。
2. 如果结果字符串的第一个字符是一个[XRI_Syntax_2.0] (Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” .) 的2.2.1节定义的XRI全局上下文符号（“=”、“@”、“+”、“$”、“!”）或“(”， 那么输入应该当作XRI处理。
3. 除此之外，输入应该当作http URL处理；如果输入的标识不包含一个“http”或“https”，则必须添加“http://”前缀。 如果URL含有一个片断（#后的部分），则必须连同“#”一起除去。查看Section 11.5.2 (HTTP and HTTPS URL Identifiers)了解更多信息。
4. URL标识必须通过下面2个方法进一步规格化，一是在获取其内容时跟随其重定向，二是最后应用[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .)第6节所提的规则来得到其最终的目的URL地址。 最终URL必须经依赖方记录为Claimed标识，并用于请求认证 (请求认证)。

参见规格化示例 (Normalization)。

7.3.  自动发现

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

1. 如果标识是一个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. 如果是一个URL，将首先尝试Yadis协议 (Miller, J., “Yadis Specification 1.0,” .) [Yadis]。 如果成功了，结果是一个XRDS文档。
3. 如果Yadis协议失败并没有得到有效的XRDS文档，或者在XRDS文档中没有找到服务条目 (OpenID服务元素)，将尝试通过URL进行基于HTML的自动发现 (基于HTML的自动发现)。

7.3.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,” .)中定义的优先级规则。

• OP终点URL
• 协议版本

如果用户没有输入OP标识，也会给出下面的信息：

• Claimed标识
• OP-Local标识

如果用户输入了OP标识，则没有Claimed标识。为了产生OpenID认证请求，当输入了OP标识时，必须把值 “http://specs.openid.net/auth/2.0/identifier_select”赋给Claimed标识和OP-Local标识。

7.3.2.  基于XRDS的自动发现

如果使用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服务元素

7.3.2.1.1.  OP标识元素

一个OP标识元素是一个包含了下列信息的<xrd:Service>元素：

内容为"http://specs.openid.net/auth/2.0/server"的<xrd:Type>标签。

内容为OP终点URL的<xrd:URI>标签。

7.3.2.1.2.  Claimed标识元素

一个Claimed标识元素是一个包含下列信息的<xrd:Service>元素：

内容为"http://specs.openid.net/auth/2.0/signon"的<xrd:Type>标签。

内容为OP终点URL的<xrd:URI>标签。

内容为OP-Local标识的<xrd:LocalID>标签（可选的）。

7.3.2.2.  抽取认证数据

一旦依赖方获得了一个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和CanonicalID元素

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

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

当使用XRI解释时，Canonical ID必须被用作Claimed标识。 要使XRI成为一个有效的标识，<ProviderID>和 <CanonicalID>必须在自动发现的XRDS文档中存在。

当使用URL标识时，CanonicalID元素如果存在则必须被忽略。

7.3.2.4.  附加信息

在OpenID认证2.0中，“openid”命名空间不再被使用。 而“xrd”命名空间是“xri://$xrd*($v*2.0)”。

考虑到已部署的代码的兼容性， 建议依赖方也接受<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），如果这些终点可用的话。

如果OP支持扩展（Section 12 (Extensions)）， 这些扩展应该作为附加的<xrd:Type>元素，列于<xrd:Service>中。

7.3.3.  基于HTML的自动发现

基于HTML的自动发现必须被依赖方支持。它只有在发现了Claimed标识时有用。 OP标识必须是支持自动发现的XRI或URL。

要使用基于HTML的自动发现，作为Claimed标识的URL所指的HTML文档必须可访问。 文档的HEAD元素中需：

包含一个LINK元素，必须带有属性“rel”设置为“openid2.provider”，“href”设置为OP终点URL。

可以包含一个LINK元素，带有属性“rel”设置为“openid2.local_id”，“href”设置为用户的OP-Local标识。

执行HTML自动发现时协议版本是“http://specs.openid.net/auth/2.0/signon”。

HTML文档所在的主机可以与用户的OP所在的主机不同。

“openid2.provider”和“openid2.local_id”的URL不能包含除了 “&amp;”、“&lt;”、“&gt;”和“&quot;”以外的实体。 其它的在HTML文档中无效的或者该文档的编码无法表示的字符， 必须以[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .)中描述的百分号-编码（%xx）机制编码。

正如OpenID认证1.1兼容模式 (OpenID Authentication 1.1 Compatibility)章节所讨论的， 这里提到的自动发现标签不同于以前版本的协议。 即使表达相同的数据，名字却改变了，这样就可以允许依赖方来决定所使用的协议的版本。 依赖方可能会遇到这样一个Claimed标识，这个标识使用基于HTML的自动发现来同时告知其1.1和2.0的提供方。

8.  创建Associations

依赖方和OpenID提供方之间的association建立一个共享密钥，用来验证随后的协议消息并减少交互次数。

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

8.1.  Association会话请求

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

8.1.1.  通用的请求参数

这些参数为所有association请求所通用：

• openid.ns

  参见Section 4.1.2 (HTTP编码)。

• openid.mode

  值：“associate”

• openid.assoc_type

  首选的association类型。 Association类型定义了后续消息的签名算法

  值：一个有效的association类型（Section 8.3 (Associations类型)）

• openid.session_type

  首选的association会话类型。定义传输中使用的加密association的MAC密钥的方法。

  值：一个有效的association会话类型（Section 8.4 (Association会话类型)）。

  注意：除非使用了传输层加密，否则不能使用“no-encryption”。

8.1.2.  Diffie-Hellman请求参数

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))

查看Section 8.4.2 (Diffie-Hellman Association会话)获得这些参数的更多信息。

注意：“btwoc”函数定义在Section 4.2 (整数的表示)。

8.2.  Association会话响应

一个association会话响应是一个从OP到依赖方的直接响应， 响应形式为键值对形式 (键值表单编码)。

8.2.1.  通用响应参数

• ns

  参见Section 5.1.2 (直接响应)。

• assoc_handle

  association handle作为后续消息中检索该association的关键词。

  值：长度为255或小于255个字符的字符串。必须仅由在33-126之间的ASCII字符（可打印的非空白字符）组成。

• session_type

  请求中的“openid.session_type”的值。 如果OP不愿意或者不支持这个association类型，它必须返回一个未成功的响应 (不成功的响应的参数)。

• assoc_type

  请求中的“openid.assoc_type”的值。 如果OP不愿意或者不支持这个association类型，它必须返回一个未成功的响应 (不成功的响应的参数)。

• expires_in

  该association的生命周期，单位秒。 过了这个时间，依赖方不能再使用这个association。

  值：用10进制的ASCII表示的一个整数。

8.2.2.  非加密的响应参数

• mac_key

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

8.2.3.  Diffie-Hellman响应参数

• dh_server_public

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

  描述：OP的Diffie-Hellman公钥。

• enc_mac_key

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

  描述：MAC密钥（共享密钥），用机密的Diffie-Hellman值加密。 由会话类型决定H是“SHA1”还是“SHA256”。

注意：“btwoc”函数定义在Section 4.2 (整数的表示)。

8.2.4.  不成功的响应的参数

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

• ns

  参见Section 5.1.2 (直接响应)。

• error

  值：人可理解的消息，指出为什么association请求失败。

• error_code

  值：“unsupported-type”

• session_type

  值：（可选的）OP支持的有效的association会话类型（Section 8.4 (Association会话类型)）。

• assoc_type

  值：（可选的）OP支持的有效的association类型（Section 8.3 (Associations类型)）。

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

8.3.  Associations类型

8.3.1.  HMAC-SHA1

类型为“HMAC-SHA1”的association，使用 HMAC-SHA1 (签名算法)签名算法。

8.3.2.  HMAC-SHA256

类型为“HMAC-SHA256”的association，使用HMAC-SHA256 (签名算法)签名算法。

8.4.  Association会话类型

OpenID认证定义了3个有效的association会话类型："no-encryption"、"DH-SHA1"和"DH-SHA256"。

8.4.1.  No-Encryption Association会话

在一个“no-encryption”association会话中，OP以纯文本形式发送association MAC密钥给依赖方。 这使得在没有使用传输层加密时，监听者截取密钥，伪造消息给依赖方成为可能。 因此，“no-encryption”association会话不能使用，除非消息使用传输层加密。 查看Section 15.1.1 (Eavesdropping Attacks)获得更多信息。

OP发送的MAC密钥的长度必须是请求的association类型中指定的，参见Section 6.2 (签名算法)。

8.4.2.  Diffie-Hellman Association会话

“DH-SHA1”和“DH-SHA256”association类型使用Diffie-Hellman密钥交换安全地传输共享密钥。

MAC密钥必须与哈希函数H的输出值长度相同──DH-SHA1为160位（20字节）或DH-SHA256为256位（32字节）， 也即该association的签名算法的输出值。

依赖方指定一个模数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.  请求认证

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

9.1.  请求参数

• openid.ns

  参见Section 4.1.2 (HTTP编码)。

• openid.mode

  值：“checkid_immediate”或“checkid_setup”

  注意：如果依赖方希望用户能和OP交互，应该使用“checkid_setup”。 有一种情况是用户和OP之间没有交互请求，例如认证请求是在JavaScript中以异步的方式进行。

• openid.claimed_id

  值：（可选的）Claimed标识。

  如果两者都没有出现，那么断言则不是关于一个标识的， 而会在它的请求中使用扩展 (Extensions)包含其它信息。

  建议OP接受所有的XRI标识，不论是否有“xri://”前缀，参看规格化 (规格化)一节。

• openid.identity

  值：（可选的）OP-Local标识。

  如果没有指定一个和claimed标识不同的标识，那么claimed标识就必须作为openid.identity的值使用。

  注意：如果该值被设置为“http://specs.openid.net/auth/2.0/identifier_select”， 那么OP应该选择一个属于用户自己的标识。 如果请求不是关于一个标识的，那么这个参数可以忽略 （例如，使用扩展建立请求，使得即使没有这个参数，请求也是有意义的；参见上面的openid.claimed_id）。

• openid.assoc_handle

  值：（可选的）依赖方和OP之间的association的句柄，OP应该使用它来对响应进行签名。

  注意：如果没有发送association句柄，处理将会以无状态模式 (Verifying Directly with the OpenID Provider)进行。

• openid.return_to

  值：（可选的）OP应该返回给User-Agent的URL，响应表明了请求的状态。

  注意：如果请求中没有这个值，意味着依赖方不希望用户被返回。

  注意：return_to URL可以作为一种机制，用于依赖方附加关于请求的上下文给认证响应。 该文档没有定义一个特定的机制使得依赖方能确定查询参数没有被其它第三方修改。 这种机制可以由RP自己定义。

• openid.realm

  值：（可选的）OP应该询问用户信任的URL模式。参见Section 9.2 (域)。 如果openid.return_to被省略，那么这个值必须提供。

  默认：return_to URL

9.2.  域

域是一个范式，它代表着使得 OpenID 认证请求有效的 URL 的部分。 域用来给用户指示认证请求的范围。 在要求用户同意认证请求时，OP 应该呈现这个域。 这个域应该被 OP 用来唯一地确认 RP。 例如，OP 可以使用这个域来允许用户自动同意认证请求。

一个域范式类似一个 URL，但有如下不同：

• 域不能包含 URI 定位片断
• 域可以在开头节部分包含一个通配符。 通配符由字符“*.”组成，位于 DNS 名字前面。

一个 URL 匹配一个域，当且仅当：

• URL 方案和端口和域的完全相同。 关于 URI 匹配规则，参见RFC 3986 (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) [RFC3986]，3.1 章节。
• URL 的路径与域的路径相同或者是域的路径的子目录。
• 满足下面条件之一：
  1. 域的域名包含通配符“*.”，并且 URL 的域名的尾部和域中紧跟在通配符“*.”之后的部分相同，或者
  2. URL 的域名和域的域名相同。

当呈现的时候，“openid.return_to” URL 必须匹配“openid.realm”， 否则 OP 必须返回一个间接通信失败响应 (间接通信失败响应)。

建议 OP 保护他们的用户，禁止通过类似 http://*.com/ 或 http://*.co.uk/ 的过度通用的域进行断言。 当域用于标识一个特定的 RP 时，过度通用的域可能存在危险。 无论一个域是否过度通用，OP 都要谨慎对待。

9.2.1.  使用域对返回 URL 确认

OP 应该确认在请求中指定的 return_to URL 地址是 RP 的终点 URL。 要确认 return_to URL，需要通过在 RP 上执行自动发现 (Discovering OpenID Relying Parties)，得到针对该域的 RP 终点 URL。 当执行自动发现时，被发现的 URL 是上次 HTTP 响应的 URL，接下来进行重定向。 当针对该域执行自动发现时，如果有重定向发生，确认将会失败。 如果自动发现执行成功了，要确信 return_to URL 和某个 RP 终点一致。

一个域可能包含一个通配符，因此可能不是一个有效的 URL。 既然是那样，通过用“www”替代通配符部分，然后对该 URL 执行自动发现。

匹配 return_to URL 和一个 RP 端点，使用与匹配 return_to URL 和域相同的规则， 将 RP 的终点 URL 看作域。RP 终点 URL 必须不包含通配符，并且应该尽可能地具体。

如果确认经过尝试后失败了，OP 不应该发送肯定的断言给 return_to URL。

OP 可以缓存通过确认了的 return_to URL。

9.3.  即时请求

当请求认证时，RP可以要求OP不和用户交互。在这种情况下，OP必须直接给出响应， 它可能是一个说明认证成功的断言，也可以是一个表明由于没有更进一步的用户交互而使得请求没有完成的响应。 这通过一个将“openid.mode”设置为“checkid_immediate”的认证请求完成。

10.  响应认证请求

当一个认证请求是来自User-Agent通过间接通信 (间接通信)产生时， OP应该确认是一个经授权的用户希望完成认证。如果一个经授权的用户希望完成认证， OP应该发送一个肯定的断言 (Positive Assertions)给RP。

标识经授权用户的方法以及获得一个返回OpenID认证断言许可的方法超出了本规范的范围。 参见Section 15.1.2.1 (Rogue Relying Party Proxying)了解更多关于OP安全的考虑。

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.

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.

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

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.

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.

10.1.  Positive Assertions

Positive assertions are indirect responses (间接通信) with the following fields:

• openid.ns

  As specified in Section 4.1.2 (HTTP编码).

• openid.mode

  Value: "id_res"

• openid.op_endpoint

  The OP Endpoint URL.

• openid.claimed_id

  Value: (optional) The Claimed Identifier. "openid.claimed_id" and "openid.identity" SHALL be either both present or both absent.

  Note: The end user MAY choose to use an OP-Local Identifier as a Claimed Identifier.

  Note: If neither Identifier is present in the assertion, it is not about an identifier, and will contain other information in its payload, using extensions (Extensions).

• openid.identity

  Value: (optional) The OP-Local Identifier

  Note: OpenID Providers MAY assist the end user in selecting the Claimed and OP-Local Identifiers about which the assertion is made. The openid.identity field MAY be omitted if an extension is in use that makes the response meaningful without it (see openid.claimed_id above).

• openid.return_to

  Value: Verbatim copy of the return_to URL parameter sent in the request.

• openid.response_nonce

  Value: A string 255 characters or less in length, that MUST be unique to this particular successful authentication response. The nonce MUST start with the current time on the server, and MAY contain additional ASCII characters in the range 33-126 inclusive (printable non-whitespace characters), as necessary to make each response unique. The date and time MUST be formatted as specified in section 5.6 of [RFC3339] (Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps,” .), with the following restrictions:

  • All times must be in the UTC timezone, indicated with a "Z".
  • No fractional seconds are allowed

  For example: 2005-05-15T17:11:51ZUNIQUE

• openid.invalidate_handle

  Value: (optional) If the Relying Party sent an invalid association handle with the request, it SHOULD be included here.

• openid.assoc_handle

  Value: The handle for the association that was used to sign this assertion.

• openid.signed

  Value: Comma-separated list of signed fields.

  Note: This entry consists of the fields without the "openid." prefix that the signature covers. This list MUST contain at least "op_endpoint", "return_to" "response_nonce" and "assoc_handle", and if present in the response, "claimed_id" and "identity". Additional keys MAY be signed as part of the message. See Generating Signatures (产生签名).

  For example, "op_endpoint,identity,claimed_id,return_to,assoc_handle,response_nonce".

• openid.sig

  Value: Base 64 encoded signature calculated as specified in Section 6 (产生签名).

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 (间接通信).

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

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:

• openid.ns

  As specified in Section 4.1.2 (HTTP编码).

• openid.mode

  Value: "setup_needed"

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:

• openid.ns

  As specified in Section 4.1.2 (HTTP编码).

• openid.mode

  Value: "cancel"

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.

11.  Verifying Assertions

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

• The value of "openid.return_to" matches the URL of the current request (Section 11.1 (Verifying the Return URL))
• Discovered information matches the information in the assertion (Section 11.2 (Verifying Discovered Information))
• An assertion has not yet been accepted from this OP with the same value for "openid.response_nonce" (Section 11.3 (Checking the Nonce))
• The signature on the assertion is valid and all fields that are required to be signed are signed (Section 11.4 (Verifying Signatures))

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.

11.1.  Verifying the Return URL

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

• The URL scheme, authority, and path MUST be the same between the two URLs.
• Any query parameters that are present in the "openid.return_to" URL MUST also be present with the same values in the URL of the HTTP request the RP received.

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.

If the Claimed Identifier is included in the assertion, it MUST have been discovered (自动发现) 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.

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.

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.

This table shows the mapping of discovered information (自动发现的信息) into fields in the OpenID Authentication 2.0 "id_res" response (Positive Assertions)

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.

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 (自动发现的信息). 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.

11.3.  Checking the 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.

• When using "check_authentication", the OP MUST NOT issue more than one successful response to a request with the same value for "openid.response_nonce".
• When the Relying Party checks the signature on an assertion, the Relying Party SHOULD ensure that an assertion has not yet been accepted with the same value for "openid.response_nonce" from the same OP Endpoint URL.

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.

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

11.4.1.  Verifying with an Association

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

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.

11.4.2.  Verifying Directly with the OpenID Provider

To have the signature verification performed by the OP, the Relying Party sends a 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).

11.4.2.1.  Request Parameters

• openid.mode

  Value: "check_authentication"

• Exact copies of all fields from the authentication response, except for "openid.mode".

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.

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.

11.4.2.2.  Response Parameters

• ns

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

• is_valid

  Value: "true" or "false"; asserts whether the signature of the verification request is valid.

• invalidate_handle

  Value: (optional) The "invalidate_handle" value sent in the verification request, if the OP confirms it is invalid.

  Description: If present in a verification response with "is_valid" set to "true", the Relying Party SHOULD remove the corresponding association from its store and SHOULD NOT send further authentication requests with this handle.

  Note: This two-step process for invalidating associations is necessary to prevent an attacker from invalidating an association at will by adding "invalidate_handle" parameters to an authentication response.

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.

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.

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.

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.

11.5.2.  HTTP and HTTPS URL Identifiers

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.

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 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.

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.

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:

• assoc_handle
• assoc_type
• claimed_id
• contact
• delegate
• dh_consumer_public
• dh_gen
• dh_modulus
• error
• identity
• invalidate_handle
• mode
• ns
• op_endpoint
• openid
• realm
• reference
• response_nonce
• return_to
• server
• session_type
• sig
• signed
• trust_root

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.

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.

13.  Discovering OpenID Relying Parties

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.

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.

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

• Containing at least one <xrd:URI> element.
• Where all <xrd:URI> tags contain a URL that accepts OpenID 2.0 Authentication responses.
• Containing a <xrd:Type> tag whose content is "http://specs.openid.net/auth/2.0/return_to".

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>

14.  OpenID Authentication 1.1 Compatibility

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.

14.1.  Changes from OpenID Authentication 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.

14.1.1.  Updated Initiation and Discovery

• Supports OP Identifiers. This new variation of the protocol flow is initiated by an end user entering an OP Identifier instead of their own Identifier. This allows the OP to assist the end user in selecting an Identifier.
• Supports the use of XRIs as Identifiers. XRIs may be used as Identifiers for both end users and OPs, and provide automatic mapping from one or more reassignable i-names to a synonymous persistent Canonical ID that will never be reassigned.
• When URLs are used as Identifiers, they are normalized according to the guidelines in [RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .), for better compatibility with the existing Web infrastructure.
• Uses the Yadis protocol for discovery. This allows for using multiple OPs for a single Identifier, for load-balancing and fallback in the case of OP failure. Additionally, it allows for discovery of supported extensions and other associated services.

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.

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

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

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.

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

14.2.  Implementing OpenID Authentication 1.1 Compatibility

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.

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.

14.2.1.  Relying Parties

• When HTML discovery is performed, the OP endpoint URL is marked by the link relationship "openid.server" rather than "openid2.provider". The end user's OP-Local Identifier is marked by the link relationship "openid.delegate" rather than "openid2.local_id". The protocol version is in this case "http://openid.net/signon/1.1". HTML allows multiple link relationships to be specified for a single link, so if an OP provides both OpenID Authentication 1.1 and OpenID Authentication 2.0, "openid2.provider" and "openid.server" may appear in the same "rel" attribute.
• When XRDS-based discovery is performed, the end user's OP-Local Identifier appears in the <openid:Delegate> tag of the OpenID <xrd:Service> element rather than in the <xrd:LocalID> tag. In order to support currently-deployed discovery code, both tags MAY appear in the <xrd:Service> element.
• Relying Parties SHOULD extract and use OpenID Authentication 1.x service elements from XRDS documents, if Yadis succeeds on an URL Identifier. Such service elements are identified by <xrd:Type> tags whose text contents are "http://openid.net/server/1.0" or "http://openid.net/server/1.1". Although this is not specified in the previous version of the protocol, it is a generally accepted practice of advertising OpenID Authentication 1.x services through Yadis.
• "openid.claimed_id" is not defined by OpenID Authentication 1.1. Relying Parties MAY send the value when making requests, but MUST NOT depend on the value being present in authentication responses. When the OP-Local Identifier ("openid.identity") is different from the Claimed Identifier, the Relying Party MUST keep track of what Claimed Identifier was used to discover the OP-Local Identifier, for example by keeping it in session state. Although the Claimed Identifier will not be present in the response, it MUST be used as the identifier for the user.
• "openid.identity" MUST be sent in a authentication request (响应认证请求).
• Relying Parties MUST send a blank session_type parameter in "no-encryption" association requests.
• In OpenID Authentication 1.1, the "no-encryption" association session type is represented by a blank or missing "openid.session_type" parameter. Relying Parties MUST NOT send requests with "openid.session_type" set to "no-encryption".
• In authentication requests (请求认证), the "openid.identity" parameter SHOULD NOT be the special value "http://specs.openid.net/auth/2.0/identifier_select", because OpenID Authentication 1.1 does not support the use of OP Identifiers.
• The "openid.realm" parameter in authentication requests was known as "openid.trust_root". The syntax and meaning are identical.
• When responding with a negative assertion to a "checkid_immediate" mode authentication request, the "user_setup_url" parameter MUST be returned. This is a URL that the end user may visit to complete the request. The OP MAY redirect the end user to this URL, or provide the end user with a link that points to this URL.
• The Relying Party MUST accept an authentication response (Positive Assertions) that is missing the "openid.response_nonce" parameter. It SHOULD implement a method for preventing replay attacks.
• Relying Parties MUST accept authentication responses (Positive Assertions) that are missing the "openid.op_endpoint" parameter.

14.2.2.  OpenID Providers

• "openid.identity" MUST be sent in a positive authentication assertion (Positive Assertions).
• In OpenID Authentication 1.1, the "no-encryption" association session type is represented by a blank or missing "openid.session_type" parameter. OPs MUST NOT send responses with "openid.session_type" set to "no-encryption".
• OPs MAY choose to return a successful "no-encryption" response to any association request. As above, the "openid.session_type" parameter MUST be blank or omitted from the response.
• OPs MUST accept association requests with no assoc_type parameter, and assume them to be of type HMAC-SHA1.
• Unsuccessful association attempts MAY be responded with direct error messages or with "no-encryption" positive association responses.
• The "openid.realm" parameter in authentication requests was known as "openid.trust_root". The syntax and meaning are identical.
• When responding with a negative assertion to a "checkid_immediate" mode authentication request, the "user_setup_url" parameter MUST be returned. This is a URL that the end user may visit to complete the request. The Relying Party may redirect the end user to this URL, or provide the end user with a link that points to this URL.
• OPs MUST NOT send the "openid.op_endpoint" parameter in authentication responses (Positive Assertions), since it is not part of the OpenID Authentication 1.1 protocol.

15.  Security Considerations

15.1.  Preventing Attacks

15.1.1.  Eavesdropping Attacks

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

• If the nonce were not checked, an eavesdropper could also intercept a successful authentication assertion and re-use it.

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.

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.

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.

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.

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.

15.1.2.1.  Rogue Relying Party Proxying

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.

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.

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.

15.3.  User Interface Considerations

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

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.

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.

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.

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.

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.

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.

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.

Identified security variants.

Appendix A.  Examples

Non-normative

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.

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/".

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

Claimed Identifier

http://www.example.com/

OP-Local Identifier

https://exampleuser.exampleprovider.com/

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/":

<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>

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:

<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/"/>

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.

Appendix B.  Diffie-Hellman Key Exchange Default Value

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

DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61E
F75A2E27898B057F9891C2E27A639C3F29B60814581CD3B2CA3986D268370557
7D45C2E7E52DC81C7A171876E5CEA74B1448BFDFAF18828EFD2519F14E45E382
6634AF1949E5B535CC829A483B8A76223E5D490A257F05BDFF16F2FB22C583AB

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/

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)

16. Normative References

Author's Address