Skip to main content

Auditability and Observability

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

Trustworthy identity infrastructure requires more than correct cryptography. Institutions need to know whether services are functioning, policies are being enforced, credentials and devices are changing state, recovery actions are authorized, and abnormal behavior is occurring.

UbID combines observability with minimised operational evidence so that important events can be explained without recording secret material or unnecessary personal data.

Observability and audit are different​

  • Observability helps operators understand current system behavior through health, metrics, logs, traces, and alerts.
  • Audit evidence supports later review of who or what performed an action, under which policy, with which authorization, and with what result.

A dashboard may summarize both, but it is not the authoritative source by itself. The underlying events, metrics, policy references, and signed or checksummed artifacts remain the evidence.

What should be observable​

Public operational domains include:

  • service health and dependency availability;
  • credential issuance and delivery outcomes;
  • verification success, failure, and indeterminate states;
  • credential status changes;
  • device registration, suspension, revocation, and replacement;
  • authentication and constrained fallback outcomes;
  • recovery stage transitions and authorization results;
  • key state, rotation, and cryptographic-operation health;
  • policy evaluation and version usage;
  • integration failures and unusual error patterns.

This does not mean that every event is public or that all telemetry is retained indefinitely.

Minimised evidence model​

A useful identity event may record:

  • event and transaction references;
  • actor, service, or organizational role;
  • timestamp and environment;
  • policy and credential-type references;
  • challenge or request identifiers;
  • authorization and verification outcomes;
  • key or algorithm references where relevant;
  • status transition;
  • evidence integrity reference;
  • error category and remediation state.

It should not record private keys, recovery secrets, full credentials, undisclosed claims, biometric templates, raw identity documents, access tokens, or ordinary user passwords.

Evidence chain​

High-value operations can produce a linked evidence chain connecting:

  1. the request and declared purpose;
  2. the policy version evaluated;
  3. the evidence sources considered;
  4. the authorization decision;
  5. the deterministic operation performed;
  6. the resulting artifact or status change;
  7. alerts, review, or remediation.

Integrity references and versioning help reviewers determine whether records were altered or separated from their original context.

Alerting and response​

An alert is useful only when it has an owner, severity, routing rule, expected response, and evidence source. Excessive low-quality alerts can hide important incidents.

Operational governance should distinguish:

  • availability degradation;
  • policy or trust failures;
  • suspected account takeover;
  • abnormal credential issuance or verification;
  • device or recovery anomalies;
  • key and signing risk;
  • data-handling or privacy incidents;
  • telemetry failure itself.

Customer-specific alert thresholds, detection rules, and response procedures remain controlled.

Privacy of observability​

Telemetry can become a secondary identity database if it contains stable identifiers, complete claims, wallet contents, or detailed presentation history.

Observability design should therefore apply:

  • scoped identifiers and pseudonymous references;
  • role-based access;
  • purpose-specific retention;
  • redaction and field allow-lists;
  • separation of security, business, and support data;
  • controlled export and investigation access;
  • deletion and legal-hold procedures;
  • monitoring for observability leakage.

AI-assisted operations​

AI may summarize, prioritize, and explain evidence, but deterministic systems remain authoritative for state, policy, and execution.

An AI-generated explanation should reference the underlying evidence and state its uncertainty. It must not claim that an action was performed merely because it recommended the action or operated in read-only mode.

Assurance and testing​

Institutions should test more than ordinary success paths. Evidence and monitoring should be exercised during:

  • credential and key rotation;
  • verifier dependency failure;
  • status-service interruption;
  • device compromise and revocation;
  • recovery drills;
  • backup and restoration;
  • policy rollback;
  • incident response and notification.

A control that cannot produce evidence during failure may be difficult to trust during a real incident.

Public documentation boundary​

The public portal does not expose private dashboards, alert thresholds, log queries, customer identifiers, incident timelines, vulnerabilities, on-call procedures, internal health endpoints, or detection logic.

See UbID Pulse, UbID Sentinel AI, and Security Model.