2026 Chrome Email Verification API 発行者リクエストはどう検証する？

発行担当者は証拠を段階ごとに分けます

「リクエストを受け取った」「署名を検証した」「トークンを発行した」「サイト側でメール確認が完了した」は、それぞれ異なる状態です。サーバーのログやQAの判定で一つにまとめると、署名検証を通過していないのに発行処理へ進む欠陥や、発行成功をメール所有権の確認完了と取り違える問題を見落とします。

Chrome Email Verification APIは、ブラウザー側から発行者へ届く要求を処理する工程と、ウェブサイト側が発行されたEmail Verification Token（EVT）を受け取り確認する工程を含みます。発行者は署名とユーザーの状態を検証してトークンを発行します。サイト側のEVT受け入れ処理まで試験したい場合は、API全体の処理フローも確認し、発行端の成功をサイト側の完了証拠として扱わないようにします。

判断に使う証拠の差は次のとおりです。

互換性担当者はブラウザー版と実リクエストを対応付けます

Chrome公式資料によると、Chrome 153以降の発行リクエストではJSON本文とHTTP Message Signaturesが使われます。以前の形式と同じものとして処理を固定せず、旧形式と新形式の差は公式の発行者向け実装ガイドで確認してください。すべての利用者が同じ版、同じリクエスト形式を使うと仮定するのも避けます。

また、Chrome 154以降はSec-Fetch-Destの値がemail-verificationになり、それ以前にはハイフンのない表記が存在します。これは発行可否を決める唯一の安全判定ではありませんが、固定値だけを許可すると移行中の要求を誤って拒否する可能性があります。版ごとの実リクエストを収集し、受け付ける値とログ上の分類を、公式資料の記述に合わせて管理します。

Chrome 156以降については、署名アルゴリズムを示す情報とトークン内のメールアドレス宣言に関する変更が公式更新に記載されています。細部を旧版から推測せず、2026年10月のChrome更新とガイドを参照し、検証処理と期待値を更新してください。回帰試験では「ブラウザー版」「受信形式」「ヘッダー値」「判定結果」を同じ記録単位にします。

バックエンド担当者は署名とプロキシ境界を検証します

SignatureとSignature-Inputは一組として扱います。Signature-Inputが示す署名対象とパラメーターから署名ベースを構成し、Signatureの値を適切な鍵で検証します。Content-Digestについては、ヘッダーがあるだけでなく、受信本文から算出した摘要と一致することを確認します。各ヘッダーの意味と検証の考え方はRFC 9421およびChromeの発行者ガイドに照らしてください。

Signature-Keyを含む鍵情報の扱いも、単なるフィールド確認で済ませてはいけません。現行ガイドが示す鍵の取得・照合方法に従い、許可されていない鍵や検証に失敗した署名を拒否します。TLSで接続されていることや、署名関連ヘッダーが揃っていることは、メッセージ署名の検証成功を意味しません。

プロキシやロードバランサーの背後では、公開リクエストのauthorityと、アプリケーションから見える内部ホスト名が異なることがあります。署名対象を組み立てる際に内部値へ不用意に置き換えると、検証失敗や誤った対象の検証につながります。外部から届いた値をどの信頼境界で確定するかを設計し、公式例と照合して、転送ヘッダーを無条件に信頼しない構成にします。

セッション担当者は要求メールとアカウントを照合します

暗号学的な署名検証に成功しても、それだけで発行してはいけません。要求に結び付くユーザーセッションが有効であることを確認し、リクエストのメールアドレスがそのユーザーについて検証対象として登録されたアドレスと一致するかを調べます。セッションがない場合や別ユーザーのアドレスが指定された場合は、署名が正しくても発行を拒否します。

照合用の内部値と、トークンへ返すメール文字列は分けて扱います。アカウント検索で正規化した値を使う場合でも、トークンのメール宣言へ同じ正規化値を無条件に転記しないでください。Chrome 156以降のトークンでは、メール宣言を要求値と一致させる変更が公式ガイドに示されています。処理条件はChromeの発行者向け要件で再確認し、比較用の値と出力値を別々に試験します。

セキュリティ担当者は拒否条件を独立して試験します

正しい署名を持つ要求だけをテストすると、実装が署名検証を省略していても通過してしまいます。テスト用の秘密鍵、アカウント、メールアドレスは本番データから分離し、次の条件を一件ずつ変えて確認します。

• 署名が正しい要求では、署名・本文摘要・セッション・対象メールの確認後にのみ発行処理へ進む。
• SignatureまたはSignature-Inputがない要求、署名値を変更した要求は拒否される。
• 本文を変更して摘要と一致しなくした要求は拒否される。
• セッションが無効または存在しない要求は拒否される。
• 要求メールとセッション上のユーザーの対象アドレスが異なる要求は拒否される。

各負例では、応答だけでなく、トークン発行が発生していないことも確認します。エラー応答が返っていても、別の非同期処理でトークンを作成していれば失敗です。ログには秘密情報や不要な個人情報を残さず、試験ケースと判定理由を対応付けてください。

QA担当者は発行・受け入れ・回退を別々に記録します

QAでは、署名が有効な要求について、現行の公式形式に合う発行結果が得られることを確認します。そのうえで、発行者がトークンを返した事実、ブラウザーがそれを受け入れた事実、サイト側がメール確認を完了した事実を分けて記録します。ひとつの成功ログだけで三段階すべてが完了したと判断しないでください。

ブラウザーが機能に対応しない場合、トークンを取得できない場合、サイト側の確認が失敗した場合には、自社の既存メール確認フローが継続できるかも試験します。メールリンクや確認コードを使う既存経路があるなら、API経路の拒否・失敗からその経路へ移れることを確認します。テスト受信先でメールを確認できても、それは本番環境での到達率や送達を保証するものではありません。

リリース記録には、Chrome版、リクエスト形式、Sec-Fetch-Destの値、署名・摘要の結果、セッションとメールの照合結果、トークン発行結果、メール確認への回退結果を残します。実際のメール受信を検証する作業は、署名の発行テストとは別の試験項目にします。検証コードメールを実際に受信して確かめる方法を参照する場合も、確認対象をメールの受信事実に限定し、API発行の証拠と混同しないでください。

よくある確認事項

発行者リクエストの検証で、ヘッダーの存在だけでは不十分なのはなぜですか

ヘッダー名が届いていても、その値が正しい署名であることや、署名が対象本文に結び付いていることは証明されません。署名、署名入力、本文摘要を検証し、さらにセッションとメールアドレスの関係を別に確認します。各段階の結果を独立して記録すれば、どの境界で拒否されたかを切り分けられます。

HTTP Message Signaturesはどのような順で確認しますか

まず公式ガイドで対象コンポーネントと鍵の扱いを確認します。次にSignature-Inputに従って署名ベースを構成し、Signatureを検証します。本文についてはContent-Digestと実際の受信内容を照合します。RFC 9421は標準機構の確認に使い、Chrome固有の要求や変更点はChromeの実装ガイドで確認してください。

Chromeの移行期にヘッダー値を一つに固定できますか

固定は避け、対象にするブラウザー版と取得したリクエストを対応付けて判断します。Chrome 154以降のSec-Fetch-Destはemail-verificationで、旧版にはハイフンのない表記があると公式資料に記載されています。許容値は無制限に広げず、公式要件と互換性試験に基づいて管理します。

署名を拒否した後、メール確認へ戻れることは何で証明しますか

署名欠落や本文摘要不一致などの負例でトークンが発行されないことを確かめ、その後に既存のメール確認を開始・完了できることを別に記録します。テスト受信箱で確認コードを受け取った記録はメール経路の証拠ですが、署名検証の成功や本番メールの到達保証にはなりません。両者を異なる試験結果として保存します。

受信試験は発行端とは別の作業として扱います

Chrome Email Verification APIの署名発行をテストする場面では、テスト受信先はメール回退経路を確かめるための補助です。臨時の受信先を使っても、発行者の署名検証やブラウザー側のトークン受け入れを代替できません。自社の登録フローでメール確認への回退が動くかを調べるなら、テスト用のメール受信確認ガイドのように、何を証明する試験なのかを先に分けておくと記録が明確になります。

一時的な登録や確認コードの受信だけを試す場合は、主アドレスをテストデータに使わず、ZOSendの受信先を選択肢に加える方法もあります。これはメール回退の受信確認に使うものであり、Chrome Email Verification APIの発行端を検証する機能ではありません。銀行・決済・行政など、長期的な本人確認やアカウント復旧が必要な用途では、継続して管理できるメールアドレスを使ってください。

よくある質問

発行者側はリクエストを受信した後、何を確認すればよいですか？

受信したという事実だけではトークンを発行しません。現行の公式ガイドに従ってHTTP Message SignaturesとContent-Digestを検証し、署名鍵の扱い、ユーザーセッションの有効性、リクエスト内のメールアドレスと対象アカウントの一致をそれぞれ確認します。各判定を分けて記録すると、失敗箇所を特定しやすくなります。

SignatureとSignature-Inputは、どちらか一方を確認すれば十分ですか？

十分ではありません。Signature-Inputが示す署名対象とパラメーターから署名ベースを構成し、Signatureの値を対応する鍵で検証します。さらにContent-Digestが本文と一致することも確認します。RFC 9421の署名検証手順とChromeの発行者向け実装ガイドを参照し、ヘッダーの存在確認を暗号学的な検証の代わりにしないでください。

Chrome 154以降のSec-Fetch-Dest変更は、発行者の処理に影響しますか？

影響する可能性があります。Chromeの公式資料では、Chrome 154以降の値はemail-verificationで、それ以前にはハイフンのない表記があると説明されています。固定文字列ひとつだけで判定すると、移行期のリクエストを誤って拒否するおそれがあります。検証環境ではブラウザー版と実際のヘッダーを組み合わせて記録し、公式ガイドの更新に合わせて許容条件を見直します。

無効な署名を拒否しながら、既存のメール確認も継続できるか試すには？

有効な署名だけでなく、署名欠落、署名不一致、本文摘要の不一致、無効なセッション、別アドレスの要求をそれぞれ用意します。無効なケースではトークンが発行されないことを確認し、その後、対象サービスの既存メール確認へ進めることも別の証拠として記録します。テスト用の鍵、アカウント、受信先は本番データから分離します。