Glossary

This glossary collects the Self-Sovereign Identity (SSI), decentralized-identity, and Identus-specific terms used throughout the book. Definitions are written for the working developer: enough to follow the surrounding chapters, with pointers to the standards where a term is formally defined. Terms are listed alphabetically.

ADA

The native cryptocurrency of the Cardano blockchain. PRISM Node spends ADA on transaction fees when it anchors did:prism operations on-chain — test ADA on test networks such as preprod, real ADA on mainnet.

AnonCreds (Anonymous Credentials)

A privacy-preserving Verifiable Credential format originating in the Hyperledger Indy ecosystem. It uses zero-knowledge proofs and predicate proofs so a holder can prove facts (for example, “age over 21”) without revealing the underlying attribute values. Supported by the Identus Cloud Agent.

API key

A per-tenant credential (sent in an apikey header) that scopes Cloud Agent API calls to a specific tenant’s wallet. Privileged administrative operations instead use an admin token.

Apollo

The Identus building block that provides cryptographic primitives — hashing, digital signatures, encryption, and key generation — used across the platform to ensure data integrity, authenticity, and confidentiality.

AppRole

A HashiCorp Vault authentication method (a role ID plus a secret ID) preferred over a static root token for automated, production Cloud Agent deployments.

Aries (Hyperledger Aries)

A family of Hyperledger interoperability protocols (RFCs) for SSI agents — covering DID exchange, out-of-band invitations, issue-credential, and present-proof flows. The Identus Cloud Agent is built to be W3C- and Aries-compatible.

assertionMethod

A verification relationship in a DID Document listing the keys approved for making assertions, including signing (issuing) Verifiable Credentials. A verifier checks that the credential’s signing key appears here.

authentication

A verification relationship in a DID Document listing the keys approved for proving control of the DID through challenge-response authentication.

Building Blocks

The set of focused, modular Identus libraries that each handle one area of SSI functionality: Apollo (cryptography), Castor (DIDs), Pollux (credentials), Mercury (DIDComm), and Pluto (storage). Both the Cloud Agent and the Edge Agent SDKs implement the same building blocks.

Cardano

The public blockchain Identus uses as its production Verifiable Data Registry, anchoring did:prism operations so that anyone can resolve a published PRISM DID. Anchoring requires ADA to pay transaction fees.

Cardano DB Sync

A Cardano component that follows the chain and indexes blocks into a PostgreSQL database so that PRISM Node can read ledger data efficiently. Typically the heaviest resource consumer in a self-hosted Cardano stack.

Cardano Wallet

The Cardano-ecosystem service PRISM Node uses to manage funds and submit Cardano transactions when publishing DID operations. Distinct from an SSI wallet.

Castor

The Identus building block that creates, manages, and resolves Decentralized Identifiers, currently supporting the did:prism and did:peer methods.

Certificate Authority (CA)

The traditional centralized model of digital trust, in which a central authority vouches for identities. Contrasted in this book with a Trust Registry, which records authority within a governed ecosystem but does not itself issue or hold credentials.

Claim

A single statement or attribute about a subject within a credential — for example a name, a date of birth, or a license category. A Verifiable Credential is a set of claims made by an issuer.

Cloud Agent

The server-side Identus agent (written in Scala) that manages wallets, DIDs, and DIDComm messaging, and that can issue, hold, and verify Verifiable Credentials. It is driven by a controller application through its REST API and is expected to be online at all times.

cnf (confirmation key)

A key-binding element embedded in an SD-JWT credential. It binds the credential to a holder key so the holder can later prove control by signing the verifier’s challenge and domain.

Confirmation depth

The number of blocks that must be added after a DID transaction before its state is treated as final and safe to resolve. A tuning knob when anchoring DIDs on a ledger.

Connection

An established, secure, ongoing DIDComm relationship between two agents, typically underpinned by Peer DIDs and tracked as a connection record in each party’s wallet.

Controller (application)

The application that drives a Cloud Agent through its REST API and webhook callbacks. The controller holds the business logic; the agent handles the SSI standards work. (Not to be confused with a DID controller.)

Coordinate Mediation

The DIDComm protocol (coordinate-mediation/2.0) a wallet uses to request mediation from a mediator and register the recipient keys for which the mediator should accept messages.

Correlation

The linking of a person’s or organization’s activity across different contexts by means of a shared identifier or reused key. Public DIDs and reused DID Document material create correlation risk; pairwise DIDs reduce it.

COSE

The CBOR-based family of cryptographic standards for signing and encryption — the binary counterpart to JOSE — referenced by the W3C VC “Securing with JOSE/COSE” recommendation.

Credential offer

A message from an issuer proposing to issue a specific credential to a holder, which begins the credential issuance flow.

Credential issuance

The protocol flow by which an issuer creates, signs, and delivers a Verifiable Credential into a holder’s wallet. In Identus this follows the Issue Credential protocol over DIDComm, or OpenID4VCI.

Credential schema

A registered, shared definition of a credential type’s structure — its fields, types, and required attributes. Issuers issue against it, and verifiers and verification policies are scoped to it. Identus supports JSON Schema (for JWT/SD-JWT) and AnonCreds schemas.

credentialStatus

The property inside a revocable credential that points to its status list entry, allowing a verifier to discover whether the credential has been revoked or suspended. Defined by the W3C VC Data Model.

Decentralized Identifier (DID)

A globally unique identifier that an entity controls without a central registrar. Defined by the W3C DID Core specification, a DID is a URI with three parts — the did: scheme, a method name, and a method-specific identifier — and it resolves to a DID Document.

Derivation path

The deterministic path used together with a wallet seed to regenerate a specific DID’s keys (hierarchical-deterministic key derivation). The Cloud Agent stores the path rather than the derived keys.

DID controller

The entity authorized, under a DID method’s rules, to change a DID Document (rotate keys, add services, deactivate). The controller may be the same as the DID subject or a different entity acting on its behalf.

DID Document

The document a DID resolves to. It publishes the public material needed to interact with the DID subject — verification methods, verification relationships, and service endpoints. It should never contain private keys, secrets, or a personal profile.

DID method

The scheme (the part after did:, such as prism or peer) that defines how a particular class of DID is created, resolved, updated, and deactivated. The W3C defines the shared data model; each method specification defines its own registry, operations, and lifecycle.

did:peer

See Peer DID.

did:prism

See PRISM DID.

DID resolution

The process of looking up a DID and returning its DID Document plus resolution metadata. Performed by a resolver that understands the relevant DID method.

DIDComm (DIDComm Messaging V2)

A secure, encrypted, transport-agnostic messaging protocol for communication between DID-identified agents. DIDComm V2 (the version Identus uses) hides message content from everyone except authorized recipients, proves the sender in authenticated mode, and works over any transport (HTTP, WebSockets, Bluetooth, and so on).

DIDPair

The cryptographic pairing of a sender DID and a recipient DID that together identify a DIDComm channel. A mediator maintains a message queue per DIDPair.

DIF (Decentralized Identity Foundation)

An industry organization that develops decentralized-identity standards, including DIDComm and Presentation Exchange.

DIF Presentation Exchange

A DIF specification for expressing what proof a verifier requires and how a holder’s wallet responds. The Identus Cloud Agent implements it for credential requests and submissions.

Disclosure (SD-JWT)

In an SD-JWT credential, the salted claim value a holder reveals at presentation time so the verifier can hash it and match it against the signed digest in the credential. Undisclosed claims stay hidden.

Edge Agent

An Identus agent that runs inside a user-facing application (web, mobile, desktop), implemented as an SDK. Unlike a Cloud Agent, an Edge Agent cannot be assumed to be online and relies on a mediator to send and receive messages. Edge Agents typically act as the user’s wallet.

Edge SDK

The Identus client libraries — available in TypeScript, Swift, and Kotlin Multiplatform — that embed Edge Agent capabilities into an application. They implement the same building blocks as the Cloud Agent.

Ecosystem

A community of participants operating under a shared governance framework within which trust relationships and authorizations are defined. A Trust Registry answers questions about authority within a specific ecosystem.

Ed25519

A widely used elliptic-curve digital-signature algorithm and key type, used for authentication and credential signing (for example, required for SD-JWT issuer and holder keys in Identus).

Entity

In the Cloud Agent, the administrative object that represents a tenant and is bound to a wallet. Authentication (an API key or Keycloak permission) is attached to an entity. In single-tenant mode a default entity (ID all-zeros) is used automatically.

forward message

A DIDComm routing message (from the routing/2.0 protocol) that wraps an already-encrypted message for a final recipient inside an outer envelope addressed to a mediator, so the mediator can route it without reading the inner content.

Governance authority

The body that defines an ecosystem’s rules and maintains, or oversees, its Trust Registry.

Governance framework

The set of rules, published by a governance authority, describing who may do what within an ecosystem. A Trust Registry is its runtime, queryable expression. Authority comes from the governance framework, not from the registry technology itself.

HashiCorp Vault

A secrets-management service that the Cloud Agent can use as its production secret storage backend for wallet seeds and key material, with per-wallet paths in multi-tenant deployments.

Holder

The role that receives Verifiable Credentials, stores them (usually in a wallet), and creates presentations from them in response to verifier requests. The holder is often, but not always, the subject of the credential.

Holder binding

Cryptographic evidence that the party presenting a credential actually controls the key associated with the credential’s subject. See also key binding.

Hyperledger Indy

A Hyperledger blockchain/SSI ecosystem from which the AnonCreds credential format originated.

Identus (Hyperledger Identus)

The open-source decentralized-identity platform this book is about, hosted under the Linux Foundation’s decentralized-trust umbrella. It provides the Cloud Agent, PRISM Node, Edge SDKs, and Mediator for issuing, holding, and verifying credentials.

Issue Credential protocol

The DIDComm protocol (Issue Credential 3.0 in Identus) that governs the credential offer, request, and issuance message exchange between issuer and holder.

Issuer

The role that makes claims about a subject, packages them as a Verifiable Credential, and cryptographically signs it. The issuer’s authority comes from the surrounding context — law, accreditation, contract, or governance.

Issuer DID

A DID controlled by an issuer and used to sign the credentials it issues, so verifiers can resolve the issuer’s keys and check authorship. Issuer DIDs are typically public (PRISM DIDs).

JOSE

The JSON-based family of cryptographic standards (JSON Web Signature, JSON Web Encryption, JSON Web Key, JSON Web Token) commonly used to secure credentials. See also COSE.

JSON Web Key (JWK)

A JSON format for representing a cryptographic key. DID Documents and DIDComm key material are often expressed as JWKs.

JWT-VC

A Verifiable Credential format that packages claims inside a signed JSON Web Token (JWT). A JWT-VC is generally presented whole, so all of its claims are revealed (no selective disclosure).

keyAgreement

A verification relationship in a DID Document listing keys approved for key agreement — for example, establishing the encryption used by DIDComm. Typically backed by an X25519 key.

Key binding

Cryptographically tying a credential to a holder’s key so the holder can prove control of that key when presenting the credential. See also holder binding and cnf.

Keycloak

An identity and access-management server that Identus can integrate so that tenants authenticate via OIDC and receive wallet permissions via UMA, replacing static API keys.

Ledger anchoring

Recording DID operations as transactions on a blockchain (such as Cardano) so they become tamper-evident and publicly resolvable.

Link secret

A holder-controlled secret used by AnonCreds to bind issued credentials to the holder and to enable zero-knowledge proofs across multiple credentials.

Long-form / Short-form PRISM DID

Two encodings of a PRISM DID. The long form embeds the DID’s full initial state in the identifier and is resolvable before the DID is published. The short form is the compact identifier used once the DID has been published to the ledger.

Mediation

The arrangement a holder’s wallet establishes with a mediator so the mediator will receive and relay DIDComm messages on its behalf. It produces routing information the wallet then advertises in its DID Document.

Mediator

A DIDComm V2 service that acts as a stable, always-online relay for agents — such as mobile wallets — that are not continuously reachable. It queues encrypted messages per DIDPair and delivers them when the recipient polls or connects, without being able to read the encrypted content. It is not a VDR.

Mercury

The Identus building block that provides the DIDComm V2 interface for secure agent-to-agent messaging, independent of the underlying transport.

Message Pickup

The DIDComm protocol (messagepickup/3.0) a wallet uses to poll a mediator for queued messages, request their delivery, and confirm receipt.

Multi-tenancy

A Cloud Agent mode in which a single agent instance hosts many isolated tenants, each with its own wallet, DIDs, credentials, and connections. The opposite is single-tenant mode, which serves one default wallet.

NeoPRISM

A newer DID-node backend for Identus, recommended for production, that can replace the legacy PRISM Node as the way did:prism operations are published and resolved.

OpenID4VCI (OID4VCI)

OpenID for Verifiable Credential Issuance — an OAuth 2.0-based protocol for a wallet to obtain credentials from an issuer’s credential endpoint. An alternative issuance path to DIDComm.

OpenID4VP

OpenID for Verifiable Presentations — an OAuth 2.0-based protocol for requesting and presenting credentials. An alternative presentation path to DIDComm.

OIDC (OpenID Connect)

A standard authentication protocol layered on OAuth 2.0, used (via Keycloak) to authenticate tenants and issue access tokens.

Out-of-Band (OOB) invitation

A self-contained DIDComm invitation — often delivered as a URL or QR code (carried in an _oob query parameter) — that lets a new party start a connection, mediation, or a connectionless issuance/presentation without a pre-existing channel.

Pairwise DID

A DID created uniquely for a single relationship, so that each relationship uses a different pseudonymous identifier. Pairwise (relationship-specific) DIDs reduce correlation across contexts; Peer DIDs are typically used this way.

Peer DID

A DID (method did:peer) shared privately between the parties to a relationship and not published to any public ledger. Identus uses Peer DIDs for DIDComm connections and mediation, where relationship-specific identifiers reduce correlation.

Pluto

The Identus building block that defines the storage interface for identity data (DIDs, keys, credentials, connection state). The application supplies the concrete storage implementation.

Pollux

The Identus building block (and Cloud Agent subsystem) responsible for Verifiable Credential operations — issuance, verification, selective disclosure, and credential status.

Predicate proof

A proof that an attribute satisfies a condition (for example, age >= 21) without disclosing the underlying value. A core feature of AnonCreds and zero-knowledge proofs.

Presentation request

A message (also called a proof request) in which a verifier specifies exactly what proof it needs from a holder. Carried by the Present Proof protocol.

Present Proof protocol

The DIDComm, format-neutral protocol (Present Proof 3.0 in Identus) that carries a presentation request from a verifier and a presentation back from a holder.

PRISM DID

A DID using Identus’s did:prism method, whose create, update, and deactivate operations are anchored to the Cardano ledger via PRISM Node. PRISM DIDs suit public issuer and verifier identities that need ledger-backed resolution. See also long-form / short-form.

PRISM Node

The Identus component that implements the did:prism method, acting as a second-layer node over the ledger. It publishes and resolves PRISM DIDs, maintaining an indexed internal state synchronized with the underlying blockchain. It serves as the VDR for PRISM DIDs and is expected to be online at all times.

Published DID

A DID whose operations have been anchored to the ledger so that any party can resolve it. Contrasted with an unpublished DID — for example, a holder usually does not need to publish their DID, whereas an issuer typically must.

Recipient keys

The keys a wallet registers with a mediator so the mediator knows which incoming messages to queue for that recipient.

Relying party

The party that consumes a verification result and applies business and trust policy — accepted issuers, schemas, and credential types — to decide whether to act. Often the same actor as the verifier.

Resolver

Software that performs DID resolution: given a DID, it returns the DID Document. A Universal Resolver routes many methods to method-specific drivers. Resolver choice is itself a trust decision.

Revocation / Suspension

Invalidating a previously issued credential — permanently (revocation) or temporarily (suspension) — before its natural expiry. The change is reflected through a status list that verifiers check via credentialStatus.

SD-JWT / SD-JWT-VC

Selective Disclosure JWT — a JWT variant that uses salted hashes (digests) so a holder can reveal only selected claims while the verifier checks each disclosed value against the signed digest. SD-JWT-VC is the Verifiable Credential format built on it. Supported by Identus. See disclosure and cnf.

secp256k1

An elliptic-curve key and signature algorithm (also used by Bitcoin and Cardano) supported by Identus for certain credential and status-list proofs.

Secret storage

The Cloud Agent’s configurable store for wallet seeds and private keys. A postgres backend stores secrets in plaintext (lab use only); a HashiCorp Vault backend is recommended for production.

Selective disclosure

A holder’s ability to reveal only the specific claims a verifier needs, rather than an entire credential — for example, proving “over 21” without revealing a full birth date. It depends on the credential format (SD-JWT and AnonCreds support it; plain JWT-VC does not) and supports the practice of data minimization.

Self-Sovereign Identity (SSI)

A model of digital identity built around user-held credentials and cryptographic proofs rather than a central identity provider. A subject receives a credential from an issuer, stores it as a holder, and presents proof to a verifier who checks it against its own policy. SSI changes the custody and exchange of identity data; governance, law, and reputation still shape trust.

Service endpoint

An entry in a DID Document advertising where and how to interact with the DID subject — for example, a DIDCommMessaging endpoint that names the URL, accepted DIDComm profile, and routing keys.

Status list

A published, space-efficient revocation mechanism (such as a Bitstring Status List / StatusList2021) in which each bit represents the revocation or suspension status of one credential. A verifier reads the bit referenced by a credential’s credentialStatus. In Identus this is provided by Pollux.

Subject

The person, organization, device, account, or thing that a credential’s claims describe. The subject is often the holder but need not be — a parent may hold a credential about a child, or a fleet manager about a device.

Tenant

A logical user or organization served by a Cloud Agent, represented by an entity and backed by an isolated wallet. See multi-tenancy.

ToIP (Trust over IP Foundation)

A Linux Foundation body developing standards for decentralized digital trust, including the ToIP Stack (a layered model of DIDs, DIDComm, data-exchange protocols, and application ecosystems) and the Trust Registry Query Protocol.

Triangle of Trust

A common way of describing the three SSI roles — issuer, holder, and verifier — and the credential/presentation flows between them. The roles are interaction-specific: the same entity can issue one credential, hold another, and verify a third.

TRQP (Trust Registry Query Protocol)

A ToIP read-only protocol for asking a Trust Registry whether an entity holds a given authorization under a given ecosystem’s governance — in plain terms, “Does entity X hold authorization Y under governance framework Z?” Sometimes described as “DNS for trust registries.”

Trust Registry

An authoritative, governed, machine-readable record of which entities are authorized to play which roles in an ecosystem. A verifier queries it to confirm an issuer’s authority — a separate question from the cryptographic validity of a credential. A Trust Registry is not a Certificate Authority and is not a VDR.

Trusted issuers

The set of issuer DIDs, usually scoped to a credential schema, that a verifier accepts as authoritative. In Identus this is configured today in a verification policy and is the concept a Trust Registry generalizes.

UMA (User-Managed Access)

An OAuth 2.0-based authorization standard that Keycloak uses to grant a subject permission to a specific Cloud Agent wallet resource, issuing a Requesting Party Token (RPT) the tenant presents to the agent.

Universal Resolver

A public resolver service able to resolve many different DID methods by routing each to a method-specific driver.

Validation

The verifier’s business-rule check on whether a credential is appropriate for a particular decision — for example, whether the issuer is acceptable under a hiring policy. Distinct from verification: a credential can be cryptographically valid yet fail validation.

Verifiable Credential (VC)

A set of claims made by an issuer, secured with a cryptographic mechanism so that software can detect tampering and confirm authorship. Defined by the W3C Verifiable Credentials Data Model. The data model is separate from the credential format (see JWT-VC, SD-JWT-VC, AnonCreds).

Verifiable Data Registry (VDR)

A system — often a blockchain, but potentially a database, distributed network, or in-memory store — against which DIDs and related data are published and resolved, so that independent parties can verify authenticity and integrity without a central authority. Identus accesses VDRs through pluggable drivers (for example, the PRISM Node and NeoPRISM drivers). A mediator is not a VDR.

Verifiable Presentation (VP)

Data derived from one or more Verifiable Credentials and shared with a specific verifier in response to a request. Depending on the credential format, a presentation can include a whole credential, parts of one (see selective disclosure), or data from several.

Verification

The technical check that a credential or presentation is cryptographically sound: valid signatures, correctly resolved issuer keys, proper key usage (verification relationships), current status, and holder binding. Distinct from validation, which applies business policy.

Verification method

An entry in a DID Document that specifies a public key (for example as a JWK), its type, and its controller. Verification methods are referenced by verification relationships for specific purposes.

Verification policy

The verifier-side configuration in Identus expressing which credential schemas and trusted issuers are accepted. Applied after cryptographic checks, it is the practical form of acceptance policy / validation.

Verification relationship

The association in a DID Document between a verification method and a permitted purpose — authentication, assertionMethod, keyAgreement, capabilityInvocation, or capabilityDelegation. These relationships prevent a key from being reused across proof purposes.

Verifier

The role that requests a presentation from a holder and decides whether to accept it, performing both verification (cryptographic checks) and validation (business policy). See also relying party.

Wallet

In SSI, software that stores and protects a party’s DIDs, keys, connections, and credentials, and that creates presentations. In the Identus Cloud Agent, a wallet is also the unit of tenant isolation. A holder’s wallet is usually an Edge Agent; a server-side wallet runs in a Cloud Agent. Distinct from a Cardano Wallet.

Wallet seed

The secret root key material from which a wallet deterministically derives its DID keys, via a stored derivation path. It is a high-value secret: losing it can permanently break the ability to use or update existing DIDs.

Webhook

The HTTP callback mechanism by which the Cloud Agent notifies a controller of state changes — a received connection, a credential issued or received, a presentation verified, and so on.

X25519

An elliptic-curve key type used for Diffie-Hellman key agreement to set up the encryption used by DIDComm. Appears in DID Documents under the keyAgreement relationship.

Zero-knowledge proof (ZKP)

A cryptographic technique that proves a statement is true without revealing the underlying data. The basis of AnonCreds predicate proofs such as “over 21” without disclosing a birth date.