Terminology and Concepts

This page defines the core terms used throughout the Wallet Server documentation. The audience is assumed to know HTTP APIs, JWTs, and cryptography basics, but not necessarily Self-Sovereign Identity.

Self-Sovereign Identity (SSI) A model of digital identity in which control of identifiers and credentials belongs to the subject rather than a central provider. Credentials are issued, held, and presented under the holder's control.

Decentralized Identifier (DID) A globally unique, cryptographically verifiable identifier that resolves to a DID Document. The Wallet Server creates and uses two DID methods:

• did:key — a self-contained method derived from an Ed25519 public key (did:key:z6Mk...). No hosting is required.

• did:web — a method whose DID Document is hosted over HTTPS at a path the service controls (did:web:issuer.example.com:<uuid>).

This service works with did:key and did:web; see the FAQ for how this relates to the did:empe method of the wider Empeiria ecosystem.

DID Document The JSON document that a DID resolves to. It contains the verification methods (public keys), services, and controller information used to verify signatures made by the DID subject. For did:web, the service hosts this document itself and serves it over HTTPS.

Verifiable Credential (VC) A cryptographically signed set of claims that an issuer asserts about a subject (for example, that an employee belongs to a department). A VC can be verified offline using the issuer's DID Document.

Holder Tenant (holderId) The unit of wallet isolation. Each holder is a per-user cloud-wallet tenant identified by a holderId (a UUID) and owned by an authenticated OIDC user. A holder has its own DID and its own stored credentials. Ownership is enforced, so a user can only access the holders they own. Wallet data is partitioned per holder, not directly by the JWT sub.

Credential Offer URI (OpenID4VCI) The input a holder consumes to receive a credential. An issuer creates an offer and returns an openid-credential-offer://... URI (often encoded as a QR code). The holder submits the URI, and the wallet requests the offered credential(s) and stores them in that single operation — no separate multi-step "claim flow" object is involved.

Authorization Request URI (OpenID4VP) The input a holder consumes to present credentials. A verifier creates a request and returns an openid4vp://... URI (or an HTTPS authorization request, often encoded as a QR code). When a holder processes this URI, the wallet selects the matching credential(s) — using DCQL or DIF Presentation Exchange — and sends the presentation back to the verifier in a single operation.

OpenID4VCI The protocol the Wallet Server speaks to issue credentials into a holder. Issuance uses the pre-authorized code flow, with an optional PIN for additional binding.

OpenID4VP The protocol the Wallet Server speaks to request and verify presentations from a holder.

SD-JWT (Selective Disclosure) An SD-JWT VC (vc+sd-jwt) is a credential format in which individual claims can be selectively disclosed. The issuer marks which claims are selectively disclosable when the credential is created; at presentation time the holder discloses only the claims a verifier needs, keeping the rest private. A credential configuration referencing this format looks like EmployeeBadge@1:sd-jwt.

JWT-VC-JSON A credential format (jwt-vc-json) in which the credential is a JWT carrying the full claim set. Unlike SD-JWT, it does not support per-claim selective disclosure; the whole credential is presented.

Tenant Scoping Every non-public request is evaluated in the context of the authenticated OIDC user (a valid Authorization: Bearer <token>). Holder and wallet operations are additionally scoped to a specific holder tenant owned by that user, so data is isolated per holder. In local development, AUTH_DISABLED=true treats every request as an authenticated user.

Cryptographic Binding Method The DID method a holder uses to bind a received credential to its key. A holder is created with a did:key or did:web identifier, but it advertises support for binding via did:key, did:jwk, and did:web (the cryptographicBindingMethodsSupported it returns at creation). Binding is what ties an issued credential to the holder's controlled key.