Skip to main content

UbID Credential Cloud

UbID Credential Cloud is the product domain for issuing and managing verifiable credentials. It helps an institution turn an approved claim into portable, cryptographically protected evidence that can be held by a person or organization and independently verified under policy.

The product is designed for institutions that need more than document generation. Credential issuance must connect identity evidence, issuer authorization, schema governance, signing-key identity, credential status, delivery, and an auditable reason for the operation.

What it addresses​

Traditional digital processes often require every recipient to request a new database lookup or retain another copy of the same document. This creates duplication, privacy exposure, and tightly coupled integrations.

A verifiable credential changes that model. The issuer signs a structured statement, the holder receives it, and a verifier can evaluate its provenance and integrity without requiring unrestricted access to the issuer's internal systems.

Core responsibilities​

UbID Credential Cloud supports the public lifecycle of an issued credential:

  • define approved credential types and the claims they may contain;
  • validate that an issuance request is complete and authorized;
  • correlate issuance with appropriate proofing and policy evidence;
  • create a signed credential using an identifiable issuer key;
  • deliver the credential through an approved holder or wallet flow;
  • maintain lifecycle information such as validity, suspension, revocation, renewal, or replacement;
  • preserve evidence explaining who or what authorized the issuance and why.

Issuer accountability​

Cryptographic validity does not establish that a claim is true. The issuer remains responsible for:

  • the source and quality of the underlying evidence;
  • the meaning of each claim;
  • the authorization to issue it;
  • the validity period and lifecycle rules;
  • correction and revocation procedures;
  • regulatory and contractual obligations.

UbID provides the mechanisms that make these responsibilities explicit and verifiable. It does not transfer institutional accountability to the credential holder or to the platform.

Credential lifecycle​

A credential is not complete at the moment of signature. Its lifecycle may include:

  1. Definition — an institution approves the credential purpose and claim model.
  2. Evidence — the necessary identity or source evidence is evaluated.
  3. Authorization — policy confirms that issuance is permitted.
  4. Issuance — a new signed artifact is created.
  5. Delivery — the credential is provided to the intended holder.
  6. Use — the holder presents selected information to a verifier.
  7. Status change — the issuer may suspend, revoke, renew, or replace the credential.
  8. Evidence retention — records are kept according to purpose and retention policy.

A profile change or correction should normally produce a new signed artifact rather than silently altering an existing credential.

Privacy and minimisation​

Credential design should avoid reproducing an entire institutional record. A well-designed credential contains only the claims required for its purpose and supports selective disclosure where the format permits it.

The issuer should also avoid embedding universal correlation identifiers, internal database keys, unnecessary biometrics, or operational metadata in a credential.

Relationship with other products​

  • UbID Proof provides identity and document assurance before issuance.
  • UbID Wallet receives and protects holder-controlled credentials.
  • UbID Connect enables standards-based exchange and trusted messaging.
  • UbID Trust API exposes governed integration contracts.
  • UbID KeyVault protects institutional signing operations.
  • UbID Pulse records service posture and issuance evidence.

What this product does not decide​

UbID Credential Cloud does not decide whether a verifier must accept a credential. A verifier evaluates the issuer, credential type, status, holder relationship, requested claims, and transaction context under its own policy.

It also does not make an institution legally compliant by itself. The issuer must define lawful processing, notices, retention, rights procedures, contractual roles, and any required assessments or certifications.

Public documentation boundary​

This page explains the product responsibility and lifecycle. Detailed credential schemas, signing profiles, tenant configuration, test credentials, customer rules, operational endpoints, and key-management configuration belong in controlled partner or internal documentation.

See also Verifiable Credentials, Credential Lifecycle, and UbID Proof.