Faying Protocol/1.0 — §10 Error Handling
プロトコル本文ナビ：章目次 ｜ 前章 §9 セキュリティ考慮事項 ｜ 次章 §11 未解決の課題
§10 Error Handling
本章は §5.4 のエラーコードと、具体的な失敗シナリオ、プロトコル応答、状態遷移、回復経路、可観測性の制約をまとめて述べる。すべてのエラーは §5.2 エンベロープ下の ERROR メッセージで応答し、claims 本体は { code, message, mandate_id?, recovery_hint? } のような形である。§5.4 のエラーコード表に加え、エラー処理は本章の 4 節を正とする。
EH.1 エラーシナリオとプロトコル応答
下表は §5.4 に列挙したすべてのエラーコード（1001–1014 と 1099）の全景ビューを示す。各行には、トリガーシナリオ、プロトコル応答、Revoke をトリガーするか、降格をトリガーするか、監査チェーンへの記入が必須か、HP ビューチャネルへの記入が必須かを含む。本表は §5.4 エラーコード表と一対一に対応する。
| Code | 名称 | トリガーシナリオ | プロトコル応答 | Revoke トリガー | 降格トリガー | 監査記入 | HP ビュー記入 |
|---|---|---|---|---|---|---|---|
| 1001 | E_NO_MANDATE | 業務リクエストが Faying Protocol ヘッダ / Mandate を携えていない | RP が即時拒否。audit を確立しない | ✗ | ✗ | ✗ | ✗ |
| 1002 | E_MANDATE_EXPIRED | now > Mandate.not_after | RP 拒否 + MS が当該 Mandate の Revoke をトリガー | ✓ | ✗ | ✓ | ✗ |
| 1003 | E_SCOPE_VIOLATION | 呼び出しアクション ∉ Mandate.scope.actions | RP 拒否 + 疑わしいイベントを記録。累積回数が降格をトリガー | ✗ | ✓（累積） | ✓ | ✗ |
| 1004 | E_GRADE_INSUFFICIENT | RP が現在の Mandate.grade より強い grade を要求 | RP 拒否 + 昇格を提案（昇格経路は HP human_witness が必要） | ✗ | ✗ | ✓ | ✗ |
| 1005 | E_PRESENCE_STALE | presence.last_freshness が max_staleness_ms または LivenessDetectionBudget を超過 | RP 拒否。IF は能動的に D 次元を停止し、PRESENCE キャリブレーションを待つ。状態機械 Active → Degraded | ✗ | ✓ | ✓ | ✗ |
| 1006 | E_REVOKED | RR が revoked と標記 | RP 拒否。同一チェーンの呼び出しを連鎖拒否。IF は直ちに Rogue Fay へ戻る | ✓（撤回済み） | ✗ | ✓ | ✓ |
| 1007 | E_ATTESTATION_INVALID | Attestation Chain ノードの署名検証失敗 / タイムスタンプが親ノードの validity window 内にない / endorsement サブフィールドの改竄 | RP 拒否 + MS が当該 Mandate の Revoke をトリガー | ✓ | ✗ | ✓ | ✓ |
| 1008 | E_RR_UNAVAILABLE | RR 照会タイムアウト ≥ StaleBudget | RP が Default-Deny で拒否。IF はすべての D 次元を一時停止。状態機械 Active → Degraded | ✗ | ✓ | ✓ | ✗ |
| 1009 | E_REPLAY | nonce が 2 × max_message_lifetime 内で同一 subject にすでに観測された | RP 拒否 + セキュリティ警告。IF は直ちにセッション鍵を rotate | ✗ | ✗ | ✓ | ✓ |
| 1010 | E_HUMAN_WITNESS_REQUIRED | grade-up / FAYING_REQUEST など HP 見証が必要な場面で欠落または human_witness 検証失敗 | RP / MS 拒否。HP 見証後に再発起を待つ | ✗ | ✗ | ✓ | ✗ |
| 1011 | E_ROGUE_DETECTED | D 次元の違反を検知（ego-deviation / 行為ベースライン超過など） | RP 拒否 + 強制 Revoke。IF は直ちに Rogue Fay へ戻る | ✓ | ✗ | ✓ | ✓ |
| 1012 | E_BUDGET_EXCEEDED | 呼び出し累積が Scope.budget / ResourceBudget を超過 | RP 拒否 + 降格または（極端な場合）Revoke をトリガー | ✓（極端） | ✓ | ✓ | ✗ |
| 1013 | E_ENDORSEMENT_INVALID | endorsed_scope ⊄ scope / endorsed_grade.autonomy > grade.autonomy / endorsed_lifetime の欠落または超過 / endorsement サブフィールドの改竄 / DELEGATE の子 endorsement が親に収束しない | MS が発行拒否 + 当該 Mandate の Revoke をトリガー。IF は直ちにすべての endorsed 行為を停止 | ✓ | ✗ | ✓ | ✓ |
| 1014 | E_FAYING_REQUEST_NOT_CONFIRMED | iFay が能動的に発起した FAYING_REQUEST が BootstrapTimeout 以内に HP の明確な認可を得られない | MS が FAYING_REQUEST_RESP { status="timeout" } で返却。いかなる Faying 状態の変化も生じない。イベントを Attestation Chain へ書き込み | ✗ | ✗ | ✓ | ✗ |
| 1099 | E_PROTOCOL | バージョン / フォーマット / フィールド欠落 / 解析不能 / DISCLOSURE mandatory_fields の欠落または解析不能 / 署名入力が不正 / §5.3 メッセージ一覧に明示的に列挙されていない msg_type | RP / MS 拒否。DISCLOSURE 経路からトリガーされた場合は追加で HP ビューへ push | ✗ | ✗ | ✓ | ✗*（DISCLOSURE 経路は ✓） |
*注：E_PROTOCOLは既定では監査チェーンにのみ書き込む。§5.3.7 DISCLOSURE のmandatory_fields欠落または解析不能の経路からトリガーされた場合、MS は追加で HP ビューチャネルへプッシュしなければならない（§5.4 注記と整合）。
Trace：R2.1.1–R2.1.4（デフォルト拒否）、R3.2.1–R3.2.3（エラーイベントの監査と HP ビューへの記入）、R4.2.1–R4.2.3（撤回可視性の予算と到達性）、R11.1.4（endorsement 改竄が E_ATTESTATION_INVALID + Revoke をトリガー）、R11.2.1–R11.2.3（endorsement 収束違反が E_ENDORSEMENT_INVALID をトリガー）、R1.3.3（FAYING_REQUEST のタイムアウト未認可が E_FAYING_REQUEST_NOT_CONFIRMED をトリガー）、R13.3.1（DISCLOSURE mandatory_fields の欠落または解析不能が E_PROTOCOL をトリガー）。
EH.2 回復経路
「Faying 状態の再確立を要するか否か」によって、エラーコードを 3 種の回復経路に分ける。すべての回復経路は EH.4 Default-Deny 収束の内で実行しなければならず、楽観的に通過させる中間ウィンドウは存在しない。
EH.2.1 回復可能なエラー（BOOTSTRAP の再実行不要）
| Code | 名称 | 回復アクション |
|---|---|---|
| 1004 | E_GRADE_INSUFFICIENT | GRADE_SWITCH-up をトリガー（HP human_witness 必須、詳細は §7.4）。見証を飛ばした回復は許さない |
| 1005 | E_PRESENCE_STALE | PRESENCE メッセージを再送し、last_freshness を回復。なお失敗すれば LivenessDetectionBudget に従って Degraded → Suspended へ収束 |
| 1008 | E_RR_UNAVAILABLE | Default-Deny ウィンドウ内で retry-with-backoff（StaleBudget を超えない）。超過すれば Degraded へ移り、RR 回復後に再接続 |
| 1012 | E_BUDGET_EXCEEDED | GRADE_SWITCH-down をトリガーするか、予算ウィンドウの更新を待つ。「予算を無視する」ことによる回復は許さない |
EH.2.2 HP の再見証を要する回復（必ず BOOTSTRAP を再実行）
| Code | 名称 | 回復アクション |
|---|---|---|
| 1002 | E_MANDATE_EXPIRED | BOOTSTRAP を再実行。新 mandate_id は必ず旧 mandate_id と等しくない（P10 撤回不可逆と整合） |
| 1006 | E_REVOKED | 回復不能。HP が能動的に新たな BOOTSTRAP を発起するしかなく、新 mandate_id は必ず旧 mandate_id と等しくない |
| 1007 | E_ATTESTATION_INVALID | 同上。当該 Mandate の強制 Revoke をトリガーした後にのみ新 BOOTSTRAP を許す |
| 1011 | E_ROGUE_DETECTED | 同上。通常は HP の直接介入と ego-deviation 監査を伴う |
| 1013 | E_ENDORSEMENT_INVALID | 同上。当該 Mandate の Revoke をトリガーした後、必ず HP が新たな BOOTSTRAP を発起（合法な endorsement フィールドを含む） |
EH.2.3 Faying 状態の変化を構成しない（回復の必要なし）
| Code | 名称 | 処理 |
|---|---|---|
| 1001 | E_NO_MANDATE | 呼び出し側はまず Mandate を取得してから呼び出しを発起する必要がある。本プロトコル層に「Mandate なしの一時的な通過」経路は存在しない |
| 1003 | E_SCOPE_VIOLATION | 呼び出し側は action を調整して Mandate.scope.actions 内に収める必要がある。累積した疑わしさが降格をトリガー |
| 1009 | E_REPLAY | 呼び出し側は新しい nonce で再発起すべき。攻撃行為であればすでにセキュリティ警告と HP ビューへ書き込まれている |
| 1010 | E_HUMAN_WITNESS_REQUIRED | HP 見証後に再発起を待つ。IF / MS / SA が見証を代替することは許さない |
| 1014 | E_FAYING_REQUEST_NOT_CONFIRMED | iFay は合法なレート内で FAYING_REQUEST を再発起できるが、これを借りて確認洪水を実施してはならない（詳細は §9.10.7、付録 B ConfirmationRateLimit） |
| 1099 | E_PROTOCOL | 呼び出し側はメッセージ構造を修正してから再発起する必要がある |
共通のハード制約：回復経路は §EH.4 Default-Deny 収束を迂回してはならない。「不確かだがとりあえず通しておく」という楽観的な回復経路は、プロトコル層にいっさい存在しない。
EH.3 エラー応答の可観測性制約
すべての ERROR メッセージは下記 4 条の強制制約を満たさなければならない。
- 監査 5 つ組：
E_NO_MANDATE（Mandate コンテキストなし）を除き、すべてのエラーコードは(error_code, mandate_id, ts, RP_id, reason)の 5 つ組で Attestation Chain / audit-log へ書き込まなければならない。この 5 つ組は §3.2、§EH.1「監査記入」列と一致する。 - HP ビューチャネルへの必達プッシュ：エラーコード集合
{E_REVOKED (1006), E_ATTESTATION_INVALID (1007), E_REPLAY (1009), E_ROGUE_DETECTED (1011), E_ENDORSEMENT_INVALID (1013)}は HP ビューチャネルへ push しなければならない。DISCLOSURE 経路からトリガーされたE_PROTOCOL (1099)も同じく必達である。RP がサイレントに飲み込んではならない。 - 機微情報を漏らさない：エラー応答中に MS の内部状態、Mandate 秘密鍵のフィンガープリント、他の HP の識別子、IF の内部状態機械変数などの機微情報を携えることを禁止する。
messageとrecovery_hintフィールドはプロトコル層の公開意味論でなければならず、実装の詳細を透けさせてはならない。 - 監査チェーンは独立検証可能：Attestation Chain へ書き込むエラーイベントは §3.3 I-AC-1 / I-AC-2 が要求する署名ノードを携え、第三者が MS 秘密鍵を保持せずとも葉から根までのチェーン検証を完了できるようにしなければならない（詳細は §6.3）。
Trace：R3.2.1（エラーコード 5 つ組を audit-log へ書き込み）、R3.2.2（エラー応答に機微情報を携えない）、R3.2.3（指定エラーコードは HP ビューへ必達）、R3.1.4（監査チェーンの追跡可能フィールド）。
EH.4 Default-Deny の統一収束
明確に分類できないいかなるエラー、解析不能ないずれかのフィールド、RR 到達不能の期間中の任意の呼び出しについて、プロトコル層は一律
E_PROTOCOLまたはE_RR_UNAVAILABLEで拒否する。「不確かだがとりあえず通しておく」正当な経路は存在せず、「より緩い状態に従って処理する」楽観的な回復経路も存在しない（真にはオンラインだが連絡途絶と知覚されたウィンドウ B を含む、詳細は §9.9）。
収束規則の 4 つの等価な表現：
- 状態機械層：§4.3 Mandate 状態機械 / §8.1 Lifecycle 状態機械に明示的に列挙されていない遷移は一律拒否する。
- メッセージ層：§5.3 メッセージ一覧に明示的に列挙されていない
msg_type、またはエンベロープフィールドの欠落 / 型エラーは、一律E_PROTOCOLで拒否する。 - エラーコード層：§5.4 / §EH.1 に明示的に列挙されていない失敗原因は一律
E_PROTOCOLへ分類して拒否する。 - 決定層：プロトコル層は Perceived-Disconnected のみを決定の根拠とする。ウィンドウ A（真には連絡途絶だがオンラインと知覚）/ ウィンドウ B（真にはオンラインだが連絡途絶と知覚）の楽観的通過経路は、プロトコル層に存在しない（詳細は §9.9 悲観的推定の原則、P17.1 / P17.2）。
Trace：R2.1.1–R2.1.4（デフォルト拒否）、R12.1.1–R12.1.3（二重意味論 Perceived-only 決定）、R12.2.1–R12.2.3（悲観的推定 / 知覚連絡途絶期間中の拒否）。