Verifiable Credential Exchange

Summary

Verifiable credential exchange is the foundation of decentralized, online identity. This post describes how it works.

I realized last week that I'd never explained verifiable credential exchange as a stand-alone topic—it was always buried in something else.

Multi-source identity (MSI) depends on issuing, exchanging, and verifying digital credentials. The specification for verifiable credentials is being formulated by the World Wide Web Consortium’s Verifiable Credentials Working Group. Verifiable credentials provide a standard way to express credentials in a way that is cryptographically secure, privacy respecting, and automatically verifiable.

Credentials are defined by their issuer in a credential definition. The credential definition links the public decentralized identifier (DID) of the issuer, the schema for the credential, and a revocation registry for the credential. The definition, public DID, schema, and revocation registry are all stored on a distributed ledger that is used for decentralized discovery. (See What Goes on the Ledger (PDF) for more detail on these.)

Credential exchange is the process by which credentials are issued, held, presented, and verified. Credentials are exchanged peer-to-peer by software called "agents." The specific details of how this works technically is defined in Indy agent protocol. Agents create relationships in this peer-to-peer network by exchanging DIDs and their associated public keys.

Here's an example of how credential exchange works. Suppose Alice is applying for a loan at her local bank. The bank requires proof that Alice is employed and makes at least $70,000 per year. Alice has pre-existing relationships with her employer and her bank, meaning her agent is connected to their agents via an exchange of DIDs. Alice’s employer has issued an employment credential that includes her employment status and her current salary. It might also include many other attributes related to Alice’s job. As shown below, Alice holds this credential in her agent. She can present the credential to prove to the bank that she is employed and makes more than $70,000.

Credential Flow for Alice Obtaining a Loan (click to enlarge)

When Alice proves her employment status to the bank, she doesn’t present the entire credential since doing so would reveal more information than is necessary. Instead, Alice presents a zero-knowledge proof of just the information the bank needs. The ability to limit the information presented from a credential is important to maintain privacy through the principle of minimal disclosure.

Alice’s bank can verify the credential proof by looking at the credential definition on the ledger, retrieving the public DID and associated DID Document of the issuer, and using the public key in the DID Document to check the signature of the credential to ensure it hasn’t been tampered with. The bank can also cryptographically verify that it was issued to Alice. As part of making her proof from the credential, Alice also proves that it has not been revoked by referencing the revocation registry, which is also available on the ledger.

In multi-source identity, a particular credential is not intrinsically true. Rather each verifier determines who and what they will trust by relying on the attestations of other parties. Thus, truth is established through a preponderance of evidence. How much evidence is needed for a situation depends on the risk, something the verifier determines independently.

For example, in the previous scenario, if the bank does not already know the public DID of the employer, they could validate it in several ways. The most obvious is to interrogate the endpoint in the employers DID Document and ask for proof that they are a legal business and any other information they need to trust the employer. The employer could use credentials they have to prove this to the bank, or they could do it out of band. Once the bank knows to trust the public DID of the employer, this information could be cached according to the policies of the bank.

The trust model for verifiable credentials has five important characteristics that mirror how credentials work in the offline world:

Credentials are decentralized and contextual. There is no central authority for all credentials. Every party can be an issuer, a holder (identity owner), or a verifier. Verifiable credentials can be adapted to any country, any industry, any community, or any set of trust relationships.

Credential issuers decide on what data is contained in their credentials. Anyone can write credential schemas to the ledger. Anyone can create a credential definition based on any of these schemas.

Verifiers make their own trust decisions about which credentials to accept—there's no central authority who determines what credentials are important or which are used for what purpose.

Verifiers do not need to contact issuers to perform verification—that's what the ledger is for. Credential verifiers don't need to have any specific technical, contractual, or commercial relationship with credential issuers.

Credential holders are free to choose which credentials to carry and what information to disclose. People and organizations are in control of the credentials they hold (just as they are with physical credentials) and determine what to share with whom. This is sometimes referred to as self-sovereign identity (SSI).

Multi-source identity is composed of credentials from multiple sources. In addition to her relationship with her employer and bank, Alice likely has a relationship with the state, and holds credentials they issue representing her birth certificate and driver’s license. She might hold credentials from her university representing her transcript. The list of potential credentials that Alice holds is long and depends on her relationships online and offline. She could have hundreds of relationships and associated credentials in her wallet. She can use any of these, in any combination, to prove things about herself (with minimal disclosure) to any other party who accepts them.

Decentralized credential exchange is not new—we've been doing it in the physical world for centuries. But doing it online is novel. Decentralized digital credential exchange gives people and organizations the freedom and autonomy to create authorization regimes that meet their particular needs. Furthermore, credential holders have autonomy and choice in whether to participate. The result is a flexible identity architecture that covers thousands of use cases, even ad hoc use cases, while supporting choice and privacy for identity owners.

Verifiable credential exchange enables online identity transactions that are nearly impossible to imagine using the single-purpose, IdP-based identity systems of the past. The Internet enabled a rich, decentralized ecosystem of message exchange that could never have been supported by the walled gardens of Compuserve and AOL. Similarly, self-sovereign, multi-source identity enables a richer, decentralized ecosystem of identity transactions than can ever be realized with the single-source identity systems we've used to date. Self-sovereign, multi-source identity enables an Internet for Identity.