User Consent in the Age of Attributes

An interesting, and often frustrating, conversation that takes place in the federated identity and authorization space revolves around obtaining the consent of the user, in real time, for attribute release and who exactly is responsible for doing so. Is it the responsibility of the Identity Provider (IdP) to get the consent and release only those attributes that are necessary for a transaction, or is it the responsibility of the Relying Party (RP) to notify the user as to its needs for attributes? And what is the role of the Attribute Provider (AP) which may very well be a separate entity from the IdP and the RP?

To begin, this conversation really needs to revolve around the needs of the consumer and what they are willing to provide to a service provider to obtain a service, and what the service provider needs from the consumer in order to fulfill that service. The following graphic depicts the various intersections of what an IdP/AP can provide and what an RP needs, with the sweet-spot being the upper right quadrant.

The challenge in the current state of affairs is that there is a distinct lack of visibility for the consumer at run-time/real-time in what is provided by the IdP/RP on their behalf and what is being asked for by the service provider to provide a service to them, which limits their ability to make an informed choice. Current implementations typically show one side or the other and often defer to protocol support to even offer that choice. To get to where we need to, the user experience in providing that visibility needs to remain consistently understandable across protocols, platforms and user interfaces.

I believe that what we need is something that sits “in the middle” of the IdP-AP-RP transaction troika and surfaces to the consumer information about them that is available and/or requested, and asks them to make explicit choices as to what they are willing to share about themselves in order to obtain a service. And since I don’t want to keep calling it “the-thing-in-the-middle”, I name it Attribute Chooser!

Given below is a UI mock-up of what the Attribute Chooser could look like:

Starting with top right quadrant, you can see that NAME, EMAIL, ADDRESS and MOBILE number are available from the IdP/AP. NAME and EMAIL are required by the RP in order to complete the transaction, but the decision to provide the ADDRESS and MOBILE number are up to the Consumer.

The top left quadrant lets the Consumer know that the IdP/RP is also providing information such as HOME PHONE, JOB TITLE and LIKES (a clear case of sharing far too much information and something the Consumer may want to tighten up if possible at the IdP/AP). But it is also made clear to the Consumer that this information is NOT requested or collected by the RP.

The bottom right quadrant notes two pieces of information, NIST LOA and EMPLOYER, that the RP would like to have but is not provided by the existing IdPs/APs.

It truly does not matter who implements this capability. It could be the IdP, the AP, the RP or even a third party service subscribed to by the consumer such as an Identity Oracle. What I do know is that, given that Privacy issues more are more are having real impact on bottom-line business results, we need something like this that allows us to operationalize Privacy.

RELATED INFO

• User consent in the age of attributes - Part 2
• Fair Information Practice Principles (FIPPs)