要約

  • W3Cは2026年8月25日、Web Authentication Level 3をRecommendationとして公開し、6月26日時点の固定実装報告を結び付けた。
  • 報告は53テスト、415サブテストを掲げ、Chrome、Firefox、Safari Preview、Edgeの具体的なビルド、環境、共通のWPTコミットを示す。ただし機能ごとの実装系統は示さない。
  • 最終移行記録はChromeとEdgeの実装が「一部」異なるとする。必要なのは両者を一律に同一視したり別物と数えたりすることではなく、機能、実装層、根拠、判断用途を結ぶ対応表である。

製品列が正確に記録しているもの

8月25日版のWeb Authentication: An API for accessing Public Key Credentials — Level 3は、Webアプリケーションがユーザーエージェントと認証器を通じ、Relying Partyに限定された公開鍵資格情報を作成・利用するためのAPIを定める。文書は広い導入を勧告し、5月26日のCandidate Recommendation Snapshot以降に実質的変更はないと記す。

先頭にはImplementation Reportへのリンクがある。リンク先は6月26日時点のweb-platform-testsのスナップショットであり、更新されないため最新状況はライブサービスを見るよう明記している。対象は/webauthn/の53テスト、415サブテストだ。

実行条件も具体的である。Chrome 151とFirefox 154 alphaは6月25日にLinuxで、Safari 246 Previewは翌日にmacOSで、Edge 151は同日にWindowsで実行された。4件ともWPTのd41367df1eを参照する。表にはPASSだけでなく、FAIL、TIMEOUT、ERROR、NOTRUN、結果なしも残る。

この記録は、「この製品ビルドが、この環境とテスト版で何を返したか」を確かめるのに適している。しかしW3C Processが問う「独立した相互運用実装があるか」は別の命題だ。製品名は実行場所を示しても、その機能を担った実装の系譜までは自動的に示さない。

4列をそのまま4実装と数えるのは粗い。反対に、ChromeとEdgeを常に1実装として扱うのも粗い。ブラウザー製品は、エンジン、OSの機能、プラットフォーム認証器、ベンダー固有部品を組み合わせ得る。ある機能では関連経路を共有し、別の機能では分かれることがある。独立性には機能と層の指定が必要だ。

会議では層を問い、最終記録では「一部」になった

Recommendationへの最終移行issueは、「Implementation」の下にライブWPT結果と固定スナップショットを置く。その直後に、Chromeの実装の一部はEdgeと異なる、と一文だけ記す。

この注記には価値がある。共通部分があるという理由だけで、両製品の全結果を一つに畳むべきではないと分かるからだ。一方で、異なる部分、対象機能、テスト群、部品境界は書かれていない。独立性を支える根拠へのリンクも、どの移行判断でChromeとEdgeの組を用いたのかという説明もない。

3月18日のWorking Group議事録には、より細かな思考の跡がある。「Testing」でEdgeには「通常のChrome」と技術的に異なる部分があるとの発言が記録された。その後、Microsoft AuthenticatorがAndroidまたはiOS経由なのかという問いが出て、ある拡張について両者をWebAuthn層の二つの実装として扱う発言が続く。未解決事項を片付けた後にRecommendationを提案することには、異議なしで合意した。

したがって、独立性を検討しなかったという話ではない。会議はむしろ、製品より細かな層を問題にしていた。課題は公開記録への圧縮である。拡張と層に付いていた説明が「一部」に縮み、テスト表との接続が失われた。

決定手続は完了している。移行issueには7月17日のTeam承認、8月18日に合意かつFormal Objectionなしで終わったAdvisory Committee Review、19日の公開承認、25日のRecommendation URLが残る。公開対応表がないことから、非公開の根拠までなかった、あるいは決定が無効だったとは推論できない。

Processはブラウザー数を合格式にしていない

W3C ProcessのImplementation Experienceは、固定の算式を置かない。仕様が明確かつ完全で市場に関連し、各機能について独立した相互運用実装が実現できることを示すための経験を求める。Teamは、各機能の実装、独立性と相互運用性、仕様執筆者以外による実装、公開導入、エコシステム各層の経験、困難の報告などを検討する。

PASSセルは観測した挙動を示す。実装者やコード経路の独立性まで同時に証明するわけではない。OSの違いも、プラットフォーム機能には重要でも別の機能には無関係かもしれない。同じWPTコミットを使うことは比較可能性を高めるが、テスト対象の系譜を示さない。

FAILやTIMEOUTを製品の安全性評価に変えるべきでもない。未対応、実装差、テスト期待の再検討など複数の説明があり得る。結果なしならなおさら情報は限られる。Recommendationには、全製品の全セルを緑にするという一般規則はない。本稿もそのような新しい関門を作らない。

機能別の「独立性対応表」を添える

追加すべき記録は小さくできる。移行根拠に使う機能またはテスト群ごとに、固定仕様版、テストコミット、製品とビルド、関連する実装層を記す。その上で、限定された独立性の主張と根拠を付ける。公開アーキテクチャ資料があればリンクし、詳細を公開できない場合は責任者と証明範囲を明示する。

同じ行に相互運用の観測と、移行判断で利用したかを置く。ChromeとEdgeが特定拡張で異なる経路を通るなら、その拡張にだけ結ぶ。別機能で関連経路を共有するなら、二つの製品列を無言で二実装にしない。Firefox、Safari、Android、iOS、認証器、Relying Partyソフトウェアにも、機能単位で同じ方法を使う。

これはソースコード監査でも新しい承認機関でもない。十分な実装経験かを判断する権限は、ProcessどおりW3C Teamに残る。対応表は、テストした場所、観測した挙動、特定目的で独立と扱う理由という三つの命題を分けるだけだ。

Lu HengのMinimum Initial Specificationは、Recommendationを調整用の成果物と位置付け、実装、検証、導入、採用を別の現実として扱う。同じ節度は、その前段の証拠にも要る。ブラウザー名はテスト対象を示すが、内側の実装系統を自動証明しない。

出典