We care about four major lifecycle phases:

1. Creation
   • User creates a Vault.
   • Key Tree, Attribute Tree, and Policy Tree are initialized.
   • Initial identity_commitment is derived.
   • A LivreID (e.g., odin.livre) may be reserved and bound to the commitment.
2. Update
   • Attributes are added/changed/expired.
   • Keys are rotated or new devices added.
   • Policies are updated (e.g., allow bank X to request income proof).
   • Trees are recomputed → new roots → new identity_commitment.
3. Recovery
   • Control keys are lost or compromised.
   • Recovery process uses recovery keys and Vault backup.
   • A new Key Tree is created and bound to existing attributes/policies.
   • A new identity_commitment is produced, but the identity continuity is preserved.
4. Revocation / Sunset
   • In extreme cases (fraud, legal reasons, user request), an identity can be marked as revoked or sunset.
   • The last identity_commitment is flagged in revocation registries.
   • The Vault can still keep encrypted data, but no new proofs are issued.

Identity Continuity

Each new identity_commitment references the previous one via an identity history chain stored in the Vault:

identity_history = [
    commitment_v1,
    commitment_v2,
    ...,
    commitment_vN
]

Verifiers don’t need the full chain by default, but advanced flows (compliance, forensics, audits) MAY request proof that:

• the current commitment is derived from a given previous one
• certain changes happened within certain rules.