Kim Cameroon responds and clarifies.
Kim had previously showed a Ping ID demo that he asserted nicely demonstrated how 'user-centric' and 'federated' were compatible but orthogonal.
I think the demo is undeniably cool and shows a perfectly valid use-case. What I question is Kim's claim that it displays some clear and fundamental distinction between user-centric and federated identity.
According to Kim, the user-centric piece of the demo (where the user authenticates to the portal with Cardspace) helps 'people get through their day' and the federated piece (in which the user is SSO'ed into various services) is 'tieing portals together'.
For the demo, this seems an accurate description. It is only when authenticating to the portal that the user appears to have any control over the release of their identity (by selecting and reviewing an Identity Card). Once signed-in to the portal, the demo suggests that the 'user-centric experience' is over, from here on the portal and the services decide what identity gets shared, and the user's ability to control this boils down to clicking on the relevant service 'Sign On' button or not. This piece of the demo doesn't appear very user-centric at all.
But of course the demo could well have shown the portal offering the user the same sort of fine-grained control over identity release to the various services - what gets shared needn't be a done deal between the portal and the services and out of the user's control.
Put another way, if user control over the sharing and use of their identity is the prime criteria for user-centricity (which I believe is the case), then there is no reason why user-centricity cannot extend into the identity exchanges between the portal and the services - the user can have meaningful control over these exchanges just as they did for the exchanges between their local IDP and the portal.
Hubert has another demo that shows "federation" technologies used in this manner.
I take the following from this thread (and another that Kim engaged in with Conor).
User-centric identity requires:
1) a philosophy of user-empowerment +
2) technology (protocols, UI, consent mechanisms, etc) in support of #1.
If an identity system has the first(who would claim anything less), but the technology can't back it up, then it's not user-centric. Conversely, technology (any) can always be applied in a non user-centric manner if not deployed in a manner consistent with the philosophy of empowerment.
2 comments:
You are right "there is no reason why user-centricity cannot extend into the identity exchanges between the portal and the services". There are definitely use cases e.g. Portal to 401k where user in the flow is very much desired.
The demo demonstrated
a) IdP to SP with user in the flow
b) IdP to SP without user in the flow.
And yes, it's only illustrated a subset of several permutations possible.....but I don't see where it implied that others aren't valid.
Some addional comments here:
http://itickr.com/index.php/?p=28
Hi Ashish, thanks for comment. I didn't mean to imply that the demo was biased, you had to choose what to show after all. My point is just that there is opportunity for confusion in using such a demo (which necessarily demonstrates only one permutation) to draw conclusions about the scope and applicability of the different pieces involved, and that's what I saw Kim doing.
paul
Post a Comment