ritouです。
Email Verification Protocol Origin Trial
Email Verification ProtocolのOrigin Trialが始まったようです。
https://developer.chrome.com/blog/email-verification-protocol-origin-trial
「なんか便利そうな仕組みやな〜」とのんびり眺めるのではなく、ID管理の基本を用いて解像度を上げていきましょう。
まずは説明を読んでみます。サービスの新規登録時などに行われるメールアドレス確認は、一度受信したメールを確認しに行く必要があるため、離脱などの課題がありました。そして、その後に書かれているのがこちらです。
The Email Verification API is a proposal that allows the browser to communicate directly with the email provider to verify that the user owns the email address. Users select an email from the browser's autofill or autocomplete suggestion, submit the form, and the site verifies the email address with the provider without sending an email or interrupting the user's flow.
メール検証APIは、ブラウザがメールプロバイダと直接通信して、ユーザーがメールアドレスの所有者であることを検証できるようにする提案です。ユーザーはブラウザの自動入力または自動補完候補からメールアドレスを選択し、フォームを送信すると、サイトはメールを送信したり、ユーザーの操作を中断したりすることなく、プロバイダにメールアドレスを検証してもらえます。
この「プロバイダと直接通信して〜」の部分で何をしているのかを押さえられると、理解はぐっと楽になるでしょう。
Email verification flow
フローについて、提示されている図を見てみます。
何が行われているかはドキュメントにも書かれているので確認してみましょう。
最初にも触れましたが、この仕組みではブラウザがメールアドレス宛に何かを送信する話ではありません。メールアドレスの所有者がメールアカウントを管理しているサービスにログインしていることを利用して、「このメールアドレスが有効であること」「このメールアドレスの所有者がサービスを利用しようとしている」ことをサービスに伝えます。サービスはメールアドレスを確認済みの属性情報として新規登録などで利用できます。
ID管理の基礎的な用語を用いて整理してみる
- メールアドレスの確認では、メールアカウントを管理するサービスとの「簡易的なID連携」を用いて、メールアドレスの所有者がログイン中であることを利用する。
- Discoveryの仕組みを用いて、メールアドレスからメールアカウントを管理するサービスを特定する。
- メールアカウントを管理するサービスは、「このメールアドレスの所有者がログイン中であること」を表現するEmail Verification Token (EVT) を生成する。ブラウザは、それにオリジンやnonceなどを組み合わせたパッケージをフォームに追加してサービスへ渡す。
- サービスはそれらを検証したうえで、「このメールアドレスは確認済みである」と判断し、新規登録などに利用する。
この一連のやり取りは、簡易的なID連携と捉えることができます。また、サービス側から見ると、得られるものは「このメールアドレスの所有者が現在メールプロバイダでログイン中である」という主張です。メールアドレスの所有確認という目的であれば、OIDCで取得する email クレームと email_verified クレームに近い形で利用できます。
過去の自分も含め、未だに「OAuthは認可、OIDCは認証」とドヤ顔で語る人が多いですが、OIDCはあくまでID連携（情報提供）の仕組みです。それで得られた情報を、サービスが身元確認に使うのか、当人認証に使うのか、あるいはその両方に使うのかはサービス側の責任です。 そのくらいの解像度までは上げていただきたいところです。
頭の体操: OIDCで似たようなことをしようと思ったら？
それでは、ブラウザの関与を利用せず、既存のOIDCだけで、サービス利用者が提示したGmailアドレスが有効であり、かつ本人が所有していることを確認したい場合はどうすればよいでしょうか。
まずは、メールアドレスからIssuerを探す必要があります。EVPではDNSとエンドポイントによるメタデータ公開により実現されていますが、ID管理に関わる身としては古から語り継がれるWebFingerプロトコルなどが思い浮かびますね。
そして、OIDCの認可コードフローでは以下のパラメータがサポートされることで実現できそうです。
- login_hint=(提示されたGmailアドレス)
- prompt=none
- scope=openid email
何をやりたいかというと、
- 対象ユーザーを絞り込み、
- Google側の画面は表示せず、
- メールアドレスが確認済みであるという情報だけを取得したい
ということです。
仮にこのあたりがサポートされていたとしても、OIDCでは動的/静的なクライアント登録が必要になりますし、ユーザー情報の取得まで含めて実装しなければなりません。
それと比べると、ブラウザが仲介する今回の仕組みはかなりシンプルに実現できることが分かります。
まとめ
生成AIの新機能を見るたびに驚く人達のような反応をする必要はありません。
FedCMのようにブラウザが仲介する仕組みでは何が実現できるのか。それはOIDCでも実現できるのか。できるのであれば、どのように実現するのか。
そのあたりまで考えられるようになると、仕様を見る解像度はかなり上がってくるはずです。
最後に宣伝です。
https://x.com/ritou/status/2008559657904935128
ではまた。
