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:
W3C DID Standard: Defines how to create and manage globally unique, user-controlled identifiers independent of any centralized authority.
W3C Verifiable Credentials Data Model: Specifies the structure and format for Verifiable Credentials (VCs), including cryptographic signing and tamper-proof verification.
Industry Initiatives and Working Groups: Organizations like the Decentralized Identity Foundation and the OpenID 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.
Configuration/Binding
DID Configuration (served, not verified)
DIF / OIDF
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/<uuid>/did.json, so no external infrastructure is required. Adid:webidentifier looks likedid:web:issuer.example.com:<uuid>.did:key— a self-contained identifier derived directly from an Ed25519 public key, useful for ephemeral or fully portable identities. Adid:keyidentifier looks likedid: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 [email protected]: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.
Last updated