「Private Access Tokens」という提案仕様が、Google, Apple, Fastly, Cloudflareの方々らの共著でIETFに提出されています。なお、すでに実装が進められているそうです。
この「Private Access Tokens」の一つのモチベーションに次のようなものがあります。
昨今、プライバシー保護の要求は高まっており、ユーザのIPアドレスを秘匿する、iCloud Private RelayやOblivious HTTPといった技術が出てきています。いままではIPアドレスベースでアクセスレートリミットを行っていましたが、
そのような環境でも、アクセスのレートリミットを設けたいというというのが一つの目的です。
それを、追加のユーザインタラクション無しに、かつユーザをトラッキングできないような匿名なトークンで行うというのがPrivate Access Tokens」です。
IETF 112のSec Dispatch WGのセッションで発表(Agenda)があるようですが、簡単に予習しておきます。(追記: 発表資料スライド)
なお、RSAブラインド署名やHPKEなど、使われている暗号処理はまではまだ理解できてないので概要だけ。
仕様の内容
この仕様では、大きく分けて２つのことが書かれています。
また、各手順に置いて、登場人物がどのようなやり取りをするのかが定義されてます。
登場人物
- Client: IssuerにPrivate Access Tokensをリクエストし取得する。Originのサービスにアクセスするために、Private Access Tokensをオリジンに提示する。
- Mediator: IPアドレスやアカウント名などの情報をも使用してClientを認証する。ClientをIssuerに対して匿名化し、匿名化されたClientとIssuerのやりとりを中継する。
- Issuer: Originに代わって匿名化されたClientにPrivate Access Tokensを発行する。OriginをMediatorに対し匿名化し、Originのポリシーを適用する。
- Origin: ClientをチャレンジでIssuerにリダイレクトする。そして、クライアントからのレスポンスとしてPrivate Access Tokensを受け取る。Clientにコンテンツやサービスを提供する。
IssuerはOriginによって選択されますが、MediatorはClientによって選択されます。
IssuerはOriginがClientに課したいポリシーを知っており、Originに代わりそれらを課します（ポリシーは、クライアントごとに10アクセスに制限すると言った例）。なお、IssuerへアクセスではClientの情報は匿名化されているため、本当のユーザはわかりません。
各登場人物は処理が必要な情報だけしか知りえません。共謀しないとい前提で、各登場人物がどのような情報を知りえるかは仕様の方を御覧ください。
大雑把な流れ
大雑把な流れは以下のとおりです。赤字がChallenge/Response Flowになります。
- ClientがOriginにアクセスする
- Originは、Challenge/Response Flowの一環としてOriginからIssuerにリダイレクトを行う。このとき、WWW-AuthenticateヘッダでTokenChallenge及び、Issuance Flowに必要な情報をClientに通知します
- Clientは、TokenChallengeをブラインド処理し、Issuer固有の鍵で暗号化した上で、Mediatorを介してIssuerにPrivate Access Tokensを要求します。
- Issuerは、復号を行い、各種検証を行った後、ポリシーの適応とPrivate Access Tokensの発行を行います。Mediatorを介してClientに渡されます。
- ClientはChallenge/Response Flowの一環として、ResponseをOriginに送信します。
感想
Issuance Flowの細かいところ難しい...
