User Centricity of a relationship and protocol

This entry was written based on my existing unhappiness with user-centric identity definitions and some thoughts on the "user-centric identity" discussion that I read at [Eve Maler - Sun: R-E-S-P-E-C-T], Paul Madsen: A protocol for the people and Pete Rowley - People in the protocol
As I have said earlier , the user centric identity infrastructure must have three components i.e.

1. User having some level of control what they need to disclose to existing or new acknowledging entity [User-Ack]
2. User have some level of control on what information acknowledging entity can receive about them from 3rd entities. [3rd-Ack]
3. User have some level of control on what information acknowledging entity can give to 3rd entities [Ack-3rd]
4. User have some level of control on what 3rd entities do with the information that they recieve from acknowledging entities and other 3rd entities.[3rd-3rd]

Intent and Share Event
Now the control of the identity data can be done at intent or share event level. For example, any protocol or relationship before accepting the identity data would tell user it has intention to provide the information about the user at a later stage with other entities. Or the protocol or relationship could be designed so that it allows user to control the identity data transfer only at the point where it is needed by a identity data enabled protocol.
Control Level
The level of control itself can be classified as follows

• none - user is not in the loop when it comes to any of the attributes being shared in any relationships
• inform - user is just informed about the intent and/or event of data transfer between any two entities. Most of the websites privacy policies would probably fall into this category.
• monitor - user is able to monitor the intent and event of identity data sharing as it happens. This level is slightly different from the "inform" level. The "inform" happens only after the intent or event has occured. While monitor requires the acknowlegement of intent or share event by the user before it completes. Please note that in this case the protocol or relationship does not provide any recourse to identity entity/user to stop the event or intent. But at the same time the user may be able to stop the same by involving external agencies.
• Concent - user would be able to control whether the particular intent or event ever happens. This is where most of the brick and mortar companies would probably place their privacy policies.

Control Granularity
Now it is pretty clear that this is just one aspect of the user centric control system. Other aspect is the granularity of the control with regards to with whom data is being shared. For example, there has to be a way to differentiate two entity who may allow capability to control shared at everybody or nobody level vs per-entity level(like identity providers of future in the "identity 2.0" world).
The granularity can be classified as

• All - This is the most coarse grained control level where user can only tell whether all or nothing can be shared with other entities.
• Class - The sharing entity itself may classify its relationship with other entities in to various classes (like legal vehical, legal entities, affiliates, partners, marketing agencies) and would allow user to control the information at that level. Most of the brick and mortar companies (atleast my bank) privacy policy would probably fall into this category with regards to granularity.
• Entity - This would allow user to control the data share at legal entity level.

Data Granularity
Besides the granularity of the involved entity, there also need to be granularity with regards to data being shared such that,

• Identity - This would allow user to control whether all or none of the identity information available can be shared.
• Attribute - This would allow user to control the data share at the attribute level itself.

User Centricity
Now bringing these four things together i.e. intent/event, control level and control, data granularity allows us to classify a protocol's "user centric" level or user centricity (Sorry could not stop myself from inventing yet another term).

A user centricity would be defined as a combination of the control level and granularity with data granularity for the intent AND share event of a given protocol or relationship (may need to work on the sentence. Thoughts??)

This term is applicable to any identity data enabled protocol (i.e. a protocol that requires identity data to function). We should be able to define the user centricity of any identity data enabled protocol by the combination of control and granularity level for the intent and share event.
So for example the credit card application that I received today in my mail, did not have any information about intent of sharing (intent-none) but hopefully incase I form the relationship I would be allow be control share event by concenting for all my identity data with various classes of entity (share event-concent-class-identity). This would define the user centricity of the protocol between myself (identity entity) with my credit card company (acknowledging entity) i.e. [User-Ack] and the creditcard company with 3rd entity (i.e. [Ack-3rd]) as [intent-none,share event-concent-class-identity]. With regards to other protocols i.e. [3rd-Ack], if undefined then the user centricity of that protocol is [intent-none, share event-none].

I think that even though we have defined the user-centricity of the various identity data enabled protocols, there has to be an overall measurement of user-centricity of the relationship between myself and the creditcard company. I think just like with any other data security system, the user-centricity is as good as the weakest link. So this would probably put my relationship with credit card company as [intent-none, share event-none].

Thoughts?