Recently I saw Mr. Messina's mocks for teaching the user what an OpenID is and how to get one or use an existing one. See http://www.flickr.com/photos/factoryjoe/3841182425/
I feel that this is still complicated for a regular end user. They just want to log in or signup for the new service as fast as possible.
The open id relying party should be able to just show the user their openids with the last one they used selected so the end user does not even have to bother typing anything if they don't want to.
I would like to propose a potential solution to this. When a provider creates an openid for a user they register it with an "OpenId Registrar". The OpenID registrar will cookie the user.
An OpenId Registrar keeps track of all the identities a user has. It will have APIs similar to the Social Graph Apis from Google. Given one OpenID from a given provider you can get the rest. This can also be supported via webfinger. Given an email address give me all the openids for the person. And with the help of the cookie it can say give me what openid provider I should present to this user.
So the way in which having an OpenID registrar would solve the NASCAR issue is that it will provide an API which returns the list of OpenIDs for the user on that browser and the last one used. Which means the registrar should also have an endpoint which can be invoked to store which provider was just used.
Fairly simple but should address end user confusion.
What do you think ?
Subscribe to:
Post Comments (Atom)
social coder
- Monica
- San Francisco, California, United States
- Open Web Standards Advocate
1 comment:
Hey Monica, two things.
First, my mockup isn't actually for signing in to a website. It's for helping people *realize* that they probably already have an OpenID and then provide them with a way to identify it (by logging in).
The goal of the design is to give people a sense for what's available, and if they don't know that they already have an OpenID, it seems like a decent idea to start by showing people the lists of brands that support OpenID.
As for the OpenID Registrar idea — that idea was proposed by Google to have a "Central Discovery Service" which would do exactly what you've described:
https://sites.google.com/site/oauthgoog/Home/pds/cds
While the idea has some merits, it is of course a centralization that would need to be managed in a way similar to DNS. That, frankly, scares me.
I think another approach would be to consider the browser's role in storing your IDP(s) for you — that way you as the user are in control — and if you're savvy enough about OpenID to know that you have one — you might be savvy enough to tell your browser what it is.
Of course all of these ideas suffer from lack of portability, but I think with the right approach, those issues can be overcome.
Post a Comment