Skip to content

Identity Attestation and Recovery in DIA

Document Status

Field Value
policy-id DIA-ID-REC-001
type Implementing act (Level 3 of the normative hierarchy)
version 0.1.0-draft
basis Art. III.1-9, VII.4-8, XVI of the DIA Constitution; ROOT-IDENTITY-AND-NYMS.md
mechanism status the flow and data model are normative; KDF choice and parameters remain deployment details

1. Purpose of the Document

This document defines:

  • the first attestation of root-identity,
  • creation of anchor-identity,
  • the role of the recovery phrase,
  • the role of salt and KDF parameters,
  • memory of prior attestation,
  • recovery and reconstruction of anchor-identity,
  • identity-data update,
  • compromise classes, revocation, and rotation,
  • minimum KDF profiles and parameter-migration policy.

Its purpose is to combine three properties:

  • strong anchoring in root identity,
  • the ability to recover derived identity without repeating full onboarding,
  • minimization of stored civil data within swarm infrastructure.

This document assumes that one anchor-identity may have many successive or coexisting attestation records over time, with different strengths (weak / strong), without breaking identity continuity.

2. Core Principles

  1. anchor-identity MUST be derived from:

  2. normalized identity data used during the first attestation,

  3. a recovery secret derived from a word phrase,

  4. random salt,

  5. explicit KDF parameters.

  6. salt is not a secret. It differentiates derivation and protects against precomputation. The system SHOULD store it itself so that the user does not need to remember it.

  7. The recovery phrase is the user's secret. The system MUST NOT store it in plaintext or in a reversible form.

  8. After a successful first attestation, the system SHOULD remember that a given anchor-identity has already been anchored by a method with a defined IAL. Later recovery NEED NOT require repeated use of DigitalID, mObywatel, qualified signature, or vouching, provided cryptographic continuity and attestation validity remain intact.

  9. The system SHOULD NOT store full civil data if the following are sufficient:

  10. a reference to the attestation,

  11. lookup_tag,

  12. salt,

  13. KDF parameters,

  14. validity status and IAL.

  15. A weak -> strong attestation upgrade SHOULD raise the strength and maximum IAL of an existing anchor-identity, rather than create a new anchor, provided the user proves control over the current anchor and supplies a new strong attestation.

3. Conceptual Model

3.1. Flow

root-identity claims
  + recovery phrase
  + salt
  + kdf_params
    -> recovery_secret
    -> anchor-identity
      -> node-id

3.2. Role Separation

Element Nature Stored by
root-identity claims input data for attestation user / attesting authority
recovery phrase user secret user
salt differentiating, non-secret parameter system, optionally user
kdf_params public security parameter system
lookup_tag record lookup marker system
anchor-identity stable derived identity system

3.3. The Role of salt

salt:

  • is not a password or a second secret,
  • does not by itself enable reconstruction,
  • is needed for reconstructing anchor-identity,
  • SHOULD be stored in the system record,
  • MAY also be exported to the user as part of the recovery bundle.

The practical rule is simple: the user does not need to store salt, but may do so for an independent backup.

4. First Attestation

4.1. Input

During first attestation, the user provides:

  • the data required by the chosen attestation method,
  • the material needed to normalize identity claims,
  • a locally generated recovery phrase or consent to have it generated by the client,
  • optional helper data for exporting a recovery bundle.

4.2. Steps

  1. The system or client normalizes the input into normalized_claims.

  2. A random salt is generated.

  3. recovery_secret is derived from the recovery phrase.

  4. anchor-identity is computed:

  5. by a KDF resistant to guessing and costly to evaluate,

  6. from normalized_claims + recovery_secret + salt + kdf_params.

  7. An attestation record and an anchor-identity record are created.

  8. The user receives an optional recovery bundle.

4.3. Result

After success, the system remembers:

  • that this anchor-identity has already been attested,
  • by which method,
  • at which IAL,
  • until when the attestation is valid,
  • whether refresh is required.

5. Attestation Memory

The system maintains memory of prior attestation as a record referring to anchor-identity, not to raw civil data.

5.1. Attestation Memory Record

identity_attestation_memory:
  attestation_id: "[unique identifier]"
  anchor_identity_ref: "[reference]"
  lookup_tag: "[lookup marker]"
  lookup_domain: "person:v1"
  pepper_id: "[identifier or null]"
  attestation_strength: "strong" # weak | strong
  source_class: "mobywatel"      # phone | multisig-basic | multisig-audited | eid | mobywatel | epuap | qualified_signature | registry | other
  assurance_level: "IAL3"
  method: "mobywatel"        # mobywatel | epuap | qualified_signature | multisig-basic | multisig-audited | other
  status: "valid"            # valid | expired | revoked | superseded
  issued_at: "[ISO 8601]"
  valid_until: "[ISO 8601]"
  evidence_ref: "[evidence reference]"
  salt_ref: "[salt reference]"
  kdf_params_ref: "[parameters reference]"

5.2. lookup_tag

lookup_tag is used to find the correct record without storing full civil data as the lookup key.

It should be computed from:

  • normalized_claims,
  • an optional federation or domain pepper,
  • an explicit hashing algorithm.

lookup_tag should not, by itself, enable easy cross-federation correlation.

5.3. lookup_tag Contract

lookup_tag SHOULD be computed according to:

lookup_tag = H(
  lookup_domain
  || canonical(normalized_lookup_claims)
  || pepper_or_empty
)

Where:

  • lookup_domain distinguishes record classes and uses,
  • normalized_lookup_claims is only the minimal subset of claims needed to find the record,
  • pepper_or_empty is a federation or domain pepper, if one is used.

normalized_lookup_claims SHOULD NOT contain excess civil data. In particular:

  • for a natural person, it should contain only the minimal stable set of claims used during first attestation,
  • for an organization, it should contain the minimal set of registry or organizational data.

5.4. pepper

A federation MAY use a pepper to limit correlation of lookup_tag across federations or domains. If pepper is used:

  1. It MUST be stored as a system secret outside the user record.

  2. It MUST have its own pepper_id and validity window.

  3. It MUST NOT be exported with the recovery bundle.

  4. Changing pepper MUST trigger either reindexing of lookup_tag or a grace period during which at least two pepper versions are accepted.

  5. Raw lookup_tag SHOULD NOT be transferred across federations as an interoperability artifact.

6. Recovery

6.1. Minimum User Input

To recover anchor-identity, the user supplies:

  • the same or semantically equivalent identity data used during the first attestation,
  • the recovery phrase.

The user does not need to supply salt if the system preserved the attestation memory record.

6.2. Recovery Steps

  1. The system normalizes the input into normalized_claims.

  2. The system computes lookup_tag and finds the memory record.

  3. The system retrieves salt and kdf_params.

  4. recovery_secret is derived from the user's phrase.

  5. anchor-identity is reconstructed.

  6. The system compares the result with the stored record.

  7. If the attestation record remains valid, the user regains continuity without repeated full root-identity attestation.

6.3. When Re-attestation Is Required

Re-attestation is required when:

  • the record status is expired or revoked,
  • there is a dispute about the integrity of the prior attestation,
  • federation policy requires refreshing IAL3 or IAL4,
  • recovery concerns a role that requires fresh anchoring evidence.

7. Recovery Bundle

The system SHOULD allow the user to export a recovery bundle, but it must not require that bundle as the sole method of reconstruction.

7.1. Minimum Contents

recovery_bundle:
  anchor_hint: "[short hint identifying the record]"
  salt: "[salt]"
  kdf_params:
    algorithm: "argon2id"
    memory_cost: 262144
    time_cost: 3
    parallelism: 1
  attestation_id: "[reference]"
  issued_at: "[ISO 8601]"

7.2. Rules

  1. The recovery bundle does NOT contain the recovery phrase.

  2. Loss of the bundle must not, by itself, make recovery impossible if the system preserved the memory record.

  3. Possession of the bundle without the phrase and without correct identity claims does not grant the right to take over the identity.

8. Identity Data Update

Changes in civil data, such as surname, organization name, or registry number, should not automatically destroy identity continuity.

8.0. Attestation-strength upgrade

The system SHOULD allow transition from weak to strong attestation without rotating anchor-identity, node-id, or persistent_nym, if all of the following hold:

  • control over the existing anchor or over the node-id derived from it,

  • a new strong attestation,

  • no hard signals of compromise or identity dispute.

If the upgrade starts from source_class = phone, a federation SHOULD also require:

  • expiry of phone_upgrade_cooldown since the first attestation or the latest material identity change,

  • no active recovery or fresh key reset,

  • station, nym, and device churn checks,

  • geographic, network, or behavioral anomaly checks when such signals are available,

  • manual review when the upgrade result would unlock IAL3+ roles.

8.1. Procedure

  1. The user initiates identity_update.

  2. The system links:

  3. the old anchor-identity,

  4. the new set of normalized_claims,

  5. a valid or refreshed attestation.

  6. This produces:

  7. a new attestation memory record,

  8. possible marking of the prior attestation as superseded,

  9. a migration trace,

  10. continuity of accountability and reputation.

8.2. Rule

A change in civil data must not be treated either as an automatic reset of reputation or as sufficient grounds to create a new, unrelated anchor-identity.

8.3. Effect of a weak -> strong upgrade

  1. anchor-identity remains the same.

  2. node-id and persistent_nym may remain unchanged.

  3. Ephemeral nyms, station certificates, and session material MAY be refreshed so that further communication points to the stronger anchoring.

  4. The history of the earlier weak attestation remains in the audit chain.

9. Revocation and Compromise

9.1. Revocation

An attestation record or anchor-identity record may be revoked when:

  • false attestation is established,
  • theft or compromise of the recovery phrase is established,
  • there is hard evidence of abuse of the recovery track,
  • a lawful constitutional or legal procedure requires it.

9.2. Effect

Revocation may cause:

  • reduction of IAL,
  • temporary suspension of node-id,
  • a requirement for fresh attestation,
  • rotation of nyms and stations,
  • activation of the incident procedure.

9.3. Compromise Classes

Class Description Minimum response
C1 Suspected loss of secrecy of the recovery phrase without hard proof suspend the recovery track, increase monitoring, require additional verification
C2 Hard proof of theft of the recovery phrase or recovery_secret revoke the recovery track, rotate anchor-identity, review related node-id values
C3 Compromise only of node-key or the main node-id key rotate node-id, nyms, and stations; anchor-identity may remain
C4 Compromise of one or more stations without signs of higher-layer compromise revoke station_delegation, analyze harm, no automatic anchor-identity rotation
C5 False root-identity attestation or failure in the attestation channel revoke attestation, lower IAL, possibly invalidate anchor-identity
C6 Abuse of the recovery procedure or bypass of unsealing thresholds suspend the recovery track, audit, possible procedural and legal sanctions

9.4. Rotation Matrix

  1. Station compromise (C4) should not by itself force rotation of node-id or anchor-identity.

  2. node-key compromise (C3) SHOULD lead to:

  3. a new node-id,

  4. rotation of active nyms,

  5. renewal of station certificates,

  6. preserved continuity of accountability through the common anchor-identity.

  7. Recovery-phrase compromise (C2) SHOULD lead to:

  8. revocation of the old recovery track,

  9. generation of a new phrase,

  10. a new salt,

  11. a new anchor-identity,

  12. controlled rebinding of active node-id values or their rotation according to federation policy.

  13. False attestation or compromise of the attestation channel (C5) SHOULD be treated as a breach of the anchoring layer and may require:

  14. full re-attestation,

  15. freezing of high-stakes roles,

  16. invalidation of derived node-id values.

  17. Every rotation MUST leave an audit-track trace linking the old and new identity layers, but NEED NOT create a public correlation between old and new operational masks.

10. Data Model

10.1. Minimum KDF Profiles

The default algorithm SHOULD be argon2id.

Profile Minimum use case memory_cost time_cost parallelism
KDF-S low cost, constrained devices, no high-stakes roles 65536 3 1
KDF-M default profile for most users and IAL2-IAL3 262144 3 1
KDF-H high-stakes roles, IAL4, privileged recovery 524288 4 1

Federations MAY raise these minima, but may not go below them for a given profile.

10.2. KDF Parameter Migration Policy

  1. The KDF record MUST be versioned.

  2. The system MUST be able to verify an older profile during a migration window.

  3. Upgrading the KDF profile SHOULD happen:

  4. on successful recovery,

  5. on a significant change of role or IAL,

  6. during planned federation security migration.

  7. The system MUST NOT automatically downgrade the KDF profile for an existing identity.

  8. If the record uses a weaker profile than required for the current role, the federation SHOULD require migration before allowing that role.

  9. KDF migration SHOULD NOT by itself change anchor-identity, unless normalized_claims, the recovery phrase, or salt also change.

10.3. KDF Parameters

kdf_params_record:
  kdf_params_id: "[identifier]"
  profile: "KDF-M"
  version: 1
  algorithm: "argon2id"
  memory_cost: 262144
  time_cost: 3
  parallelism: 1
  output_length: 32
  created_at: "[ISO 8601]"

10.4. pepper Record

pepper_record:
  pepper_id: "[identifier]"
  scope: "federation"        # federation | domain
  status: "active"           # active | grace | retired
  valid_from: "[ISO 8601]"
  valid_until: null

10.5. salt Record

salt_record:
  salt_id: "[identifier]"
  salt_value: "[encoded random bytes]"
  created_at: "[ISO 8601]"
  rotate_at: null

10.6. Recovery Record

identity_recovery_record:
  recovery_record_id: "[identifier]"
  anchor_identity_ref: "[reference]"
  lookup_tag: "[lookup marker]"
  lookup_domain: "person:v1"
  pepper_id: "[identifier or null]"
  salt_ref: "[reference]"
  kdf_params_ref: "[reference]"
  attestation_id: "[reference]"
  recovery_status: "enabled"      # enabled | suspended | revoked
  last_recovered_at: null
  last_recovery_channel: null

10.7. Attestation Chain Record

attestation_chain_record:
  chain_id: "[identifier]"
  anchor_identity_ref: "[reference]"
  current_attestation_id: "[reference]"
  prior_attestation_ids:
    - "[reference]"
  strongest_attestation_strength: "strong" # weak | strong
  current_max_ial: "IAL3"
  continuity_proof_ref: "[proof of control over the prior anchor]"
  upgrade_cooldown_profile: "phone-default-14d"
  anomaly_check_ref: "[reference or null]"
  updated_at: "[ISO 8601]"

11. Relation to Other Documents

  • ROOT-IDENTITY-AND-NYMS.md: that document defines the identity layers; this act specifies how anchor-identity is created and recovered.
  • PANEL-SELECTION-PROTOCOL.md: audits and panels may use custodian_ref, while going down to root-identity requires the unsealing track.
  • ABUSE-DISCLOSURE-PROTOCOL.md: disclosure of root identity must respect minimal disclosure and high-stakes thresholds.
  • PROCEDURAL-REPUTATION-SPEC.md: high-stakes eligibility depends on the validity of attestation memory and current IAL.
  • ATTESTATION-PROVIDERS.md: this document maps attestation methods to weak / strong classes, maximum IAL, and operational limits.