Why self-sovereign identity will get adopted (and it’s not the reason you probably want)

(Thanks to Kim Cameron for prompting me to write this down. Special thanks to Chuck Mortimore for his insight and probing questions and who helped me improve this.)

In the identity industry, there’s been a lot hype these days around self-sovereign identity. The latest permutation in the quest for user-centric identity, self-sovereign revisits the laudable goal of enabling people to be in better control of how information about them passes to enterprises and organizations (but now with added blockchain.) To be clear, increased individual control is an important goal and one that incredibly sharp people have been working on for 15+ years, going back to InfoCard and Higgins.

Before I discuss why self-sovereign has a real chance at widespread adoption, it’s important to understand why identity technologies and approaches get adopted in the first place. At least, three things are required:

  1. People who will use the identity system
  2. Organizations willing to consume identities from the system
  3. Significant and relatively equivalent value for both groups

You need a lot of people to use an identity system for mainstream adoption. You get those people by providing enough value to them either in hard currency (e.g. you give them a cut of what their personal data is worth, extend discounts in lieu of currency, or free services) or in efficiencies (e.g. never fill out an account registration form ever again) or in security (e.g. your account will be harder to hack) or in privacy (e.g. your data will never be resold or your data is anonymized.)

There also needs to be real utility for people to use a given identity system. Assuming there is a choice to be made, an individual will naturally select an identity system that gives them access to more services than one that doesn’t. (To be clear only a small portion of people spend time thinking identity systems or the selection thereof. And an even smaller portion know that they are thinking about identity systems. What people do think about is, “how can I log into this service over here with minimal pain” and “how I can avoid disclosing too much about myself.”)

To get enterprises interested in consuming digital identities from a system, enterprises needed to see value as well. Such values include the data flowing in the identity system is useful and accurate, reduction in the cost of acquiring large numbers of well-proofed identities, lower customer acquisition costs, and increased data quality.

Now you might be scratching your head on the 3rd point, specifically the phrase “relatively equivalent.” Both the individual and the organization need to get value out of the use of the identity system. AND both have to feel like they got a fair deal. If individual feels they were take advantage of, or the organization just simply doesn’t see enough value for the investment, neither will use the system. All it takes is one bad deal with one organization and an individual will be inclined to stop using the identity system. So, bad organizational actors prevent the network effect and widespread adoption from being realized.

There have been technologies and systems to provide these sorts of value propositions to both people and enterprises for years. Arguably, the only one that has seen widespread adoption is social sign-on (the use of a social network identity for sign up and sign-on into other services) because it provides efficiencies to the person and lower cost of acquisition and large addressable population to the enterprise. And with the increased attention to how social networks use shared information about people and increased competition by social providers in other markets where “traditional” enterprises deal, social sign-on may be facing some head winds.

The time could be ripe for something different. Something like self-sovereign identity?

The goals of user-centric/personal data/self-sovereign provide an impressive value proposition (at least from an individual’s perspective) including control, privacy, and security and thus could generate a large potential user-base. Organizations also need to see value in order to adopt this sort of identity system. In this case, we need to leave aside data quality and the ability to acquiring proofed customer/citizen identities because those abilities have been available in identity systems for 15+ years. That said, self-sovereign/user-centric brings a new potential asymmetrical value for organizations to realize: the ability to shift risk onto the individual. And that, my friends, is a huge attractor to enterprise and a huge detractor for individuals.

The core notion of user-centric identity is that the individual can choose what information about them to disclose to which organizations and for what purposes – the individual has greater control. I love that notion. But I am not a typical person and if you want widespread adoption, do not use me as a baseline for design purposes.

Here’s my concern: in course of interacting with an organization online, a person is asked to disclose some information. The person’s smart user agent gathers the individual’s consent to disclose the information and it sends the data to the organization. The person then receives lower quality of service from the organization. The person complains to the organization saying that they didn’t understand what they was being asked to consent to. “Too bad,” says the organization because we have evidence that your smart agent sent us the data and you provided consent for the use of that information.

In this case, the organization can push the risk of attribute use (or mis-use in the eyes of the individual) back onto the individual. The organization has a clear line of sight as to how it acquired the data (directly from the individual) and the individual has no recourse in the case they made a mistake or misunderstood what was being asked of them. This sort of risk shifting is asymmetrical in favor of the organization at the expense of the individual.

In the payment card world, there are clear guidelines on personal liability. $50 if you use credit and up to $500 for debit depending on when you report the issue. Based on that, different people choose to use different “systems.”

However, no such guidelines exist for the use of identity information (e.g. attributes.) In the absence of such guidelines and especially in a world without the right of personal action, the risk will shift from the enterprise to the individual and we can expect enterprises to aggressively try to shift this risk and thus adopt self-sovereign approaches. This exploits and exacerbates an asymmetry; this is not “relatively equivalent value.”

And that seems at odds with the goal of putting the individual in control. This asymmetry shouldn’t be the actual reason for widespread adoption.

A Maturity Model for De-Weaponizing Identity Systems – Part 3

In Part 1 of this series, I discussed the types of attackers who can weaponize your identity systems, use them to cause harm. In Part 2, I introduced the design goals of the Maturity Model as well as the disciplines needed to implement the Maturity Model. In this post, I’ll discuss each of the 5 levels of the Maturity Model and controls you should put in place to achieve those levels.

Level 1 – Managed

This level is table stakes. It optimizes your organization’s existing security controls for identity systems. I believe it helps make compliance with things like GDPR easier but it is in no way a “cure all” for regulatory burdens. To achieve Level 1, you’ll need a combination of access control, data protection, and audit:

  • Access Control
    • 2FA for admins
    • No developer access to production data
    • No program-lead access to production
  • Data Protection
    • No insecure data transfers
    • No insecure data staging
    • Data encrypted in transit
  • Audit
    • Audit all admin system configuration changes
    • Audit user access to systems

Some of things to note… 2FA for admins is just good practice in every setting, especially if you do not have a privileged account management procedure in place. We often hear about “no developer access to production” but in an era of DevOps, you want your developers in production… but that doesn’t mean they need to access to production data, just the production systems themselves. Similarly, while developers get a lot of attention, one constituency that doesn’t are program leads. People like me should not have access to production. If you oversee an IAM program, you should not have any sort of administrative access to your production systems. Sure, you are an end-user of those systems, like everyone else, but you should not have any other privileges.

Probably not a lot of surprises in the Data Protection section, but we still see people getting tripped up by staging data insecurely.

Audit too comes with little surprise. Know what admins are doing to your systems and know who it using your systems. Continue reading “A Maturity Model for De-Weaponizing Identity Systems – Part 3”

A Maturity Model for De-Weaponizing Identity Systems – Part 2

In the first part of this series, I discussed different kinds of attackers and why they attack our identity systems. I also discussed how they can weaponize our identity systems, turning what is meant to deliver services and do good into something that can be used to cause harm. In this part I’ll talk about the goals of the model, the disciplines needed to do this work, and the levels of maturity.

Goals of the Maturity Model

When coming up with this maturity model, I had 4 goals in mind:

  1. Defend against all attackers
  2. Balance protection and productivity
  3. Achieve greater transparency
  4. Promote data provenance

Defend against all attackers

Since all 3 kinds of attackers can weaponize identity systems, we have to defend against every time of attacker: Bulk, Single Data Subject, and Successor. However in order to do this requires that we have specialized defenses against each type. Said differently, a generic defense is in effective. In fact, one can think of this maturity model as a specialization of existing security controls for identity systems, but more on that later. Continue reading “A Maturity Model for De-Weaponizing Identity Systems – Part 2”

A Maturity Model for De-Weaponizing Identity Systems – Part 1

It’s no secret that we, as identity professionals, are the custodians of some of the most crucial information in our enterprises. We hold information about employees and customers in our identity systems in order to deliver them services that range from productivity to entertainment to personal health and wellbeing.

And as professionals, none of us want to build systems that can harm other people. Certainly, none of us want to build systems that can be used to harm ourselves. At the core of our professional code of ethics is the spirit of “do no harm.”

Now it is true that if our identity systems are of value to us and to our employers, then they are of value to attackers.

Who are these attackers?

There are two kinds of attackers: bulk and single data subject attackers; let’s look at both.

Bulk Attackers, as the name implies, want bulk data… they want all the data. Why they want all the data can vary widely. They might be interested in a single vendor’s customers. Or they might be interested in everyone in a region who shares a medical condition or ethnic heritage, or employer. They might be setting up for a later spear phishing attack. They might be putting the pieces together for an ethnic minority oppression campaign or a voter suppression campaign.

On the other hand, Single Data Subject Attackers are only interested in a single data subject. They are focused just one individual. Why? They might want to take control of a celebrity’s mobile phone for the lulz or leak personal photos to the web. They might be interested in dox’ing an adversary. They might want to make an ex-spouse’s life a living hell.

Continue reading “A Maturity Model for De-Weaponizing Identity Systems – Part 1”