> For the complete documentation index, see [llms.txt](https://docs.toolkit.equs.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.toolkit.equs.ai/docs/about-the-system/concepts.md). # Concepts The core ideas behind decentralized identity: verifiable credentials, issuers, holders and verifiers, and how trust, revocation and delegation work. New to decentralized identity? Start here 🧭. \ \ This page is the five-minute version. Services often need verified facts about the people who use them: that someone passed an identity check, holds a qualification, or meets an eligibility rule. Collecting that information is costly, and holding it afterwards carries compliance risk. Decentralized identity moves the data to the user. An issuer signs a claim once. The user keeps it in a digital identity wallet and presents it wherever it's needed. A verifier checks the signature instead of calling the issuer back. You can rely on the data without having stored or re-verified it yourself.

### Credentials and identifiers 🪪 A **verifiable credential** is a set of claims about a subject, signed by the issuer so that anyone can check the claims haven't been altered. A driver's license, a diploma, and a completed identity check are all good examples of credentials. The platform issues credentials in the **SD-JWT VC** format, which builds on JSON Web Tokens and adds selective disclosure. A holder can present their date of birth without revealing their address, or prove they are over eighteen without revealing either. To check a signature, a verifier needs the issuer's public key and a reliable way to tell whose key it is. Credentials rely on one of two mechanisms for that: * A **Decentralized Identifier (DID)** is a URI that resolves to a document (DID Document) of public keys and service endpoints, with no central registry or identity provider required. The method name in a DID's prefix determines how that identifier is created and resolved. * An **X.509 certificate** binds a public key to a named organization and is itself signed by a certificate authority. The credential carries the issuer's certificate chain, and a verifier checks that the chain leads to a root it trusts. This is the model the EU Digital Identity ecosystem uses, most notably for the **Person Identification Data (PID)**: the credential that establishes a person's identity, a digital counterpart of the national identity card. The Issuers you create on the Developer Toolkit are identified initially by `did:web`, with X.509 and other DID methods coming soon. As a Verifier, you can accept credentials signed under either model. ### The credential lifecycle ♻️ Three operations make up a credential's life. You issue a credential once, the holder presents it as many times as they need, and you revoke it if the facts behind it stop being true.

* [**Issuance**](/docs/issuance/overview.md)**:** An issuer signs a credential and delivers it to the holder's wallet. From then on the holder carries it: the platform keeps no copy, and the issuer doesn't need to be online when it's used. * [**Presentation**](/docs/presentation/overview.md)**:** A verifier requests proof, and the holder responds with the claims they choose to disclose, along with a key binding proof that they control the credential. The verifier checks the issuer's signature, the key binding, and the credential's status. The verifier can be you, or any party that trusts the issuer, even one you've never integrated with. * [**Revocation**](/docs/revocation/overview.md)**:** An issuer marks a credential as no longer valid, and verifiers see the change on their next status check. A signature stays valid forever and a credential can't be deleted from the holder's wallet, so revocation is how it stops being trusted before it expires. ### Where trust comes from 🔐

A verifier trusts a credential because it can resolve the issuer's identifier, retrieve the issuer's public key, and check the signature against it. No call to the issuer is involved, which is what makes verification work offline and at scale. How far you can trust that resolution depends on how the issuer is identified. With `did:web`, the identifier resolves over HTTPS to a document hosted on the issuer's domain, so trust in the credential follows from trust that the issuer controls that domain. With X.509 certificates, trust follows the chain: a credential is trusted when the issuer's certificate chains to a root the verifier has decided to accept. Choosing those roots is the real trust decision, and in a regulated ecosystem it isn't left to each verifier. \ \ Under eIDAS 2.0, Member States notify the providers they have approved, such as PID providers, wallet providers and access certificate authorities, and these are published in **trusted lists** along with their certificates. EUDI verifiers take their roots from those lists. On the platform, you set the roots each Verifier accepts. Checking revocation doesn't mean asking the issuer about a particular credential. The issuer publishes the status of all its credentials as a **Token Status List**: a compressed list where each credential occupies one index. A verifier fetches the whole list and reads the index for its credential, so the issuer never learns which credential was checked or when. ### Schemas 📐 The platform describes credentials with two schemas of its own: * A [**VC Schema**](/docs/issuance/configuration-issuer-and-vc-schema.md) defines a credential type you issue: its claims and the Issuers that can issue it. Wallets see it as a standard OID4VCI credential configuration. * A [**VP Schema**](/docs/presentation/configuration.md) defines what you ask for in a Presentation: which credentials, whether yours or issued elsewhere, and which claims from them. Wallets see it as a standard DCQL query in the OID4VP request. ### Delegation and mandates 🤝 * [**Delegation**](/docs/agentic/delegation.md) lets a holder authorize another party, usually an AI agent, to act on a credential they hold, within limits they set. It's built on **dSD-JWT**, a delegated SD-JWT, and doesn't involve the issuer. * An [**AP2 mandate**](/docs/agentic/ap2.md) is a delegation for payments, defined by the Agent Payments Protocol: the user approves what an agent may buy, and the agent can prove it to a merchant. ### EU Digital Identity (eIDAS 2.0) If you accept credentials from EUDI Wallets, you'll come across a few terms specific to the EU framework:

Term	Meaning
eIDAS 2.0	Regulation (EU) 2024/1183, which establishes the European Digital Identity framework.
EUDI Wallet	The European Digital Identity Wallet that each Member State must offer its citizens.
PID	Person Identification Data: the credential that establishes a person's identity in the EU Digital Identity ecosystem, a digital counterpart of the national identity card. It holds core attributes such as family name, given names, date of birth, place of birth and nationality. A PID provider approved by the Member State issues it into the holder's EUDI Wallet and signs it with X.509 certificates rather than a DID, so verifiers trust it through the certificate chain.
Relying party	eIDAS's term for a verifier.
Trusted list	A published list of approved providers and their certificates. Verifiers take their trust anchors from it.
Access certificate	The X.509 certificate a relying party signs its presentation requests with, so the wallet can tell who is asking.
Registration certificate	Issued by the national Registrar where you're established, stating what you're registered to ask for.
Intended use	One registered purpose, backed by its own registration certificate. Each presentation request names the intended use it's made under.

--- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.toolkit.equs.ai/docs/about-the-system/concepts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.