Local Credentials and Life in the Federation Glass House

I’ve been a long time proponent of the value of identity federation. But when faced with a choice of using a federated credential or creating a local credential, in the vast majority of cases, I have chosen the latter. This blog post is an analysis of that behavior and its implications for (my) adoption of federated credentials.

Let me be clear that I use unique and complex passwords at each web site, do not reuse the passwords, and utilize a password manager for which I have turned on multi-factor authentication. Yet, in a majority of cases I am willing to assume the burden of creating a local credential when I have a choice of using a federated credential e.g. Login with facebook/Google+/Twitter etc. etc.

In doing a bit of reflection on my behavior and taking to heart that people in glass houses should not throw stones, I have realized that when it comes to federation there are two customer segments, end users and service providers (relying parties). Everyone else in the flow (CSPs, Attribute Providers etc.) are simply mechanical constructs that exist to support the interaction between these two customer segments. For a similar take on the subject, let me provide a pointer to work by Andrew Hughes that puts this within the context of a conceptual model of an identity ecosystem.

My support of identity federation has been shaped by what I see as the immense value proposition in utilizing strong federated credentials by Relying Parties (RPs). But when I am a potential customer of an RP, the value proposition to me is entirely influenced by getting satisfactory answers to the following questions:

1. What information is being sent by the CSP to the RP, and for what purpose?
2. Is the RP getting information about me beyond what is needed in order to create an account? If so, what?
3. Does the RP provide a reason for why they want additional information, and does that reason fit within the parameters of my business relationship with the RP?
4. Does the RP provide information on third parties with whom they share my information and the purpose for the sharing? Under what circumstances?
5. Am I uncomfortable with the CSP gaining visibility into which RPs I do business with?
6. Do I have any visibility and control over the personal information (direct, transactional, correlated, behavioral, location, “metadata”) the CSP has gathered in my interactions with this or other RPs?
7. Does the CSP provide information on third parties with whom they share my information and the purpose for the sharing? Under what circumstances?

To me these are the questions that I would need answers to in order for me to choose a federated credential over a local one.

One could make an argument that the implementation of a robust informed consent management capability as part of the transaction flow could address some of these concerns. I am not entirely sure about that and would point you to the paper by [Daniel Solove on “Privacy Self-Management and the Consent Dilemma”][2]:

There are too many entities collecting and using personal data to make it feasible for people to manage their privacy separately with each entity. Moreover, many privacy harms are the result of an aggregation of pieces of data over a period of time by different entities. It is virtually impossible for people to weigh the costs and benefits of revealing information or permitting its use or transfer without an understanding of the potential downstream uses, further limiting the effectiveness of the privacy self-management framework.

Privacy Self-Management and the Consent Dilemma

What questions would you want answered before you chose a federated credential over a local one?

RELATED INFO

• Andrew Hughes: A Conceptual Model for the NSTIC ID Ecosystem v02
• [Daniel Solove: Privacy Self-Management and the Consent Dilemma][2]

[2]: http://www.harvardlawreview.org/issues/126/may13/Symposium_9475.php “Privacy Self-Management and the Consent Dilemma