> For the complete documentation index, see [llms.txt](https://docs.nfh.global/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nfh.global/product-documentation/products/vc-on-edge/concepts.md).

# Concepts: VCs, DIDs, trust chains, revocation

Background for working with OpenCred — Verifiable Credentials, DIDs, trust chains, and revocation.

Background reading for anyone working with OpenCred. If you already know verifiable credentials, DIDs, and credential status, skip ahead to [Desktop](/product-documentation/products/vc-on-edge/desktop.md) or [Docker](/product-documentation/products/vc-on-edge/docker.md).

A typical OpenCred credential answers four questions for a verifier:

1. **Is the data intact?** — proven by the cryptographic **proof**.
2. **Whose key signed it?** — answered by resolving the **issuer DID**.
3. **Should I trust that key?** — answered by walking the **trust chain**.
4. **Is it still valid?** — answered by checking validity dates and **revocation status**.

OpenCred enforces all four during verification.

## Verifiable Credentials

A Verifiable Credential (VC) is a tamper-evident, cryptographically-signed set of claims about a subject (a person, business, agent, or asset), structured to the **W3C VC Data Model 2.0**. OpenCred supports multiple proof formats:

* **JSON-LD VCs** with embedded data-integrity proofs.
* **vc-jwt** — JWT-encoded credentials.
* **sd-jwt-vc** — selective-disclosure JWT credentials.
* **PixelPass / QR** compact encodings, and **printable PDF certificates** with an embedded QR plus a copy of the payload in the PDF info dictionary.

## DIDs (Decentralized Identifiers)

OpenCred uses three DID methods, each encoding the issuer's public key differently:

| Method    | What it is                                                                           | When to use                                                                                          |
| --------- | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- |
| `did:key` | Public key encoded directly in the identifier.                                       | Fully self-contained; **verifies offline**. Good for portable, no-infrastructure issuance.           |
| `did:jwk` | A JWK embedded in the identifier.                                                    | Like `did:key`, JWK-shaped.                                                                          |
| `did:web` | Resolves to a DID document hosted at `.well-known/did.json` on a domain you control. | When you want a stable, domain-anchored identity you can rotate. Requires network access to resolve. |

OpenCred also supports a **per-key registry model** (the OpenCred key registry) layered on [DeDi](https://docs.nfh.global/dedi), with a key lifecycle of **active / rotated / revoked** and a `did.json` snapshot stored on each key record.

## Trust chains

Trust chains explain how a verifier gets from a credential's signature back to a root anchor. OpenCred supports three issuer types:

| Issuer type                                           | How trust flows                                                                                                                             |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **Issuer with a DSC** (Digital Signature Certificate) | The credential carries an `x5c` certificate chain; the verifier walks it back to a CSCA root in a trust store on disk.                      |
| **Issuer seeking a DSC**                              | A transitional posture while CA integration for DSC acquisition is finalised.                                                               |
| **Self-published keys**                               | The issuer publishes its public key (via `did:web` or the DeDi key registry); trust is anchored in domain ownership or the registry record. |

## Revocation

OpenCred handles status through **DeDi-backed hash lookup**, and computes `credentialStatus` accordingly.

* **Key revocation vs per-credential revocation** are distinct. Revoking a key invalidates everything it signed; per-credential revocation targets a single credential.
* **The "no DeDi status available" case → the credential stays VALID.** If the status source cannot be reached, OpenCred does not fail closed into a false "revoked"; absence of a revocation record is not evidence of revocation.

## Where these live in the product

* DID resolution and proof verification run inside the shared `@opencred/verification` engine used by both the Desktop app and the Docker server.
* Revocation status is read from a DeDi **Revocation** registry — see [DeDi → schema templates](https://docs.nfh.global/dedi).

***

**Next:** [Desktop app](/product-documentation/products/vc-on-edge/desktop.md) · [Docker image & API](/product-documentation/products/vc-on-edge/docker.md) · [Verifying credentials](/product-documentation/products/vc-on-edge/verifying.md)


---

# 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.nfh.global/product-documentation/products/vc-on-edge/concepts.md?ask=<question>&goal=<user_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.