Embed the CodeB European Digital Identity Wallet backend in your native app.
Twenty-five documented endpoints across four capability groups. Your iOS + Android app implements the client side with platform-native crypto (Secure Enclave, Android Keystore); the wire protocol is identical to the CodeB browser-based Web Wallet you can try today. Backed by a complete API reference, five native-integration cookbooks, an OpenAPI 3.1 spec, and a Postman collection. Contact info@aloaha.com for OEM licensing.
What your app can do.
The endpoint contract mirrors what the CodeB browser wallet does today. Every native OEM app maps to the same wire protocol; the differences are in local crypto and persistence.
A. Credential import (10 endpoints)
OID4VCI 1.0 FINAL holder side. Discover issuer metadata, handle both pre-authorized-code and authorization-code + PAR grants, sign the openid4vci-proof+jwt on-device, POST /credential for both dc+sd-jwt and mso_mdoc. Import from external issuers (issuer.eudiw.dev) and from our own vci.ashx.
B. Self-issue from OIDC identity (2 endpoints)
When CodeB is BOTH your identity provider and issuer, skip the OID4VCI ceremony: enumerate eligible VCs via ?available-attributes, mint bound to a fresh wallet key via ?issue-in-session. Two calls, no browser hop.
C. Credential presentation (3 endpoints)
OID4VP 1.0 FINAL holder side. Fetch JAR directly, resolve DCQL against local credentials, build SD-JWT KB-JWT or mDoc DeviceResponse, POST via direct_post or direct_post.jwt (JWE ECDH-ES + A128GCM). Attach the Wallet Attestation as OAuth-Client-Attestation header when the verifier requires it.
D. Wallet operations (10 endpoints)
Narrow session tokens, encrypted vault backup / load / delete (opaque to server), server-side mDoc verify with configurable trust anchors, tenant DID discovery, RP-initiated logout with Clear-Site-Data, member-facing self-offer mint, ARF 3.0 TS7 data-deletion and TS8 DPA-report.
Pick the deployment that fits your risk profile.
Shared managed
phone.aloaha.com. Fastest to onboard: your OEM OIDC client_id is provisioned in days, isolation via the azp claim baked into the vault storage-key hash. Lowest ops burden for your team.
Per-OEM subdomain
<you>.aloaha.com. Dedicated tenant with own DIDs, own CA, own branding. Suitable when your regulatory posture wants a named sub-processor with distinct data boundaries.
On-premise
Full CodeB stack on your Windows Server + IIS. No cloud dependency except optional QTSP timestamp lookup. For regulated industries or public sector deployments that require complete data residency.
| Dimension | Shared managed | Per-OEM subdomain | On-premise |
|---|---|---|---|
| Onboarding | Days | Weeks | Weeks (deploy + train) |
| Isolation | OIDC azp in storage-key hash | Separate tenant, separate keys | Separate infrastructure |
| Custom branding | App-side only | Server + app side | Full |
| Data residency | Malta (Aloaha) | Malta (Aloaha) | Your choice |
| Ops burden | None | None | You run IIS |
Integrator deliverables.
- API reference — wallet-api.html. Every endpoint with request/response shapes, auth badges, native-parity notes.
- Five cookbooks with iOS Swift + Android Kotlin snippets — import, present, Wallet Attestation, vault sync, self-issue.
- OpenAPI 3.1 spec — openapi/wallet-api.yaml. Codegen a client for your language of choice.
- Postman collection + environment — collection, env template. QA-team-ready.
- Direct access to the Aloaha technical team during integration. E-mail SLA one business day.
HAIP-conformant runtime mint.
The runtime mint at /wallet-attestation.ashx is HAIP §5.11 conformant. Each call binds the wallet's walletPublicJwk to the acting OIDC sub and returns a JWT with typ=wallet-attestation+jwt in the header, per-tenant HS256-signed, 24-hour expiry. Verifiers that check the JWT signature against the tenant's HMAC key accept it as evidence that the presenting client is a legitimate wallet. See the WA cookbook for the wire.
EU jurisdiction. Real one.
Aloaha Limited is based in Malta — an EU member state with an English-language legal system, GDPR applicability, eIDAS conformance and a LOTL-listed national trust list. Wallet Attestations minted from a Maltese tenant carry EU legal recognition under Regulation (EU) 910/2014. US-jurisdictional providers bring CLOUD Act reach and Schrems II complexity that many European OEM integrators actively avoid for identity-adjacent data.
See EU ID Wallet software Malta for the broader positioning.
Start OEM onboarding.
Send an e-mail with your company details, technical contact, OIDC client name, and rough deployment scope. Aloaha's tech team responds within one business day and provisions your OEM client_id against the tenant of your choice.
Frequently asked questions
What is the CodeB Web Wallet OEM offering?
A licensable European Digital Identity Wallet backend that OEM integrators embed in their own native mobile apps. Twenty-five documented endpoints across four capability groups: OID4VCI credential import (holder side, 10 endpoints), self-issue from the OIDC identity (2 endpoints), OID4VP credential presentation (holder side, 3 endpoints), and wallet operations (10 endpoints). Your native app implements the client side with the platform's Keychain / Keystore for on-device crypto; the wire protocol is identical to what CodeB's browser-based Web Wallet uses today, so the backend is battle-tested.
Which hosting tiers are available?
Three tiers. Shared managed hosting on phone.aloaha.com — fastest to onboard, per-OEM OIDC client_id isolates apps and the storage-key hash includes azp for cross-OEM vault isolation. Per-OEM subdomain (yoursubdomain.aloaha.com) — dedicated tenant with own DIDs, own CA, own branding. On-premise — you deploy our IIS stack in your own data centre, complete sovereignty. All three tiers use the same endpoint contract; upgrading between tiers is transparent to the app.
How does OEM onboarding work?
Lightweight KYB via email to info@aloaha.com: company legal name and registration, technical contact, OIDC client name and redirect URIs, deployment scope. Aloaha provisions a per-OEM OIDC client_id against the tenant of your choice within two business days. The Wallet Attestation mint works out of the box on the shared managed tier.
What deliverables do OEM integrators receive?
Human-readable API reference (wallet-api.html) documenting every endpoint with request/response shapes and native-parity notes. Five cookbooks with iOS Swift and Android Kotlin code samples: credential import (OID4VCI holder), credential presentation (OID4VP holder), Wallet Attestation, encrypted vault sync, self-issue from OIDC identity. OpenAPI 3.1 spec for machine-readable codegen. Postman collection with an environment template. Access to the Aloaha technical team for integration questions.
Why Malta?
Aloaha Limited operates from Malta — an EU member state with an English-language legal system, GDPR applicability, eIDAS conformance, and a LOTL-listed national trust list. Wallet Attestations minted by us carry EU legal recognition under Regulation 910/2014. US-jurisdictional providers bring CLOUD Act and Schrems II risks that many European OEM integrators actively avoid for identity-adjacent data.
How is cross-OEM isolation enforced?
On the shared managed tier: (1) every OEM's app has its own OIDC client_id; (2) the OIDC access token carries the client_id in the azp claim; (3) our wallet-backup handler hashes storage keys over sub|tenant|azp, so two OEMs on the same tenant whose users share a sub cannot collide on the same vault blob. Per-OEM subdomain and on-premise tiers use full tenant separation instead — separate App_Data/tenant directories, separate signing keys, separate DIDs.
What is the state of Wallet Attestation?
The runtime mint at /wallet-attestation.ashx is HAIP §5.11 conformant: JWT with typ=wallet-attestation+jwt in the header, walletPublicJwk bound to the acting OIDC sub, 24-hour expiry, per-tenant HS256 with a symmetric HMAC key. Verifiers that check the JWT signature against the tenant's HMAC key accept the WA as evidence that the presenting client is a legitimate wallet.
Is on-premise sovereignty possible?
Yes. The full CodeB stack is deployable as an on-premise IIS deployment. Requirements: Windows Server 2019+, IIS 10+, .NET Framework 4.8. No cloud dependency except the qualified timestamp lookup at the QTSP for signing operations (and that QTSP endpoint is configurable). The wallet backend endpoints are contained entirely within your deployment.