Friday, April 03, 2009

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. 


George Fletcher said...

In the OAuth/ProtectServ space I believe that authorization through "social relationships" will be filled by the Portable Contacts (PoCo) service. This service does combine both contact information and "social relationship" grouping but I think that is fairly familiar to users. What PoCo needs is "membership" queries so that I don't have to expose contact information to SPs where membership authorization is the only need.

Paul Madsen said...

George, makes sense. And as you say, PoCo needs to support a "Is Bob in the 'Family' group" as opposed to a "List me all members of 'Family' and I'll see if Bob is included" model.

This just the 'principle of minimal disclosure' applied to social identity (as well as an efficiency)