独立した実装とレビューのガイド¶

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

DCP は独立して実装できるプロトコルです。本ガイドは、リポジトリ内のアプリケーションやサービスを採用せずに同じ証拠を評価するための、実装者やレビュー担当者の準備を支援します。監査、認証、推奨を意味するものではありません。

最初に対象範囲を定める¶

コアの概要を読んでから、該当する規範文書を確認してください。

V1 および V2 の検証チェックリスト。
正規化プロファイル。
V2 規範仕様。アルゴリズム、複合署名の構成要素間の結合、検証ポリシーを含みます。
プリンシパルへの信頼または strict-v1 を実装する場合は、受け入れ判定プロファイル。
V2 スキーマの該当ファイルと、仕様が参照する正誤表。

コアとプロファイルの区分は仕様を整理するためのものであり、V2 実装が必須の検査を省略できるわけではありません。アプリケーション、ネットワーク上の情報源、キャッシュ、保護対象のハンドラーは統合層に属します。それらによる制御の適用に関する主張は、コアの検証とは分けて扱ってください。

判断の基準は仕様です。Rust/WASM や他の SDK は実装の参考であり、規範を置き換える定義ではありません。参照ライブラリの再利用が適切な場合もありますが、その依存関係を明示し、検証ロジックを独立して実装したとは表現しないでください。

再現可能な入力セットを固定する¶

レビュー済みのリポジトリのリビジョンを使用します。完全なコミット ID と、作業ツリーに変更があるかを記録してください。そのリビジョンのスキーマ、フィクスチャ、カタログ、実行ツールのソースを一緒に保持します。実装のバージョン、解決されたコードのパスまたは成果物のハッシュ、ランタイム、ツールチェーン、ポリシー、検証時刻を記録してください。

カタログとフィクスチャのハッシュはバイト列を識別しますが、提供者を認証するものではありません。信頼する情報源からリビジョンを取得してください。ラッパーの名前とバージョンは自己申告なので、実際に実行された実行ファイルやパッケージを独立して確認します。

公開キットには Node 20 以降が必要です。外部実装はどの言語でも構いません。選択した標準入力・標準出力の契約を実装すれば利用できます。リポジトリ内のラッパーをビルドする場合は、各 SDK の文書に記載されたツールチェーンと依存関係も必要です。ビルド手順と由来の確認方法はキットの READMEにあります。

該当するインターフェースを実行する¶

リポジトリのルートで、まず利用できるケースを確認します。

node tools/conformance-external.js --list
node tools/conformance-external.js --catalog evidence --list
node tools/conformance-external.js --catalog admission --list

次に -- の後に実行ファイルとその引数を指定します。/path/to/implementation は実際のコマンドに置き換えてください。

node tools/conformance-external.js --report /tmp/dcp-primitives.json -- /path/to/implementation
node tools/conformance-external.js --catalog evidence --assessment verdict --report /tmp/dcp-evidence.json -- /path/to/implementation
node tools/conformance-external.js --catalog admission --report /tmp/dcp-admission.json -- /path/to/implementation

これらのコマンドは、それぞれ異なる 3 種類の実行契約を選択します。実装が一部のみをサポートすることは可能ですが、レポートにはその範囲を明示する必要があります。このリポジトリの WASM には受け入れ判定 API がありません。未対応の操作を成功として報告しないでください。

証拠のコマンドは --assessment verdict を明示的に選択しています。規範に基づく判定を評価し、診断メッセージは別途保持します。従来の評価方式も引き続き利用でき、既存のデフォルトは変わりません。診断文字列の一致だけでは、意図した検査が行われた証拠にはなりません。

リクエストに含まれるのはケース ID と操作への入力であり、期待される結果ではありません。契約で定められたレスポンスのエンベロープと必須フィールドを厳密に返し、同じ実行識別情報と、要求された各ケースにつき 1 件の結果を含めてください。ログは stderr に出力します。レスポンスの後でプロセスが失敗終了した場合、その実行は成功ではありません。

キットの契約には、正確なエンコード規則、制限、終了コード、レポート構造が記載されています。このガイドから新しい通信プロトコルを推測しないでください。

明示的にスキーマ診断を選ぶ場合は、証拠コマンドの --catalog evidence を --catalog tools/conformance/external-schema-catalog.json に置き換えます。同じ /2 契約を使い、規範上の失敗は失敗のまま扱います。デフォルトの証拠カタログとは別です。SDK API 単体の結果を解釈する前にカバレッジマップを確認してください。

生成されたレポートの確認¶

キットの README には最小限のリクエストとレスポンス、実行可能な TypeScript と Python のラッパー例があります。bundle 検証を実装する前に digest の交換で通信契約を確認してください。これらのラッパーを再利用しても、その SDK の検証ロジックが独立した実装になるわけではありません。

上の証拠検査コマンドを実行した後は、成功例をコピーするのではなく、実際のレポートを確認します。

node --input-type=module - <<'NODE'
import fs from 'node:fs';
const report = JSON.parse(fs.readFileSync('/tmp/dcp-evidence.json', 'utf8'));
console.log(JSON.stringify({
  status: report.status,
  run_id: report.run.id,
  started_at: report.run.started_at,
  finished_at: report.run.finished_at,
  contract: report.kit.contract,
  catalog_sha256: report.kit.catalog_sha256,
  fixtures_sha256: report.kit.fixtures_sha256,
  implementation: report.implementation,
  totals: report.totals,
}, null, 2));
NODE

これは実行結果の値を表示するだけで、レポートの検証や実装の認証はしません。コマンドの終了状態、実行時間帯、固定したカタログとフィクスチャのバイト列に照らして確認してください。最小要件に加えて、インストール済みツールチェーンの正確なバージョンも記録します。ネイティブラッパーのビルド要件はキットの README に記載されています。

結果を正確に解釈する¶

プロセスの終了ステータスとレポートを併せて確認します。レポートが今回の実行に対応すること、全体のステータスが合格であること、選択した全ケースが実行されたこと、必須の実装が省略されていないことを確認してください。古いレポート、部分的な結果、複数の不具合のある実装間の一致だけでは不十分です。

互換性を主張する前に、セキュリティのカバレッジマップを読んでください。スキーマ検証、暗号学的検証、プリンシパルへの信頼、受け入れ判定はそれぞれ異なる層です。main の五つの SDK の V2 検証器は V2-2 のスキーマ検査を自ら行いますが、公開済みの SDK バージョンは行いません。いずれの場合も、検証済みという結果は、プリンシパルへの信頼、受け入れ判定、認可について何も示しません。

否定ケースには、正常に機能する肯定対照が必要です。変更したペイロードが意味上の欠陥に加えて無効な署名も持つ場合、その拒否だけでは意味上の検査を切り分けられません。パーサーや正規化の差異を再現するときは入力バイト列を保持してください。解析して書き直すと原因が失われる可能性があります。

実装間で結果が異なる場合は、次の手順を取ります。

有効な対照とともに、同じバイト列、時刻、ポリシーで再現します。
プロトコルの判定を、プロセスの異常終了、結果の欠落、タイムアウトと区別します。
該当する失敗と対照を維持したままケースを縮小します。
該当する規範要件を正確に引用します。仕様から判断できない場合は、多数派の判定を選ぶのではなく未解決の問題として報告します。
期待する動作に妥当な根拠が得られてから、回帰テストを追加します。

独立したセキュリティレビューを準備する¶

レビュー用資料には、固定したリビジョン、セキュリティモデル、カバレッジマップ、選択した契約、正確なコマンド、入出力ハッシュ、未解決の問題を含めると有用です。各主張がどの実装と公開 API を対象とするかを明示してください。

コアのレビューでは、正規化、マニフェストと成果物の結合、署名ポリシー、スキーマ検証、プリンシパルへの信頼、受け入れ判定、テストツールの信頼性を扱えます。サプライチェーン上のリスクの一部として、暗号ライブラリの依存関係とバージョンも確認します。既知の正解を用いるテストは有用な証拠ですが、ライブラリ自体の監査ではありません。レビューの委託範囲からそれらの内部暗号実装を除外する場合は、その除外を明示してください。

トランスポート、鍵の保管、リモートの信頼・失効情報源、キャッシュ、テナント分離、アプリケーションの認可、デプロイ環境の制御には、それぞれ別の対象範囲が必要です。コア関数をテストしても、これらの性質は証明できません。

秘密鍵、本番環境の認証情報、個人情報を含む記録、機密ログをフィクスチャとして提出しないでください。公開された合成テストデータを使います。脆弱性については、リポジトリのセキュリティ報告手順に従ってください。公開テストコーパスは、調整された脆弱性開示の代わりにはなりません。

実装経験を報告する¶

再現可能な実装レポートには、次の事項を記載してください。

仕様のリビジョン、サポートする通信形式のバージョン、明示的に選択したプロファイル。
再利用した暗号実装または SDK のコード。
正確なテストスイート、評価方式、コマンド、実装バージョン、レポート識別情報。
記録されたポリシーと検証時刻、肯定対照、省略または未対応の機能、既知の不足点。
秘密情報を除去し、規範文書に対応付けた最小限の差異。

アーリーアダプタープログラムは、メンテナーが統合時のフィードバックを集める方法を説明しています。このガイドはその準備であり、外部の実装者が DCP をレビューまたは採用したと主張するものではありません。