Product · CodeB Business Wallet
The CodeB Business Wallet is built on the emerging European Digital Identity Wallet architecture and the eIDAS 2.0 framework. When the EU Business Wallet specification is published, we will align. Directors, secretaries, legal representatives, compliance officers and employees each hold their own role. External Relying Parties — banks doing KYC, business registries pushing corporate documents, auditors, competent authorities — participate under explicit consent. Everything upload-once, share-selectively, audited-forever.
App_Data/<tenant>/business-wallets/<companyId>/. Every wallet has its own path-scoped did:web:<tenant>:business-wallets:<companyId>. Sign in with your OIDC identity to use it.
This tenant may host multiple businesses, each with its own path-scoped did:web and its own document vault. New wallets are private by default — only a director can flip a wallet to publicly listed.
Every wallet on this tenant where you are enrolled as an employee. Sign in to populate. Private wallets show a lock badge.
Sign in to see your wallets…
Wallets whose director has opted into public discovery.
Loading…
How this Business Wallet is addressed. The primary identifier is did:web:<tenant>, resolvable from /.well-known/did.json. The urn:aloaha:web-wallet:<id> URN is a wallet-only identifier that stays stable when the wallet has no reachable DNS presence — grants and trust-list entries accept either.
did:key + did:jwk are derived from the tenant issuer key when present. did:web is always available — the others fall back to did:web when no issuer key has been generated yet.
A personal European Digital Identity Wallet has one holder. A Business Wallet has many — each employee signs in with their own OIDC identity and inherits a role (Director, Secretary, Legal Representative, Compliance Officer, Employee). Permissions are enforced per-action, not per-session.
The company is the subject. Its identifier is did:web:<company-tenant>, published at /.well-known/did.json. Employee actions are attributed to the employee, but credentials are issued in the company’s name.
Banks, registries, notaries and auditors are first-class citizens. They authenticate as themselves, request specific credentials via OID4VP, and (once granted consent) fetch them — or push new ones (a registry uploading a corporate certificate).
Every document is uploaded once and reused. When a new bank wants your beneficial-ownership declaration, you grant read access — no new upload, no email attachments, no duplicate PDFs.
Every share is scoped. A bank doing KYC needs directors’ ID cards + beneficial ownership. It doesn’t get the source-of-wealth declaration unless it’s explicitly granted. SD-JWT VC selective disclosure carries over from the personal wallet.
Every read, write, share, revoke, employee add/remove is appended to a signed log. Complete accountability for who accessed what and when — a hard requirement for any regulated relying party.
Only a director can flip this. Off (default) → wallet is discoverable only to members via Wallets I belong to and via direct ?bw=<id> links. On → wallet appears on this tenant's public list. Note: the DID Document at /business-wallets/<id>/did.json stays resolvable regardless (needed for VC signature verification), and HMAC share links remain gated by their own token.
Employees sign in via OpenID Connect with their own identity. Their role determines which permissions apply per-action.
Provide at least an email or a wallet-id/DID. Wallet-id / DID enables in-wallet credential binding when the employee has no email on this tenant.
The intended role/permission enforcement is documented below. Per-action server-side enforcement is scheduled for the general-availability release; the current reference implementation records the actor’s identity in the audit log for every mutation but does not yet block Employee-role callers from admin actions. Custom role definitions per company are also planned.
| Permission | Director | Secretary | Legal Rep | Compliance | Employee | AI Agent |
|---|---|---|---|---|---|---|
| Edit company profile | ✓ | ✓ | — | — | — | — |
| Add / remove employees | ✓ | — | — | — | — | — |
| Upload documents | ✓ | ✓ | ✓ | — | — | — |
| Grant Relying-Party access | ✓ | ✓ | ✓ | — | — | — |
| Revoke access | ✓ | ✓ | ✓ | ✓ | — | — |
| View documents | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| View audit log | ✓ | ✓ | ✓ | ✓ | — | — |
| Mint agent capability tokens | ✓ | ✓ | — | — | — | — |
| Deactivate an agent | ✓ | ✓ | — | — | — | — |
Any employee whose role is AI Agent shows here. Mint short-lived, scope-limited ES256 capability tokens signed by this wallet’s issuer key. Downstream services fetch the public agent manifest to learn what the agent may do and to verify a presented token. See why identity matters for AI agents.
Corporate credentials issued to the company, or uploaded by employees / pushed by external registries. Each carries a document type, issuer, issue date, retention period, and Relying-Party grants.
PDF files only (max 8 MB). Non-PDF uploads are rejected server-side even if the extension says otherwise. Uploaded document stored server-side. Metadata (title, type, VCT, issuer, grants, countersignatures, signature state) lives in a sibling .meta.json. The two checkboxes are independent and use different certificates: the uploader signature uses your per-user signing key (auto-generated under App_Data/<tenant>/user-signing-certs/<you>/, subject CN=<you>, commitment-type proof-of-approval); the wallet seal uses the tenant issuer key (subject CN=CodeB VCI Issuer, O=CodeB, OU=<tenant>, commitment-type proof-of-origin). When both boxes are ticked, the PDF carries TWO signatures — personal approval on the inside, institutional seal on top — and both appear in Acrobat’s Signature Panel. When either is ticked, PAdES-B-T is applied synchronously at upload; if a Trusted Timestamp Authority is configured, an RFC 3161 timestamp is embedded, otherwise the signer falls back to B-B.
SD-JWT VCs issued to your company by external issuers — banks, chambers of commerce, notaries, government issuers. Stored server-side under your tenant. Every credential is verifiable on demand: the local vcdm.ashx verify endpoint checks signature, expiry, issuer trust and embedded-issuer cross-check; a local ES256 fallback catches gross tampering when the loopback verifier is unreachable.
Storage: App_Data/<tenant>/business-wallet/vcs/<vcId>.jwt + .meta.json. vcId = sha256(vc_jwt)[:16] base64url. Every store / verify / delete is appended to the audit log.
Third parties who’ve been granted — or requested — access to specific documents. Every grant is scoped to a document set, time-bounded, and revocable.
Identifier accepts did:web:<host>, did:key:…, did:jwk:…, did:webvh:…, or urn:aloaha:web-wallet:<id>. Email + mobile are only used for notifications when documents are granted, updated, or countersigned. If the tenant’s WhatsApp Business channel is configured and the mobile is known, a WhatsApp message is dispatched in addition to email.
Every action is appended here, in order. In production the log is signed with the tenant’s issuer key and mirrored to a per-tenant append-only file — individual entries cannot be edited or removed.
Each document is stored once against the company’s tenant. Subsequent Relying-Party requests trigger consented shares, not re-uploads.
Documents issued as signed Verifiable Credentials carry the same legal weight as original physical copies under eIDAS 2.0 and equivalent national Central Data Repository frameworks emerging across the EU. Verification is cryptographic.
Default 5 years from last use per credential. Extendable to 10 years when required for investigation of serious financial crimes (money laundering, terrorism financing). Retention policy is per-document-type, admin-configurable.
The company is the data controller for its own credentials. Employees have their own subject-access rights against the tenant’s Data Protection Impact Assessment. Full DPIA and Record of Processing Activities are published per tenant.
Documents are stored as SD-JWT VC. A Relying Party requests specific attributes via OID4VP with DCQL; the wallet reveals only those attributes plus a Key-Binding JWT proof.
Every audit entry is timestamped, appended, and periodically anchored via a chain-of-hashes signed by the tenant’s issuer key. Tamper-evident by construction.
Relying-Party access requests use DCQL query syntax over direct_post.jwt.
Registries push credentials via the pre-authorised code flow with tenant-bound Wallet Attestation.
Draft 07-compliant issuance + selective disclosure + KB-JWT.
JSON credential, @context, JOSE envelope typ=vc+jwt, ES256.
Company identifier as did:web:<tenant>, auto-published at /.well-known/did.json.
Employee wallets carry a Wallet Instance Attestation minted by the company’s Wallet Provider backend.
Federate with banks + registries on other CodeB tenants via signed bilateral trust statements at /.well-known/trust-federation.jws.
Revoke a shared credential grant instantly by flipping its bit; every Relying Party checks the list before use.
Publish the tenant’s trusted authorities and issuers as a signed XMLDSig LoTE.
Built on the European Digital Identity Wallet standard (EUDI Wallet, eIDAS 2.0, ARF 3.0) — extended for corporate multi-user scenarios. See also: the personal European Digital Identity Wallet · cross-tenant trust federation · ARF 3.0 conformity.
No. An official European Business Wallet specification, extending the European Digital Identity Wallet framework to companies, is being drafted at EU level and has not been finalised or published. This implementation is our best interpretation grounded in the existing EUDI Wallet + eIDAS 2.0 standards and in national Central Data Repository patterns emerging across Member States. We will align the wallet to the official specification as soon as it is published.
Three methods are supported: (1) another company’s did:web identity that appears in this tenant’s trust list; (2) a personal EUDI PID passed as a Verifiable Presentation and verified against the credential’s issuer signature; (3) an OpenID Connect bearer token issued by the wallet’s tenant.
Two optional signing moments controlled by checkboxes at upload: (1) uploader signature via PAdES-B-B using CSC v2 remote signing (director attests to the document); (2) wallet seal on ingest with a received-at PAdES seal by the tenant’s issuer key. A third moment applies automatically: delivery-time PAdES-B-LT wraps documents when a Relying Party downloads, embedding a fresh RFC 3161 timestamp and OCSP responses, giving legal equivalence under eIDAS 2.0.
Yes. Banks, notaries, auditors and other Relying Parties can countersign a document (accepted / verified / approved / endorsed / witnessed) via the countersign endpoint. Countersignatures are stored alongside the document metadata and appear in the audit log.
Yes. HMAC-signed public share links with configurable expiry (from 15 minutes up to permanent) let anyone with the link download the document. The token is bound to the document ID and expiry, verified with constant-time comparison, and every download is logged in the audit trail.
Documents delivered to Relying Parties are wrapped in PAdES-B-LT seals by the wallet’s issuer key with embedded RFC 3161 timestamps and OCSP responses. Under eIDAS 2.0 and equivalent national Central Data Repository frameworks emerging across the EU, this delivery envelope carries the same legal weight as an original physical copy.
Default retention is 5 years from last use per credential, extendable to 10 years when required for investigation of serious financial crimes (money laundering, terrorism financing). Retention policy is per-document-type and admin-configurable.