# 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](../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](https://www.rfc-editor.org/rfc/rfc9106.html#section-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](https://www.rfc-editor.org/rfc/rfc5869.html#section-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](../SECURITY.md) and the
[threat model](../THREAT-MODEL.md) for the current protection boundaries.