要約

  • remoteClientDataJSONは既定で無効であり、ローカルの呼び出し元オリジンごとに許可が必要だ。ただし、その許可はリモート側がオリジンとRP IDの関係を正しく検証した証拠ではない。
  • ローカルUAに同じ検証を繰り返させるのではなく、リモートセッション、適用ポリシー、検証結果、厳密なクライアントデータのハッシュを結ぶ受け渡し記録を残すべきだ。

2026年9月15日に公開されたWeb Authentication Level 4のFirst Public Working Draftが動かしたのは、暗号方式というより責任の置き場所である。

通常のWebAuthnでは、ブラウザが自分の実行コンテキストから呼び出し元のオリジンを得る。RP IDは原則としてそのオリジンの有効ドメインと同一か、その登録可能なドメイン接尾辞でなければならない。関連オリジンを用いる場合には別の検証手続きがある。ブラウザがclientDataJSONを組み立て、認証器がそのハッシュを署名し、Relying Party（RP）は式典の種類、チャレンジ、期待するオリジン、RP IDハッシュを確かめる。

リモートデスクトップでは、この近接した関係が崩れる。認証を要求するサイトやアプリはリモートホストで動作する一方、利用者の認証器は手元の端末にある。ローカルブラウザが自身のページ情報からクライアントデータを再構成すると、リモートセッション内のRPではなく、リモートデスクトップWebクライアントのオリジンが入る。フィールド順序や空白といったJSONの表現差だけでもハッシュは変わり、RP側の検証に失敗し得る。

remoteClientDataJSON拡張は、リモート側が用意した完全なクライアントデータ文字列を、許可されたWebクライアントがローカルブラウザへ渡せるようにする。ローカルブラウザはJSONを解析するが、内容を追加、削除、変更してはならない。シリアライズ時には入力文字列そのものをclientDataJSONとして使い、リモートホストが想定したものと同じバイト列を認証器に署名させる。

権限の境界は弱くない。草案はpublickey-credentials-remote-client-data-jsonを強力な機能であり、同時にPermissions Policyで制御される機能と位置づける。既定の許可状態はdenied、記載された既定の許可リストは'none'である。設定はオリジン単位でなければならず、全オリジンを一括許可する仕組みは禁止される。式典の最中に安易な許可ダイアログを出すのではなく、管理ポリシーやブラウザ設定での明示的なオリジン別選択を想定している。

それでも、この権限が答えるのは「このローカルオリジンが拡張を呼べるか」という問いだけだ。「リモートクライアントがリモートRPのオリジンを正確に示し、そのRP IDを適切な規則で検証したか」という問いには答えない。

処理手順は境界を明示している。ローカルの許可状態がgrantedでなければNotAllowedErrorとなる。RP IDも明示的に指定されなければならず、与えられたJSONは解析される。だがその後、ローカルブラウザはRP IDと、リモートデータ内のoriginとの通常のドメイン関係チェックを省略する。草案は、RP IDに関するオリジンチェックをすべてリモートクライアントへ委ねると説明する。セキュリティ考慮事項も、許可を与えるUAは、呼び出し元がリモートRPのオリジンを正確かつ誠実に提供し、リモート側がRP IDを正しく検証したと信頼しなければならない、としている。

したがって、いくつかの成功シグナルを一つの証明にまとめてはならない。拡張出力のtrueは、拡張が実行されたことを表すだけだ。リモートセッションID、検証ポリシー、関連オリジンの根拠、検証結果は含まれない。バイト列が維持されたことも、ローカルブラウザがデータを作り直さなかった証拠にはなるが、その中のオリジン表明が真実で、現在も有効で、許可されたものだとは証明しない。

認証器の署名にも固有の役割がある。署名は結果をクライアントデータのハッシュと認証器データへ結び付ける。RPにはなお、式典タイプとチャレンジを確認し、クライアントデータのオリジンを検証し、期待するRP IDのrpIdHashを照合する義務がある。これは重要な最終防衛線だが、どのリモートクライアントが、どのポリシー版で、どの認証済みチャネルにおいて委任された判断を行ったかまでは自動的に保存しない。

これは脆弱性や攻撃、事故を主張する話ではない。Level 4は最初の公開作業草案であり、W3C勧告でも、実装や相互運用、実運用の証拠でもない。文書自身が、公開はW3Cや会員による支持を意味せず、草案は更新、置換、廃止され得ると明記している。W3C WebAuthnリポジトリの未解決Issue 2430は、'none'という既定許可リストの用語が依存先のPermissions Policy草案でまだ規範的に定義されていない点を追跡する。意図された既定無効の動作は明確で、Issueも動作変更を求めてはいない。

ゆえに、対策は委任を取り消すことではない。リモート側には、関連オリジン文書やOS固有のアプリ関連付けなど、ローカルブラウザが持たない文脈がある。ローカルUAにすべての検証を再実装させれば、二つの判定系が別々に変化し、新たな不一致を生む。

必要なのは、制御境界を越える検証レシートである。ローカル呼び出し元オリジン、許可の主体・根拠・版・期限を、リモートセッションと認証済みチャネルに結び付ける。リモートオリジン、RP ID、検証アルゴリズムと版、結果、関連オリジンやアプリ関連付けの証拠参照を記録する。そして、厳密なremoteClientDataJSONのハッシュとRPサーバーの検証結果で鎖を閉じる。例外、失効、訂正は元の判断を上書きせず、履歴として追加する。

このレシートは運用上の統制案であり、WebAuthn仕様の要求だと主張するものではない。ローカル能力の許可、リモート検証、バイト保持、利用者と認証器の操作、RPの受理という異なる事実を、後から混同せず確認するためのものだ。「WebAuthn成功」という一つの緑色表示だけでは、その全てを証明できない。

出典