注意:WebID 方面的很多这些问题都在 Foaf+ssl FAQ 中得到了解答。
BrowserID 与 WebID:区别是真的吗?
BrowserId (detailed spec ) 是 Mozilla 实验室的一个实验,非常新,没有完全定义(例如,没有指定电子邮件服务器的公钥应该如何找到)并且没有完全实现(它需要真正的浏览器支持分散式)。WebId协议正在W3C 孵化器组中开发,建立在以前称为 foaf+ssl的协议之上。所以它也在进化。这两个协议都于2011 年 5 月在加利福尼亚州 Mozilla 办公室的浏览器研讨会上的 W3C Identity 上提出
此外,尚不清楚这两个项目是否不兼容——或者更确切地说,如果它们兼容,这只是一个语义问题。可以区分它们不同的两个维度:身份验证和序列化。
- 身份验证:证书签名验证(BrowserId)或主题公钥验证(WebId/foaf+ssl)
- 证书格式:证书的 JSON (BrowserId) 或 X509 (foaf+ssl) 格式
当前 BrowserId 已由该对(证书签名验证,JSON 证书)和 WebID/foaf+ssl 由该对(用户公钥验证,X509 证书)定义,如本电子邮件中所述
但是没有合乎逻辑的理由为什么一个人不能同时拥有其他两种组合:
- (证书签名验证,X509 证书) - 即使用 TLS 完成的 BrowserId 身份验证
- (用户公钥验证,JSON 证书) - 即使用 JSON 证书完成的 WebID 身份验证。
或者,也可以对每种证书类型同时使用两种策略。那就是可以先验证证书签名,然后如果需要还验证 WebID。这对于获取有关用户的更多信息(RESTful 属性交换)可能很有用,并且检查密钥是否未被撤销也可能很有用。
所以我们在这里要处理的问题实际上是:“纯”BrowserId 身份验证与“纯”WebID(也称为 foaf+ssl)身份验证相比有哪些优点和缺点。请记住这个答案的其余部分。
比较 Pure BrowserId 和 WebId/foaf+ssl
回答说明了 2011 年 7 月的情况。
泄露的密钥如何失效?
在 WebID 中,它们从“个人资料”页面中删除。一个好的用户界面将使这成为一键式的事情。用户在登录后会进入他的社交网络——可能是通过手机发送给他的一次性密钥——并删除被泄露的公钥,他可以通过名称、生成它的计算机或其他一些其他方式来识别它使事情容易记住的方式。
BrowserId 当前使用具有有效期的 JSON 证书,该协议当前希望将其限制为非常短的期限。|(JSON) 证书需要非常短暂的原因是因为当前 BrowserID 规范中的依赖方只能通过使用电子邮件提供商的公钥检查证书的签名来验证证书。证书的有效期越长,就越有可能出现问题——例如,用户的计算机可能被盗。
但是,如果 BrowserId 与 WebID 结合使用(即:JSON 证书包含一个 http(s) 主题名称),则可以使用更持久的密钥:依赖方可以通过检查用户的公共配置文件来验证密钥没有被泄露.
多设备浏览器支持如何工作?
WebID 和 BrowserId 都可以有多个公钥。
使用 WebID/foaf+ssl,每个公钥都会在个人资料页面中发布,如“4 分钟内创建和使用 WebId”视频中所示。每个设备/浏览器都可以为同一个 WebID 拥有自己的证书。通过验证证书中的公钥是否与 WebID 配置文件页面上发布的公钥之一匹配来完成用户身份验证。
一旦该部分集成到浏览器中,BrowserId 将把密钥保存在浏览器/操作系统钥匙串中。依赖方通过检查颁发者是否真的签署了证书来验证证书,而不是通过逐字节比较证书来验证证书。所以任何证书都可以使用,只要签名是真实的。
如果这些导致多个公钥,它们是如何链接的?
在 BrowserId 中,用户证书的公钥仅用于验证客户端在认证过程中是否拥有对应的私钥。没有链接正在进行。
使用 WebID,可以在个人资料页面上发布不同的公钥,并且可以将其链接到那里。其中一些密钥可以被描述为持久的,因此也用于签名和解密。
是否需要为每个消费者完成链接?
在纯 WebID 中,每个配置文件都需要发布每个公钥。配置文件可能只不过是该密钥的发布。
BrowserID 只需要电子邮件服务器发布其公钥。
当前浏览器的支持如何?
自 1998 年左右以来,所有桌面浏览器都支持 X509 证书选择。(除了 Chrome 的早期版本等少数例外)手机更加零散。维基页面
要让 BrowserId 以分散的方式工作,它需要浏览器支持。这是目前缺失的,但它有可能被部署,因为它得到了 Mozilla 实验室的支持。
用户界面是否容易被普通用户理解(包括创建、选择、从当前计算机撤销,以及身份的全局撤销)?
- 创作:这两者都是一键式的。使用 WebID X509 证书可以使用 html5 keygen 元素和 IE ActiveX 解决方法生成。用户只需点击一个大按钮 - 参见WebID 和浏览器视频或上面的“webId 创建和使用”之一。用户界面当然可以通过更好的网页设计师来改进。
- 选择:
- WebId:Selection 在 Chrome、Safari、Opera 和 IE 上非常出色,但很难看 - 尽管在 Firefox 中并非不可能使用。为什么他们不费心去解决这个问题是个谜。请投票支持错误 396441 - 改进 SSL 客户端身份验证 UI。可以做很多事情来改进 UI,但不完美的浏览器从未阻止有创造力的网络人创造性地使用它。
- BrowerId:选择可以由网站设计,尽管这可能会产生更多的安全风险,并且不会提供跨站点的一致身份验证 UI(因此可能存在物理风险)
- 从当前计算机吊销
- WebID:应该避免从当前计算机中删除 X509 证书,当然应该改进 UI。
- BrowserId:当前计算机的撤销尚未定义,因为它尚未实现。
- 全球撤销身份
- WebID:如果需要完全删除身份,这仅需要配置文件页面返回 HTTP 错误代码之一,或者如果配置文件移动,则返回 HTTP 重定向,或者旧身份和新身份之间的语义身份关系,或者只是如果证书被盗,则从配置文件中删除其中一个公钥。
- BrowserId 使用短期(基于 JSON)证书保护自己
是否有可以跟踪用户的集中式组织?
- WebID:可以完全去中心化。你可以把你的 WebId 放在你的 FreedomBox 上,你所有的朋友也可以。如果您信任该服务,您也可以将它放在某个匿名服务器上。
- BrowserId:当 JSON 证书存储与浏览器集成时 - 不再需要使用 browserid.org,那么每个电子邮件提供商都可以参与。由于 Freedom Boxes 也可以是电子邮件提供商,因此它们也可以是权威机构。
是否有可以跟踪用户的去中心化组织?
那会是什么样子的例子?
跟踪的详细程度如何?
依赖方使用 BrowserId 获取电子邮件提供商的公钥。提供者应该知道的是某个服务器发出了 GET 请求。这可能值得集成到 WebID 中。另一方面,依赖方最终会得到一个可能被滥用于垃圾邮件的电子邮件地址。
使用 WebID - 依赖方在配置文件页面上发出请求。这个请求可以通过代理甚至 ip-proxy 匿名完成。
消费者获得正确实施的难易程度如何?
WebID over TLS 需要为依赖方设置更多内容,包括 SSL 服务器。该服务器不应该对客户端证书进行通常的身份验证。另一方面,它更安全,因为它强制使用 TLS。随着时间的推移,有很多 TLS 工具已经过测试,并且一直在测试中。
BrowserId 不需要依赖方上的 TLS,因此更容易设置。另一方面,如果未设置 TLS,则可能存在中间人攻击。
(但此时应该注意到,BrowserID和WebID不能同时使用新提议的JSON证书格式并结合它们的优势并没有什么深层次的原因。完全可以做BrowserId)
它在您无权安装软件的 Internet 终端上如何工作(假设您接受它被泄露的风险)?
互联网终端总是危险的。只有加密密钥才能使风险可接受。通过将密钥完全放置在硬件中,可以消除私钥被盗的风险。请参阅WebId 和 Crypto Stick。否则,如果必须使用 WebID 或 BrowserId,那么寿命非常短的密钥是一种损害限制解决方案。两种协议都可以使用短期密钥。
也许 OpenId 在这里结合手机传递的一次性密码会更好。