林健的BLOG

　　前面三篇文章分别介绍了三类已经投入实际使用的、独立的 Identity 2.0 机制。与此同时很多在互联网时代既得利益的公司也都试图借助自己庞大的用户资源在身份认证领域分一杯羹。微软的 Windows Live ID（早期称为 .NET Passport、Microsoft Passport Network）算是动手比较早的，Google Account Authentication、Yahoo! BBAuth、Facebook Connect 等是各家公司推出的类似的身份认证服务。但这些服务本质上不符合 Identity 2.0“以用户为中心”的精神，它们仍使用原有的集中式用户系统，由这几家大公司自己维护用户数据，仅允许其它网站借助其 API 验证用户身份，读取用户的非敏感信息。这类技术的用户价值在于单点登录和相对安全（类似于 OpenID），单点失效问题通过内部对用户透明的分布或容错机制实现（目前阶段，这几家大型网站的可靠性相比小型的 OpenID provider 更有技术保障，至少用户的心理体验是这样）。对小型网站的经营者来说，让拥有 Google、Yahoo、Facebook 账号的用户直接登录自己的网站，同时能从知名网站获得用户的部分注册信息，确实有一定的吸引力。目前已经有像 clickpass 这样集成各家身份认证的第三方服务。而对于想为第三方网站提供身份认证服务的普通网站来说，开放的 OAuth 协议可以直接在既有系统中集成，twitter、豆瓣等是其成功案例。但 OAuth 更多地用于与提供身份认证的网站息息相关的第三方应用开发，还不能算是一种通用的身份认证机制。

　　此外还有一系列或是没有走出实验室、或是没有着力推广的 Identity 2.0 技术。关于它们的讨论可以通过以下一些网站获取：
　　● Identity 2.0 Blog
　　● Identity Commons Wiki
　　● Internet Identity Workshop
　　我们回过头来看，Identity 2.0 概念的提出大约有五年了，而事实上像 Microsoft Passport Network 之类的原型产品的推出是更早之前的事。但即使是现在发展情况最好的 OpenID，支持它的独立公众网站也维持在三位数之内。而看看上述几个网站，文章和项目的活跃程度也在逐渐下降，不少链接失效。Identity 2.0 为什么没有像 Web 2.0 那样大放异彩？这个问题值得业内人士思考。我列出以下几点：
　　“鸡与蛋”的问题——要想让基础设施（互联网标准、客户端软件）支持 Identity 2.0 的特性，就需要用足够的杀手级应用来说明其重要性；而要建立有影响力的杀手级应用，又需要基础设施的原生支持。要让用户接受并广泛使用 Identity 2.0 的个人身份，就需要有大量的既有应用启用 Identity 2.0 机制；而要让现存的网站加入对 Identity 2.0 的支持，又需要广大持有 Identity 2.0 身份的用户来诱发。
　　使用的体验的改变——普通用户可能不会理解 OpenID 这种 provider 中介模式的安全优势，因为在用户看来还是要输入一次用户名密码的，而且是把密码交给了第三方。对于 Information Card，用户可能难以习惯长期保存并随身携带 Card 文件的使用模式，在经历了一两次 Card 丢失或一时无法取得的情况，就会打击用户的使用兴趣。而如果在线保存 Information Card，又存在和密码托管网站一样的信任危机。至于基于 XRI 的 i-name，普通用户可能也不愿意为其缴纳年费。
　　安全性问题——这是任何一种身份认证机制都必须首先保证的。各类 Identity 2.0 技术都宣称自己的协议比传统方式安全，这不假，但它们的前提假设是：provider 等第三方机构确实可信；用户按照一定的规程来使用（比如不随意复制未加密码的 Information Card）。如果 provider 作恶或者用户不遵守使用规程，同样会造成信息泄露。provider 作恶在其它分布式系统中是存在的（比如 DNS 欺骗、虚假 Tor 节点等），难免在 Identity 2.0 中重演；而引入新的用户体验之后，要求用户掌握其操作原则是有时间成本和运营风险的。
　　用户价值的体现——我认为这是核心因素。Identity 2.0 究竟能不能给用户带来全新的使用价值？是否满足普通用户和网站经营者双方的利益需求？身份认证方面的创新能否给互联网带来足够大的积极影响？这些问题不是纯粹的技术问题，有待市场来检验。但 Web 2.0 时代用户是重要的资源，如果将用户系统拱手交出，全线采纳 Identity 2.0，或许是一些既得利益者不愿意看到的。即使对于普通用户，像单点登录、一卡走天下这样的特性真的是大众的需求吗？也许更细的授权粒度、站点独立的密码设置才能让一部分人放下心来。
　　我们不能过早地断言 Identity 2.0 会走向失败。也可能是早期定义的 Identity 2.0 过于激进，我们来看看 OpenID 现在的发展：在多数网站中没有完全取代传统的身份认证机制，而是作为它们的补充；通过底层的服务发现协议来和 LID、i-name 等兼容（最近 Windows Live ID 也要和 OpenID 兼容了），力图建立统一且开放的 Identity 2.0 平台。这种渐近式的、开放包容的路线，应该是 Identity 2.0 的生路所在。

　　最近做了一些和用户管理系统相关的调研，了解到“Identity 2.0”这个概念。Identity 2.0 的提法大约是 2005、2006 年间诞生的，是对一类以用户为中心、支持跨域的身份认证机制的泛称。Identity 2.0 旨在替代现行网络系统上常用的用户名-密码验证机制，以解决用户名-密码机制的以下缺点：
　　1. 键盘敲击用户名-密码有被恶意软件记录的危险；
　　2. 很多设计不周的网站使用 http 协议直接明文传输密码；
　　3. 钓鱼网站的威胁；
　　4. 用户在不同网站上重复填写注册信息、记忆和管理密码的负担较重；
　　5. 不能实现跨域的单点登录。
　　OpenID 可能是目前 Identity 2.0 中影响力最大的一个，我也算是在 OpenID 刚推出之后就使用的用户。它最初是由 LiveJournal 等公司发起的开放技术，允许任何人建立用户管理和认证节点（OpenID provider），用户可以在上面注册一个形同 URL 的 OpenID，此 OpenID 事实上仍要对应 OpenID provider 上的一组用户名-密码。在支持 OpenID 的网站上，用户只需使用自己的 OpenID 登录。该网站通过访问 OpenID URL 找到 OpenID provider，如果用户已成功登录 OpenID provider（或在本地保存了有效的 Cookie），则 OpenID provider 向目标网站返回用户身份信息；否则重定向到 OpenID provider 的登录界面，要求输入用户名-密码以验证用户对 OpenID 合法拥有。OpenID 没有解决上述缺点1，但如果支持 OpenID 的网站多起来了，则可以大幅减少密码输入次数；OpenID provider 通过使用 https 及密码摘要可以解决缺点2；用户只要记清楚 OpenID provider 的域名，不在 OpenID provider 以外输入用户名-密码，可以在一定程度上降低钓鱼网站（缺点3）的威胁（但钓鱼网站仍可以伪装成目标网站来欺骗用户，获取 OpenID provider 中的非敏感信息，只是得不到密码）；缺点4在 OpenID 中不存在，但需要权衡的是在 OpenID 中保存多少个人信息，毕竟我们对不同目标网站的信任度是不同的；而解决了缺点5正是 OpenID 的最大亮点。OpenID 带来的新问题是单点失效。虽然网上有很多 OpenID provider，但一个 OpenID 只保存在一个 OpenID provider 中，只要这个服务器失效了，上面所有的用户就无法登录任何基于其验证身份的网站了。解决这个问题的方法之一是使用 OpenID 的 Delegation 机制，通过另一个相对安全稳定的 URL（称为“Delegating OpenID”，位于普通的 web 服务器上即可）指向 OpenID URL。一旦原来的 OpenID provider 失效，可以在另一个 OpenID provider 上注册新用户，并将原有的 Delegating OpenID 指向新 OpenID。这时凡使用 Delegating OpenID 注册的网站账户登录不受影响。但从本质上说，保存 Delegating OpenID 的 web 服务器仍有单点失效的危险，用户最好能自己控制 Delegating OpenID 的域名，以方便在 web 服务器失效时快速迁移。但这对于大众用户来说又是不现实的。
　　目前 OpenID Directory 收录的支持 OpenID 登录的网站有 800 多个，其中不乏 Blogger、SourceForge 等知名网站。但相当多的网站没有把 OpenID 作为自己唯一的、主推的登录方式，很多网站只使用 OpenID 的登录认证功能，而自己独立管理用户个人信息。不少网站只把 OpenID 作为一个别名，绑定到已有的用户名-密码之上。还有部分网站的 OpenID 用户只能使用有限的功能（例如只能给 Blog 留言，不能建立自己的 Blog），不是一个完整的账号。真正把 OpenID 作为唯一入口的网站并不多，CopyTaste 是一个例子；Twitterfeed 以前也是，不过现在支持（并且主推的是）用户名-密码登录方式。造成这种现状很可能是因为 OpenID 的可靠性问题（单点失效）没有得到有效的解决。此外，开放的 OpenID provider 市场难免鱼目混珠，也使一些网站经营者对其望而却步，毕竟网站经营者要对自己的用户数据负责。抛开这些，仅仅从技术角度说，OpenID 为了开发和使用的灵活，在使用模式上没有太多的规矩，但这反而可能使开发人员对其误用，造成包括数据不一致在内的诸多问题。我就在 Twitterfeed 上遇到过这样的问题（与使用 Delegating OpenID 有关），好在它的开发者 Mario Menti 热心地帮我直接修改数据库得以解决。我还因为同时使用具有相同 Email 的普通账户和 OpenID 账户，在基于 Moodle 的 Impact English 中丢失了学习记录，最终也是请教师在后台查证的。
　　对传统 OpenID 的安全性进行小幅改进的是 VeriSign Labs 推出的 Personal Identity Portal (PIP)，它可以使用数字证书、电子口令牌或手机动态口令等方式对 OpenID 的登录进行二次验证。这使得 OpenID 的密码即使被他人窃取，也无法在别的电脑上轻易登录。除安全型 OpenID 之外，PIP 还提供密码托管服务，将其它网站的密码保存在 PIP 上，用户只要成功登录了 PIP 就可以免输密码直接登录那些网站。这种服务严格地说不算是 Identity 2.0，但确实不失为一种不用修改目标网站（或只要求其增加少量安全的 REST API）即可实现跨域单点登录的模型。密码托管可以防止钓鱼和键盘记录，并尽可能地帮用户选择 https 登录通道。国内也有像豌豆网、PassBox 这样的密码托管服务提供商，然而这种使用模式的缺点显而易见：任凭服务商宣称其技术和管理上如何安全，也难以说服用户放心地把密码保存在第三方的服务器。有恶意的服务商完全有能力借此窃取用户的密码，这时服务商本身变成了一个钓鱼网站。此外值得一提的、和 Identity 2.0 关系不大但有可能成为另外一条思路的是同 PIP 紧密结合的 VeriSign Identity Protection (VIP) 服务，用户可以申请电子口令牌（收费）或安装手机动态口令软件（免费），作为登录支持 VIP 的网站的二次验证凭据，这很像国内一些银行所采用的动态口令牌。VIP 和 OpenID 一样，也需要目标网站的支持，目前支持它的多为美国的消费类网站，其中 PayPal、eBay 等对中国用户可能也有实用意义。如果 VeriSign 能将 PIP 和 VIP 开放标准，或许可以推动 OpenID 标准的进步和市场的开拓。

　　同样基于 URL 的身份认证机制还有 LID (Light-Weight Identity)。OpenID 和 LID 的发起者很早便意识到不同机制间互操作的重要性，因此他们共同制定了 Yadis 服务发现协议，使得二者在一定程度支持互操作。目前 LID 的影响力不如 OpenID，MyLID 可能是唯一一家正式运营的 LID provider。当然 LID 也是开源的，允许任何人建立自己的 provider。
　　和 OpenID 机制类似的是微软的 Windows Live ID，也就是通常所说的 Hotmail 或 MSN 账号。除了是由微软独家提供身份认证服务器并使用 Email 作为用户名称，其工作原理和特性与 OpenID 大同小异。尽管微软提供了比 OpenID 更加易用的 SDK，但是 Windows Live ID 目前只在微软的各种网站，如 Imagine Cup、微软学生中心上普遍使用，第三方网站使用得很少，也许是对微软这个巨头及其垄断的标准怀有戒心。一家 OpenID provider 倒了可以换另一家，但如果微软对 Windows Live ID 撒手，使用它的第三方网站和用户都会遭殃。此外，反对者还认为使用 Email 作为用户名称更容易招致垃圾邮件。