Skip to main content
Version: Next

TSG Wallet

The TSG Wallet manages participant DIDs, software signing keys, verifiable credentials and credential exchange. One Wallet process can serve several managed organizations. Each organization has its own keys, DID, credentials and issuer configuration.

Tenant Management creates or explicitly imports organizations and keeps their authorization snapshots fresh. A fresh Wallet starts without participants; startup configuration supplies provisioning defaults. See deployment and migration before upgrading an existing Wallet.

Capabilities​

  • Create and publish did:web or did:tdw identities and update their keys and DID services.
  • Generate EdDSA and ES384 keys, or import an X.509 certificate with its matching PKCS#8 private key.
  • Issue, store, verify, revoke and present credentials through the supported OpenID4VC and Eclipse DCP flows.
  • Configure credential types, JSON-LD contexts, validation schemas and display metadata.
  • Publish credential status and verify supported status lists from other issuers.

The module guide maps these capabilities to APIs. The process flows explain credential exchange, and the OpenAPI reference defines the current request contracts. The DCP test report describes the automated interoperability checks and their scope.

Keys and stored credentials​

Signing uses software keys. The Wallet exports private key material as JWKs and stores it in its database. Credentials and proofs are also stored there. The application does not encrypt these fields at rest or integrate with an HSM. Protect the database, storage volumes and backups accordingly; access to a Wallet database can expose its private signing keys and credentials.

Presentations select matching complete credentials and sign the resulting presentation. Credential selection does not redact individual claims within a credential. The current presentation builders do not provide selective-disclosure or zero-knowledge proofs.

Access and organization boundaries​

Management requests use SSO-issued tokens and the shared permission-based ABAC model. A local tenant selector chooses the addressed organization, while its canonical tenant ID, receiving audience, membership and service grant determine authorization. Organization roles alone do not grant Wallet permissions.

External credential protocols use their own token and proof checks. Public DID and credential-status reads remain available when protected organization access is suspended. See shared tenancy contracts.

Configuration and deployment​

The configuration reference covers validated file and environment settings. SQLite supports local experiments; replicated deployments require shared PostgreSQL. Keep the database and encryption secrets together in backups. TENANCY_SECRET protects managed OAuth credentials; it does not encrypt the Wallet's signing-key or credential tables.

Use the managed HTTP sample for a coordinated SSO, Tenant Management, Wallet and Control Plane deployment. The build guide covers local development and image creation.

Protocol references​

These specifications describe the protocols used by the Wallet. Support for a protocol does not imply every optional format or feature is implemented; use the API reference and test report to assess the implemented behavior.