Continuing my popular “people in” series of blogs I note that distinguishing between protocol and policy seems to be a hard thing to do. At least there appears to be a level of confusion between the two with regard to user-centric identity. This manifests when folk start talking about use cases that require access to identity data when the user is offline and not available to have the data flow through them. I recently replied to one example:

I think we are in danger of conflating architecture and policy. The point of the architecture is that the data flows through the user. User granted policy could be that data. The policy might include credentials that allow access to portions of the user data with other constraints attached such as time and usage limits. The policy will be observed by the IdP [Identity Provider]. The credentials will be owned by the RP [Relying Party]. Both will have passed through and been approved by the user and therefore are “user-centric.”

User-centric identity has a large slice of online user created policy implicit in the architecture, but it does not preclude persistent policy decisions, including decisions that result in data flows around rather than through the user. The key is that the policy was created by the user and granted by the user, and incidentally should be revokable by the user.

Next week, people in the teleconference.