Skip to main content

Privacy by Design

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

Privacy by design means that privacy is expressed through the identity architecture, credential schemas, verification requests, retention rules, and operational evidence—not added later as a notice or preference screen.

UbID is designed to support identity operations in which institutions can receive trustworthy evidence while collecting less underlying personal data. Credentials remain under holder control, disclosures can be scoped to a purpose, and different participants receive only the information needed for their role.

Core privacy principles

Purpose before collection

A verifier should define why evidence is required before requesting it. The declared purpose helps determine:

  • which credential or claim is appropriate;
  • whether full identification is necessary;
  • which attributes may be disclosed;
  • how long evidence or receipts should be retained;
  • which institution is responsible for the resulting decision.

A broad request for "identity data" is not a sufficient policy. The request should describe the specific trust question being answered.

Proportional disclosure

Many transactions do not require an entire identity profile. A service may need confirmation that a person is over an age threshold, holds an active qualification, is resident in a permitted jurisdiction, or is authorized to represent an organization.

UbID supports presentations that disclose the relevant evidence without automatically providing unrelated claims or a complete source document.

Holder agency

The holder should be able to understand:

  • who is requesting evidence;
  • what information is requested;
  • the stated purpose;
  • which credential will be used;
  • what will be disclosed;
  • whether the presentation is optional or required for the service.

Holder authorization does not remove the institution's legal and ethical responsibilities. Consent is not automatically the correct lawful basis for every identity operation, especially where participation is mandatory or power is unequal.

Reduced duplication

The strongest privacy contribution is not a larger central identity repository. It is the ability to validate signed evidence without requiring every verifier to retain another copy of the complete source document or profile.

Where retention is legally or operationally necessary, the institution remains responsible for defining the scope, period, access controls, deletion process, and rights workflow.

Scoped identifiers

A universal identifier used everywhere can make unrelated interactions easy to correlate. UbID favors identifiers and references that are appropriate to a participant, relationship, credential, device, or transaction context.

This does not guarantee unlinkability in every deployment. Institutions must also avoid combining logs, metadata, and external data in ways that recreate unnecessary surveillance.

Privacy across the trust lifecycle

Lifecycle stagePrivacy control objective
ProofingCollect only source evidence necessary for the approved assurance level.
IssuanceUse minimal, purpose-appropriate credential schemas.
CustodyKeep credentials and sensitive documents under protected holder control.
PresentationRequest and disclose only necessary claims.
VerificationProduce an explainable result without exposing unrelated wallet contents.
StatusCommunicate validity without publishing sensitive reasons or personal history.
RecoveryUse strong evidence while preventing custodians from learning the complete secret.
OperationsRecord decisions and outcomes without logging credentials, biometrics, or secret material.

Rights and lifecycle governance

A privacy-preserving architecture must support operational procedures for access, correction, suspension, revocation, deletion, restriction, objection, and portability where applicable.

A signed credential is an immutable artifact, so correction normally requires a new version, replacement, or status change rather than silently editing the original signature. Institutions should preserve the reason and authorization for lifecycle actions while limiting exposure of the underlying personal details.

What UbID does not replace

A UbID deployment still requires:

  • a documented lawful basis for each processing purpose;
  • accurate privacy notices and institutional policies;
  • controller, processor, issuer, verifier, and custodian role allocation;
  • retention and deletion schedules;
  • data-subject request procedures;
  • impact assessments for high-risk processing;
  • transfer and vendor controls;
  • incident response and regulatory notification;
  • local legal and sector review.
Compliance language

UbID can support privacy and compliance controls. It does not make an institution compliant by itself, and this documentation is not a certification or legal opinion.

See Data Minimisation, Selective Disclosure, and Data Lifecycle and Rights.