BLUEPRINT

第 7 章 Open Questions（未解決の課題）

本章は、現行のプロトコル層で確定せず、実装側 spec、後続のプロトコルバージョン、または独立した ADR にて解決されることを意図したオープンな課題を列挙する。各課題は design.md 第 10 節の同名項目に対応し、後続タスク 8 にて open-questions.md の整理時にさらに具体化することができる。

これらの課題は FayID プロトコルの欠陥ではなく、意図的に保留された拡張点である。共通する特徴は、プロトコル層で早期に決定すると実装の自由度を制限する、あるいはエコシステムの進化に伴って調整が必要となることにある。

1. 具体的なハッシュ／署名／KDF アルゴリズム

課題：プロトコル層は候補（Ed25519／HKDF-SHA256／BIP-39）のみを示し、最終選定は実装 spec に委ねる。

影響範囲：実装間の相互運用性、暗号学的監査

解決方針：実装 spec でアルゴリズムを固定し、バージョン化（例：fayid/dyn/v1、fayid/gmc/v1 の v1 サフィックス）と組み合わせる。将来的なアルゴリズムアップグレードは新バージョン番号により共存を実現する。

2. Dynamic Code の有効ウィンドウ長

課題：プロトコル層は Dynamic Code に expiresAt が存在することのみを要求する。具体的な長さ（分単位／時間単位）は実装の戦略に委ねる。

影響範囲：ユーザー体験、プライバシー強度、ローテーション頻度

解決方針：実装側がシナリオに応じてカスタマイズする。高セキュリティシナリオでは短いウィンドウ（例：5 分）を用い、通常シナリオでは時間単位まで緩和できる。

3. Verification Code 検証失敗のレート制限閾値

課題：VERIFICATION_RATE_LIMITED のウィンドウ幅、失敗回数閾値、バックオフ戦略はいずれも実装側の決定事項である。

影響範囲：ブルートフォース耐性、ユーザー体験

解決方針：業界標準（指数バックオフ等）を参照し、実装 spec でデフォルト値を定める。

4. Authorization Grant のデフォルト TTL と更新モデル

課題：プロトコル層は expiresAt の明示的存在のみを要求する。更新／スライディング有効期限／短 TTL + リフレッシュトークンといった具体モデルは実装 spec に委ねる。

影響範囲：ユーザー体験、セキュリティ、従来型認証ソースとの相互運用性

解決方針：実装 spec で RefreshGrant 種別を導入する可能性がある。あるいは legacySourceKind ごとに差異化された TTL を適用することもできる。

5. Human ID の失効セマンティクス

課題：現行プロトコル層において Human ID は REVOKED 状態に入らない。Mnemonic 漏洩後の「救済」経路（Human ID 再発行、信用移管等）は本仕様の範囲外である。

影響範囲：災害復旧、信用の継続性

解決方針：以下のように進化する可能性がある：

  • 上位層で「信用移管」メカニズムを導入する（旧 opaqueRef → 新 opaqueRef のチェーン上宣言）
  • またはプロトコル v2 で制限付きの Human ID 失効と承継メカニズムを導入する

6. resourceRef 名前空間の規範

課題：本仕様は <scheme>://<authority>/<path> 形式の提案のみを示す。正式構文は独立 spec に進化する、あるいは既存の URI 標準と接続する可能性がある。

影響範囲：実装間の相互運用性

解決方針：独立した「FayID Resource Identifier」仕様を形成する、あるいは直接 RFC 3986 URI 標準を採用する可能性がある。

7. 複数の FayID System インスタンス間の相互運用性

課題：複数の FayID System デプロイメント（異なる運営主体）が存在する場合、Human ID／iFay ID／Organization ID のグローバル一意性はグローバル名前空間または接頭辞分割メカニズムを必要とする。

影響範囲：複数運営主体エコシステム、クロスチェーン相互運用性

解決方針：FayID v2 の中核課題として進化する可能性がある。候補方針には以下を含む：

  • 名前空間プレフィックス（例：hid_us_xxx vs hid_eu_xxx）
  • DNSSec 風のルート命名権威
  • チェーン上のレジストリ

8. GMC opaqueRef の鍵ローリング

課題：gmc_namespace_secret のローテーションは長期信用関連付けを破壊する——同一の Human ID は新旧鍵下で異なる opaqueRef を派生する。

影響範囲：信用の継続性、鍵セキュリティ

解決方針：

  • 旧新 namespace_secret の共存ウィンドウを設計する
  • またはチェーン上の「opaqueRef 移管宣言」を通じて旧新参照の等価関係を確立する
  • 本課題は独立 ADR を必要とする

9. Property P9 の執行メカニズム

課題：プロトコル層は「Human ID は出方向に流出せずログにも記録されない」という挙動を規定する。実装側の強制メカニズム（型システムタグ、シリアライズ redact、CI 静的スキャン）は実装 spec が選択する。

影響範囲：実装品質、セキュリティ監査

解決方針：

  • 型システム層：newtype／branded type を用いて Human ID を他のエンティティと区別する
  • シリアライズ層：デフォルト redact、明示的なオプトインホワイトリスト
  • CI 層：出方向ペイロードとログ経路を静的スキャンする

10. 従来型認証ソースの信頼度等級

課題：すべての従来型クレデンシャルが等価に Authorization Grant に交換可能か。SMART_CONTRACT と PASSWORD に異なる TTL 上限を適用すべきか。

影響範囲：セキュリティポリシー、リスク管理

解決方針：

  • legacySourceKind から TTL 上限へのマッピングを導入する
  • 低信頼ソース（単純な PASSWORD 等）には短い TTL を適用する
  • 高信頼ソース（SMART_CONTRACT 等）には制限を緩和する

整理と追跡

上述の 10 件の課題は後続タスク 8 にて .kiro/specs/fayid-identity-system/open-questions.md に整理される。各項目には以下の項目を付記する。

  • owner：課題の主担当者
  • 影響範囲：影響を受けるサブシステム
  • 解決マイルストーン：v1／v2／実装 spec／ADR

本章はブループリントの「未解決課題」インデックスとして、課題概要のみを再述する。詳細な整理と追跡については、後続生成される open-questions.md を参照されたい。