API modules

The Wallet groups identity and credential operations into six modules. The routes below are relative to the deployed API base. Embedded Docker deployments use /api; a configured public subpath comes before that prefix. Management calls require a local tenant selector and credentials for that canonical organization and the Wallet audience.

DID module

The DID module creates and publishes each participant's did:web or did:tdw identity. It maintains verification methods and DID services as keys and service registrations change. did:tdw also keeps a signed document history.

GET /management/did reads the selected participant's document; /management/did/services manages its services. Public resolution uses the published DID's URL, such as /tenants/:tenantSlug/did.json for did:web. Discover and retain these published URLs when importing an existing participant.

Keys module

The keys module generates software keys, imports matching X.509 key/certificate pairs and selects a default signing key. SignatureService signs credentials, presentations and JWTs; SecureTokenService handles DCP self-issued tokens.

/management/keys manages keys, and /management/signature exposes signing and verification operations. Private keys are stored as JWKs in the database without application-level encryption. HSM-backed signing is not implemented.

Credentials module

The credentials module stores complete credentials, their proofs and metadata. It verifies signatures, validity, configured trust anchors, schemas and supported credential status. Locally issued credentials can be revoked through status lists.

/management/credentials provides credential management. Credential records are stored without application-level encryption; protect the database and backups. Presentations select complete matching credentials without redacting their claims.

Issuance module

The issuance module implements holder and issuer flows for OpenID4VCI and Eclipse DCP, including credential offers and requests.

/management/issuance starts and inspects local issuance operations. DCP peers use the participant's DID-advertised service, including /tenants/:tenantSlug/dcp/issuer/metadata, /tenants/:tenantSlug/dcp/issuer/credentials and /tenants/:tenantSlug/dcp/credentials. OpenID4VCI clients discover issuer metadata and follow its advertised endpoints.

Presentation module

The presentation module builds and verifies signed presentations and exchanges them through OpenID4VP or Eclipse DCP. Query matching selects credentials; the builders include complete credentials in the signed presentation.

/management/presentation manages local presentations and scopes. GET /management/dcp/holder/token creates a holder token, and POST /management/dcp/verifier/verify starts DCP verification. Holders receive peer requests at POST /tenants/:tenantSlug/dcp/presentations/query. OpenID4VP management is under /management/oid4vp/verifier. See DCP presentation flow for token scopes and query modes.

Issue configuration module

Issue configurations define credential types, JSON-LD context documents, validation schemas and display metadata such as names, colors and images.

/management/issue-configurations manages these records. Public context documents and configured images use /tenants/:tenantSlug/issue-configuration/:id and its /background-image route.

Shared infrastructure

The modules use shared authentication, ABAC authorization, tenant context and audit logging. SQLite and PostgreSQL persist Wallet state. SSO manages login identities, while Tenant Management owns organization lifecycle and service grants. See shared tenancy contracts for the boundaries between these services.

The OpenAPI reference lists the exact methods, bodies and permissions for each route.