iam

Derivation profiles: decision before identity enrollment

Status: OPEN proposal. P0/P1/P2 are undefined discussion labels, not adopted profiles. IAM 1.1 still specifies identity KDF v1. This document changes no parameters, namespaces, keys, wire rules or test-vector expectations.

Decision and timing

Choose the identity-derivation design before a product issues real identities under it. Confirm whether any production keys, records, integrations or recovery instructions already depend on the published derivation; this repository is not an authoritative deployment inventory.

If no real identities depend on it, a new design can avoid migrating existing users’ keys. That does not remove versioning and implementation costs. A published derivation still needs an unambiguous name, exact inputs, archived old rules and new vectors. Wire v2 identifies record-validation rules; it does not prove how a signing key was derived.

Changing the KDF inputs or parameters generally changes the master seed and root public key. An old public key cannot supply the missing incantation or master seed to a migration tool. Users retaining the required secrets can derive a new key, but that key is a new identity. Software must not silently relabel the result as the old identity.

What is currently specified

KDF v1 uses Argon2id version 0x13, 65536 KiB total memory, three passes, parallelism 1, 32 output bytes, empty optional secret/associated data, the name-derived salt and HKDF namespace given in IAM.md.

There are no P0/P1/P2 parameter definitions or target-device measurements in this repository. Do not assume three profiles are necessary, map them to “bots / corporations / states”, or treat a profile label as a security result. First establish the user-secret model, intended devices, recovery workflow and acceptable latency/memory budget. A single well-defined profile remains a candidate if multiple profiles have no justified use cases.

Requirements for a concrete proposal

A PR proposing profiles must specify:

  1. Secret source and protection objective. State whether the input is a user-chosen phrase or generated secret, how unpredictability is obtained, what guessing costs are estimated, and which endpoint/coercion threats are outside the design. A higher KDF cost does not repair a disclosed secret.
  2. Exact derivation. Define each profile’s identifier, input encoding, algorithm/version, memory, passes, lanes, output lengths, optional inputs, salts and domain separation. Distinguish a KDF version from record wire version and from a UI label. Show positive and negative vectors.
  3. Selection and recovery. Explain how a user or another device selects exactly the same profile and retains the needed public metadata. Metadata integrity and its initial trust source must be explicit. A signature from a key discovered only by accepting that metadata does not, by itself, authenticate the initial choice. No silent fallback to a cheaper profile or automatic parameter tuning may change the identity.
  4. Cross-profile secret reuse. If the same phrase is used in a cheap and an expensive profile, the attacker knows the cheap profile’s public key, and its other derivation inputs are known or guessable, guesses can be checked cheaply there. After recovering the phrase, the attacker can derive the expensive identity once its remaining inputs, including name and any profile metadata, are known. Domain separation produces different keys; it does not isolate a reused secret from guessing.
  5. Measured implementation costs. Provide reproducible measurements on the lowest supported devices and relevant implementations, including peak memory, latency and resource refusal. Describe attacker-cost assumptions separately from honest-device timings; do not extrapolate a “state-proof” guarantee from a benchmark.
  6. Compatibility and rollout. Declare treatment of KDF v1, existing keys if any, profile discovery, unsupported profiles and migration of trust edges. Record the chosen design in an explicit specification release before enabling production enrollment. Have an outside implementer check recovery and exact-byte agreement, as well as record conformance.

Argon2 parameters are inputs to the derivation itself, including parallelism; they cannot be locally retuned while expecting the same output. RFC 9106 §3.2 defines that binding. HKDF domain separation binds uses of key material, but does not add entropy to the input secret. RFC 5869 §3

Identity and recovery architecture

The current identity model is deliberate: an identity is its root public key. Changing that key creates a new identity. Existing edges retain their original key endpoints; social recovery requests new acceptances rather than transferring old trust automatically. Device replacement through personal ACCEPT/REVOKE does not rotate the owner’s identity.

A stable random root seed encrypted under a changeable password-derived key would be a different design. It can change password protection without changing the root, but requires stored recovery material and an explicitly specified encryption/authentication and backup scheme. It must not be introduced silently as if it were the current stateless phrase-to-identity derivation.

Submit concrete alternatives through proposals/ with a threat-model mapping, measurements and recovery vectors. A proposal is not adopted because a label exists or a sample benchmark passes. See SECURITY.md and the threat model for the current protection boundaries.