How UbID Works

UbID distributes responsibility among participants instead of treating one central system as the permanent owner of every identity fact.

A typical interaction has three primary roles:

1. An issuer evaluates evidence and issues a governed credential.
2. A holder receives the credential, protects it, and decides when to present it.
3. A verifier requests proportionate evidence and checks whether the presentation satisfies its policy.

A relying institution then uses the verification result to make its own business, eligibility, onboarding, or access decision.

A simplified trust flow

Stage	What happens	Primary responsibility
Establish evidence	Identity, qualification, authorization, or another fact is evaluated.	Issuer and proofing process
Issue credential	The approved claims are placed in a signed credential.	Issuer
Hold securely	The credential is delivered to and protected by the holder.	Holder and wallet
Request proof	A verifier states what evidence is required and why.	Verifier or relying party
Authorize presentation	The holder reviews and approves the requested disclosure.	Holder
Verify	Integrity, issuer, status, freshness, holder relationship, and policy are evaluated.	Verifier
Decide	The institution applies its own business or access rule.	Relying party
Maintain trust	Status, renewal, device changes, recovery, and evidence are managed over time.	Shared lifecycle responsibilities

Issuance

Issuance begins with a defined credential purpose and schema. The issuer determines which claims it is authorized to make, what evidence is necessary, and which policy must be satisfied.

After evaluation, the issuer creates a signed credential and delivers it to the holder. A trustworthy issuance process connects the credential to:

• the issuing organization;
• the evidence and policy used;
• the credential type and version;
• the signing key identity;
• lifecycle information such as validity and status;
• the intended holder where holder binding applies.

The credential is not trustworthy merely because it is digital. Trust depends on the issuer, the evidence, the signing process, and the lifecycle controls remaining coherent.

Holder custody and consent

The holder receives the credential in a wallet or protected vault. The wallet helps the holder understand what is stored, what a verifier is requesting, and what will be disclosed.

Holder control means that the person can authorize presentation and manage registered devices. It does not mean that the holder can rewrite institutional claims or ignore credential status. Issuer authority and holder control are complementary.

Presentation and verification

A verifier requests evidence for a declared purpose. The request should be limited to the information needed for the transaction.

The holder can then approve an appropriate presentation. Depending on the credential and policy, this may disclose selected claims rather than the entire credential or source document.

The verifier checks relevant conditions, which may include:

• who issued the credential;
• whether its integrity is valid;
• whether it is current, suspended, expired, or revoked;
• whether the presentation is fresh and intended for the requesting party;
• whether the holder relationship is demonstrated;
• whether the disclosed claims satisfy the declared policy.

The verifier returns an explainable result. The relying institution remains responsible for the final decision.

Beyond a single transaction

Trust continues after issuance. Credentials may expire, be renewed, suspended, or revoked. Devices may be replaced. Authentication may require stronger assurance. A holder may need recovery. Institutions may need evidence showing what was requested, what was disclosed, which policy applied, and what outcome occurred.

UbID therefore treats issuance, custody, presentation, verification, status, recovery, and operational evidence as parts of one lifecycle rather than unrelated features.

Separation of decisions

The wallet manages the holder experience, but it does not decide institutional trust policy. The verifier evaluates evidence, but the relying party remains responsible for the business decision. The platform supports these responsibilities without silently merging them.