Skip to content

Identity Attestation Methods and Mapping in DIA

Document Status

Field Value
policy-id DIA-ATTEST-PROVIDERS-001
type Implementing act / attestation-method registry
version 0.2.0-draft
date 2026-03-31
changes Added software-pinned source class with strength sovereign and max IAL5; clarified that sovereign is not an attestation-chain method.

1. Purpose

This document maps identity-attestation methods to:

  • attestation-strength class (weak / strong),
  • maximum IAL,
  • operational limits,
  • requirements for upgrade and refresh.

It does not create a new kind of root-identity. It defines only the quality of attestation of the identity source.

2. General Rules

  1. weak, strong, and sovereign are properties of the assurance source, not of personhood.

  2. The same anchor-identity may have many attestations of different strength over time.

  3. A weak -> strong upgrade SHOULD preserve anchor-identity, node-id, and persistent_nym if proof of continuity of control exists.

  4. The maximum IAL of a method is the default ceiling; a federation may lower it, but should not raise it without an explicit validation procedure.

3. Default Mapping

source_class Example Strength Default max IAL Notes
phone phone number with OTP confirmation weak IAL1 IAL2 only through an explicit opt-in federation policy and added safeguards
multisig-basic k-of-n vouching without deeper attester audit weak IAL2 fallback for jurisdictions without strong eID
multisig-audited k-of-n vouching with audit, diversity, and attester accountability strong IAL3 does not unlock IAL4 without a separate unsealing track
eid state or supranational eID strong IAL3 to IAL4 only when paired with an unsealing track
mobywatel official QR / state app channel strong IAL3 locally jurisdiction-dependent
epuap trusted profile / official channel strong IAL3 depends on integration quality
qualified_signature qualified signature strong IAL4 preferred for high-stakes roles
registry formal registry data of an organization strong IAL3 to IAL4 after meeting procedural requirements
software-pinned public key compiled into a signed software release or pinned in a signed deployment configuration distributed with the release sovereign IAL5 not an attestation method; confers governance-level trust anchor designation; assignment through software release governance, not through identity proofing; orthogonal to IAL0–IAL4
other local / experimental method depends on validation IAL0-IAL2 requires explicit federation documentation

Note on sovereign strength class. sovereign is not a stronger form of strong attestation. It is categorically different: the trust derives from explicit key pinning in the software distribution and its release governance process, not from any verification of the key holder's real-world identity. A sovereign-class source does not satisfy identity-proofing requirements for roles that specify IAL1–IAL4. It applies only where a role or policy explicitly names IAL5 or sovereign trust anchor status.

4. Special Rules for Phone Numbers

  1. A verified phone number is convenient for entry, but SHOULD NOT by itself unlock high-stakes roles.

  2. For source_class = phone, a federation SHOULD at minimum restrict:

  3. governance roles,

  4. panel roles,
  5. high-stakes oracle roles,

  6. operations requiring U2 or U3.

  7. A federation MAY allow phone -> IAL2 only through an explicit opt-in policy and only when there are additionally:

  8. a longer reputational maturation period,

  9. takeover-anomaly detection,
  10. influence-multiplication limits,

  11. the ability to downgrade quickly after a compromise signal.

  12. A phone -> strong upgrade SHOULD pass through a waiting period (phone_upgrade_cooldown) and anomaly checks consistent with IDENTITY-UPGRADE-ANOMALY-SIGNALS.md.

Default safe profile:

  • phone_upgrade_cooldown = 14 days,

  • no active recovery in the short window preceding the upgrade,

  • no abrupt rotation of stations, nyms, or node keys,

  • no active identity dispute, takeover signal, or open incident,

  • no fresh phone-number or attestation-source change without additional review.

5. Upgrade Rules

  1. A weak -> strong upgrade requires, at the same time:

  2. control over the existing anchor,

  3. a new strong attestation,

  4. no hard identity dispute.

  5. After the upgrade:

  6. anchor-identity remains the same,

  7. node-id may remain the same,
  8. ephemeral nyms and station certificates may be refreshed,

  9. the prior attestation remains in the audit chain as superseded or expired.

  10. If the upgrade starts from source_class = phone, a federation SHOULD at minimum trigger:

  11. age check of the phone attestation,

  12. device and station churn check,
  13. geographic or network anomaly check when such signals are available,
  14. review of recent recovery attempts, key resets, and revocations,
  15. manual review for roles that would enter IAL3+ after the upgrade.

6. Relations to Other Documents

  • ROOT-IDENTITY-AND-NYMS.md defines identity layers and IAL levels.
  • IDENTITY-ATTESTATION-AND-RECOVERY.md defines attestation memory and upgrade.
  • ROLE-TO-IAL-MATRIX.md defines which roles can be unlocked at a given IAL.
  • IDENTITY-UPGRADE-ANOMALY-SIGNALS.md defines the minimum catalog of signals, responses, and review for attestation upgrade.