Danube Wallet Docs

Appearance

Integration Overview ​

Looking for a business/compliance-level summary instead? See For Technical Decision-Makers.

Danube Business Wallet is a self-hosted platform for issuing, holding, and verifying Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) for organizations. It combines DID resolution, DID registration, credential issuance, credential verification, revocation, key management, and DID-versioning into one deployable stack, exposed behind a single API gateway and account/API-key model.

Built for the EU's eIDAS 2.0 / EUDI Wallet ecosystem: the issuer, holder, and verifier components implement the OpenID4VC High Assurance Interoperability Profile (HAIP) — the protocol profile the EUDI Wallet is built on — end to end, including wallet attestation, PKCE, PAR, and dc+sd-jwt. The issuer ships with a predefined PID (Person Identification Data, urn:eu.europa.ec.eudi:pid:1) credential configuration alongside other eIDAS-aligned attestation types, so an organization can stand up a HAIP-compliant issuer, holder, and verifier for EUDI Wallet-style credentials out of the box.

The stack is built to the eIDAS 2.0 / EUDI Wallet architecture and the HAIP specification from the ground up, rather than retrofitted onto an existing system — and Danube Tech is actively pursuing interoperability testing with relevant ecosystem parties to validate that alignment. It has not yet been through formal eIDAS 2.0 conformance certification or an official EUDI Wallet interoperability event.

Supported Credential Formats ​

FormatDescriptionSupported by
JSON-LDLinked-data Verifiable Credentials, signed with e.g. Ed25519Signature2020Universal Issuer, Universal Verifier
VC-JWTVerifiable Credentials encoded as JWTsUniversal Issuer, Universal Verifier
SD-JWT (VC)Selective-disclosure JWT credentialsUniversal Issuer, Universal Verifier

Core Capabilities ​

Issuer — Universal Issuer ​

  • Issues Verifiable Credentials via a common REST interface, in JSON-LD, VC-JWT, or SD-JWT.
  • Standard issuance: direct, server-to-server issuance via REST API — no prior configuration required.
  • OID4VCI issuance: wallet-driven issuance using OpenID for Verifiable Credential Issuance, after registering credentialConfigurations (schema, signing keys, format) via the Issuer Configuration API.
  • Works with the Revocation Service for status-list-based revocation.

Holder / Wallet Unit ​

The OID4VCI + OID4VP protocol behavior that makes the Danube Business Wallet act as a real HAIP-compliant holder, not just an issuer/verifier/resolver stack. This is business/protocol logic — it holds no keys itself and consumes the Key Management layer below for that.

  • Credential issuance (client side / OID4VCI) — redeems a credential offer from any OID4VCI-compliant issuer: pre-authorized-code flow (with optional tx_code/PIN) and authorization-code flow (with PKCE, browser redirect to an external IdP, and callback handling), including deferred-credential polling.
  • Credential presentation (client side / OID4VP) — consumes an OID4VP authorization request from any verifier, builds a consent screen from the requested credential/claim query (DCQL-style — mandatory vs. optional claims, required vs. skippable credentials), and returns the presentation via direct_post or redirect.
  • Credential store — holds received credentials and exposes them for listing/filtering by type.
  • HAIP-compliant by design — see HAIP Compliance below.

HAIP Compliance ​

The OID4VC Holder Service implements the OpenID4VC High Assurance Interoperability Profile (HAIP), the profile the EUDI Wallet ecosystem (and eIDAS 2.0 conformant wallets) is built on:

  • Wallet attestation — presents a two-part OAuth client attestation (oauth-client-attestation+jwt) per HAIP §4.4: a Danube Tech-signed Part 1 binding the wallet's identity (sub) to a cnf.jwk public key (ES256, x5c certificate chain in the JOSE header), plus a fresh, endpoint-bound Part 2 proof-of-possession JWT signed per request with the corresponding private key held in the Key Management layer (default backend is HashiCorp Vault directly, per this service's own configuration — see CONFIGURATION.md).
  • Authorization-code flow with PKCE (S256) and preference for Pushed Authorization Requests (PAR) when the issuer supports it.
  • dc+sd-jwt / SD-JWT VC as a first-class credential format, alongside jwt_vc_json and ldp_vc.
  • Matching HAIP support on the issuer and verifier sides of the same stack (see below), so the whole issue → hold → present chain can run as a single interoperable profile.

Verifier — Universal Verifier ​

  • Verifies Verifiable Credentials and Verifiable Presentations via a common REST interface, for JSON-LD, JWT, and SD-JWT.
  • Standard verification: direct REST call, checks authenticity, status, and schema compliance.
  • OID4VP verification: interactive, wallet-driven presentation flow using OpenID for Verifiable Presentations, after one-time setup via the Verifier Configuration API.

Key Management ​

Key custody is deliberately not part of the Issuer / Holder / Verifier capabilities above — it's a separate choice you make per deployment: where should your organization's cryptographic keys actually live? Two options are available today, and both work identically from the outside — the Issuer, Holder, and Verifier capabilities behave the same regardless of which one you pick.

Option 1 — Wallet ServiceOption 2 — HashiCorp Vault
What it isWallet Service — built-in key/DID storage, run as part of your deploymentBring-your-own HashiCorp Vault instance
Where keys liveIn your deployment's own database, managed end-to-end by the Danube Business WalletIn Vault, under your organization's existing secrets management
Best forSimplest setup — nothing extra to run or trustOrganizations that already standardize on Vault for secrets/key management

Switching between the two is a configuration choice, not a rewrite — nothing about how you use the Issuer, Holder, or Verifier changes.

Extensible by design — more options coming soon:

  • 🔜 AWS KMS — coming soon
  • 🔜 Azure Key Vault — coming soon

Platform Features ​

  • Identity infrastructure, not just a wallet app — the platform also ships a Universal Resolver (DID resolution) and Universal Registrar (DID create/update/deactivate), so the same deployment can act as general-purpose DID infrastructure, not only credential issuance/verification for one organization.
  • Broad DID method interoperability — resolver and registrar drivers for did:key, did:jwk, did:web, did:ebsi, did:cheqd, did:ethr, did:pkh, did:v1, did:webvh, and more. Full matrix: Supported DID Methods.
  • Pluggable key custody — see Key Management: choose Wallet Service or HashiCorp Vault today, with AWS KMS and Azure Key Vault coming soon.
  • DID history & analytics — the Version Service tracks every version of every DID document per method, supports point-in-time resolution (versionTime), and full-text search over DIDs and DID document contents.
  • Credential revocation — the Revocation Service supports StatusList2021 mechanisms.
  • Driver-based extensibility — new DID methods are added as independent driver containers behind the resolver/registrar gateway, without touching the core services.
  • Unified API surface — every component is reachable through one API gateway (http://localhost:21080/1.0.0/), documented in a single OpenAPI Spec and browsable via the bundled Scalar reference UI (:21082).

Governance, Security & Operations ​

  • Authentication: every API call requires either
    • an API key (Authorization: Bearer <api-key>), or
    • an OAuth2 Client Credentials token, obtained from the Auth Service (/oauth2/token) using the account ID as client_id and a client secret.
  • Account model: auth-service owns accounts and API keys (scopes such as * or oauth2:secret:*); profile-service owns organization profile and product metadata per account.
  • Dedicated services per concern: auth, profile, and payment are split into independent services (auth-service, profile-service, payment-service), each with its own datastore.

Deployment Options ​

ModelDescription
Self-hosted (Docker Compose)The model documented in this repository: pull versioned images from the Danube Tech registry and run the full stack (or a subset, via docker-compose.override.yml) with docker compose up. All state lives in Postgres containers you control.

Component Architecture ​

ComponentRoleDefault port
Business Wallet frontendAccount dashboard UI21081
Business Wallet (gateway)Unified API gateway21080
Auth ServiceAccounts, API keys, OAuth218080
Profile ServiceOrganization profile & products19080
Payment ServicePayment/product transactions20080
Universal ResolverDID resolution8080
Universal RegistrarDID create/update/deactivate9080
Wallet ServiceKey/DID storage, sign/verify — one of two key-management options today (see Key Management); the other is HashiCorp Vault12080
Universal IssuerVC issuance13080
Universal Issuer OID4VCIHAIP-capable OID4VCI issuance endpoint13081
Universal VerifierVC/VP verification14080
Universal Verifier OID4VPHAIP-capable OID4VP verification endpoint14081
OID4VC Holder ServiceHAIP-compliant holder/wallet backend (credential offer redemption, presentation consent, credential store) — not yet wired into this compose stack18080 (default)
Revocation ServiceCredential status/revocation16080
Version ServiceDID history, search, analytics10080
Scalar API reference UIInteractive API docs21082

(A simple architecture diagram belongs here — see the iGrant reference for the visual style: gateway in the center, Issuer/Wallet/Verifier around it, Resolver/Registrar/Version/Revocation as supporting infrastructure.)

Getting Started ​