[DM-084] Distributed custody and RC identity hardening

[nicoechaniz]

Outcome

Turn the merged V0 baseline into a release-candidate identity/recovery boundary with a genuinely separated recovery quorum and an aggregator that never opens all holder keys. Reconcile the authoritative checkpoint documents with the merged baseline.

Baseline: e855148ffac5b2f4068ba56be6324d7b78fb430f (tree be24a07fd387c9fe10331b17507904f14f66ea71).

Blocked by

None. This card is limited to repository code, documentation, synthetic custody fixtures and disposable local/CI processes.

Acceptance

• each recovery and replacement-root holder operates one disjoint owner-only custody store;
• public, content-bound partial signatures can be produced independently;
• an aggregator validates exact bodies, roles, key IDs, thresholds, duplicates, expiry and revocation without receiving private keys;
• target authorization can also be assembled without reopening a combined root store;
• the old combined-store ceremony is removed from runtime CLI or explicitly renamed/restricted to synthetic fixtures;
• crash/retry, hostile share, missing holder and process-separation tests pass;
• RESUME.md, CURRENT-STATE.md and ROADMAP.md name the merged baseline and honest remaining gates;
• full package, conformance and supported-Python CI stay green.

Deployment: not deployed. This card authorizes no root ceremony, real key generation, external contact, host access or production effect.

[nicoechaniz]

/claim

[github-actions]

[nicoechaniz]

Implementation checkpoint (pre-release, local only): the first distributed-custody candidate 9c71e769c62f1fadf6b5ea1fd181d2be262450b0 was deliberately rejected by exact-hash adversarial review.

Release blockers reproduced: multi-head recovery was not carried through the operator/authority verifier; bootstrap still centralized genesis recovery seeds; central all-seed APIs remained public; holder descriptor publication had a crash window; and the exact static check exposed one test typing error. The candidate is being corrected in-place and will receive a fresh independent exact-head review. No PR/merge or runtime/custody claim is made from the rejected hash.

[nicoechaniz]

RC progress 2026-08-16: the first distributed-custody candidate 9c71e76 was independently rejected (dead multi-head path, genesis centralization, public all-seed APIs, holder descriptor crash window, and mypy failure). The correction round now has those reproduced blockers closed locally with per-holder genesis/recovery stores, keyless aggregation, atomic holder packages and multi-head authority handling; a clean full suite and exact commit are still pending, so no acceptance is claimed. Separately, fd2f9e9041509b50b11aef0181e434c287ac26c8 partitions all SERVICE_METHODS into disjoint least-authority profiles; it is not yet wired into bootstrap/rebirth and is therefore not a final candidate.

[nicoechaniz]

Matrix RC capability/custody successor ready for exact-hash review (not merged).

Candidate 64e41b82b6ed8a4216f1a8afe2e7913c627a55e1, tree 56c8cf0c2a28b46f5625fca707dc2792e771737b.

This consolidates the distributed recovery-custody corrections with least-authority runtime provisioning: ten disjoint role capabilities, separate keys/slots/client directories, observe-only default, bounded 30-day lifetime with T-7-day reprovision, and fail-closed expiry/revocation. Bootstrap/rebirth, install lists, docs, vectors and provenance are updated together.

Clean evidence on the exact candidate, no rerun:

• full pytest: 603 passed, 37 intentional skips, 610 subtests in 239.79s;
• focused capability/custody: 85 passed, 1 skip, 8 subtests;
• scoped Ruff and mypy (51 modules), Hermes vectors --check: clean;
• two isolated builds byte-identical: wheel sha256 5a62bb11ddaea6a4f72e78b6a6311da2fb7055bc4f0ba62bb1322301970d6558, sdist 1d8c9add2a0578d48e734454bc9e9b8a569c36184aa60f4278e762799c44d674.

Independent exact-hash review is the next gate; no release claim yet.

[nicoechaniz]

Independent review of exact 64e41b82b6ed8a4216f1a8afe2e7913c627a55e1 returned REQUEST_CHANGES; no merge/release claim.

Reproduced blockers:

• runtime accepted a regenerated observe descriptor with the same key/slot but all 84 service methods because it checked only methods <= SERVICE_METHODS, not the exact role profile;
• capability validation/load reject at observed_at_ms == not_after_ms, but request authentication still accepted that boundary;
• termination immediately after the final holder-directory rename left a complete package whose retry failed as genesis_holder_exists instead of converging idempotently;
• DM078 operational docs still named public recover / authorize-recovery commands that were intentionally renamed/isolated as synthetic and no longer exist.

The focused suite remained green, demonstrating missing negative coverage rather than a simple existing test failure. A consolidated successor is in progress with exact profile binding, a closed expiry boundary, post-rename recovery, and a documentation/CLI consistency test; it will receive a fresh full qualification and independent exact-hash review.

[nicoechaniz]

Exact successor a9c65278a93e19b7db3228c0ff13a403bac5c670 (tree 207b066695c86dce31ae24feb65471fd0ad60bf5) remains REQUEST_CHANGES after independent re-review.

The four prior findings are closed, but two new gaps were reproduced:

• the published V7 JSON Schema accepted a real bundle with 9/10 profiles and another with a duplicate profile, while the runtime later rejected them;
• runtime validated each row internally but did not bind all ten profiles to one runtime identity. A valid observe descriptor/slot/key/client config from runtime beta could replace only alpha's observe row and load_runtime accepted the mixed set.

Focused evidence (54 tests / 801 subtests) remained green, so new negative schema and cross-runtime cases are required. The next successor will close exact schema cardinality/uniqueness and introduce one bundle-level runtime binding across bootstrap and rebirth before another full qualification/review.