Self-Sovereign Identity Glossary

[david.luna]

This glossary gives a (very) quick overview of the significant actors, roles, and components of a fully-realized Self-Sovereign Identity (SSI) solution.

For more formal definitions, please see https://www.w3.org/TR/vc-data-model/#terminology

Components

Verifiable Credential (VC)

A credential which has been generated about a given individual entity (Subject) by an Issuer. A credential is formed as a collection of attributes (or ‘claims’) that describe qualities of the subject. A Verifiable Credential is signed by its Issuer, allowing the receiver of a presentation of that VC (Verifier) to cryptographically prove that the credential was indeed issued by the Issuer the VC indicates.

Zero-Knowledge Proof (ZKP)

A process through which ownership of a piece of information is proved without revealing the information itself. This allows the ability for a Verifier to request responses to queries such as “Prove you are over 18”, without the Holder having to release a VC which states a Subject’s age or birthdate.

Verifiable Data Registry

The location in which the schema and key information relating to a given Verifiable Credential is stored. For example, an Issuer’s public keys, used by a Verifier when validating a presented VC. In the fully-decentralized world of SSI, this data is stored on an Immutable Public Ledger.

Wallet

The location a Holder stores their VCs. This could be on a hardware device a Holder owns (e.g. an app on their mobile phone) or a ‘web wallet’, available

Agent

The software that communicates between Holders, Verifiers, and Issuers using the necessary protocols. A Holder’s Wallet will often comprise a built-in agent.

Immutable Public Ledger

A location accessible to all involved Actors, assured to be resistant to tampering. Most commonly this is considered to be a public blockchain.

Actors / Roles

Holder

The entity to which VCs are issued by an Issuer, and from which a Verifier requests presentations. Holder’s generally own (or have access to) a Wallet in which they store their credentials. A Holder is often, but not always, the Subject to which the VCs in their Wallet refer.

Subject

An individual entity about which claims can be made which can be formed into VCs; e.g., a person, service, or device.

Issuer

An entity that issues VCs to a Holder, by communicating a VC to them and ensuring the necessary information to verify that VC is available in a Verifiable Data Registry.

Verifier

An entity that requests a presentation of a VC from a Holder. Note: A single entity may concurrently be a Subject, Holder, Issuer, and Verifier.

Other Articles by This Author:

The Real World Is Not Ready For SSI

Self-Sovereign Identity (SSI)—in the pure form that its most ardent supporters promote—envisions a situation where every user controls their own digital wallets containing verifiable credentials (VCs). The contents of these VCs are stored in immutable public blockchains and are shared to service providers through zero-knowledge proofs (ZKPs). Unfortunately, the real world is not ready for SSI. For a quick primer on the technologies, actors, and roles involved in SSI and how they interact, ref…

Passkeys, and other announcements from the FIDO Alliance, Apple, Google, and Microsoft

Further steps towards passwordless adoption. The latest front in the war on passwords was opened recently via a multi-pronged attack by the FIDO Alliance, Apple, Google, and Microsoft. The announcement by the FIDO Alliance on the introduction of “passkeys” (or “multi-device credentials”) has been met with excitement by the Identity and Access Management community. At ForgeRock, we have been passionate about helping reduce the burden of passwords, and fully support these moves. The announcement…

Operator Tokenomics and Respectful Personal Data Brokering

This article was written by Eve Maler and David Luna. A video demonstration is included at the end of this article that shows a no-code integration of the Privacy Co-op consent engine into a user journey design. The Challenge Creating tangible value while complying with privacy regulations can get complicated. In order for providers to deliver the most personalized (and monetizable) experience, consumers need to share some personal data. Meanwhile, data privacy regulations are upping the…

#define web3

#define web3 The journey that we’re on… As we saw the emergence of Web2.0 (“web two point oh”) around 2003-2004 it changed the way users interacted with the world-wide web. No longer were static pages of information akin to an offline directory suitable for the modern web; it was time for dynamic content, and user participation. No longer were discussions between users hidden away in forums; it was time for comment sections and sites with built-in chat functionality. No longer was a user require…

Push Protocol – Challenge/Response & Registration Redux

Overview Push authentication depends on the secure verification of information sent from the server to the client, and from the client to the server. This lets the server verify that the notification was received by the original device, and for the device to verify that only the server sent the original request. This approach is achieved by a combination of communication channels: QR Code over HTTPS: Required for setup of the account on the user’s device. This allows an out-of-band setup of…

How To: Configure the SAML2 Authentication Module for Auto Federation in AM

By David Luna A quick video tutorial on how to configure the SAML2 Authentication module for auto-federation in AM This demonstration walks through configuring the module from first principles, showing how to configure a service provider (SP), an identity provider (IdP), and then the Authentication module as part of a login chain. NOTE This video demonstration uses OpenAM 13.0; although the appearance has changed between AM and OpenAM 13.x, the same principles and processes still apply. In A…