Home runtime identity profile — decision record for the first personal-domain vertical slice

Companion to: N4A_DEVICE_AUTHORITY_EVALUATION.md (the primitive), IDENTITY_SEMANTICS.md (the canonical contract), GEN_SUBJECT_CONTEXT_GENESIS.md (genesis) · Issues: #2599 (N4), #2602 (GEN), #2694 (ladder), #2800 (N1-D), #2801 (naming), #2806 (ADR-0083 drift) · PR: #2807

Truth status. This is a decision record and consumption profile, not a new identity model and not an implementation claim. Every primitive it names is classified below as PRODUCTION / LIB-TESTED / FIXTURE-ONLY / EXPERIMENTAL / DOC-ONLY / MISSING against the live checkout at main 7ef8a670a plus PR #2807 (2026-10-04). Rows (f) and §6.3 were updated on 2026-10-24 after N1-D (#2800) and its daemon rehydration (#2843) merged; every other class is as of the original snapshot. Where a class says MISSING, nothing downstream may build a substitute. The motivating deployment (a thin client to a hosted workstation) is a fixture for requirements; it is not part of ICN and no real person's identity material exists or may be created from this document.

0. The question and the one-line answer

Which ICN primitives does a person's Home runtime consume so that a phone, a small desk computer, a PC and a hosted workstation can be replaceable device Principals under one durable human, in several contexts, without any device, host or operator becoming the human?

Answer. The human is an N1 Subject per context (GEN-A inception, client-held ContinuityRoot); each device is an ordinary Principal holding a per-context key of its own; authority is an N1 Authorize grant in the Subject's log, bounded by capability set and optional position span; revocation is an N1 Revoke; a relying party decides any act with N4-A verify_device_act at a position it chose. All of that is LIB-TESTED today. What is MISSING is the enrollment ceremony that moves a grant request from a new device to the phone and the event back (N4), a transport container for facts and acts (next slice), a GEN context kind for personal and household contexts (#2602), and recovery (N7). The Home runtime consumes; it never defines.

On naming: per #2801, Mutualware is the intended public name of ICN itself, public-brand-first and protocol-stable. There is no "Mutualware identity" and no "contract layer" above ICN. A downstream document that frames a Home runtime as a contract layer should read it as a consumption profile of ICN identity — this document — and nothing more.

1. Primitive map (acceptance item 1)

Classes: PRODUCTION exercised by a running node, route or deployment (operationally wired; ADR-0032/0033 maturity claims need that evidence) · CLI-REACHABLE executable by an operator from a workspace binary, with end-to-end tests, but wired into no runtime, route, deployment or profile · LIB-TESTED implemented and tested, no runtime caller · FIXTURE-ONLY exists only inside tests · EXPERIMENTAL present but unreachable, stubbed or unsafe · DOC-ONLY · MISSING.

What a Home runtime consumes today, truthfully: rows (a), (b), (c), (c′), (d), (g) and (h′) as a Rust library, and row (h) as a stateless icnctl verb. Row (i) (context kinds) and the transport/delivery around (h′) are the seam it is still waiting on.

2. The fixture test (acceptance item 2) — done

icn/crates/icn-identity/tests/device_authority.rs (PR #2807): Subject S; A authorized at 1, B at 2, A revoked at 3. A's act at E = 3 → Refused(DeviceNotAuthorized); B's → evidence {granted_at: 2, generation: 0}; S's identifier, authority set, generation and next commitment identical before and after; A ∉ devices, B ∈ devices, B ∉ authority; device bytes ≠ Subject bytes. A's act at E = 2 still verifies. 25 tests; independent reference 4/4.

Extended through every boundary (2026-10-04): tests/device_lifecycle_acceptance.rs enrols A and B through N4-C requests and attenuated approvals, carries the facts and each act as N4-B bytes to an independent relying party, revokes A, and pins: A refused and B accepted at the current position; S's identifier, authority set, generation (still 0: nothing rotates) and pre-rotation commitment unchanged; the same verdicts for every arrival order of the facts; and a relying party that evaluates at a position it does not hold failing closed (PrefixIncomplete). A relying party whose facts stop before the revocation still accepts A at its own older tip: it is behind, not deceived (N4-E §4). 2 tests observed 2026-10-27.

3. The external verification boundary (acceptance item 3)

The container's record layout should align with #2800's event_id ‖ signature → canonical body so that "what the daemon persists" and "what a client carries" are one framing. With N4-B landed, external systems consume ICN truth reaches a stateless CLI relying party; what the Home runtime still lacks is the ceremony transport (N4-C defines the request and approval, not their carriage) and a context kind for personal/household contexts (#2602).

4. GEN stance for Private / Household / a person's own project (acceptance item 4)

Can a personal or household context exist today without a GovernanceDomain?

Mechanically, yes: GEN-A accepts any non-empty UTF-8 context_id and never checks that a GovernanceDomain exists (subject_context.rs:293–305). Semantically, no: the only kind tag is GovernanceDomainV1 (0x01), so a Subject incepted for "household.example" is a Subject in a governance domain called household.example. That is the institutional collapse the contract leaves to GEN to avoid (IS §2.2: "a context may later be bilateral, informal, community-level … GEN defines").

Three routes were weighed:

Proposed shape, for #2602 to decide (not decided here):

NON-NORMATIVE until #2602 decides: neither kind exists, nothing may implement or rely on them, and the kind byte would feed the N1 KDF permanently.

• PersonalContextV1 — one human, no other party. context_id is an opaque 32-byte descriptor digest the person's own client mints and keeps; it is never published beyond the person's own clients and devices. No registrar, no founder, no charter. Private and a person's own small project are both this kind; if a project later takes on members it becomes a household or an institution through genesis, not by relabelling.
• HouseholdContextV1 — two or more humans, no governance object. context_id is the genesis digest of a household descriptor the founding members' clients agree on; membership is mutual recognition between members' Subjects (the GEN-B recognition shape, bilateral), never an AuthorityGrant, never a steward. A household has no treasury, no charter and no office; if it ever needs institutional authority it undergoes institutional genesis and becomes an Institution — it is not promoted in place.

Each human still holds one Subject per context, so person-A-in-Household and person-B-in-Household are two Subjects, unlinkable to their Private Subjects except through each person's own ContinuityRoot.

What this means for the vertical slice now. The device-authority proof is context-agnostic, so it is testable today against a fixture GovernanceDomainV1 context. No production Private or Household context may be created until a GEN kind exists; the deployment track is not blocked by that, because it does not create any context.

5. Contradictions, settled against the text

6. What a Home runtime may implement against today (acceptance item 5)

This is the specification a deployment track may build to without inventing identity. Every step says which ICN object it produces or consumes and whether that object exists. Steps marked MISSING may be designed around but must not be substituted by a conventional mechanism that pretends to be the ICN one.

6.1 First boot of a device (any endpoint: desk computer, PC, hosted client)

The device presents a key, nothing more. Possession of the device proves nothing about the human.

6.2 Enrollment approval

Forbidden substitute: a bearer token, invite code, OS account, SSH key, RDP login or TLS client certificate standing in for the Authorize event. These may gate a transport; none of them is device authority.

6.3 What the Home runtime stores

6.4 What revocation does

1. The authority edge authors N1 Revoke { device } at the next position.
2. Any relying party that has retained that fact evaluates every later act at E ≥ the revoke position and refuses the device (DeviceNotAuthorized). Acts at earlier E remain verifiable: history is not rewritten.
3. Effectiveness is per relying party, exactly as far as its retained facts go. There is no global instant revocation and no claim of one (#2599 invariant 5; N3 owns propagation).
4. Replacing a device is Revoke(old) + Authorize(new); the Subject is untouched. Reflashing a device is the same two events; a reflashed device with a fresh secret is a new Principal.
5. A Home runtime that loses contact with the authority edge cannot revoke anything; it can only stop relaying. Stopping relay is a hosting decision and confers no authority.

6.5 What the TLS trust root is

ICN binds a Principal to a TLS certificate only for nodes, through BindingInfo in the network Hello (bundle.rs:181; IS §9), and that binding is per connection and node-scoped. There is no device-Principal-to-TLS binding for Home transports, and BindingInfo must not be repurposed for humans or devices. Therefore:

• the thin-client transport (remote desktop to a hosted workstation) keeps its conventional PKI, owned and operated by the deployment track; it is a transport fact, not an identity fact;
• a Home transport that wants "this connection is device Principal K" uses the N4-D binding: a Present act whose payload is (channel digest, nonce), verified by N4-A over retained facts and then one equality against the channel the relying party sees — LIB-TESTED (N4D_DEVICE_CHANNEL_BINDING.md); what channel digests is the transport profile's to state;
• nothing about a TLS root ever identifies the human.

6.6 The MAY / MUST NOT list

A Home runtime or deployment MAY rely on: the N4-A verdict and the VerifiedDeviceAct that verify_device_act returns (never bare DeviceAuthorityEvidence from evaluate_device_authority, which checks no signature and names no act); act_id as an act's identity; the refusal classes; the rule that a revoked device is refused at every E at or after the revoke and unaffected before it, under the facts retained (N4-A §2); the N1-D record layout (merged, #2800). No hosted verifier and no consumer that enforces an action on an N4-A result exists today. When one is built, it must enforce on a VerifiedDeviceAct, never on an authority evaluation alone.

It MUST NOT: use a node's transport or network key as a device Principal (a public node key would make the device a correlation handle for the person, IS §2.4); reimplement encodings, the fold, grant semantics or refusal logic in another language; treat any account, key, token, VM or machine as the Subject or derive a SubjectId from one; hold or derive a ContinuityRoot on infrastructure; mint a Subject or a context on a person's behalf; choose E from the act or fall back to the frontier when the act's E is not retained; build an enrollment, revocation or recovery mechanism of its own; promote fixture identities into anything real.

7. Acceptance scenario status

8. Routing

#2694 (ladder; container as the shared missing boundary) · #2599 (device case; ceremony, device TLS binding) · #2602 (context kinds) · #2806 (ADR-0083 status drift) · PR #2807 (this branch).