セキュリティ保証と適合性テストのカバレッジ

英語版の参考訳です。更新日：02/11/2026。相違がある場合は英語版が優先されます。識別子、コマンド、コードブロックは翻訳せず保持しています。

本書は規範要件とリポジトリの実行可能なテストを対応付けた参考情報です。新しいプロファイル、認証、全入力をテストしたという主張、特定のデプロイ環境が合格した証拠ではありません。テスト結果は、その実行で記録した正確な実装、入力、ポリシー、検証時刻、ツールバージョンに適用されます。

検証チェックリスト、正規化プロファイル、受け入れ判定プロファイルが引き続き判断の基準です。参照実装とテストキットのどちらにも不具合があり得ます。仕様と再現可能なケースに基づいて差異を解決してください。実装間の一致によって正しさが決まるわけではありません。

保証の意味

層	検査によって確認できること	確認できないこと
スキーマ	入力が許可された構造とフィールド値を持つこと	有効な署名、誠実な主張、プリンシパルの身元、認可
暗号学的検証	調べた署名、ハッシュ、関係が、指定された鍵、ポリシー、時刻における適用規則を満たすこと	名指しされたプリンシパルが信頼されること、記録された出来事が実際に起きたこと、ツールの実行許可
プリンシパルへの信頼	検証済みのプリンシパル署名の構成要素が、運用者が帯域外で指定した信頼集合と一致すること	その信頼元の範囲を超えた身元保証、操作の実行権限
strict-v1 の受け入れ判定	検証、プリンシパルへの信頼、署名された宛先・セッション制約、十分に新しい失効状態がプロファイルを満たすこと	一回限りの使用、スナップショット後の失効、操作の認可
アダプターによる制御の適用	統合が、保護対象ハンドラーの実行前に運用者の受け入れ判断を適用すること	コアプロトコルが提供する性質、または外部適合性キットが証明した性質

action_authorized は false のままです。ブロックまたはエスカレーションされた操作について検証や受け入れ判定を通過した記録は、その記録上の判断の証拠であり、実行許可ではありません。セッションの結合は不整合なセッションの継ぎ合わせを防ぎますが、bundle を消費したり、一回限りの使用にしたりはしません。

証拠の読み方

キットの READMEは、コマンド、契約、レポートフィールド、終了コードを定義しています。各テスト対象面は異なります。

• 参照実装： tools/conformance.js は参照ヘルパーと lib/verify.js を呼びます。後者は V2 スキーマを検証し、暗号学的検証を TypeScript に委譲します。
• 外部プリミティブ： 契約 /1 は指定した実装を通じて正規化とダイジェストをテストします。
• 外部証拠： 契約 /2 は Merkle ルート、複合署名、V2 bundle 検証をテストします。リポジトリは TypeScript、Python、Go、Rust、WASM のラッパーを提供します。
• 外部受け入れ判定： 契約 /3 は検証と組み合わせた受け入れ判定と設定の読み込みをテストします。TypeScript、Python、Go、Rust のラッパーを提供しています。WASM には受け入れ判定 API がありません。
• SDK とアダプターのスイート： それぞれ独自の入口と範囲を持つ別のテストです。キットの一覧に項目があっても、キットがそのテストを実行したことにはなりません。

番号付きの契約は実行ツールのインターフェースであり、DCP プロトコルのバージョンではありません。ラッパーの識別情報は自己申告です。5 個のラッパーが 5 者の独立した外部採用者を意味するわけではありません。WASM は Rust とコードを共有し、これらのラッパーはすべて同じリポジトリに属します。

否定結果は、正常に動作する肯定対照があって初めて有用です。署名を更新せずに署名対象を変更すると、複数の原因で失敗し得ます。spec_step ラベルやエラーメッセージの一致だけでは、特定の検査が拒否の原因だったとは証明できません。規則を切り分ける有効・無効の対は、個別に構築した拒否対象 bundle とスイート単位の肯定対照だけの場合よりも強い証拠となります。

V2 検証マップ

以下のケース名は bundle ベクトルを参照します。M、R、A はそれぞれ must_reject、must_reject_bundles、must_accept_bundles です。外部 ID は external.v2.bundle_vectors. に、それぞれ must_reject、must_reject_bundles、must_accept とケース名を続けます。signed_bundle が基準の肯定ケースです。これは追跡可能な代表例であり、網羅的な一覧や完全性の評価ではありません。

規範規則	選択した既存のケースまたはスイート	範囲と残る制限
V2-1：バージョンの選択	M dcp_bundle_version_1_0, dcp_bundle_version_3_0	V2 の入口での拒否。V1 の全要件をテストするものではない
V2-2：エンベロープと成果物のスキーマ検証	参照 v2.signed_bundle.schema_invalid_payload_rejected、スキーマスイート、明示的に選択するスキーマ検証カタログ（57 ケース）	main の SDK 検証器は V2-2 を自ら実行する。公開済みの SDK バージョンは実行しない。後述の境界を参照
V2-3：マニフェスト、ペイロードハッシュ、監査の結合	M intent_payload_hash_wrong, audit_entries_truncated; R manifest_intent_hash_mismatch, audit_chain_hash_wrong; A empty_audit_trail	ハッシュとチェーン結合の例。全フィールドや不正な構造を切り分けて網羅してはいない
V2-4：セッション、時刻、未署名メタデータの整合性	R intent_session_nonce_differs, session_expired_with_offset, session_longer_than_policy_max_with_late_created_at; M signature_signer_id_other; A session_duration_at_millisecond_precision	固定時刻でのテスト。要求されたポリシーと実効モードを区別する必要がある
V2-5：署名構造と正規エンコード	M bundle_classical_sig_b64_with_trailing_bits, intent_classical_sig_b64_unpadded; R classical_only_bundle_signature_without_pq	エンコードの例は全署名位置や欠陥の組み合わせを網羅していない
V2-6：プリンシパルによるマニフェストへの署名	R bundle_signed_by_agent_keys; 参照 v2.signed_bundle.forged_classical_signature_rejected	役割の結合と署名の例。自己申告のプリンシパルへの信頼は確立しない
V2-7：存在する PQ 署名の検証	M bundle_pq_signature_invalid, bundle_pq_slot_holds_ed25519	従来の証拠カタログでは選択されたポリシーで実行する。全実効モードを主張するには対応する対照が必要
V2-8：各成果物をコンテキストと署名者の役割に基づいて検証	M rpr_classical_signature_invalid, intent_signed_by_principal, policy_decision_signed_under_intent_context	成果物と役割の例。構成要素、コンテキスト、鍵の全組み合わせではない
V2-9：宣言による引き下げを許さずティアを導出	R classical_only_intent_action_type_constructor, classical_only_intent_security_tier_constructor	判定の例。外部 bundle 操作は報告された解決済みティアを評価しない
V2-10：実効モードとアルゴリズムポリシーの適用	R classical_only_payment_from_low_risk_passport; 4 モードの classical_only_routine	モードの例。従来の証拠カタログにアルゴリズム許可リストとアドバイザリー専用のマトリクスはない
V2-11：存在する副次フィールドの検証	副次ベクトルの external.v2.secondary_sha3	肯定対照と不正・不一致フィールド。欠落したリンクは任意なので、受理は完全な副次チェーンを意味しない
V2-12：チェックポイントの結合と検証	A pq_checkpoint_over_the_trail; R pq_checkpoint_listed_but_missing, pq_checkpoint_event_range_count_wrong, pq_checkpoint_pq_signature_invalid	所属、範囲、署名の例。不正な範囲や構成要素の全組み合わせではない
V2-13：鍵 ID の導出と鍵の有効性確認	R passport_key_kid_not_derived, passport_key_public_key_with_trailing_bits, rpr_binding_key_revoked	鍵、エンコード、状態の例。鍵ポリシー全体の網羅ではない
V2-14：成果物間の整合性	R passport_principal_binding_reference_other, audit_entry_policy_decision_other; A blocked_action_recorded, escalated_action_recorded	証拠の整合性と操作の許可は異なる

コーパスの期待値は、宣言されたポリシー、ケースごとの上書き設定、検証時刻と併せて解釈する必要があります。有効なハイブリッド bundle は pq_only でも検証に成功し得ます。結合に必要な従来型署名のバイト列を含むことは、否定対照になる理由ではありません。要求された classical_only は、操作のティアによってより厳しい実効モードに解決される場合があります。

スキーマと暗号 API の境界

V2-2 はスキーマ検証を要求します。main では、TypeScript、Python、Go、Rust、WASM の各 SDK の V2 検証器が自らこれを実行します。対象は verifySignedBundleV2 とその対応関数、最初に検証を行う結合されたアドミッション API、実験的な候補の検証器です。以前の検証結果からアドミッションを評価する場合は、これを再実行しません。公開済みの SDK バージョンには含まれていません。このゲートは、署名済み bundle のエンベロープと四つのペイロード（responsible_principal_record、agent_passport、intent、policy_decision）を schemas/v2 に照らして検証します。実行されるのは、検証器のポリシーと時計の確認の後、検証器がマニフェスト、ペイロードのハッシュ、鍵、署名を確認する前です。すべての SDK は schemas/v2 から生成された同じ表現（tools/schema-ir/）を解釈し、CI はそれを再生成してコピーを比較します。

• 閉じたオブジェクトと開いたオブジェクト。 閉じたオブジェクト（additionalProperties: false。たとえばエンベロープ、SignedPayload、composite_sig、監査エントリー、チェックポイント）の未知のメンバーは、ハッシュと署名が有効なままでも拒否されます。intent の target や監査の evidence のような開いたオブジェクトでも、宣言されたメンバーは制約を保ちます（たとえば target.channel は必須で、列挙された値をとります）。この層で検査されないのは、スキーマが記述していない追加のメンバーだけで、コミットメントの下にあるものは正規化に届くことがあります。bundle オブジェクト自体の追加のメンバーは受け入れられます。スキーマが bundle を開いたままにしており、そのメンバーは（bundle が含む署名済みの成果物やマニフェストとは異なり）どのコミットメントの下にもなく、後続のどの検査もそれを読まないためです。
• 欠落と null。 必須メンバーの欠落も、スキーマが別の型を期待する位置の null も拒否され、診断は異なります（required、type）。マニフェストの session_issued_at と session_expires_at は、存在する場合は文字列でなければならず、null は拒否されます。
• 診断。 スキーマの失敗は verified: false と schema: <JSON pointer> <keyword>[ <member>] 形式のエラーを返します。最大 16 件で、その後に schema: further errors not listed が続き、入力の値も暗号に関する詳細も含みません。以前はより深い検査が報告していた拒否が、今はスキーマの診断になる場合があります。スキーマの失敗は、深い検査が実行されたことを示しません。
• 候補のオーバーレイ。 呼び出し側が明示的に選択する実験的な dcp-jcs-v2 の経路での唯一の違いはマニフェストの canonicalization_profile で、dcp-jcs-v2 でなければなりません。既定のプロファイルと署名済みのバイト列は変わりません。
• date-time。 形式の確認は参照検証器が適用しているもの、つまり full モードの ajv-formats 3.0.1 で、その癖も含みます。区切りとして任意の ECMAScript の空白文字または t、+hh と +hhmm のオフセット、オフセットで移した時刻が 23:59 のときの秒 60 を受け入れます。これはスキーマ層の互換性の境界であり、厳密な RFC 3339 ではありません。V2-4、V2-13、V2-14 の時刻パーサーは別の後続の層のままで、スキーマが受け入れた時刻を拒否することがあります。
• パーサーが先。 JSON パーサーが拒否するものは V2-2 に届きません。Go はオブジェクトでないルートを従来のパースエラーとして報告します。Rust の API はパース済みの serde_json::Value を受け取るため、serde_json の拒否（孤立サロゲート、1e400）は呼び出し側のものです。WASM のバインディングは、ポリシーのパースエラー、JSON parse error、バージョンの振り分けを V2-2 の前に保っています。
• 受理の変更。 以前は SDK の検証器が受け入れていたスキーマ上無効な bundle は、今は verified: false を返します。スキーマだけの API は追加されず、スキーマもプロファイルも変わりません。

V2 チェックリスト全体への適合を主張する実装者は、暗号学的検査だけでなく V2-2 も満たす必要があります。テストを通すためにスキーマを弱めたり、部分的な API を完全な検査として説明したりしないでください。キットはこれらの層を分けて報告します。

未知のメンバーが一律に禁止されているわけではありません。一部のスキーマオブジェクトは開いています。署名対象オブジェクトの拡張がスキーマ上許容されても、古い署名が有効なままになるわけではありません。署名対象が変わればハッシュと署名の再計算が必要です。ここでは必須拡張の新しい仕組みを定義していません。

明示的に選択するスキーマ検証カタログは、署名済みの 57 ケースを実装に通します。13 の肯定ケースと 44 の否定ケースで、各否定ケースは同じ実行で基準ケースが検証に成功した場合にだけ数えられます。CI は五つの SDK ラッパーでこれを実行します。明示的に選択するスキーマ診断カタログは 15 の閉包ケースを保持します。基準データと許可された拡張を肯定対照とし、閉じたオブジェクトの拡張や列挙外の値には規範上の拒否を維持します。SDK ケースの失敗は失敗のままで、どちらのカタログに合格しても、対象はそのケースだけです。別の tools/conformance/schema-boundary.js レポートは、スキーマ検証、有限のコーパスの整合性、コーパスの時刻でのスキーマと SDK の組み合わせを区別します。この組み合わせは SDK 単体が V2-2 を実装する証拠ではなく、整合性ヘルパーも汎用の規範検証器ではありません。

検証器ポリシーのサンプル

明示的に選択するポリシーカタログは、既存の /2 契約で 74 ケースを追加します。内訳は肯定対照 10、存在する無効な PQ 署名 24、アルゴリズムリストとアドバイザリ 14、既に版管理されたティアケース 26 です。各リクエストには正確なポリシーと検証時刻が含まれます。既定の証拠カタログは変更しません。

新しい routine ティアのハイブリッド対照は、実効 classical_only と他の 3 モードを検査します。standard ティアのハイブリッド対照では、要求した classical_only が hybrid_preferred に引き上げられます。コーパスはこの導出を記録しますが、/2 が評価するのは判定であり、実装が報告するティアや実効モードではありません。

PQ の否定ケースでは bundle、パスポート、チェックポイントの PQ 署名だけを変更し、古典署名は有効なままです。アルゴリズムリストのケースでは同じ bundle のままポリシーだけを変更します。ティアケースは別々に署名された既存 bundle と、同じ要求モードの routine 対照を再利用するため、単一変更の対ではありません。各否定ケースには、同じ実行で肯定対照が成功することが必要です。

pq_only での古典アルゴリズム除外は、解釈の明確化まで期待判定なしで除外します。未実施のケースと解釈上の質問はコーパスに記録します。未検査の組み合わせがあることだけでは、仕様の矛盾は証明できません。これらのサンプルはスキーマの不足を解消せず、完全な V2 適合性も確立しません。

構造に関するサンプル

明示的に選択する構造カタログは、/2 に16ケースを追加します。陽性対照2件と陰性ケース14件で、署名エンコーディング、チェックポイントの署名成分と範囲、マニフェストのコミットメント、小数を含むペイロード、セッション時刻の順序、および古典署名を無効化した後にPQ署名を正しく再計算したバンドルを扱います。実効モードは hybrid_preferred です。これらの古典署名の陰性ケースは pq_only の結果を主張しません。

エンコーディングの4ケースは、デコード後の署名バイト列を保持します。チェックポイント範囲には監査列内の実際の位置を使い、識別子は意図的にソートしていません。変更したマニフェストには再署名します。時刻の順序を逆転させたセッションには、許容クロックスキュー内の別の陽性対照があります。各陰性ケースは、同じ実行内ですべての対照が合格することを必要とします。

分離には明示的な限界があります。小数は dcp-jcs-v1 で表現できないため、元のハッシュと署名は変更後の内容に対応しません。逆向きの範囲にも、その範囲に対する有効なルートはありません。成分の検査は意図した欠陥を記録しますが、SDKのどの検査が拒否の原因になったかは特定しません。これらのサンプルはスキーマの検証不足を解消せず、完全な適合性も証明しません。

受け入れ判定マップ

共有受け入れ判定ベクトルと外部受け入れ判定カタログは、組み合わせ API と設定ローダーで次のグループをテストします。各ケースの正確な rule、入力、期待フィールドを読んでください。グループ名は網羅性の証明ではありません。

要件	テスト対象面	制限
T1–T2：プリンシパルと構成要素の鍵を運用者の信頼に結び付ける	external.admission.outcomes	信頼は帯域外で供給する。キットは現実世界の身元を確立しない
P1–P4：V2、署名された宛先とセッション期間、プリンシパルのハイブリッド署名	結果と組み合わせケース	構造上の検査と検証済みであることの検査は異なる。不正値の全組み合わせは列挙していない
R1–R5：スナップショットの可用性、形式、鮮度、対象の状態	結果	新しいスナップショットでも、その checked_at 後の失効イベントは証明しない
設定：未知のフィールド、不正な信頼設定、プロファイルの弱体化を拒否	external.admission.config	複数欠陥のケースでは複数の規範エラーが許容され得る。付随的なメッセージ表現が規則ではない
組み合わせ手順と結果	結果と組み合わせケース	action_authorized:false、記録された判断、信頼・プロファイルの結果を評価する。完全な signer_keys 出力は直接比較しない
A1–A3：保護対象ハンドラー、運用者設定、情報源、テナント、キャッシュ	別のアダプターテスト	外部キットの対象外。SDK の結果は統合による制御の適用を証明しない

計算済みの検証結果を受け取る評価器は、同じ bundle、ポリシー、時刻に対する結果を呼び出し側が渡すことを信頼します。外部受け入れ判定操作は組み合わせ API を使います。そのテストに合格しても、呼び出し側が任意に渡す検証オブジェクトが安全になるわけではありません。

コアとプロファイルについて主張できる範囲

対象面	キットから報告できること	分けて扱う必要があること
コアのデータ表現	実際にテストした正確な dcp-jcs-v1 正規バイト列とダイジェスト	未テストの入力と実験候補
V2 証拠検証	選択した bundle、Merkle、署名ケースの結果	別途確認されない限り、完全な V2 適合、特にスキーマのカバレッジ
暗号プリミティブ	テストしたドメイン分離、構成要素の検証、結合	検証ポリシー、プリンシパルへの信頼、受け入れ判定
strict-v1 の受け入れ判定	選択した受け入れ判定・設定ケースの結果	デプロイ環境での制御の適用、操作の認可
V1	コミット済みフィクスチャに対する参照スキーマ・整合性検査	独立した第三者の V1 適合性
A2A とガバナンス	名前を明示したスイートで実際にテストした規則のみ	各プロファイルの完全な機能適合性
DCP-05 から DCP-09	内部スキーマ・通信形式スイートが明示する検査	ライフサイクル、権利、委譲の完全な意味論
実験的な dcp-jcs-v2	個別に選択した実験テスト	規範またはデフォルトとしての地位。dcp-jcs-v1 は不変

部分集合の結果には、その範囲と制限を明記する必要があります。unsupported、ケースの欠落、異常終了、タイムアウト、省略されたマトリクスを合格にしてはいけません。マトリクスを実行せずに終了する予約済みの SDK テストは、そのマトリクスが実行された証拠にはなりません。

追加の検証

実装者ガイドは、独立して結果を再現・報告する方法を説明します。外部実装と独立したセキュリティレビューは追加のマイルストーンです。このリポジトリのテストはそれらの代わりにはなりません。

性能測定には専用の文書化された実行ツールを使います。端から端までの時間は、暗号プリミティブへのコスト帰属や早期終了がないことの証明にはなりません。具体的なコストを測定してから、検証判断と互換性を維持して最適化してください。