Provider Oriented Architecture vs. Protocol Oriented Architecture Vs. SOA

With all the recent buzz concerning the possible secret malicious and evil intentions of the contact management software Plaxo - I thought it was time to break in with some input on why I believe Plaxo is inherently evil - not in design, nor practice - but in concept. Plaxo is the living embodiment of a "Provider Oriented Architecture" where the benefits surround a single company or provider of a service as opposed to a protocol or actual paradigm of contact management methodology. Instead of converging adherence to a protocol or standard - if they had their way there would be ever increasing conversion rates throughout the market to their specific service.

The evil nature of Plaxo rests in its orientation and intention to draw the market into its domain by getting everyone to contribute to their user-contributed content base and eventually get everyone to use their service - which from a business sense would sound just and fair if only the end uses for this type of content were not so blatantly sick and perverted in concept. No one wishes to say it - but its gotta be said - Plaxo maintains personal contact information for all of its users - although its terms of use may say differently (they are also apt to change at any point in time) what other way is there to make money with thousands upon thousands of users' personal information? Its EVIL!

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.

1. User signs up at a provider (e.g. gmail - email providers would be ideal)
   
2. User sets up contact information distribution settings
   

• Public Contact Information - contact-info - User sets up password or public access

This would be for the same applications as plaxo - to get what information user@gmail.com has set up to be public - the information would be requested from "user:contact-info@gmail.com" in either a blank message or protocol formatted message specifying what fields are being requested regardless - only the information user has set to be public will be released.
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

For applications where you sign-up for many services - but don't want to fill out information again and again - you could set up multiple tiers for this type of authorization - some tiers releasing specific information - some tiers releasing modified protected information (such as a temporary email address for registration purposes only- integrated with the authorization / email service). The service being signed up for sends a request with the user provided password to "user:account-info@gmail.com".

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:mashup@provider.com - 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:account-info@provider.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?