Ship digital identity wallet solutions fast and with ease.

Credential Formats

SD-JWT VC (dc+sd-jwt), W3C VC as JWT (jwt_vc_json), ISO/IEC 18013-5 mdoc (mso_mdoc), and ISO/IEC 23220.

W3C VC JSON-LD

Linked-data credentials using ldp_vc. Current Issuer2, Verifier2, and Wallet2 stacks reject this format.

Protocols

OID4VCI 1.0 and OID4VP 1.0 with pre-authorized and authorization-code flows; ISO-18013-7 for mDL / mdoc remote flows. Deprecated Wallet v1 still covers earlier drafts.

Status Credential Formats

TokenStatusList (incl. draft 8), Bitstring Status List v1.0, StatusList2021, RevocationList2020

Digital Credentials API

Unified browser API for credential issuance/verification; abstracts OID4VCI/VP & ISO-18013-7 for 1-click web integrations.

Same-device remote flow

User stays on one device for issuance or presentation, typically via redirect or in-app handover.

Cross-device remote flow

QR code or companion-device handover for issuance and remote presentation.

Proximity presentation

In-person credential share over BLE or NFC, including ISO/IEC 18013-5 proximity flows.

Selective disclosure

Only requested claims leave the wallet, using SD-JWT disclosures or mdoc namespaces.

Signed request object (JAR)

Wallet authenticates the verifier from a signed request object before showing consent.

Request by reference

Wallet fetches the presentation request from request_uri over HTTPS, including GET and POST retrieval.

X.509 verifier identity

Verifier identity from certificate-bound client identifiers, including x509_hash and x509_san_dns.

Posted / encrypted presentation responses

Authorization responses posted to response_uri as direct_post or encrypted direct_post.jwt.

Pushed Authorization Requests

Authorization parameters stay off the front channel via PAR during issuance.

PKCE (S256)

Public wallet clients bind the authorization code with S256 so it cannot be replayed.

DPoP

Access tokens are bound to the wallet key during issuance.

Wallet / client attestation

Issuer can accept only attested wallet software; wallets can send attestation headers.

Key attestation

Issuer can require hardware-backed or attested holder keys on the credential proof.

Signed and unsigned issuer metadata

Wallets consume unsigned HTTPS issuer metadata and can verify signed JWT issuer metadata.

Encrypted credential request

Wallet encrypts the credential request so the issuer receives it as JWE.

Encrypted credential response

Issuer encrypts the issued credential; the wallet must request and decrypt the JWE.

OID4VCI notification endpoint

Wallet reports accepted, failed, or deleted credentials to the issuer notification endpoint.

Present-to-obtain

Holder presents an existing credential before a new one is issued.

Nonce endpoint

Fresh c_nonce for proofs during OpenID4VCI issuance.

Key Management (KMS-agnostic)

Use external KMS (AWS, Azure, Hashicorp, Oracle, …), PKCS#11 HSMs, or raw keys for PoCs; supports ed25519, secp256r1/k1, RSA and key rotation.

DIDs & Identifiers

Supports did:key, did:jwk, did:web (and others) plus x509 certificates;

Webhooks / Callbacks

Notify or mirror lifecycle events (e.g., issuance, verification) into external systems for orchestration and audit.

Wallet-initiated issuance

Wallet starts issuance from issuer metadata or a catalog, without first receiving an offer.

Scope-based credential request

Wallet asks for a credential using the issuer-published scope.

Deferred issuance

Issuer returns a transaction id and the wallet polls later for the credential.

Batch issuance

Several credentials or keys in one credential request.

Combined offer or request

PID plus mDL, or the same document in two formats, in one offer or presentation request.

Automatic holder binding & proof-of-key

PoP and holder-binding during issuance/presentation per OID4VCI/VP so issuers/verifiers can trust key control.

One-user-one-wallet consumer model

Custodial, stateful wallet with built-in user auth.

One-user-multi-wallet model

Flexible user↔wallet mapping with multi-tenant support (shared or individual wallets).

Username/password auth for wallet users

Built-in email/password login and session management for wallet users.

External IdP (OIDC) for wallet users

Integrate external OIDC IdPs for wallet user login.

Local credential storage

Custodial credential storage in wallet DB with list/import/delete APIs.

Hardware-backed keys

Holder keys stay in platform keystore or Secure Enclave on the device.

Transaction log

Holder can review past issuance and presentation events.

Backup and restore

Attestations can be recovered onto the same wallet product.

Move to another wallet

Attestations can be migrated to a different wallet product.

Wallet-to-wallet share

Two holders share an attestation in proximity.

Request deletion from a relying party

Holder can ask a previous verifier to delete received data.

Report a suspicious request

Holder can report an unlawful presentation request to a data-protection authority.

Pseudonyms / passkeys

Wallet can authenticate without releasing identity attributes.

Zero-knowledge proofs

Presentations that do not disclose the underlying attribute.

Wallet instance revocation

A compromised wallet unit can be withdrawn.

Credential status validation

Check stored credentials for revocation/status (e.g., Bitstring Status List).

Host did:web Documents

Serve and auto-update did:web documents directly from the platform.

DID Document Storage

Persist DIDs and DID documents via internal / enterprise DID store.

X.509 PKI Issuance

Issues IACA root and Document Signer certificates.

External KMS

Integrate AWS, Azure, Hashicorp, PKCS#11 HSMs; supports ed25519, secp256r1/k1, RSA with rotation.

Trust Registries

Check parties against configured trust sources such as VICAL or authority key identifiers.

QTSPs

Qualified signature support via QTSPs.

EMEA alignment

Aligned with EU eIDAS2, EBSI and Swiss SWIYU requirements.

APAC alignment

Aligned with NZ DISTF, Australia, Thailand, Japan, etc.

Americas alignment

Aligned with US, Canada, Brazil frameworks.

Custom ecosystems

Adaptable to other/local ID ecosystems.

On-Prem / Self-Hosting

Self-hosting in your own cloud or data center — no managed SaaS

Multi-tenancy setups

Isolated wallet configurations for B2B/B2G/B2B2C use cases

Clustering / horizontal scaling

Run multiple enterprise stack instances behind a load balancer with shared state (sessions, configs, etc.)

API Data Persistence

Persisted wallet data across service restarts and deployments.

Data Encryption

Encrypt sensitive data at rest in the database.

Protected APIs (AuthN/Z)

Fine-grained protection of APIs with scoped tokens per tenant/service.

Roles & permissions (RBAC)

Granular roles for orgs/tenants/services following least-privilege principle; Supports importing and mapping roles from an external IdP's.

API keys (server-to-server)

Scoped M2M API keys for backend/service integrations.

Audit logging

Recorded logs and events for auditing and compliance.

Analytics & metrics

Track operations, success/error rates across tenants/services for ops and reporting.

User accounts (operators/admins)

Admin GUI logins with role-based permissions.

Admin GUI

Configure services, monitor sessions, and manage credential lifecycle operations (e.g. revocation) or verification states.