近年、WebAuthnによる認証の記事をよく見かけるようになりました。パスワードレス認証を実現する仕組みとして、注目されていますね。
WebAuthnの「認証」と「登録」に関する記事はよく見かけますが、それ以外の「（登録）解除」や「クレデンシャル情報の紛失」と言ったことに関して説明している記事が少なかったので、W3CのWebAuthnに関するドキュメントをちらっと見てみました。
WebAuthnについて、投稿時点で参考にした資料は以下です。
https://www.w3.org/TR/2020/WD-webauthn-2-20200730/
Decommissioning（解除）について
W３Cのドキュメントに、「Decomissioning（解除）」について記載されています。(Non-normative)
https://www.w3.org/TR/webauthn-2/#sctn-sample-decommissioning
上記リンクの記載によると、解除が望まれるケースとして以下が想定されています。
（もちろん、これ以外のケースも、個々のサービスに応じて検討は必要）
①ユーザーがクレデンシャルを紛失したことを報告
＜処理フロー＞
(1)Webサイトにて認証完了後、「端末の紛失・盗難の報告」と言ったページに進む。
(2)サーバは、ユーザーに紐づくクレデンシャル情報を一覧にしたページを表示
(3)ユーザーは一覧から削除したいクレデンシャル情報を選択
(4)選択されたクレデンシャル情報をサーバ側のデータベースから削除
(5)以降、削除したクレデンシャル情報での認証は不可
上記手順の(1)では、紛失したクレデンシャル以外で認証を行う手段があることを前提としていると思われます。
例として、以下のようなパターンが挙げられます。
・ユーザーに紐づく公開鍵クレデンシャル情報を、複数個サーバに登録している。
・WebAuthn以外の認証方法でもユーザー認証が行える。
②サーバによる不活性なクレデンシャル情報の削除
＜処理フロー＞
(1)サーバのメンテナンス中に、クレデンシャルを削除。
(2)以降、削除したクレデンシャル情報での認証は不可
サーバメンテナンスや定期的に行われるバッチ処理などで、削除条件に該当するクレデンシャル情報を削除するケースですね。
サービスによっては、（後述のように、推奨はされていませんが）ユーザーアカウントとクレデンシャル情報との関連を１対１に制限している場合もあるかもしれません。安易にクレデンシャル情報を削除してしまうと、代替の認証方法がない場合に詰みますので、削除要否も含め検討した方が良さそうです。
個々のサービスの特性や、認証処理の統計情報等を鑑みて、削除対象とする条件を決める必要がありそうです。
③ユーザーによるAuthenticatorからのクレデンシャル情報削除
＜処理フロー＞
(1)Authenticator固有の方法（例：端末の設定画面など）で、ユーザー自らクレデンシャル情報を削除
(2)以降、削除したクレデンシャル情報での認証は不可
※ユーザーが削除したクレデンシャル情報は使用されなくなるので、上記②の運用を行なっている場合、（削除条件により）サーバ側で管理しているクレデンシャル情報も削除される。
Credential Loss（クレデンシャル情報の紛失）
W3Cのドキュメントにて、クレデンシャル情報の紛失について触れられています。
WebAuthnでは、クレデンシャル情報のバックアップや、Authenticator間のクレデンシャル情報の共有については定義されていません。
したがって、ユーザーがRPサーバに対して、1つのクレデンシャル情報しか登録していない場合、Authenticator(認証器）の紛失・機種変更などにより、認証手段も失うこととなります。
これに対し、W3Cのドキュメントでは、「複数のクレデンシャル情報の登録」と「excludeCredentialとuser.idオプションの活用」について述べています。
複数のクレデンシャル情報の登録
Relying Parties SHOULD allow and encourage users to register multiple credentials to the same account.
(https://www.w3.org/TR/webauthn-2/#sctn-credential-loss-key-mobilityより引用)
「一つのアカウントに対し、複数のクレデンシャル情報を登録することをユーザーに促すべきである」
ということですね。
このようにすれば、一つのクレデンシャル情報（Authenticator）を紛失しても、もう一つのクレデンシャル情報を使用して認証することが可能です。
シンプルなテーブル定義としては、「User」テーブルと「Credential」テーブルが１対多の関連となっている形が考えられます。
ただ、全てのユーザーが複数のクレデンシャル情報を登録するのは理想的なケースで、一つのクレデンシャル情報しか登録しないユーザーも多いでしょう。
WebAuthn以外の認証方法が存在する既存のWebサービスの場合、従来からの認証方法（パスワード認証など）によるログインも可能とする、と言った措置も考えられるかもしれません。ただし、WebAuthnがパスワードレス認証を実現する仕組みなのに、ここでパスワードのみによる認証を許可してしまうのは本末転倒です。
なので、クレデンシャル情報登録済みのユーザーが、WebAuthn以外で認証を実施した時は、多要素認証や多段階認証を行うことはユーザーの意思に関わらず必須とした方が良いと思われます。
また、WebAuthn以外の認証方法を事前に許可するかの設定画面などを設けておき、デフォルトではWebAuthn以外は許可しない、といった運用も考えられるかもしれません。
この場合、1つのアカウントに紐づくクレデンシャル情報が1つだけの場合に詰んでしまうので、カスタマーサポートへの窓口案内等の導線を予め用意しておくなど、事前に検討が必要そうです。
excludeCredentialとuser.idオプションの活用
Relying Parties SHOULD make use of the excludeCredentials and user.id options to ensure that these different credentials are bound to different authenticators.
(https://www.w3.org/TR/webauthn-2/#sctn-credential-loss-key-mobilityより引用)
「RPは異なるクレデンシャル情報が、それぞれ異なるAuthenticatorに紐づくことを確かなものとするために、"excludeCredentials"と"user.id"オプションを活用するべきである」
excludeCredentials
excludeCredentialsは、クレデンシャル登録時にRPサーバから返却される情報で、1つのAuthenticatorで同一のアカウントに対するクレデンシャルが複数登録されることを回避するために使用されることを意図したものです。
excludeCredentialsに設定されているクレデンシャルと一致するクレデンシャルがAuthenticatorに既に存在していた時、クライアント（WebブラウザやOSのSDKなど）はエラーを返却することが要求されるものとしています。
user.id
user.idも、クレデンシャル登録時にRPサーバから返却される情報で、RPサーバに登録されるユーザーを識別するための情報として扱われます。
https://www.w3.org/TR/webauthn-2/#dom-publickeycredentialuserentity-id
https://www.w3.org/TR/webauthn-2/#user-handle
excludeCredentialとuser.idについては実際に実装している記事を見た方が早いと思います。
これらのパラメータにより、「ユーザー」の情報と「クレデンシャル」の情報を１対多の関連として実装するために利用することができます。
最後に
WebサービスでWebAuthnを導入するとなると、やはり「（登録）解除」や「クレデンシャル情報の紛失」と言った事項の検討は避けられないと思います。
実際に設計・実装するとなった時に、上記の事項を忘れていると慌てそうなので、やはり事前に考慮しておきたいものです。