HTTP Message Signatures とは
HTTP Message Signatures は RFC 9421 で定義されており、HTTP リクエストまたはレスポンスの一部に対してデジタル署名を作成し、検証するための IETF 標準です。クライアントは対象に含めるコンポーネントを選びます。例えば method, target URI, authority, 選択した headers です。そこから正規化された signature base を組み立て、秘密鍵で署名します。結果は 2 つの headers に入ります。Signature-Input (Section 4.1) は対象に含めたコンポーネントと created, expires, keyid, alg などのパラメータを सूचीします。Signature (Section 4.2) は署名値そのものを運びます。どちらも RFC 9651 の Structured Field Values syntax を使います。
受信側は、実際に受け取った request から同じ signature base (Section 2.5) を再構築し、keyid で参照される公開鍵を探して、署名を検証します。署名で対象に含めたものが途中で変わっていれば、検証は失敗します。
apps, APIs, MCP servers で重要な理由
多くの自動化トラフィックは、user-agent string か自分で名付けた client name で自分を名乗ります。どちらも簡単に偽装できます。message signature はこれとは異なり、request を key に結び付け、秘密鍵の保持者だけが有効な署名を作れます。crawler, assistant, autonomous agent からの traffic を受ける application にとって、これは「この client は X だと言っている」から「この request は X が公開する key で署名されている」へと意味を変えます。
この違いは、協調的な自動化 client を匿名 traffic ではなく、既知の参加者として扱うための基盤です。API は署名済み crawler を structured endpoint に振り分けたり、既知の operator に別の rate limit を適用したり、MCP server に tool を呼び出している相手についてより多くの context を与えたりできます。
実運用での検証方法
Signature-InputとSignatureを解析し、期待した components が含まれていることを確認します。役に立つものを何も覆っていない signature では、証明できることはほとんどありません。createdとexpiresの parameters を確認し、許容範囲内で古い request や replay された request を拒否します (Section 7.2.2 の signature replay を参照)。keyidを、運用者が既知の場所で公開している key directory のような、信頼できる source から取得した public key に解決します。IETF の Web Bot Auth protocol draft は、自動化 client 向けにそのような directory を定義しています。- 指定されたとおりに signature base を正確に再構築し、宣言された algorithm で検証します。
- 何が検証され、どの context で検証されたかを記録し、後続の判断で参照できるようにします。
本番環境では、手作業で parsing するのではなく、保守されている RFC 9421 実装を使ってください。canonicalization の細部は誤りやすいからです。署名付き AI agent request を検証する方法 の guide では、各手順を code 付きで説明しています。
有効な署名が証明することと、証明しないこと
有効な署名は、その request が key によって署名されたこと、さらに key が domain 配下で公開されている場合には、その request がその domain の operator に関連付けられていることを証明します。ただし、次のことは証明しません。
- operator が誠実であること、または action が安全であること
- 人がその request を指示した、または承認したこと (delegated authority を参照)
- client が要求していることを実行する権限を持つこと (agent authorization を参照)
identity の evidence と permission は別の問題です。実際に client が何をできるかは、application 側の authentication と authorization が決めます。署名付き AI agent request が証明することと、証明しないこと の blog post で、これをさらに詳しく説明しています。
よくある誤解
- "Signed means trusted." Signed は attributable という意味です。trust は、帰属先についてあなたが下す policy decision です。
- "Signatures replace API keys." それらは別の質問に答えます。API key はどの account が呼び出しているかを示し、signature はどの client が request を生成したかを示します。多くの deployment では両方が有効です。
- "Unsigned traffic is malicious." 現在の自動化 traffic の多くは署名されていません。signature がないと立証できることが減るだけです。それ以上ではありません。だからこそ Unknown は第一級の結果なのです。
Proof of Actor における signatures の扱い
Proof of Actor では、公開された key に対して検証に成功した signature は、basis verified として記録されます。検証で確かめられた内容、つまり key とそれが属する identifier に厳密に限定されます。得られる class (通常は Agent) は authorization を意味しません。結果は分析のために Understand に流れ、Route では独自の policy によって、署名済み client に structured path を与えるか、別の limit を適用するか、あるいは何も変更しないかを決めます。Web Bot Auth のような署名付き agent 標準は進化中であり、Proof of Actor はそれらが成熟するにつれて signed request を検証できるよう設計されています。
evidence が何を確立できるかについてさらに読む、または early access に申し込む。
Sources
- RFC 9421: HTTP Message Signatures: signature components, parameters, verification を定義する IETF standard
- RFC 9651: Structured Field Values for HTTP:
Signature-InputとSignatureの syntax - draft-ietf-webbotauth-httpsig-protocol: RFC 9421 を自動化 client に適用する IETF Web Bot Auth draft (2026年11月時点で作業中)