Data Lifecycle and Individual Rights

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

Identity systems contain several related but distinct records. Deleting one object does not automatically revoke another, erase a third party's lawful record, or remove an immutable public reference.

UbID governance therefore separates account, credential, wallet, presentation, evidence, biometric, and institutional-record lifecycles.

Distinct lifecycle actions

Action	Meaning	Typical decision owner
Delete local credential	Remove the holder's local copy	Holder or wallet policy
Revoke or suspend credential	Change the issuer-managed validity or status	Issuer under credential policy
Delete wallet or local vault	Remove local custody data and keys according to the approved process	Holder and wallet service
Close service account	End the contractual or operational account relationship	Service provider
Correct claim	Update source data and, where required, replace or reissue a credential	Authoritative source and issuer
Delete proofing or biometric evidence	Remove evidence according to purpose, retention, dispute, and legal obligations	Institution controlling the processing
Delete verifier receipt	Remove or minimize the relying party's retained transaction evidence	Verifier or relying party
Exercise a privacy right	Request access, correction, deletion, restriction, objection, portability, or review under applicable law	Responsible controller or institution

These actions may be coordinated, but they are not interchangeable.

Lifecycle data classes

Holder-controlled data

May include credentials, local keys, consent history, registered devices, recovery references, and wallet preferences. Holder control does not eliminate the issuer's status record or the relying party's independent obligations.

Issuer data

May include source evidence, issuance decision, credential identifier, schema and policy version, status, renewal, replacement, revocation, and dispute records.

Verifier and relying-party data

May include the request, purpose, disclosed claims, verification result, decision, retention class, and review or appeal evidence. A verifier should not retain the complete credential or source document when a minimized result is sufficient.

Operational and security evidence

May include timestamps, actor and service references, challenge state, policy version, outcome category, integrity references, incident evidence, and access records. Secret material and unrelated personal content should be excluded.

Public or distributed references

Public identifiers, public keys, status references, or ledger commitments may have different correction and erasure properties. Personal data, biometric templates, credential payloads, recovery shares, and presentation histories should remain off public ledgers.

Rights-routing model

A person should not have to understand internal service topology to exercise a right. The entry point should route the request to the responsible participant.

A rights workflow should:

1. authenticate the requester proportionately;
2. identify the person, role, jurisdiction, and relevant processing;
3. classify the request and statutory timeline;
4. locate issuer, wallet-service, verifier, custodian, and operational records;
5. apply legal holds, fraud, security, public-record, or contractual restrictions where valid;
6. coordinate correction, deletion, restriction, export, review, or explanation;
7. notify relevant processors or recipients where required;
8. record the response and unresolved disputes;
9. avoid disclosing another person's data, secrets, or security-sensitive information.

Access and transparency

A meaningful access response may distinguish:

• information supplied by the person;
• claims issued by an institution;
• credentials stored under holder control;
• presentation events and recipients;
• verification and decision records;
• devices and authentication methods;
• recovery and custodian events;
• retention schedules and deletion status;
• processors, transfers, and sources where applicable.

Correction and credential replacement

A signed credential cannot usually be edited in place without invalidating its proof. Correction generally requires:

1. update or validate the authoritative source;
2. suspend, revoke, or supersede the inaccurate credential as appropriate;
3. issue a corrected credential;
4. deliver it to the holder;
5. preserve only the historical evidence required for accountability;
6. notify relevant participants where law or contract requires it.

Deletion and retention

Deletion decisions should consider:

• purpose completion;
• credential and account lifecycle;
• security and fraud prevention;
• legal claims and disputes;
• statutory or public-record duties;
• audit and certification evidence;
• biometric destruction requirements;
• backups and restoration windows;
• processor and subprocessor deletion;
• distributed or public references.

A retention schedule should identify the data class, owner, purpose, start event, period, legal source, deletion method, evidence of deletion, and exception process.

Portability

Portability can involve different artifacts:

• a holder-controlled credential;
• an export of account or wallet metadata;
• a standardized presentation to another service;
• a machine-readable copy of personal data supplied or generated under applicable law.

Credential interoperability does not automatically satisfy every statutory portability requirement, and a statutory export does not necessarily provide a usable verifiable credential.

Restriction, objection, and automated decisions

A deployment should support policy states that can:

• pause processing while accuracy or authority is reviewed;
• prevent a credential or attribute from being used for a disputed purpose;
• route a decision to human review;
• record an objection or appeal;
• preserve evidence without continuing unrelated processing;
• explain the principal policy and evidence categories used in a consequential decision.

Recovery and deletion

Recovery is intended to restore legitimate access. It must not be used to bypass a deletion, suspension, restriction, or account-closure decision. After recovery, keys, devices, sessions, and recovery state may need rotation or reauthorization.

Public limitations

This portal explains lifecycle concepts. Exact retention periods, legal-hold rules, identity-verification methods for rights requests, processor inventories, and exception procedures remain deployment-specific controlled documentation.

See Credential Lifecycle, Recovery and Continuity, and Biometric Governance.