Appearance
For Technical Decision-Makers
Looking for architecture, APIs, and component detail instead? See the Integration Overview for engineering teams.
What it is
Danube Business Wallet is a self-hosted platform that lets your organization issue, hold, and verify Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) — the building blocks of digital identity under the EU's eIDAS 2.0 regulation and the EUDI Wallet ecosystem it defines.
Rather than a single app, it's a full stack — issuer, holder/wallet, verifier, DID resolver/registrar, and credential revocation — deployed as one unit behind a single API and account model. It's built for organizations that need to stand up credential issuance, verification, or wallet capability themselves, on infrastructure they control.
Why this matters for eIDAS 2.0 / EUDI Wallet
eIDAS 2.0 requires every EU member state to offer citizens a Digital Identity Wallet, and requires large categories of private-sector relying parties to accept it. Organizations building toward this — whether as an issuer of attestations, a relying party that needs to verify wallet-presented credentials, or a wallet provider — need infrastructure that speaks the specific protocol profile the EUDI Wallet ecosystem has standardized on, not generic DID/VC tooling retrofitted after the fact.
Danube Business Wallet's issuer, holder, and verifier components are built to the OpenID4VC High Assurance Interoperability Profile (HAIP) from the ground up — the profile the EUDI Wallet is built on. It ships with a predefined PID (Person Identification Data) credential configuration and other eIDAS-aligned attestation types out of the box, so the protocol groundwork doesn't have to be built in-house.
Compliance & conformance status
| Standards alignment | Built to eIDAS 2.0 / EUDI Wallet architecture and the HAIP specification from the ground up (not retrofitted). |
| Interoperability testing | Danube Tech is actively pursuing interoperability testing with relevant ecosystem parties. |
| Formal certification | Not yet completed. The platform has not been through formal eIDAS 2.0 conformance certification or an official EUDI Wallet interoperability event. |
What this means for planning: treat Danube Business Wallet today as a platform architected for conformance, not a substitute for your own certification path. If your program has a hard certification or interoperability-event milestone, budget time for that process independently of adopting this platform, and track Danube Tech's certification progress as a dependency.
Deployment model: your infrastructure, your data
Danube Business Wallet is self-hosted — there is no managed/SaaS version to opt into instead. That's a deliberate control tradeoff, not a limitation:
- Runs entirely on infrastructure you operate, via Docker Compose. All application state lives in Postgres databases you control — no data leaves your environment as part of normal operation.
- You choose where cryptographic keys live. Key custody is a separate, swappable choice from the issuer/holder/verifier capabilities themselves:
- Built-in Wallet Service — simplest option, keys and DIDs managed end-to-end within your own deployment/database.
- HashiCorp Vault — bring your own Vault instance if your organization already standardizes on it for secrets management.
- Switching between the two is a configuration change, not a re-architecture. AWS KMS and Azure Key Vault are on the roadmap as additional options.
- Deployable as a full stack or a subset — organizations that only need, say, verification, or only DID resolution, can run just those components.
What's included
| Capability | What it does |
|---|---|
| Issuer | Issues Verifiable Credentials — direct server-to-server issuance, or wallet-driven issuance via OID4VCI. |
| Holder / Wallet Unit | HAIP-compliant wallet protocol logic — redeems credential offers, builds consent for presentation requests, stores received credentials. |
| Verifier | Verifies credentials and presentations — direct REST verification, or wallet-driven verification via OID4VP. |
| DID Resolver & Registrar | Resolves and manages DIDs across a broad set of methods (did:web, did:key, did:ebsi, did:cheqd, and more), so the same deployment can serve as general-purpose DID infrastructure. |
| Revocation | Status-list-based credential revocation. |
| DID history & analytics | Point-in-time DID resolution and full-text search across DID document history. |
Credentials are supported in the three formats the ecosystem actually uses: JSON-LD, VC-JWT, and SD-JWT (VC) — including dc+sd-jwt, the format HAIP mandates.
Governance & security posture
- Every API call is authenticated — API key or OAuth2 Client Credentials — with a scoped account/API-key model.
- Concerns are split into independent services (auth, profile, payment), each with its own datastore, rather than one monolithic store of organizational and credential data.
- New DID methods are added as independent driver containers, so extending method support doesn't require touching or re-certifying the core platform.
Where to go next
- Evaluating technical fit or planning integration? Hand your engineering team the Integration Overview — architecture, component breakdown, and API references.
- Want to see it running? Quickstart walks through authenticating and making a first resolve / issue / verify call.
- Checking DID method coverage? Supported DID Methods.
- Public docs: docs.danubewallet.com · API reference: api.danubewallet.com