Identity, programmable
The OID4VP gateway for your verifiable credentials.
Accept SD-JWT and mDoc credentials from any wallet. Cryptographically verify the issuer, enforce selective disclosure, and get verified claims back via webhook — with six production-ready demos proving every scenario.
What Broker does
The Wallet Broker is an OID4VP gateway. It accepts verifiable credentials (SD-JWT or mDoc) from holder wallets, verifies them cryptographically against the Trust Registry, enforces the issuer's selective-disclosure commitments, and returns verified claims to your application via webhook. What the holder doesn't disclose never leaves the wallet — Broker can't see it.
Flow
How a presentation flows
- Step 1
Your application calls POST /broker/sessions with a presentation definition.
- Step 2
Broker returns a request_uri; you render it as a QR code for the holder.
- Step 3
Holder scans the QR; their wallet presents matching credentials with selective disclosures.
- Step 4
Broker validates signatures via the Trust Registry, verifies holder binding, enforces limit_disclosure.
- Step 5
Broker webhooks your application with verified_claims — only what was disclosed, nothing more.
Standards
Protocols and formats Broker speaks
OpenID4VP
Verifiable Presentation request/response protocol — the EUDIW standard for online verification.
SD-JWT VC
Selective Disclosure JWT with commitment-based claim reveal. Undisclosed claims are cryptographically unreachable.
mDoc / ISO 18013-5
Binary credential format used for EUDIW and mobile driving licences.
Presentation Definition
W3C schema for describing exactly which credentials and claims you need from the holder.
Compliance
eIDAS 2.0-ready, privacy-by-protocol
Broker is designed for the EUDIW reference architecture. Privacy is enforced by the protocol, not by policy — if a claim is undisclosed, Broker literally cannot see it.
- Selective disclosure enforced at the protocol layer — undisclosed claims never reach the verifier
- Trust Registry integration for live issuer and VCT validation (fail-open by default; configurable fail-closed with static allow-lists)
- Holder binding enforcement prevents credential theft via per-holder key proof
- Replay prevention with nonce-embedded sessions and one-time VP token submission
Integration
One API call to Broker; one webhook to your app
Register a wallet profile once with your presentation definition. Every verification afterwards is a single POST to start a session, a QR rendered to the user, and a webhook back to your app with verified claims.
- REST admin API for wallet profiles, trust registries, and session configuration
- Webhook callback delivery with verified claims and optional Policy Engine decision
- Six production-ready demo scenarios you can run in Docker locally
Demos
Six demo scenarios
Each scenario runs locally in Docker with a mock wallet, webhook receiver, and HTML UI — so you can see the full credential flow without a real issuer.
KvK — Business verification
Single SD-JWT credential (organisation details). Selective disclosure of legal entity name only; constraint validation against a business registry.
Gate — Driving licence
EUDIW-format mDoc DrivingLicense. Constraints on valid CE mark and expiry; policy-free gate opening on a valid credential.
Transport — Port terminal
Dual-credential flow requiring both a DrivingLicense and a TransportMandate. Holder binding consistency across both; Policy Engine evaluates the combined claims.
Nightclub — Age gate
Single SD-JWT with limit_disclosure enforcement. Wallet must disclose only age_over_18 — the bouncer never sees name, birth date, or document number.
Red Team — Attack simulation
Live simulation of replay, tampered claim, expired credential, wrong issuer, credential substitution, and identity mismatch. Proves Broker's defences.
Army — Military base access
Dual credential (military ID + health declaration). Multi-fact constraints (deployment_fit + NATO clearance level) via Policy Engine; issuer revocation simulation.
FAQ
Frequently asked
- Can Broker see all my claims even if I only disclose a subset?
- No. SD-JWT uses cryptographic commitments — each claim is hashed during issuance. When you present, the wallet only sends the claims you select; the hashes for undisclosed claims are never included. Broker receives only what was disclosed. The protocol prevents over-disclosure, not policy.
- What happens if the Trust Registry is down?
- Broker fails open — it logs a warning and continues. If you need fail-closed behaviour, configure your wallet profile with a static trusted_issuers_json allow-list instead. Most operators prefer fail-open to avoid locking legitimate holders out during a registry outage.
- How do I test this before going to production?
- Run one of Broker's six demo scenarios — KvK, Gate, Transport, Nightclub, Red Team, or Army. Each demo ships with a mock wallet, webhook receiver, and HTML UI so you can see the full flow in Docker on localhost. No real issuer or mobile wallet required.
Ready to verify credentials?
Request access to run the demos and wire Broker into your app.