Credentials & Trust
VDX manages the full credential lifecycle, from schema design through issuance, wallet storage, selective disclosure presentation, and verification against trusted issuers. Organizations control every aspect: what credentials they issue, who can verify them, which trust frameworks govern the process, and how credentials integrate with their authorization infrastructure.
Use the EDK Credentials, status, and trust learning path for the implementation-level decision matrix, runnable profile walkthroughs, OpenAPI references, Postman collection, Admin Console paths, and fail-closed verification checklist. For the task-by-task developer route, start with the EDK developer journeys: platform foundations, then credential issuance and credential verification, each split into small journeys whose first step reads the data it is about to change.
Semantic Modeling
VDX provides a governed four-layer model that keeps business meaning separate from protocol-specific credential shapes:
| Layer | Purpose |
|---|---|
| Data Domain | Defines object types, business terms, relationship types, governance overlays, schema relationships, and authoritative grounding |
| Object Model | Composes roles from published data domains and applies narrow-only constraints for a business context |
| Data Product | Selects the exact governed terms required for one issuance, verification, form, document, or API scenario |
| Channel | Maps a data product to a concrete form, document, verifiable credential, OID4VCI configuration, or API payload |
Business terms can record their source, a pinned legal-source reference, the retrieval date, and a grounding kind. Entry-code schemes distinguish enumerations, reference lists, and code lists. Governed obligations distinguish obligations, requirements, and criteria.
Issuer credential designs and verifier DCQL queries can be projected from the same published channels. That keeps format-specific claim paths synchronized while preserving the data product's constraints and records usage lineage for the terms consumed by each artifact.
The complete authoring and projection surface requires the semantic-modeling.v1 feature and is available through /api/model/v1. VDX also provides POST /api/model/v1/data-products/lightweight for the focused lightweight workflow under semantic-modeling-lite.v1.
Credential Design & Issuance
The Credential Designer is a visual tool for defining credential schemas. Administrators specify which claims to include, which are mandatory, which support selective disclosure, and what display metadata (names, descriptions, icons, colors) wallets should present to users. No code required, schemas are defined through the admin portal and published as OID4VCI credential configurations.
Issuer Management handles the operational side. Each issuer has its own DID, signing keys, and issuance policies. Multiple issuers can operate within a single tenant, useful when different departments issue different credential types. The platform tracks the full credential lifecycle: issuance events, usage, expiration, and revocation.
Choose the credential, status, and trust profile
| Credential profile | OID4VC format | Documented status lane | Trust material to configure |
|---|---|---|---|
| SD-JWT VC | dc+sd-jwt | JWT Token Status List | DID/JWK or X.509 evidence in the applicable trust domain |
| mDL / mdoc | mso_mdoc | CWT Token Status List | DSC/IACA certificate chain; optional VICAL as a separate mdoc trust artifact |
| W3C VCDM 1.1 | jwt_vc_json | Bitstring Status List | DID/JWK or X.509 evidence in the applicable trust domain |
| W3C VCDM 2.0 | jwt_vc_json-ld | Bitstring Status List | DID/JWK or X.509 evidence in the applicable trust domain |
Each format has its own wire identifier and claim paths. A verifier can combine separate format-specific credential queries in one DCQL request, but an mdoc is not automatically interchangeable with an SD-JWT or W3C credential.
- Profile-by-profile status and issuance walkthroughs
- Azure KMS, BYOK, and BYOC
- mDoc VICAL and CWT status
Verification
The Verifier Management console defines what credentials your organization accepts. Verification requirements are configured per resource or service:
- A building entrance requires a student credential from a specific university
- A financial service requires a government-issued PID with eIDAS
highassurance - A conference registration accepts any of three credential types from trusted issuers
Requirements can be composed: "present A AND B" or "present A OR B." The platform supports DCQL (Digital Credentials Query Language) for complex credential set matching where multiple credentials from different issuers are evaluated together.
Verification works in two modes:
Online: real-time OID4VP flow with QR code or deep link. The user presents credentials from their wallet, and the platform verifies signatures, holder binding, issuer trust, and credential status in real time.
Offline: signature validation against cached trust material. For environments without reliable connectivity (kiosks, border control, field verification), the platform validates cryptographic signatures locally using pre-fetched trusted issuer keys.
Credential status is a separate decision from signature and trust validation. The verifier must resolve the status reference using the matching JWT, CWT, or W3C status-list representation and fail closed when required material is expired, malformed, unavailable, signed by the wrong issuer, or served with the wrong media type.
Trust Establishment
Credentials are only as valuable as your trust in the issuer. VDX supports multiple trust frameworks, configurable per tenant:
| Framework | What it provides |
|---|---|
| ETSI TS 119 612 / TS 119 602 | Distinct trust-list profiles and signed trust-source snapshots; configure and evaluate only the profile implemented for the integration |
| OpenID Federation | Trust chain resolution for federated identity ecosystems |
| DID-based trust | Configurable trusted issuer DID lists per credential type and tenant |
| X.509 PKI | Certificate chain validation with CA bundles and fingerprint matching |
| ISO mdoc VICAL | Signed CBOR/COSE list used to admit mdoc document-signing authorities; separate from ETSI trust lists and credential status |
Trust configuration is tenant-scoped, each organization defines which issuers they trust for which credential types, without affecting other tenants on the same platform.
See Trust domains for attachment resolution, admission classes, ETSI trust sources, and the separate VICAL configuration path. A configured key, valid DSC, ETSI list, VICAL, or status list proves only its own part of the verification decision.
Device & Kiosk Verification
VDX extends credential verification to physical devices: reception kiosks, access terminals, event check-in tablets, and NFC readers.
The Mobile RP SDK enables building relying party experiences on mobile devices. NFC proximity verification supports ISO 18013-5 flows for mDL and other mdoc credentials. Devices can operate in online mode (connected to VDX) or offline mode (validating locally against cached trust material).
Device Management tracks which devices are authorized, their last-known status, firmware versions, and which verification policies apply to each device or device group. Push verification initiates the flow from the device, a reception kiosk starts the verification when it detects a visitor, rather than waiting for the user to trigger it.
Authorization Server
The VDX Security Token Service (STS) integrates credential-based authentication with standard OAuth2/OIDC infrastructure.
RFC 8693 Token Exchange: tokens from any authentication source (wallet VP, institutional OIDC, Azure AD, Keycloak) are exchanged for uniform STS tokens with standardized claims. Enterprise applications keep using standard OIDC tokens, no code changes needed.
Identity Broker: connects upstream OIDC providers while maintaining control over token issuance. Unlike direct federation, the broker preserves issuer_state for OID4VCI correlation, which is critical for credential issuance flows that span multiple authentication steps.
Claims Mapping: translates between credential formats and OIDC claims output, with provenance tracking that records which credentials contributed each claim. Output includes verified_claims structure per OIDC Identity Assurance, downstream consumers know what was verified, how, and to what assurance level.