In a previous post, I argued that the appropriateness of a Distributed Ledger (DLT) to a use case depends on whether three criteria are true, specifically:

 

• That it be desirable that it be difficult to later modify the database used to record transactions.
• That the parties engaged in transactions may have conflicting and even adversarial interests.
• That it is undesirable that a third party manage the database.

 

In this post I'll try to answer the question "Do identity use cases meet the above criteria?" and so explore whether and how DLTs might be relevant to identity and access management (IAM).

 

Identity Use Cases

Of the above three, the immutability property of DLTs seems hardest to reconcile with identity applications. I argued this point in the first part of this post and won't belabor it here.

 

I'll focus below on the other two key features of DLT, namely their ability to allow mutually distrusting actors to come to agreement about the existence and ordering of some set of facts shared between them, without that agreement being moderated by a single central party.

 

A fundamental identity use case is one entity asserting attributes or characteristics of a second. The first entity asserts a value of some attribute for a second entity to a third entity; the third, in the absence of being able to itself confirm the value of those attributes, relies on those assertions and acts accordingly. As a concrete example, in a single sign-on flow, A authenticates the user B and then asserts that fact (plus perhaps some other attributes) to the website or application C where the user wants to access services.

 

For C to have confidence in the assertion about B that it receives from A, certain questions need to be answered:

 

1. Is A a credible and authoritative source for the attributes?
2. Is A diligent and rigorous in the processes and procedures by which it ensures that it issues assertions only to the relevant parties, i.e., B and not somebody pretending to be B?
3. Is the delivery of the assertion from A to C protected against tampering? I.e., modification, replay etc?

 

Let's consider how DLTs, and specifically their ability to deprecate the need for a third party to mediate the state of some databases, can help answer these questions.

 

Business Considerations

In the above list, the first is a business problem. Only the Government of Canada (GoC) can attest to the fact that I am Canadian. Or, to be precise, only GoC can do so with any credibility. Others can make the claim, but a relying party would have no reason to accept that claim.

 

And no technical mechanism will ever be able to prevent one business from cheating a business partner for its own advantages by lying about the attributes of the subjects. For instance, if some SaaS were charging its enterprise customers per employee, an enterprise could conceivably minimize its costs by having multiple employees share the same asserted identifier at the SaaS.

 

So how does C become confident that A is a reputable business that won't completely fabricate the contents of the assertions it creates? Likely by relying on a mix of signals (they have a website and a business credit card or similar indicators of legitimacy) and legal protections should they cheat. Legal protections, of course, imply dependence on a third party, i.e., different levels of government.

 

Logistical Considerations

The second is a logistical problem. In theory, C could send investigators to examine the processes and technology A has in place to protect its identity management infrastructure from compromise. They could dig into how identities are issued, authenticated and other technical mechanisms. For instance, they might verify that a social provider supports authentication factors beyond password, and so be better able to authenticate its users when doing social login.

 

Months later the investigators would report back that A runs an efficient shop and does an adequate job of protecting identities. Or not. This sort of direct review would, of course, be expensive and slow. That's why there exists an industry of specialized third-party providers that perform the investigation (for a fee) and attest accordingly.

 

It is now worth pointing out that DLTs allow parties to come to consensus on the state of the shared ledger; that is, everybody can agree they are all looking at the same set of data. DLTs themselves say nothing about whether that data is actually true. E.g., everybody can come to agreement that the database includes the statement "The sky is green."

 

Given that, I don't see DLTs offering any unique value in helping the relying party C answer these first two questions. Both demand that C make a value judgement, e.g., that A is "good" at something, and DLTs will never help with that, other than merely providing a place where other parties recommendations about A could be stored. But that, of course, reintroduces a third party into the mix that DLTs promised us to do away with.

 

Technical Considerations

The third requirement is a technical problem: How can we deliver an assertion over the (likely public) network so that we prevent a malicious actor interfering with that transmission for nefarious purpose?

 

It is on this third requirement that different identity standards and models differ--and where I believe that DLTs can offer value (albeit with tradeoffs) relative to other models.

 

Every identity system can be characterized and differentiated by how it answers the following questions (which determine the how, what, and when an assertion is shared):

 

1. What is asserted (i.e., identifiers, or other attributes, or both)?
2. Is the assertion created in real time or beforehand?
3. How is the assertion delivered (directly or indirectly via a user-agent)?
4. How is the assertion's security protected (i.e., has it been tampered with or replayed)?

 

As an example, a deployment of SAML in support of employees accessing SaaS applications might answer the above questions as:

 

1. An identifier plus role information to help drive authorizations.
2. Created in real time by the enterprise in response to an indication from the employee they wish to access the SaaS.
3. Indirectly, via a browser redirect to the SaaS with an artifact that is subsequently exchanged for the desired assertion.
4. A combination of the enterprise signing the assertion, SSL protecting the front and back channels, and a one-time nonce give the SaaS confidence it wasn't modified or replayed.

 

A deployment of OpenID Connect for social login would have similar answers for #2, #3, and #4, but would likely replace role attributes of #1 with profile info or social streams.

 

In a typical deployment of the SAML and Connect models, the asserting party (the identity provider) is involved in the real-time delivery of the identity assertion to the application. This involvement has a number of consequences, including:

 

1. The identity provider will have knowledge of where the assertion is used and so which sites the user is visiting. This level of knowledge has sometimes been characterized as "panoptical," giving the asserting party inappropriate visibility into the user's activities, as in 18th century prisons built so that a prisoner was always under observation. It is worth pointing out that 1) in the enterprise case, it is of course perfectly appropriate for the enterprise to know which SaaS applications an employee is visiting in the course of their job, and 2) in both cases, the asserting party won't know what the user is doing at the application, only that they visited there.
2. The relying party will have knowledge of the identity providers at which the user maintains their identities. In many situations this knowledge is valid (even necessary), but not always.
3. There is the theoretical potential for the identity provider to refuse to issue an assertion to a particular relying party. Perhaps the US government would refuse to issue an assertion as to the nationality of one its citizens to the Russian government?
4. There is the theoretical potential for an identity provider (or a malicious insider working there) to impersonate a user by presenting an assertion about that user to a relying party.

 

For some, these consequences give too much power or knowledge to the identity provider and too little empowerment to the user. Using the analogy I introduced in the first part, they see the SAML and Connect models as "placing too many privacy eggs in the IdP basket." Such critics contrast it with the real-world example of somebody being able to purchase alcohol by presenting a driver's license proving their legal age, where DMV, the agency that issued the license, is unaware that the user is buying alcohol and has no ability to prevent the user from doing so.

 

The Self Sovereign Identity Model

The Self Sovereign Identity (SSI) community is proposing an identity model that de-emphasizes the real-time involvement of the identity provider and so aims to mitigate the above concerns. SSI still recognizes the value of certain parties being authoritative over certain identity attributes (e.g. the DMV for driving ability) but argues the benefits of disintermediating those asserting parties from being actively involved in the sharing and presentation of the assertions.

 

In the absence of an identity provider creating identity assertions on a just-in-time fashion in response to a request from a relying party, we need an alternative issuance-delivery-validation model. The SSI community advocates introducing a DLT into the mix, specifically to store references to user identity assertions stored off-ledger.

 

Critically, in SSI models, identity assertions are issued ahead of time rather than at the real-time behest of a relying party. This, of course, means that identity assertions are not created for the particular relying parties to which they will be presented. Like a real-world driver's license, the SSI assertions are not targeted for a specific audience.

 

In the SSI model, a DLT is merely a place where the identity provider can add pointers (not the assertions themselves for privacy reasons) to the assertions it makes. A DLT provides a shared database where IdPs can logically place assertions about user identity attributes and relying parties can subsequently look them up. A user lays claim to those assertions by demonstrating they have possession of an associated crypto key when interacting with a relying party.

 

The DLT serves to distance the IdP from the RP, and so mitigate the concerns listed above where the IdP was perceived to have excessive power and control. Instead of using a DLT, all IdPs could place their assertions into some centralized database. But this just shifts the problem and gives to that single central database inappropriate visibility and control into a user's identity operations.

 

So the SSI model and its usage of a DLT may offer privacy advantages relative to the web redirect model normalized by SAML and OpenID Connect. But there are, of course, tradeoffs. In the next post in this series, I'll explore what those tradeoffs might be.

 

---