What I would propose is an open protocol and personal information management paradigm that circumvents the need for any type of corporation centered service to operate - similar to RSS and falling short of the complexities it would take to implement OpenID based solutions. RSS is a "Protocol Oriented Architecture" and has demonstrated its continuing success over the years - it is not a methodology centered around a company - nor is it necessarily solely centered around SOA (at least in the depraved corporate buzz word sense which has been so rampantly abused in recent times) - rather its centered around the fact that it remains malleable for many use-cases beyond the protocol's initial application to news. Likewise - I would propose to create an open identity protocol without all the complexities of OpenID. I was thinking if everyone had an email address - then the provider of the email address could be their authorization provider.
- User signs up at a provider (e.g. gmail - email providers would be ideal)
- User sets up contact information distribution settings
- Public Contact Information - contact-info - User sets up password or public access
In the password protected model, the user would provide the password to the requester so that the requester would be able to access the information.
- Private Account Information account-info - User sets up password
Benefits of a Protocol through Any Provider Paradigm
By releasing the protocol from the grip of a specific provider, you enable the user to be completely free to go with whatever provider maintains the best implementation of the protocol - its more democratic.
Migrations would be simple - as providing the highest authorization to the new provider to transfer all lower information dissemination tiers.
Service management made easy - User Oriented Services.
Since the end application would be communicating with the identity authorization provider , the provider would have a list of services for which the user is signed up. The user could pipe these services together within his provider's sandbox into new services in the style of. user:firstname.lastname@example.org - alternately (of course this would exactly work on the gmail platform - however might work where a provider also provides hosting for users) user.provider.com/?somemashup
What you could do with a User Centric Protocol Oriented Architecture
What if you were to route their current location service fed from their nextel phone available as a constantly updated JSON latitude longitude feed known as "jps" with a presentation service called "cartographer" which takes latitude and longitude and feeds them to yahoo, live, and google maps. user.provider.com/?jps>latitude,longitude>cartographer to get a current map of the user at any given point in time. The user would have registered their jps service through their user:email@example.com or along the same URL instead of Email paradigm user.provider.com/?account-info - and also registered for cartographer via the same method. Instead of going to cartographer's site or the jps site - the user could go to the mashup and pipe parameters explicitly through the piping service. ?jps>latitude,longitude>cartographer. Optionally, the presentation service could be available as a feed of image urls and could be piped through another service - like a service that pools images from a list of sources (cartographer and flickr) into a flash river animation. user.provider.com/?((jps>latitude,longitude>cartographer>map-url),(flickr>url-stream))>riverpool
Wouldn't that be cool? Wouldn't a protocol oriented internet be cooler - simpler and easier than a venture-capital Plaxo centered internet?