Integration Model

A UbID integration is a governed relationship among participants that exchange verifiable evidence. The technical flow is only one part of the model. Authority, purpose, data responsibility, trust policy, lifecycle, and operational evidence must be defined together.

Participants and responsibilities

Participant	Primary responsibility	Must not be assumed to do
Issuer	Validate the basis for claims and issue governed credentials	Make the relying party's final decision
Subject	Person or entity described by the claims	Always be the same party as the holder
Holder	Control receipt and presentation of credentials	Determine whether an issuer is trusted by every verifier
Wallet or holder service	Protect credentials, keys, consent, and presentation context	Silently disclose unrelated credentials or claims
Verifier	Validate presented evidence and evaluate verification policy	Treat a valid signature as automatic entitlement
Relying party	Make the final institutional or business decision	Delegate all accountability to the credential technology
Proofing provider	Produce evidence or assurance used by an issuer or policy	Become the issuer merely by supplying evidence
Custodian or recovery participant	Protect a bounded recovery responsibility	Reconstruct or control the complete identity alone
Infrastructure provider	Operate approved platform services	Use operational access as authority over credential truth

One organization may perform more than one role, but each role should remain explicit in policy, contracts, access control, audit evidence, and incident procedures.

The trust contract

The integration profile should record at least:

1. Purpose — the transaction or service for which evidence is requested.
2. Credential definition — issuer, credential type, subject, claim semantics, schema, and lifecycle.
3. Assurance — the evidence and process required before claims are issued or accepted.
4. Disclosure — the minimum claims and presentation conditions allowed.
5. Cryptographic policy — formats, algorithms, key relationships, holder binding, and freshness.
6. Status policy — expiry, suspension, revocation, replacement, and dependency behavior.
7. Decision ownership — the actor responsible for the final result and any review path.
8. Data governance — lawful purpose, retention, deletion, rights, transfer, and biometric conditions.
9. Operational evidence — identifiers, policy version, timestamps, outcomes, and references retained without secrets.
10. Change governance — compatibility, migration, deprecation, and incident notification.

End-to-end integration sequence

A representative trust interaction follows this pattern:

1. An issuer defines an approved credential and the evidence required to issue it.
2. The subject or holder completes the authorized proofing and consent flow.
3. The issuer validates evidence and policy, then authorizes credential creation.
4. A controlled signing service produces the credential using an approved key and algorithm.
5. The credential is delivered to the holder through an approved wallet interaction.
6. A verifier requests the minimum evidence needed for a declared purpose.
7. The holder reviews the request and authorizes a suitable presentation.
8. The verifier validates provenance, integrity, status, context, holder relationship, and policy.
9. The relying party makes the final decision.
10. Each participant retains the evidence required for its own accountability without collecting the complete lifecycle of the holder.

This sequence may be implemented through standards-based flows or governed APIs, but the trust responsibilities remain the same.

Integration boundaries

UbID separates four architectural responsibilities:

Experience channels

Portals, wallets, mobile applications, and partner interfaces collect user intent and display outcomes. They do not independently decide credential trust or perform unrestricted cryptographic operations.

Trust services

Proofing, issuance, verification, access, and recovery services evaluate authoritative policy and manage domain state.

Platform control services

Key management, messaging, identifier resolution, status, evidence, and shared integration components provide reusable controls through narrow contracts.

Operational services

Monitoring, alerting, audit, and AI-assisted interpretation observe and explain. They do not silently change identity or credential state.

Interaction patterns

Standards-first exchange

Wallet, issuer, and verifier interactions should use recognized profiles where they provide suitable interoperability. The exact supported subset must be pinned and tested.

Governed API coordination

Institutional systems can use UbID Trust API contracts to prepare, validate, approve, execute, and retrieve results. Authorization to discover a capability is different from authorization to execute it.

Secure agent messaging

DIDComm can carry protected, identity-bound messages where asynchronous or agent-to-agent coordination is required. Messaging does not replace issuance or verification policy.

Event and evidence integration

Authorized systems may receive lifecycle notifications or evidence references. Events should be scoped, authenticated, replay-resistant, and designed to avoid unnecessary personal-data replication.

Data minimisation in integration design

Integration architects should distinguish:

• source evidence used for proofing;
• claims placed in a credential;
• disclosures selected for one presentation;
• verification results returned to a relying party;
• operational records retained for accountability.

These are different data sets and should not be copied together by default. A verifier often needs a policy result and a small set of claims, not the source document, complete credential, wallet inventory, or proofing record.

Failure and dependency model

An integration should define behavior for:

• unresolved issuer or key metadata;
• unavailable status service;
• expired or superseded credential;
• stale or replayed presentation;
• unsupported format or algorithm;
• incomplete disclosure;
• indeterminate proofing result;
• policy-version mismatch;
• partner timeout or duplicated request;
• operational degradation.

High-assurance flows should fail closed or route to an explicit review state rather than silently weakening policy.

Integration evidence

A useful evidence record may identify:

• participant and transaction identifiers;
• declared purpose and requested credential type;
• policy and schema versions;
• verification checks performed;
• result and reason category;
• authorization or consent reference;
• timestamps and dependency outcomes;
• lifecycle action or final decision reference.

It should not contain private keys, recovery shares, complete wallet contents, raw biometric templates, or unnecessary source documents.

Public documentation boundary

This model defines the public trust architecture. Tenant identifiers, production endpoints, exact message schemas, credentials, trust registries, policy code, infrastructure maps, operational thresholds, and exception procedures remain controlled partner or internal documentation.

See Trust and Policy, Public Metadata and Discovery, and Roles and Responsibilities.