Faying Protocol/1.0 — §5 Protocol Messages

プロトコル本文ナビ：章目次 ｜ 前章 §4 データモデル ｜ 次章 §6 暗号

§5 Protocol Messages

本章はプロトコルのすべてのメッセージを列挙する。エンコーディング規則、エンベロープ構造、7 種類の業務メッセージと 1 種類のエラー応答、そしてエラーコードと監査・HP ビュープッシュの対応関係である。

型の権威性に関する注記：本章の TypeScript ブロックで参照する Mandate / Scope / Grade / PresenceSignal / PresenceRequirement / Endorsement / SignatureBundle / Attestation / WebAuthnAssertion / AtomicAction / RevokeReason などの型について、その権威定義は §4 Data Models（CDDL）にある。TypeScript ビューは Non-normative な人間向けビューであり、両者に差異が生じた場合は §4 CDDL を正とする。

§5.1 エンコーディング規則

• 主フォーマット（CBOR）：ワイヤ上を伝送するすべての既定エンコーディングは CBOR（RFC 8949）である。HTTP Content-Type は必ず application/faying-protocol+cbor と宣言しなければならない。
• 相互運用フォールバック（JSON）：JSON（RFC 8259）はデバッグ / ブラウザ / 人間向けレビューの場面でのみ用い、HTTP Content-Type は必ず明示的に application/faying-protocol+json と宣言しなければならない。セキュリティ上の等価性は、同一のフィールド意味論と署名フォーマットによって保証される。
• Deterministic Encoding：すべての署名対象は、署名前に必ず RFC 8949 §4.2.1 Deterministic Encoding 規則に従って CBOR シリアライズし、JSON シリアライズの曖昧さを避けなければならない。JSON 形態でも署名入力は依然として Deterministic CBOR シリアライズしたバイト列のハッシュである（詳細は §6.3）。
• トランスポートバインディング：既定は HTTP/1.1 と HTTP/2 で、Mandate Service エンドポイントは POST /faying-protocol/v1/{verb} に従う。gRPC（faying-protocol.v1 service）や WebSocket / SSE（faying-protocol.v1 streaming）へのバインディングも可能である。すべてのトランスポート層バインディングは、メッセージ層の署名と nonce を保持しなければならず、トランスポート層 TLS チャネルの身元でメッセージレベルの署名を代替することを禁止する。

§5.2 エンベロープ構造

すべてのメッセージは統一エンベロープ FayingProtocolEnvelope を用いる。

interface FayingProtocolEnvelope<TPayload> {
  header: {
    version:    "Faying Protocol/1.0";
    msg_type:   FayingProtocolMsgType;
    msg_id:     string;        // ULID
    issued_at:  IsoTime;
    expiry:     IsoTime;
    nonce:      Nonce;
    grade:      Grade;         // 現在のセッショングレード（RP が低グレードリクエストを拒否するため）
    issuer:     HumanPrimeID | string;
    subject:    FayID;
  };
  claims:      TPayload;
  attestation: Attestation;
  signature:   SignatureBundle;
}

type FayingProtocolMsgType =
  | "BOOTSTRAP"        | "BOOTSTRAP_RESP"
  | "PRESENCE"         | "PRESENCE_ACK"
  | "GRADE_SWITCH"     | "GRADE_SWITCH_RESP"
  | "DELEGATE"         | "DELEGATE_RESP"
  | "REVOKE"           | "REVOKE_RECEIPT"
  | "FAYING_REQUEST"   | "FAYING_REQUEST_RESP"
  | "DISCLOSURE"
  | "ERROR";

エンベロープ層の不変条件：

• いずれかのフィールドの欠落または型エラーはすべて E_PROTOCOL で拒否する（詳細は §5.4）。
• nonce は 2 × max_message_lifetime のウィンドウ内で同一 subject に対し最大 1 回しか受理されない。重複すれば即 E_REPLAY。
• expiry は必ず有限かつ > issued_at。期限切れのエンベロープは業務検証経路に入らず、直ちに E_PROTOCOL で拒否する。
• signature の入力は必ず H( Deterministic-CBOR( Envelope_without_signature ) ) でなければならない（詳細は §6.3）。

§5.3 メッセージ一覧

本プロトコルは計 7 種類の業務メッセージを定義する：BOOTSTRAP / PRESENCE / GRADE_SWITCH / DELEGATE / REVOKE / FAYING_REQUEST / DISCLOSURE。これに 1 種類のエラー応答 ERROR を加える（詳細は §5.4）。

§5.3.1 BOOTSTRAP（Faying Action）

用途：Human Prime は BOOTSTRAP を通じて MS のもとに 1 件の Mandate を確立し、iFay へ監護認可を発行する。BOOTSTRAP は Faying Protocol の唯一の正当な Faying Action 入口である。

interface BootstrapClaims {
  human_prime:   HumanPrimeID;
  fay:           FayID;
  scope:         Scope;
  grade:         Grade;
  presence_req:  PresenceRequirement;
  not_after:     IsoTime;          // 必ず有限
  human_witness: WebAuthnAssertion; // user-verification = true
  endorsement?:  Endorsement;       // オプション。存在すれば Endorsed Mandate を発行（§4 / §11 参照）
  faying_request_ref?: string;      // IF-initiated 経路では、対応する FAYING_REQUEST.msg_id を参照
}

成功応答：Mandate の完全なオブジェクト（signature_bundle を含む）を返す。

プロトコル層のハード制約：

• not_after は必ず有限かつ > not_before。∞ と負値を禁止。違反はすべて E_PROTOCOL で拒否する（§3.1 I-MS-1 / Property 7 と整合）。
• human_witness フィールドの欠落または署名検証失敗はすべて E_HUMAN_WITNESS_REQUIRED で拒否する。IF / MS / Supervisory Agent が HP に代わって認可確認を完了する正当な経路は存在しない。
• BOOTSTRAP が、以前に iFay が発起した FAYING_REQUEST に応答する場合、faying_request_ref は当該リクエストの msg_id を指さなければならない。MS は Attestation Chain 上で「iFay が発起 → HP が見証 → 発効」の 3 ステップを不可分の証拠チェーンとして連ねなければならない（詳細は §5.3.6 と §3.3）。
• endorsement フィールドが存在する場合、MS は発行前に endorsed_scope ⊆ scope ∧ endorsed_grade.autonomy ≤ grade.autonomy ∧ 0 < endorsed_lifetime_ms ≤ (not_after − not_before) を検証しなければならない。いずれかを満たさなければ E_ENDORSEMENT_INVALID（エラーコード 1013）で拒否する。

§5.3.2 PRESENCE（継続的キャリブレーション）

用途：iFay_Instance は周期的に、Presence Device が生成した在場信号を MS へプッシュし、対応する Mandate の PresenceState.last_freshness を更新する。

interface PresenceClaims {
  mandate_id:    MandateID;
  signal:        PresenceSignal;
  device_health: {
    secure_element: boolean;
    tampered:       boolean;
    last_boot_at:   IsoTime;
  };
}

プロトコル層のハード制約：

• signal は §3.2 I-PC-1 の強制三つ組（nonce / produced_at / device_attestation）を携え、Presence Device が署名しなければならない。一つでも欠ければ E_PROTOCOL。新鮮度ウィンドウは対応する Mandate の presence_req.max_staleness_ms が与え、信号自身が持つのではない。
• 信号が presence_req.max_staleness_ms を超えれば E_PRESENCE_STALE とし、§3.2 I-PC-3 に従って収束をトリガーする（より厳しい grade または Suspended へ遷移）。
• 同一 (subject, nonce) が 2 × max_message_lifetime のウィンドウ内で重複出現すればすべて E_REPLAY。

§5.3.3 GRADE_SWITCH（グレード切り替え）

用途：Mandate のライフサイクル内でその認可グレードを調整する（昇格 / 降格）。

interface GradeSwitchClaims {
  mandate_id:    MandateID;
  target_grade:  Grade;
  reason:        "human-initiated" | "presence-loss" | "policy-trigger";
  human_witness?: WebAuthnAssertion;  // 昇格方向は必須、降格方向はオプション
}

プロトコル層の不変条件（昇格は強い見証）：target_grade.autonomy > current.autonomy（すなわち自律性の方向で現在のグレードより厳密に強い）のとき、human_witness は MUST である。欠落または署名検証失敗はすべて E_HUMAN_WITNESS_REQUIRED で拒否する。降格方向（target_grade.autonomy ≤ current.autonomy）はプロトコルが自動トリガーすること（presence-loss / policy-trigger など）を許し、human_witness を強制しない。

§5.3.4 DELEGATE（デバイス横断 / サブエージェント派生）

用途：親 Mandate から子 Mandate を派生し、デバイス横断またはサブエージェントの場面に用いる。

interface DelegateClaims {
  parent_mandate: MandateID;
  child_subject:  FayID;            // 派生体の FayID
  child_scope:    Scope;            // 必ず ⊆ parent.scope
  child_grade:    Grade;            // child_grade.autonomy は必ず ≤ parent.grade.autonomy（自律性がより低いか等しい、すなわちより厳格か等しい）
  device_id?:     string;           // デバイス横断派生時に具体的な端末をバインド
}

プロトコル層のハード制約：

• child_scope ⊆ parent.scope ∧ child_grade.autonomy ≤ parent.grade.autonomy。いずれの方向の拡張も E_PROTOCOL で拒否する（§3.1 I-MS-4 / Property 6 と整合）。
• 子 Mandate の signature_bundle.chain は親 Mandate の副署を携え、Attestation Chain 上の派生ノードを構成しなければならない。
• 親 Mandate が endorsement を携える場合、子 Mandate の endorsement（存在すれば）は親 endorsement に収束しなければならない。収束しなければ E_ENDORSEMENT_INVALID で拒否する。

§5.3.5 REVOKE

用途：1 件の Mandate を撤回する。そのすべての派生子 Mandate をオプションで連鎖撤回できる。

interface RevokeClaims {
  mandate_id:   MandateID;
  cascade:      boolean;            // すべての派生子 Mandate を連鎖撤回するか（既定 true）
  reason:       RevokeReason;
  effective_at: IsoTime;            // 既定 = now。予定撤回を許す
}

type RevokeReason =
  | "human-initiated"
  | "expiry"
  | "task-completed"
  | "human-prime-unreachable"
  | "ego-deviation"
  | "fay-credential-invalid"
  | "human-prime-credential-invalid"
  | "regulatory-order"
  | "terminal-disconnected";

RevokeReason は §13 章の 9 項目のトリガー条件と一対一に対応する。

プロトコル層のハード制約：

• 撤回の到達性は必ず ≥ Bootstrap の到達性（Property 4 / R4.1 と整合）。iFay 自身が REVOKE を正当に発起する経路は存在しない。
• cascade = true のとき、すべての派生子 Mandate は RevocationVisibilityBudget 以内に revoked として可視でなければならない（Property 14 と整合）。
• 撤回は不可逆：Revoked は吸収状態であり、認可を回復するには改めて BOOTSTRAP を通さねばならず、新しい mandate_id は旧 mandate_id と等しくない（Property 10 と整合）。

§5.3.6 FAYING_REQUEST / FAYING_REQUEST_RESP（IF-initiated 双方向 Faying）

用途：iFay が能動的に Human Prime へ Faying を求める（監護関係の確立または調整を要求する）。このメッセージは直接 Mandate を生まない。MS は転送者にすぎず、リクエストを HP ビューチャネルへプッシュし、続いて HP が BOOTSTRAP を通じて認可・発効させる（§2.4 Phase A0 参照）。

interface FayingRequestClaims {
  initiator:        FayID;          // iFay 自身
  target_human:     HumanPrimeID;   // 対象 HP
  proposed_scope:   Scope;          // 提案する監護範囲
  proposed_grade:   Grade;          // 提案するグレード
  reason:           string;         // 自由テキストの補足
  reason_code:
    | "establish"
    | "adjust-scope"
    | "adjust-grade"
    | "renew"
    | "endorsement-request";
  expected_lifetime_ms?: number;    // 期待する Mandate 寿命
  proposed_endorsement?: Endorsement; // Endorsed Mandate を同時に求める場合
}

interface FayingRequestRespClaims {
  request_msg_id: string;           // 上流の FAYING_REQUEST.msg_id を参照
  status:         "accepted" | "rejected" | "timeout";
  bootstrap_ref?: string;           // status=accepted のとき、HP が完了した BOOTSTRAP.msg_id を指す
  reject_reason?: string;
}

プロトコル層のハード制約：

• iFay が能動的に発起した FAYING_REQUEST は、いかなる Faying 状態の変化も直接生まない。HP が BootstrapTimeout 以内に BOOTSTRAP（faying_request_ref と検証可能な human_witness を携える）で応答してはじめてリクエストが発効する。
• HP が BootstrapTimeout 以内に明確な認可確認を与えなければ、MS は FAYING_REQUEST_RESP { status="timeout" } で返し、当該イベントを Attestation Chain へ書き込まなければならない。対応するエラーコードは E_FAYING_REQUEST_NOT_CONFIRMED（1014）。
• MS / IF / Supervisory Agent が HP に代わって認可確認を完了する正当な経路は一切存在しない。human_witness を欠けばすべて E_HUMAN_WITNESS_REQUIRED（1010）。
• 各ペア (HP, IF) の FAYING_REQUEST の頻度は ConfirmationRateLimit（詳細は付録 B）の制約を受け、超過すれば §9.10.7 T6 に従って処理する。

§5.3.7 DISCLOSURE（構造化された披露メッセージ）

用途：iFay が報告または確認要求の際に用いる構造化された披露メッセージ。規制側と MS はこのメッセージに対し schema-level の監査を行うことができ、純粋な自由テキストで重要情報を覆い隠すことを禁止する（詳細は §9.10.4 T3）。

interface DisclosureClaims {
  mandate_id:         MandateID;
  /** mandatory_fields（いずれかが欠落すればプロトコルエラーとみなす） */
  action:             AtomicAction;          // 1 回の披露はちょうど 1 つの Atomic_Action に対応
  scope_used:         Scope;                 // 実際に使用した scope のサブセット
  risk_level:         "low" | "normal" | "high" | "critical";
  reversibility:      "reversible" | "partially-reversible" | "irreversible";
  affected_resources: string[];
  uncertainty_flags:  string[];              // 例：["ambiguous-target", "stale-context"]
  /** オプションの補足 */
  free_text?:         string;
  intent?:            "report" | "request-confirmation";
  endorsement_id?:    string;                // Disconnected 期間中に発生した場合、対応する endorsement を指す
}

mandatory_fields 強制リスト（R13.3 / §9.10.4 と整合）：

action / scope_used / risk_level / reversibility / affected_resources / uncertainty_flags。

プロトコル層のハード制約：

• いずれかの mandatory_fields の欠落または解析不能 → MS は E_PROTOCOL（1099）で拒否し、HP ビューチャネルへプッシュしなければならない。
• 高機微アクション（risk_level ∈ {high, critical}）は、D 次元での実行前にまず DISCLOSURE を発し、HP の明示的確認を待たねばならない（現在の grade がすでに G4 Autonomous でかつアクションが主 scope 内に収まる場合を除く、詳細は §7）。
• 後続の監査で DISCLOSURE 中の mandatory_fields が実際のアクションと不一致と判明した場合、MS は RevokeReason="ego-deviation" で当該 Mandate を撤回しなければならない。
• Disconnected 期間中に実行したアクションの DISCLOSURE は endorsement_id を携え、当該アクションを具体的な 1 件の endorsement まで独立して追跡できるようにしなければならない。

§5.4 エラーコード

エラー応答は統一して ERROR メッセージ（エンベロープ msg_type = "ERROR"）を用い、claims 本体は { code, message, mandate_id?, recovery_hint? } のような形である。下表はすべてのエラーコードとその監査・HP ビュープッシュ制約を示す（§EH.3 と整合）。

Code	名称	意味	応答	監査必須	HP ビュー必須
1001	E_NO_MANDATE	リクエストが Mandate を携えていない	拒否	✗	✗
1002	E_MANDATE_EXPIRED	Mandate が期限切れ	拒否 + Revoke トリガー	✓	✗
1003	E_SCOPE_VIOLATION	呼び出しが scope を超過	拒否 + 疑わしいとして記録	✓	✗
1004	E_GRADE_INSUFFICIENT	現在のグレードでは当該機微アクションを実行できない	拒否 + 昇格を提案	✓	✗
1005	E_PRESENCE_STALE	在場信号が期限切れ	拒否 + 降格トリガー	✓	✗
1006	E_REVOKED	Mandate が撤回済み	拒否	✓	✓
1007	E_ATTESTATION_INVALID	Attestation 検証失敗	拒否 + Revoke トリガー	✓	✓
1008	E_RR_UNAVAILABLE	撤回登録センターが到達不能	Default-Deny で拒否	✓	✗
1009	E_REPLAY	nonce の重複	拒否 + セキュリティ警告	✓	✓
1010	E_HUMAN_WITNESS_REQUIRED	グレード昇格 / 双方向 Faying で人類見証を欠く	拒否	✓	✗
1011	E_ROGUE_DETECTED	Rogue 行為を検知	拒否 + 強制 Revoke	✓	✓
1012	E_BUDGET_EXCEEDED	ResourceBudget を超過	拒否 + 降格トリガー	✓	✗
1013	E_ENDORSEMENT_INVALID	Endorsement フィールドが不正（endorsed_scope ⊄ scope / endorsed_grade.autonomy > grade.autonomy / endorsed_lifetime の欠落または超過 / 改竄 を含む）	拒否 + 当該 Mandate の Revoke トリガー	✓	✓
1014	E_FAYING_REQUEST_NOT_CONFIRMED	iFay が能動的に発起した FAYING_REQUEST が BootstrapTimeout 以内に HP の明確な認可を得られなかった	拒否 + Attestation Chain へ書き込み	✓	✗
1099	E_PROTOCOL	プロトコル層エラー（バージョン / フォーマット / 署名 / DISCLOSURE mandatory_fields の欠落または解析不能）	拒否	✓	✗*

* 注：E_PROTOCOL は既定では監査にのみ書き込む。ただし §5.3.7 DISCLOSURE の mandatory_fields 欠落または解析不能の経路からトリガーされた場合、MS は追加で HP ビューチャネルへプッシュしなければならない（詳細は §5.3.7 と §9.10.4 T3）。

監査 / HP ビューの意味論の説明：

• 監査必須：エラーは (error_code, mandate_id, ts, RP_id, reason) の 5 つ組で Attestation Chain / audit-log へ書き込まなければならない。E_NO_MANDATE（Mandate コンテキストなし）を除き、すべてのエラーコードが ✓ である。
• HP ビュー必須：エラーは HP ビューチャネルへ push しなければならず、RP がサイレントに飲み込むことを禁止する。基本 4 種（E_REVOKED / E_ATTESTATION_INVALID / E_REPLAY / E_ROGUE_DETECTED）は §EH.3 が強制する。E_ENDORSEMENT_INVALID はそのトリガー経路が必然的に E_REVOKED を伴うため、同じく HP ビューチャネルへプッシュする。
• エラー応答中に MS の内部状態、Mandate 秘密鍵のフィンガープリント、他の Human Prime の識別子などの機微情報を携えることを禁止する（詳細は §EH.3）。