> 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/understand/self-sovereign-identity/protocols-and-standards.md). # Protocols and Standards Understanding the standards that Empeiria is built on helps you assess compatibility with existing systems and future-proofing for your organization. This section explains the key standards the platform implements and what they mean for your use case. ## Why Standards Matter Standards compliance matters for four practical reasons: **interoperability** (compliant systems work together without custom integration, easing vendor changes), **future-proofing** (established standards evolve with the ecosystem), **enterprise adoption** (large organizations typically require it), and **regulatory compliance** (many regulations reference specific technical standards). The success of SSI relies on interoperable protocols and standards. Key contributions include: 1. [**W3C DID Standard**](https://www.w3.org/TR/did-core/)**:** Defines how to create and manage globally unique, user-controlled identifiers independent of any centralized authority. 2. [**W3C Verifiable Credentials Data Model**](https://www.w3.org/TR/vc-data-model-2.0/)**:** Specifies the structure and format for Verifiable Credentials (VCs), including cryptographic signing and tamper-proof verification. 3. **Industry Initiatives and Working Groups:** Organizations like the [Decentralized Identity Foundation](https://identity.foundation/) and the [OpenID Foundation](https://openid.net/foundation/) work on best practices for SSI, fostering interoperability and innovation. Standards compatibility is the key to data interoperability. Empeiria enables data sharing across various data ecosystems and organizational adoption by adhering to the industry standards in the table below. ## Standards Compatibility The platform implements the following standards across identifiers, credential formats, issuance, and verification. | | Name | Standardizing Body | URL | | :---------------------------: | :--------------------------------------: | :----------------: | :---------------------------------------------------------------------------------------------------------------------------------------------: | | Data Model | VC, VP | W3C | [w3.org/TR/vc-data-model](https://www.w3.org/TR/vc-data-model) | | Entity Identifier | DID | W3C | [w3.org/TR/did-core](https://www.w3.org/TR/did-core/) | | Credential Format | SD-JWT VC | IETF (OAuth WG) | [datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc](https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/) | | Credential Format | Selective Disclosure JWT (SD-JWT) | IETF | [datatracker.ietf.org/doc/rfc9901](https://datatracker.ietf.org/doc/rfc9901/) | | Credential Format | JWT-VC | W3C | [w3.org/TR/vc-data-model/#json-web-token](https://www.w3.org/TR/vc-data-model/#json-web-token) | | Credential Format — Signature | JWS / EdDSA | IETF | [datatracker.ietf.org/doc/html/rfc7515](https://datatracker.ietf.org/doc/html/rfc7515) | | Issuance | OpenID4VCI | OIDF | [openid.net/specs/openid-4-verifiable-credential-issuance-1\_0.html](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html) | | Presentations | OpenID4VP | OIDF | [openid.net/specs/openid-4-verifiable-presentation-1\_0.html](https://openid.net/specs/openid-4-verifiable-presentation-1_0.html) | | Credential Query | DCQL | OIDF | [openid.net/specs/openid-4-verifiable-presentation-1\_0.html#name-dcql](https://openid.net/specs/openid-4-verifiable-presentation-1_0.html) | | Credential Query | Presentation Exchange v2 | DIF | [identity.foundation/presentation-exchange](https://identity.foundation/presentation-exchange/) | | Configuration/Binding | DID Configuration (served, not verified) | DIF / OIDF | [identity.foundation/.well-known/resources/did-configuration/](https://identity.foundation/.well-known/resources/did-configuration/) | | Data Format | JSON for Linking Data (JSON-LD) | W3C | [w3.org/TR/json-ld11/](https://www.w3.org/TR/json-ld11/) | ## What These Standards Mean in Practice ### Decentralized Identifiers (DIDs) DIDs are the cryptographically verifiable identifiers that issuers, verifiers, and holders use to identify themselves. The platform creates and manages two DID methods directly: * **`did:web`** — anchored to an HTTPS domain. The platform hosts the DID document itself and serves it at `//did.json`, so no external infrastructure is required. A `did:web` identifier looks like `did:web:issuer.example.com:`. * **`did:key`** — a self-contained identifier derived directly from an Ed25519 public key, useful for ephemeral or fully portable identities. A `did:key` identifier looks like `did:key:z6Mk...`. In addition to creating these methods, the platform can **resolve** `did:jwk` identifiers presented by other parties. Keys are Ed25519, and credentials are signed with **EdDSA (Ed25519)**. DID documents are created and served by the platform itself over HTTPS. ### Verifiable Credential Formats The platform issues and verifies two credential formats: * **SD-JWT VC** (`sd-jwt-vc` / `vc+sd-jwt`) — a privacy-preserving JWT format that supports **selective disclosure**. When a schema defines a disclosure frame, individual claims can be hidden by default and revealed only when the holder consents, so a verifier learns exactly what it needs and nothing more. This is the recommended format for most use cases. * **JWT-VC-JSON** (`jwt_vc_json`) — a JSON Web Token encoding of the W3C Verifiable Credentials data model, for interoperability with systems that expect the classic JWT-VC profile. A credential schema combined with a format produces a **credential configuration id** of the form `Name@Version:format`, for example `EmployeeBadge@1.0:sd-jwt`. This identifier is what credential offers reference. ### Issuance with OpenID4VCI Credentials are issued using the **OpenID for Verifiable Credential Issuance (OpenID4VCI)** protocol with the **pre-authorized code flow**, optionally protected by a transaction PIN. The issuer publishes its issuer metadata document at `GET /agent/issuer/:did/.well-known/did-configuration`, and offers are delivered to wallets as `openid-credential-offer://` URIs or QR codes. ### Presentation with OpenID4VP Credential presentation uses the **OpenID for Verifiable Presentations (OpenID4VP)** protocol. The platform supports multiple draft profiles (`v1`, `v1.draft21`, `v1.draft24`) and several response modes, including `direct_post`, `direct_post.jwt`, and the **Digital Credentials API** modes (`dc_api`, `dc_api.jwt`). To describe which credentials a verifier wants, you can use either of two complementary query languages: * **DCQL (Digital Credentials Query Language)** — the OpenID4VP-native query format. * **DIF Presentation Exchange v2** — the Decentralized Identity Foundation's presentation definition format. Each authorization request supplies exactly one of these queries. ### DID Configuration The platform publishes a DID configuration / issuer metadata document so wallets and verifiers can discover an issuer's metadata. This document is **served** by the platform; it does not perform domain-linkage verification of credentials it receives. ## Standards Not Currently Implemented To set accurate expectations for compatibility planning, the following are **not** part of the platform's current capabilities: * **Credential revocation / status lists** — there is no on-chain or Bitstring Status List revocation mechanism in the issuance and verification service today. * **SIOPv2** — Self-Issued OpenID Provider v2 is not currently implemented. * **DIDComm messaging** — there is no DIDComm message endpoint exposed by the service. --- # 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/understand/self-sovereign-identity/protocols-and-standards.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.