[stuck] ① did:webvh: 凍結トポロジ「server が didwebvh-rs で log 構築 / SPA が pluggable signer で署名」が did-webvh 0.1.0 では成立しない。署名鍵の置き場所(=なりすまし可能性)に関わる安全性の分岐なので、実装前に判断を仰ぎます。 @rail44.bsky.social

参照: 実装設計 n_01KSZQB038AF2C7B35PJ19TKM9 / direction n_01KSZE9ARMR9H8Y7Y9T5APMRW4。worktree=owner-did-webvh、コードはまだ1行も書いていません(調査のみ)。

## 何が判明したか(did-webvh 0.1.0 を実際にDLして実装を読んだ)

- 唯一の crate は `did-webvh` 0.1.0(Indicio-tech、2024-12 の単一リリース)。署名は **in-process で秘密鍵を直接渡す** API のみ:
  - `DIDWebVHState::create_log_entry(prev, document, parameters, signing_key: &Secret)` — `&Secret` は秘密鍵実体。
  - 内部は `LogEntry::create_log_entry(...)`(未署名 entry 構築・鍵不要)→ `LogEntry::sign(&Secret)` → `DataIntegrityProof::sign_data(data, &Secret)`(JCS正規化+SHA256+Ed25519署名+multibase を一括)。
  - **pluggable / deferred / remote signer trait は存在しない。** 「署名入力(hash)だけ取り出して外部署名を後付け」する分割APIも無い(`sign_data` は `&Secret` を取り全部内部でやる、`from_signature` 的constructorも無い)。
- 検証は `load_log_entries(&str)` + `validate_log_entries()` で **公開情報(log 文字列)だけで完結** する(秘密鍵不要)。

→ つまり「pluggable signer = client」という凍結前提が **このライブラリには無い**。誰かが didwebvh-rs を呼ぶ=その process に Ed25519 **秘密鍵**が存在する必要がある。SPA は TS なので didwebvh-rs を呼べない。

## なぜ破綻か(3つの凍結制約が同時に満たせない)

「didwebvh-rs を使う(自前で log ロジックを書かない)」「鍵は client 側・server は seed を見ない」「server が log を構築 / SPA が署名」— これらは両立しない。何かを諦める必要があり、**諦め方=秘密鍵の置き場所**が安全性を左右する。

## 取りうる解 (R1–R3)

- **R1(推奨): quacker-channel が mint、server は検証+記録+serve**
  - seed を持つ唯一の Rust client = quacker-channel(pairing で seed 受領済、`keys.rs::derive_identity_signing_key` も #265 でここに landed)。ここで `create_log_entry` を in-process 実行 → 完成した自己検証可能な did.jsonl 行を server に提出 → **server は `validate_log_entries` で検証 → event log に記録 → did.jsonl を axum で serve**。秘密鍵は server に渡らない。
  - 自己主権 ✓ / 自前crypto無し ✓ / #265 再利用 ✓。
  - brief からの乖離: mint が SPA→quacker-channel に移り、didwebvh-rs 統合が server ではなく CLI crate に入る。owner の DID 確立に quacker-channel の pairing が要る。
- **R2: SPA が署名・server が構築(brief の字面通り)**
  - affinidi は「署名入力 hash を出す/外部署名を付ける」分割を公開していないので、**eddsa-jcs-2022 の署名入力(proofConfig+document の JCS→SHA256連結)と proofValue 組み立てを自前実装**する羽目になる = 「自前で log ロジックを書かない」に反する。security層の self-roll crypto。脆い。
- **R3: server が Ed25519 秘密鍵を保持して mint(didwebvh-rs を server に置く字面通り)**
  - 一番素直だが **server(=operator)が owner の identity を偽造/鍵ローテできる** → did:plc を脱いで自己主権へ、という今回の目的そのものを潰す。seed か派生鍵を server に渡す必要もある。memory `project_quacker_identity_account_direction`(自己主権)と矛盾。**非推奨。**

## 併せて報告すべき副次findings(依存プロファイル)

- did-webvh 0.1.0 は `affinidi-data-integrity` を **git 依存**(crates.io 未公開)で引く。さらに推移的に **`ssi 0.12`** を引き込む(direction で「ssi 全部は過剰で不採用」と書いた当のdep)。単一 0.1.0 リリース。identity/security 層の依存として、採用判断を意識的にしたい点。

## 判断してほしいこと

1. R1 / R2 / R3 のどれで進めるか(私の推奨は R1)。
2. R1 採用なら「owner の DID 確立は quacker-channel(local)経由」を許容するか。
3. did-webvh 0.1.0 の依存プロファイル(git dep + ssi 0.12 + 単一リリース)を許容して採用するか、別ライブラリ/自前最小実装を再検討するか。

注: 上記調査でネットワークアクセスを行いました(crates.io から did-webvh / affinidi-data-integrity を DL してソースを精読、Bash sandbox を一時 disable)。

replies