One thing that has always amazed me is the lack of Identity online. There is not even a standardized phone book! A lot of it is due to the inherent problems with email, privacy and spam.
OpenID is a very promising approach but I can not understand why we have to introduce yet another identifier for people? Your personal email is already the de-facto identifier used on numerous websites. What is missing from the equation is a simple bridge between OpenId/OAuth and email. I imagine a simple REST API answering to requests by email or hased md5(email).
http://pubidhub.net/johan.sellstrom@gmail.com/{json,atom}
In return you would get the OpenId provider (if any) as well as a list of public feeds/service ids on various social networks, amazon, ebay or whatever. If an OpenId provider is present the requesting service simply invites to provider to the OAuth dance. If not, we would have to resort to traditional signup but at the same time offer to provide OpenId services. This way we would release the OpenId virus. What is interesting is that a lot can be facilitated by the fact that major identity providers such as Google, Yahoo etc are already OpenId providers and thus we can automagically deduct and assume a default OpenId URL from any *@gmail.com or *@yahoo.com address. The PubIDHub would cache such information until the identity owner takes control and updates the setting.
I am planning to build a simple PubIdHub service to use in the development of this project and hopefully it could evolve. To be totally honest I have not fully penetrated the proposed standards such as XRDS-Simple and OpenID Discovery but I only need something simple. In addition I will discover memberships and affiliations using my own little spider hack and I do not believe that is part of the scope for standardization? Please correct me as I am probably wrong.
The format used for the {json,xml} replies will of course be PortableContacts.
Update: I found this description from the Django Project
“A Consumer wishing to access a user’s data via Portable Contacts must start with an Initial Identifier for the Service Provider containing the user’s data, usually provided by the user. In many cases, this may be the domain name of the Service Provider’s web site, such as sample.site.org, but may be a more specific URL, such as the OpenID identifier of the user, if available. Consumers then perform Discovery on the Initial Identifier to determine where the Portable Contacts endpoint for this Service Provider resides. If successful, the Consumer may then attempt to request information from that endpoint. If the endpoint contains private data, the Service Provider will return an authorization challenge, and the Consumer must then guide the user through an appropriate authorization flow to obtain the credentials necessary to access this private data. Upon successful authorization, the Consumer may request data from the Portable Contacts endpoint using these authorization credentials. Whether accessing public or private data, Consumers may request a specific subset of the user’s data using standard Query Parameters. Upon a successful request, the data is returned in the response, and the Consumer may then parse the response data and use it as desired. ”
UPDATE: Duh, this is actually called web finger: http://code.google.com/p/webfinger/
