iam

Release history and migration

Documentation follow-up — 2026-09-14

Added visible security limits, a separate threat model and explicit project/agent review provenance. Clarified that changing the root key creates a new identity, and that distinct Node/Python code paths are not an independently authored implementation or a proof of specification completeness.

Opened proposals for the derivation decision before enrollment and an outside implementation. P0/P1/P2 remain undefined and unadopted. This follow-up changes no KDF inputs, wire rules, graph outcomes or vector expectations; existing version tags remain unchanged.

iam-core 1.1 — 2026-09-14

This release incorporates the September external audit and project reviews. It defines wire version 2 while retaining the v1 identity-derivation namespace. It is a validation and wire revision, not a promise that every historical input remains accepted.

Profile identity is carried by the protocol

Component	iam-core 1.0	iam-core 1.1
Record field v	1	2
Record id domain	IAM1:id\0	IAM2:id\0
Signature domain	IAM1:record\0	IAM2:record\0
Community tree domain	IAM1:tree\0	IAM2:tree\0
Name salt prefix	iam:v1:name:	Unchanged
Root HKDF info	iam/v1/root-ed25519	Unchanged
Intended Argon2id derivation	64 MiB, t=3, p=1, 32 bytes	Same parameters, explicit version 0x13 and empty optional inputs
Canonical seal	Four words	Same wordlist and four words, explicit raw-key bytes

Changing only the community tree-hash domain would leave personal graphs without an intrinsic validation-version distinction. Wire v2 and all three new domains cover both contexts. No per-record configuration or signature-verifier fallback selects a weaker profile. The JSON field set stays the same size; its v value changes.

Normative changes

• Exact pure-Ed25519 point, subgroup, scalar and verification rules; reject weak identity keys while permitting valid identity-point R signatures.
• Explicit Argon2id/HKDF inputs, raw-byte seal input and technical incantation length bound.
• Closed record/envelope schemas and a separate six-field descriptor schema; exact number-token and base64 rules.
• Signature authentication before logical-id deduplication and fork evidence; alternate valid signatures do not create forks.
• Invalid predecessor chains propagate to descendants. Semantic operation failure alone does not break a valid chain. Signed backwards-time siblings still prove equivocation.
• The requested community’s genesis key is reserved from ordinary actions and acceptance.
• Each anchored set has one tree/context; explicit errors replace silent partial evaluation for malformed dependencies or mixed scopes. Legacy integer wire versions are input errors in the wire-v2 evaluator.
• Bounded quarantine and explicit signer coordination/head/monotonicity obligations.
• Complete single-publisher anchoring profile in ANCHORING.md, separate from core identity and without a distributed-consensus claim.

ACCEPT, REVOKE, community LEAVE, the DAG, multiple parents, edge-local revocation and permanent departure within one evaluation remain. Re-ACCEPT can restore still-active descendant edges. There is no new RETURN, rotation, quorum or six-word-seal primitive.

Explanations of Argon2 memory, bootstrap inclusion, axiomatic membership, phantom acceptance, time, compromise, privacy and revocation freshness were corrected. README and the public introduction now describe the implemented scope.

Migration

1. Preserve the original specification, bootstrap, records and authoritative anchors. The iam-core-1.0 tag remains unchanged. Do not rewrite old v fields, signatures or ids.
2. Validate existing keys against the new profile. Keys produced by the specified modern KDF retain their values; inputs produced by alternate derivations or incompatible key policies require explicit handling. No claim is made that every unknown implementation used the same derivation.
3. For a community, publish a new wire-v2 bootstrap with the intended valid root keys. Its tree id differs. Recreate intended acceptance relationships with new signed wire-v2 records; this is not automatic historical replay under relabeled ids.
4. For a personal graph, retain the owner’s valid public key as tree, but build a new wire-v2 record chain from empty prev. Wire-v1 records cannot serve as predecessors or device-acceptance proofs in that new history.
5. Distribute and authenticate the new bootstrap/anchor according to the selected runtime policy. Keep old/new graph contexts explicit and archived. A core upgrade does not silently migrate any live tree or change anyone’s social acceptance.

Public inspection at release preparation found specification files in this repository and GitHub Pages publishing from main. There is no authoritative live-tree or deployed-validator inventory in the repository. We do not assume there are zero external deployments or one harmless tree. This release publishes new rules and reference artifacts; it does not mutate external trees. Operators must inventory their own histories before adoption.

Verification

The published vectors include identity derivation, raw-byte seal, canonical records, bootstrap and 30 signed graph scenarios. Node/OpenSSL generates signatures and canonical/hash fixtures; a standard-library Python implementation independently checks Ed25519 arithmetic and graph results. Expected graph states are specified separately from the tested evaluator.

The Node Argon2 provider is checked against RFC 9106. Python independently checks SHA, HKDF, public-key derivation and seal, but does not independently implement Argon2. Reference tools do not implement the anchoring runtime or production resource management. CI runs vector regeneration checks and the Python suite.

See review resolution for the disposition of the final review and the review record for reproducibility of the original findings. Superseded proposal files are retained as labeled history.

iam-core 1.0

Published baseline: m=670625, commit fdbfe854, tag iam-core-1.0. Later README and introductory prose at 9e95c989 did not change that core text.