Wednesday, August 29, 2007

Preferences and Entitlements

So far I have thought about the Preferences and Entitlements as two separate notions that are not connected to each other. But today while thinking about a few things from work and some blog posts, I realized that there is more to the it than that meets the eye.
Before we go any further let's summarize the definition of terms for the purpose of this discussion


Preference is information that user makes available to resource / application to allow the resource /application to present information in a "user-friendly" manner. (I understand that this is very limited version of preference and there might be other better terms like Persona to describe the same concepts).

Entitlement Model (including model and data) is information that resource / application owner makes available to resource / application so that it can present information that user has access to.


Even though these definitions are not the standard, they are used here to drive the point of view that I am trying to explain. At some level we can view these two things as being about the same thing i.e. annotation of the user-resource mapping / relationship. There are a few implications that I could think of



  • Entitlement Modeling as preference source and vise versa - One of the various source for the user preferences that an application can have is Entitlement Model. For example [James McGovern - Relationships and Authorization] - In case the Insurance application has  modeled user's preferences (including relationships and their access levels /roles) in to its entitlement model, his preferences should be taken into account while determining the access for the user's son.

  • One way relationship (do we have a word for these things) - If we treat the relationships as preference (i.e. I prefer to call John Doe my friend even though he may prefer to consider me to be an acquaintance) and have a standard way to integrate preferences into entitlement model, relationships can be just another preference that is supported by the entitlement model. Please note that incase preferences are modeled as attributes, downgrading relationships to attributes is something that can come back to bite when there are specific requirements wrt relationships.

  • Provisioning - As discussed as part of entitlement and provisioning integration topic earlier, user's attributes for a given application can be based on the entitlement model the application enforces. Now one of the aspect of this is that some of the attributes /relationships being exported by entitlement model to provisioning model can be part of the self-service workflow to be managed as user preference.

  • Extending Social Graphs - The relationships and attributes that form part of the identity provider trove, can be further enriched by providing additional preferences or refine the scope of relationships based on resources. For example I can be friend of a person in the context of specific resource (say flickr) but an acquaintance in the context of other resource.


Thoughts?

No comments:

Post a Comment