メインコンテンツへスキップ
コンプライアンスレポートが監査人にとって有用なのは、あなたが生成して以降編集 されていないと信頼できる場合だけです。OrcaRouter が生成するすべてのレポートは、 アカウントアクセスなしにそのチェックを可能にする 2 つのものを備えています： 正規のエビデンスの SHA-256 コンテンツハッシュと、そのハッシュに対する Ed25519 署名です。このページは、コンプライアンスレポートをどう検証するかを 示します — 公開鍵を取得し、ハッシュを確認し、署名をチェック — 公開エンドポイント だけを使って。 ユースケースは具体的です：あなたは監査人に署名付きレポート（または 共有ポータルリンク）を手渡し、彼らは それに依拠する前に、それが本物で改ざんされていないことを証明する必要があります。 彼らはあなたのワークスペース、キー、コンソールに一切触れません。

​
1. レポートと共に移動するもの

3 つの値がレポートを自己検証可能にします。それらはレポートアーティファクトと、 リンク用の公開共有ポータルメタデータに現れます。
レポートの正規エビデンス JSON の小文字 16 進 SHA-256 ダイジェスト。バイトは 所与のレポートに対して決定論的であるため、同じエビデンスを持つ誰もが同一の ハッシュを再計算します。エビデンスへのいかなる編集もこの値を変えます。
16 進 content_hash に対して計算された base64 Ed25519 署名。これは、ハッシュが OrcaRouter の署名鍵によって署名され、偽造されていないことを証明します。
アクティブな公開鍵の短く安定した識別子（例えば orca- に続く 16 進 フラグメント）。検証者はそれを使って、レポートが現在公開されているキーで 署名されたことを確認します — 未知のキー id で署名されたレポートはフェイル クローズします。
署名はレンダリングされた PDF、CSV、JSON のバイトを直接ではなく、コンテンツ ハッシュをカバーします。同じエビデンスがひとつのハッシュから 3 つすべての フォーマットにレンダリングされるため、完全性保証は基礎となるエビデンスに対する ものです — 所与のレポートのすべてのエクスポートは、ひとつの content_hash、 signature、sig_key_id を共有します。

​
2. 公開鍵を取得する

署名公開鍵はオープンエンドポイントで公開されています — 認証なし、ワークスペース コンテキストなし。監査人はそれを直接呼び出します。 
curl https://api.orcarouter.ai/api/public/compliance/pubkey

{
  "success": true,
  "message": "",
  "data": {
    "algo": "ed25519",
    "key_id": "orca-1a2b3c4d5e6f",
    "public_key": "base64-encoded-ed25519-public-key"
  }
}
public_key は base64 エンコードされた 32 バイトの Ed25519 公開鍵です。ここの key_id はレポートの sig_key_id と一致しなければなりません — 一致しない場合、 レポートは異なる（おそらくローテーションされたか古い）キーで署名されており、 この公開された鍵に対して検証されません。

​
3. 署名を検証する

署名は 2 通りの方法で検証できます。OrcaRouter にタプルをチェックしてもらうか、 公開された公開鍵で完全にオフラインで検証するかです。

​
ホストされた検証エンドポイント

レポートから 3 つの値をオープンな検証エンドポイントに POST します。それは公開 されています — 監査人は認証情報なしで呼び出します。 
curl -X POST https://api.orcarouter.ai/api/public/compliance/verify \
  -H "Content-Type: application/json" \
  -d '{
    "content_hash": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
    "signature": "base64-ed25519-signature-from-the-report",
    "sig_key_id": "orca-1a2b3c4d5e6f"
  }'

{
  "success": true,
  "message": "",
  "data": {
    "valid": true,
    "key_id": "orca-1a2b3c4d5e6f"
  }
}
valid: true は、そのキー id のアクティブな鍵に対して署名が確認されることを 意味します。valid: false は、署名がハッシュと一致しないか、ハッシュが空か、 sig_key_id が現在公開されている鍵と一致しないかのいずれかを意味します。
検証エンドポイントはアクティブな key_id をエコーバックします。送信した sig_key_id と比較してください：両者が異なる場合、レポートはもうアクティブで ない鍵で署名されており、それが検証に失敗した理由です。

​
公開鍵でオフライン検証する

懐疑的な監査人は、検証エンドポイントを一切信頼する必要はありません。アルゴリズム が 16 進コンテンツハッシュに対する標準 Ed25519 であるため、署名は任意の暗号 ライブラリでチェック可能です： 
import base64
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

# public_key from GET /api/public/compliance/pubkey
pub = Ed25519PublicKey.from_public_bytes(base64.b64decode(PUBLIC_KEY_B64))

# content_hash + signature from the report
message = CONTENT_HASH.encode()            # the hex hash string, as bytes
signature = base64.b64decode(SIGNATURE_B64)

pub.verify(signature, message)             # raises if invalid; returns None if valid
署名されたメッセージは16 進ハッシュ文字列そのものであり、ASCII バイトとして エンコードされています — ハッシュがデコードされる生の 32 バイトではありません。 署名検証の前に content_hash 値をそのまま渡してください、さもなければ正しい レポートでもチェックが失敗します。

​
4. 署名が何をカバーするか

署名はレポートの content_hash が OrcaRouter によって署名されたことを証明し、 ハッシュはエビデンスが編集されていないことを証明します。ひとつの微妙な点： ハッシュはゲートウェイが構築するエビデンスの正規形式に対して計算されます — JSON や PDF ファイルの生のバイトではありません。そのため、ダウンロードした アーティファクトを自分で再ハッシュしても content_hash を再現しません。 検証エンドポイント（§2/§3）を使ってください、それは正規ハッシュを再計算し、 あなたのために Ed25519 署名をチェックします：
チェック意味
signature_valid: truecontent_hash は OrcaRouter の鍵で署名された — エビデンスは本物で未編集。
キー id 一致レポートの sig_key_id == 公開されたキー id → アクティブな鍵で署名。
両方がパスすれば、レポートは本物で改ざんされていません。署名失敗は、ハッシュ、 エビデンス、またはキー id が OrcaRouter の署名鍵に属さないことを意味します。

​
5. 共有されたレポートを検証する

ファイルの代わりに監査人に共有ポータルリンクを 送ると、ポータルメタデータには既に content_hash、signature、sig_key_id、 加えてサーバーで計算された signature_valid フラグが含まれています。監査人は そのフラグを信頼し、上記のチェックを公開鍵に対して独立して再実行できます — 共有ポータルはログイン不要で、検証パスは同一です。
共有されたアーティファクトは、そのスタンプされたリージョンがワークスペースの 宣言されたデータレジデンシーリージョンと まだ一致する間のみ配信されます。リージョンが変更された場合、署名メタデータが 検証可能なままでもダウンロードは保留されます。これは設計によるものです — クロスリージョン読み取りを参照。

​
6. 次に行く場所

署名付きレポート

署名付きレポートがどう生成され、どんなエビデンスを捕捉し、監査人共有リンクを どう発行するか。

エビデンスをエクスポートする

監査人のワークペーパー向けにレポートエビデンスを PDF、CSV、JSON として 引き出します。

データレジデンシー

レポートのリージョンスタンプが、それがどこに保存され配信されるかをどう 統制するか。

責任共有

OrcaRouter がゲートウェイパス上で保証するものと、あなたのものとして残るもの。
署名鍵は OrcaRouter のもの；検証は誰のものでもあります。その分割が全体の眼目です — 監査人は、レポートを生成したワークスペースへのアクセスを一切必要とせずに、 レポートが本物であることを証明します。