WebAuthn Signal API：クライアントサイドでパスキーを更新・削除する

パスキーのエコシステムは進化を続けています。その変化を促進するため、基盤となるWebAuthn標準も急速に進化しています。新しい機能は、多くの場合、まずGitHubの技術的な解説書から始まり、十分に議論された後、標準へのプルリクエストへと発展します。最近、こちらのプルリクエストがWebAuthn Signal APIとして標準ドラフトに追加されました。この記事では、以下の内容について解説します。

• WebAuthn Signal APIが必要な理由： WebAuthn Signal APIはどのようなユースケースをサポートするのでしょうか？
• WebAuthn Signal APIの仕組み： WebAuthn Signal APIは具体的にどのように機能するのでしょうか？リライングパーティへの推奨事項は何でしょうか？

2025年1月時点の更新情報として、WebAuthn Signal APIはChrome 132からデフォルトで有効になっています。以前はReporting APIという名称でしたが、同名の別のAPIとの競合を避けるために改名されました。

WebAuthn Signal APIは、クライアントサイドでのパスキー管理に関する特定のユースケースに対応します。具体的には、リライングパーティ（RP）と、クライアントサイドのオペレーティングシステムの一部である認証器との間で情報を同期させるのに役立ちます。以下のような重要なユースケースがあります。

Subscribe to our Passkeys Substack for the latest news.

Subscribe

パスキーが作成される際、user.id、user.name、user.displayNameといったいくつかの情報が含まれます。パスキー自体は、一意のCredential IDによって識別されます。

• user.id: パスキーがリンクされているアカウントを表す一意の識別子です。このuser.idは、パスキーとユーザーアカウントを実際に照合するために不可欠です。
• user.nameとuser.displayName: これらはユーザーインターフェースでの表示のみに使用されるメタデータです。

以下の図は、どの情報がどのフィールドに通常保存されるかを示す、典型的でシンプルなデータベース構造です。

user.name（多くはメールアドレス）とuser.displayName（より親しみやすく読みやすい名前）は、ユーザーが選択UIで自分のアカウントを識別するのに役立ちますが、パスキーとアカウントの実際の関連付けはuser.idと**Credential ID**によって維持されることを理解することが重要です。

• 1つのアカウントは複数のパスキーを持つことができますが、各パスキーはuser.idを使用して一意に識別され、アカウントと照合されます。
• すべてのパスキー自体には、認証器によって生成される一意のCredential IDがあります。

問題の1つは、メールアドレスであるuser.nameが変更されたときに発生します。現在、この変更をクライアントサイドの認証器で直接更新する仕組みはありません。user.nameは、ユーザーがメールアドレスを更新した場合など、さまざまな理由で変更される可能性があります。サーバー側でアカウントのメタデータが変更されたにもかかわらず、古いuser.nameが資格情報選択UIに表示され続け、ユーザーの混乱を招く可能性があります。

この問題の回避策は、更新されたuser.nameと同一のuser.idで新しいパスキーを作成し、既存のパスキーを上書きすることです。しかし、このアプローチはいくつかの理由で不便です。

1. 冗長性: 各user.idはリライングパーティIDごとに1つのパスキーしか持てないため、古いパスキーを新しいものに置き換える必要があり、余分なステップとなります。
2. ユーザーエクスペリエンス: ユーザーはなぜ新しいパスキーを作成する必要があるのか理解できません。そのため、この回避策は広く使われていません。
3. 複雑さ: メタデータを更新するためだけにパスキーの作成と置き換えを管理するのは、不必要な複雑さです。

メールアドレスや電話番号などの識別子は定期的に変更される可能性があります。user.nameとuser.displayNameを認証器で直接更新する簡単な方法がないと、ユーザーは古いメールアドレスに関連付けられたパスキーを選択しなければならないという根強い問題に直面するかもしれません。この状況は、パスキーが目指すシームレスな体験を損ないます。WebAuthn Signal APIは、新しいパスキーを作成することなく、リライングパーティがパスキーのメタデータの更新を報告できるようにすることで、この問題を解決することを目指しています。Signal APIの実装方法を説明する前に、それが対応する2つ目の重要なユースケースを見ていきましょう。

Become part of our Passkeys Community for updates & support.

Join

もう1つの重要なユースケースは、クライアントサイドの認証器でのパスキーの削除です。時間が経つにつれて、ユーザーはパスキー管理リストから資格情報を失効させたり、アカウントを削除したりすることがあります。その際、これらの資格情報が将来の資格情報選択UI（条件付きUI / パスキーの自動入力）に表示されないように、クライアントサイドの認証器から削除されるようにすることが必要になります。

この機能の必要性は、いくつかのシナリオで生じます。

1. アカウント設定からのパスキー削除: ユーザーがアカウント設定から明示的に資格情報を削除した場合など、資格情報が有効でなくなったとき。

ユーザーの視点からすると、上記のようなダイアログでアカウント設定を削除しても、このクライアント上のパスキーが削除されないことは理解しがたいです。

2. アカウントの削除: ユーザーがアカウントを削除した場合、関連するすべてのパスキーも削除されるべきです。
3. セキュリティポリシー: リライングパーティは、長期間の非アクティブ状態や検出されたセキュリティ問題により、資格情報の失効を要求するセキュリティポリシーを持っている場合があります。

クライアントサイドでパスキーを直接削除する方法がないと、これらの古くなった、または無効な資格情報が選択UIを煩雑にし続け、混乱を招きます。ユーザーはもはや有効でないパスキーを見て使用しようとし、認証の失敗やユーザーエクスペリエンスの低下につながる可能性があります。

WebAuthn Signal APIを実装するには、機能が正しく安全に統合されるように、いくつかのステップと考慮事項が必要です。Signal APIを使用すると、リライングパーティ（RP）はクライアントサイドの認証器でパスキー資格情報を更新または削除できます。このセクションでは、実装のための主要な考慮事項と手順を概説します。

WebAuthn Signal APIを実装する際には、以下の考慮事項を念頭に置くことが重要です。

• プライバシーの保護: WebAuthn Signal APIは、WebAuthnの基盤の1つであるユーザーのプライバシーを保護するように設計されています。これは、要求された変更が処理されたかどうかについてRPにフィードバックが提供されないことを意味します。APIは、資格情報の状態に関する情報の漏洩を防ぐために、静かに動作します。

• 認証器の可用性: WebAuthn Signal APIの有効性は、認証器の可用性に依存します。これには、物理的な可用性（例：セキュリティキーの存在）とソフトウェアのサポート（例：ブラウザとオペレーティングシステムの互換性）の両方が含まれます。認証器がアクセス可能で、生体認証を必要とせずに必要な操作をサポートしている場合にのみ、ブラウザはアクションを実行できます。

• ドメインの制限: APIは、特定のドメインに関連付けられたリライングパーティのみが、そのドメインに関連する資格情報の変更を要求できるようにします。これは、第三者による不正な変更を防ぐためのセキュリティ対策です。

• キーとしてのCredential ID: パスキーを参照する際、Credential IDはWebAuthn Signal APIが使用する主キーです。このIDは、クライアントサイドの認証器でパスキーを一意に識別します。APIを使用すると、RPはパスキーに関連付けられたメタデータを変更したり、特定のパスキーにアクセスできなくすべきであることを通知したりできますが、それはCredential IDを介してのみです。特定のCredential IDを認証器が知らない場合、それは静かに無視されます。

これらの考慮事項は、WebAuthn Signal APIが正しく機能するための最も重要な側面を理解するために不可欠です。

WebAuthn Signal APIは、リライングパーティ（RP）がクライアントサイドの認証器でパスキーに関連付けられたメタデータを更新するための合理化されたメカニズムを提供します。これは、ユーザーが不必要に新しいパスキーを作成することなく、資格情報選択UIで正確かつ最新の情報を確認できるようにするために特に重要です。APIがこれをどのように可能にするかを以下に示します。

signalCurrentUserDetails(options)によるメタデータの更新

Signal APIのsignalCurrentUserDetails(options)メソッドは、パスキーのメタデータを更新するために特別に設計されています。このメソッドにより、RPはuser.nameとuser.displayNameの現在の値を提供できます。

プロセスの仕組みは次のとおりです（WebAuthn Level 3標準も参照してください）。

1. メソッドの構造: signalCurrentUserDetails(options)メソッドには、rp.id、user.id、およびuser.nameとuser.displayNameの更新された値が含まれます。

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    name: "New user name",
    displayName: "New display name",
});

2. ローカルメタデータの更新: rpIdとuserIdに一致する、ローカル（認証器上）で利用可能な資格情報を探します。一致するすべての資格情報について、認証器は資格情報のnameとdisplayNameを更新します。

3. プライバシーの保護: このプロセスはプライバシーを保護するように設計されています。Signal APIは、更新が正常に処理されたかどうかについてRPにフィードバックを提供しないため、資格情報の状態に関する情報の漏洩を防ぎます。

4. デバイス間での一貫性: signalCurrentUserDetails(options)メソッドを定期的に実行することで、RPはユーザーが認証する可能性のあるさまざまなデバイスやプラットフォーム間でパスキーのメタデータの一貫性を確保できます。このアプローチにより、古くなった、または不正確な情報が資格情報選択UIに表示される可能性が減少します。

上のスクリーンショットでは、Google Chromeがユーザーにこのような更新をどのように通知するかがわかります。WebAuthn Signal APIはChrome 130の一部であり、試験運用版のウェブ プラットフォームの機能を有効にすると、デスクトップのGoogleパスワードマネージャーでテストできます。

WebAuthn Signal APIは、リライングパーティ（RP）がクライアントサイドの認証器からのパスキーの削除を通知するためのメカニズムを提供します。これは、古くなった、または無効な資格情報が資格情報選択UIに表示されないようにし、合理化された安全なユーザーエクスペリエンスを維持するために不可欠です。パスキーをローカルで削除するには、signalUnknownCredential(options)とsignalAllAcceptedCredentials)(options)の2つのメソッドがあります。前者はユーザーが認証されていない状況で使用でき、後者はユーザーが認証されている場合に使用できます。したがって、プライバシー上の理由から後者の方が推奨されます。

2つのメソッドの仕組みは次のとおりです。

1. メソッドの構造: signalUnknownCredential(options)メソッドには、rpId（リライングパーティID）とcredentialId（削除する資格情報の一意の識別子）が含まれます。

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc", // credential id the user just tried, base64url
});

2. メソッドの呼び出し: RPは、資格情報を削除すべきだと検出したらいつでもこのメソッドを呼び出します。これは、無効な資格情報での認証試行の直後、アカウント削除時、またはユーザーがアカウント設定を通じて資格情報を失効させたときなどです。

3. メソッドの処理: signalUnknownCredential(options)メソッドが呼び出されると、クライアントサイドの認証器は、指定されたrpIdとcredentialIDに一致する資格情報を探し、除外しようとします。認証器の機能に応じて、資格情報は削除されるか、将来の認証セレモニーで資格情報を非表示にするための認証器固有の手順が採用されます。

1. メソッドの構造: signalAllAcceptedCredentials(options)メソッドには、rpId（リライングパーティID）、userId、および有効なCredential IDのリストallAcceptedCredentialIds（保持すべき資格情報の一意の識別子のリスト）が含まれます。

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    allAcceptedCredentialIds: ["bb"],
});

2. メソッドの呼び出し: RPは、資格情報を削除すべきだと検出し、有効な資格情報のリストを通知する必要がある場合にこのメソッドを呼び出します。資格情報を削除するには、signalUnknownCredential(options)よりもこのメソッドが推奨されます。

3. メソッドの処理: signalAllAcceptedCredentials(options)メソッドが呼び出されると、クライアントサイドの認証器はrpIdとuserIdを照合します。認証器は、rpIdとuserIdに一致するすべてのローカル資格情報を検索します。その結果をallAcceptedCredentialIdsと比較します。allAcceptedCredentialIdsに含まれていないローカル資格情報がある場合、それらの資格情報はローカルで削除されます（または認証器に応じて非表示になります）。

4. 資格情報の再表示: （認証器によっては）資格情報が非表示にされているだけで、今回allAcceptedCredentialIdsに含まれている場合、それらの資格情報は将来の認証セレモニーで再び表示されるようになります。

5. 役立つヒント:

   • signalAllAcceptedCredentials(options)を使用する場合、このメソッドが実行されるときに認証器が常に接続されているとは限らないことに注意することが重要です。そのため、リライングパーティは、すべての資格情報が最新であることを保証するために、サインインごとなど、定期的にsignalAllAcceptedCredentials(options)を実行することを検討するかもしれません。
   • リライングパーティは、資格情報IDのリスト（allAcceptedCredentialIds）を指定する際に注意が必要です。このリストに含まれていない資格情報は、認証器によって非表示または削除される可能性があり、元に戻せない場合もあります。有効な資格情報が誤って省略されるのを防ぐために、リストが完全であることを確認することが不可欠です。有効な資格情報IDが誤って除外された場合は、認証器がこれをサポートしていると仮定して、できるだけ早くsignalAllAcceptedCredentials(options)に再追加して、再び表示されるようにする必要があります。
   • 可能な限り、認証器は資格情報を完全に削除するのではなく、一時的に非表示にすることを優先すべきです。このアプローチは、リライングパーティによって有効な資格情報IDが誤って省略された場合に回復を容易にし、永久的な損失なしに復元できるようにするのに役立ちます。

上のスクリーンショットでは、Google Chromeが削除をどのように通知するかがわかります。WebAuthn Signal APIはChrome 132の一部であり、デスクトップのGoogleパスワードマネージャーでテストできます。

WebAuthn Signal APIを効果的に実装し、クライアントサイドの認証器間でパスキーメタデータのシームレスな同期を確保するために、以下の推奨事項を検討してください。

• WebAuthn Signal APIの更新と実際の実装に注意する: Signal APIに関連する最新の開発と更新について常に情報を入手してください。WebAuthn Signal APIはGoogle Chrome 132で有効になり、他のブラウザ（例：Safariもサポートを表明）がそれに続きます。WebAuthn Signal APIの進捗と更新を定期的に確認し、実装が最新の標準と実践に沿っていることを確認してください。このブログ記事は、2025年1月14日時点で入手可能な情報に基づいており、将来的に更新される予定です。
• すべての成功したログイン後にsignalAllAcceptedCredentials(options)アプローチから始める: このアプローチは、すべてのメタデータと資格情報IDが単一のメソッドで更新されることを保証し、プロセスを簡素化し、デバイスやプラットフォーム間での一貫性を維持し、同時に削除されたまたは古い資格情報を無効化します。
• 大規模なデプロイメントでのsignalUnknownCredential(options)によるリアルタイムメッセージング: 大規模なデプロイメントや即時の更新が必要な場合は、signalUnknownCredential(options)メソッドによるリアルタイムメッセージングの使用を検討してください。このメソッドは、資格情報管理の効率と正確性を向上させ、無効または古い資格情報が選択UIから迅速に削除されることを保証します。

これらの推奨事項に従うことで、WebAuthn Signal APIがサポートされ次第、効果的に実装でき、パスキーのメタデータがすべてのクライアントサイドの認証器で最新かつ一貫性を保ち、それによってパスキーのためのスムーズで安全なユーザーエクスペリエンスを提供できます。

WebAuthn標準は継続的に進化しており、月単位で機能が豊富になっています。WebAuthn Signal APIの導入は、クライアントサイドの認証器でのパスキーのメタデータ管理と削除において大きな一歩です。このAPIは、リライングパーティ（RP）と認証器との間で情報を同期させ、無効または古いパスキーを削除することでユーザーエクスペリエンスを向上させるという重要なユースケースに対応します。

• Signal APIが必要な理由 Signal APIは、クライアントサイドの認証器でパスキーのメタデータを更新し、パスキーを削除するために不可欠です。これにより、選択UIで資格情報が表示される際に混乱を招く可能性のある、古くなったuser.nameやuser.displayName情報に関する問題が解決されます。さらに、失効または削除されたパスキーを削除することで、クリーンで安全な資格情報選択インターフェースを維持するのに役立ちます。
• Signal APIの仕組み Signal APIは、RPがメタデータの更新やパスキーの削除の通知など、資格情報の現在の状態に関するメソッドを呼び出すことで機能します。これらのレポートはクライアントサイドの認証器によって処理され、ユーザーに提示される情報が正確で最新であることが保証されます。APIはプライバシーを保護するように設計されており、更新の成功についてRPにフィードバックを提供することなく動作します。

WebAuthn標準が進化するにつれて、標準のさまざまな部分を前進させる参加者の多様な関心事から恩恵を受けています。これらの動向に注目することは、最新の機能強化について常に最新の情報を入手し、実装が最新のベストプラクティスと標準に沿っていることを確認するために不可欠です。WebAuthnコミュニティは革新を推進し続け、認証をより安全でユーザーフレンドリーなものにしています。