要約

  • 本人にはサイトごとに異なるsubjectを渡すが、エージェントの鍵ID、handle、鍵の指紋はサイトをまたいで共通する。
  • 草案は、二つのサイトがその代理側のフィールドを比べれば、別々のsubjectを同じ本人へ結び付けられると記す。実装状況に記載された試験は、一サイトでの本人ログインだけだ。

公開記録の範囲は狭い。Datatrackerはこの文書を個人Internet-Draftとして掲載し、RFCの予定ステータスは示していない。実装状況には、小規模事業者のサイトがレコードを公開し、本人一人がpasskeyログインを完了したとある。エージェントのログイン試験、二サイト間の比較、実際の相関事例は記載されていない。設計とリスクは文書にあるが、採用状況の数字はない。

委任ログインを評価する運用者は、「pairwise subject」を資格情報全体のプライバシー保証として扱えない。pass内の本人とエージェントの各識別子、それを受け取るサイト、subjectを再計算できる発行者、エージェントの権限を定めるgrantを個別に確認すべきだ。草案はgrant自体を対象外としているため、passの説明は、それを成立させた権限より詳しい。

店を替えるたび本人の番号は変わる。代理人の会員証は、どの店でも同じだ。

エージェントの経路には別のフィールドが付く。権限を与えられたエージェントは発行者に短命のacts-for passを求める。passは本人をサイト固有のsubjectで示し、エージェントをacting.kid、Bot階層のhandle、署名鍵の指紋cnf_jktで示す。サイトは発行者の署名、受け手、期限、エージェント鍵で署名されたリクエストを検証する。passは発行から最長5分で失効し、grantに書かれた期限も超えない。

この検証でpassの使い回しは抑えられる。エージェントの身元はサイト間で共通のままだ。草案のプライバシー節は、同じエージェントがどこへログインしてもacting.kid、acting.handle、cnf_jktは同一だと明記する。二つのサイトがこれらを比較すれば、異なるpairwise subjectが一人の利用者を示すと分かる。未解決事項の10番目は、エージェントにサイトごとの鍵とhandleを持たせるべきかを問う。

これが、2026年10月21日更新の個人Internet-Draft、Acts-Forにあるプライバシー上の継ぎ目だ。提案は、~handleとpasskeyでサイトにログインし、すべてのサイトに同じ個人IDを渡さずに済む仕組みを描く。サイトはDNSレコードを公開し、発行者がそのサイトをクライアントとして登録する。本人が毎回passkeyで認証すると、サイト専用のsubjectが届く。

草案は、発行者が持つHMAC秘密鍵、本人の内部ID、正規化したサイトドメインからsubjectを計算する。同じ人でもサイトが違えば値が変わる。subjectだけを突き合わせてもアカウントはつながらない。OpenID Connectのpairwise subjectは、全サイトで共通の番号を使わず、相手ごとに識別子を分ける考え方だ。

発行者にも集中した情報が集まる。pairwise subjectを作るHMAC秘密鍵を保持し、任意の人について任意サイト向けのsubjectを計算できる。自分がトークンを発行するログインもすべて見える。サイト間の直接照合を難しくするsubjectと、発行者が再計算できる対応表は、同じ設計の両側だ。協力するサイトなら、共通のエージェントIDを照合キーにできる。

出典