OpenID 中文新闻聚合

OpenID基金会日本分部即将成立

=my — Fri, 29 Feb 2008 05:49:56 GMT

当地时间28日，Six Apart株式会社、日本VeriSign株式会社和野村综合研究所共同发布了一项公告，宣布将建立日本OpenID基金会，开展OpenID在日本的普及和推广活动。

前不久，OpenID基金会接纳了一些业界巨头作为董事会成员，他们相信只有更顶尖的技术成员的参与，才能真正帮助OpenID解决一直以来的最大问题——推广；同时基金会也在世界各地，鼓励各自的当地社区成立分部以进一步支持和推动OpenID。

此次建立日本分部的三家发起人，均是日本国内OpenID推广的有力支持者。同时共有11家公司及组织，将作为最初的成员加入日本分部。他们是：

Ascent Networks
E-context
Infoteria
Livedoor
Mixi
@nifty
Technorati
Yahoo Japan
Six Apart
NRI
VeriSign Japan

这些公司来头都不小，其中Mixi是日本最大的社交网络，远远抛开其他活跃于欧美的著名社交网，垄断本土市场；他们在加入日本OpenID基金会分部后，将随即提供OpenID支持。这种成员的加入，将在OpenID的推广，特别是本地化推广上，起到举足轻重的作用（想像一下QQ支持OpenID的局面）。

OpenID基金会（日本）的最终名称和组织形态还未完全确定，但他们将在4月份获得美国总会的许可后正式建立。OpenID基金会副主席David Recordon在昨天东京的发布会上表示，正如欧洲的本土OpenID社区在2007年OpenID推广活动中所作出的卓越贡献一样，基金会日本分部将在未来扮演同样的角色，帮助将OpenID渗透进日本的主流网络服务中。

更少的密码还是——没有密码？

=my — Mon, 25 Feb 2008 13:46:27 GMT

在Linus著名的三段论中，技术产生于基本的生存需求，即技术降低了为达到同样的生存状态而付出的成本；换种说法，我们因为懒惰而创造技术。当用户懒得去记住越来越多的密码的时候，类似豌豆或者1Password的服务诞生；当网站也懒得去管理用户越来越多的密码的时候，OpenID诞生；那些指责OpenID将鸡蛋放在一个篮子里的人，恐怕多数还是会在各种账户中使用同一个密码，因为懒惰从来不是错误；如果当我们连密码都懒得记了呢？

为了摈弃密码，我们使用一种可以传送认证信息的加密文件，即客户端证书。熟悉银行业务的人对于客户端证书一定有所了解，这种在上世纪90年代就已经存在的技术，被广泛应用于网络银行以及税务申报系统，但在别的地方却很少见，以至一般人极少注意到它的存在。

那它到底存在么（记住，我们始终将话题围绕在OpenID周围）？如果你是一位MyOpenID的用户，恭喜你，它是存在的，并且它就在那儿。MyOpenID提供了这种称为SSL证书认证的登陆模式，在Authentication Settings下，你可以创建一个证书，这张证书被保存在本地，你可以备份并转移这张证书，你也可以在任何你认为安全的终端上创建任意多张证书。一旦证书被创建，它就和你的MyOpenID账户挂钩，当你在MyOpenID登陆的时候，MyOpenID向你的浏览器索取证书并完成验证，然后将你弹回Consumer。如果你想在你的网站上实现SSL认证支持，这篇HOWTO应该有所帮助。

无须密码的登陆过程给人的体验是很神奇的，由多至少的量变效应远远不及从有到无的质变。Microsoft在探索认证框架的时候，也创造了一种沟通用户和联机服务的系统：CardSpace。CardSpace用个人信息卡代替证书，在用户和服务之间充当信使。除了完成认证外，CardSpace还能同时向联机服务发送卡上存储的信息，因此它更符合一个账户系统的需求。

在被原生支持的Vista中，CardSpace拥有和SSL证书一样友好的用户体验。因此在去年上海那次OpenID交流会上，我曾夸张性的提出CardSpace将击败OpenID（估计没有人记得了），但那里的人是为了OpenID而去的——就像你在Joomla论坛提问是Joomla好还是Drupal好无法得到客观的答案一样——没有人理会我。

事实上，CardSpace没有击败OpenID，而OpenID也没有令CardSpace消失，微软在认证领域的努力使他们紧紧跟随OpenID而没有被抛下。如今，MyOpenID（是的，又是MyOpenID，我一直都坚信自己一年前在wiki中所作的判断）将CardSpace也纳入其中。还是在Authencation Settings页面上，你可以发现添加Information Card的小节，通过绑定信息卡，来体验一下不用密码的感觉吧。更早提供CardSpace登陆的OpenID Provider是SignOn，不过JanRain却率先公开了实施CardSpace支持的Python代码，而LinkSafe则神奇的成为一家能用Information Card登陆的i-name注册商（他们同时还是历史上第一个尝试提供免费i-name和i-name托管转移的商家）。

凭借SSL和CardSpace，MyOpenID的用户黏度空前高涨，我实在找不出任何使用其他OpenID Provider的理由。因为对于像我这样时刻携带本子的人来说，证书式认证是抛弃密码的良好解决方案，但无论SSL还是CardSpace，他们最大的问题是不便携：他们是用来在受控终端上使用的，在公共终端或临时在另一台机器上登陆需要繁琐的备份导出过程，这简直是一场用户体验灾难。

那么，除了摈弃密码，另一个方案或许更有前途，那就是替换密码。这方面已经作出尝试有TrustBearer以及更早的爱沙尼亚eID，他们使用更为便于携带的智能卡或USB令牌作为密钥。其中我更为看好TrustBearer，因为在最初的支持列表中，我们看到了指纹识别器，用无法抛弃无须记忆的指纹作为密码，将懒惰式登陆推到极致。

在各种动作或者科幻大片中，我们见识过一些超级安全系统，往往是射频、虹膜、指纹等多重认证，对于安全要求不是很高的普通应用来说，没有密码也是必然的发展趋势，因为懒惰，从来都不是错误。

dotnetopenid 0.1.1 发布

=my — Mon, 25 Feb 2008 03:50:01 GMT

几天前，Andrew在Google Groups中发布了DotNetOpenID 0.1.1，包含了一些新的特性和安全更新：

Added OpenIdTextBox.ShowLogo property to easily show OpenID logo from embedded resource.

Added a Remember Me checkbox to the OpenIdLogin control.

Added OpenIdLogin.RegisterVisible property.

Fixed UTC/Local DateTime inconsistent usage.

Fixed bug where one of CheckIdRequest’s constructors would always fail due to passing Uri.AbsolutePath to TrustRoot’s constructor.

Improved security by adding TrustRoot validation that was missing from earlier versions.

Added OpenIdTextBox.TrustRootUrl property.

Andrew和他的小组成员们的努力工作，使.NET平台上的开发者可以轻松的将OpenID支持加入应用，并享受这个目前最为成熟的.NET项目带来的便利。你可以从这里下载代码和演示：

http://dotnetopenid.googlecode.com/files/dotnetopenid%200.1.1.zip

Openvatar 你怎么不觉悟？

=my — Sat, 16 Feb 2008 09:47:37 GMT

Openvatar 是一家刚刚上线的头像托管服务，支持 OpenID 登录。用户将头像上传到 Openvatar 的服务器上，然后使用 avatar.php 进行调用：

http://www.openvatar.com/avatar.php
?openvatar_id=9b2894b2fa12ea24c455f4be9331d3fe
&size=50
&default=”http://www.mysite.com/avatar.jpg

博客们最早广泛的接受头像始于 Gravatar ，他们用邮件地址作为用户 ID ，通过插件来实现头像调用，支持的平台相当广泛。内部 Gravatar 和 Openvatar 的调用语法十分相似（几乎一模一样）， avatar id 也是一个 MD5 的邮件地址，同时还有一样的 size 和 default 属性。

随后 Gravatar 经历了一段长时间的掉线，使我们逐渐放弃它，并开始思考分布式（就像 OpenID 一样）的存储方式。 Pavatar 由此诞生。简单的说， Pavatar 更像一种规范而非服务。它用三种方式规定头像文件的位置。

修改 HTTP 头增加 X-Pavatar 属性；
在 HTML 头增加标签
<link rel=”pavatar” href=”http://example.com/path/my-pavatar.png” />；
类似 favicon.ico 标准，将 pavatar.png 放置在 URL 根目录。

很快，第二名称也推出个人网络图标，而将头像加入 OpenID 协议的讨论也在社区中轰轰烈烈的进行了一段时间，但很快，我们发现这样做显得如此的多余。 Gravatar 因为将某种公开而微小的信息（头像）加密并集中存储而显得多余， Pavatar 则在现有的标准身边尝试创造新标准而显得多余。

是的，这个现有的标准就是 Microformats 。头像和诸如姓名、地址等个人信息一样，是开放的、可见的，因此一开始， hCard 就包含了 class=photo 的定义。在 OpenID （或者任何 URL 标识）应用端看来，使用 avatar 的过程十分简单：

连接 OpenID URL 寻找 hCard 段，如果有 photo 字节，使用其提供的头像地址；
如果没有 photo 或者没有 hCard ，那么在 OpenID URL 根目录寻找 avatar.png （这一步涉及到创立一种新规范及其他很多问题，不推荐但也并非不可行）；
没有发现任何头像信息，则使用内置的缺省头像。

整个过程很干净，应该说是目前头像应用比较完美的解决了，有兴趣的朋友可以看一下Wordpress 的 hAvatar 插件。

回头再看一看 Openvatar 的发布，一下把人拉回到 Gravatar 时代，就算跟 OpenID 扯上那么一点关系，也不能太缺乏觉悟吧。

TrustBearer 推出强化安全认证的 OpenID

=my — Thu, 14 Feb 2008 05:16:58 GMT

还记得去年提到过的爱沙尼亚吗，他们将 OpenID 服务关联到公民身份证中，率先提供了一种使用硬体认证的 OpenID 。现在，不用后悔自己没有生在爱沙尼亚了（即使不为了 OpenID ，那里几乎 100% 的网络覆盖率也值得你重新投一次胎）， TrustBearer 实验室最近刚发布了他们自己的 OpenID 服务，集成 TrustBearer Access 套件。

TrustBearer 实验室在安全认证领域有超过 10 年的软件开发经验。这次他们推出的 OpenID 体系十分类似爱沙尼亚的 eID ，通过在认证环节中插入硬体验证来提供强化安全的 OpenID 。更重要的是，由于兼容了现有的认证设备标准，他们的 OpenID 支持超出想象数量的外设种类。从智能门禁卡、 USB key 到指纹，理论上说，所有基于 CCID 的智能卡阅读器、 PIP 卡、 CAC 卡、 Java 卡都可以使用，光是这份已经过完全测试的支持列表就足以令人眩目了：

Device	Provider	Photo	OS Support
TrustBearer Security Key
Smart Cards
CAC (Common Access Card)	various providers
PIV (Personal Identity Verification)	various providers
JCOP, personal smart card
Cosmo 64RSA, personal smart card
Smart Card Readers
Athena, ASEDrive IIIe USB V2 Smart Card Reader
GemPC Twin, smart card reader
Cardman 3021, smart card reader
SCM, SCR3311 smart card reader
USB Tokens
Cardman 6121, personal USB dongle
ID-One, personal USB token
SCM, SCR3320 smart card reader
Biometric Readers
PlusID 90, personal biometric fingerprint token
Precise Biometrics 200MC, personal biometric fingerprint and smartcard reader
Precise Biometrics 250MC, personal biometric fingerprint and smartcard reader

其中实验室也提供了自己的 USB key ，称为 TrustBearer Security Key ，价格 40 刀，可在线购买，当然多数人将可以利用已有的设备。

XRDS 完结篇

=my — Wed, 13 Feb 2008 15:48:46 GMT

让我们继续认识 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 的新动向也不多，真的是一个很缓慢的社区。

Yadis 插件

=my — Mon, 11 Feb 2008 11:39:17 GMT

继续之前，插播一条消息。

对于不想自己动手的朋友，如果你们需要的只是前面提到的多 OpenID 委派，并且你在你的 URL 上运行着 Wordpress ，有一个插件可以比较轻松的自动生成 XRDS 文档： WP-Yadis 。

http://wordpress.org/extend/plugins/yadis/

它将一个 <meta> 插入到页面的 <head> 中，同时将 XRDS 文档存为 Wordpress 根目录中的“ xrds ”。在有更新的版本前，这个插件基本上只能编辑 XRDS 中的 OpenID 服务，并且不会自动帮你集成多个 OpenID 版本。这个方法虽然很偷懒，但也是有效的，而随着插件的升级，新的功能一定会被引入，但是无论如何，自己动手吧， XRDS 实在是很简单的。

将 WP-Yadis 和 WP-OpenID 插件同时武装进你的 Wordpress ，你的博客就可以自称是 OpenID Enabled 了。

深入 XRDS

=my — Sun, 10 Feb 2008 11:06:29 GMT

昨天，我们建立起了一份简单的 XRDS 文档，并利用位于 <head> 中的 <meta> 元素将其植入我们的 Yadis URL 。正常情况下， Yadis URL 应该返回 HTTP 头中所声明的 application/xrds+xml 格式的 XRDS ；但协议同时提到，如果 HTTP 头没有指出位置，而 URL 返回了一个 HTML 文档，那么可以解析 HTML 从中提取 <meta> ，并将 XRDS 返回。这使我们可以十分轻松的在 URL 上实现 Yadis 支持。

XRDS 文档，又称为 Yadis 资源描述文档。它使用 Extensible Resource Descriptor 格式，这一格式由 XRI Technical Committee 开发，并包含进 XRI 解析规范中。

<xrds:XRDS
    xmlns:xrds="xri://$xrds"
    xmlns="xri://$xrd*($v*2.0)"
    xmlns:openid="http://openid.net/xmlns/1.0">
  <XRD>
    ......
  </XRD>
</xrds:XRDS>

文档顶层是含有名称空间定义的 <XRDS> 标签，它包含一个或多个 <XRD> 元素，昨天的例子中我们只有一个 <XRD> 。如果有多个，那么最后的一个是可用的，如果一个都没有，这个文档也是有效的，但不含任何的服务。

    <Service priority="10">
      <Type>http://openid.net/signon/1.0</Type>
      <URI>http://www.myopenid.com/server</URI>
      <openid:Delegate>http://yourname.myopenid.com/</openid:Delegate>
    </Service>

在 <XRD> 中，服务由 <Service> 来描述。一个 <Service> 至少有一个 <Type> 元素，定义服务类型。同时根据不同的服务，还有其他各种标签来提供进一步的信息。可以看到上面的例子，是定义一个 1.0 的 OpenID ，在 OpenID 中，这一方式也叫委派。

至此，我们花费了十几行代码，才实现了过去流行的在 HTML 中使用两个 <link> 标签在个人域名上向外委派 OpenID 的功能。但这是值得的，因为你很快注意到位于 <Service> 中 priority 的这个属性。

这是一个重要的属性， priority 用来指定某个服务的优先级。我们可以用它来实现一些实用的特性。先看一个 MyOpenID 的标准 <XRD> 节。

    <Service priority="0">
      <Type>http://specs.openid.net/auth/2.0/signon</Type>
      <Type>http://openid.net/sreg/1.0</Type>
      <Type>http://openid.net/extensions/sreg/1.1</Type>
      <Type>http://schemas.openid.net/pape/policies/2007/06/phishing-resistant</Type>
      <Type>http://openid.net/srv/ax/1.0</Type>
      <URI>http://www.myopenid.com/server</URI>
      <LocalID>http://yourname.myopenid.com/</LocalID>
    </Service>

    <Service priority="1">
      <Type>http://openid.net/signon/1.1</Type>
      <Type>http://openid.net/sreg/1.0</Type>
      <Type>http://openid.net/extensions/sreg/1.1</Type>
      <Type>http://schemas.openid.net/pape/policies/2007/06/phishing-resistant</Type>
      <Type>http://openid.net/srv/ax/1.0</Type>
      <URI>http://www.myopenid.com/server</URI>
      <openid:Delegate>http://yourname.myopenid.com/</openid:Delegate>
    </Service>

priority 的值是一个数字，越小说明优先级越高。这里用 0 和 1 分别将 2.0 和 1.1 的 OpenID 都描述下来，这样这个 OpenID URL 就可以在实施不同版本的网站上进行登录，而不会像 Yahoo! OpenID 那样在 1.0 的网站上失败。注意看这里两个 <Service> 的 <Type> 是不同的，如果我们描述两个相同的 <Type> 呢？

    <Service priority="10">
      <Type>http://openid.net/signon/1.0</Type>
      <URI>http://www.myopenid.com/server</URI>
      <openid:Delegate>http://yourname.myopenid.com/</openid:Delegate>
    </Service>

    <Service priority="20">
      <Type>http://openid.net/signon/1.0</Type>
      <URI>http://www.livejournal.com/openid/server.bml</URI>
      <openid:Delegate>http://yourname.livejournal.com/</openid:Delegate>
    </Service>

这是两个 1.0 OpenID 的描述，聪明的你应该想到了它的作用。网站在解析出这个 XRDS 文档后，发现两个一样的服务，于是它先使用优先级高，也就是 priority 值小的那个，如果第一个服务失效了，那么网站会沿着优先阶梯继续发出请求，直到成功为止。利用 priority ，我们很好的解决了上次 MyOpenID 离线引发的问题而不用担心网站端是否支持绑定多 OpenID 。

由优先级属性引起的第三个附加作用，是负载平衡。如果多个相同的服务被指定相同的优先级， Yadis 规定其中一个将被随机的选中。如果这一技巧频繁出现在将来的 XRDS 中，那说明 OpenID 已经产生显著的影响力了，因为截至目前， OpenID 仍是 Yadis 中使用的最多的服务。

盘弄一下你的 XRDS ，然后休息一下，看看接下来我们还能做些什么。

建立起你的第一个 XRDS 文档

=my — Sat, 09 Feb 2008 10:15:41 GMT

还记得 IDSelf 中断更新前，本来想介绍一下 XRDS，于是有了获得一个 i-name 的文章。当时，只有 i-name 才可以对自己的 XRDS 文档进行编辑。当然你也可以用库里的程序在自己的 URL 上架设服务器，或者用一点小技巧。更容易的，我们使用这样一个标签：

<meta http-equiv="X-XRDS-Location" content="http://yourname.com/xrds.xml" />

这么做是为了让你的 URL 支持 Yadis 发现。 XRDS 文档也可以称为 Yadis 文档。这个文档以 XML 格式存储，因此首先是一行对文件类型的描述：

<?xml version="1.0" encoding="UTF-8"?>

接下来我们在根元素中定义名称空间，类似这样：

<xrds:XRDS
    xmlns:xrds="xri://$xrds"
    xmlns:openid="http://openid.net/xmlns/1.0"
    xmlns="xri://$xrd*($v*2.0)">
  <XRD>

最后以此结尾：

  </XRD>
</xrds:XRDS>

位于 XRDS 中间的部分，是对各种服务的描述，也是 Yadis 的意义所在，你首先拥有的最有可能是对 OpenID 的定义：

<Service priority="0">
  <Type>http://openid.net/signon/1.0</Type>
  <URI>http://www.myopenid.com/server</URI>
  <openid:Delegate>http://yourname.myopenid.com/</openid:Delegate>
</Service>

先不去深入它的含义，让我们组装起自己的第一份 XRDS 文档：

<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS
  xmlns:xrds="xri://$xrds"
  xmlns:openid="http://openid.net/xmlns/1.0"
  xmlns="xri://$xrd*($v*2.0)">
  <XRD>
<Service priority="0">
  <Type>http://openid.net/signon/1.0</Type>
  <URI>http://www.myopenid.com/server</URI>
  <openid:Delegate>http://yourname.myopenid.com/</openid:Delegate>
</Service>
  </XRD>
</xrds:XRDS>

如果你有一个 i-name ，你会发现 XRI 解析出的 XRDS 稍有不同，你最好还是有一个 i-name ，因为下面有的列子只有 i-name 能做。

欢迎 OpenID 基金会的新董事们

=my — Thu, 07 Feb 2008 02:38:57 GMT

基本上，你已经知道 Yahoo! 开始提供 OpenID 服务（尽管他们的地址不怎么好记）， Microsoft 在一年前的 RSA 安全会议上也曾经承诺整合 Cardspace 和 OpenID （尽管什么动作都没有看到）， Google 则在他们的 Blogger 中小心翼翼的支持 OpenID 评论（尽管使用的是 1.0 使得 Yahoo 帐号无法登录），你是否和我一样以为这些行业巨头们态度一点也不认真呢？直到今天晚些时候，一则新闻才打破我们的疑问。 OpenID 基金会宣布了 5 个新的董事会成员，他们分别是 Google 、 IBM 、 Microsoft 、 VeriSign 和 Yahoo! 。

这或许将成为今年 OpenID 社区中最重大的事件，这些巨人们从来没有像今天一样一起行动过。这 5 家以公司名义加入董事会的成员，各自派遣了一名代表参与协助基金会的日常工作，他们分别是：

Dewitt Clinton 来自 Google
Tony Nadalin 来自 IBM
Michael B. Jones 来自 Microsoft
Gary Krall 来自 VeriSign
Shreyas Doshi 来自 Yahoo!

我们看到，实际上一个横跨面广泛的认证体系并不是雾里看花，而是实实在在的需求，所有参与者的合作努力将促成 OpenID 在此领域的成功。 2008 年有一个良好的开端，人们在继续解决 OpenID 安全性问题的同时，也将 3.0 摆上了议事日程，重量级玩家不断涌入，公众的认知度也是护士涨， 2008 将成为 OpenID 之年。

对于商业公司加入董事会的疑虑，基金会保持了以 Kveton 为首的 7 个来自社区的董事和 1 个欧洲代表，以维持董事会的平衡，乃至董事会和整个社区间的平衡。接下来会发生什么激动人心的事情，让我们拭目以待。

Scott Kveton 加盟 Vidoop

=my — Wed, 06 Feb 2008 13:35:29 GMT

在参加完 SG FooCamp ‘08 后， OpenID 基金会主席 Scott Kveton 马不停蹄的加盟了 Vidoop ，任副总裁负责开放式平台部门，以及其位于波特兰新办事处的主管。

Kveton 在开源界是个人物。除了基金会主席，他还是 JanRain 的 CEO 以及 Open Source Lab 的创始人，前者旗下有着 MyOpenID 、 Jyte 等强悍产品，后者则支援着一大批开源项目的开发，如著名的 Firefox 。

而 Vidoop 来者也不善。他由一群前美国海军破译工程师组建，并且持有一笔长期的固定投资。他们的 OpenID 服务称为 myVidoop 。或许你听说过但没有关注过， myVidoop 在安全性方面有着自己十分有趣的解决方案。在注册过程中， myVidoop 会要求你从一些随机图片中至少选出三个来，每张图片代表某个类别，如“空间”、“电脑”、“宠物”等。当再次登录的时候， myVidoop 再次从图片库中随机提取一系列来，这些图片不一定同于注册的时候所出现的，但肯定含有能代表同一种类的图片；这个时候，只有用户才能正确选出对应的图片。这种机制被称为 Captcha ，与被广泛应用于各种网站注册流程中的 Captcha 虽然不太一样，但都是通过语义信息来防止机器人攻击。 myVidoop 十分聪明，他们在图片所代表的不同领域寻找合作商，并将广告图片注入图片库中，如果你注册的时候选择过“电脑”这个类别，不要奇怪将来登录中会时不时的出现 Lenovo 、 HP 的标志。

震惊吗？当你仍然在 OpenID 的 QQ 群中看到大量对于 OpenID 盈利模式的质疑的时候，已经有人不动声色的在做了。你或许会不屑一顾，这个模式看似并没有 OpenID 什么事，但其实问题就在于我们过于保守了，同时缺乏创新。而在另外一份 OpenID 服务提供商的对比表中，我们可以再一次领略 Vidoop 的实力。

回到主题，这次 Vidoop 牵手 Kveton ，将继续增强他们在开放式标准领域的开发能力，并进一步扩大他们的影响力，对于整个社区，也将是极大的推动。

Good luck, Kveton !

没有 MyOpenID 的世界

=my — Mon, 04 Feb 2008 13:12:52 GMT

作为极富创意的 Janrain 公司的产品之一、最早的 OpenID 服务提供商， MyOpenID 一直以来都保持着较高的活跃度。世界上绝大多数主动注册的 OpenID 帐号都直接或间接的托管于 MyOpenID 。尽管 OpenID 是一种“分布式的“认证框架，但我们仍然习惯于信任某个大众化系统；那么一旦这个受信系统崩溃会怎样呢？

今晨 5 点左右， MyOpenID 经历了一次一个小时左右的网络维护，期间 MyOpenID 网站离线，所有 MyOpenID 帐户均无法使用以登录其他网站。让我们用刘韧体来思考一下这个没有 MyOpenID 世界的前前后后：

1. OpenID 以分布式为其首要特点，在彻底理解分布式之前，我们面临一个更大问题，由于在认证框架中多了一方，服务离线的几率变的更大了。

2. 如果仅仅是 OpenID 服务器宕机，我们仍然可以在应用网站上临时注册帐号来使用，既然这样，干嘛不直接注册帐号还要 OpenID ？

3. 为了避免某个 OpenID 服务器宕机而引起问题，我们在多个 OpenID 服务提供商处注册帐号；这么做首先需要应用网站支持绑定多个 OpenID（事实上，这样网站不多），其次我们又回到需要管理繁多帐号的境地。

4. 进一步，我们注册一个域名，用委派的方法将域名作为 OpenID 帐户，当某个 OpenID 服务器挂掉，我们可以迅速的改变委派来保证 OpenID 的正常使用。

5. 于是我们变得更加保守了么？不，只要 OpenID 存在，第三方就存在，服务离线的几率仍然没有减少，想象一下主机空间宕机了。自架服务器在一定程度上是完美的，但没有人会这么做。

6. 采用委派带来的更为严重的是所谓的 OpenID 循环问题， OpenID 认证过程是通过用户对 URL 所有权的证明来实现的，如果你失去一个作为 OpenID 的域名并随后被其他人注册，那意味着他合法的继承了你所有使用该 OpenID 网站的帐户及资料。 i-name 以及 2.0 都在努力寻求解答，但不是现在。

7. 于是我们绕了一圈，回到必须使用类似 MyOpenID 的独立服务商的最初状态，并承担风险。

8. OpenID 从一开始就是一群技术精英创造的，带着明显的理想主义精神。它将成功还是失败，我们拭目以待。

Yahoo! OpenID 服务公测

=my — Thu, 31 Jan 2008 15:50:07 GMT

今天 Yahoo! 在他们的开发者日志上正式宣布其 OpenID 提供商服务开始公开测试，两亿四千八百万的 Yahoo! 用户，拥有了直接登录任何支持 OpenID 2.0 标准网站的能力。

紧随 AOL 、法国电信以及 Google （至少是 Blogger ）后， Yahoo! 作为业界超级玩家加入 OpenID 阵营，使得 OpenID 用户在三年多后终于艰难的达到了四亿，尽管这里面绝大多数都不是主动者。

在这篇日志中， Yahoo! 强调了几点关键特性：

1. 可用性：得益于 OpenID 社区成员们对于加强用户体验所作的努力，在 2.0 中，用户不必输入令人费解的 OpenID URL 完整形式（如果你读过 2.0 ，会发现它确实是费解的），只需使用服务器地址即 yahoo.com 登录，支持 2.0 的应用站点会理解并将用户带到 Yahoo! 的登录界面中完成认证。这项改进看似十分软，但对于一直以来以“推广”为最大难题的 OpenID 来说，很有可能是具有转折意义的硬朗特性。

2. 用户培训： Yahoo! 不遗余力的进行 OpenID 推广，从更狭隘的意义上来说，更类似一种信徒行为。所有 OpenID 或者任何一种不够大众的技术社区的参与者，无不在其所能影响的范围里，企图制造更多的影响。当然，这一切都是值得的。

3. 反钓鱼：被 Yahoo! 称为登录印章的服务，类似 MyOpenID 的安全头像，利用浏览器 session 及用户端自主意识来对假冒网站进行预防；与另外一种以 MyOpenID 的安全登录及 Firefox 3 中将引入的 OpenID 支持为主的系统级防伪，构成目前较为主流的 OpenID 安全措施架构。

Yahoo! 将 OpenID 列入了其应用目录中，尽管我们已经有了 OpenIDDirectory ，但相信将来这个目录会因其更高的流量而产生更深远的影响。

最后值得一提的是， Yahoo! 在这篇开发者日志中详细的提供一份鸣谢名单：

We’d like to take this opportunity to thank the OpenID community for educating us over the past 1 year and helping us make this happen. In particular, we’d like to say “Thank you” to Bill Washburn, Brian Ellin, David Recordon, Dick Hardt, Johannes Ernst, Johnny Bufu, Joseph Smarr, Josh Hoyt, Kaliya Hamlin, Kevin Turner, Larry Drebes, Mike Graves, Scott Kveton, and Simon Willison.

基本涵盖了社区中常见的各色人物，可见 Yahoo! OpenID 的开发者小组已经十分深入的融入进来了。

Zooomr 2008发布中

=my — Thu, 31 Jan 2008 09:11:00 GMT

希望这次 Zooomr 不要保持跳票传统，根据 Zooomr 信息中心公布的最新进展，数据服务器已经完成在东京的转移，绝大部分功能已经恢复正常了，最后的上传也将在近一两天内重新上线。

关于这次代号为 Mark IV 的发布的具体信息还不是很多，一个所谓的重要更新是版权系统。版权标签将可以作为搜索项，例如，如果你想寻找符合 CC 的美女图片，直接搜索就得了。

微软积极配合通行证系统的互联互通

=my — Mon, 11 Jun 2007 08:21:36 GMT

随着 Web 2.0 的深入发展，新的认证体系也逐个浮出水面，这其中除了我们经常提起的 OpenID ，还有来自自由联盟的 SAML ，以及微软在 Vista 中带来的 CardSpace 系统。多种体系并存所导致的是人力的浪费和社区的分裂，也会使终端用户左右为难，历史上 Unix 的发展是一个典型案例。现在，人们经常会在早期就开始考虑兼容并通的问题，而自由联盟的 Concordia 计划就是因此而产生的。

事实上，自由联盟最初是为了反微软的 .NET Passport 而建立，尽管事情在慢慢发生变化，但自由联盟一直以来对 Passport 的冷淡态度也使得微软无心加入这个大家庭。但历史的潮流是不可阻挡的，打着 Identity 2.0 标签的 CardSpace 没有理由再拒绝社区的合作项目，因此他们同意参加本月底即将在旧金山召开的 Concordia 大会。微软 CardSpace 小组的 Mike Jones 将出席会议，他将和同行们一起听取来自 AOL 、 Boeing 、 General Motors 等厂商的成功经验，并讨论如何运用到各自的项目上。

在年初，微软曾宣布将支持 OpenID ，其时业内欢呼一片，而现在他们的合作进一步在加强。自由联盟的主席 Sullivan 表示，微软加入 Concordia 显示了他们对于该项目的信任和信心， Concordia 不会对任何组织实行强制性举措，并将一如既往的站在公开、公平的立场上，以独立论坛的身份帮助社区的积极发展。

openid.org 域名风波

=my — Sun, 10 Jun 2007 05:55:35 GMT

OpenID 虽然是个比较新的概念，但对于域名投资者来说，这种简单易记的词组，早早就会放在桌头。稍微了解过 OpenID 的朋友一定知道他们的主站点位于 openid.net ，之前一段时间 openid.org 也指向 openid.net ，但 openid.com 和 openid.org 都不在 OpenID 基金会手上，并且对于 OpenID 这样的项目， .com 和 .org 的重要性更大。因此， OpenID 社区的主要成员们，一直和另外两个域名，尤其是 openid.org 的所有者进行交涉，希望拿回域名所有权，有必要的话也会支付一定的转让费。在刚刚结束的 IIW 2007 上，拿回域名这件事也作为一项 Todo 被重点提出过。

openid.org 和 openid.com 虽名花有主，但一直处于闲置状态，连停靠都没有。但就在大约一周前， Jyte 上出现了 http://steven.openid.org 的用户。马上点进 openid.org ，发现他们已经作为一家 OpenID Provider 上线了，网站非常崭新，其时首页显示大约仅有 10+ 个注册 ID ， Steven 实际上是这个域名的所有者和网站创始人。 OpenID.org 的上线在社区中引起了一点小小的波澜。因为 OpenID 基金会一直在联络 openid.org 企图买回域名，而 Steven 却一直保持缄默，如今网站作为服务商出现，必然可以利用其极品域名取得不错的 SEO 效果及未来可能的商业价值，对于开源社区，这让人很难以接受。

从该站点开通，可以看出 Steven 完全没有转让域名的意思了。有人认为可以利用 OpenID 的商标所有权向 ICANN 提出域名申诉，但 openid.org 在 2005 年 3 月就已注册，而 OpenID 商标则生效于稍后的 5 月； openid.com 则更是可以追溯到 2001 年。因此通过申诉找回域名是很困难的，只能寄希望域名所有者大发善心了。对于社区中某些人的不满， Steven 解释道：

I’m actually trying to get some people using a single open, free provider and so create more consumers rather than yet more commercial providers. Is that not something people are confused with. Is an ORG provider not quite sensible?

I didn’t give up the domain name because i saw it as valuable for open projects i wanted to use it for - not financially, more more in terms of openness. I had another project intended for it when i bought it some years back, but with the advent of OpenID figured i could help the cause rather than obfuscate. I have chosen to redirect with no hassles.

说回 OpenID.org 本身，作为 OpenID Provider ，他们也提供了一些有趣的功能。除了模仿 MyOpenID 的安全头像外， Steven 做了一个邮件转发接口。在发送消息页面上，输入对方在 openid.org 的帐号和信息内容，系统就会将其转发至对方帐号的邮件地址中，这个有一点类似 i-name 的 Contact page 。另外在首页上我们还可以看到 Steven 正在开发转发至 Twitter 的功能。另一个很引人注目的是 mobile 版本，可以用于手机使用的界面。虽然 OpenID.org 还 bug 多多，如 FF 下排版混乱、个人档案无法建立等，但看的出 Steven 是个虔诚的 OpenID 爱好者和程序员，大家都是为了 OpenID 的良性发展，这场域名风波还真的不知道该向着谁。对于用户来说，你又多了一个 Provider 的选择，而且现在的注册人数还不到 50 人，如果你不满意在 MyOpenID 的用户名，可以来这申请个短的，而且挂的后缀也够吊。

我承认，我也注册了一个，并且我认为 openid.org 还是应该还给 OpenID 社区。

Update: Steven 全名 Steven Livingstone-Pérez ，个人网站 livz.org 。

Webware 百强最后一天

=my — Sun, 10 Jun 2007 03:43:06 GMT

在最近的各种线上评选中， OpenID 除了摘得 2007 Next Web 大奖，还进入了 Webware 百强提名。这一奖项由网民自由投票，从 10 大类共 250 个网站和应用中评选 100 名最终得主。 Webware 的分类很奇特， OpenID 位于 Browsing 类，与 Firefox 、 IE7 、 Google Reader 等同场竞技。估计绝大多数的选票都将投向 Firefox ，剩下的 9 个就看各个产品的粉丝数量了，因此 OpenID 最终能否入围百强，是很不容乐观的。当然，评奖只是一种大众偏爱的娱乐形式，结果如何，都不会影响各种优秀的应用在各自领域发挥所长。 OpenID 能进决赛，说明它已经受到越来越多的关注了，我们期待 OpenID 一路走来能茁壮成长。

今天是 Webware 百强投票的最后一天， 11 号票选将关闭，结果统计出来后将在 18 号公布。既然您来看 IDself 了，难道不投 OpenID 一票？

换掉 Habari

=my — Thu, 07 Jun 2007 04:02:14 GMT

最近几天都没有更新了，一来每天晚上在上课，二来下课回到家得照顾小狗，喂食、洗澡、陪它玩……我第一次养小狗，所以每天都是手忙脚乱的。这只小狗是同事收养的，然后转送给我，因此没有名字。开始我给它起名 OpenID 希望它随着 OpenID 一起成长；不过这名字实在是难叫，前段时间不是还有一个给 OpenID 起中文名的活动吗，可见人都觉得这个单词听起来麻烦，况狗呼。于是取头尾，就叫 OD ，中文念“欧弟”，当然此“欧弟”是不会模仿张学友的。

我听取了天真的建议，把 Habari 换掉，重新用上熟悉的 WordPress 。当时用 Habari 纯粹是因为想尝试一下用一个新系统写博。这个程序非常简洁，如果不考虑定制，几天用来就基本可以把它翻烂，所以差不多好换掉了。另外确实将来升级可能会有很多麻烦。第三 Habari 没有现成的 OpenID 支持，得自己写代码，而 WordPress 上插件则可以很方便的实现此功能，写 OpenID 的网站不支持 OpenID 就有点说不过去了。所以趁早期换回来，由于后台更换， feed 变了，如果有订阅过本站的朋友，请更新阅读器。这次俗套一点，新地址使用 feedburner ，您可以直接订阅 idself.cn ，会自动转向。

这里告诉大家我还活着，虽然 OD 把我搞的焦头烂额，但我会尽快重新开始更新 IDself 。

OpenID 获 2007 Next Web 大奖

=my — Sun, 03 Jun 2007 01:00:44 GMT

在 6 月 1 日荷兰阿姆斯特丹的 Tuschinski 剧院，新一界的 The Next Web Conference 圆满闭幕。会议上，来自 Zyb.com 的志愿主持人 Tommy Ahlers 颁布了 2007 Next Web 大奖。该奖项共分 8 个大类，在对 55000 多份票选进行统计后得出。

OpenID 最终在 Disruptors 类中拔得头畴。对于 Disruptors 这个词的理解，我稍微有点困惑。它字面的意思是干扰物、分裂或瓦解。在这里，我个人推测 Disruptors 可以理解为杂类，或者重量级应用类；这两种译法相去甚远，不知哪位达人可以指点一二。

和 OpenID 同在 Disruptors 中竞争的还有：

Joost
Netvibes
Zopa
Sellaband
Zecco
Edgeio
Turn
A Swarm of Angels
Pixenate - The online Photo Editor
37 Signals

对这些名字有些我们耳熟能详，有些则很陌生，但他们都是过去一段时间以来非常引人注目的网站；因此允许我暂且把 Disruptors 翻译为“杀手级应用”。

除了 Disruptors 外，另 7 类的 2007 Next Web 大奖分别授予了：

Entertainment: YouTube
Company: Yahoo!
Social: LinkedIn
Search: WikiPedia
Web Celeb: Tariq Krim
Beta & Stealth: Joost
Populizr: TechCrunch

这里有一小段幻灯片展示了所有参与竞选的公司、网站、应用或者个人。

获得一个 i-name

=my — Sat, 02 Jun 2007 04:07:11 GMT

相信你从三部曲中对 i-name 及 XRDS 有了一点点的了解，当然我自己的理解也是非常狭隘的，所以不能保证把问题完全说清楚了。

那让我们一起继续深究下去。为了在后面方便进行一些 XRDS 入门试验，我们得获取一个 i-name 。尽管根据 OpenID 2.0 ， URL 形式的 OpenID 也可以解析出一个 XRDS 文档，但目前几乎所有的 OpenID Provider 都不提供让你修改 XRDS 的功能，因此为了能快速开始，取得一个可以自由编辑 XRDS 的 i-name 还是很有必要的。

不幸的是，你已经从三部曲中知道了 i-name 十分昂贵。一个个人的、以“=”开头的 i-name 一年需要 20 美元。排除去年推广期的 50 年买断外， 20 美元是目前的全球统一价。我是从 2idi 购买的，它是早期的一个权威 i-name 注册商，我个人推测有超过一半的 i-name 都在他们帐下。如果你舍得这笔钱，那么就选 2idi 。

接下来，一个更便宜的地方是 LinkSafe 。 LinkSafe 以最早在社区中提供免费 i-name 而闻名。尽管他们不再提供了，但从今年 6 月 1 号开始，他们的个人顶级 i-name 降价为每年 12 美元，这个价格已经向国际域名逼近了，但就目前的情况看来，除非 i-name 出现杀手级应用，否则只有降到白菜价才会真的有人买。

最后才是你需要关心的，免费 i-name 。在五月中旬的时候上线的这家网站叫 @freeXRI 。如果算上 @XRID 的话， @freeXRI 是第二个免费提供次级 i-name 的网站。不同于 @XRID 的测试性质， @freeXRI 是专为提供免费 i-name 而生的，因此我倾向于将它称作第一家免费 i-name 注册商。该网站本身支持 OpenID ，你可以在你的账号下建立多个免费 i-name 并随意调整设置。而且重要的是， @freeXRI 的帮助文档、管理功能及辅助工具都非常完善，比任何一家收你 20 美元的授权 i-name 注册商都要好，这对于 XRI 及 XRDS 的迅速入门将有很大帮助。那么在我们继续之前，请去 @freeXRI 或者 @XRID 注册你的第一个 i-name 吧。

通行证三部曲

=my — Fri, 01 Jun 2007 03:45:42 GMT

这是我在刚深入接触 OpenID 的时候所做的笔记，很多想法和理解都很不成熟。原发于个人博客，连接过来

通行证
 通行证续一
 通行证续二

在后半段，我涉及到了 i-name 、 XRDS 以及 XRDS 的一点小把戏，稍候我们会来稍微多认识一下 XRDS ，这是 OpenID 2.0 所包含的一个重要特性；不过首先，如果你还完全不知道 i-name ，读一下三部曲。