Pete Rowley presents a nice pithy descriptor for user-centric identity - based on the idea that the prime (sole?) criteria for an identity flow to warrant the term is that it occur 'through' the user - and so Pete suggests 'people in the protocol'.Works for me. This is consistent with a taxonomy that some Liberty folks have been bandying about - as shown in the diagram.
The idea is that such user-mediated flows are a subset of a broader category in which the user will still have the ability to specify policy and preferences for how their identity is shared, but would not directly mediate any such sharing. Identity would flow by some other route than through the user, but still determined (at least partially) by the user's own policies. In the diagram, these deployments are labelled as "user-controlled" to capture this different level of control compared to the user-centric case.
Such user-controlled scenarios are themselves a subset of more general user-consented scenarios in which the user may not be given the option for specifying their own policies for how their identity is shared - enterprise use cases being an example. Although the user may not be in control, the assumption is that they have still been given the opportunity to give their consent, even if only through their signature on their employment contract.
Additionally:
- User-centric (as typified by the channel by which identity flows) enables but does not guarantee that the user have the final say on the sharing of their identity. I'm sure that enterprise deployments of Cardspace will support administrative policy that will override any preferences the employee user might have over what cards get presented to which RPs.
- Some identity architectures support only the user-centric flows, and do not allow for the user-controlled flows. But many important identity use cases have one of both subjects offline and thereby unavailable to act as a conduit for the flow of their identity. Does the world stop when I'm not sitting in front of a browser?
- User-centric flows are often described as decoupling the RP and the IDP, and thereby supporting cases where neither need 'know' the other beforehand - this leading to 'scale'. While true in principle, in practice there are lots of other factors pushing the two providers towards each other (such as the realities of risk management) that are independent of the specific channel by which the identity flows. So, if the nature of the shared identity or the value of the transaction doesn't require/imply that the two providers 'know' each other, then it can make sense to share identity through a provider-obfuscating user-centric flow. If not, then the value of the user-mediation is diminished.
No comments:
Post a Comment