> -----Original Message----- > From: Dan Brickley [mailto:[email protected]] > Sent: Wednesday, May 26, 2010 7:52 AM
> OK, let's look at what they have in common, if anything, from a user's > perspective. It seems to be yes to all these questions with some reservations. I can only guess for v.Next, but this is based on the charter. > Do both allow users to be identified via http: URIs such as > http://danbri.example.com/ ? The Connect proposal allows users to use anything that can be resolved into an authority as a hint. What the user types in or clicks doesn't matter much. Only the identifier coming back from the provider matters and that has to be an https:// URI. The identifier is explicitly not meant to be a nice, easy to remember URI - it is an internal identifier used by the client to uniquely identify the user. The fact that what the user provides is nothing more than a hint is a significant architectural change. I don't know how v.Next will address this, but this is a complicated matter which has significant usability implications. > Do both allow users to be identified via email-shaped URIs? > [email protected] (URI-ified as acct:[email protected] or similar) Connect already does, but it is still not clear if an 'acct:' URI is needed. If the canonical identifier has to be an https:// URI (which is still being discussed), then the email address entered by the user is just a hint, which means it can be expressed as a 'mailto:' URI (since it will not be the subject of an XRD document or be used in links). But there is still a proposal for using 'acct:' URIs as the canonical, so this isn't settled. > Do both allow users to based such URIs on domains they own/control, while > allowing the heavy-lifting to be done by implementations hosted/run by > (easily swappable - eg. homepage markup) external providers? Connect supports this in a restricted manner. You can either operate your own provider, or find a provider willing to assert your own domain (which today doesn't exist, and something I doubt any of the large providers will offer). It will only work if smaller providers decide this is a good way to make money. The proposal removed the identifier aliasing capability in OpenID 2.0 which never really worked right. I don't know what v.Next will support, but this is clearly something very important to those leading the effort. > Is there some consistent story that can be put together for users while 'the > marketplace' figures out the ugly under-the-cover details? If history has anything to say, then no. To me the core issue is the user experience when logging it, and that's still not solved for OpenID 2.0 after 3 years. And this was supposed to be the big priority for the foundation. It is not clear from the charter what v.Next will look like to the user. OAuth 2.0 supports 6 flows (and counting) customized to specific user experiences. Add to that the obvious input box and logo buttons, and the ability to use email addresses, and the variation in login experiences just gets bigger. In addition, since OAuth is inherently an API-specific protocol, any solution based on that gives a huge amount of autonomy to the provider to guide their developers on the best user experience. The only way the foundation can get developers aligned is by building a recognizable brand/logo and then restrict how it can be used using legal means. I don't see the foundation being successful doing that. I do see individual companies being successful (and many are). The connect proposal is optimized for two edge cases: a single provider (such as Facebook and Twitter, both using a flavor of the Connect proposal), and many providers with an "anything goes" approach - be as flexible as possible in accepting what the user provides. It is based on the assumption that building a coherent OpenID (or other) brand with logo that people see on sites and immediately recognize is not possible at this time, at least not by the communities involved. Figuring out the 'under-the-cover' details matters very little because discovery (including capabilities) is now at a pretty mature point. It might mean a bit more work for developers (client complexity in Connect is very low), but it is an easy engineering challenge. EHL _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
