OpenID 原则上是一个好主意,但是 UI 和关于它为什么好的解释目前还不是为一般用途量身定制的——您认为 OpenID 需要怎样才能为公众服务?这可以通过技术解决,还是问题本质上如此困难,以至于我们陷入了难以解释/多步骤注册程序、众多帐户或安全性差的困境?
21 回答
它需要更简单:涉及更少的概念知识,并且需要更少的步骤 - 最好是零。当这项技术在很少或没有帮助的情况下工作时,它就会起飞。
OpenID 凭证、提供者和供应商的机制不应该暴露给用户。人们谈论教育广大互联网用户,但这永远不会发生 - 群众永远不会停止愚蠢。如果你想吸引大众,你需要降低技术以达到他们的水平。当 Google 附属网站发现您已登录 Google 并默默地使用该帐户时,它就可以正常工作,而您无需告诉它您是谁。相比之下,OpenID 如此笨拙的事实是为什么像谷歌这样的大供应商仍在回避它,以及为什么公众不会采用它。
我认为 OpenID 的开发人员在使用 URL 而不是电子邮件地址作为 ID 时搞砸了。人们知道什么是电子邮件地址,他们已经拥有一个与他们相关联的地址(或者可以轻松获得一个),并且像谷歌和微软这样的电子邮件提供商很乐意扮演门户的角色。事实上,从电子邮件地址到 URL 的自动翻译就足够了:
myname@example.com -> http://www.example.com/openid/myname
我认为这将需要数百万人使用的网站的大量购买。例如,MySpace 即将支持 OpenID,所以现在 OpenID 支持的用户数量猛增。如果网络上更多的高活动站点遵循此引导,您就去吧!
它将采用所有支持它的流行网站,并使其对用户透明。
“您可以在这里创建一个用户帐户,或者如果您使用 MySpace、Google Mail、Hotmail 等,那么您可以使用 OpenID 登录。”
不要将其作为新服务出售,而是将其出售为能够使用与其他站点不同的 ID 登录。
然而,问题在于每个人都支持它,每个用户现在都将拥有一个 myspace id、google id 等。现在,如果他们使用 myspace id 登录到 stackoverflow,然后再使用 google,他们可能会感到困惑,stackoverflow 无法识别它们.
我想知道 openid 是否有链接 openid 帐户的解决方案,因此它们是相同的 - 我怀疑技术是否允许这样做,因为它们本质上是独立的签名机构。谷歌必须与 Myspace 共享数据,反之亦然,才能实现这一点……
ISP 应该向所有模仿其电子邮件地址的客户提供 openId。也许 openID 需要支持将 foo@example.com 自动转换为http://openid.example.com/foo以便 ISP 可以轻松地在单独的服务器上进行设置。
我认为它不会成为主流。我认为 Ted Dziuba 说得对,他说它解决了一个大多数人认为不值得解决的“问题”。
http://teddziuba.com/2008/09/openid-is-why-i-hate-the-inter.html
它必须变得简单得多,ID 更容易记住。
你的意思是现在还没有?;)
显然,许多当前流行的应用程序都需要提供它,并表明它是一个很好的选择。
如果谷歌和 Facebook 将其作为一个显而易见的选择,那将有所帮助。
最终,用户教育将真正发挥作用。我怀疑大多数人会在意……愚蠢的羊。
到目前为止,许多回应似乎归结为两种选择:
- 用户教育,以及
- 强制采用(许多网站从内部身份验证更改为 openid。)
这就是我们所能做的吗?让普通用户轻松进行 openid 委托的分布式工具怎么样?(比如说,与 OS X / Windows / Ubuntu 集成的东西)是否存在使这不可行的技术障碍?
如果客户端(和供应商发布的)应用程序可以让您管理您的在线安全偏好,那么我们可能能够应对与向随机站点提供密码相关的一些风险——因为“登录区域”将是一些本地程序位于您的系统托盘中,或者不是。当然,Web 应用程序与桌面的集成(例如 Chrome 提供的)在实践中可能无法进行这种区分,因此这可能是一个有争议的问题。
无论如何,看起来我们现在应该做些什么来让 openid 更受公众欢迎,并加快采用速度,同时让系统更加用户友好。
作为主要使用 Java 编写 Web 应用程序的人,我不能/不会使用 OpenID,因为没有库支持。 JOID和openid4java是我所知道的仅有的两个。JOID 显然没有得到积极维护,不包括几个月来一直在邮件列表中的真正重要的补丁;并且 openid4java 需要 >40 MB 的外部依赖项,包括一些需要进入认可的类路径的依赖项,正如一位用户评论的那样,这很荒谬:
2008 年 4 月 28 日,witichis 发表评论
46MB 下载,用于简单的重定向和解密/加密 - 你喝醉了吗?
在我看来,OpenID 还不错。它整合了登录凭据。它确实解决了一个实际问题,虽然它可能不是最佳解决方案 我能看到的唯一两个问题是,您必须信任身份提供者不允许其他人声称是您,以及依赖方(您登录的网站in to) 可以串通将您在多个站点上的身份链接在一起。
我个人认为它根本不需要成为主流,这是一个有趣的想法,但它不再相关。
当我创建一个正常登录时,我输入我的用户名、主密码并单击 SuperGenPass 小书签。就是这样,当我必须注册 stackoverflow 时,我必须找到一个 openId 提供商,在那里注册(这需要永远)登录我的网站并设置委托,然后将 stackoverflow 添加到我的网站列表中。
昨天我无法登录,因为我已经从我的虚拟主机中删除了该文件,并且他们遇到了一些安全问题。
结论:不要使用openid。
选择供应商需要简单得多。
目前没有办法知道它们中的任何一个有多可靠、值得信赖或安全,或者在 6 个月后仍然存在。
我认为我们需要看到更多面向消费者的网站作为登录方法提供 OpenID。有很多大型消费者网站可以用作 OpenID 提供者,但我记得在 Stackoverflow 之前看到 OpenID 可作为登录名的唯一地方是在 Blogger 上发表评论。成为提供者固然很棒,但消费者几乎看不到它。另一方面,查看使用 OpenID 的实际位置可能会引起更多兴趣。
如果更多的 OpenID 消费者也是 OpenID 提供者,那肯定会有所帮助。作为一名开发人员,我很乐意通过一些曲折来弄清楚我可以在 openid.org 上创建一个新 ID,但更主流的消费者很容易被这个过程推迟。
大网站接受 OpenID 的事实本身并不足以使其成为主流。到目前为止,我看到的最接近的是 LiveJournal 既接受又提供 OpenID 身份验证(我相信它已经做了很长一段时间了)。
但我认为仅仅接受 OpenID 是不够的。我们真正需要的是更多这样的网站,拒绝建立自己的认证系统,并要求OpenID 认证。如果“下一件大事”说您必须使用您的 OpenID 登录(通过一个非常简单的向导与其他人设置新 ID),我相信它会开始正常滚动。
如果我可以在每个站点上执行它并稍后根据我自己的时间和条件聚合身份,我会使用它。事实上,即使是找到一个像样的 OpenID 提供商也是一件非常痛苦的事情。体面的意思是stackoverflow.com不是一个,所以我不会打扰。
浏览器应该自动填充 OpenID 登录框,这样您就不必记住您的 ID。
Web 框架应将其作为默认设置,除非您花费大量额外时间来配置简单的用户名/密码组合。
使用 OpenID 的站点需要将其放在登录页面的前面和中心。我见过许多网站将其隐藏在标准登录/注册页面下的链接后面,如下所示:
用户名:
密码:
或使用您的 OpenID
我现在正在研究 OpenId 以集成到启动站点中,以便它可以管理我的站点的登录过程。
我认为要制作这个主流,他们需要让这个超级简单。将代码复制、粘贴到您的站点中,它会加载登录表单,为您提供 Stackoverflow.com 的功能。
我认为您也可以将表单的布局设计得更容易识别。
它不会成为主流,因为对于那些习惯使用电子邮件地址和密码的人来说,它太费力并且太混乱了。
例如:
要使用 Opera 登录到 stackoverflow,我必须单击登录,从列表中选择 myOpenID,输入我的用户名,按 Enter,按 Ctrl+Enter 在 myOpenID 站点上自动填充密码,然后按继续按钮。
要使用 Opera 登录任何普通站点,只需按 Ctrl+Enter 即可自动填充已保存的用户/密码组合。
Make it less open.
i do not want the same identity on multiple sites. i do not want to have to create a flickr account before StackOverflow will let me post. i do not have to have to create a new flickr account for each website that i want to register with.