DBSCの標準化動向とパスキー連携｜W3C草案の現状と併用の設計【2026年10月】

DBSC（Device Bound Session Credentials）は、ログイン後に発行されるセッションCookieを端末内の秘密鍵に縛る仕様です。パスキーがログインの瞬間を偽サイトから守るのに対し、DBSCはログインした後のCookieが持ち出されたときの被害を短くします。この記事では、W3Cでの標準化の進み具合、Mozilla・WebKitが示した懸念、先行したToken BindingやDPoPとの違い、そしてパスキー認証とDBSCを1つのログインフローで組み合わせる設計を、仕様書とGitHub上の議論をもとに整理します。ブラウザごとの対応バージョンとサーバー実装の手順はDBSCの対応状況とサーバー実装の手順で扱っています。

まとめ：DBSCとパスキーの役割分担と標準化の要点

• 守る段階が違う：パスキーはログイン時の認証を、DBSCはログイン後のCookieの更新を守ります。仕様自身が「WebAuthnは安全なサインインを、DBSCはサインイン後の利用者を守る補完関係」と書いています。
• 名前が似ている別物：「デバイス固定パスキー（device-bound passkey）」は同期されないパスキーの種類で、DBSCとは関係のない用語です。
• 標準化の段階：W3CのWebアプリケーションセキュリティWGが2025年8月21日に初回の公開草案（First Public Working Draft）を出し、2026年10月時点の最新の公開版もこの草案です。編集者草案は2026年9月8日まで更新が続いています。
• ブラウザの立場：ChromeとEdgeが提供し、Mozillaは2026年8月5日にnegative（反対）を確定、WebKitは立場を表明していません。スマートフォン版Chromeの提供時期は未定です。
• 併用の設計：パスキー認証が成功した応答でDBSCの登録を始め、更新に失敗したセッションの再ログインをパスキーで受けるのが基本形です。端末に常駐するマルウェアはどちらでも防げません。

以下、役割分担、仕様が別建てになった理由、併用の設計、標準化の現状の順に説明します。

パスキーとDBSCが守る段階の違い

パスキーでログインしても乗っ取られる経路：インフォスティーラーによるCookie窃取

パスキーは公開鍵暗号でログインし、秘密鍵は登録したサイトのドメインでしか使えません。偽サイトにパスワードやワンタイムコードを入力させる攻撃は、この仕組みで成立しなくなります。ただし、ログインに成功するとサーバーはセッションCookieを発行し、以降のリクエストはこのCookieだけで本人として扱われます。

Googleのセキュリティブログ（2026年4月9日）は、セッション窃取の典型として、利用者がマルウェアをダウンロードし、マルウェアがブラウザのCookieを抜き取って攻撃者へ送る流れを挙げています。この情報窃取型マルウェア（インフォスティーラー）が持ち出したCookieは、パスキーでログインしたセッションでも有効期限内なら使えます。この経路では、パスキーの暗号を破らなくても、ログイン済みのセッションを悪用できます。ログイン後のCookieを守る仕組みが別に必要になる理由がここにあります。

デバイス固定パスキー（device-bound passkey）とDBSCの混同

FIDO Allianceは、パスキーの解説で、パスキーを利用者の端末間で同期できるものと、特定の端末に固定されたもの（device-bound passkeys）に分けています。後者はセキュリティキーなどに保存され、鍵が端末の外に出ません。「device bound」という語が共通するため混同されますが、デバイス固定パスキーはログインに使う認証情報の種類で、DBSCはログイン後のセッションを縛る別の仕様です。

表のとおり、DBSCの鍵は利用者が意識しないところで作られ、仕様上はサイトデータの削除（Clear-Site-Data）とともにセッションごと消えます。デバイス固定パスキーを採用しても、ログイン後のCookieは従来どおり持ち出せる点は変わりません。パスキーの登録・認証の流れはWebAuthnとパスキー認証の登録・認証フローで詳しく扱っています。

WebAuthnを拡張せずDBSCを別仕様にした理由

WebAuthnもブラウザに鍵を作らせて署名させる仕組みなので、これを広げればセッションも守れそうに見えます。DBSCの仕様書は「代替案の検討」の節でこの案を取り上げ、採らなかった理由を2つ書いています。1つは、WebAuthnの資格情報が特定のセッションに結び付かず、長く使われ、サイトデータを消しても残る前提であることです。セッション用の鍵に求められるプライバシー上の性質（セッションとともに消える）と合いません。もう1つは、WebAuthnが利用者の明示的な操作を前提にしていることです。利用者の操作なしに定期的に署名するには、WebAuthnに「黙って使える別種の鍵」を持ち込む必要があり、両方の仕様が複雑になります。

GitHubの説明文書（README）は、WebCryptoやWebAuthnに似た低レベルの鍵APIを使う案にも触れています。保護された鍵での署名は負荷が高いため、サイト側が署名を集める頻度を自前で設計しなければなりません。決済など重要な操作だけを守るとセッション全体が守られず、任意のリクエストを署名用のエンドポイントへ回すと、多数のチームが作った大規模サイトでは改修が重くなります。DBSCは署名をログイン時の登録と期限切れ時の更新の2点に集め、ブラウザが自動で更新する形を選びました。仕様の結論は「WebAuthnは安全なサインインを提供し、DBSCはサインイン後の利用者を守る補完的なもの」です。

パスキー認証とDBSCを1つのログインフローで組み合わせる設計

パスキー認証成功時のDBSC登録ヘッダ

DBSCの登録は、サーバーが応答にSecure-Session-Registrationヘッダを付けたときに始まります。パスキーと組み合わせる場合は、WebAuthnの署名検証に成功した応答にこのヘッダを付けます。ヘッダには任意のauthorization引数があり、ここに入れた文字列はブラウザが登録時に送る署名付きJWT（DBSC proof）のauthorizationクレームへそのまま写されます。

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256 RS256);path="/dbsc/register";challenge="c-8f3a";authorization="pk-login-7d21"

# ブラウザが /dbsc/register へ送るDBSC proofのペイロード
{ "jti": "c-8f3a", "authorization": "pk-login-7d21" }

仕様はauthorizationの値の意味を定めていません。設計例としては、パスキー認証の成功ごとに使い捨ての値を発行し、登録エンドポイントでDBSC proofの署名を検証したうえで、その値を認証済みのアカウントと照合して1回で消費します。これで直前のパスキー認証の結果と、登録される公開鍵を関連付けられます。登録の時点で端末が侵害されていれば鍵の差し替えは防げない点は変わりません。登録エンドポイントと更新エンドポイントの実装、短命Cookieの扱いはDBSCのサーバー実装の手順を参照してください。

重要な操作の前に使う「DBSCの強制更新」と「パスキーでの再認証」

送金や権限変更の直前に本人性を確かめたい場面では、2つの手段があり、確かめる対象が違います。DBSCの仕様は、短命Cookieを失効させるSet-Cookieを付けて同じURLへHTTP 307でリダイレクトすると、リダイレクトの前に更新が走る方法を示しています。これで確認できるのは「登録時と同じ端末の鍵がまだ使えるか」で、利用者の操作は要りません。

一方、パスキーでの再認証（ステップアップ認証）は、WebAuthnのuserVerificationをrequiredにしてサーバーでUVフラグを検証すれば、認証器が生体認証やPINで利用者を確認したことまで確かめられます。端末にマルウェアが常駐していると、DBSCの署名は利用者の操作なしにマルウェアからも使える可能性があるため、取り消せない操作には利用者確認つきのパスキー再認証を選びます。ただし再認証も、操作内容そのものへの同意までは保証しません。DBSCの強制更新は、画面遷移ごとに利用者へ操作を求めたくない中程度の操作に向きます。

DBSC更新失敗時のパスキー再ログイン

更新エンドポイントが署名を検証できないとき、サーバーが403・407・429以外の4xxを返すと、ブラウザはDBSCセッションを終了し、短命Cookieは更新されません。持ち出されたCookieで攻撃者が続けようとした場合も、正規の利用者の端末で鍵が失われた場合（OSの再インストールなど）も、結果は同じ再ログインです。ここでパスワード入力に戻すと、攻撃者に偽サイトでの入力という別の入口を残します。再ログインをパスキーで受けるだけでなく、別のログイン画面やアカウント復旧の経路にも同じ強さの認証を求めて、初めてDBSCで切ったセッションをパスワードの窃取で取り戻される道がふさがります。パスワードとパスキーを併存させる移行の進め方はパスキー移行の実装手順にまとめています。

W3CでのDBSC標準化の現状（2026年10月）

初回の公開草案（2025年8月21日）と編集者草案の更新

DBSCはGoogleがWICG（Web Platform Incubator Community Group）で提案し、W3CのWebアプリケーションセキュリティWGへ移りました。WGは2025年8月21日に初回の公開草案（First Public Working Draft）を出し、W3Cの勧告を目指す標準化の手続き（Recommendation track）に乗っています。2026年10月時点で、W3Cの公開版（www.w3.org/TR/dbsc/）はこの初回草案のままで、作業中の内容は編集者草案（2026年9月8日付）にあります。編集者はGoogleの技術者で、変更履歴の節には「初期の草案」とだけ書かれています。

2026年の編集者草案での変更は細部の確定が中心です。8月には公開鍵の拇印（JWK Thumbprint）のハッシュをSHA-256と明記し、9月には.well-knownのURLを正規化したオリジンから導くよう改めました。リポジトリには、Node.js向けの実装（2026年5月）や、Node.js・Bun・Denoで動くTypeScriptのサーバーライブラリ（2026年9月）など、Google以外の開発者による実装報告も届いています。

同じ事業者の複数ドメインで鍵を共有するフェデレーション

編集者草案の3.3節は、ログインを担うサイト（Session Provider）とその利用側サイト（Relying Party）で同じ鍵ペアを使う仕組みを定めています。ログインしたままの利用者は、ログイン用のサイトでパスワードを求められないことが多く、利用側サイトが独立にDBSCセッションを作ると、マルウェアが自分の鍵で登録を済ませてしまうためです。利用側サイトは登録ヘッダに提供元のURL・セッションID・公開鍵の拇印を付け、両サイトが.well-knownで互いを宣言したときだけ鍵が共有されます。

名前から「Googleでログイン」のような他社間のOIDC・SAML連携を想像しがちですが、Googleの担当者はGitHubの議論（#254、2026年4月15日）で、これは同じ事業者が複数のドメインを持つ場合のための仕組みで、他社間の連携を意図したものではないと説明しています。提供元のセッションが終わったときに利用側も終わらせるかは、両サイトがバックエンドで決める事柄だと編集者が答えています（#259、2026年6月1日）。

企業向け拡張DBSC(E)とMicrosoftの提案

DBSCには、登録の瞬間にマルウェアがいれば攻撃者の鍵で登録されてしまう弱点があります。Microsoftの技術者が書いた企業向け拡張DBSC(E)の説明文書は、常駐しないマルウェアでも新たなサインインを強制し、それ以降のセッションを乗っ取れると指摘しています。DBSC(E)は、組織が従業員に配る前の端末を「クリーンルーム」で1回だけ登録し、以後のセッションの鍵がその端末にあることを暗号的に証明させる案です。説明文書はDBSCの仕様へ統合される見込みとしていますが、2026年10月時点の編集者草案には入っていません。

Microsoftはこれとは別に、OAuthのDPoPにならってCookieなどのブラウザ側の資格情報を公開鍵に縛る「BPoP」を、Edgeの説明文書リポジトリで提案しています。Mozillaの担当者は2024年1月の時点で、DBSCをこのMicrosoftの案とそろえるべきだとコメントしています。

Mozilla・WebKitの立場とスマートフォン対応

MozillaはWebの標準案への立場を示すリポジトリ（standards-positions #912）で、2026年6月30日にnegativeを提案し、8月5日にラベルを付けて閉じました。ハードウェアでセッションを守ること自体には賛成としたうえで、短命Cookieの期限が切れるまで盗んだCookieが使える窓が残ること、再認証に既存のCookie処理と合わない独自の手順が要ることを理由に挙げています。TPMの利用が前提になることや、端末の証明（アテステーション）がサイトへ渡ることへの懸念も書いています。これに対しGoogleの担当者は、DBSCはアテステーションを求めず、リクエストごとの署名は大規模運用で現実的でないと答えました。経緯と企業向けFirefoxの実験パッチはDBSCの対応状況の記事で詳しく扱っています。

WebKit（Safari）の立場の表明（standards-positions #281）は2023年11月から開いたままで、「懸念：使い勝手（usability）」のラベルが付いています。WebKit側の担当者は2024年11月、端末のバックアップから復元したときの体験が悪くなることを懸念しました。Googleは2025年1月に説明文書を改め、鍵の持ち出しを防げるならバックアップと復元を許すのは妥当なトレードオフだと返しています。

スマートフォンでは、Googleの担当者（仕様の編集者）が2026年5月5日の議論（#256）で、AndroidとiOSのChromeへの提供時期は決まっていないと答えています。同じ回答で、Linuxでフラグから有効にできるソフトウェア鍵はDBSCの安全上の利点を失うと明言しています。

Token Binding・DPoPとの違いから見るDBSCの設計判断

トークンを鍵に縛る試みはDBSCが初めてではありません。Token Binding（RFC 8471、2018年10月）は、CookieなどのトークンをTLSの接続に暗号的に結び付ける規格です。Chromeは実装を進めていましたが、Chrome 70で削除しました（Chrome Platform Statusの記録）。DBSCのREADMEは、TLSと統合する方式は、TLSを終端する場所（たとえばロードバランサーやCDN）がログインやセッション管理のアプリケーションから遠い環境で組み込みにくいと書き、DBSCはアプリケーション層で縛る方式を選んだと説明しています。

DPoP（RFC 9449、2023年9月）は、OAuthのアクセストークンを公開鍵に縛り、クライアントがリクエストのたびに署名付きの証明を付ける規格です。MozillaがDBSCに求めた「リクエストごとの署名」はこの形に近く、アクセストークンだけを盗まれた場合は使える窓がなくなります（署名済みの証明そのものの持ち出しや、端末上の不正なコードには別の対策が要ります）。代わりに、署名のたびに鍵を使うため、TPMのような遅い保管場所では負荷が問題になります。DBSCは窓を短命Cookieの寿命まで残す代わりに、通常の各リクエストではなく、登録時と更新時に鍵の所持を証明する方式を採りました。

APIクライアントがOAuthのアクセストークンを扱う構成ならDPoPが合い、ブラウザのCookieセッションを既存の仕組みのまま守りたいならDBSCが合います。どちらか一方を選ぶ話ではなく、守るトークンの種類で使い分けます。OAuthの認可フローはOAuth 2.0の仕組みと認可フローで解説しています。

併用しても残るリスクとDBSCを待たずに打つ手

パスキーとDBSCを両方入れても、端末にマルウェアが常駐している間の悪用は防げません。仕様は非目標として、攻撃者が端末にいる間は署名機能を使われうること、登録時にブラウザが乗っ取られていれば攻撃者の鍵で登録されることを明記しています。DBSC(E)の文書が指摘するように、マルウェアがサインインを強制すれば、利用者がパスキーで正しくログインしても、新しいセッションは攻撃者の用意した鍵に縛られえます。

導入の順序ははっきりしています。消費者向けサービスでは、パスキーを先に入れるべきです。偽サイトによるフィッシングは大規模に起きており、パスキーはSafariやFirefoxを含む主要ブラウザで使えます。DBSCは、WindowsやmacOSのChrome・Edgeから管理画面や決済に入る利用者が多く、インフォスティーラーの標的になる高権限アカウントを抱えるサービスで次に検討します。iPhoneのSafariが利用者の大半を占めるサービスでは、DBSCを実装しても保護される利用者がわずかです。

DBSCの普及を待つ間にできるのは、セッションの寿命を見直すことです。管理画面や決済など影響の大きい画面ではセッションを短くし、重要な操作の前にパスキーで再認証させれば、盗まれたCookieで実行できる操作を狭められます。セッションIDの発行から失効までの設計はセッション管理の実装と保存先の選定で扱っています。

よくある質問

device-bound passkeyとDBSCは同じものですか？

別のものです。device-bound passkey（デバイス固定パスキー）は、端末間で同期されず1台に固定されたパスキーで、ログイン時の認証に使います。DBSCは、ログイン後に発行されたセッションCookieの更新を端末内の鍵に縛るW3Cの仕様案です。

パスキーは突破されることがありますか？

パスキーの秘密鍵は登録したサイトでしか使えないため、偽サイトに入力させる手口では突破されません。ただし、ログイン後に発行されたセッションCookieをインフォスティーラーが盗めば、Cookieの有効期限内はパスキーを経ずにアカウントへ入れます。DBSCはこの経路で使える時間を短命Cookieの寿命まで縮める仕組みです。

SafariはDBSCに対応する予定ですか？

2026年10月時点で、WebKitは標準化への立場を表明していません。立場を示すリポジトリの議論（standards-positions #281）は開いたままで、WebKit側の担当者は端末のバックアップから復元するときの使い勝手を懸念しています。対応予定の発表はありません。

DBSCはW3Cの標準になっていますか？

まだ標準（勧告）ではありません。W3CのWebアプリケーションセキュリティWGが2025年8月21日に初回の公開草案を出した段階で、2026年10月時点の公開版もこの草案です。内容は編集者草案で更新が続いており、変更される可能性があります。

スマートフォンのChromeでDBSCは使えますか？

2026年10月時点では使えません。ChromeのDBSCはWindowsとmacOS向けで、Googleの担当者は2026年5月の議論でAndroidとiOSへの提供時期は決まっていないと答えています。対応していないブラウザではDBSCの登録ヘッダが無視され、従来のCookieでログインが続きます。

関連記事

• DBSCとは？Chrome・Edge・Firefoxの対応状況とサーバー実装の手順【2026年10月】
• WebAuthnとは？パスキー認証を実装する仕組みと登録・認証フロー・RP実装の要点
• パスキー移行の実装手順：パスワード併存からSignal API・CXPでの鍵移行まで
• FIDO認証・FIDO2とは？仕組みとパスキー・導入判断を解説
• セッション管理とは？セッションIDの発行から失効までの実装と保存先選定を解説