UbID KeyVault
UbID KeyVault is the security-control domain for institutional keys and cryptographic operations. It provides governance over which keys exist, what each key may be used for, which service may request an operation, which algorithms are permitted, and how lifecycle evidence is maintained.
The product separates application intent from key possession. An application should request an approved signing, encryption, decryption, or key-wrapping operation without receiving unrestricted access to the underlying institutional key material.
Why key governance matters
Strong algorithms are not sufficient if keys are shared informally, used for multiple purposes, never rotated, or accessible to more services than necessary.
Trustworthy key management requires independent control over:
- key purpose;
- key identifier and version;
- authorized callers;
- allowed algorithms and operations;
- creation and activation;
- rotation and replacement;
- suspension, revocation, or retirement;
- backup and recovery;
- audit and evidence.
Named cryptographic responsibility
A public key or signature should be traceable to a named key identity and purpose. This allows a verifier or auditor to understand:
- which key produced an artifact;
- whether that key was valid at the relevant time;
- which issuer or service controlled it;
- which algorithm and policy applied;
- whether the key has since been rotated or revoked.
Key identifiers are therefore part of trust governance, not merely implementation metadata.
Separation of duties
UbID KeyVault supports a model in which:
- applications define the business operation they need;
- policy determines whether the operation is permitted;
- the cryptographic control plane performs the narrow operation;
- key material remains isolated from ordinary application code;
- audit evidence records the result without exposing secrets.
Sensitive operations may require stronger controls such as dual authorization, hardware-backed protection, confidential execution, or independently reviewed recovery procedures.
Crypto-agility
Identity systems and credentials can remain valuable for many years. Key governance must therefore support controlled evolution rather than binding the platform permanently to one algorithm or provider.
Crypto-agility includes:
- versioned algorithm policy;
- explicit allow-lists;
- separate key families for separate purposes;
- migration and coexistence of classical and post-quantum protections;
- verifier behavior that fails safely when an algorithm or key is not approved;
- evidence that shows which protection was used.
Holder keys and institutional keys
UbID distinguishes holder-controlled keys from institutional keys. UbID KeyVault primarily governs institutional operations such as credential signing, protected service encryption, and platform secrets.
It does not turn the institution into the owner of the holder's identity. Holder custody, wallet protection, and recovery have separate controls and responsibilities.
Relationship with other products
- UbID Credential Cloud uses approved issuer-signing operations.
- UbID Connect uses cryptographic services for trusted exchange.
- UbID Recover may use narrowly authorized protection and release operations.
- UbID Trust API calls cryptographic capabilities through governed contracts.
- UbID Pulse monitors key state and operation evidence.
What this product does not solve alone
A well-protected key cannot correct poor proofing, excessive privilege, weak recovery, inaccurate claims, or an unsafe verifier policy. Key management is one layer of a broader trust architecture.
Public documentation boundary
Public documentation explains lifecycle, separation of duties, crypto-agility, and accountability. Key material, secret names, provider credentials, unsealing procedures, recovery packages, operational paths, and production configuration are never published here.
See also Cryptographic Protection, Post-Quantum Readiness, and UbID Pulse.