Conor Cahill picked up on a discussion I recently relayed to identityblog readers – part of an ongoing dialog between Brett McDowell and Dick Hardt. Conor says:
I think the issue causing the disagreements here is the interpretation of the term “federation” when discussed in an identity context.
Certainly federation can mean groups of businesses working together and this is the traditional meaning of the term in the business community. This meaning would fit with Kim's statement above.
However, in an identity context (as in “identity federation” — the stuff the Liberty Alliance has been working on since its founding) the term federation was used to describe the sharing of identity information from party A to party B. Party A is usually some party representing the user (acting on the user's behalf) such as an Identity Provider or an Attribute Provider. There is nothing that says whether Party A is an entity operated by the user or by some 3rd party.
In fact, in the Cardspace solution, the process of sending data through an Infocard instance to a relying party would be considered taking place under identity federation, whether the infocard instance was rooted in a local data source or a remote data source.
Ultimately, I would say that federation can be used in both user centric and non-user centric solutions. Federation is a technology/protocol and user centric is an implementation philosophy. When designing a user centric solution, you almost always have to include some form of identity federation, but give the user great control over its use. The converse is not required to be true (although I wouldn't object to it if it was true in any environments in which I played).
I like a lot of Conor's thinking. I agree that use of a managed card in Cardspace should be considered a form of “federation” between the relying party and the identity provider – federation approved by the user.
But I don't quite buy that “federation is a technology/protocol” wherease “user-centric is an implementation philosophy”. I doesn't compute given a great deal of work I've been doing lately.
It's clear to me that good “user-centric” experience isn't just an automatic or natural by-product of some other “technology/protocol”. In fact, it requires just as much study, just as much thought, just as much coding, and just as much experimentation as protocols do – probably more.
What I'm try to say here is that it requires technology. In the past we've had a lot of technology that failed miserably at organizing, integrating and rationalizing the user's experience. I've been working on software that I think does a lot better job at this. Why wouldn't Conor call that a technology?
To my way of thinking, you have two more or less orthogonal technology efforts – that oriented around federation issues, and that oriented around the user's experience.
As a user, when I go from portal to portal to portal, it's likely they will have relationships with different identity providers. Should my experience therefore be totally discontinuous as I move from one portal to another, being organized by the portal rather than by my own system?
In Cardspace (and with Information Cards running on other devices and platforms) we postulate that the user can benefit from computerization of his or her own identity experience – just as enterprises benefit from computerization of theirs.
Through Information Cards users can benefit, to the extent the technology is adopted, from the same well-understood experience as they move between unrelated portals which do not share identity relationships.
I see Cardspace as providing a palette of identity relationships (Information Cards) that work for me as a user and make sense from my point of view as an individual with a complicated life.
I think Dick Hardt, and others like Paul Trevithick at Higgins, share a number of the same notions as I do, though each of us is concentrating on different aspects of the problem.
So that's why I'm saying that there are two legitimate technology areas, orthogonal in the sense that you can have either one without the other, but synergistic in that together you get a number of critical new scenarios.
To make this more concrete, my next post will be a demo of Andre Durand and Ashish Jain's work in showing how this can look in practice.
