Issuer Integration

An issuer integration converts authoritative institutional evidence into a credential that can be held, presented, and independently verified. The issuer remains responsible for the truth, scope, governance, and lifecycle of the claims it signs.

UbID coordinates proofing, policy, credential definition, signing, delivery, status, and evidence while keeping those responsibilities independently governable.

Establish issuing authority

Before implementing a flow, the organization should document:

• the legal or institutional basis for issuing the claim;
• the population and jurisdiction covered;
• the source systems or evidence considered authoritative;
• the assurance required before issuance;
• who can approve, suspend, revoke, replace, or renew a credential;
• the retention and rights procedures associated with the credential;
• the relying contexts for which the credential is intended.

A technically capable organization is not automatically authorized to issue every type of claim.

Define the credential

A credential definition should specify:

Area	Questions to resolve
Identity	Who is the issuer, subject, and intended holder?
Semantics	What does each claim mean and which source establishes it?
Minimisation	Which claims are necessary, optional, or prohibited?
Schema	How are required fields, formats, and versions validated?
Assurance	Which evidence and review level support issuance?
Binding	How is the credential associated with the intended holder or wallet?
Lifecycle	When does it expire, renew, suspend, revoke, or become superseded?
Status	How can a verifier determine current acceptability?
Privacy	Which disclosures are expected and which correlation risks must be limited?
Governance	Who owns changes, incidents, support, and communication?

Schemas support consistency, but they do not establish that the source claim is true. Evidence, authority, and policy remain essential.

Issuance flow

A representative flow contains these stages:

1. Initiation — an authorized process starts an issuance transaction for a defined credential.
2. Evidence collection — the minimum required evidence is obtained from approved sources.
3. Proofing and validation — identity, document, institutional, or other evidence is evaluated.
4. Policy evaluation — the issuer checks authority, eligibility, assurance, schema, duplicates, and lifecycle conditions.
5. Holder or wallet binding — the intended recipient proves the relationship required by the credential profile.
6. Approval — an authorized person or policy grants issuance.
7. Signing — a controlled cryptographic service signs the approved claims with an identifiable key version.
8. Delivery — the credential is delivered through the approved holder interaction.
9. Registration and status — lifecycle references and status are created consistently.
10. Evidence — the issuer retains an auditable record of the operation without retaining unnecessary secret material.

The stages may occur synchronously or asynchronously. A successful proofing result should not automatically become a signing operation without an explicit policy transition.

Prepare, validate, approve, execute

Issuer APIs should preserve separation between intent and authoritative state change:

• Prepare assembles the credential request and supporting references.
• Validate checks syntax, schema, evidence, identity, duplicates, and policy.
• Approve records the required authorization.
• Execute creates and signs the credential.

This structure supports segregation of duties, human review where required, idempotency, and explainable failure.

Key and signing responsibility

The issuer owns the meaning of the signature and the governance of its signing identity. Applications should request a bounded signing operation from an approved key service rather than receive raw institutional key material.

The partner profile should define:

• issuer identifier and verification relationship;
• approved credential format and algorithms;
• key activation, rotation, retirement, and compromise response;
• how verifiers resolve public verification material;
• how historical credentials remain reviewable;
• which evidence links a credential to the key version used.

Production key identifiers, internal KMS configuration, and operational recovery procedures are not public documentation.

Delivery to the holder

Credential delivery should confirm:

• the intended wallet or holder interaction;
• authorization and transaction freshness;
• proof of required holder key control;
• one-time or replay-resistant transaction state;
• clear user information about the issuer and credential;
• timeout, abandonment, and retry behavior;
• a final delivery outcome visible to the issuer without exposing wallet contents.

Delivery success does not authorize the issuer to monitor every later use of the credential.

Status, renewal, and replacement

The issuer should maintain a coherent lifecycle:

• active — currently usable under policy;
• expired — outside the defined validity period;
• suspended — temporarily unacceptable;
• revoked — no longer acceptable;
• superseded — replaced by a newer credential;
• renewed — reissued following approved policy.

The exact states depend on the credential profile. Public status should reveal only what a verifier requires and should avoid publishing sensitive reasons or holder history.

A changed claim or profile should normally produce a new signed artifact and a consistent lifecycle transition rather than mutating an existing signed credential.

Error and review outcomes

An issuer integration should distinguish:

• incomplete or invalid input;
• unsupported credential configuration;
• insufficient or indeterminate evidence;
• failed eligibility or issuer policy;
• holder-binding failure;
• duplicate or conflicting lifecycle state;
• stale, reused, or consumed transaction;
• operation awaiting review;
• signing or delivery dependency unavailable;
• credential created but delivery outcome unresolved.

Errors should help an authorized partner recover safely without revealing anti-abuse rules, other applicants' data, or internal topology.

Issuer evidence

An issuer may retain references to:

• credential definition and schema version;
• source and assurance category;
• policy decision and approver;
• holder-binding result;
• signing key version reference;
• issuance and delivery outcome;
• status and lifecycle events;
• correction, renewal, suspension, or revocation reason category.

Retention should be purpose-bound and jurisdiction-aware. Raw evidence should not be duplicated merely because a credential was issued.

Issuer readiness checklist

Before production approval, confirm that:

• issuing authority and claim ownership are documented;
• schema and claim semantics are approved;
• minimum data and disclosure expectations are defined;
• proofing and assurance requirements are testable;
• key lifecycle and verifier discovery are governed;
• holder binding and delivery have replay protections;
• status, renewal, replacement, and revocation are operational;
• positive, negative, duplicate, expiry, and dependency tests pass;
• support and incident owners are assigned;
• public claims accurately describe the implemented scope.

Public documentation boundary

This page does not publish customer schemas, source-system mappings, production metadata, endpoint contracts, client registrations, signing configuration, approval rules, anti-fraud thresholds, or operational credentials. Those details are supplied through controlled partner onboarding.

See UbID Credential Cloud, OpenID for Verifiable Credentials, and Public Metadata and Discovery.