> For the complete documentation index, see [llms.txt](https://docs.empe.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.empe.io/develop/wallet-server/terminology-and-concepts.md). # 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:`). This service works with `did:key` and `did:web`; see the [FAQ](/develop/wallet-server/faq.md#does-the-service-create-didempe-or-anchor-dids-on-a-blockchain) 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 `). 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.empe.io/develop/wallet-server/terminology-and-concepts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.