Division of Roles

The ProtectServe proposal (I'd attribute it to Eve but I think she has been lionized enough recently) separates out the PDP (Policy Decision Provider) role from the PEP (Policy Enforcement Provider) role - this compared to default OAuth which collapses the two.

This made me think of a possibly useful way to look at different identity systems for permissions-based attribute sharing.

I posit that any given request for some user's identity attributes can have associated with it the following actors/roles

1) on behalf of which actor the request is being sent
2) which actor's identity attribute is being sought
3) which actor is sending the query
4) which actor holds the identity attribute (PEP)
5) which actor makes the authz decision (PDP)

ProtectServe distinguishes itself from default OAuth by introducing the Relationship/Authorization (which is it going to be) Manager. The SP holds the identity attributes, but the AM holds the corresponding authorization policy for the release of those attributes to specific Consumers. The AM provides a single policy management point for the User, hopefully simplifying for the User that burden.

Neither OAuth nor ProtectServe explicitly support 'social identity requests', i.e. a Consumer sends to an SP a request for Alice's attributes on behalf of Bob'. Liberty's SOAP Binding does allow this scenario, by allowing both Alice's and Bob's identities to be carried on a request. Bob would be the 'invoking identity' (ie that on whose behalf the request it sent) and Alice would be the 'target identity' (i.e. that that 'owns' the attribute).

In this scenario, the WSC sends a request on behalf of Bob to a WSP that carries some identity attribute of Alice's. The WSP looks at the policy that Alice has defined for her friend's abilities to access those attributes, and decides whether the request should be authorized.

Through the People Service, ID-WSF also allows the User to effectively separate out the above PDP role (probably more a PIP) from the WSP.

Instead of Alice defining her 'social authorization rules' at the WSP that holds her attributes, she can specify them in terms of a social structure maintained at her People Servicee, e.g. 'Allow any member of the group 'Family' to access my private calendar'. By so doing, Alice can leverage that same social structure for defining authorization at other WSPs, e.g. 'Allow any member of the group 'Family' to view my current location', etc.

Ultimately, I think User's need to be able to define authorization rules for their identity attributes in terms of both

1) the requesting actor (Consumer in OAuth/ProtectServe, WSC in ID-WSF)
2) an individual with some defined social relationship to themselves

ProtectServe's AM is designed to simplify for User's the definition and management of the first type of authz rules, Liberty's People Service the second.