Verification and Policy

A verifier checks more than whether a credential contains a valid signature. Trust depends on the issuer, credential type, signing key, current status, disclosed claims, presentation context, holder relationship, assurance, and the policy of the relying institution.

UbID separates technical verification from the final institutional decision. A valid credential may be necessary for a transaction but is rarely sufficient by itself.

Verification questions

A verifier may evaluate the following questions:

Question	What it establishes
Who issued the credential?	Provenance and issuer identity
Is the issuer trusted for this claim?	Scope of institutional authority
Has the artifact been altered?	Cryptographic integrity
Is the key and algorithm approved?	Cryptographic policy conformance
Is the credential current?	Validity period and lifecycle status
Was the presentation created for this request?	Freshness, audience, and replay resistance
Is the presenter the intended holder?	Holder binding where required
Were only the requested claims disclosed?	Proportionality and request conformance
Does the evidence meet the assurance requirement?	Suitability for the transaction
Which policy version produced the result?	Explainability and historical review

Issuer trust

A cryptographically valid credential is not automatically trustworthy. The verifier must determine whether the issuer is recognized and authorized to make the relevant claim.

For example, an organization may be trusted to issue employee-role credentials but not government identity, professional licenses, or academic degrees. Trust should be scoped by credential type, jurisdiction, sector, purpose, and assurance.

Integrity and algorithm policy

The verifier resolves the relevant verification material and checks the signature or proof. It also confirms that the algorithm, key type, key status, and credential format are permitted by policy.

Verification should fail safely when required material cannot be resolved or when an artifact uses an unapproved or deprecated protection.

Status and lifecycle

A credential can be authentic but no longer acceptable because it has expired, been suspended, revoked, superseded, or replaced.

Status checking should reveal only what the verifier needs to know. Sensitive revocation reasons or complete holder histories should not be exposed through public status services.

Presentation context

A presentation should be bound to the requesting party and transaction. Fresh challenges, audience restrictions, and time constraints help prevent a valid presentation from being copied and replayed elsewhere.

The verifier should also confirm that the disclosed claims correspond to the request and that no required condition was omitted.

Holder relationship

Some credentials require proof that the presenter controls the holder key or approved wallet relationship associated with the credential. Other credentials may be bearer-like or use a different binding model.

The verifier policy must know which model applies. Holder binding should not be assumed merely because a credential was received through a user interface.

Explainable outcomes

Verification results should distinguish among outcomes such as:

• verified and policy-satisfied;
• cryptographically valid but insufficient for the policy;
• expired, suspended, or revoked;
• untrusted issuer or unsupported credential type;
• missing required disclosure or holder relationship;
• stale, replayed, or incorrectly addressed presentation;
• indeterminate because an authoritative dependency is unavailable.

A binary "valid" response can hide important distinctions.

Final institutional decision

The relying party remains responsible for the final decision. It may need to apply additional business, legal, safety, eligibility, fraud, sanctions, clinical, employment, or access rules.

Credential verification should not be described as automatic admission, onboarding, payment approval, medical authorization, licensing, or entitlement unless the institution has explicitly designed and approved that decision process.

Policy governance

Verification policy should be:

• versioned;
• approved by an authorized owner;
• scoped to credential type and purpose;
• testable with positive and negative cases;
• observable in production;
• retained with historical decisions;
• updated when issuers, keys, standards, risks, or laws change.

Public documentation boundary

This page describes public verification semantics. Customer trust lists, acceptance thresholds, private issuer relationships, fraud rules, policy code, endpoints, and operational exception paths remain controlled.

See UbID Proof, Trust Policy, and Verifiable Credentials.