OpenID 属性交换 1.0 - 最终版

Abstract

OpenID 属性交换是一个用来在端点间交换身份信息的 OpenID 服务扩展。 它提供了身份信息的存取所使用的消息。

Table of Contents

1.  术语
    1.1.  定义与约定
2.  概述
3.  信息模型
    3.1.  主体 Identifier
    3.2.  属性类型标识
    3.3.  属性值
        3.3.1.  属性特定的编码
4.  Discovery
5.  获取消息
    5.1.  获取请求格式
    5.2.  获取响应格式
6.  存储消息
    6.1.  存储请求格式
    6.2.  存储响应格式
        6.2.1.  存储成功
        6.2.2.  存储失败
7.  安全考虑
8.  鸣谢
9.  References
    9.1.  规范参考
    9.2.  非规范性参考
§  Authors' Addresses

1.  术语

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

1.1.  定义与约定

用户：

也称作“最终用户”或“主体”。 拥有数字身份的人，他们使用客户端软件，典型的如网络浏览器，参与基于 OpenID 的身份信息交换。

身份数据：

数字身份的属性，属性名和属性值表现为名——值对。

属性：

信息模型的基础，用来描述交换的身份数据，

角色：

用户身份数据的子集。一个用户可以有多个角色作为他们的身份。 例如，一个用户可能有工作角色和家庭角色。

OpenID 提供商:

也叫“OP”或“服务器”。一个 OpenID 认证服务器，Relying Party 通过它确认用户是否拥有某个 Identifier。

Relying Party:

也叫“RP”或“Consumer”。一个网络应用程序，它想证明用户拥有某个 Identifier，并请求该用户的身份数据。

所有的 OpenID 属性交换消息必须包含下面的扩展命名空间声明，正如 OpenID-Authentication-2.0 的扩展那一节描述的那样。

openid.ns.<extension_alias>=http://openid.net/srv/ax/1.0

实际的扩展命名空间别名应该由各消息本身决定，这种方式可以避免多个扩展发生冲突。

2.  概述

属性交换服务扩展由 URI “http://openid.net/srv/ax/1.0”标识。这个 URI 必须在扩展命名空间声明中指定。

一个属性就是一个个人身份信息单元，它通过一个唯一的 URI 来标识。 它可以是任意类型的信息。[OpenID.axschema] (Hardt, D., “Schema for OpenID Attribute Exchange,” May 2007.)提供了一个定义属性类型的参考示例。

这个服务扩展定义了两个消息类型用来传输属性：获取（参见Section 5 (获取消息)）和存储（参见Section 6 (存储消息)）。 从 OpenID Provider 获取属性信息，当在 OpenID Provider 上存储或更新属性信息时。 来自 Relying Party 和通过用户代理传给 OpenID Provider 的消息均请参照 OpenID 认证协议规范。

这里详述的请求参数必须使用[OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0 - Final,” August 2007.)中的扩展机制来发送。

3.  信息模型

OpenID 属性交换服务扩展提供了在站点间移动身份信息的机制，就其本身而论，信息模型是简单的。

一个属性是和一个主体 Identifier 相关的

一个属性有一个类型标识符和一个值

一个属性的类型标识符是一个 URI

一个属性的值可以是任意类型的数据。

3.1.  主体 Identifier

用来标识一套属性的标识。必须是一个 URI。 主体 identifier 与消息的认证部分的用户 identifier 相对应。 也就是说，在消息的属性交换部分中的身份属性的主体和认证部分的用户一致。 主体 identifier 不包含在属性交换中。

3.2.  属性类型标识

一个属性类型标识必须是一个 URI，用来作为属性值的参考。

如果有属性类型标识 URI，那么它可以用来检索属性的描述。 通过检索新的或者未知的属性类型得到元数据，OpenID Provider 可以利用元数据来动态地辅助用户提供属性。

这个特性是为灵活性和可扩展性准备的。 灵活性体现在，URN 和 URL 都可以用来作为属性值的参考。 扩展性则允许任何个体站点，或者站点的所有者，通过商定的语法和语义来对相关的属性定义他们自己的类型。

[OpenID.axschema] (Hardt, D., “Schema for OpenID Attribute Exchange,” May 2007.)描述了定义一个新属性类型 URI 的方法示例， 也提供了一套属性类型，描述了相关的元数据schema和数据格式。

3.3.  属性值

属性值必须是一个 UTF-8 (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.) [RFC3629] 字符串。 为了遵从[OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0 - Final,” August 2007.)协议中定义的数据格式， 属性值不能包含换行符（UCS codepoint 10，"\n"）。

OpenID 属性交换可以用于交换任意类型的数据。 如果数据中含有换行符，而不是一个 UTF-8 字符串或者TODO， 数据必须编码为不含有换行符的 UTF-8 字符串。

3.3.1.  属性特定的编码

属性特定的编码可以通过属性元数据描述来定义， 并被 OpenID 属性交换之上的协议层使用

可选的，属性特定的编码可以使用语言标签[OpenID.value‑lang‑1.0] (Wahl, M., “Language Tags for OpenID Values,” April 2007.)来进行本地化。

4.  Discovery

属性交换服务扩展的 discovery 通过[OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0 - Final,” August 2007.)中描述的机制来完成。 属性交换命名空间“http://openid.net/srv/ax/1.0”应该作为子元素列在 XRDS discovery 文档的 <xrd:Service> 的一个 <xrd:Type> 中。

5.  获取消息

获取消息用来从一个 OpenID Provider 获取个人身份属性。

5.1.  获取请求格式

除了“openid.ax.mode”，下面列出的所有请求字段都是可选的， 不过在请求中必须至少有一个“openid.ax.required”或“openid.ax.if_available”， 并且出现在“openid.ax.required”或“openid.ax.if_available”中的属性别名必须有一个相关的“openid.ax.type.<alias>”参数。 属性别名支持的长度必须至少为 32 个字符。

“openid.ax.required”和“openid.ax.if_available”中的多个属性别名用逗号（“,”）隔开。

openid.ax.mode

必需的。值：“fetch_request”。

openid.ax.type.<alias>

这个参数的值指定了请求属性的类型标识的 URI。 <alias>将会用来标识被交换的属性。

属性别名不能包含换行符和冒号，正如[OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0 - Final,” August 2007.)的数据格式/协议消息这一节所描述的那样； 它们也不能包含逗号（“,”）和句号（“.”）。

openid.ax.required

值：一个属性别名，或者属性别名列表，别名必须和“openid.ax.type.<alias>”参数中定义的 URI 一致。 多个属性别名用逗号（“,”）隔开。

By requesting attributes using this field, a hint is sent to the OP about the RP's requirements for offering certain functionality and should be used by the OP to help the user decide what attributes to release. RP's requirements should not be enforced by the OP.

如果通过属性交换没有得到这些属性，那么 RP 应该提供一个额外的替代方案来收集它所需要的属性。

openid.ax.if_available

值：一个属性别名，或者数并别名列表，别名必须和“openid.ax.type.<alias>”参数中定义的 URI 一直。 多个属性别名用逗号（“,”）隔开。

RP 通过这个字段来指示这些请求的属性是可选的； 如果 OP 没有提供这些可选属性的值，那么 RP 应该能够通过与用户的交互来获得这些值。

openid.ax.count.<alias>

Relying Party 希望从 OpenID Provider 接受到的指定属性别名的值的个数。 如果存在，该值必须大于 0，或者指定为“unlimited”以表示 RP 请求 OP 所拥有的该属性的所有值。 如果不存在，只请求一个值。

OpenID Provider 返回该字段相关属性的值的数量可以少于或恰好为指定的数量，但是不能多于指定的数量。

openid.ax.update_url

如果存在，OpenID Provider 可以在初始响应发送后的同时使用一个 OpenID 认证肯定断言向指定的 URL 再发送一次获取响应消息， 如果 OpenID Provider 支持这个特性，它必须返回这个参数，作为获取响应消息的一部分。 如果它不支持这个特性，则可以忽略该参数。

字段“openid.ax.update_url”的值必须用做 OpenID 认证的获取响应更新的肯定断言的字段“openid.return_to”的值。

如果字段“openid.realm”存在，那么“openid.ax.update_url”的值也必须和获取请求中 OpenID 消息的领域所指定的值相匹配。 匹配规则就是 OpenID 认证协议的“领域”章节所描述的规则。

“unsolicited”响应消息将会产生属性信息更新响应，其中包含了更新了的数据。 OP 应该获得用户的准许，才能通过 OpenID 肯定断言（OpenID Positive Assertion）再发送更新了的数据给 RP。

The relying party may include transaction data encoded in the URL such that it contains enough information to match the attribute information to the identity subject. Additional information may be encoded in the URL by the relying party as necessary. Relying party 可以将业务数据编码在 URL 中TODO

如果 RP 不希望接受属性更新，它可以对“update_url”返回一个 HTTP 404 响应。 OP 可以在遇到 404 响应后决定停止发送更新。

这个例子将请求必需的全名和性别信息，可选的喜欢的狗和电影信息。 Relying Party 希望得到该 subject identifier 相关的 3 个喜欢的电影。

openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=fetch_request
openid.ax.type.fname=http://example.com/schema/fullname
openid.ax.type.gender=http://example.com/schema/gender
openid.ax.type.fav_dog=http://example.com/schema/favourite_dog
openid.ax.type.fav_movie=http://example.com/schema/favourite_movie
openid.ax.count.fav_movie=3
openid.ax.required=fname,gender
openid.ax.if_available=fav_dog,fav_movie
openid.ax.update_url=http://idconsumer.com/update?transaction_id=a6b5c41

5.2.  获取响应格式

获取相应消息提供获取请求所请求的信息。 每个属性都以指定的别名加上前缀“openid.ax.value.”来提供。 属性类型也在“openid.ax.type.<alias>”参数中被返回。 属性别名支持的长度必须至少为 32 个字符。

除了“openid.ax.mode”，下面所有的请求字段都是可选的， 但是所有在“openid.ax.value.<alias>”参数中出现的属性值， 都必须有一个相关的“openid.ax.type.<alias>”参数。

如果某个值没有提供或者该用户没有设置这个值， 相关的“openid.ax.value.<alias>”字段应该不包含在 OP 的获取响应中。 一个值为 “0” 的 “openid.ax.count.<alias>”和相应的“openid.ax.type.<alias>”字段可以包含在其中以明确表示该属性没有提供任何值。

Validation of the received data should be performed out of band of attribute exchange by the RP. RP 应该对接收到的数据进行验证。TODO: out of band

openid.ax.mode

必需的。值“fetch_response”。

openid.ax.type.<alias>

这个参数的值指定获取响应中的一个属性类型标识符 URI。 <alias> 将用来标识被交换的属性。

属性别名必须不包含换行符和冒号，正如 [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0 - Final,” August 2007.) 的数据格式/协议消息章节所描述的那样； 也不能包含逗号（“,”）和句号（“.”）。

openid.ax.count.<alias>

<alias> 所指的属性的值的个数。

openid.ax.value.<alias>

指定 <alias> 所指的属性的值。 如果没有发送 “openid.ax.count.<alias>”， 那么必须设置这个参数。

openid.ax.value.<alias>.<number>

指定 <alias> 所指的属性的值。 如果发送了“openid.ax.count.<alias>”且至少为相关的属性提供了一个值， 那么必须指定这个参数。

<number> 唯一标识值的索引，从 1 到“openid.ax.count.<alias>”所指定的值。 参数的数目必须和“openid.ax.count.<alias>”所指定的值一致。 OP 没有必要维持获取响应中属性值的顺序。

openid.ax.update_url

返回请求中指定的“update_url”参数。 如果 OpenID Provider 接受一个“update_url”参数且打算支持属性更新特性， 它就必须提供“update_url”参数和值，作为获取响应消息的一部分。

获取响应消息也可以被发送给响应中Section 5.1 (获取请求格式)指定的“update_url”来在 OpenID Provider 上进行属性值更新。

对前一个请求示例的响应， 它请求了全名信息（必需的）和喜欢的狗的信息（可选的）， 还请求了 3 个喜欢的电影的名字（可选的），但是 OP 只提供两个值。

openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=fetch_response
openid.ax.type.fname=http://example.com/schema/fullname
openid.ax.type.gender=http://example.com/schema/gender
openid.ax.type.fav_dog=http://example.com/schema/favourite_dog
openid.ax.type.fav_movie=http://example.com/schema/favourite_movie
openid.ax.value.fname=John Smith
openid.ax.count.gender=0
openid.ax.value.fav_dog=Spot
openid.ax.count.fav_movie=2
openid.ax.value.fav_movie.1=Movie1
openid.ax.value.fav_movie.2=Movie2
openid.ax.update_url=http://idconsumer.com/update?transaction_id=a6b5c41

6.  存储消息

存储消息是用来将个人标识信息存储到 OpenID Provider 的； 它提供了一个途径，该途径可以让 RP 传送用户认为有用的属性给 OP，比如把这些属性再提供给其它的 RP。 属性别名支持的长度必须至少为 32 个字符。

OP 如何处理存储请求中所提供的属性，超出了本文档的范围。

6.1.  存储请求格式

除了“openid.ax.mode”之外，下面所有的请求字段都是可选的。 出现在“openid.ax.value.<alias>”或“openid.ax.value.<alias>.<number>”参数中的属性别名必须有一个相关的“openid.ax.type.<alias>”参数。

openid.ax.mode

必需的。值：“store_request”。

openid.ax.type.<alias>

该参数的值指定了请求中的属性的类型标识 URI。 <alias> 将用来标识被交换的属性。

属性别名必须不包含换行符和冒号，正如 [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0 - Final,” August 2007.) 的数据格式/协议消息章节所描述的那样； 也不能包含逗号（“,”）和句号（“.”）。

openid.ax.count.<alias>

<alias> 所指的属性的值的个数。如果存在，则必须大于 0。

openid.ax.value.<alias>

指定 <alias> 所指的属性的值。 如果没有发送 “openid.ax.count.<alias>”， 那么必须设置这个参数。

openid.ax.value.<alias>.<number>

为 <alias> 所指的属性指定一个值。 <number> 唯一标识值的索引，从 1 到“openid.ax.count.<alias>”所指定的值。 如果存在“openid.ax.count.<alias>”则必须使用该参数， 并且参数的数目必须和“openid.ax.count.<alias>”所指定的值一致。 OP 没有必要维持获取响应中属性值的顺序。

openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=store_request
openid.ax.type.fname=http://example.com/schema/fullname
openid.ax.value.fname=Bob Smith
openid.ax.type.fav_movie=http://example.com/schema/favourite_movie
openid.ax.count.fav_movie=2
openid.ax.value.fav_movie.1=Movie1
openid.ax.value.fav_movie.2=Movie2

6.2.  存储响应格式

6.2.1.  存储成功

存储操作成功由存储响应中的 mode 参数标示：

openid.ax.mode

必需的。值：“store_response_success”。

openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=store_response_success

6.2.2.  存储失败

存储失败响应格式如下：

openid.ax.mode

必需的。值：“store_response_failure”。

openid.ax.error

可选的。该参数描述了导致本错误响应的原因，它将用来显示给最终用户。 消息的本地化区域信息必须和 HTTP 消息的本地化区域信息一致。

openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=store_response_failure
openid.ax.error=General storage failure

7.  安全考虑

OpenID 属性交换是一个 OpenID 扩展，因此使用 OpenID 认证请求和响应消息来交换属性。

参见 [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0 - Final,” August 2007.) 的安全考虑一节。

8.  鸣谢

John Merrells 和文档“draft-merrells-dix”的其他贡献者。 本文档使用了该文档其中的一部分。

Mark Wahl 对如何处理属性编码提供了建议。

9.  References

9.1. 规范参考

9.2. 非规范性参考

Authors' Addresses