OpenID认证协议2.0中文版

《OpenID认证协议2.0中文版》由会员分享，可在线阅读，更多相关《OpenID认证协议2.0中文版（43页珍藏版）》请在装配图网上搜索。

1、OpenlD Authentication 2.0 -Implementor Draft 12OpenID 认证协议 2.0 草案 12Table of Contents1. 符号惯例 42. 术语 53. 协议概要 64. 数据格式 64.1 协议消息 64.1.1 键-值表单编码 64.1.2 HTTP 编码 74.1.3 例子 74.2 整数的表示 85. 通信类型 85.1 直接通信 85.1.1 直接通信请求 85.1.2 直接通信响应 85.1.2.1 成功响应 95.1.2.1 失败响应 95.2 间接通信 95.2.1 HTTP 重定向 95.2.2 HTML 表单重定向 95

2、.2.3 间接通信失败响应 106. 产生签名 106.1 步骤 106.2 签名算法 107. 初始化及自动发现 117.1初始化 117.2规格化 117.3 自动发现 117.3.1 自动发现的信息 117.3.2 基于 XRDS 的自动发现 127.3.2.1 OpenID 服务条目 127.3.3 基于 HTML 的自动发现 138. 创建 Association 138.1Association 会话请求 148.1.1 通用请求参数 148.1.2 Diffie-Hellman 请求参数 148.2 Association 会话响应 148.2.1 通用响应参数 158.2.2

3、非加密响应参数 158.2.3 Diffie-Hellman 响应参数 158.2.4 不成功响应参数 158.3 Association 类型 168.3.1HMAC-SHA1 168.3.2HMAC-SHA256 168.4 Association 会话类型 168.4.1 No-Encryption Association 会话 168.4.2 Diffie-Hellman Association 会话 169. 请求认证 179.1 请求参数 179.2 Realms 189.2.1 域 189.2.2使用域对返回 URL 确认 199.3 即时请求( Immediate Reques

4、ts) 1910. 响应认证请求 2010.1 肯定断言 2010.2 否定断言 2210.2.1 响应即时请求 2210.2.2 响应非即时请求 2211. 验证断言 2311.1 验证返回 URL 2311.2 验证发现的信息 2311.3 检查随机序列 2411.4 验证签名 2511.4.1 利用 Association 验证 2511.4.2同 OP 直接验证 2511.5 标识用户 2611.5.1 标识回收 2611.5.2 HTTP 和 HTTPS URL 标识 2612. 扩展 2713. RP 发现 2814. 与 OpenID 认证协议 1.1 版本兼容性 2914.1

5、自 1.1 版变更 2914.1.1 初始化与发现过程的更新 2914.1.2 安全改进 2914.1.3 扩展 3014.2 实现与 1.1 版兼容 3014.2.1 依赖方 (Relying Party) 3014.2.2 OpenID 提供方 (OpenID Providers) 3115. 安全考虑 3215.1 预防攻击 3215.1.1 窃听攻击 (Eavesdropping Attacks) 3215.1.2 中间人攻击 (Man-in-the-Middle Attacks) 3215.2 用户代理 3315.3 用户界面考虑 3315.4 HTTP 和 HTTPS URL 标识

6、3415.5拒绝服务攻击3415.6协议变量34附录A. 示例35附录A.1规范化35附录 A.2 OP-Local 标识36附录 A.3 XRDS 36附录A.4 HTML 标识记号 36附录 A.5 XRI CanonicalID 37附录B. Diffie-Hellman 密匙交换默认值 37Appe ndix C. Ack no wledgeme nts 3716. Normative References 38对照词汇表英文中文MUST必须MUST NOT必须不REQUIRED需要的SHALL应该SHALL NOT不应该SHOULD应该SHOULD NOT不应该RECOMMENDED

7、推荐MAY可以OPTIONAL可选的Identifier标识User-AgentUARelying PartyRPOpenlD ProviderOPOP Endpoint URLOP终点URL地址OP IdentifierOP标识User-Supplied IdentifierUser-Supplied 标识Claimed IdentifierClaimed 标识OP-Local IdentifierOP-Local 标识element条目tag标签Non-normative非正式example示例section节parameter参数assertiion断言user, end uesr用户a

8、ssociationassociati onassociation sessionassociati on 会话association session typeassociati on会话类型nonce随机序列realm域form表单request请求response响应Key-Value键-值Name-Value名-值message消息information信息Message Authentication CodeMACcontext上下文normalization规格化shared secret共享密匙note、八亠 注意stateless无状态initiation初始化discovery

9、自动发现field字段文档历史版本日期撰写人备注0.12007-09-18Xuxi Che n xchenttg.cc Zhe Zha ng zzhanqttq.ccSichua n Li slittq.ccDennv Wana dwanqttq.cc内容合并，初步校对0.22007-09-19Denny Wang dwanqttq.cc复查至第8章复查9-16章，并调整格式0.32007-09-20Zhe Zha ng zzhanqttq.cc0.42007-09-21Denny Wang dwanqttq.cc复查全文0.52007-9-22Zhe Zhang zzhanqtxc修改9-1

10、2章部分翻译1.符号惯例MUST 必须MUST NOT 必须不REQUIRED 需要的SHALL 应该SHALL NOT 不应该SHOULD 应该SHOULD NOT 不应该RECOMMENDED 推荐MAY 可以OPTIONAL 可选的在文档中，有些值是用引号引起来的，用来精确表示，在实际的协议消息中 必须不用引号。2.术语Identifier 标识标识为 HTTP或HTTPS形式的URI （本文中一般地指 URL ）或XRI（eXtensible Resource Identifier）（可扩展的资源标识符，是一套与 URI兼容的抽象标识符体系）。本 文有不同类型的标识，是考虑不同的环境情

11、景设计。User-Agent用户代理（简写为UA）一般为用户的浏览器，要实现HTTP/1.1 RFC2616 协议。Relying Party依赖方（简写为RP）是一个WEB应用程序，它需要证实某用户确拥有一个标识。OpenlD Provider Openld 提供方（简写为 0P）是一个提供验证OpenID标识的服务器，它能为 RP提供断言，证实用户拥有某个 标识。OP Endpoint URL OpenId 提供方（OP）终点 URL是一个用来接收 OpenID认证请求的URL ,它是通过用户提供的标识而找到的，这个URL必须是绝对地址。OP Identifier OpenId 提供方标识

12、是一个 OpenID Provider 的标识。User-Supplied Identifier User-Supplied标识是用户出示给RP的标识，或者是用户在 OP那里选择的标识，用户可以敲入自己 的标识也可以敲入 OP标识，如果是 OP标识，那OP要让用户选择一个标识给 RP。Claimed Identifier Claimed 标识是一个标识，用户声明自己拥有，本协议的目标就是查证他真的拥有该标识。这个标识可以是：如果是一个URL，是一个规格化后的 User-Supplied标识。如果是一个 XRI，则是一个 CanonicallD。OP-Local Identifier OP-Lo

13、cal 标识为用户提供的替代标识，定位到某一个op,并不是由用户控制的。3. 协议概要1. 用户通过UA（用户代理，通常为浏览器）向RP （依赖方）提供一个User-Supplied标 识，初始化认证过程。2. 在规格化User-Supplied标识之后，RP执行自动发现来获取认证所需的OP终点URL地址。需要注意的是用户提供的标识也可以是OP标识（将在7.3.1节中讨论），这允许用户在OP上选择一个Claimed标识，或者如果通过其它的一些扩展将容许没有Claimed 标识。3. （可选的）在 RP 和 OP 之间建立一个 association通过 Diffie-Hellman RFC26

14、31密钥交换协议协商共享密钥。OP用association对消息签名，同时RP验证这些消息。这就可省略在每次请求/响应后续验证签名的直接请求。4. RP让用户的浏览器重定向到 OP,并带上认证请求参数。5. OP确定这个用户是否有权并且愿意接受OpenID认证。至于用户如何鉴别 OP和其它的鉴别策略不是这个文档讲的范围。6. OP让用户的浏览器重定向返回 RP,参数中指明Authentication是认证通过还是认 证失败。7. RP校验从OP收到的信息。检查 Return URL，验证自动发现信息，检查nonce （随机序列），并用asscociation验证签名或发一个直接请求来验证。4.

15、 数据格式4.1协议消息OpenID Authentication （OpenID认证）协议消息全部是映射为文本的键值形式，这些键值允许是 Unicode字符集（UCS）,当它们转换成字节的时候，必须按照UTF-8 形式编码RFC3629。消息必须不能有同名的参数。在这篇文档中，所有的 OpenID消息都是必须的，除非特别申明为 可选的。，后跟一个4.1.1键-值表单编码键-值表单组成的消息是由一系列的行组成，每行开始是一个键名冒号，然后是该参数的值，结束于一个换行符（”n ”，UCS代码是10 ）。参数名和值都必须不包含换行符，参数名也必须不包含冒号。额外的字符，包括空白符，必须不出现在冒号

16、前后或换行符的前后。消息必须编码成UTF-8形式的字节串。键-值表单编码会用于签名计算和给RP的直接响应中。4.1.2 HTTP 编码发送给HTTP服务器的消息，必须用规范HTML401丨中第17.13.4节的规格编码。如果Content-Type”包含在请求头（Request Header）中，那么的报文体 也必须这样编码。所有的请求消息的名都 必须以openid.”作前缀。这样可防止与认证消息中的 其它参数冲突。当消息以“POST”方式发送时，OpenID参数必须只在Post报文体中。所有的消息请求（Get或Post）都必须包含下面的这些字段：ope nid.ns值：http:/specs

17、.ope nid.n et/auth/2.0”对于一个 OpenID认证2.0版的请求，该值必须在请求中存在。将来的版本 可能会定义其它的值来标识它的请求。如果这个值被省略或是 http: 或 http: ”，那么这个消息就 应该用与 OpenID认证1.1 版兼容的模式来处理。ope ned.mode值：参照消息类型的不同而不同。参数openid.mode让消息接受者知道被处理的是什么类型的消息。如果没有openid.mode参数，我们应该假设这不是一个 OpenID消息。该参数用于通过用户浏览器发送给依赖方RP和供应方OP,也用于从RP发给OP的消息。4.1.3例子耳非正式下面是要编码的消

18、息：Key | 值+mode| errorerror| This is an example message用键值表单的编码：mode:errorerror:This is an example message用x-www-urlencoded形式，也就是在 HTTP POST体中或URL地址的查询串 中（RFC3986第 3 节）：ope ni d.mode=error&ope ni d.error=This%20is%20a n%20example%20message4.2整数的表示任意精度的整数 必须被表示为big-endian的补码（btwoc）, Base64编码。换句话说， btw

19、oc 是一个函数，输入bigint 并返回 shortest big-endian 补码。所有用于Diffie-Hellman密钥交换的整数皆为正数。这意味着双字节的最左边位必须为零，如果不是，程序必须在这个串的前面加零。非正式例子:10进制数+| btwoc字符串表示0| x00127| x7F128| x00x80255| x00xFF32768| x00x80x005. 通信类型5.1直接通信直接通信由 RP初始化，用于向 0P终点URL提出申请，主要用于 创建Association和 验证认证断言。5.1.1直接通信请求请求消息必须按照POST方式编码，参见4.1.2节。所有直接通信请

20、求都是HTTP POST，并且含有4.1.2节列出的所需字段。5.1.2直接通信响应响应的主体由HTTP响应主体，即键-值组成。响应中的content-type应该设为text/plain。 所有键-值应该包含如下字段：ns值：一个有效的OpenID 2.0响应必须包含这个特值。因为以后的标准可能为请求定义 不同的值，这样设定才能使消息接受方恰当地解释请求消息。如不指定该值或指定为 以下两者之一，http:/ope nid. net/sig non/1.1、 5.1.2.1成功响应当服务器接收到有效请求时，必须返回HTTP状态码为200的成功响应。5.1.2.1失败响应如果请求消息格式不正确，

21、或者包含无效参数，服务器必须返回HTTP状态码为400的失败响应。响应主体必须包含下列键-值信息：ns参见5.1.2节。error值：人可理解的消息，指出错误原因。con tact值：（可选）服务管理员的联系地址。该地址可以以任何形式表达。reference值：（可选）参考标记，如支持代号或新闻blog的URL链接等。OP可以给响应添加额外字段。5.2间接通信在间接通信中，消息通过 UA来传递。RP和OP都可以初始化间接通信。它可用于认证请求和认证响应。该通信方式有两种方法：HTTP重定向和HTML表单提交。两者都要求发送方指定接 收方的URL,并且接收方URL可接受间接消息到来， 如4.1.

22、2。通信的初始化选择哪种方法 接受视能力而定，比如消息大小或者其他外在因素。所有间接消息以HTTP请求形式传送，并且包含 4.1.2列出的需要的字段。5.2.1 HTTP重定向可以通过对用户 UA发出302,303,307 HTTP重定向请求，进行数据传输。重定向 URL 是接收方的URL，并携带OpenID认证信息作为请求参数，如4.1.2指定。5.2.2 HTML表单重定向通过返回包含了 HTML表单条目的HTML页面给UA，可以传输键-值表。表单提交 可 以是自动完成的，比如使用JavaScript。条目的action属性值必须是接收方的 URL。每个键-值必须包含在表单的 条目中。键

23、必须按照name属性编码，值必须以value属性编码，当提交表单时 UA会生成如4.1.2指定的信息。表单 必须包含提交按钮。5.2.3间接通信失败响应如果请求信息格式不正确或包含无效参数，0P必须重定向UA到 openid.return_toURL，前提是该值已给出且是有效值。ope nid.ns参见4.1.2ope ni d.mode 值:error ope ni d.error 值：人可理解的消息，指出错误原因ope ni d.c on tact值：（可选）服务管理员的联系地址。该地址可以以任何形式表达（由人来读）。ope ni d.refere nee值：（可选）参考标记，如支持代号或

24、新闻blog的URL链接等0P可以给响应添加额外字段。如果RP接收了错误格式的或者无效信息，或者openid.return_to未指定或无效，服务器应该返回响应给用户，指出连接失误无法继续通信。6. 产生签名Association常以消息认证码（MAC ）密钥的形式，来签署 OpenID认证消息。产生MAC密钥时，应该遵守RFC1750给出的建议。6.1步骤产生消息签名需如下步骤：1. 根据需要签名的消息（10.1节），决定签名的键列表。签名的键列表必须是消息的一部分。列表存储于键openid.signed中，值是以逗号分隔的键名列表，这些键名需以openid.为前缀。这个方法仅用于以open

25、id.开头的签名键。2. 按照键在openid.signed列表中出现的顺序，在消息中找到每个键的对应值。3. 按照键-值表单编码，转换待签名的键-值为字节串。4. 在Association类型中选择签名算法，对已转换的字节串执行该算法。6.2签名算法OpenID认证支持两种签名算法：HMAC-SHA1-160 位（RFC2104和RFC3174）HMAC-SHA256-256 位（RFC2104和FIPS180-2）一般推荐使用 HMAC-SHA256算法。7. 初始化及自动发现7.1初始化为了初始 OpenID认证过程，RP应该给用户一个表格，该表格中需包含可以输入 User-Suppli

26、ed标识的字段。该表格字段中name属性应该包含openid_identifier，这样UA才能自动的识别这是一 个OpenID表格。如果该属性未恰当设置，即使是支持OpenID认证的浏览器插件或其他软件，也可能检测不到该 RP是支持OpenID的。7.2规格化用户输入必须被规格化为如下所示标识：1. 如果用户输入以xri:开始，必须将其去掉，以便 XRI能够以标准型使用。2. 如果结果字符串的第一个字符是XRI全局上下文符号(=,”, +, $, ”!”) 或(”,2.2.1 XRI_Syntax_2.0中定义)，应该 以 XRI 处理。3. 除此之外，输入应该以HTTP URL处理；如果输

27、入的标识中不包含 http或https， 必须添加http:/前缀。如果 URL包含一个碎片(#后部分)，必须除去。查看11.5.2 了解更多信息。4. 当检索其内容， 和对最终目的(final destination)URL应用RFC3986第六部分的规则时，URL标识必须进一步规格化。最终URL必须经RP鉴定(be noted as)为Claimed标识，然后用于 请求认证。参考规格化样例。7.3自动发现自动发现是指 RP用标识来自动发现(discover)初始化请求的必要信息的过程。OpenID认证有三种途径实现自动发现：1. 如果标识是 XRI形式，XRI_Resolution_2.0

28、将调用XRDS文档，该文档中包含必要信息。需要指出的是，RP可以利用XRI代理解释器(XRI Proxy Resolvers)，如XDI.org在上提供的，这样 RP就可以不用本地分解 XRI 了。2. 如果输入为一个 URL,应该尝试Yadis protocol Yadis。如果成功，再检索 XRDS 文档。3. 如果Yadis协议失败并无有效 XRDS文档可供检索，或文档中没有 服务条目，则对 URL进行检索，并尝试 基于HTML的自动发现。7.3.1自动发现的信息在成功完成自动发现的基础上，RP会得到一个或多个信息集 (参考Terminology section中定义)，如下所示。如果多

29、于一个信息集被自动发现，需应用XRI_Resolution_2.0中定 义的时间顺序规则。OP终点URL协议版本如果用户未输入 0P标识，应该同时给出以下信息：Claimed 标识OP-Local 标识如果用户输入了 0P标识，则没有Claimed标识。为了产生OpenID认证请求，当输入 0P 标识时，必须把值 Claimed 标识和 OP-Local 标识。7.3.2基于XRDS的自动发现如果使用XRI或者Yadis自动发现，得到的结果是 XRDS文档。这是一种 XML文档， 它包含标识中相关的服务条目，定义参见XRI_Resolution_2.0的第三部分，到 附录A.3查看XRDS文档

30、示例。7.3.2.1 OpenID月艮务条目7.321.1 OP标识条目一个OP标识是包含了下列信息的 条目： : : OP 终点 URL7.3.2.1.2 Claimed 标识条目一个Claimed标识是包含如下信息的 条目： : : OP 终点 URL （可选）：OP-Local 标识7.3.2.2抽取认证数据一旦RP得到了 XRDS文档，必须先按照XRI Resolution 2.0的描述，搜索该文档得 到OP标识条目。如果没有找到，RP将搜索Claimed标识条目。7.3.2.3 XRI 和 CanonicalID 条目当标识是XRI形式时，包含了 OpenID认证的条目必须也包含 ，

31、该条目的值 必须被用作 Claimed标识（参考11.5）.这些是出于灵活和安全 考虑的，因为CanonicalID条目的最初目的是断言一个不会被重分配的永久标识，这样可以 阻止XRI被新注册者接管的可能。RP必须确认包含了 条目的XRD的提供者对于 Canonical ID具有权威 性，并且XRDS文档对于OpenID服务条目具有权威性。RP应该手动确认，或者保证他们的解释器（resolver）作这件事。当使用XRI解释时，Canonical ID必须作为Claimed标识使用。要使 XRI成为有效的 标识，ProviderlD和CanonicallD必须 在自动发现的 XRDS文档中给出。

32、当使用URL标识时，如果给出 CanonicallD条目，也要忽略才行。7.324附加信息在 Ope nID 认证2.0中，ope nid命名空间不再被使用，而xrd命名 空间是 xri:/$xrd*($v*2.0)。考虑到代码兼容性， 一般推荐 RP也接受xrd:Type的值是 或 OpenlD 认证 1.1 兼容模式。如果 RP 支持 OpenId2.0 认 证，推荐使用以http:/specs.ope nid.n et/auth/2.0/server 和如果 OP支持扩展(节12)，这些扩展 应该作为附加的xrd:Type列出，同时这些 xrd:Type 作为 xrd:Service 的

33、子条目。7.3.3基于HTML的自动发现基于HTML的自动发现 必须被RP所支持，它只有在发现Claimed标识时有用。OP标识必须是支持XRDS自动发现的XRI或URL。使用基于HTML的自动发现，作为 Claimed标识的这个URL上的HTML文档必须可 访问，文档 HEAD中需包含：LINK，必须有属性rel指定为openid2.provider，href指定为 OP 终点 URL ； LINK，可以有属性rel指定为openid2. Iocal_id，href指定为 OP-Local 标识。执行 HTML 自动发现时，协议版本应该为HTML文档的主机可以与用户OP主机不同。openid

34、2.provider和openid2.local_id的 URL 必须不包含除了 &, &It;, >, 和"以外的实体，其他在 HTML文档中是无效的字符，或文档字符编码不能表达的 字符，则必须以百分号-编码(%xx)机制编码，RFC3986中描述了该机制。如OpenID认证1.1兼容模式 中的讨论，这里提到的自动发现标签不同于以前的协议， 即使表达相同的数据，名字却改变了，这样就允许RP来决定使用的协议版本。RP可以遇到同时发现1.1和2.0两种版本的 OP的Claimed标识，这种标识也使用基于HTML的自动发现。TOC&创建 AssociationRP和OP的A

35、ssociation建立了它们之间的共享密钥，利用此密钥可以检验随后的协议消息，并减少交互次数。如果可能，推荐RP形成Association，如果 RP不能创建或存储 Association， 11.4.2提 供另一可用验证机制，即无状态模式(Stateless Mode)。8. “Association 会话请求一个Association会话由从 RP到0P终点URL的直接请求初始化，在该请求中将openid.mode的值设为associate。8.1.1通用请求参数下列参数为所有Association请求通用：ope nid.ns见 4.1.2 (HTTP 编码).ope ni d.mod

36、e值:associateope ni d.assoc_typeAssociation类型定义了后续信息的签名算法值：有效的 Association 类型 8.3 (Association 类型)ope ni d.sessi on _type定义传输中使用的加密Association MAC密钥的方法.值：有效Association会话类型 8.4 (Association会话类型).注：除非使用了传输层加密，no-encryption必须不使用.&1.2 Diffie-Hellman 请求参数请求参数中 Association 会话类型(openid.session_type)为DH-SHA1

37、或DH-SHA256 时，下列参数必须给出：ope ni d.dh_modulus值:base64(btwoc(p)默认值:附录B (Diffie-Hellman Key 交换默认值)ope ni d.dh_ge n值:base64(btwoc(g)默认值:g = 2ope ni d.dh_c on sumer_public值:base64(btwoc(g A xa mod p)参见8.4.2 (Diffie-Hellman Association会话)，查看这些参数信息注：btwoc方法的定义在 4.2.8.2 Association 会话响应一个Association会话应当是从 OP到R

38、P的直接响应，这些响应为键 -值形式。8.2.1通用响应参数ns参见5.1.2.assoc_ha ndleAssociation handle被用作在后续信息中检索该Association的关键词.值：少于等于255个字符的串，必须且仅能由33-126的ASCII字符(可打印非空格) 组成。sessi on _type请求中openid.session_type的参数值，如果 OP不愿或不能支持该 Association类型， 必须返回 unsuccessful responseassoc_type请求中openid.assoc_type的参数值，如果 OP不愿或不能支持该 Associati

39、on类型， 必须返回 unsuccessful responseexpires_ in秒级别的Association生命周期，过了这个时间RP必须不能使用该Association。值：base10 ASCII表示的整数。8.2.2非加密响应参数mac_key此 Association 的 MAC 密钥(共享密钥)，Base 64RFC3548编码。&2.3 Diffie-Hellman 响应参数dh_server_public值：base64(btwoc(g A xb mod p)描述：OP Diffie-Hellman 公钥.en c_mac_key值：base64(H(btwoc(g a

40、(xa * xb) mod p) XOR MAC key)描述：MAC密钥(共享密钥)，用secret Diffie-Hellman值加密.由会话类型决定 H 是SHA1还是SHA256。注：btwoc方法的定义在 4.2.8.2.4不成功响应参数如果OP不支持会话类型或Association类型，它 必须直接返回一个错误信息，指出Association请求失败。如果有其他支持的Association会话类型或者 Association类型，OP应该在响应中包含如下信息：ns参见5.1.2.error值：人可理解的消息，指出错误原因error_code值：un supported-typese

41、ssi on _type值：（可选）OP支持的有效 Association会话类型 8.4 （Association会话类型）. assoc_type值：（可选）OP支持的有效 Association类型 8.3 （Association类型）.在收到unsupported-type响应时，RP可以用给出的 Association会话类型和 Association 类型创建另一个请求。如果未创建Association， RP可以使用直接验证 继续认证过程.8.3 Association 类型8.3.1HMAC-SHA1类型为HMAC-SHA1的Association，应使用 HMAC-SHA1

42、 签名算法。8.3.2HMAC-SHA256类型为HMAC-SHA256的 Association，应使用 HMAC-SHA256 签名算法。8.4 Association 会话类型OpenID 认证定义 了有效 Association 会话类型：no-encryption, DH-SHA1和 DH-SHA256。8.4.1 No-Encryption Association 会话在no-encryption Association会话中，OP以纯文本形式发送 Association MAC 密钥给 RP。这样使监听者截取密钥成为可能， 并可以在不使用传输层加密时， 传递伪造消息给 RP。 因

43、此，除非使用了传输层加密， no-encryption Association会话必须不用。参考15.1.1 。 OP发送的MAC密钥的长度 必须是请求消息中Association类型指定的长度，参考 6.2.&4.2 Diffie-Hellman Association 会话DH-SHA1和DH-SHA256Association 类型使用 Diffie-Hellman 密钥交换，安全的传递 共享密钥。MAC密钥必须与H的输出值长度相同，H即DH-SHA1 -160位（20字节）和DH-SHA256-256位（32字节），同时这个长度也是该Association签名算法的输出值长度。RP指定

44、一个模数（modulus） -p，和一个产生因子（generator） -g，它选择一个随机的 私钥xa, OP选择一个随机私钥 xb，两个私钥都在1 . p-1范围内。用来加密 MAC密钥的 共享密钥即为g A （xa * xb） mod p = （g A xa） A xb mod p = （g A xb） A xa mod p更多信息请参考RFC2631，关于随机数选择，参考 RFC1750.9. 请求认证一旦RP成功的执行了自动发现并且和0P终点URL地址创建了一个 Association,它就发送一个认证请求给 0P去获得一个断言。认证请求是一个间接请求（通过用户的浏览器）9.1请求参

45、数* ope nid.ns参看4.1.2节关于HTTP编码的说明* ope ni d.mode值：checkid_immediate或者checkid_setup注意：如果RP希望用户能够和 0P交互，应该使用“ checkid_setup ”。有一种情况 是用户和0P之间没有交互请求，例如认证请求是在 JavaScript中以异步的方式进行。* ope nid.claimedd值：（可选的）Claimed标识openid.claimedd和openid.identity应该成对出现（或皆不出现）。如果两者都没 有出现，那么该断言不是关于一个 标识的，会在负载中通过使用 扩展包含一些其他 信息

46、。推荐OP接受所有XRI标识，不论是否有xri:前缀，参看 规范化一节的说明。* ope ni d.ide ntity值：（可选的）OP-Local标识如果没有指定一个新的（不同的）OP-LOCAL标识，Claimed标识必须 作为openid.identity 的值。注意：如果该值被设置为 OP 应该选择一个属于用户的标识。 如果请求不是关于标识的， 这个参数可以忽略。（例 女口，即使没有它，若使用了一个扩展，将使请求也有意义。参看上面关于openid.claimed_id 的说明） ope ni d.assoc_ha ndle值：（可选的）用于RP与OP之间Association的一个句柄

47、，应该用于对响应签名。注意：如果没有传送 Association句柄，事务将会以一种无状态模式发生（和 OP进 行直接证实）。* ope ni d.return_to值：（可选的）OP返回给UA的URL，其响应表明了请求的状态。注意：如果这个值没有在请求中传送，它意味着RP不希望用户被返回。注意：return_to URL可以作为一种机制，用于 RP附加关于认证请求的上下文给认 证响应。该文档没有定义一个特定的机制使得RP能够确定查询参数没有被其他的第三方修改。这种机制 可以由RP自己定义。* ope ni d.realm值：（可选的）OP应该要求用户信任的 URL的范式。参看9.2节（关于R

48、ealms）。 如果openid.return_to被省略，这个值 必须提供。缺省值：return_to URL9.2 Realms9.2.1 域域是一个范式，它代表着使得OpenID认证请求有效的 URL地址。用于提供用户关于认证请求范围的指示。当要求用户批准一个认证请求的时候，OP应该提供这个域。这个域 应该被OP用于唯一地确认 RP。例如，OP可以使用这个范围去允许用户自动许可认证请求。一个域（Realm）类似一个URL，但有如下不同：一个域必须不包含URI定位段* 域可以在规范的URL的开头节部分包含一个通配符，它由字符“*.”组成，位于DNS域名前面。一个URL匹配一个域（Realm

49、）,当且仅当： URL的模式和端口和域中的完全相同。参看RFC3986 (Berners-Lee, T.,“ UniformResource Identifiers (URI): Generic Syntax,)”URL的路径与域的路径相同或者是其子目录路径*满足下面条件之一：1. 域包含着通配符“ *. ”，并且URL域的尾部分和域中紧跟通配符之后的部分 相同。或者2. URL的域名和提供的域(Realm)的名字相同。当呈现的时候，openid.return_to必须匹配openid.realm，或者OP必须返回一个间接的响 应错误。推荐OP保护用户，禁止他们通过类似于http:/*.com

50、/ or http:/*.co.uk/的过度通用的域进行断言。当域用于标识一个特定的RP的时候，过度通用的域可能存在危险。无论一个域是否过度通用，OP都要谨慎对待。TOC9.2.2使用域对返回URL确认OP应该确认在请求中指定的 return_to URL地址，这是一个 RP的终点URL。为了确认 return_to URL，需要通过在 RP上执行自动发现，得到针对该域的 RP终点URL。当执行自 动发现的时候，被发现的URL是上次HTTP响应的URL，接下来进行重定向。当针对该域执行发现阶段时，如果每个重定向都执行，确认将会失败。如果发现阶段已经成功完成，要 确信return_to URL和

51、某个 RP终点一致。一个域可能包含一个通配符。因此可能不是一个有效URL。例如，通过用 WWW替代通配符获得URL,针对该URL执行自动发现。匹配return_to URL和一个RP端点的规则和匹配 return_to URL和域的规则相同，将 RP的 终点URL作为域。RP终点URL必须不包含一个范围通配符，并且 应该尽可能的具体。如果经过尝试的验证失败了，OP不应该发送一个肯定的断言给这个return_to URL。OP可以缓存通过验证的returnt_to URL.9.3 即时请求(Immediate Requests)当进行请求认证时，RP可以要求OP不和用户交互。在这种情况，OP必须

52、直接给出响应，它可能是一个说明认证成功的断言，或者是一个表明由于没有更进一步的用户交互而使得请求没有完成的响应。这通过一个将openid.mode设置为checkid_immediate的认证请求完成。10. 响应认证请求当UA通过间接通信提出一个认证请求时，0P应该确定是一个经授权的用户希望完成认证。 如果一个经授权的用户希望完成认证，0P应该发送一个肯定断言给RP。标识经授权用户的方法以及获得一个返回OpenID认证断言许可的方法超出了本规范的范围。参看15.1.2.1节对于0P安全的考虑。如果 RP 将 openid.identity 设置为 OP 驱动 的标识选择，并且有多个、用户授权

53、用于进行认证响应的标识，那么0P应该允许用户选择使用哪个身份标识。如果RP提供一个带有认证请求的Association句柄，OpenID RP应该尝试寻找基于该句柄的Association。如果Association已经过期或者丢失，0P应该在响应中发送openid.invalidate_handle参数，其值为请求中openid.assoc_handle参数的值，并且应该像没 有指定Association句柄一样继续进行下去。如果没有指定 Association句柄，0P应该使用私有的 Association为响应签名。0P必须存储 这个Association，并且必须对后来的请求给予响应，

54、通过直接验证 来检查响应的签名RP应该接受和验证断言，那些断言是关于还没有提出认证请求标识的，0P应该使用私有Association为未经同意的肯定断言签名。如果在请求中openid.return_to的值被省略了，RP不希望接受一个来自于0P的认证断言。这点可能在使用扩展在RP和0P之间传递数据时发挥作用。10.1肯定断言肯定断言是附带着下面字段的间接响应* ope nid.ns参看4.1.2节（HTTP编码）* ope ni d.mode值：id_res* ope ni d.op_e ndpo int0P终点URL地址 ope ni d.claimed_id 值：（可选的）Claimed

55、标识。“openid.claimed_id ”和openid.identity ” 应该两者 同时提供或者两者同时缺省。注意：用户可以选择一个本地的 0P的标识作为 Claimed标识。注意：如果没有任何一个标识呈现在断言中，那么它不是关于标识的，并且将会通 过扩展在负载中包含其它信息。* ope ni d.ide ntity值：（可选的）OP-local标识注意：关于使用哪个断言，0P可以帮助用户选择 Claimed标识和OP-local标识。如果使用扩展可以保证在缺少Openid.identity字段的时候，响应仍然有意义，那么 该字段可以省略。* ope ni d.return_to值：

56、与请求中的 return_to URL 参数相同。* ope ni d.resp onse_nonce值：一个长度不超过255个字符的字符串随机序列，必须唯一标识该特定的成功的验证响应。该随机序列是为了唯一标识每个响应，它必须以服务器的当前时刻开始，可以包含额外的ASCII字符串，其编码范围在33-126之间（可打印的非空白字符串）。日期和时间 必须按照 第5.6节RFC3339 （Klyne, G. and C. Newman,因特网上的时间与 日期：时间戳，”）,的说明格式化，满足下面的要求：o 所有的时间 必须使用UTC时区，使用”Z”来标识o 最小单位为秒例如：2005-05-15T1

57、7:11:51ZUNIQUE* ope ni d.i nvalidate_ha ndle值：（可选的）如果RP在请求中发送一个无效的Association句柄，它的值 应该包含在这里。* ope ni d.assoc_ha ndle值：用于对断言进行签名的Association句柄。*ope ni d.sig ned值：逗号分隔的签名字段的列表注意：这些条目包含的字段没有ope nid.前缀，并且覆盖了签名的所有字段。列表中至少包含op_endpoint ”，return_to ， response_nonce禾口 assoc_handle字段， 如果用于响应中，则再包含claimedd和identity.额外的关键词 可以作为信息的一部分被签名。参看产生签名例女口, op_endpoint,identity,claimed_id,return_to,assoc_handle,response_nonce.* ope nid.sig值：Base 64编码的签名封装，参看Section 6 （产生签名）的说明。10.2否定断言如果op不能标识用户，或者用户不能接受认证请求，op应该以间接响应 方式发送一个否定、断言给RP。当接受一个针对checkid_immediate模式请求的否定断言时， RP应该使用checkid_