[This post was submitted to the DIF blog as part of an educational grant by researcher, educator, and consultant Kaliya Young and originally posted to medium.com]

It is a mouthful of an acronym: it stands for OpenID Connect — Self-Issued Identity Provider. Unless you are familiar with the terminology of the OpenID community, knowing what the acronym stands for doesn’t illuminate much, but rest assured, this is one of the most exciting developments to support the widespread adoption of Verifiable Credentials across the web.

This post will explain how it’s exciting and what kinds of adoption it could galvanize. First, we will cover OpenID & OpenID Connect, then touch on how decentralized identity (or “self-sovereign identity”) relates to “authentication” and “user accounts,” and finally how they can work together, with two educational videos along the way.

While there is substantial and sophisticated prior art, particularly in the Aries community, for integrating verifiable credentials with OpenID Connect, using DIDs for OIDC is still emerging and approaching its first stable specification in the coming months. This is the culmination of substantial collaborative work to develop this bridge between the DID Authentication Working Group at DIF and various interlocutors at the OpenID Foundation. This post breaks down key elements of this development and shares more resources if you want to explore it further.

What is OpenID & OpenID Connect

The first seeds of OpenID were sprouted at the very first Internet Identity Workshop in 2005. All the companies interested in URL-based protocols got together and collaborated together on their various models for designing authentication for users against URLs they controlled, like their personal blogs. This protocol has evolved and the latest iteration is based on sophisticated OAuth (Open Authorization) standards and tooling.

The basic and most typical flow used by OpenID Connect can be described as follows: an individual, which in this context can be called a “user” of the identity system, first gets a fresh proof of authenticity of their digital identity. This unique proof is minted in the course of an interaction with a service called an “Identity Provider” (IP), i.e. Google or Facebook. This proof usually takes the form of a “token,” a single-use cryptographic access code linked to the corresponding identity record at the IP. The user then takes that token to a second site that they are going to login to, with is called the “Relying Party” or RP, which can then trust they are dealing with the same person identified (usually very strongly) by the Identity provider.

OpenID Login Flow diagram — OpenID Login Flow

The teams of professionals that created OpenID Connect had enough imagination to anticipate more complex use-cases that weren’t immediately needed by the commercialized web of 2005, but for which the technical foundations were still worth laying. Among there, there was a clear idea that users would, in some cases, prefer or need to bring their own identity with them rather than a pointer to a record on an IP’s server. This identity would thus be “self-issued,” a capability they designed into the OpenID core specification.

The vision of DID-SIOP is a way of bringing decentralized identity concepts into alignment with the ideas of “self-issued” portable identity that the original OpenID innovators had. It was good that they included and preserved this underutilized capability in their immensely popular and internet-powering framework, which is the basis of modern social login (i.e., “Sign on with Google/Facebook/etc”). After all, it would have been simpler not to, but enough of designers and thinkers involved anticipated much of what has developed in parallel, the decentralized identity technology that the DIF serves to support.

How do decentralized identity systems work?

In this conceptual framework, the “Identity Provider” has been cut down a notch, and is instead referred to as a mere “Issuer” (of credentials and information, perhaps of identities over which it has less control).Similarly, the “user” is defined less by borrowed tools and more by owned ones, assuming the title of “Holder” of information and identity, whether issued or self-issued.. The “verifier” relies less on the identity provider, choosing instead to verify information and identities presented by their holder on their own terms (with some cryptographic assurances about the issuer).

One interesting difference between traditional OIDC and decentralized systems is that in the latter, all parties have identifiers that make it possible to verify signatures; it is hard to tell from a DID whether it corresponds to an institution, an individual, or an inanimate object, because it could be any or all of those. Whatever it represents, it points to ways of verifying signatures with so-called “key material” (public keys, hints to how to classify and use them). Most often, this happens by looking up the material on a distributed ledger, but this is not, strictly speaking, definitive of the framework..

The key material from an OIDC issuer proves the veracity of whatever information or identity is being presented in a way that is tied back to that issue by similar key-material guarantees, and a self-issued OIDC token works the same way. (In a self-issued OIDC credential, the holder’s key material is used in the place of an institutional issuer’s).

Verifiable Data Registry diagram from DID v1 CR specification

How OpenID and Decentralized ID can fit together

One of the big challenges for any new technology that needs an identity system is getting adoption of the needed components so the system can actually work at a sustainable scale. This usually required buy-in from various kinds of actors in an ecosystem: at the very least, it needs critical mass of users/holders, IPs/issuers, and RPs/verifiers, each maintaining their end of the infrastructure and “keeping the lights on,” as it were.

This is exactly where the two systems can really help each other: achieving and maintaining critical mass of all three, as the distribution of more and less centralized solutions changes, and self-issued credentials come to be accepted in theory and in practice. OpenID Connect has a large “install base”: there are literally millions of websites running OpenID Connect tooling as the authentication mechanism at their “front door” for users. Indeed, while a vanishingly small portion of internet users have ever heard of OIDC, it is the nuts and bolts of the most universal and familiar UX and user flow of the contemporary commercial web, including online banking and government services.

OIDC-SIOP leverages the code that OpenID Connect relying parties already have in place across all these millions of sites, and the lion’s share of the 10,000 most used websites. Think of the screen that reads, “Log in with Google / Facebook / Twitter / Github / etc.” OIDC-SIOP enables organizations to ask for Verifiable Credentials that an individual holds in their wallet instead of a token from Google / Facebook / Twitter / Github. These can be single-use access codes with cryptography built in, or more reusable credentials, or richer credentials containing various kinds of information otherwise requested from an IP. This mechanism is provided by the Self-Issued OpenID Provider flow described by the core specification:

Diagram of SIOP v1 architecture by Oliver Terbu/DIDAuth WG

If successful, this will be a huge win for decentralized identity, because it addresses the perennial “Relying Party” problem of adoption: how do you get relying parties to adopt a new technology, install and trust a new “doorway,” adapt their security and business processes to a new set of strengths and weaknesses? In the popular imagination and even in much of the technology press, scaling a business or a technology is often imagined as a quest for users, but they are often the easiest shareholder to get on board, particularly for something convenient and powerful. The relying parties (or, in economic terms, the “demand side” of identity) is often a much harder business problem, and in this case, no “big lift” is required of the verifiers or “relying party” consuming a new kind of authentication credentials because they only have to make minor adjustments to the nearly universal OIDC tooling they already have.