Hmmm. In my mind, I prefer to interpret user-centric to mean the user has control. Control is what users care about. Conflating the idea of user-control with specific implementation or architecture is a mistake.
I mention this because a desktop-centric model such as Cardspace (an example of a user-agent) brings forward several problems:
- Sometimes desktops are shared (e.g. in manufacturing, service, or medical areas) and a single "windows" login does not match an identity. How would multiple doctors share the same desktop in an ER for example?
- Sometimes we users use multiple desktops at home, at work, and travelling. How do we stop the proliferation of personal information (e.g. InfoCards) and avoid leaving traces of ourselves?
- Sometimes we users are offline or not present during an information exchange. When an online retailer ships product, it happens when we are not present. Our personal information is shared with the shipper. How can we control the exchange of information when we do not have access to our normal desktop?
- Social networks and multi-party transactions create new challenges. What if my wife wants to look up my travel itinerary? Do I manage this dynamically, or pre-arrange this by policy (consent)? When you consider multi-party scenarios, the likelihood of one of more parties being away from their desktop or "offline" becomes problematic. I suspect this is why consent in social networks is most often handled by e-mail.
SAMLv2 and ID-WSF's more service-centric implementation of user-centricity is also an excellent design. The supported use-cases for user-control and relationship handling are very broad indeed. Finally, they depend little on a user-agent but still offer user-control. The thin user-agent has been both their key advantage, but also key disadvantage. Microsoft's work on Cardspace shows how important it can be when it comes to providing a strong visual interface that improves a user's understanding of information flow.
It seems that like life, no single implementation model of user-centricity will fits all use cases (at least nobody has proposed one yet). I'm not sure what a combined solution would look like. But I think this thread highlights why more of this type of conversation is needed at Project Concordia (an open effort to look at how we can have better interoperability across protocols).
Aside: It also occurs to me that smartcards are also a nice portable form of identity. The use of the card is under the control of the user. But are they a good implementation for user-centricity? The problem with smartcards is they are fixed in time and tend to be created for a single purpose. Is it appropriate to use a smartcard for reasons other than its intended purpose? If a card maps to a single-identity or set of assertions, then that may create problems with privacy. The beauty of SAMLv2 and Infocard systems is the potential for dynamic relationships that allow only specific information to be provided to each web site - kind of like having many many cards in your wallet. Smartcards are still an important format for credentials, but like driver's licenses and passports, I'm skeptical about the use of a smart card as a universal credential.