林健的BLOG

　　OpenID 可以在网上免费申请，Information Card 可以在本地自行创建，但如果说有一种 Identity 2.0 的用户身份需要付费注册，你还会使用吗？这就是 i-name。
　　严格地说，i-name 不是一种身份认证技术，而是一种通用的网络资源命名机制。i-name 的缘由要从 OASIS (Organization for the Advancement of Structured Information Standards) 相关工作组制定的 XRI (Extensible Resource Identifier) 说起。XRI 旨在建立一种兼容并扩展 URI 的资源抽象标识符体系，提供统一的，与管理域、位置、应用和传输无关性的标识符。它使用若干符号来标识语义：
　　● “=”：个人，例如“=Mary”代表 Mary；
　　● “@”：组织，例如“@ABC.Company”代表 ABC Company；
　　● “+”：概念或主题，例如“=Mary/(+blog)”代表 Mary 的 blog；
　　● “*”：委托，即委托下一级 XRI 解析器操作，语义上类似于 DNS 中的子域，例如“@ABC.Company*HR”代表 ABC Company 的 HR 部门。
　　为了显式说明一个字符串是 XRI，常在前面加上协议标识“xri://”。
　　上面呈现的几个例子均是对人类友好的、可读的 XRI 形式，这种 XRI 名字称为“i-name”或“可重新赋值的（reassignable）XRI”。此外还有一种以“!”后接点分十六进制标识的、用于机器读取的“i-number”或“持久的（persistent）XRI”，形如“@!7F6F.F50.A4E4.1133”。i-name 和 i-number 相当于架设在 DNS 和 TCP/IP 之上的全局资源命名层，其中 i-number 唯一并永久地标识了特定的网络资源，而 i-name 提供了一种易于记忆的、相对稳定的资源名称。正如 URI 常常指向相应的 HTML 文档，XRI 指向的是机器可读的 XML 数据，这种数据的规范是 XDI (XRI Data Interchange)，它包括了资源的标识、描述、连接、同步等信息（参见 XRI 与 XDI 体系结构图）。与 DNS 系统的运作类似，XRI 体系也有分布式的名字服务器，也需要在客户端使用解析器来定位资源。同样有像域名注册商一样的机构（称为“i-broker”）负责 XRI 名字的注册和管理。注册时通常一并提供 i-name 及其对应的 i-number，用户可以自行改变 i-name 到 i-number 的映射，就像修改 DNS 的 A 记录一样。
　　XRI 还没有形成大气候，它甚至在 OASIS 内部的投票中失败，尚未成为 OASIS 标准，更不用说得到 W3C 的认可。名字服务器的稀少使它还未能充分体现分布式系统的可靠性和高效性；客户端软件与库普遍不支持“xri://”解析，这也限制了 XRI 的应用。不过 XRI 引入了代理（proxy）机制，可以通过 HTTP 访问 XRI。官方提供的“http://xri.net/”代理使得用户通过“http://xri.net/=Mary”就可以访问“xri://=Mary”（下文中的 XRI 均使用代理链接）。目前运营的 i-broker 有 1id、fullXRI 等，它们模拟域名注册商的经营模式，提供 XRI 名字（i-name 与 i-number）的注册和转移。“=”名字和“@”名字的年费分别是 $12 和 $55，作为一种全局资源，这种收费也看似有理有据。此外像 freeXRI 等网站也提供免费的、含“*”的委托名字注册，相当于 DNS 中的免费二级域名。我注册了“http://xri.net/=web*linjian”用于测试。
　　介绍完 XRI，我们再回到作为 Identity 2.0 技术的 i-name。XRI 引入“=”名字的目的就是要将用户作为一种资源，将其接入互联网。i-name 为用户提供多种与个人身份密切绑定的服务（称为“i-service”）。这些服务包括：
　　● OpenID 认证服务。i-name 虽然不是基于 URL 的用户名称，但底层同样使用了 Yadis 服务发现协议，因此和 OpenID、LID 具有互操作性。OpenID 协议 2.0 版本开始原生支持 i-name，理论上说拥有 i-name 即可登录所有使用 OpenID 2.0 或更新版本进行认证的网站。但这也取决于网站程序本身有没有限制非 URL 形式的 OpenID，例如 twitterfeed 虽然可以通过 i-name 的身份认证，却会在登录网站之后报错。从实现上看，i-name 也是通过密码来验证用户对其的合法拥有，因此 i-name 相对于传统用户认证方式的优缺点和 OpenID 是基本一致的。尽管 XRI 和 DNS 一样具备分布式特性，但可靠和高效的优势只在资源名称查找方面有所体现，而身份验证仍需要在注册该 i-name 的 i-broker 服务器上进行，存在单点失效隐患。
　　● 联系服务。相当于对个人私密联系方式（如 Email、Skype）的封装。通过在 i-name 后面追加“+contact”等标识，对访问者提供相应的 web 界面，使之能够与 i-name 的所有者通信，避免暴露 Email 地址等个人私密联系方式，同时有助于防范垃圾信息。例如可以通过“http://xri.net/=web*linjian/(+contact)”给我发邮件。
　　● 转发服务。同样是在 i-name 后面追加特定的“+”标识，以便跳转到该 i-name 所有者事先指定的页面，例如“http://xri.net/=web*linjian/(+www)”、“http://xri.net/=web*linjian/(+blog)”分别指向我的网站与 blog。
　　另外 i-name 还提供 SAML 认证服务、位置服务等。除了身份认证服务，其它服务在“http://xri.net/”代理的封装下失去了 XRI 的特异性，变得和访问一般网页无异。

　　作为与环境无关的、持久的网络资源命名机制，XRI 是一项有意义的探索。目前 XRI 仍处于实验演化和向标准迈进的阶段，产业界的支持与否很大程度上可以决定其生死。作为个人身份标识的 i-name 似乎是 XRI 面向市场宣传的唯一“杀手级应用”，有点喧宾夺主。但从原理上说，Yadis 协议已经使得此类技术趋同，i-name 宣称的终身性、持久性优势紧密依赖于 XRI 的存亡。相比之下域名系统已经稳定运行了数十年，技术和市场早已成熟，保守的用户也许会选择用更少的开销维护一个自己的域名来保证 OpenID 或 LID 的持久性。但我们也不能忽视 XRI 成功的可能性，说不准现阶段就是投资抢注 i-name 的大好时机。

　
　　提示性阅读：
　　● 写作计划缘起
　　● 我的意外加入
　　● 部分故事连载
　　● 我的一点剧透 [1] [2] [3]
　
　　一个偶然的机会，我加入了《我是一只 IT 小小鸟》这本书的写作计划。在访谈名录初稿中，我看到了刘未鹏、徐宥等在博客圈子里熟知的名字，而周筠老师选择让我加入令我既感欣喜又觉得责任不小。在写作个人经历的同时，我也不断阅读其他作者的文稿，每个人独特的生活、学习、工作经历及其心路历程都反映着平凡人的不平凡之处，对部分文字产生共鸣的同时我也不禁感到一番压力。相比之下，直到目前我的发展轨迹是平坦而幸运的，不过我至少不失一些代表性：一是从西部地区出来的学生，二是选择走上科研道路的人。作为本身资历也不深的作者，我们难免会出现孟岩先生所说的“本能地‘撒谎’”的问题，这也就期望读者能够用慧眼看出语言的用意，而不要过于追究历史细节。希望这本书能够给刚刚踏入 IT 相关专业的师弟师妹，或是有意愿走进这个圈子的朋友带来一些帮助。
　
　　外传一：有人问我前几天的 IM 签名为什么是“新长征路上的摇滚”，答案是这四句歌词似乎能代表我文章中的部分思路：

　　听说过，没见过，两万五千里
　　有的说，没的做，怎知不容易
　　埋着头，向前走，寻找我自己
　　走过来，走过去，没有根据地

　
　　外传二：表妹很快就要来北京上学了。准备先送她两本书，这本是其中之一；另一本很多人可能猜到了，是李笑来老师的《把时间当作朋友》。期待传说中的胖兔子插画版，呵呵。

　　为纪念中国人民抗日战争胜利 64 周年，我与 Jeep、m100 同学自行组织了参观冀中抗日根据地之一的霸州市一日游活动。
　　我们上午乘坐 1487 次列车从北京出发，不到一个小时顺利抵达霸州市。本次活动原定的主要参观对象是霸州博物馆，该博物馆包括霸州历史、文化、瓷器、书画等多个展馆，以及著名的中国自行车博物馆。然而不巧的是博物馆自昨日起调试空调和消防等设施（从现场施工人员来看似乎不像是“被调试”），故临时闭馆。我们之前没有在网上看到相关通知，所以不幸扑了空。

　　不过在 m100 同学的提议下，我们发扬“二战特种兵”的革命乐观主义和探索实践精神，通过观察博物馆四周情况，混入施工人员，避开保安视野，成功地从后门进入。博物馆大厅中矗立着代表霸州文化的霸台模型。一层是历史展馆，虽然没有照明，我还是借着相机闪光灯捕捉了部分展品和展板画面，它们反映了从义和团运动到抗战胜利前后霸州人民的英勇革命斗争历程。由于通往上层的楼梯在保安视野范围之内，我们未能继续上行。保安对我们的热情表示理解，但向我们解释了其工作原则。我们对保安在双休日坚守岗位、坚持原则的精神表示赞许，并在友好的气氛中离开了博物馆。



　　其后，我们还参观了霸州街景，了解了霸州市政建设情况。Jeep 同学对霸州火车站前的北京公交集团八方达客运公司驻地及站牌表现出极大的兴趣。在参观结束并品尝了当地美食之后，我们乘坐北京公交 943 路长途汽车返回了北京。

　　（有关本次活动的更多图片可以查看这里）

　　在 Identity 2.0 技术族中，Information Card（信息卡）算是 2006 年左右炒作得比较多，然而目前发展却不尽如人意的一支。当时微软把 Windows CardSpace——即它的 Information Card 套件同 WCF、WPF、WF 并列，作为 .NET Framework 3.0 的四大新兴组件来宣传。然而仅从现在的技术图书市场就可以看到：W*F 相关书籍在 .Net 书架上大行其道，而有关 Windows CardSpace 的书籍则是凤毛麟角。细心的 Windows 用户常常会疑惑：新版系统的控制面板中为什么会有一个似乎是制作名片用的 Windows CardSpace 工具？一般用户很少知道微软当年“Codename InfoCard”的雄心。

　　事实上，Information Card 不是微软一家独推的身份认证技术，它还得到了 Intel、Google、Novell、Oracle、Paypal 等公司的支持，并由这些公司共同组建了非盈利的 Information Card Foundation (ICF) 来推进这一技术。和 OpenID 一样，Information Card 也开放标准，没有中心节点，允许任何人按照标准独立实现和构建 Identity Provider 以及基于 Information Card 认证的网络应用，甚至允许用户使用相应的软件在本地自行创建个人 Information Card。Information Card 的工作模型源于生活中的实体证件认证机制：Identity Provider 是按照一定的规则给用户颁发 Information Card，并可以管理和验证自己颁发的 Information Card 的机构，相当于颁发驾照的交管部门或发行信用卡的银行；Identity Selector 是帮助用户保存和管理自己的 Information Card 的本地软件或网络应用，相当于钱包或保险柜；很多 Identity Selector 也兼具创建个人 Information Card 的功能，相当于名片印刷设备。对其工作机制的一个简单比喻是：用户自行制作数字名片，或在发证机关办理数字卡片或证件；平时把自己的数字名片、卡片或证件放在虚拟的钱包或保险柜中；在需要向目标网站证明自己身份的时候，打开钱包或输入保险柜密码，出示相关名片、卡片或证件（事实上只是它们部分“页面”的“复印件”）；目标网站获取其中的非敏感信息，有时还需要向发证机关求证一下卡片或证件的真伪；通过验证之后目标网站即可为用户提供相应的服务。
　　上文所谓的“名片”即个人（Personal）Information Card，这是 Information Card 最常见的一种形式。个人 Information Card 包含用户的非敏感信息，及其创建时间、创建软件和唯一的 ID 等。在发送给目标站点进行身份认证时，只有用户的非敏感信息被传送，因此不存在前文所述的缺点1、2。由于目标网站没有拿到 Information Card 上的 ID 等重要信息，所以它们无法伪造一个与原 Information Card 完全相同的复本来登录原用户注册过的其它网站。在登录时，一个根据协议生成的、不可修改的 Site-Specific Card ID 会发送给目标站点，它唯一表示了特定 Information Card 与特定目标站点的认证关联。Site-Specific Card ID 配合安全协议，具有双向认证特性，可以防止恶意用户伪造他人 Information Card 或钓鱼站点欺骗用户登录（缺点3）。缺点4和缺点5的克服与 OpenID 类似。而个人 Information Card 优于 OpenID 的，是它不存在单点失效问题——因为个人 Information Card 根本用不到 Identity Provider。个人 Information Card 的薄弱环节存在于 Identity Selector，不同的 Identity Selector 可以实现不同的 Information Card 管理和使用授权策略。例如 Windows CardSpace 使用 PIN 码验证本地用户对 Information Card 合法拥有，由于 PIN 码验证完全在本机进行，因此没有网络传输的危险；Windows CardSpace 也不允许导出非加密的 Information Card 文件，因此只要 Windows CardSpace 软件机制没有被破解，设置过 PIN 的 Information Card 是不能从本机或网络轻易窃取的——当然还有一个大前提是用户不滥用 Administrator 权限，否则“C:\Users\[Username]\AppData\Local\Microsoft\CardSpace”目录还是有被盗取的危险。而另一家知名的 Identity Selector——Azigo 则提供支持多平台的、本地与在线相结合的 Information Card 存储，其信任模型类似于密码托管服务。
　　而上文所谓的“卡片或证件”的学名则是托管（Managed）Information Card，它的主要功能不是验证用户身份和传递用户信息，而是用以证明用户具有某种资质（例如成年用户具有在购物网站购买酒精饮料的资质；持有特定信用卡的用户具有在银行网站使用贵宾服务的资质）。Identity Provider 通过额外的手段审查用户具有某种资质之后，在服务器端生成相应记录，并颁发给用户具有特定字段的托管 Information Card。托管 Information Card 本质上只是一个 XML 格式的、指向 Identity Provider 中相应记录的“指针”文件，它也可以像个人 Information Card 一样保存在 Identity Selector 中。当网站需要验证用户某种资质的时候，托管 Information Card 中的“指针”信息被传送给目标网站，目标网站再连接 Identity Provider 查证用户资质是否存在。托管 Information Card 同样可以克服传统用户名-密码机制的诸多缺点，然而单点失效的问题再一次显露。况且不同的 Identity Provider 提供的资质证明服务是异质的，它们与目标网站也通过证书认证等方式绑定，故不能像 Delegating OpenID 那样简单地找替代品绕过，这是托管 Information Card 有待解决的问题。另外，由于托管 Information Card 的“指针”文件容易复制和传播，为保证其安全，协议规定需要使用 X.509 证书、Kerberos ticket、个人 Information Card 或传统的用户名-密码等至少一种机制来验证用户对托管 Information Card 的合法拥有。这将托管 Information Card 的安全性问题划归到上述机制的安全性问题上了。
　　机制的灵活性使得创造其它类型的 Information Card 成为可能。但新的 Information Card 特性往往需要目标网站和 Identity Selector 的支持。例如 Azigo 支持的几种 Action Card 类似于现实中的商场会员卡、打折卡，启用之后可以和 Google、Yahoo 或一些购物网站交互，对使用本卡可打折的商品加以图标提示。
　　Information Card 已经发布多年了，但支持用它登录的网站依然很少，ICF 官方的资源目录中登记的站点屈指可数。微软的 Windows Live 的 Information Card 支持长期处于“Beta”阶段。具有讽刺意味的是专门提供 CardSpace ASP.NET 控件的 Quality Data 公司自己的网站还在使用用户名-密码登录。稍微有点意义的托管 Information Card 是 Equifax 提供的“Over 18 I-Card”成人验证。它通过查证用户的美国社会保险号码发给其代表成人身份的托管 Information Card，目前唯一的用途是在 Watch-This 网站观看 18+ 的视频。而那几家提供 Azigo Action Card 的网站也往往只把虚拟打折卡和实体打折卡绑定，没有让用户体验到 Information Card 的优势，反而是用一种复杂的机制实现了简单的会员折扣提醒功能。
　　Information Card 市场接受程度远不如 OpenID 的原因，我想很可能与其 Identity Selector 机制有关。Identity Selector 确实在一定程度上增强了安全性，但它不像 OpenID 只基于现有的 Web 机制，而需要在客户端部署依赖于操作系统、浏览器的组件。这使得用户感到不便乃至不安，网站运营者因此不会有太大的兴趣。我目前还没有找到在 Chrome 和 Opera 下好使的 Identity Selector。就连 Windows CardSpace 在 IE8 下工作得都有问题，像 SignOn 等网站只有使用 IE7 兼容模式才能登录。可以想像网站运营者如果添加 Information Card 认证，只能收到更多用户的询问或抱怨。Windows Vista 以后 Windows CardSpace 以成为了系统标配，但微软这种把标准协议绑定到 IE 上的行为反而可能引起某些第三方开发者的不满，正如 Mono 常常被一些“纯粹”的自由软件人士抵制一样。
　　和 Information Card 思路类似的是 IBM、Novell 等公司发起的 Higgins 开源项目，它提供给用户的“名片”称为 I-Card，也借助客户端（或网络托管的）Selector 保存 I-Card（沿用 ICF 的部分工作）。并支持两种可替换的 Identity Services，其中一种“可信伙伴”服务可以将 Information Card 或 OpenID 认证方式接入 Higgins 框架。此外 Higgins 还引入了 Attribute Services，用于表述数据的上下文及实体（用户、目标网站）之间的关系，并提供访问控制支持（对用户来说，他们此时需要持有一种表示实体间关系 Relationship Card）。Higgins 仍是一个演进中的实验室项目，它提出的一系列认证模型和身份、关系管理机制值得在学术界研究，但目前阶段实用部署仍显复杂。对网站运营者和普通用户来说，额外组件的安装部署、既有应用的修改、新的使用模式和安全守则的学习都是不小的开销。“名片”模式要摆脱现在这种尴尬境地，任重而道远。

　　最近做了一些和用户管理系统相关的调研，了解到“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 作为用户名称更容易招致垃圾邮件。