Human Identity in ICN — a first-principles architecture

What a human identity should be in ICN, how cryptographic authority over it should evolve, what institutions and peers should observe, and how devices act for humans.

Truth status, section by section. No section is left unclassified; §20 is the full per-result index.

Sections	Status	Meaning
§1	summary	restates results established or recommended below; carries no independent authority
§2	normative	requirements adopted for this analysis, each labelled HARD / STRONG / SOFT. They are chosen, not discovered — a reader may reject one, and §7's verdict may move if they do
§3	descriptive	verified at b26bf681 with file:line citations. Load-bearing rows re-read by hand; §3.0 marks which
§4	ESTABLISHED — derivation over §3	the decomposition, and the proof that a durable subject identifier cannot be a public key. It follows from §2's requirements plus §3's facts and holds unless one of those is rejected
§5	ESTABLISHED as a diagnosis; REJECTED as a verdict on Model A	that the six blockers share one cause is a derivation over §3, checkable by re-tracing each row. The consequent rejection of key-derived durable identifiers is a design decision, recorded REJECTED in §20
§6	mixed, per claim	§6.1 is RECOMMENDED on a bounded argument (not ESTABLISHED — see the caveat there); §6.2–§6.3 are ESTABLISHED external results; §6.4–§6.5 are summaries
§7 onward	PROPOSED architecture	design, not implementation

No claim here asserts production operation, pilot readiness, or institutional adoption. Prose that reads like a fact but is not classified ESTABLISHED is a defect in this document.

Relationship to PRINCIPAL_MODEL.md. That document's §1–§3 (the invariant, the verified current state, the classification of historical intent) remain the best evidence map in the repo and are retained; §3.0 below lists the corrections this pass found in them. Its §4–§16 (the proposed four-class taxonomy, member-origin signing via a carried DeviceAuthorization, and the A0→A→B→D slice program) are superseded by this document — not because they were careless, but because the open decisions they accumulated (O8, O9, O13, O16, O17, O18) turned out to be six symptoms of one structural choice, which §5 identifies and §6 removes.

Adversarial review, and what it changed. This document was attacked on ten axes before publication (hidden clocks, hidden arrival-order dependence, hidden correlation, hidden permanent root, hidden registry, claims-vs-source, proposed-as-current, invented protocol, internal contradiction, unmet HARD requirements). It found nine blocking errors, all of which are corrected in place with the correction marked rather than silently removed. The four that most changed the result: (1) pre-rotation constrains rotations only, so a compromised current key can still fork a non-establishment event (§6.2); (2) the impossibility claim was overstated and is downgraded from ESTABLISHED to a bounded argument (§6.1); (3) under the default recovery path, continuity-root compromise is a takeover and is unrecoverable (§12.2); (4) the class-1 fallback is a known R5.1 violation, not a safe default (§9.3).

Round 2 attacked the replicated state model specifically and found seven more blockers, all corrected: (5) the durable element must be a canonical body, not an event — Ed25519 admits several valid signatures per message, so an event-keyed set is really a map with an undefined value merge (§9.2.1); (6) σ and prev_digest must use the body digest too, or a re-signing mints a second SubjectId and a child can name a discarded parent (§9.2.1); (7) pre-rotation commits to the next key set, not the body, so rotation bodies must be deterministic or an honest crash-retry halts the subject permanently (§9.2.1); (8) independent M-of-N guardian signatures give any M guardians a kill switch, making threshold signing a prerequisite rather than an upgrade (§12.2); (9) a single compromised current key halts a subject unilaterally, and superseding recovery orphans the entire suffix (§9.2.1, §9.2.2); (10) class-2 settlement is not convergent under a fork — Live(A) → Live(B) leaves permanently different settled state, so this model is not by itself a sufficient basis for irreversible settlement (O-N7); (11) the durable set is attacker-writable, so eviction must be protocol-specified or convergence-under-attack is vacuous (O-N8).

Round 3 found two more: (12) a position bound does not stop spam at frontier + 1 from evicting the legitimate next event — eviction must be authority-aware, and the gap region beyond the frontier remains unsolved, so R4.6 and permutation-invariant convergence hold only absent adversarial storage pressure (§9.2.1, O-N8); (13) an existing did:icn:<key> cannot serve as a SubjectId, because inception admission requires σ == event_id(b) — migration must allocate a new subject naming that DID as its initial key, plus a membership bridge (§15.1).

Round 4 refuted two more claims: (14) the position validity window bounded nothing as specified — the signer chooses the position an act references, so a compromised device keeps referencing its original position forever. It binds only against an evaluation position the signer does not control, which exists for class 1 (once O-N6 lands) and not at all for class 2 (§9.3); (15) superseding recovery orphans historical authorization evidence, so R2.3 is qualified: receipts from orphaned positions keep a verifying signature but degrade from "authorized" to "authored on a superseded branch" (O-N9).

Round 5 found three more: (16) FROST alone does not remove the guardian kill switch — a group key authenticates a quorum but does not bind it to one message, so closing it needs enforced canonical body derivation plus one next-authority commitment per position (§9.2.1 constraint 3); (17) §9.4's normative verification flow still checked the signer-chosen position after round 4 fixed only the narrative (§9.4 step 4); (18) deriving the initial device key from SubjectId is a fixed point — S = H(inception(KDF(secret, S), …)) — so genesis is uncomputable; the initial key must derive from a pre-subject context nonce (§11.1).

§9.6 lists every shortfall the model does not discharge.

Related, deferred to, not restated: authenticated-governance-replication (#2469 — the convergence doctrine this design must satisfy) · AUTHORITY_SPINE (attenuation / revocation lifecycle) · MEMBER_STANDING (the derived read model) · KERNEL_APP_SEPARATION (the Meaning Firewall) · passport-keyring-position-receipt (vocabulary doctrine)

1. The executive answer

A human identity in ICN should not be a globally published identifier at all.

It should be three separable things, and ICN's current difficulty comes almost entirely from having collapsed them into one 32-byte string:

The person is not any one of these. The person is the human who holds the continuity root and, through it, organizes a set of context relationships, each of which is currently exercised by one or more device keys.

Three consequences follow immediately, and they are the substance of this document:

1. Did should mean exactly one thing — a cryptographic principal (a public key). Every other use of it today (privacy anchor, treasury identifier, stable subject across rotation, credential subject) is type reuse that the type cannot support, and §3 shows it failing in production code.

2. Authority to act for a subject evolves in a log the subject alone writes, and each institution decides for itself how fresh that log must be. The subject keeps a single-writer key-event log; the institution is the relying party that holds a copy and sets its own recency bar. Neither owns the other: the person cannot force an institution to accept them, and the institution cannot rewrite who the person is. #2469 §9 already reached the neighbouring conclusion for key rotation ("v1 treats rotation and revocation as membership changes"); §6 shows what it generalizes to. That generalization dissolves two blockers (O8, O18), partly answers two (O13, O17), narrows one (O16), and rejects one as posed (O9) — see §6.5, which is the authoritative summary.

3. There is no convergent global device revocation, and there cannot be one without paying a price ICN has declined to pay. Agreeing on a time-varying predicate across an asynchronous partition-tolerant network requires a synchrony assumption, randomization, or an ordering authority — ICN rejects all three (§6.1). The correct move is to stop asking. Revocation must be scoped to a relying party that has an authoritative view — which is why ICN's one revocation mechanism that is designed this way (RPC/gateway token revocation, scoped to a single gateway with a durable store and a fail-closed read, AUTHORITY_SPINE §2) has a coherent story where identity revocation does not. (That is an architectural observation about its shape, not a re-verification of its runtime behaviour this pass.)

The recommended architecture is Model C of §7 — context-scoped identity with a private continuity root — and §9 states it precisely.

What this does not do. It does not eliminate hard work; it relocates it. The recommendation depends on a per-subject, single-writer key-event log that does not exist today (§3.7 proves the absence of any ordering substrate). That is one named, bounded piece of infrastructure whose cost is formally understood — a single-writer object has consensus number 1 and is implementable with reliable broadcast alone (§6.1) — replacing six unbounded open questions about a global namespace. That trade is the whole argument, and §9.6 states honestly what remains open.

2. Normative requirements

Derived before any representation was chosen, from the mission brief, the Constitutional Core immutable principles, #2469's invariants I1–I12, and PRINCIPAL_MODEL §1's five invariant tests.

Labels: [HARD] a violation is a defect · [STRONG] tradeable only against another HARD/STRONG, explicitly · [SOFT] a goal whose cost may exceed benefit.

R1 Sovereignty

• R1.1 [HARD] Genesis requires no registrar, no network, no permission.
• R1.2 [HARD] No institution, node, gateway or operator holds a key that lets it author acts as a human. Custody defines identity.
• R1.3 [HARD] Loss of any infrastructure must not destroy the human's identity or their ability to establish identity elsewhere.
• R1.4 [STRONG] No single institution may revoke a person's identity. It may revoke standing within itself only.

R2 Continuity — three properties that must not be conflated

• R2.1 [HARD] Continuity of subject. The same human remains the same subject across device replacement, key rotation, total device loss, algorithm change.
• R2.2 [HARD] Continuity of authority. Which keys may currently act is time-varying and must change without changing the subject.
• R2.3 [HARD] Validity of history. An act validly authored when made stays verifiable as having been made, forever, independent of later authority changes. (Verifiable ≠ still-effective — see R5.)

  Not fully met by the recommended model. Superseding recovery orphans the suffix, so receipts from positions after a fork retain a verifying signature but lose their authorization proof (§9.2.1, O-N9). R2.3 holds unconditionally only for positions preceding the earliest fork.

• R2.4 [STRONG] Subject continuity must not require a permanent master secret whose compromise is unrecoverable.

R3 Multi-device and least privilege

• R3.1 [HARD] A device holds its own key and never receives another principal's key.
• R3.2 [HARD] Delegated authority is a strict subset of the delegator's own (attenuation). Currently violated — #2590.
• R3.3 [HARD] Every security-relevant field of a delegation is cryptographically bound to it. Currently violated — #2588.
• R3.4 [STRONG] Adding or replacing a device must not require the highest authority to be online, except where root-only is a deliberate choice.
• R3.5 [STRONG] Device classes differ by scope and custody strength, never by principal class.

R4 Determinism and partition tolerance (inherited from #2469; non-negotiable)

• R4.1 [HARD] No validity decision depends on the receiver's wall clock.
• R4.2 [HARD] No validity decision depends on the order in which a receiver learned two independent facts. (I12)
• R4.3 [HARD] Two honest nodes with the same durable state reach the same verdict. (I10)
• R4.4 [HARD] Verification never fetches authority material over the channel carrying the act. (I9)
• R4.5 [HARD] Authority may be evaluated against receiver-local replicated state iff that state is itself authenticated and converges deterministically.

  This corrects PRINCIPAL_MODEL §6.2's "carried, not resolved", which over-generalized #2469 §14.1. #2469 resolves against local durable state at ingress steps 7–11 by design; what it forbids is resolving against unauthenticated state (§7.0: "the receiver would compare it against commons state that is itself unauthenticated"). The distinction is load-bearing: it is what makes §9 possible at all.

• R4.6 [HARD] A legitimate act is eventually applied; nothing is permanently discarded because of arrival order. (I11/I12)

R5 Revocation — a requirement on effect, not on admission

• R5.1 [HARD] A compromised device loses the ability to produce new effective acts within a bounded, stated window, without requiring a global total order.
• R5.2 [HARD] Revocation semantics is stated per act class and never differs silently between classes.
• R5.3 [STRONG] Revocation does not retroactively invalidate acts whose effects have already settled irreversibly. Without rollback semantics that is a correctness bug, not a security win (PRINCIPAL_MODEL §6.5 established this).
• R5.4 [HARD] "Could not determine whether this was revoked" never resolves to "not revoked". (AUTHORITY_SPINE §2)

R6 Privacy — structural

• R6.1 [STRONG] Two institutions cannot correlate a person by default from protocol-visible identifiers alone.
• R6.2 [STRONG] A person proves standing in a context without revealing other contexts.
• R6.3 [STRONG] A person may, at their option, prove two personas are one human.
• R6.4 [STRONG] Recovery does not require deanonymizing every persona.
• R6.5 [SOFT] Network- and device-layer correlation is outside identity's sole control, but must not be made worse.
• R6.6 [HARD] Sybil resistance must not require a public global person identifier. Uniqueness ≠ identification.

R7 Offline and partitioned operation

• R7.1 [HARD] Genesis works fully offline. R7.2 [HARD] Signing works fully offline. R7.3 [HARD] Delayed/reordered delivery is safe and converges.
• R7.4 [STRONG] Multiple devices may act concurrently while partitioned.

R8 Authorship and governance

• R8.1 [HARD] Infrastructure never manufactures human authorship.
• R8.2 [HARD] These five stay distinct: session authentication · content authorship · delegated authority · institutional authority · transport identity.
• R8.3 [HARD] A receiver establishes authorship from bytes in hand plus authenticated local state — never from unauthenticated state.
• R8.4 [STRONG] A relay relays without holding any key of the author.

R9 Recovery

• R9.1 [HARD] Recovery is possible from total device loss.
• R9.2 [HARD] Recovery is an authenticated, auditable event, never a silent substitution.
• R9.3 [HARD] Competing recovery attempts resolve deterministically; the losing attempt is visible.
• R9.4 [HARD] M-of-N counts distinct authenticated participants. (#2591)
• R9.5 [STRONG] Recovery does not create a new permanent single point of catastrophic failure.
• R9.6 [STRONG] Recovery is contestable by the legitimate subject (delay + veto).

R10 Usability

• R10.1 [HARD] A member never needs to understand DIDs, PKI, Merkle trees, quorums or key-event logs to join and participate.
• R10.2 [HARD] Phone-only onboarding produces a secure, recoverable identity by default — not a degraded one to repair later.
• R10.3 [STRONG] At most one irreversible user decision at onboarding.

R11 Infrastructure independence

• R11.1 [HARD] Identity works with no node / one personal node / many personal nodes / hosted-only. Moving between them changes hosting, never identity.

R12 Evolvability

• R12.1 [HARD] Signature algorithm replaceable without "create a new person".
• R12.2 [HARD] New device classes without protocol change.
• R12.3 [STRONG] A migration has an enforceable end state. A dual-stack that never ends is not a migration (#2469 / O13).

R13 Meaning Firewall (constitutional)

• R13.1 [HARD] The kernel holds keys, identifiers and opaque scopes — never Person, member, role, cooperative.

  PRINCIPAL_MODEL §1.1 states this, and then §4 proposes Person and Device as principal classes in icn-identity. That tension is real and §9.5 resolves it.

Invariant tests (PRINCIPAL_MODEL §1, retained verbatim)

T1 replacing a phone must not create a new human · T2 replacing a node must not create a new cooperative · T3 hosting a cooperative must not make the host the cooperative · T4 assigning a personal node to a coop must not rewrite the node's identity · T5 running one institution's workload must not change the node's species.

3. What ICN implements today

Verified at b26bf681. This section is descriptive. It does not restate PRINCIPAL_MODEL §2, which remains accurate on the points it covers; it records what this pass found in addition to and in correction of it.

3.0 Corrections to PRINCIPAL_MODEL §2, and new findings

Rows marked verified were re-read in source by hand during this pass; rows marked (agent-traced) were produced by a source-tracing pass and spot-checked rather than fully re-read. One agent-traced claim was checked and found wrong — see F4 — so the (agent-traced) rows should be treated as high-confidence but not yet load-bearing, and re-verified before any of them is used to justify deleting code.

3.1 What a Did actually is

pub struct Did(String) (icn-identity/src/lib.rs:177). from_str (:209-244) requires did:icn: + multibase decode + exactly 32 bytes + a valid Ed25519 point. from_public_key (:193-196) always emits base58btc; from_str accepts any multibase, and PartialEq/Hash are derived over the inner String (:174) — so Did equality is string equality, not key equality.

new_unchecked (:284) bypasses all of it. It has one call site: from_anchor_id (anchor.rs:194-197). And from_anchor_id's production use has almost nothing to do with persons — it is a generic "mint a Did from 32 arbitrary bytes" hatch: cooperative treasury identifiers (icn-coop/src/actor.rs:493,788; apps/membership/src/coop_core/actor.rs:359,523, from 16 bytes zero-padded to 32), a ZKP holder pseudonym (icn-zkp/src/prover.rs:257), and placeholders (icn-ledger/src/fx.rs:118, icn-gateway/src/api/sdis/qr.rs:163).

ESTABLISHED: Did is a key identifier, and every non-key use of it is type reuse the type cannot support. F1 and F2 are that reuse failing in production code, not in theory.

3.2 Genesis is already sovereign — and that part is right

KeyPair::generate() (:341) → Did::from_public_key (:191). No registry, no network. R1.1 and R7.1 are already met and must be preserved.

3.3 The device model is built, unreachable, and unverifiable

F8, F9 and F10 together: multi_device.rs implements a coherent roster and rotation model; the gateway path that would use it can never find a document; the verifier has no callers; and the one production signer signs a different message than the verifier checks. can_sign has zero production callers (confirmed — docs/status.toml:32 already records this).

Consequence for #2588 and #2590. Both describe real defects in real code. But the gateway route they sit on is currently unreachable (F8), which changes their urgency without changing their validity: they are correctness debts to fix before the path is wired, not live exploited surface. This document does not propose closing them here; it proposes (§19) that they be fixed as part of whatever wires device authority, so the wiring cannot ship the defects.

3.4 Authority is a bearer token over an HMAC, and one mint path proves nothing

Confirmed against source: join_via_invite (api/invites.rs:245-296) takes req.did from the request body with form validation only, takes no HttpRequest, and mints a token for it (:280) — #2589 confirmed line-for-line. The challenge paths do prove key control, but the signed payload is the raw nonce bytes only (auth.rs:315), with no domain separator and no binding to the requested coop_id or scopes.

3.5 SDIS held two incompatible models of its own anchor, simultaneously

This is the most important historical finding, and it is a genuine unreconciled split rather than a decision that was made and lost:

• Anchor as public identifier — it becomes the DID (SDIS_IMPLEMENTATION_PLAN.md:344-345), is a URL path key (/v1/sdis/anchor/{anchor_id}), is written to replicated state, is carried in cleartext gossip, is typed by users during recovery, and is returned in an HTTP response alongside its own hex (api/commons/anchor.rs:67).
• Anchor as secret witness — Attestation is "Private attestation from an issuer (kept secret by holder)" (icn-zkp/src/types.rs:217); the membership circuit takes the anchor-derived DID as a private input (icn-zkp/src/circuit/membership.rs:60-63); the audit checklist requires "No VUI/anchor logged" (SDIS_AUDIT_CHECKLIST.md:286).

Anchor-to-anchor correlation across cooperatives is never named as a threat in any SDIS document. And genesis_random's only documented rationale — "prevents rainbow table attacks on VUIs" (anchor.rs:102-104) — is a pre-image defence, which only makes sense if the anchor is published. So the honest reading is: the anchor was intended to be a publishable pseudonym that hides its inputs, not a private continuity root — and the ZK layer, built on the opposite assumption, was never reconciled with it.

Anchor::to_did was in the original SDIS commit (8c434077, 2025-12-10) but was specified under "Task S2.1.2: Implement DID format extension" with the literal instruction "Add backward compatibility" — an interop bridge to the pre-existing key-derived Did, not a doctrine that a person's public identifier should be their anchor.

3.6 Documented contradictions nobody has adjudicated

The sharpest, which PRINCIPAL_MODEL does not record: does recovery preserve the DID? design/multi-device-identity-design.md:664 says the DID stays stable; design/social-recovery-design.md:26,29 says recovery creates a new DID and installs a did_mapping:<old_did> indirection. Those are incompatible, both are "PARTIALLY CURRENT", and each has code. Also unadjudicated: whether keys are exportable (CLIENT_MODEL says never; MDI ships an encrypted BackupSeed), and whether a person has one DID or many (CLIENT_MODEL:99 vs PRINCIPAL_MODEL:1144).

3.7 There is no ordering substrate. At all.

This is the fact that decides the architecture, so it is stated flatly.

ESTABLISHED: ICN has no replicated authenticated ordered log that a governance operation lands on, and no per-cooperative or per-domain order that a governance operation and an identity event could share. The nearest specification of one is #2469 §5.6, and it is unbuilt.

4. What "identity" collapses today

Testing the mission's decomposition hypothesis against §3, Did is currently serving as eight distinct concepts:

Result of the decomposition test. Only 1 and 5 genuinely need to be a public key. Concept 2 is the decisive one:

ESTABLISHED: a durable human subject identifier must not be a public key.

Proof. R2.1 requires the subject to survive rotation; R2.2 requires the authorizing keys to change; R1.2 says custody defines identity. If the subject identifier is a key, then either that key can never be retired — contradicting R2.2 — or the subject is permanently named by a key nobody controls. ICN already exhibits the second horn: DidDocument.id is the original key's DID, so after revoke_device("device-1") the document is identified by the key it just revoked (multi_device.rs:21-22, :426-447). ∎

Concepts 2, 3, 6 and 8 must therefore each get their own representation. §9 gives them one; §10 states what is left for Did.

5. The structural diagnosis: one choice, six blockers

PRINCIPAL_MODEL accumulated O8, O9, O13, O16, O17 and O18 across twenty review rounds. They are not six problems. They are six consequences of one decision:

The Person's durable identifier is derived from a key, and authority over it must nevertheless evolve.

Trace each:

O16 deserves emphasis because it is the deepest: a key-derived durable identifier makes its genesis key a permanent master secret. That directly violates R2.4 and R9.5, and no amount of chain machinery repairs it — the chain's anchor is the master key.

REJECTED: the key-derived durable Person identifier (PRINCIPAL_MODEL §4's Person row, and Model A of §7). Not because it is inelegant, but because it mathematically entails a permanent unretireable root, and every one of the six blockers is downstream of that.

O9 is the one blocker that is not dissolved by fixing the identifier, because it is not a consequence of the choice — it is a consequence of physics. §6.1.

6. The reframe: three moves, two of them forced

6.1 Move 1 — stop asking for global convergent revocation

Classification: RECOMMENDED, on a bounded formal argument — not ESTABLISHED. (An earlier draft called this "provably unachievable" and classified it ESTABLISHED. That was an overstatement, corrected in adversarial review; the correction is recorded here rather than quietly removed.)

The argument has two steps and one honest caveat.

1. Requiring all peers to agree on whether an act preceded a revocation is requiring atomic broadcast. Chandra & Toueg, Unreliable Failure Detectors for Reliable Distributed Systems, JACM 43(2), 1996: "Consensus and Atomic Broadcast are equivalent in asynchronous systems with crash failures… a solution for one automatically yields a solution for the other."
2. Deterministic consensus is unsolvable in the pure asynchronous model with crash faults. Fischer, Lynch & Paterson, JACM 32(2), 1985: "every protocol for this problem has the possibility of nontermination, even with only one faulty process."

The caveat, stated because omitting it would be misuse. FLP is routinely circumvented — by randomization (Ben-Or), by partial synchrony (DLS, PBFT), and by unreliable failure detectors. Chandra & Toueg is itself a positive result: it shows ◊W suffices to solve consensus. Citing only its equivalence half while suppressing its solution half would be quoting a paper against its own thesis.

So the correct claim is not "global convergent revocation is impossible." It is: global convergent revocation requires adopting a synchrony assumption, randomization, or an ordering authority — and ICN declines all three. #2469 excludes consensus by design; R4.1 forbids clock-based synchrony; and icn-kernel-api::Coordination is a Raft-shaped trait with zero implementors (§3.7). That is a design choice with a cost, and it is reopenable by paying the cost, not a theorem that forecloses it.

⇒ O9, as posed — "how is a device revoked convergently at all" across the network — has no solution within ICN's stated model. PRINCIPAL_MODEL was right that all three candidate shapes fail; it stopped one step short of the reason, which is that the target is unreachable given premises ICN has chosen, rather than merely unbuilt.

The survey confirms it empirically: no deployed system achieves decentralized global convergence on revocation. Every one either supplies an ordering authority (Signal Sesame's central server; Matrix's homeserver; WebAuthn's RP database; BitstringStatusList's issuer endpoint), only detects divergence (Certificate Transparency, CONIKS, KEYTRANS — and draft-ietf-keytrans-architecture-09 §3.3 concedes detection needs "a connected graph of all users", so a partition defeats it), or deliberately discards the ambiguous case (DIDComm: "The message recipient MUST ignore those messages"). KERI detects duplicity and resolves it only per validator — "the first seen version of an event is the authoritative one for that validator" — so partitioned validators diverge by design.

The escape hatch is formal. Guerraoui, Kuznetsov, Monti, Pavlovic & Seredinschi, The Consensus Number of a Cryptocurrency, PODC 2019: "the consensus number of an asset transfer object is 1… a more general k-shared asset transfer object where up to k processes can atomically withdraw from the same account… has consensus number k."

Consensus number 1 means the object is wait-free implementable without consensus — but be precise about what that buys:

• The primitive it needs is Byzantine reliable broadcast (BRB), not "gossip". BRB guarantees non-equivocation among receivers of a delivered message; it does not stop a Byzantine single writer from authoring two conflicting events in the first place. That residual is exactly the duplicity case §9.2 has to handle explicitly.
• ICN does not have BRB. GossipEntry carries no signature field at all (§3.7), so building the log's replication path is "implement Byzantine reliable broadcast", not "add a topic". §19.1 slice N3 is costed accordingly.

This gives the design its single most important constraint: keep the authority log single-writer. The moment two devices can independently author authority changes for the same subject, k > 1 and the system is back in consensus territory.

6.2 Move 2 — make the identifier commit to an event, not to a key

A self-addressing identifier — SAID = H(inception_event) — is self-certifying without being a key. Given the identifier and the inception event, any peer verifies the binding by hashing. This is KERI's construction, and it is the only one in the survey that discovers current authority with no online authority, no clock and no consensus (by replaying a log anchored at a self-certifying inception).

Two consequences fall out immediately:

• O17's authenticity half dissolves. The genesis document is the thing the identifier commits to, so there is no trusted starting document to obtain. Its acquisition half does not: a truncated-but-valid prefix verifies perfectly and yields a stale authority state, so completeness remains open (§18, O-N5).
• O16 is narrowed by pre-rotation — for rotations only. KERI's inception commits a digest of the next key set; rotation reveals it. A compromised current key therefore cannot rotate, because it does not hold the pre-committed next keys.

Pre-rotation does not prevent forking in general, and an earlier draft of this section wrongly said it did. (Corrected in adversarial review.) It constrains establishment events only. A compromised current key can still author a competing non-establishment event — an authorize or a revoke — at the next position, because those are signed by a currently-authorized key and commit to nothing held in cold storage.

This matters twice over. First, the fork is real. Second, and worse, a naive "every honest holder refuses to advance past the fork" rule turns a key compromise into permanent denial of identity: the victim can never publish the revocation that would remove the attacker, because the log is wedged.

The mitigation is KERI's superseding recovery, and it is adopted here: "a rotation event overrides or supersedes an interaction event with the same event sequence number", after which the witness "will no longer accept any new events of any type into the disputed branch." So the victim recovers by rotating at the disputed position using pre-rotated material the attacker does not hold. KERI's own honest concession applies unchanged: "Recovery may create an unavoidable race condition but the special rule minimizes the extent of that race condition."

Net: forking a rotation requires cold-key compromise; forking a non-establishment event requires only current-key compromise and is recoverable but racy. Residual policy is O16′ (§17), and it is a liveness question, not only a selection question.

6.3 Move 3 — let the acceptor set recency, and let the subject own the order

Rivest, Can We Eliminate Certificate Revocation Lists?, FC'98 — 28 years old and still the correct architecture here:

"Proposition 1: Recency requirements must be set by the acceptor, not the certificate issuer. The reason is that the acceptor is the one who is running the risk if his decision is wrong." Corollary 1: "Periodically-issued CRLs are wrong." Proposition 2: "The signer can (and should) supply all the evidence the acceptor needs, including recency information."

Applied to ICN: an institution is the acceptor. It decides how fresh a member's authority evidence must be. The member's device supplies that evidence with the act. Nobody needs a global agreement, because no global decision is being made — each institution decides for itself, about its own state, which is exactly the scope in which it already has legitimate authority.

This also explains why ICN's one working revocation mechanism works: RPC and gateway token revocation (AUTHORITY_SPINE §2) is scoped to a single relying party with a durable store and a fail-closed read. It is not an accident; it is the only shape that can work.

6.4 What the external survey teaches, architecture by architecture

Primary specifications, not summaries. Adopted means the idea is used in §9; rejected means it was examined and does not fit ICN's premises.

The cross-cutting lesson. Of every architecture surveyed, exactly one discovers current authority with no online authority, no clock and no consensus — KERI, by replaying a single-writer log anchored at a self-certifying inception. That is not a coincidence: it is the only one built from the same premises ICN's R1/R4/R7 state.

6.5 What the three moves buy

This table is a summary of §18 and must never diverge from it. (An earlier draft marked O13 and O17 "dissolved" here while §18 correctly called both partial; review caught the mismatch, and readers of the summary alone could have treated unresolved prerequisites as closed.)

7. Candidate models

Five models, each stated at its strongest. None is a straw man; A is the repo's own current proposal and D is the position most of the external ecosystem holds.

Model A — Key-as-Person (the status quo, plus the A0 program)

The Person identifier is a self-certifying key-derived Did. Authority evolves through an authenticated identity-document chain anchored at the genesis key the DID encodes. Device authority travels as a carried, self-contained DeviceAuthorization.

Strongest case. Nothing new to build for genesis — it already works offline (§3.2). Verification needs no resolution, no registry, no network round-trip: author.to_verifying_key() and done, which is exactly why #2469 could freeze a field set. One identifier everywhere means membership records, storage keys and the whole existing type surface keep working. The chain's cheap parts already exist: capability checks, Ed25519 verification, strict +1 monotonicity.

Why it fails. §5: the identifier's binding to the genesis key makes that key a permanent, unretireable master secret, which is a direct R2.4/R9.5 violation and the root of O16. O8, O17, O13 and O18 follow. It also fails R6.1 outright — one permanent 32-byte value in every membership record, every gov:vote:{pid}:{voter} key and every gossiped op. REJECTED.

Model B — Stable non-key Person anchor, globally resolvable

A durable Person identifier exists independent of keys (random bytes, or a hash); keys and devices are authorized for it. This is what SDIS's Anchor actually is (F3).

Strongest case. It gets R2.1/R2.2 right — subject and authority are genuinely separate, rotation is natural, and there is no permanent genesis key. It matches the strongest existing ICN design intent, and KeyBundle::did() already carries the doc-comment "Returns the anchor's DID, not a key-based DID".

Why it fails. Three ways. (i) Genesis has no authority root: nothing stops a second party claiming an unclaimed anchor, and first-writer-wins in a global namespace is arrival-order dependent — the exact rule #2469 §8 withdrew as non-convergent. (ii) Resolution requires a global authenticated directory, so you inherit key-transparency's split-view problem, whose own architecture draft concedes detection needs "a connected graph of all users". (iii) Correlation is worse than Model A, because a permanent non-rotating anchor cannot even be changed. REJECTED as a global identifier; its core idea — a durable non-key subject — is retained in §9 and made self-certifying and per-context.

Model C — Context-scoped identity with a private continuity root

There is no global Person identifier. The person holds keys and a private continuity root. Each institution knows them by a distinct, self-certifying subject identifier whose authority evolves in a log the subject alone writes. The institution is the relying party.

Strongest case. Satisfies R6.1 structurally rather than by policy. Removes the global namespace and therefore O8/O16/O17 in their global form. Single-writer authority logs have consensus number 1 (§6.1), so no consensus is required. Matches the only external designs built on the same premises (did:peer's relationship-scoped registry; KERI's per-relationship AIDs).

Costs, stated up front. Recovery is per-context work, not one act (§12). Cross-context proof requires an explicit linkage step (§11.3). Sybil resistance needs a nullifier, and ICN's ZK stack cannot currently provide one (F16). "Who is this person, globally?" becomes unanswerable — which is usually correct and occasionally inconvenient.

Two costs an earlier draft omitted, both found in adversarial review, and both worse than the ones above.

1. The continuity root has a larger blast radius than Model A's genesis key. It is the person's index of their own subjects plus the material that recovers each one, so compromising it is simultaneously takeover of every context and full cross-context deanonymization — it hands the attacker exactly the linkage map §11 exists to prevent anyone else from building. Model A's rejected genesis key compromises one identity. This model concentrates what Model A distributes, and §12.2 path (b) exists because of it.
2. Availability is a per-subject dependency, not zero infrastructure. A verifier needs the subject's log prefix; when it is missing, someone reachable must serve it. Model B was rejected partly for needing one global directory; Model C needs N per-subject availability paths. They are materially different — a relying party can serve the logs of its own members, so the dependency is per-relationship rather than global and universal — but "no centralization dependence" is too clean, and the matrix below is corrected.

Model D — Credential-centric, no person identifier at all

The person holds keys; institutions issue verifiable credentials; every relationship is a credential. Standing is proven by presentation.

Strongest case. Maximum portability — standing provable to a third party that holds no registry, which is precisely the gap PRINCIPAL_MODEL §7.2 names. Aligns with the largest external ecosystem (VC-DM 2.0). Institutions already behave this way: FounderSignature (F18) is a credential in all but name.

Why it fails as the whole answer. (i) A credential subject still needs an identifier, so pairwise identifiers reappear — D collapses into C plus a credential layer. (ii) Credential revocation is the same impossibility again, and the ecosystem's answer is BitstringStatusList, which mandates an online fetch (STATUS_RETRIEVAL_ERROR if unreachable) and whose own privacy section concedes correlation below ~131 072 entries — unattainable per cooperative. (iii) It supplies no continuity mechanism: lose every device and there is nothing that is still you. REJECTED as the whole answer; adopted as a layer (§11.2, §14).

Model E — Hybrid identity/authority graph

Continuity anchor + authority keys + pairwise identities + recovery authorities + institutional credentials, all first-class.

Strongest case. It can express every requirement, and every component has a real justification somewhere in §2.

Why it fails. Complexity is itself a cost, and here it is disqualifying: five first-class concepts means five genesis stories, five recovery stories and five revocation stories, whose interactions are where security bugs live. §3 is a catalogue of what happens when ICN maintains several parallel identity models at once — three "steward vouch" authority models that disagree (F6/§3.5), two incompatible DidDocument types, two contradictory definitions of "who may sign". E institutionalizes that failure mode. REJECTED — but note that C is E with four of the five concepts demoted from protocol objects to client-side or app-layer concerns, which is the whole point.

Evaluation matrix

Qualitative, with reasons rather than false precision. ✔ meets · ~ partial / costed · ✘ fails · n/a not applicable.

Selected: Model C — on the balance of the table, not on a clean sweep. Three cells above are shortfalls the model does not discharge: R2.4 under the default recovery path, R9.1 [HARD] under both recovery paths, and per-subject log availability. §9.6 carries them forward; a reader who weighs R9.1 above correlation resistance should reach a different answer, and that is a legitimate reading of the same evidence.

8. Adversarial scenarios

All 25 mission scenarios, walked against Model C as specified in §9, with the discriminating failures of the rival models noted. A scenario that Model C cannot answer is marked OPEN and appears in §17 — none are silently absorbed.

Scenarios Model C does not fully answer, carried to §17: 2 (residual duplicity policy), 3 (cross-context divergence under concurrent recovery), 5 (guardian collusion), 7 (irreducible — §6.1), 11 (relay withholding).

9. The recommended architecture

Classification: RECOMMENDED. It is the strongest model after comparison, not a forced conclusion. §17 lists what would reopen it.

9.1 Four objects, each with exactly one job

The person is not an object in the protocol. That is the point. Person is an app-layer word for the human who holds a continuity root, and no kernel type needs to know it exists (R13.1).

Why the subject is a hash of an event, not a key. §4 proved a durable subject must not be a key; §6.2 supplies the alternative. Given SubjectId and the inception event, any peer verifies the binding by hashing — self-certifying with no registrar, no resolver and no trusted starting document. That answers O17's authenticity half only — completeness of the prefix you were handed is a separate, still-open question (§18).

9.2 How authority evolves

The inception event declares the subject's initial authorized keys and commits to a digest of the next key set (pre-rotation). Each later event is signed by a key authorized in the immediately preceding state and advances the position by exactly one.

inception  { keys: [K0], next: H(K1set), policy }        position 0
   │        SubjectId = H(this event)          ← self-certifying, no registry
   ▼
authorize  { device: D1, scopes, valid_for }             position 1
   ▼
rotate     { reveal K1set, next: H(K2set) }              position 2
   ▼
revoke     { device: D1 }                                position 3

Four properties, and each does specific work:

• Single-writer ⇒ consensus number 1 (§6.1), given Byzantine reliable broadcast underneath — which ICN does not have yet (§6.1, §19.1 N3).
• Pre-rotation means a compromised current key cannot rotate. It does not prevent that key forking a non-establishment event — see §6.2. Scenario 1 contained; scenario 2 narrowed, not eliminated.
• +1 monotonicity makes out-of-order delivery buffer, never reject (R4.6) — precisely the gap-fill obligation PRINCIPAL_MODEL's A0 identified, now with a reason it is safe.
• Duplicity is detected, and recovered from by superseding rotation (§6.2).

Do not let two devices write this log. The instant two devices can independently author authority events for one subject, k > 1 and consensus is required again (§6.1). Concurrency here is a correctness boundary, not a feature request.

9.2.1 The replicated state model

Three successive drafts got this wrong, and all three errors are recorded because each is instructive. (a) The first called the merge "a monotone join, i.e. a CRDT" while also saying holders "refuse to advance past the fork" — which cannot both hold. (b) The second proposed (longest verified prefix, set of duplicity positions); review supplied the counterexample — if A advances through X@n and B through Y@n, recording the duplicity needs either branch selection (no authority) or prefix truncation (non-monotone). (c) The third stored whole events in a set; review pointed out that Ed25519 admits more than one valid signature per message, so that is really a keyed map with an undefined value merge — and any rule for picking a signature is a content-based tiebreak that breaks commutativity. The lesson each time: a verified prefix is a conclusion, and a signature is not part of identity.

Digests, stated once and used everywhere

event_id     = H(canonical_body)          ← signatures are OUTSIDE every digest
SubjectId σ  = event_id(inception body)
prev_digest  = event_id(parent body)

All three must use the body digest. If σ or prev_digest hashed the whole event, a hedged or retrying signer re-signing an identical body would mint a second SubjectId — or a child would name a parent variant that dedup discards, wedging the chain permanently. That is precisely the false duplicity the body rule exists to remove, relocated one layer down.

Durable state — two grow-only sets, whose elements are bodies

For subject σ:

Bodies(σ)   = { b : ∃ s. admissible(b, s) ∧ b.subject = σ }     -- canonical bodies
Witness(σ)  = { (event_id(b), s) : admissible(b, s) }           -- signatures, never compared

admissible(b, s) is state-independent — decidable from the bytes alone:

1. canonical encoding parses; version and domain separator are as specified;
2. s verifies under b.signer_key, carried inline (this proves only "some key signed this body" — authority is a derived question);
3. for an inception body, σ == event_id(b); otherwise b.subject == σ;
4. b.position ≤ MAX_POSITION, an absolute protocol constant — not local_frontier + C, which would make admissibility depend on local state and break the join.

• Partial order: componentwise ⊆. Join: componentwise ∪.
• Associative, commutative, idempotent: inherited from set union. ∎
• Receipt order cannot change durable state — union discards order.
• Monotone: nothing is removed by the join.

Why bodies and not events. Ed25519 permits several valid signatures over one message. With whole events as elements, (id, s₁) and (id, s₂) are two elements at one position — manufacturing duplicity that halts the subject — and collapsing them requires choosing a signature, which is a content tiebreak and destroys commutativity and idempotence. With bodies as elements, re-signings collapse automatically and Witness simply accumulates; nothing ever compares two signatures.

Representation of the awkward cases falls out for free:

State-independence is what makes the filter commute with union — filter(A) ∪ filter(B) = filter(A ∪ B) — and it is why the bound in rule 4 must be an absolute constant.

Admission is cheap, so the durable set is attacker-writable, and "retention affects liveness not safety" was too strong. Anyone can mint unlimited admissible bodies for any public σ by signing arbitrary bytes with a fresh key. They can never enter C (they are unauthorized), so they cannot fork anything — but they are a storage and bandwidth attack, which forces eviction, and eviction is a per-replica function. Under adversarial shaping, "convergence over the eventual retained set" is close to vacuous.

Two consequences, both stated rather than absorbed: the eviction rule must be protocol-specified rather than implementation-chosen, so that two honest replicas under the same attack retain the same set; and per-signer admission cost belongs in the replication layer (N3), where it may be state-dependent without touching the join.

Eviction must be authority-aware, or spam evicts legitimate authority events. (Raised in review round 3 and correct.) A position bound alone does not help: an attacker floods frontier + 1 with self-signed bodies that correctly name the verified prefix, and since admissible is state-independent it cannot tell them from the legitimate next event. A naive bounded store then discards the real one, and anti-entropy cannot restore it while the cap stays full — so receipt order would decide which replicas ever derive it.

The distinguishing predicate exists, just not in admissible: authorized in the derived view separates them perfectly, because spam is signed by keys the log never authorized. Eviction may therefore consult derived state — it is a lossy local operation, not part of the join — and the rule is retain authorized bodies before unauthorized ones, which makes spam at or below the frontier harmless.

The residual is the gap region and it is not solved here. Beyond the frontier, with intervening positions missing, authorized cannot yet be evaluated, so far-future spam is indistinguishable from legitimate future events. Retention should prefer proximity to the frontier and a carried chain-inclusion witness makes the far-future case decidable — but until that rule is specified, R4.6 and permutation-invariant convergence hold only absent adversarial storage pressure, and this document does not claim otherwise. Recorded as O-N8 (which now covers admission and compaction), with O-N5 for the topology.

Derived view — a pure function of Bodies(σ)

derive(Bodies(σ)):
    b₀ ← the unique b with σ = event_id(b)          # unique by construction
    if none: return Unknown
    state ← apply(b₀);  p ← 1
    loop:
        C ← { b ∈ Bodies(σ) : b.position = p
                            ∧ b.prev_digest = event_id(chosen(p−1))
                            ∧ authorized(b, state) }
        C ← supersede(C)
        match |C|:
            0 → return Live(state, frontier = p)
            1 → state ← apply(state, c);  p ← p+1
            _ → return Halted(state, disputed_at = p, candidates = C)

Inception cannot fork: two different inception bodies hash to two different σ, so they are two different subjects.

The recursion is well-founded: derive advances one position at a time and only after |C| = 1, so chosen(p−1) is defined whenever C at p is computed; if p−1 halts, derive has already returned.

The derived view may regress; the durable state may not. That is a conclusion changing on new information, and it is convergent — every replica holding the same Bodies(σ) computes the same verdict.

derive is pure only if authority principals are keys. Every principal named inside an event — device, guardian, recovery authority — must be a raw Did, verifiable from bytes. If a guardian were named by SubjectId, authorized would depend on another subject's log, which may itself be gapped or halted, and mutual guardianship would make the recursion non-well-founded. Normative for N1.

supersede — the one selection rule, and the constraints that make it safe

supersede(C) = if C contains any establishment event
               then { b ∈ C : b is an establishment event }
               else C

Establishment events (rotations, recovery) supersede non-establishment events (authorize, revoke) at the same position — KERI's superseding recovery, and the authenticated selector O16 needed. It selects by authority class, never by content: no lowest-hash, no first-seen, no longest-chain. Where it cannot select on authority it halts.

Three constraints are load-bearing. Violating any one turns the selector into an attack:

1. Establishment eligibility is defined by a pre-rotation pre-image reveal — never by a capability flag, and no delegation may mint it. If recover were establishment because the signer holds a Recover capability, an attacker with a compromised current device would author an establishment event and win supersede against the legitimate holder's rotation — authority-based selection becoming attacker-based selection. F13/F13a in §19.3 is exactly such a route in today's code. This also explicitly bars §9.5's generic attenuating delegation from delegating establishment authority. Same class of error as #2590, one layer up.

2. Rotation bodies must be deterministic. Pre-rotation commits to H(K_next_set), not to the rotation body — so the holder of K_next can author rotate{reveal K_next, next: H(K_a)} and rotate{reveal K_next, next: H(K_b)}, both authorized, different bodies ⇒ |C| = 2 ⇒ permanent halt with no attacker present (a device that crashes before persisting its new commitment and retries with fresh randomness kills the subject). The commitment scheme must therefore make the whole rotation body re-derivable — e.g. K_{p+1} = KDF(root ‖ p+1) with every other field determined — so an honest retry collapses to one event_id. Normative for §19.4 item 2.

3. Exactly one authorized establishment body may exist per position — and threshold signing alone does not deliver that. (Sharpened in review round 5.) With M-of-N guardians signing independently, two quorums yield two authorized bodies at p ⇒ permanent halt, so any M guardians hold a kill switch, not merely a takeover. But FROST does not fix it either: a group key authenticates a quorum, it does not restrict that quorum to signing one message, and the same M guardians can still sign two distinct bodies — as can a phrase-holder racing a guardian quorum with a different body.

   Two rules together are required, and both are normative for N1:

   • authorized must enforce canonical derivation, not merely permit it. An establishment body is authorized only if it equals the body canonically derived from the revealed pre-committed material. A non-canonical body — from a malicious quorum or an honest retry — fails authorized and never enters C. This is constraint 2 promoted from "re-derivable" to "checked".
   • Each position commits to exactly ONE next authority. Pre-rotation must not arm two alternative recovery paths at the same position; the person selects path (a) or path (b) at each rotation, never both. Otherwise the two paths reveal different material and derive two different canonical bodies, and the race returns.

   With both, at most one authorized establishment body can exist at a position, so supersede never has to choose between two. N7 remains a hard prerequisite of guardian recovery (§12.2, §19.1) — it is necessary and, on its own, not sufficient.

What this does and does not give

Class-2 settlement is not convergent under a fork, and the earlier framing understated it. The regression is not only Live → Halted; it is Live(branch A) → Live(branch B). Replica R1 receives only the attacker's authorize@5, derives Live(frontier 6), and finalizes a class-2 ledger act citing position 5. R2 receives the victim's rotate@5 first and rejects the same act. After merge both hold an identical set and derive an identical verdict — and hold permanently different ledger state, because R5.3 says settled effects are never unwound. That is the arrival-order divergence #2469 §8 withdrew, reintroduced through class 2.

An earlier draft hid this by saying "acts at positions < p remain evaluable", as if p were known at admission. It is not — p is discovered afterwards.

There is no fix inside this model. Reducing exposure means admitting class-2 acts only against positions deep enough to be beyond challenge, which is a finality depth — a concept ICN does not have, and one whose local evaluation reintroduces the same divergence in weaker form. Recorded as O-N7, and O16′ is reclassified from a liveness question to a settlement-safety question. Until it is answered, this authority model is not by itself a sufficient basis for irreversible settlement, and §9.3 class 2 must be read with that limit attached |

9.2.2 The model against adversarial delivery orders

Every case reasoned through against §9.2.1. The requirement in each: the same durable joined state and the same derived verdict for all honest replicas given the same eventual event set.

Suffix orphaning breaks R2.3 for the orphaned range, and §8 scenario 23 was too strong. (Refuted in review round 4.) If key K was first authorized at position N > p and a superseding rotation lands at p, the derived view no longer establishes that K was ever authorized — so a receipt signed by K keeps a verifying signature but loses its authorization proof.

What survives, and it is not nothing: Bodies(σ) is grow-only, so the orphaned bodies are still there. A verifier can still show "this body at N was signed by K and chained to the pre-fork prefix" — i.e. provably authored on a branch that was later superseded. That is strictly weaker than "authorized", and the difference is exactly what a receipt needs.

R2.3 must therefore be qualified: it holds unconditionally for positions before the earliest fork, and for later positions it degrades from "authorized" to "authored on a superseded branch." Preserving full accepted-at evidence across recovery would need durable per-branch endorsement records, which this model does not define. Recorded as O-N9.

Two operational consequences that are easy to get wrong.

1. Recovery must rotate at the disputed position, not at the next one. If the victim's own legitimate event also sits at p, their view may have shown frontier = p+1 before the fork was known, and the natural instinct is to publish at p+1 — which is unreachable, because derive halts at p. The rotation must be authored at p, where supersede filters out both non-establishment events — the attacker's and the victim's own. The victim therefore loses their own event at p and must re-issue it at p+1. That is a real cost of recovery, not a bug.
2. This assumes the subject notices. A halted subject stays halted until its controller observes the fork and rotates. That is KERI's "sufficiently responsive controller" assumption inherited wholesale, and it means fork monitoring is a client obligation, not an optional feature. A person whose app never checks is a person whose subject can be frozen indefinitely.

Does superseding recovery terminate? Yes. The rotation at p replaces the key set, so the attacker's compromised key is not authorized at p+1 and cannot fork again — provided the rotation actually revokes it, which is why a recovery rotation must replace rather than extend the authorized set.

Where it does not converge on a good outcome, and this is stated rather than engineered around: if the attacker holds the pre-rotation material as well, they can author an authorized establishment event at n. If the victim also does, \|C\| = 2 after supersede and the subject halts permanently — all replicas agree, so it is convergent, but the subject is dead rather than recovered. If only the attacker does, they take over. Both are the backup-compromise case §12.2 records as unrecoverable, and the residual policy is O16′.

9.3 Revocation, stated per act class — the replacement for O9

Because §6.1 forbids a single global answer, the semantics is stated per class. R5.2 requires this table to be explicit; silence would be the defect.

The vote key is keyed by a Did, not by a subject — verified. vote_key(proposal_id, voter: &Did) (apps/governance/src/state_store.rs:222-224) takes a key, which is concept 7 of §4's conflation table. save_vote (:379-384) is an unconditional put, list_votes (:386-) scans the prefix, and AlreadyVoted (icn-governance/src/error.rs:33) is declared and never constructed. So today: re-casting under the same DID overwrites (#2469 fact 15), but a person acting under a second DID — which is what a second device means today (F19) — writes a second tallied row.

That is the sybil surface subject/device separation exists to close, and it is a reason to prefer this model rather than evidence for it. (An earlier draft asserted the present-tense claim "votes are keyed by subject"; corrected in adversarial review.)

Bounding the window without a clock — and the mechanism as first specified does not work. A device authorization carries validity expressed in log positions, not wall-clock: valid for acts evaluated at positions in [N, N+k]. No clock is read anywhere, which is the property worth keeping (R4.1; it also avoids F14's fail-open entirely).

The window as originally written bounded nothing, and R5.1 is weaker than two earlier drafts claimed. (Refuted in review round 4.) The first draft checked the window against the position the act itself references. But the signer chooses that field: a compromised device simply keeps referencing N, which is inside [N, N+k] forever, no matter how far the subject advances the log. Advancing does not age the device out; neither does revoking. A second draft narrowed the failure to sole-device compromise; that was also wrong — the hole is general.

The window is only meaningful when checked against an evaluation position the signer does not control. That exists for exactly one act class:

Class	Evaluation position	Does the window bind?
1 — deferred-decision	the position the decision pins	Yes — the decision, not the signer, chooses it, so advancing past N+k does age the device out. Conditional on O-N6, which supplies the deterministic decision point
2 — immediately settled	none exists	No. There is no decision point, so the only candidates are the acceptor's own current frontier — receiver-local, therefore divergent (R4.2/R4.3) — or freshness evidence the attacker controls

Honest statement, replacing both earlier ones: R5.1 [HARD] is met for class 1 once O-N6 lands, and is not met at all for class 2. For class 2 a compromised device's authorization stays acceptable indefinitely; the only real controls are scope limits (a device may not settle above some bound) and a relying party's own freshness bar, which is the acceptor's risk decision under Rivest Proposition 1 and does not converge between acceptors.

Anchoring each act in the log — KERI's ixn — would close it, and is rejected here for a stated reason: it makes every act an authority event, so two devices acting concurrently means two writers, k > 1, and consensus is required again (§6.1).

The Let's Encrypt analogy is withdrawn: a certificate lifetime advances autonomously with time; a log position advances only if someone acts.

Cost, stated: a subject who advances too aggressively can strand an offline device. Choosing k and the re-authorization cadence is OPEN (§17, O-N1).

Class 1 has a dependency this document does not discharge. "Evaluated at the decision point against the log prefix the decision pins" is deterministic only if the decision point itself is deterministic — i.e. if closing a proposal is a replicated act that fixes the pinned position, rather than a node-local handler action. ICN does not have that today: #2469 §7.2 keeps ProposalClosed contained precisely because "membership is not the right authority for choosing an outcome" and outcome/tally are attacker-supplied fields, and the correct authority "entangles with the GovernanceProofV2 signer-authority model" that #2469 lists as a non-goal.

So class 1 is convergent conditional on deterministic proposal closure, which is a governance problem with a known shape and a named owner — not an identity problem, and not one this document solves. Recorded as O-N6 (§17).

The fallback is not safe, and an earlier draft wrongly said it was. (Corrected in adversarial review.) Without a pinned position there are exactly two options, and both break a [HARD] requirement:

Fallback	Breaks
evaluate revocation against the receiver's local prefix at arrival	R4.2/R4.3 — a node learning vote-then-revocation tallies differently from one learning revocation-then-vote. This is the arrival-order divergence #2469 §8 withdrew
ignore revocation for class 1 entirely (consistent with "never depends on revocation state")	R5.1 — a stolen device's votes count indefinitely

This document picks the second, because divergence is a correctness failure while indefinite exposure is a bounded, stateable security cost — and because it degrades to exactly today's behaviour rather than introducing a new failure mode. It is a known R5.1 violation held open until O-N6 is answered, not a safe default, and it must be described that way wherever class 1 is claimed.

9.4 Governance authorship

Person holds continuity root (offline / backup)
   │
   ├── subject S_A in Coop A, with its own authority log
   │        │
   │        └── log authorizes device D (scopes, positions [N, N+k])
   │
   ▼
D signs the governance act, referencing log position N
   │
   ▼
gateway / node RELAYS — holds no key of S_A, asserts no authorship
   │
   ▼
receiver verifies, from bytes in hand + its own authenticated local state:
   1. act signature under D's key                       [bytes]
   2. D authorized at position N, scope admits the act  [local log prefix]
   3. S_A ∈ this domain's members                       [local domain state]
   4. VALIDITY — and NOT against N, which the signer chooses:
        class 1: the DECISION-PINNED evaluation position P ∈ [N, N+k]
        class 2: no evaluation position exists ⇒ NO validity bound
                 (R5.1 not met; see §9.3)
   ── if the local prefix is shorter than N: QUARANTINE, never reject

Step 4 is written this way deliberately. An earlier revision read "position N within validity", which is the rule §9.3 retracts: the signer picks N, so a compromised device keeps referencing an in-range position forever. Round 4 fixed the narrative and left this normative flow stale — caught in round 5. Class 1 checks the position the decision pins; class 2 has no such position and therefore carries the explicit R5.1 shortfall rather than a bound that does not bind.

This satisfies #2469's I9 (no circular bootstrap — the log arrives on its own topic, not on the channel carrying the act) and R4.5 (local state that is authenticated and converges). It is the honest resolution of PRINCIPAL_MODEL §7.0.2's custody boundary: the gateway relays an act it cannot author, which is exactly what #2469 says is impossible today.

Quarantine must be bounded, and correctness rests on re-delivery — not on retention. "Never reject" invites an obvious attack: reference a log position that will never exist and the entry sits in quarantine forever. Rejecting unknown signing keys is not the fix — a device legitimately authorized at position N+1 will act before slow receivers hold N+1, and rejecting it would permanently discard a legitimate act, violating R4.6.

The correct shape has two bounds, not one:

1. Bound the position. Accept an act into quarantine only for N ≤ (highest verified position) + C for a protocol constant C. Without this, an attacker cites position 2⁶³ and the receiver can never resolve it — it cannot distinguish "not yet replicated" from "will never exist", and §9.4 forbids fetching the log over the act's channel (I9). Alternatively, require the act to carry a hash-chain inclusion witness for N; carrying is not fetching, so R4.4/I9 permits it.
2. Bound the store. #2469 slice 4's bounded quarantine with eviction and a steward release valve, where an evicted entry is recovered by anti-entropy re-delivery once the prefix catches up.

Convergence therefore depends on re-delivery being reliable over time — a property of the replication layer, not of this design. Stating "never reject" without both bounds would be an unbounded-memory claim, and the position bound in particular was missing from an earlier draft (found in adversarial review). Folded into O-N5.

Note what is not claimed: this does not make the production gateway composition converge on its own. #2469 §7.0.1's second barrier — a receiver cannot deterministically evaluate standing/suspension because that state is unauthenticated (F17) — is untouched by anything here, and remains #2441's.

9.5 Where the Meaning Firewall falls

PRINCIPAL_MODEL §1.1 forbids Person in the kernel and §4 then proposes it as a principal class. This model has no such tension:

A subject is meaning-free: it is any entity with an evolving authorized key set. A person, a treasury and a node are all subjects. That is why this model satisfies R13.1 where a Person principal class cannot.

One leak to watch. §9.1 says the log is "replicated to that subject's relying parties", and knowing which parties those are is context knowledge sitting inside the identity layer. Keep the identity layer's interface to an opaque destination set supplied from above, or R13.1 erodes here first. Flagged in adversarial review; folded into O-N5.

9.6 What this does not solve — read this before building on it

1. The N1 per-subject authority-log primitive exists as additive library code in icn-identity, but is not production-integrated. Its canonical bodies, durable join and pure derived view are implemented and tested; replication, gateway/runtime wiring and migration remain absent. The legacy RotationEvent path described in §3.7 remains unwired and is not replaced in production by N1.
2. N1 implements deterministic backward-chained pre-rotation as a library primitive, but no production path uses it. It remains load-bearing cryptographic machinery whose operational custody, replication and recovery integration are later slices.
3. Selective disclosure does not exist and cannot be wired today. F16: blind signatures are not blind, the accumulator uses a 32-bit test modulus, the trusted-issuer check passes on an empty list, and the default build can neither prove nor verify. R6.2 and any nullifier-based sybil story are new cryptographic work, not integration.
4. #2469 §7.0.1 still contains the production gateway composition. Nothing here lifts it.
5. Guardian collusion and relay withholding remain unmitigated (scenarios 5, 11).
6. Cross-context divergence under concurrent recovery is a real cost (scenario 3).
7. The continuity root concentrates what Model A distributes — its compromise is takeover of every context plus full deanonymization, and under path (a) it is unrecoverable (§12.2).
8. R9.1 [HARD] is not fully met. Path (a) fails if the backup is lost; path (b) needs threshold signing ICN does not have (F7) and which appears nowhere in §19.1's slice graph.
9. Per-subject log availability is a real dependency (§7, Model C costs).
10. Byzantine reliable broadcast is a prerequisite and does not exist — gossip entries carry no signature at all (§3.7, §6.1).
11. Class 1 currently degrades to a known R5.1 violation until O-N6 (§9.3).
12. Class 2 is not convergent under a fork — two replicas can hold permanently different settled state (O-N7). This model is not by itself a sufficient basis for irreversible settlement.
13. A single compromised current key halts a subject unilaterally, and recovery orphans every later event (§9.2.1). Fork depth is a cost multiplier.
14. Guardian recovery needs threshold signing (N7) to avoid being a kill switch — independent M-of-N signatures make any M guardians able to halt the subject permanently (§12.2).
15. The durable set is attacker-writable; eviction must be protocol-specified and authority-aware, and beyond the frontier the gap region is unsolved — so R4.6 and permutation-invariant convergence hold only absent adversarial storage pressure (O-N8).
16. Existing key-derived DIDs need a new SubjectId and a documented membership bridge — the DID cannot be the subject identifier (§15.1).
17. R5.1 [HARD] is not met for class 2 at all, and is met for class 1 only once O-N6 lands. The position window binds only when checked against an evaluation position the signer does not control, and class 2 has none (§9.3).
18. R2.3 [HARD] is qualified — receipts from positions orphaned by a superseding rotation lose their authorization proof (O-N9).
19. Threshold signing alone does not remove the guardian kill switch — closing it also needs enforced canonical body derivation and one next-authority commitment per position (§9.2.1 constraint 3).

10. What Did should mean

RECOMMENDED: option B of the mission's list — Did names a cryptographic principal, and nothing else.

That is what the type already is (§3.1); the change is to stop projecting other concepts into it, and to make the type enforce what it claims.

Should a global Person ID exist? No. Not because privacy outranks verifiability, but because nothing needs it: authorship is provable against context-local authenticated state (§9.4), and sybil resistance needs uniqueness, not identification (R6.6). Every mechanism whose sole purpose was to make a global identifier work — global current-root discovery, global fork selection, global genesis bootstrap — is cost with no corresponding requirement.

11. Privacy and correlation

11.1 What each observer learns

Device keys must be per-context too. If one device key appears in two contexts, the identifier separation is defeated. Per-context device keys are a deterministic derivation from the device's own secret.

The derivation must not take SubjectId as input for the initial key, or genesis is uncomputable. (Caught in review round 5.) The inception body contains the initial key K₀, and SubjectId = event_id(inception body). So setting K₀ = KDF(secret, SubjectId) requires solving the fixed point S = H(inception(KDF(secret, S), …)) — offline genesis cannot construct it.

The fix is to derive the initial key from a pre-subject context nonce chosen locally and carried in the inception body: K₀ = KDF(secret, nonce). The nonce exists before the subject does, so there is no cycle. Keys for later positions may safely take SubjectId as input, because by then the subject exists.

That derivation is itself a correlation oracle, and an earlier draft called it "bookkeeping, not custody burden". (Corrected in adversarial review.) Anyone holding the device secret can recompute the per-context key for any candidate SubjectId and so confirm or deny membership in any context they can guess. Device-secret compromise therefore deanonymizes every context, not just the one the device was stolen for. A non-derived (independently random, stored) key per context removes the oracle at the cost of backup complexity. OPEN — folded into O-N3.

Residual correlation, stated honestly. Four channels, none of them closed:

1. Within a context — everyone in Coop A correlates S_A's activity there. Unavoidable and correct.
2. Shared infrastructure — a gateway relaying two of a person's contexts sees both. This is the default hosted deployment (R11.1), not an edge case.
3. Recovery timing — recovery is a logged event visible to every relying party (R9.2). A person recovering after device loss rotates in every context within one window, and an observer of two coops' logs correlates on timing. R6.4 is weakened by the very auditability R9.2 requires — a genuine tension between two requirements, not an oversight.
4. Social knowledge, timing and network metadata generally.

This is protocol-level unlinkability against a passive observer of distinct contexts, not anonymity, and nothing here should be described as the latter.

11.2 Sybil resistance without identification

SDIS's genuine contribution is VUI — "proves uniqueness without revealing the underlying identity data". The correct shape is a per-context nullifier derived from a uniqueness credential: an institution learns "this is one distinct verified human, and not one it has already admitted" without learning which.

This cannot be built today (F16), and saying otherwise would be inventing a protocol to close a hole. Interim honest posture: uniqueness is a steward attestation against a registry the steward holds — which is what SDIS actually does — and that registry is a correlation surface. Recorded as OPEN (O-N2).

11.3 Proving two personas are one human

The person signs a linkage statement with the current authorized keys of both subjects, naming both SubjectIds and a purpose. Cheap, consent-gated, verifiable, and revealing nothing until the person chooses. This is the property Model A gets backwards: there, linkage is always on and cannot be withheld.

12. Recovery

12.1 Pre-rotation is the recovery mechanism

The inception event commits to a digest of the next key set. If that next key set is derived from the continuity root, held in backup and not on any device, then total device loss is recovered by restoring the root, deriving the pre-committed keys, and rotating.

This dissolves O14's mechanism — and only its mechanism. O14 asks how a total-loss recovery can advance the chain when RotationEvent::verify requires an existing non-revoked authorized key (multi_device.rs:541-552) and total loss has none. Pre-rotation answers exactly that: the committed-but-never-used next key is an authorized key, so no separate "threshold-recovery transition" needs to be bolted beside the chain rule — it is the chain rule.

What it does not solve, stated plainly. Pre-rotation presupposes the pre-rotation material survived. It converts "I lost my devices" into a solvable problem; it does not solve "I lost my devices and my backup." That case has only one answer — guardians (path (b) below) — and a person who chose path (a) and lost both has lost the subject. Describing O14 as fully closed would be exactly the invented-protocol failure the review discipline forbids.

12.2 Two paths; the person chooses

Path (b) is a kill switch, and a single group key is necessary but not sufficient to close it. With M-of-N guardians signing independently, two different quorums produce two different authorized establishment bodies at the same position, so supersede cannot choose and the subject halts permanently (§9.2.1, constraint 3). That means any M colluding guardians can destroy the subject rather than merely capture it — a strictly worse outcome than takeover — and it can happen with no adversary at all, if a phrase-holder rotates at p while a guardian quorum recovers at p. Path (b) therefore requires a single group public key emitting one signature over one body (FROST-class), which makes N7 a hard prerequisite of guardian recovery rather than an optional upgrade. An earlier draft's "insufficient alone" understated this badly.

And N7 alone still does not close it (round 5): a group key authenticates a quorum, it does not restrict that quorum to signing one message. Closing it needs the two rules in §9.2.1 constraint 3 — authorized must enforce canonical body derivation, and each position must commit to exactly one next authority, so path (a) and path (b) can never both be armed at the same position.

Path (a) root compromise is not a race the victim can win. An attacker holding the continuity root derives the pre-committed keys, rotates first, and commits a fresh next digest the victim does not hold. From that point the victim cannot rotate even though they still know the root — pre-rotation has handed the attacker the same one-way advantage it was meant to give the legitimate holder. Worse, the attacker can do this silently from a backup copy, at leisure, with no need to touch a device.

So pre-rotation makes root compromise more decisive, not less. It is an excellent defence against device compromise and no defence at all against backup compromise. That asymmetry is the entire argument for path (b), and an earlier draft's matrix cell claiming "root compromise survivable ✔ pre-rotation" was simply wrong.

Default is (a), upgradeable to (b). That answers PRINCIPAL_MODEL's O1 ("may the root live on the first phone?"): the operational keys live on the phone; the pre-rotation material is backed up off-device at onboarding. R10.2 is met — phone-only onboarding is secure and recoverable by default rather than degraded — at the cost of exactly one irreversible user decision (R10.3).

12.3 Constraints any recovery must satisfy

• R9.4 — distinct authenticated participants. Today both threshold paths fail: sync.rs:263-269 neither verifies signatures nor deduplicates; SDIS's approve_by_steward() is a bare += 1. Fixing this is #2591 plus its SDIS sibling, and it is a precondition for (b), not a follow-up.
• R9.2 — recovery is a logged event. It is an ordinary event in the subject's authority log, visible to every relying party. Never a silent substitution.
• R9.6 — contestable, and this is a named exception to R4.1/R4.3. A relying party may apply a notice-and-veto window before honouring a recovery rotation. It cannot be position-denominated: in a takeover the attacker controls log advancement and would simply advance past any positional window. So it is a wall-clock window, and deciding whether to honour a rotation is a validity decision.

  Consequence, stated rather than finessed (found in adversarial review): two nodes of the same institution with identical durable state but skewed clocks can reach different verdicts during the window. That violates R4.1 and R4.3, both [HARD]. It is accepted here as a bounded, deliberate exception confined to recovery-rotation acceptance — never to ordinary act admission — because the alternative (no contest window) makes R9.6 unimplementable and hands a stolen backup an uncontested takeover. A deployment that cannot tolerate the exception must set the window to zero and accept that instead. This is the only place in the design where a receiver's clock decides anything.

• R9.5 and R2.4 — path (a) does not meet them, and that is a deliberate trade. The continuity root in path (a) is a permanent secret, and an attacker holding it can rotate the subject away. Recovery from that is a race the legitimate holder may lose, mitigated only by a relying party's notice-and-veto policy. Path (a) therefore trades R2.4/R9.5 [STRONG] against R10.2 [HARD] — phone-only onboarding that is recoverable by default. Path (b) removes the single-secret failure at the cost of guardian UX. The trade is the person's to make, and a deployment that silently pins everyone to (a) has made it for them.
• The recovery↔DID contradiction must be adjudicated (§3.6). Under this model the subject identifier is unchanged by recovery — it commits to the inception event, which recovery does not rewrite. social-recovery-design.md's did_mapping:<old_did> indirection becomes unnecessary and should be retired.

13. Offline and partition semantics

No wall clock in act admission. Positions replace timestamps (§9.3), which also removes F14's fail-open failure mode. One validity decision does use a clock — recovery-rotation acceptance (§12.3) — and it is declared an exception rather than hidden.

Where clocks legitimately remain — and why they are not R4.1 violations. R4.1 forbids a receiver's clock from deciding validity. Three clock-shaped things survive, and none is that:

Thing	Whose clock	What it decides
"the subject periodically advances the log" (§9.3)	the subject's, on their own device	when they re-authorize. A liveness schedule, not a verdict. Every receiver still decides positionally
a relying party's notice-and-veto window before honouring a recovery (§12.3)	the acceptor's	whether to honour a recovery rotation — a genuine validity decision, and a named R4.1/R4.3 exception, not an exempt case. See §12.3
quarantine eviction (§9.4)	the receiver's	when to forget and rely on re-delivery — never whether an act is valid

The test to apply to any future addition: if two honest receivers with identical durable state could reach different verdicts because their clocks differ, it is an R4.1 violation. The first and third above cannot. The second can, and is therefore declared an exception in §12.3 rather than defended as compliant.

14. Institutions and nodes

14.1 The pattern generalizes — and that is a result, not an aesthetic

durable subject ≠ current authority

holds for humans (subject ≠ device keys), for institutions (charter ≠ current stewards) and for nodes (instance ≠ operator). All three are subjects in the §9.1 sense, which is why the identity layer can stay meaning-free.

14.2 Institutions: PRINCIPAL_MODEL §4.1 is upheld, with a caveat

Its conclusion — an institution holds no signing key, because Did models custody and institutions are constituted by governance — stands, and this model strengthens the reasoning: Did is only a key here, so it is even more clearly the wrong type for a governed entity.

But the caveat matters. The argument's premise was "an institution's identity would have to be a key." Under §9.1 that premise is false: an institution could be a subject with an authority log whose authorized keys are its current stewards, and no single person would "be" the institution. O12 therefore reopens on better terms — the question is no longer "key or mandate chain" but "does an institution need a self-authenticating statement, given that a subject log now makes one possible without single-custodian capture?" Recorded in §17.

FounderSignature (F18) is the existing primitive to build on: an institution's inception event, signed by its founding persons, is a natural EntityId binding and resolves PRINCIPAL_MODEL's O11 by construction (the id commits to the event).

14.3 Nodes

Node identity is the strongest binding ICN has — the Hello three-fact cert check (icn-net/src/handlers/hello.rs:62-97) is genuinely sound, and is per connection, not per peer (handlers/mod.rs:76-78). Nothing here changes it.

Two facts worth carrying forward: operator_did is populated as did.clone(), did.clone() (supervisor/lifecycle.rs:371-375), so node and operator are the same principal today; and node key rotation produces a new DID and is never persisted (keystore.rs:1224-1257 does not call save_v4). Under §9.1 a node becomes a subject whose authority log survives key rotation — which is the principled fix for both, and which also gives O2 (does a restored node keep its DID?) a cleaner answer: the subject persists, the keys rotate, and restore-twice is detectable as duplicity rather than indistinguishable from a clone.

15. Migration

Classification per mechanism: KEEP · MIGRATE · DEPRECATE · REMOVE · COMPATIBILITY-ONLY.

15.1 Key-derived Person DIDs — KEEP the key, allocate a new subject

This is the largest deployed class, and the key does not change. An existing did:icn:<key> is already exactly what §10 says a Did should be: a cryptographic principal. Two consequences:

• Nobody "becomes a new person" (scenario 25). No cutover, no re-enrollment, and no key ceremony: the person keeps signing with the key they already hold.

But the existing DID cannot itself serve as the SubjectId, and an earlier draft said it could. (Corrected in review round 3.) SubjectId = event_id(inception body) and inception admission checks σ == event_id(b), whereas did:icn:<key> encodes an Ed25519 public key. Barring an accidental preimage the two cannot coincide, so such an inception is inadmissible and the derived view stays Unknown.

The honest migration is therefore: allocate a new SubjectId, whose inception event names the person's existing Did as its initial authorized key. What is preserved is what actually matters — the key, custody, and the ability to sign — and what changes is the context identifier.

That is a smaller cost than a re-enrollment and a larger one than "no event". In particular, membership rows keyed by the member's Did need a documented bridge to the new SubjectId, which is the same shape as the bridge icn-commons already maintains for enrollment-DID → anchor (§15.2). Specifying that bridge is a migration prerequisite, not a detail.

Rejected alternative: a "legacy inception" rule admitting σ == did_of(initial_key). It preserves the identifier but destroys inception uniqueness — two different inception bodies could then claim one σ, producing duplicity at position 0, which §9.2.1 relies on being impossible.

15.2 SDIS anchor-derived DIDs — DEPRECATE, at near-zero cost

PRINCIPAL_MODEL rates O18 critical on the assumption that anchor-derived Persons are a live identity class with deployed authority. Anchors are created in production (F4) — but two verified facts show they carry no authority:

• F5 — in the enrollment path the acting principal is already the device key: simple_enrollment.rs:667 ("The DID is the ephemeral_did — in SDIS, keys are created on the device"), and the token is minted for ephemeral_did (:782). The anchor is returned alongside as anchor_id.
• F20 — the anchor's mutating routes are disabled, returning Forbidden.

And F4 shows the anchors that do exist carry none of the properties the design claims for them: the VUI is SHA256("gateway-enrollment-vui:" ‖ did), so it is a pure function of the public DID.

No deployed anchor-derived DID carries authority, and no deployed anchor carries a uniqueness or unlinkability property. Migration is therefore:

That trace is now complete — and it comes out clean, for an uncomfortable reason. (Left open in the first pass; resolved in review round 2.)

Step	Finding
PersonhoodAnchorStore::put indexes the anchor-derived DID	personhood_store.rs:202-205 — let did = anchor.to_did(); … put(&did_index_key(&did), anchor_id)
link_did, which would add the member's real DID to that index	zero production callers. The one hit, icn-net/src/rate_limit.rs:1781, sits after the #[cfg(test)] boundary at :1406
PersonhoodAnchorStore::get_by_did	reached only by the trait forwarder get_anchor_by_did at personhood_store.rs:599, and no production code constructs this store (supervisor/lifecycle.rs:1407 passes None). (An earlier draft said "zero production callers", which was imprecise.)

| the live anchor-by-DID lookup is a different store | icn-commons/src/store.rs:529, reached from api/commons/mod.rs:131,469 — and it maintains an explicit bridge, put_anchor_did_index, doc-commented "used when the enrollment DID differs from the anchor's internal DID" (store.rs:539-545), written during enrollment at icn-commons/src/inner.rs:173 | | standing / holder lookups | go through CommonsStore::get_holder_by_did(holder_did), where holder_did is the DID passed to create_holder_from_anchor — the member's ephemeral_did in the enrollment path (simple_enrollment.rs:703) |

So there is no live cross-keying mismatch — and for a better reason than the first draft gave. The live path (icn-commons) maintains an explicit bridge index from the enrollment DID to the anchor, precisely because the two differ; the path that indexes only the anchor DID (icn-identity's PersonhoodAnchorStore) is never constructed in production. Standing and membership consistently key on the member/device DID.

This does not make the migration risk-free, and the finding should not be read as a clean bill of health. It means the hazard is latent rather than active: the first caller to use PersonhoodAnchorStore::get_by_did with a member DID gets None, because only the anchor DID was ever indexed and link_did is never called. That fails closed, which is the safe direction, but it is surprising and would read as "this person has no anchor". Removing to_did() should therefore also remove or repurpose the DID index rather than leave a half-wired lookup behind.

15.3 Everything else

16. Rejected alternatives

17. Open decisions

Carried forward from PRINCIPAL_MODEL where still live, plus new ones from this pass. A correct OPEN is better than an invented answer.

Closed by this document: O1 (§12.2); O7 (§9.3's class table answers "which operation classes may a device sign"); O8 (§18); O9 (§18 — rejected as posed, which is a disposition, not a solution).

Decided in principle, mechanism still open: O3 — pairwise identity is adopted with costs stated (§11), but the mechanism that would complete it is O-N2, and F16 says it cannot be built today. Calling O3 "closed" would be relabelling.

NOT closed, contrary to an earlier draft of this list (corrected in adversarial review, which caught it contradicting §18): O10 — still required and widened; O13 — partial, receiver-side retirement unsolved; O14 — mechanism only, custody remains; O16 — narrowed to O16′; O17 — partial, authenticity ≠ acquisition; O18 — closed as an identity class, but see the untraced anchor↔member keying question in §15.2.

18. Consequences for the recorded open decisions and slices

19. Revised dependency graph and the next slice

19.1 The graph

  N1  authority-log primitive          (library only; no wiring)
   │      SubjectId = H(inception) · pre-rotation · +1 monotone
   │      canonical domain-separated preimage  [absorbs O10, F12]
   │
   ├──► N2  narrow `Did`               [F1, F2 — removes from_anchor_id]
   │
   ├──► N3  log replication  ==  BUILD BYZANTINE RELIABLE BROADCAST
   │          gossip entries carry no signature at all (F17/§3.7), so this is
   │          a new primitive, not a new topic.  + bounded quarantine [O-N5]
   │          │
   │          └──► N4  device authorization + attenuation
   │                     [folds #2588, #2590; needs O-N1]
   │                          │
   │                          └──► N5  GOV_OP_V2 member-origin signing
   │                                    [still bounded by #2469 §7.0.1]
   │
   ├──► N6  mobile: subject + device split + pre-rotation backup   [F19]
   │
   └──► N7  threshold SIGNING (FROST-class) — a HARD PREREQUISITE of guardian
              recovery, not an upgrade.  ICN has a threshold PRF, not threshold
              signing (F7).  Without N7, independent M-of-N signatures give any
              M guardians a KILL SWITCH (two quorums => two authorized bodies at
              one position => permanent halt), so path (b) must not ship first.
              NECESSARY BUT NOT SUFFICIENT: N7 alone leaves the halt attack
              intact — a group key authenticates a quorum, it does not bind that
              quorum to ONE message.  Path (b) is safe only with N7 PLUS
              `authorized` ENFORCING canonical body derivation PLUS exactly ONE
              next authority armed per position (§9.2.1 constraint 3).
              Without N7, R9.1 [HARD] is met only by the backup-phrase path.

  independent, and should not wait:
     X1  #2589 invite-mint fix
     X2  #2591 recovery signature + dedup  (+ the SDIS sibling)
     X3  the F2 / F13 findings — see §19.3

The old order — [O18] → A0 → (B ∥ C) → [A blocked on O9; D blocked on O9+O13] → … — is replaced. O18 no longer precedes anything (§15.2), and A/D are no longer blocked on O9 because O9 is not a prerequisite; it was an unachievable goal.

19.2 The exact next slice — N1: the authority-log primitive

Smallest slice that either validates or refutes the architecture, with no wiring, no gateway change, no SignedGovernanceOp change.

• Invariant — stated over §9.2.1's two-layer model, not over a "verified prefix". (The earlier formulation — permutation-invariance of (longest verified prefix, duplicity set) — is withdrawn; §9.2.1 explains why it is not a join.) Two obligations, tested separately:

  • Durable layer. S(σ) is a set of admissible events keyed by event_id = H(canonical_body); the join is set union; admissible is state-independent, so it commutes with union.
  • Derived layer. derive(S(σ)) is a pure function — same set, same verdict, regardless of receipt order — halting on |C| ≥ 2 after supersede.

• Seam. A new module beside icn/crates/icn-identity/src/multi_device.rs. Do not modify multi_device.rs in this slice.

• Proof / tests — the two layers are tested separately.

  Durable join (properties, ideally proptest):

  1. commutativity — S₁ ⊔ S₂ = S₂ ⊔ S₁;
  2. associativity — (S₁ ⊔ S₂) ⊔ S₃ = S₁ ⊔ (S₂ ⊔ S₃);
  3. idempotence — S ⊔ S = S, including a re-signed identical body, which must collapse to one element (the event_id rule);
  4. permutation-invariant durable state — every delivery permutation of one event multiset yields the same S;
  5. admissible is state-independent — as a differential property, not a signature observation. Classify one event under many randomly generated surrounding contexts and require an identical verdict every time. (An earlier draft said "assert by construction: the function takes only the event"; that is unfalsifiable — fn admissible(&self, e: &Event) on a struct holding the store satisfies it while consulting state.)

  Derived view (determinism): 6. deterministic authority view — derive over equal S yields equal verdicts, across permutations and across independent replica instances; 7. gaps buffer — an out-of-order event is retained and unused, never rejected, and never wedges once the gap fills (cases 1–2); 8. conflicting same-position events → Halted(p), identically on every replica, in both arrival orders (cases 3–5); 9. unauthorized or malformed events cannot fork or block — spam at position p never enters C (case 7); 10. pre-rotation — a rotation revealing the committed material succeeds; one without it is retained but never authorized (cases 8, and scenario 1); 11. non-establishment fork detection — a compromised current key forking an authorize/revoke is detected, not prevented by pre-rotation (case 9); 12. superseding recovery — a legitimate rotate at the disputed position supersedes the forked non-establishment event and advances (case 10). Two authorized establishment events at one position must halt, not choose; 13. no branch selection by content — as two falsifiable properties. (a) derive's verdict is invariant under any injective relabeling of event_ids, which no lowest-hash or ordering-based tiebreak can survive; (b) for every generated set with |C| ≥ 2 after supersede, derive returns Halted. (An earlier draft asserted "no such rule exists anywhere", an absence claim over an unbounded space that nothing can fail.)

  Cases the first draft of this list could not fail — added after review round 2: 14. re-signed identical body collapses to one element and does not produce Halted; the witness set grows instead; 15. deterministic rotation body — deriving the same rotation twice from the same state yields one event_id; a non-deterministic construction that yields two authorized rotations at one position is rejected at construction time, because at derive time it is already an unrecoverable halt; 16. digest consistency — σ, prev_digest and dedup all use event_id = H(canonical_body); a child naming a whole-event digest fails; 17. fork behind the frontier — bodies at 0–5 and 8–9 with a fork at 3 must halt at 3, and a superseding rotation at 3 must be shown to orphan 4, 5, 8, 9 (the test asserts the loss, so it cannot be discovered later as a surprise); 18. unilateral self-equivocation — one authorized key emitting two distinct bodies at one position halts the subject with no second party involved; 19. authority principals are raw Dids — an event naming a SubjectId as a device or guardian is rejected, so derive cannot become mutually recursive.

  Encoding and hygiene: 20. encode/decode round trip over a versioned, domain-separated, length-prefixed preimage, plus cross-implementation vectors (absorbs O10; avoids F12's bare-bincode signing domain); 21. no wall clock is read anywhere in the module — assert in CI, given F14.

• Security properties. Compromise of a current key cannot rotate, and can fork only non-establishment events — which superseding rotation recovers. Compromise of the inception key after a legitimate rotation grants nothing. Compromise of the pre-rotation material is out of scope of this slice's guarantees (§12.2).

• Non-goals. No replication, no gossip topic, no device-authorization format, no revocation policy, no Did change, no migration.

• Dependencies. None. This is why it is first.

• Migration impact. None — additive library code.

19.3 Findings that warrant issues before any of this

Listed, not filed — filing is a separate decision for the maintainer. The tracking column reflects a GitHub issue search performed at review round 2; it is a point-in-time result, not a standing guarantee.

19.4 Entry conditions for the N1 session

N1 is a design-and-test slice, not a wiring task. Before writing code it must settle three things this document deliberately left open, because each changes the event field set and freezing the format first would repeat the mistake PRINCIPAL_MODEL §15.1 identified:

1. The canonical preimage — version, domain separator, field order, encoding, and the Did canonicalization rule (§10). Absorbs O10; must not repeat F12's bare-bincode signing domain.
2. The pre-rotation commitment scheme — what is committed, and how a rotation proves it. This is the load-bearing new mechanism and has no precedent in the repo. It must additionally make the whole rotation body re-derivable (e.g. K_{p+1} = KDF(root ‖ p+1) with every other field determined), because pre-rotation commits to the next key set and not to the body — so a non-deterministic construction lets one honest signer author two authorized rotations at one position and halt the subject permanently, with no attacker present (§9.2.1, constraint 2). authorized must ENFORCE the canonical derivation, not merely permit it, and each position must commit to exactly one next authority — otherwise two quorums, or a phrase-holder racing a guardian quorum, still produce two authorized bodies (§9.2.1, constraint 3).
3. The event taxonomy — inception / rotate / authorize / revoke / recover; which are establishment events (and so eligible for supersede); and which may carry a validity span (O-N1). Two invariants are normative, not stylistic: an event is establishment iff authorized requires a pre-rotation pre-image reveal — never a capability flag, and no delegation path may mint one, which explicitly bars §9.5's generic attenuating delegation from establishment authority; and every authority principal named inside an event is a raw Did, never a SubjectId, or derive stops being a pure function.
4. The replicated state model must be taken from §9.2.1, not re-invented. This was added after review round 2 found that two successive drafts had specified a merge that does not form a join. The N1 session inherits, and must not redesign:
   • durable state = a set of admissible events keyed by event_id = H(canonical_body), joined by union;
   • admissible is state-independent — it must take the event and nothing else;
   • the derived authority view is a pure function of that set;
   • supersede (establishment over non-establishment) is the only selection rule, and |C| ≥ 2 after it halts;
   • no content-based tiebreak of any kind — no lowest hash, no first-seen, no longest chain.

Everything else in §19.2 is testable once those four are fixed.

20. Decision classification index