Security Model

Review status: This foundation page requires specialist review before public approval. Its claims must remain within the scope stated here.

UbID applies defense in depth across the full identity lifecycle. No single control—password, passkey, biometric check, signature, encrypted database, blockchain reference, or monitoring dashboard—is treated as sufficient by itself.

The security model connects preventive controls, validation, detection, evidence, and recovery so that weakness in one layer does not automatically compromise the complete trust system.

Security objectives

UbID's public security objectives are:

• protect the holder's credentials and cryptographic control;
• prevent unauthorized issuance, presentation, recovery, and administrative action;
• ensure that verifiers reject invalid, stale, untrusted, or contextually inappropriate evidence;
• isolate institutional keys from ordinary application access;
• limit each participant and service to the authority it requires;
• detect abnormal service, policy, device, credential, and recovery events;
• preserve sufficient evidence for investigation without exposing secret material;
• recover safely from device loss, key rotation, service failure, and security incidents.

Defense-in-depth layers

Layer	Security responsibility
Identity proofing	Establish evidence before issuing high-value claims or approving sensitive actions.
Authentication	Confirm control of an approved authenticator and session.
Authorization	Determine whether an actor may perform a specific operation.
Credential lifecycle	Protect issuance, signing, delivery, status, renewal, suspension, and revocation.
Holder custody	Protect credentials, local keys, devices, and presentation consent.
Verification	Validate issuer trust, integrity, status, freshness, context, and policy.
Recovery	Restore legitimate control through staged, distributed, and evidenced authorization.
Cryptographic control	Separate key purpose, policy, version, provider, and lifecycle.
Platform security	Enforce service identity, least privilege, protected transport, isolation, and secure delivery.
Operations	Detect failure, route alerts, investigate events, and test restoration procedures.

Zero Trust principles

Zero Trust in UbID means that trust is not inherited merely because a request originates from an internal network, an authenticated session, or a previously approved device.

Sensitive operations require explicit validation of relevant conditions, which may include:

• actor and service identity;
• operation purpose and scope;
• credential or device state;
• transaction context and freshness;
• policy version;
• authorization evidence;
• key and algorithm status;
• environmental assurance where applicable.

A user interface can display available actions, but authoritative policy decisions are made by controlled services.

Separation of duties

High-impact operations should not depend on one unrestricted actor. Separation of duties can apply to:

• credential preparation and final issuance;
• policy change and policy approval;
• key administration and application use;
• recovery request and protected release;
• evidence collection and final business decision;
• AI interpretation and deterministic execution.

This reduces the risk that one compromised account, service, administrator, or automated agent can silently perform an end-to-end sensitive action.

Fail-closed behavior

When a required trust condition cannot be validated, the secure default is to stop or return an indeterminate result rather than silently accept weaker evidence.

Examples include:

• an untrusted or unresolved issuer;
• a disallowed algorithm;
• an expired, suspended, or revoked credential;
• missing freshness or audience binding;
• a failed holder relationship check;
• an unavailable authoritative policy or status source;
• an unauthorized recovery stage.

Availability measures and fallback paths must remain more constrained than ordinary access and produce clear evidence.

Security evidence and review

Security controls should produce evidence that supports:

• architecture and threat review;
• internal control testing;
• credential and device lifecycle investigation;
• key rotation and incident response;
• recovery exercises;
• independent assurance and audit.

Evidence must be minimised. Logging a secret in order to prove that a control ran defeats the purpose of the control.

Shared responsibility

UbID provides security capabilities, but each deployment must configure and operate them appropriately. Institutions remain responsible for governance, role assignment, patching, secure infrastructure, risk acceptance, incident response, testing, vendor oversight, and regulatory duties.

Public documentation boundary

The public portal excludes production network design, security thresholds, private hostnames, detailed fallback rules, key identifiers, anti-abuse models, vulnerabilities, incident procedures, and internal acceptance criteria.

See Authentication and Device Security, Cryptographic Protection, and Auditability and Observability.