XRDS 完结篇

让我们继续认识 XRDS 中的各种元素以及它们能做的事情。

就像前面所说的， XRDS 包含一些称为 Service End Point 的节，它们用来描述服务，包括服务的类型、标识符等，以便应用端去发现和利用，即 discovery 。最初 Yadis 将这个概念带给 OpenID 和 LID ，因为它们都是一种以 URL 为标识的认证机制。从这种 URL 中解析出 XRDS ，那么我们不仅可以使用 OpenID 、 LID ，还可以加入任何其他有用的东西： SAML 、 XDI 、 Feed 、 SIP ……当然所谓“有用”，是得有能利用 XRDS 的应用服务，目前并不多，后面我们可以一一看到。

从协议上来看，所有这些都是可以实现的，无论 URL 还是 i-name 。你已经有了一个附有 XRDS 的 URL ，但 i-name 可以实验的内容更多，因此不要吝惜你的时间，去 FreeXRI 注册一个免费的 i-name 。

那么一个 i-name 的 XRDS 在哪？在 FreeXRI 中我们可以从 Your i-names -> Advanced -> Launch XRI Resolution for this XRI 得到，除了这个的 XRI Resolution Tool 外，一个更为普遍的方法是使用 XRI.net 解析网关，在地址栏输入：

http://xri.net/=my?_xrd_r=application/xrd%2Bxml

看到了么，这是我的寄生在 i-name 上的 XRDS 。这个文档比较长，为了看的更清楚，我们使用 FoXRI 插件，这个插件可以视为一种简单的应用，它发现 XRDS 并尝试解释其中的服务（而非使用它们）。让我们至上而下。

<Query>*my</Query>
<Status code="100"/>
<Expires>2008-02-13T13:00:05.000Z</Expires>

这组新出现的叫支配元素，它们提供一些基本信息，用来控制 XRDS 、缓存和处理错误。

<ProviderID>xri://=</ProviderID>
<LocalID priority="10">!E1FE.96F8.5841.1FF4</LocalID>
<CanonicalID priority="10">
=!E1FE.96F8.5841.1FF4
</CanonicalID>

认证授权及同义元素。针对 OpenID 的回收问题（《没有 MyOpenID 的世界》一文曾提到过）， i-name 的解决方案是 i-number 。整个 XRI 解析十分类似 DNS 的运作模式， 而 i-number 类似 IP 地址，它相对稳定不易变化。当一个 i-name 失去的时候，它所对应的 i-number 不会消失；注册人可以将新得到的另外一个 i-name 同义到老的 i-number 上，而失去的那个 i-name 再次被注册后会分配一个新的 i-number。除了 URL 外，用户并不需要知道同义化的数字标识，但应用端应该从同义元素中取得 i-number 作为识别 ID 。如果不这么做，设想一下 myopenid.com 欠费被收回后，下一个注册者一瞬间掌握成千上万个重要 OpenID 的恐怖局面。注意，这并非 i-name 专有的， OpenID 将会采用这一方式来规避回收产生的问题，但现在只被少数网站理解和使用；你可以在 Jyte 上尝试一下，作为 OpenID 应用界的领头羊，他们提供你所知道的所有 OpenID 特性。

<Service priority="1">
<Type match="null"/>
<Path match="null"/>
<URI append="none" priority="1">
http://xri.net/=my/(+home)
</URI>
</Service>

很眼熟， SEP 来了。除了熟悉的元素和属性，还出现了一些新的，例如 match 属性、 append 属性、Type 元素、 MediaType 元素等。请参考 XRI Resolution ，我们在这只初步理解 XRDS 文档来看看到底它能做什么，更深的内容可以通过阅读规范来学习。第一个 SEP 有一个空的 <Type> 元素。 FoXRI 认不出这是什么，但其实这是一个缺省的 URL 映射。当浏览器经过 XRI 网关， <URI> 被返回，试试

http://xri.net/=my

我们可以在 XRDS 中建立各种到 URL 的映射，不限于 http ，也可以是 mailto 、 sip 、 xmpp 、 call 等等。而通过 MediaType 来规定输出的类型，我们还可以映射各种资源形式，如 feed

<Service priority="10">
<Type match="null"/>
<MediaType match='content' select='false'>
application/atom+xml
</MediaType>
<MediaType match='default' select='false' />
<Path match="null"/>
<URI append="none" priority="1">
feed:xn--2hvy3a.com/planet
</URI>
</Service>

想到什么了吗？一个支持 XRDS 的 RSS Reader ，可以从 OpenID 中获得对方的 feed 更新；一个支持 XRDS 的 VoIP 软件可以直接 call 一串 OpenID URL 连接语音通道；一个支持 XRDS 的 IM 客户端则可以将 URL 视为帐号籍由 XMPP 与他人聊天，一个……通过 XRDS ，我们的 OpenID 真的成为了个人标志，一旦有更多的应用加入进来，你的朋友不再需要询问你的 ID ，因为你们在新的服务上，直接就是好友了。

映射利用了空 type 和一个 URI 来玩花招，这一方法并不标准，因为我们还没有足够的服务类型名称来说明这些 URI 。对于 SEP 来说， type 其实是一个服务的根本，只不过除了 Contact page 、 OpenID 和 URL 转发外，我们可以直接利用的服务还真不多。来看一个例子

<Service priority="10">
<Type select="true">
http://josephcp.com/jyte_is_member
</Type>
<ProviderID/>
<URI append="none" priority="1">
http://jyte.com/api/contacts/is_member
</URI>
</Service>

josephcp 在去年六月左右就做出了一个很漂亮的演示，我曾和他一起试验并帮他找出 bug （我不确定多少人试过它），这也是促使我当时想写 XRDS 的动力来源。简单的说：

1. 在应用网站 A ，也就是 http://openidr.mekov.com/ 上，存在用户 a 和用户 b （ =my 和 =jcp ），他们互相没有任何关联，因为这是一个新的网站。
2. 在应用网站 B ，也就是 http://jyte.com/ 上， a 和 b 使用同样的个人标识（ =my 和 =jcp）， Jyte 存在很久了，并且 a 和 b 有着共同的兴趣，因此他们互加了好友。
3. 在注册 A （严格的说，这个网站支持 OpenID 因此没有注册过程）的时候， a 和 b 各自提供 A 自己的 Flickr （某种孤立的个人信息）。
4. 在 B 中， a 发现 b 经常能作出一些惊天动地的 claim ， a 想多了解一些 b ，于是 a 登录进 A ，并搜索 b 的个人 ID。
5. A 解析 a 的 XRDS ，发现 jyte_is_member 服务，于是它用这个服务的 URI 所提供的 API ，也就是 Jyte 的 is_member 判断 a 和 b 的关系。
6. 哦 a 和 b 原来是好友，于是 A 将 b 最新上传的相片读出显示给 a 。

可以看到 A 是如何成功的实现了数据的可携带性。应该说这是一个非常纯粹的演示， XRDS 中的服务声明并不是实现这一系列功能的必要条件，但 jcp 给我们展示了这样的可能性。应用可以轻松的绑定到一个 ID 上，或者从一个 ID 上删除，甚至可以卖给一个 ID ，更好的用户体验，以及更少的学习成本。

与此同时， XRDS 是开放式的，类似你的 Profile page 。你可以分享你觉得舒服的信息，社区成员们也在开发基于隐私和安全的机制。例如 EZIBroker 的年龄声明服务：应用网站利用用户 XRDS 中的描述，引导认证服务器由用户证明自己的年龄，以合法提供相应信息等。

XRDS 很有趣，但在有更多的应用前，我们也没什么可干的。最近 OpenID 的新动向也不多，真的是一个很缓慢的社区。