W3C

Web認証：
公開鍵資格情報へアクセスするためのAPI
レベル2

W3C勧告,

このバージョン:
https://www.w3.org/TR/2021/REC-webauthn-2-20210408/
最新公開バージョン:
https://www.w3.org/TR/webauthn-2/
編集者ドラフト:
https://w3c.github.io/webauthn/
以前のバージョン:
実装報告書:
https://www.w3.org/2020/12/webauthn-report.html
課題追跡:
GitHub
編集者:
(Google)
(Mozilla)
(Microsoft)
(Microsoft)
(Yubico)
元編集者:
(Google)
(Microsoft)
(Google)
(Google)
(PayPal)
(Microsoft)
(Nok Nok Labs)
協力者:
John Bradley (Yubico)
Christiaan Brand (Google)
Adam Langley (Google)
Giridhar Mandyam (Qualcomm)
Nina Satragno (Google)
Nick Steele (Gemini)
Jiewen Tan (Apple)
Shane Weeden (IBM)
Mike West (Google)
Jeffrey Yasskin (Google)
テスト:
web-platform-tests webauthn/ (継続的な作業)

公開後に報告されたエラーや問題については、正誤表をご確認ください。

Copyright © 2021 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.

概要

本仕様は、ウェブアプリケーションによるユーザーの強力な認証を目的として、強力で証明可能なスコープされた公開鍵ベースの資格情報の作成および利用を可能にするAPIを定義します。概念的には、1つ以上の公開鍵資格情報が、指定されたWebAuthnリライングパーティにスコープされ、ウェブアプリケーションの要求に応じて認証器によって作成され、紐付けられます。ユーザーエージェントは、ユーザーのプライバシーを保護するために認証器およびその公開鍵資格情報へのアクセスを仲介します。 認証器は、ユーザーの同意がない限り、いかなる操作も行わないことを保証する責任を負います。 認証器は、証明を通じて、 リライングパーティに対して自身の特性の暗号的な証明を提供します。 本仕様はまた、WebAuthn準拠の認証器の機能モデルについても説明しており、 署名や証明機能を含みます。

この文書のステータス

このセクションは、本書が公開された時点でのステータスを記載しています。他の文書が本書に取って代わる場合があります。 現行のW3C出版物および最新の技術レポートは、 W3C技術レポート一覧（https://www.w3.org/TR/）でご確認いただけます。

本書はWeb認証ワーキンググループによって勧告として公開されました。

本仕様へのフィードバックやコメントは歓迎します。 Githubのイシューをご利用ください。 また、議論はpublic-webauthn@w3.orgアーカイブでもご覧いただけます。

W3C勧告とは、広範なコンセンサス形成の後、W3Cおよびその会員の承認を得た仕様です。W3Cは本仕様のWeb標準としての幅広い普及を推奨します。

本書はW3C会員、ソフトウェア開発者、 その他のW3Cグループや関係者によってレビューされ、 ディレクターによってW3C勧告として承認されています。 安定した文書であり、他の文書から参考資料として利用したり引用することができます。 W3Cが勧告を作成する役割は、 仕様に注意を喚起し、その普及を促進することです。これによりWebの機能性と相互運用性が向上します。

本書は 2017年8月1日W3C特許ポリシーの下で運営されるグループによって作成されました。 W3Cは、 グループの成果物に関連して公開された特許情報のリストを維持しており、 そのページには特許開示方法も記載されています。 ある個人が本仕様に関して 必須特許請求を含むと考えられる特許を知っている場合は、 W3C特許ポリシー第6節に従って開示しなければなりません。

本書は2020年9月15日W3Cプロセス文書に従って管理されています。

1. はじめに

このセクションは規範的内容ではありません。

本仕様は、ウェブアプリケーションによってユーザーを強力に認証することを目的とした、強力で証明可能かつスコープされた公開鍵ベースの資格情報の作成と利用を可能にするAPIを定義します。公開鍵資格情報は、WebAuthn認証器によって、WebAuthnリライングパーティの要求に応じ、ユーザーの同意のもとで作成・保存されます。その後、公開鍵資格情報は、そのオリジンが所属するリライングパーティのみがアクセス可能です。 このスコープは、適合ユーザーエージェントと認証器が共同で強制します。 さらに、リライングパーティ間のプライバシーも維持されます。リライングパーティは、他のスコープされたリライングパーティに属する資格情報の特性や存在を検出できません。

リライングパーティは、ユーザーを含む2つの異なるが関連する認証手続きにおいてWeb認証APIを利用します。最初は登録であり、公開鍵資格情報が認証器上で作成され、現在のユーザーのアカウント（既存の場合も新規の場合もある）にスコープされます。2つ目は認証であり、リライングパーティに対して、登録された公開鍵資格情報の存在およびユーザーの同意を証明する認証アサーションが提示されます。機能的には、Web認証APIは、Credential Management API [CREDENTIAL-MANAGEMENT-1]を拡張するPublicKeyCredentialと、 それらの資格情報をnavigator.credentials.create()およびnavigator.credentials.get()で利用可能にするインフラから成ります。 前者は登録の際に、後者は認証の際に使用されます。

概ね、適合する認証器は公開鍵資格情報を保護し、ユーザーエージェントと対話してWeb認証APIを実装します。 適合認証器の実装は、次のいずれかのソフトウェア環境で可能です： (a) 汎用計算デバイス上、 (b) デバイス内のセキュア実行環境、Trusted Platform Module (TPM)、またはセキュアエレメント (SE) 上、 (c) デバイス外部。 デバイス上で実装される認証器はプラットフォーム認証器と呼ばれます。 デバイス外部で実装される認証器（ローミング認証器）は、USB、Bluetooth Low Energy（BLE）、または近距離無線通信（NFC）などのトランスポートを介してアクセスされます。

1.1. 仕様のロードマップ

多くのW3C仕様は主にユーザーエージェント開発者やウェブアプリケーション開発者（すなわち「Web著者」）向けですが、Web認証の性質上、本仕様は複数の読者が正しく利用する必要があります。以下に説明します。

全ての読者はまず§ 1.2 ユースケース、§ 1.3 API利用例、§ 4 用語を参照し、全般的なチュートリアルとして[WebAuthnAPIGuide]も参考にしてください。 その上で、本書の主な読者層は次のグループです：

注：Web認証API本体に加え、本仕様はリクエスト-レスポンス型の暗号プロトコル—WebAuthn/FIDO2プロトコル—を定義します。 これは、WebAuthnリライングパーティサーバーと認証器間で、リライングパーティのリクエストがチャレンジ等の入力データとしてリライングパーティから認証器へ送信されます。 リクエストはHTTPS、リライングパーティのウェブアプリケーション、WebAuthn API、ユーザーエージェントと認証器間のプラットフォーム固有の通信チャネルによって伝達されます。 認証器は、デジタル署名付きの認証器データメッセージおよびその他の出力データで応答し、それは逆経路でリライングパーティサーバーに返送されます。プロトコルの詳細は、認証または登録操作がリライングパーティによって呼び出されるかによって異なります。 図1および図2も参照してください。

Web認証の導入におけるエンドツーエンドのセキュリティのために重要なのは、各コンポーネント（リライングパーティサーバー、クライアント、認証器）の役割、 そして§ 13 セキュリティに関する考慮事項および§ 14 プライバシーに関する考慮事項が、全ての読者によって理解されていることです。

1.2. ユースケース

以下のユースケースシナリオは、2種類の異なる認証器の利用例を示すとともに、さらに他のシナリオも概説します。追加のシナリオ（サンプルコード含む）は§ 1.3 API利用例で後述します。

1.2.1. 登録

1.2.2. 認証

1.2.3. 新規デバイス登録

このユースケースは、リライングパーティがローミング認証器（例：USBセキュリティキー）、プラットフォーム認証器（例：内蔵指紋センサー）の組み合わせを利用して、ユーザーが次の点を持つことを示します：

注：アカウントに複数の認証器を登録するアプローチは、アカウント復旧にも有用です。

1.2.4. その他のユースケース・構成例

他にも様々なユースケースや構成が可能です（一例）：

1.3. API利用例シナリオ

このセクションは規範的内容ではありません。

このセクションでは、公開鍵資格情報のライフサイクルにおけるいくつかのイベントと、それに対応したAPI利用サンプルコードを紹介します。これは一例の流れであり、APIの利用範囲を限定するものではありません。

前節同様、この流れは独自のディスプレイを持つ一次要素ローミング認証器（例：スマートフォン）を使ったユースケースに焦点を当てています。他の認証器タイプも、クライアントプラットフォームの実装次第でサポートされます。たとえば、クライアントデバイスに組み込まれた認証器や、ディスプレイを持たない認証器（スマートカード等）にも修正なく適用可能です。後者の場合、クライアントプラットフォームが認証器の代わりにプロンプトを表示し、認証器がクライアントプラットフォームによる資格情報の列挙を許可する必要があります。

1.3.1. 登録

これは初回の流れで、新しい資格情報が作成されてサーバーに登録されます。 この流れでは、WebAuthnリライングパーティはプラットフォーム認証器とローミング認証器のいずれかにこだわりません。

  1. ユーザーがexample.comにアクセスし、スクリプトが提供されます。この時点でユーザーは従来のユーザー名・パスワードや追加認証器、他の方法で既にログインしている場合もあり、新規アカウント作成中の場合もあります。

  2. リライングパーティのスクリプトが以下のコードスニペットを実行します。

  3. クライアントプラットフォームが認証器を検索して発見します。

  4. クライアントが認証器に接続し、必要ならペアリング操作を行います。

  5. 認証器がユーザーに生体認証やその他の認可ジェスチャ入力用のUIを表示します。

  6. 認証器がクライアントにレスポンスを返し、クライアントはさらにリライングパーティのスクリプトにレスポンスを返します。ユーザーが認証器選択や認可を拒否した場合はエラーが返ります。

  7. 新しい資格情報が作成された場合：

    • リライングパーティのスクリプトが、生成された資格情報公開鍵と、認証器の出自や特性に関する証明情報をサーバーに送信します。

    • サーバーが資格情報公開鍵をデータベースに保存し、ユーザーおよび認証の特性（証明情報による）と紐付けて保管し、後で使うための表示名も保存します。

    • スクリプトが資格情報IDなどをローカルストレージに保存し、将来のUX向上のためユーザーの資格情報選択肢を絞り込みます。

新しい鍵を生成・登録するサンプルコード：

（コードは翻訳しません）

1.3.2. ユーザー検証型プラットフォーム認証器による登録

これはWebAuthnリライングパーティが、ユーザー検証型プラットフォーム認証器を用いて公開鍵資格情報を作成したい場合の例です。

  1. ユーザーがexample.comにアクセスし、ログインボタンをクリックするとlogin.example.comにリダイレクトされます。

  2. ユーザーがユーザー名とパスワードを入力してログインし、成功後example.comに戻ります。

  3. リライングパーティのスクリプトが下記のコードスニペットを実行します。

    1. ユーザーエージェントがユーザー検証型プラットフォーム認証器の利用可否を確認し、なければこの流れを終了します。

    2. リライングパーティが、資格情報の作成希望をユーザーに確認し、希望しなければ終了します。

    3. ユーザーエージェントやOSが適切なUIを表示し、利用可能なプラットフォーム認証器で資格情報作成を案内します。

    4. 資格情報作成成功時、リライングパーティのスクリプトが新資格情報をサーバーに送信します。

（コードは翻訳しません）

1.3.3. 認証

これは既に資格情報を登録済みのユーザーがウェブサイトにアクセスし、その資格情報で認証したい場合の流れです。

  1. ユーザーがexample.comにアクセスし、スクリプトが提供されます。

  2. スクリプトがクライアントに認証アサーションを要求し、可能な限り条件を絞ってユーザーが選択しやすくします。これは登録後にローカル保存したデータや、ユーザー名入力などで得られます。

  3. リライングパーティのスクリプトが下記コード例を実行します。

  4. クライアントプラットフォームが認証器を検索して発見します。

  5. クライアントが認証器に接続し、必要ならペアリング操作を行います。

  6. 認証器がユーザーに通知で注意を促し、開くと資格情報作成時のアカウント情報やリクエスト元オリジンなどを含む選択メニューを表示します。

  7. 認証器がユーザーから生体認証やその他の認可ジェスチャを取得します。

  8. 認証器がクライアントにレスポンスを返し、クライアントはさらにリライングパーティのスクリプトにレスポンスを返します。ユーザーが資格情報選択や認可を拒否した場合は適切なエラーが返ります。

  9. アサーションが正常に生成・返却された場合：

    • スクリプトがアサーションをサーバーに送信します。

    • サーバーがアサーションを検証し、資格情報IDを抽出、データベースから登録済み公開鍵を検索し、アサーション署名を検証します。有効ならアサーションの資格情報IDに紐付いたIDを認証します。IDが認識されない場合（例：長期未使用で削除済み）認証失敗となります。リライングパーティは状況に応じた処理を行います。

    • サーバーは認証成功時に通常の処理（成功ページ表示、認証クッキー設定等）を行います。

リライングパーティのスクリプトが条件絞り込み用のヒント（例：ローカル保存データ）がない場合、認証例コードは以下のようになります：

（コードは翻訳しません）

逆に、リライングパーティのスクリプトに絞り込み用ヒントがある場合、認証例コードは以下の通りです。この例では資格情報プロパティ拡張の使い方も示しています。

（コードは翻訳しません）

1.3.4. 認証操作の中断

以下は、開発者がAbortSignalパラメータを使って資格情報登録操作を中断する方法の例です。同様の手順は認証操作にも適用できます。

（コードは翻訳しません）

1.3.5. 廃止

以下は資格情報廃止が望まれる可能性のある状況例です。これらはすべてサーバー側で処理され、本APIのサポートは不要です。

1.4. プラットフォーム固有の実装ガイダンス

本仕様はWeb認証の一般的な利用方法を定義しています。Web認証を特定プラットフォーム（例：アプリ）と組み合わせて使用する場合は、追加のガイダンスや制約についてプラットフォーム固有のドキュメント・ガイドを参照することを推奨します。

2. 適合性

本仕様は3つの適合クラスを定義します。各クラスは、他の非適合または敵対的なクラスのメンバーに対しても安全となるように規定されています。

2.1. ユーザーエージェント

ユーザーエージェントは、§ 5 Web認証APIに記載された通りに動作しなければ、適合とみなされません。適合ユーザーエージェントは、本仕様のアルゴリズムと同等の結果が得られる限り、任意の方法でアルゴリズムを実装してもかまいません。

適合ユーザーエージェントはまた、「Web IDL」仕様に記載されている本仕様のIDLフラグメントの適合実装でなければなりません。[WebIDL]

2.1.1. DOMString型としての列挙型との互換性

列挙型は、他のWeb IDLの部分で参照されません。これは、この仕様や実装を更新せずとも他の値を利用できるようにするためです。後方互換性を保つため、クライアントプラットフォームおよびリライングパーティは未知の値を扱えることが重要です。 本仕様の列挙型はドキュメントおよびレジストリの目的で存在します。列挙型が他所で表現される場合は、例えばDOMString型として扱います。 例：transportsなど。

2.2. 認証器

WebAuthn認証器は、§ 6 WebAuthn認証器モデルで定義された操作を提供しなければならず、これらの操作は同節で規定された通りに動作しなければなりません。これは認証器が適合ユーザーエージェントで利用可能となるための機能・セキュリティ要件です。

§ 1.2 ユースケースで説明した通り、認証器はユーザーエージェントの基盤となるOS内や外部ハードウェア、あるいはその組み合わせで実装可能です。

2.2.1. FIDO U2Fとの互換性

認証器が§ 8.6 FIDO U2F証明書明文フォーマットのみをサポートする場合、userHandleを保存する仕組みがないため、返されるuserHandleは常にnullとなります。

2.3. WebAuthnリライングパーティ

WebAuthnリライングパーティは、§ 7 WebAuthnリライングパーティの操作に記載された通りに動作し、本仕様が提供するすべてのセキュリティメリットを享受しなければなりません。詳細は§ 13.4.1 WebAuthnリライングパーティのセキュリティメリットも参照してください。

2.4. すべての適合クラス

上記の適合クラスのメンバーによるCBORエンコーディングはすべて、CTAP2標準CBORエンコーディング形式で行わなければなりません。 上記適合クラスのデコーダーは、CTAP2標準CBORエンコーディング形式で有効にエンコードされていないCBORや重複するマップキーを持つメッセージを拒否することが推奨されます。

3. 依存関係

本仕様はいくつかの他の基礎仕様に依存しています。下記および他仕様で定義されている用語を参照してください。

Base64urlエンコーディング

Base64urlエンコーディングは、[RFC4648]の第5節で定義されたURL・ファイル名安全な文字セットによるbase64エンコーディングを指します。末尾の'='はすべて除去し（第3.2節参照）、改行・空白・その他余分な文字は含みません。

CBOR

本仕様のいくつかの構造体（証明書明文・拡張等）は、Compact Binary Object Representation（CBOR）[RFC8949]のCTAP2標準CBORエンコーディング形式でエンコードされます。定義は[FIDO-CTAP]参照。

CDDL

本仕様はすべてのCBORエンコードデータの構文をCBOR Data Definition Language（CDDL）[RFC8610]で記述します。

COSE

CBOR Object Signing and Encryption (COSE) [RFC8152]。この仕様で確立されたIANA COSEアルゴリズムレジストリ[IANA-COSE-ALGS-REG]も利用します。

資格情報管理

本書で記載されたAPIは、Credential概念の拡張です（[CREDENTIAL-MANAGEMENT-1]参照）。

DOM

DOMExceptionおよび本仕様で利用されるDOMException値は[DOM4]で定義されています。

ECMAScript

%ArrayBuffer%は[ECMAScript]で定義されています。

HTML

閲覧コンテキスト、オリジン、不透明オリジン、タプルオリジン、関連設定オブジェクト、 登録可能ドメインサフィックスまたは等価の概念は[HTML]で定義されています。

URL

Same Siteの概念は[URL]で定義されています。

Web IDL

本仕様の多くのインターフェース定義やIDLは[WebIDL]に依存しています。このWeb IDL標準の更新版はPromiseサポートが追加され、非同期操作の推奨手法となっています。

FIDO AppID

呼び出しアプリケーションのFacetID判定およびFacetIDがAppIDに認可されているかの判定（AppID拡張のみで使用）は[FIDO-APPID]で定義されています。

本書の「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」のキーワードは、[RFC2119]の定義に従って解釈されます。

4. 用語集

証明

一般的に、証明は、証人となり、確認や認証を行うための陳述です。WebAuthnの文脈では、証明は、認証器とその出力データの出自を証明するために使用されます。例えば、資格情報ID、資格情報鍵ペア、署名カウンター等が含まれます。証明文は証明オブジェクトにより登録時に伝達されます。詳細は§ 6.5 証明や図6を参照してください。クライアントが証明文とAAGUID部分を証明オブジェクトからリライングパーティへ伝達するかは証明伝達で規定されます。

証明書証明書

認証鍵ペアのためのX.509証明書であり、認証器がその製造および機能を証明するために使用します。登録時、認証器は認証プライベートキーを利用して、Relying Party固有の認証情報公開鍵（および追加データ）に署名し、authenticatorMakeCredential操作を通じて生成・返却します。Relying Partyは、認証公開鍵が認証証明書で伝達されることで、認証署名を検証できます。なお、自己認証の場合、認証器は独立した認証鍵ペアや認証証明書を持ちません。詳細は自己認証を参照してください。

認証
認証セレモニー

セレモニーの一種で、ユーザーとユーザーのクライアント（少なくとも一つの認証器を含む）が協調し、リライングパーティに対して、ユーザーが以前登録した資格情報プライベートキーを制御していることを暗号的に証明します（登録参照）。この過程にはユーザー存在テストやユーザー検証が含まれます。

WebAuthnの認証セレモニーは§ 7.2 認証アサーションの検証で定義され、リライングパーティがnavigator.credentials.get()をpublicKey引数付きで呼び出すことで開始されます。 § 5 Web認証APIや§ 1.3.3 認証に概要と実装例があります。

認証アサーション
アサーション

暗号署名されたAuthenticatorAssertionResponseオブジェクトで、認証器がauthenticatorGetAssertion操作の結果として返します。

これは[CREDENTIAL-MANAGEMENT-1]仕様の単回使用資格情報に該当します。

認証器
WebAuthn認証器

ハードウェアまたはソフトウェアに存在する暗号エンティティで、特定のリライングパーティにユーザーを登録し、後に登録済み公開鍵資格情報の所有を証明でき、必要に応じてユーザー検証も行います。認証器は証明で自身の型やセキュリティ特性を登録時に報告できます。

WebAuthn認証器はローミング認証器やクライアントデバイス統合専用ハードウェア、クライアントデバイスのソフトウェアコンポーネント等で実装可能です。

一般的に、認証器は1ユーザー専用と想定されます。複数の自然人が1つの認証器を共有する場合、その認証器上のユーザーは同一とみなされます。もし認証器実装が分離された複数ユーザーに対応する場合、各区画は独立した認証器（1ユーザーのみアクセス可能）とみなされ、他区画の資格情報にはアクセスできません。

認可ジェスチャ

認可ジェスチャは、ユーザーが認証器と物理的にインタラクションする動作で、セレモニー（登録や認証等）の一部です。このような認可ジェスチャによって、ユーザーは同意（=セレモニーへの認可）を示します。認証器が対応していればユーザー検証も含みます。単純なユーザー存在テストの場合もあります。

生体認証

生物学的・行動的特徴に基づいて個人を自動認識すること。[ISOBiometricVocabulary]参照。

生体認証器

生体認証を実装する認証器。

紐付け資格情報

公開鍵資格情報ソースや公開鍵資格情報が、その管理認証器に紐付けられている状態を指します。つまり、それらの管理認証器のみが、紐付けられた公開鍵資格情報ソースのアサーションを生成できます。

セレモニー

セレモニーの概念は、ネットワークプロトコルの拡張であり、計算ノードだけでなく人間ノードも含み、UIや人間同士のコミュニケーション、物理的なデータの移動なども通信リンクに含みます。プロトコルの範囲外のものもセレモニーの範囲内となります。本仕様では登録や認証がセレモニーであり、認可ジェスチャはその一部となることが多いです。

クライアント
WebAuthnクライアント

本仕様では単にクライアントとも呼びます。適合ユーザーエージェントも参照。WebAuthnクライアントは通常ユーザーエージェント内で実装される中間エンティティです。概念的にはWeb認証APIの基盤であり、[[Create]](origin, options, sameOriginWithAncestors)や[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)内部メソッドを具現化します。基盤となる認証器操作の入力を組み立て、結果をWeb認証API呼び出し元に返す責任があります。

WebAuthnクライアントはWebAuthnクライアントデバイス上で動作し、両者は区別されます。

クライアントデバイス
WebAuthnクライアントデバイス

WebAuthnクライアントが動作するハードウェア機器（例：スマートフォン、ノートPC、デスクトップPC）及びその上で動作するOS。

WebAuthnクライアントデバイスとクライアントの違い：

クライアントデバイスとクライアントを合わせてクライアントプラットフォームを構成します。

クライアントプラットフォーム

クライアントデバイスとクライアントを合わせてクライアントプラットフォームとなります。一つのハードウェア機器は、異なるOSやクライアントを動かすことで、異なるクライアントプラットフォームとなる場合があります。

クライアント側

一般的には、ユーザーのクライアントプラットフォーム、認証器、それらをつなぐ全ての要素の総称です。

クライアント側発見可能公開鍵資格情報ソース
クライアント側発見可能資格情報
発見可能資格情報
[DEPRECATED] レジデント資格情報
[DEPRECATED] レジデントキー

注：歴史的に、クライアント側発見可能資格情報はレジデント資格情報やレジデントキーと呼ばれてきました。ResidentKeyやresidentKeyはWebAuthn APIや認証器モデル（辞書メンバー名やアルゴリズム変数名、操作パラメータ等）で広く使われているため、互換性維持のため名称変更していません。また、レジデントキーはここでクライアント側発見可能資格情報と同義です。

クライアント側発見可能公開鍵資格情報ソース、略して発見可能資格情報は、公開鍵資格情報ソースであり、発見可能であり、認証セレモニーにおいてリライングパーティが資格情報IDを指定しない場合に利用できます。つまり、リライングパーティがnavigator.credentials.get()を空のallowCredentials引数で呼び出す場合です。このためリライングパーティ側で事前にユーザー識別は必須ではありません。

結果として、発見可能資格情報対応の認証器は、RP IDのみで発見可能資格情報のアサーション署名を生成でき、公開鍵資格情報ソースが認証器またはクライアントプラットフォームに保存される必要があります。これはサーバ側公開鍵資格情報ソースとは対照的で、後者は認証器にRP IDと資格情報ID両方を渡す必要があり、公開鍵資格情報ソースはクライアント側保存不要です。

参照：クライアント側資格情報保存方式、非発見可能資格情報。

注：クライアント側発見可能資格情報は、認証セレモニーで資格情報IDが指定される場合にも利用可能です。つまり、navigator.credentials.get()を非空のallowCredentials引数で呼び出す場合です。

適合ユーザーエージェント

本仕様のWeb認証APIやアルゴリズムを、基盤のクライアントデバイスと協調して実装し、認証器とリライングパーティ間の通信を扱うユーザーエージェント。

資格情報ID

バイト列で、公開鍵資格情報ソースやその認証アサーションを識別します。確率的に一意となります。

資格情報IDは認証器により2つの形式で生成されます：

  1. 少なくとも16バイト（少なくとも100ビットのエントロピーを含む）、または

  2. 公開鍵資格情報ソース（資格情報IDや可変項目を除く）を、管理認証器のみ復号可能な形で暗号化。この形式では認証器はほぼステートレスとなり、リライングパーティ側で必要な状態を保存します。

    注：[FIDO-UAF-AUTHNR-CMDS]には「セキュリティガイドライン」下で暗号化手法の指針があります。

リライングパーティはこれら2種類の資格情報IDの違いを区別する必要はありません。

資格情報鍵ペア
資格情報プライベートキー
資格情報公開鍵
ユーザー公開鍵

資格情報鍵ペアは、認証器が生成し、特定のスコープ付きWebAuthnリライングパーティのための非対称鍵ペアです。これは公開鍵資格情報の中核部分です。

資格情報公開鍵は資格情報鍵ペアの公開鍵部分です。資格情報公開鍵はリライングパーティに登録セレモニーで返却されます。

資格情報プライベートキーは資格情報鍵ペアの秘密鍵部分であり、特定の認証器（管理認証器）に紐付けられ、他者（所有者も含む）に公開されないことが前提です。

注意、自己認証の場合、認証情報鍵ペアが認証鍵ペアとしても使用されます。詳細は自己認証を参照してください。

注：資格情報公開鍵はFIDO UAFではユーザー公開鍵と呼ばれ、FIDO U2Fや本仕様の該当部分でも同様です。[UAFProtocol]、[FIDO-U2F-Message-Formats]参照。

資格情報プロパティ

資格情報プロパティは、公開鍵資格情報ソースの特性（例：クライアント側発見可能資格情報かサーバ側資格情報か等）を指します。

人間可読性

人間可読性のある識別子は、一般のユーザーが覚えやすく再現しやすいことを意図しています。一方、ランダム生成バイト列等は該当しません。[EduPersonObjectClassSpec]参照。

非発見可能資格情報

資格情報のうち、資格情報IDをallowCredentialsで指定してnavigator.credentials.get()を呼び出す必要があるもの。クライアント側発見可能資格情報でない場合です。サーバ側資格情報も参照。

公開鍵資格情報ソース

資格情報ソース（[CREDENTIAL-MANAGEMENT-1]）で、認証器が認証アサーションを生成するために用います。公開鍵資格情報ソースは以下の構造体項目を持ちます：

type

PublicKeyCredentialType型の値で、デフォルトはpublic-keyです。

id

資格情報ID。

privateKey

資格情報プライベートキー。

rpId

この公開鍵資格情報ソースがスコープされるリライングパーティのリライングパーティ識別子。

userHandle

この公開鍵資格情報ソース作成時に関連づけられたユーザーハンドル。null可能。

otherUI

OPTIONALで、認証器がUI表示のために使う情報（例：ユーザーのdisplayNameなど）。otherUIは可変項目であり、更新可能な形で保存されるべきです。

authenticatorMakeCredential操作は、公開鍵資格情報ソースを作成し、管理認証器に紐付け、対応する資格情報公開鍵を返します。リライングパーティはこの資格情報公開鍵で認証アサーションを検証できます。

公開鍵資格情報

一般に、資格情報は一方のエンティティが他方に認証のために提示するデータです。公開鍵資格情報は、公開鍵資格情報ソース、場合によっては証明付き資格情報公開鍵、または認証アサーションを指します。どれかは文脈によります。

注：これは意図的違反です。英語で"credential"はa)証明するために提示されるもの、およびb)複数回使用可能なものを指しますが、公開鍵システムにおいて両方を単一データで安全に実現することは困難です。[RFC4949]では資格情報を複数回利用可能なもの（公開鍵）と定義していますが、本仕様は英語用法の柔軟性を取り入れています。より具体的な用語で[RFC4949]資格情報に関連するデータを指します：
「認証情報」（秘密鍵含む場合あり）

公開鍵資格情報ソース

「署名済み値」

認証アサーション

[RFC4949]「資格情報」

資格情報公開鍵または証明オブジェクト

登録時、認証器は非対称鍵ペアを生成し、プライベートキー部分とリライングパーティ情報を公開鍵資格情報ソースに保存します。公開鍵部分はリライングパーティに返却され、ユーザーアカウントと紐付けて保存されます。 以降、そのリライングパーティ（RP IDで識別）だけが、公開鍵資格情報を認証セレモニーでget()メソッド経由で利用可能です。リライングパーティは保存済み資格情報公開鍵で得られた認証アサーションを検証します。

レート制限

認証器がブルートフォース攻撃を防ぐため、一定時間内の連続失敗認証回数を制限（スロットリング）する仕組み。上限に達した場合、試行毎に指数的に遅延を課すか、現在の認証方式を無効化し、他の認証要素を提示する場合があります。レート制限はしばしばユーザー検証の一部として実装されます。

登録
登録セレモニー

セレモニーの一種で、ユーザー、リライングパーティ、ユーザーのクライアント（少なくとも一つの認証器を含む）が協調し、公開鍵資格情報を作成し、ユーザーのリライングパーティアカウントと紐付けます。ユーザー存在テストやユーザー検証が含まれます。登録セレモニー成功後、ユーザーは認証セレモニーで認証可能となります。

WebAuthnの登録セレモニーは§ 7.1 新規資格情報の登録で定義され、リライングパーティがnavigator.credentials.create()をpublicKey引数付きで呼び出すことで開始されます。 § 5 Web認証APIや§ 1.3.1 登録に概要と実装例があります。

リライングパーティ

WebAuthnリライングパーティ参照。

リライングパーティ識別子
RP ID

WebAuthn APIにおいて、リライングパーティ識別子は有効なドメイン文字列であり、実行中のWebAuthnリライングパーティを識別します。登録や認証セレモニーではこのRP IDが使われます。公開鍵資格情報は、登録時と同じRP IDのエンティティでのみ認証時に使用可能です。

WebAuthn操作のデフォルトRP IDは呼び出し元のoriginの有効ドメインとなります。呼び出し元が指定するRP IDは、その値が呼び出し元の有効ドメインと一致するか、登録可能ドメインサフィックスであれば上書き可能です。詳細は§ 5.1.3 新規資格情報の作成 - PublicKeyCredentialの[[Create]](origin, options, sameOriginWithAncestors)メソッドや§ 5.1.4 既存資格情報によるアサーション生成 - PublicKeyCredentialの[[Get]](options)メソッド参照。

注：RP IDはホストのドメイン名に基づきます。スキームやポートは含みません（originには含む）。公開鍵資格情報のRP IDはそのスコープ（=どのoriginで利用可能か）を決めます。具体的には：

例：リライングパーティのoriginがhttps://login.example.com:1337の場合、有効なRP IDはlogin.example.com（デフォルト）、example.com。m.login.example.comやcomは無効です。

これはCookie等の広く展開済み常駐資格情報（[RFC6265]）の挙動に合わせたものです。document.domainのsetterよりも同一origin制限を緩和しています。

これらのorigin値制約はWebAuthnクライアントに適用されます。

WebAuthn APIを模倣し、Web以外のプラットフォーム（例：ネイティブモバイルアプリ）で公開鍵資格情報を利用可能にする仕様では、呼び出し元とリライングパーティ識別子の紐付け方法が異なる場合があります。ただし、RP ID構文は有効なドメイン文字列またはURI（[RFC3986]、[URL]）に準拠しなければなりません。

サーバ側公開鍵資格情報ソース
サーバ側資格情報
[DEPRECATED] 非レジデント資格情報

注：歴史的に、サーバー側資格情報は非リジデント資格情報として知られていました。 後方互換性のため、各種WebAuthn APIや認証器モデルの「resident」を含む名称はそのままです。

サーバー側公開鍵資格情報ソース（略してサーバー側資格情報）は、 公開鍵資格情報ソースの一種で、認証式の際にリライングパーティが 資格情報IDをnavigator.credentials.get()の allowCredentials 引数に渡した場合のみ利用可能となります。つまり、リライングパーティは資格情報の保存と探索を管理し、まずユーザーを特定した上で 資格情報IDをnavigator.credentials.get() の呼び出し時に指定できる必要があります。

クライアント側で 公開鍵資格情報ソースを保存する必要は サーバー側資格情報にはありません。 これはクライアント側探索可能資格情報と対照的で、 こちらはユーザーを特定せずともユーザーの資格情報IDをnavigator.credentials.get() に渡すことができます。

参考：サーバー側資格情報保存モダリティや非探索可能資格情報も参照してください。

ユーザー存在テスト

ユーザー存在テストは、認可ジェスチャの簡易な形式であり、ユーザーが 認証器に（通常は）単純に触れる等の操作を行う技術的プロセスです（他の方式もあり得ます）。結果は真偽値です。これはユーザー検証ではなく、定義上 生体認証も、パスワードやPIN等の共有秘密提示も含みません。

ユーザー同意

ユーザー同意とは、ユーザーが求められている内容について理解し同意することです。つまり、プロンプトを読んで理解することを含みます。 認可ジェスチャは、認証式の要素であり、ユーザー同意を示すためによく用いられます。

ユーザーハンドル

ユーザーハンドルはリライングパーティによって指定され、 user.id の値となり、特定の公開鍵資格情報を リライングパーティの特定ユーザーアカウントにマッピングするために使います。認証器はさらにマッピングを行い、RP IDとユーザーハンドルのペアを 公開鍵資格情報ソースに対応付けます。

ユーザーハンドルは不透明なバイト列（最大64バイト）であり、ユーザーに表示することを意図しません。

ユーザー検証

認証器がローカルでauthenticatorMakeCredentialやauthenticatorGetAssertion操作を許可する技術的プロセスです。 ユーザー検証は 様々な認可ジェスチャ（例：タッチ＋PINコード、パスワード入力、生体認証（指紋提示など）[ISOBiometricVocabulary]）で行うことができます。 目的は個々のユーザーを識別することです。

ただし、ユーザー検証はリライングパーティに具体的なユーザー識別を提供するものではありませんが、同じ資格情報で2回以上式を実施した場合、同一ユーザーによる操作だったことは示されます。 ただし、複数の自然人が同じ認証器を共有する場合、同じユーザーとは限りません。

注：自然人の区別は、主にクライアントプラットフォームや認証器の機能によります。 例：あるデバイスが一人の利用を想定していても、複数人が指紋登録や同じPINを知っている場合、そのデバイスで同じリライングパーティアカウントにアクセスできることがあります。

注：authenticatorMakeCredentialやauthenticatorGetAssertion操作の呼び出しは 認証器が管理する鍵素材の利用を意味します。

また、セキュリティのため、ユーザー検証や資格情報秘密鍵の利用は、認証器の論理的セキュリティ境界内で完結する必要があります。

ユーザー検証手順はブルートフォース攻撃防止のためレート制限を実装しても構いません。

ユーザー存在
UP

ユーザー存在テストが正常に完了すると、ユーザーは「存在している」とされます。

ユーザー検証済み
UV

ユーザー検証プロセスが正常に完了すると、ユーザーは「検証済み」となります。

WebAuthnリライングパーティ

自身のウェブアプリケーションがWeb認証APIを利用して、ユーザーを登録・認証する主体。

リライングパーティの実装は、Web認証APIをクライアントで呼び出すスクリプトと、 リライングパーティ操作や他のアプリケーションロジックを実行するサーバー側コンポーネントで構成されることが多いです。 両者間の通信はHTTPS等の輸送セキュリティが必須ですが、それ以外は本仕様の範囲外です。

注：リライングパーティは他の文脈（例：X.509やOAuth）でも使われますが、 ある文脈でリライングパーティとなる主体が、他の文脈でもリライングパーティであるとは限りません。 本仕様ではWebAuthnリライングパーティを単にリライングパーティと呼ぶことが多く、WebAuthnの文脈でのリライングパーティを明示します。 なお、実際のWebAuthn文脈はOAuth等の広い文脈の一部として組み込まれている場合もあります。

5. Web認証API

このセクションでは、公開鍵資格情報の作成と利用のためのAPIを規範的に規定します。基本的な考え方は、資格情報はユーザーに属し、管理認証器によってWebAuthn認証器として管理され、WebAuthnリライングパーティはクライアントプラットフォーム経由でそれとやりとりします。リライングパーティのスクリプトは（ユーザーの同意があれば）ブラウザに対し将来利用する新しい資格情報の作成を要求できます。下記の図参照。

登録フロー

スクリプトはまた、既存資格情報を使った認証操作のためにユーザーの許可を要求できます。下記の図参照。

認証フロー

これらの操作はすべて認証器内で実行され、ユーザーの代理としてクライアントプラットフォームが仲介します。スクリプトは資格情報自体へのアクセスはできず、資格情報に関する情報のみオブジェクトとして取得します。

上記のスクリプトインターフェースに加えて、認証器が管理用のユーザーインターフェース（またはそれを実装するクライアントソフトウェア）を備えている場合もあります。例えば、認証器を初期化したり状態を確認したりする用途です。これは、ブラウザが履歴や保存パスワード、Cookieなどのユーザー状態管理UIを提供するのに類似しています。資格情報削除などの認証器管理操作はこのようなユーザーインターフェースの責任であり、スクリプトに公開されるAPIには意図的に含まれていません。

このAPIのセキュリティ特性は、クライアントと認証器が協力して実現します。資格情報を保持・管理する認証器は、すべての操作を特定のスコープ（オリジン）に限定し、他のオリジンへのリプレイを防止するために応答にオリジンを含め署名します。具体的には、§ 6.3 認証器操作で定義されている通り、リクエスターの完全なオリジンが新しい資格情報作成時の証明オブジェクトや認証アサーションに含まれ署名されます。

さらに、ユーザープライバシー保護と悪意あるリライングパーティによる他のリライングパーティの公開鍵資格情報存在の探索防止のため、各資格情報はスコープされたリライングパーティ識別子（RP ID）にも紐付けられます。このRP IDはすべての操作でクライアントから認証器へ渡され、認証器はリライングパーティが作成した資格情報は同じRP IDによる操作時のみ利用できるよう保証します。オリジンとRP IDを分離することで、ひとつのリライングパーティが複数のオリジンを管理する場合にも柔軟にAPIを利用できます。

クライアントは、各操作時にリライングパーティのオリジンとRP IDを認証器へ渡すことで、これらのセキュリティ制御を支援します。これはWebAuthnのセキュリティモデルの核心なので、ユーザーエージェントはこのAPIをセキュアコンテキストの呼び出し元にのみ公開します。 特にWebコンテキストでは、TLS等でエラーなく確立された安全な輸送経路でアクセスされたもののみが対象です。

Web認証APIは、以下のセクションで提示されるWeb IDL断片の合成として定義されます。まとめたIDL一覧はIDL索引にあります。

5.1. PublicKeyCredential インターフェース

PublicKeyCredential

すべての現行エンジンで利用可能です。

Firefox60以降Safari13以降Chrome67以降
Opera未対応Edge79以降
Edge（旧版）18IE未対応
Firefox for Android60以降iOS Safari13.3以降Chrome for Android70以降Android WebView70以降Samsung Internet未対応Opera Mobile未対応

PublicKeyCredential インターフェースはCredential [CREDENTIAL-MANAGEMENT-1]を継承し、新規資格情報作成時や新規アサーション要求時に返される属性を持ちます。

PublicKeyCredential/getClientExtensionResults

すべての現行エンジンで利用可能です。

Firefox60以降Safari13以降Chrome67以降
Opera未対応Edge79以降
Edge（旧版）18IE未対応
Firefox for Android60以降iOS Safari13.3以降Chrome for Android70以降Android WebView70以降Samsung Internet未対応Opera Mobile未対応

PublicKeyCredential/rawId

すべての現行エンジンで利用可能です。

Firefox60以降Safari13以降Chrome67以降
Opera未対応Edge79以降
Edge（旧版）18IE未対応
Firefox for Android60以降iOS Safari13.3以降Chrome for Android70以降Android WebView70以降Samsung Internet未対応Opera Mobile未対応 
[SecureContext, Exposed=Window]
interface PublicKeyCredential : Credential {
    [SameObject] readonly attribute ArrayBuffer              rawId;
    [SameObject] readonly attribute AuthenticatorResponse    response;
    AuthenticationExtensionsClientOutputs getClientExtensionResults();
};
id

この属性はCredentialから継承されていますが、PublicKeyCredentialはgetterを上書きし、 オブジェクトの[[identifier]] 内部スロットに含まれるデータのbase64urlエンコーディングを返します。

rawId

この属性はArrayBuffer を返し、[[identifier]] 内部スロットに格納されています。

PublicKeyCredential/response

すべての現行エンジンで利用可能です。

Firefox60以降Safari13以降Chrome67以降
Opera未対応Edge79以降
Edge（旧版）18IE未対応
Firefox for Android60以降iOS Safari13.3以降Chrome for Android70以降Android WebView70以降Samsung Internet未対応Opera Mobile未対応

response、型はAuthenticatorResponse、読み取り専用

この属性には、クライアントが公開鍵資格情報の作成または認証アサーション生成を要求した際の認証器の応答が含まれます。PublicKeyCredentialがcreate()に応答して生成された場合はAuthenticatorAttestationResponseとなり、 PublicKeyCredentialがget()に応答して生成された場合は AuthenticatorAssertionResponseとなります。

getClientExtensionResults()

この操作は[[clientExtensionsResults]] の値を返します。これは、拡張ID→クライアント拡張処理結果のエントリを持つマップです。

[[type]]

PublicKeyCredential インターフェースオブジェクトの[[type]] 内部スロットの値は "public-key"です。

注：これは、type 属性getter（Credentialから継承）を通じて反映されます。

[[discovery]]

PublicKeyCredential インターフェースオブジェクトの[[discovery]] 内部スロットの値は "remote"です。

[[identifier]]

この内部スロットには、認証器が選択した資格情報IDが含まれます。 資格情報IDは資格情報検索に利用されるため、同種資格情報・全認証器間でほぼグローバルに一意となることが期待されます。

注：このAPIはこの識別子の形式や長さを制約しませんが、認証器が一意に鍵を選択できる十分な情報である必要があります。例えば、オンボードストレージを持たない認証器は資格情報秘密鍵を認証器内の共通鍵でラップしたものを識別子として生成する場合があります。

[[clientExtensionsResults]]

この内部スロットには、リライングパーティがnavigator.credentials.create() やnavigator.credentials.get() を呼び出した際に要求したクライアント拡張処理の結果が格納されます。

PublicKeyCredentialの インターフェースオブジェクトはCredentialの[[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors)実装を継承し、 独自に[[Create]](origin, options, sameOriginWithAncestors)、 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)、 [[Store]](credential, sameOriginWithAncestors)を定義します。

5.1.1. CredentialCreationOptions 辞書拡張

navigator.credentials.create() 経由で登録をサポートするため、本書は CredentialCreationOptions 辞書を以下のように拡張します： 

partial dictionary CredentialCreationOptions {
    PublicKeyCredentialCreationOptions      publicKey;
};

5.1.2. CredentialRequestOptions 辞書拡張

navigator.credentials.get() によるアサーション取得をサポートするため、本書はCredentialRequestOptions 辞書を以下のように拡張します：

partial dictionary CredentialRequestOptions {
    PublicKeyCredentialRequestOptions      publicKey;
};

5.1.3. 新規資格情報の作成 - PublicKeyCredentialの [[Create]](origin, options, sameOriginWithAncestors) メソッド

PublicKeyCredential インターフェースオブジェクトによる[[Create]](origin, options, sameOriginWithAncestors) 内部メソッド [CREDENTIAL-MANAGEMENT-1]は、WebAuthnリライングパーティのスクリプトによるnavigator.credentials.create() の呼び出しを可能にし、公開鍵資格情報ソース（認証器に紐付け）の新規作成を要求できます。このnavigator.credentials.create() 操作は、AbortControllerを利用することで中断可能です。 詳細はDOM §3.3 AbortControllerとAbortSignalオブジェクトのAPI統合を参照してください。

この内部メソッドは以下3つの引数を取ります：

origin

この引数は呼び出し元create() 実装によって決定される 関連設定オブジェクトのoriginです。

options

この引数はCredentialCreationOptions オブジェクトであり、 options.publicKey メンバーに PublicKeyCredentialCreationOptions オブジェクトが格納されます。これにより作成予定の公開鍵資格情報の属性を指定します。

sameOriginWithAncestors

この引数はBoolean値で、呼び出し元の環境設定オブジェクトが祖先と同一オリジンの場合のみtrueです。クロスオリジンの場合はfalseになります。

注：この「sameOriginWithAncestors」制約は、Issue #1336で提起されたトラッキング懸念への対応です。今後の仕様で変更される可能性があります。

注：このアルゴリズムは同期的です： Promise の解決・拒否はnavigator.credentials.create()で処理されます。

注：このアルゴリズムで用いられるすべてのBufferSource オブジェクトは開始時点でスナップショット取得し、同期の問題を避ける必要があります。実装はバッファソースのバイトコピー取得を使い、そのコピーをアルゴリズム各所で利用してください。

このメソッドが呼び出されると、ユーザーエージェントは以下のアルゴリズムを実行する必要があります：

  1. Assert: options.publicKey が存在すること。

  2. もしsameOriginWithAncestorsがfalseなら、"NotAllowedError" DOMException を返す。

    注：この「sameOriginWithAncestors」制約は、Issue #1336で提起されたトラッキング懸念への対応です。今後の仕様で変更される可能性があります。

  3. optionsに options.publicKey の値を代入する。

  4. もしtimeout メンバーが存在するなら、その値がクライアントで定められた妥当な範囲内か確認し、範囲外なら最近傍の値に補正する。補正後の値でタイマーlifetimeTimerを設定。 timeout メンバーが無ければlifetimeTimerはクライアント独自のデフォルト値に設定。

    推奨範囲およびデフォルト値は以下の通り。 options.authenticatorSelection.userVerification

    がdiscouragedの場合

    推奨範囲：30000～180000ミリ秒。

    推奨デフォルト値：120000ミリ秒（2分）。

    required または preferred の場合

    推奨範囲：30000～600000ミリ秒。

    推奨デフォルト値：300000ミリ秒（5分）。

    注：ユーザーエージェントは特別な支援が必要なユーザーへの認知ガイドラインも考慮すべきです。

  5. options.user.id の長さが1～64バイト（両端含む）でなければ、TypeError を返す。

  6. callerOriginにorigin を代入。callerOriginが不透明オリジンならDOMException （名前は "NotAllowedError"）を返し、このアルゴリズムを終了。

  7. effectiveDomainにcallerOriginの有効ドメインを代入。 有効ドメインが有効ドメインでなければ、DOMException （名前は"SecurityError"）を返し、このアルゴリズムを終了。

    注：有効ドメインは様々な方法でhostとして表現可能ですが、 domain形式のみ許可されます。これは単純化およびPKIベースのセキュリティとIPアドレス直接識別の問題認識のためです。

  8. options.rp.id

    が存在する場合

    options.rp.id がeffectiveDomainの登録可能なドメインサフィックスでも等価でもない場合、 名前が"SecurityError"のDOMExceptionを返し、このアルゴリズムを終了します。

    存在しない場合

    options.rp.id にeffectiveDomainを設定します。

    注： options.rp.id は呼び出し元のRP IDを表します。RP IDのデフォルト値は呼び出し元のoriginの有効ドメインですが、呼び出し元がoptions.rp.id を明示的に設定した場合はその値になります（create()呼び出し時）。

  9. credTypesAndPubKeyAlgsを新規リストとし、そのアイテムはPublicKeyCredentialTypeと COSEAlgorithmIdentifierのペアとする。

  10. もし options.pubKeyCredParams のサイズが

    0の場合

    以下のペアをcredTypesAndPubKeyAlgsに追加：

    0以外の場合

    各currentについて options.pubKeyCredParamsを処理：

    1. もし current.type が本実装でサポートされるPublicKeyCredentialTypeを含まない場合は、continue。

    2. algに current.alg を代入。

    3. ペア追加： current.type とalgをcredTypesAndPubKeyAlgsに追加。

    もしcredTypesAndPubKeyAlgsが空なら、 名前が"NotSupportedError"の DOMExceptionを返し、このアルゴリズムを終了します。

  11. clientExtensionsを新規マップとし、authenticatorExtensionsも新規マップとする。

  12. extensions メンバーがoptionsに存在する場合、各 extensionId → clientExtensionInputについて options.extensionsで処理：

    1. もしextensionIdが当該クライアントプラットフォームでサポートされない、または登録拡張でなければ、continue。

    2. clientExtensions[extensionId]にclientExtensionInputをセット。

    3. もしextensionIdが認証器拡張でなければ、continue。

    4. authenticatorExtensionInputに、(CBOR) extensionIdのクライアント拡張処理アルゴリズムをclientExtensionInputに対して実行した結果をセット。 エラーの場合はcontinue。

    5. authenticatorExtensions[extensionId]にauthenticatorExtensionInputのbase64urlエンコーディング結果をセット。

  13. collectedClientDataを新規CollectedClientDataインスタンスとし、以下のフィールドを持つ：

    type

    文字列 "webauthn.create"。

    challenge

    options.challengeのbase64urlエンコーディング。

    origin

    callerOriginのシリアライズ。

    crossOrigin

    この内部メソッドに渡されたsameOriginWithAncestors引数の逆値。

    tokenBinding

    callerOriginとのToken Bindingの状態、およびcallerOriginに紐付くToken Binding ID（利用可能なら）。

  14. clientDataJSONにcollectedClientDataから構築したJSON互換シリアライズ結果を代入。

  15. clientDataHashにclientDataJSONのシリアライズ済みクライアントデータのハッシュ値を代入。

  16. options.signal が存在し、そのaborted flagがtrueなら、名前が"AbortError"の DOMExceptionを返し、このアルゴリズムを終了する。

  17. issuedRequestsを新規順序付きセットとする。

  18. authenticatorsはその時点で利用可能なセットの値で、各アイテムはこのクライアントプラットフォーム上で現在利用可能な認証器を識別するハンドル。

    注：「利用可能な認証器」の定義は意図的に明記しません。これは認証器がUSB等でホットプラグ可能であったり、NFCやBluetooth等で検出されたり、クライアントに組み込まれている場合など様々な発見手段を想定しています。

  19. lifetimeTimerを開始する。

  20. lifetimeTimerが期限切れにならない間、lifetimeTimerとauthenticators内の各authenticatorの状態・応答に応じて以下を実施：

    lifetimeTimerが期限切れの場合

    issuedRequestsの各authenticatorに対してauthenticatorCancel操作を呼び出し、issuedRequestsから削除。

    ユーザーがユーザーエージェントUIでプロセスをキャンセルした場合

    issuedRequestsの各authenticatorに対してauthenticatorCancel操作を呼び出し、issuedRequestsから削除。名前が"NotAllowedError"のDOMExceptionを返す。

    options.signal が存在し、そのaborted flagがtrueの場合

    issuedRequestsの各authenticatorに対してauthenticatorCancel操作を呼び出し、issuedRequestsから削除。名前が"AbortError"のDOMExceptionを返しこのアルゴリズムを終了。

    authenticatorがこのclient deviceで利用可能になった場合

    注：これはlifetimeTimer開始時点で利用可能だった場合も含む。

    1. このauthenticatorが候補認証器となる。

    2. options.authenticatorSelection が存在する場合：

      1. options.authenticatorSelection.authenticatorAttachment が存在しその値がauthenticatorの認証器アタッチメントモダリティと異なる場合、continue。

      2. options.authenticatorSelection.residentKey

        が存在しrequiredの場合

        authenticatorがクライアント側探索可能公開鍵資格情報ソースを保存できなければ、continue。

        が存在しpreferredまたはdiscouragedの場合

        効果なし。

        存在しない場合

        options.authenticatorSelection.requireResidentKey がtrueかつauthenticatorがクライアント側探索可能公開鍵資格情報ソースを保存できなければ、continue。

      3. options.authenticatorSelection.userVerification がrequiredでauthenticatorがユーザー検証できなければ、continue。

    3. requireResidentKeyを資格情報作成時の有効なresidentKey要件（Boolean）とし、以下の通り決定：

      options.authenticatorSelection.residentKey

      が存在しrequiredの場合

      requireResidentKey = true。

      が存在しpreferredの場合

      authenticatorがクライアント側資格情報保存モダリティ可能ならrequireResidentKey = true。 できない、またはクライアントが判定不可の場合はrequireResidentKey = false。

      が存在しdiscouragedの場合

      requireResidentKey = false。

      存在しない場合

      requireResidentKey = options.authenticatorSelection.requireResidentKeyの値。

    4. userVerificationを資格情報作成時の有効なユーザー検証要件（Boolean）とし、以下の通り決定：

      options.authenticatorSelection.userVerification

      がrequiredの場合

      userVerification = true。

      がpreferredの場合

      authenticatorがユーザー検証可能ならuserVerification = true。できなければuserVerification = false。

      がdiscouragedの場合

      userVerification = false。

    5. enterpriseAttestationPossible（Boolean）を以下で決定：options.attestation

      がenterpriseの場合

      user agentがoptions.rp.idでエンタープライズ証明をサポートする場合true、そうでなければfalse。

      それ以外

      false。

    6. excludeCredentialDescriptorListを新規リストとする。

    7. excludeCredentials内の各credential descriptor Cについて：

      1. C.transports が空でなく、authenticatorが記載されていないtransportで接続されている場合、clientはcontinueしてもよい。

        注：clientがcontinueした場合、transportヒントが正確でないと同一authenticatorに複数資格情報が誤登録される恐れがある。例えば、ソフトウェアアップデートで新たな接続方法が追加された場合など。

      2. それ以外の場合はexcludeCredentialDescriptorListにCを追加。

      3. authenticatorに対しclientDataHash、 options.rp、 options.user、 requireResidentKey、userVerification、credTypesAndPubKeyAlgs、 excludeCredentialDescriptorList、enterpriseAttestationPossible、authenticatorExtensions をパラメータとしてauthenticatorMakeCredential操作を呼び出す。

    8. issuedRequestsにauthenticatorを追加。

    authenticatorがこのclient deviceで利用不可になった場合

    issuedRequestsからauthenticatorを削除。

    authenticatorがユーザーによる操作キャンセルを示すステータスを返した場合

    1. issuedRequestsからauthenticatorを削除。

    2. issuedRequestsの残りauthenticatorに対してauthenticatorCancel操作を呼び出し、issuedRequestsから削除。

      注：authenticatorは「ユーザーが全操作をキャンセルした」ことを示す場合があり、ユーザーエージェントがこの状態をどう表現するかは現行標準では未規定。

    authenticatorが"InvalidStateError"相当のエラーステータスを返した場合

    1. issuedRequestsからauthenticatorを削除。

    2. issuedRequestsの残りauthenticatorに対してauthenticatorCancel操作を呼び出し、issuedRequestsから削除。

    3. 名前が"InvalidStateError"の DOMExceptionを返し、このアルゴリズムを終了。

    注：このエラーは、excludeCredentialDescriptorListがauthenticatorに紐付く資格情報を特定し、ユーザーが操作に同意した場合のみauthenticatorが返すため、明示的同意があるこのケースに限りリライングパーティから区別可能。

    authenticatorが"InvalidStateError"以外のエラーステータスを返した場合

    issuedRequestsからauthenticatorを削除。

    注：この場合は操作へのユーザー同意がないため、エラー詳細はリライングパーティへの情報漏洩防止のため秘匿される。詳細は§ 14.5.1 登録式のプライバシー参照。

    authenticatorが成功を示した場合

    1. issuedRequestsからauthenticatorを削除。このauthenticatorが選択認証器となる。

    2. credentialCreationDataを新規構造体とし、以下のアイテムを持つ：

      attestationObjectResult

      成功したauthenticatorMakeCredential操作から返されたバイト列。

      注：この値は§ 6.5.4 証明オブジェクトの生成で定義されるattObj。

      clientDataJSONResult

      clientDataJSONのバイト列。

      attestationConveyancePreferenceOption

      options.attestationの値。

      clientExtensionResults

      AuthenticationExtensionsClientOutputsオブジェクトで、各拡張ID→クライアント拡張出力のエントリを持つ。各エントリは各拡張のクライアント拡張処理アルゴリズムを実行して生成される。対象拡張はoptions.extensions。

    3. constructCredentialAlgを、新規グローバルオブジェクトvar globalを受け取り、手順：

      1. credentialCreationData.attestationConveyancePreferenceOption の値が

        "none"

        一意情報を非識別化データに置換：

        1. attested credential dataのAAGUIDが16バイト0、attestationObjectResult.fmtが"packed"、"x5c"がattestationObjectResultに無い場合はself attestationで追加処理不要。

        2. それ以外：

          1. attested credential dataのAAGUIDを16バイト0に置換。

          2. attestationObjectResult.fmtを"none"、attestationObjectResult.attStmtを空CBORマップに設定（§ 8.7 None Attestation Statement Format、§ 6.5.4 証明オブジェクトの生成参照）。

        "indirect"

        clientはAAGUIDやattestation statementをよりプライバシー配慮または検証容易なものに置換してもよい（例：匿名化CA利用）。

        "direct"または"enterprise"

        authenticatorのAAGUIDとattestation statementを変更せずリライングパーティに送信。

      2. attestationObjectをグローバルの%ArrayBuffer%で生成し、attestationObjectResultのバイト列を格納。

      3. idをattestationObject.authData.attestedCredentialData.credentialIdとする。

      4. pubKeyCredを新規PublicKeyCredentialオブジェクトとしてglobalに関連付け、フィールド：

        [[identifier]]

        id

        response

        新規AuthenticatorAttestationResponseオブジェクトとしてglobalに関連付け、フィールド：

        clientDataJSON

        globalの%ArrayBuffer%で生成し、clientDataJSONResultのバイト列を格納。

        attestationObject

        attestationObject

        [[transports]]

        authenticatorが対応すると考えられる一意なDOMString列（辞書順）。値はAuthenticatorTransportのメンバー推奨だが、クライアントプラットフォームは未知値を無視すること。情報秘匿したい場合は空列などプライバシー保護のため任意列でも可。情報無い場合は空列推奨。

        注：ユーザーエージェントが認証器のtransport情報を取得する方法は現行標準外だが、証明書や認証器プロトコル（CTAP2）・プラットフォーム認証器の特例知識などが含まれる場合もある。

        [[clientExtensionsResults]]

        globalの%ArrayBuffer%で生成し、clientExtensionResultsのバイト列を格納。

      5. pubKeyCredを返す。

    4. issuedRequestsの残りauthenticatorに対しauthenticatorCancel操作を呼び出し、issuedRequestsから削除。

    5. constructCredentialAlgを返しこのアルゴリズムを終了。

  21. 名前が"NotAllowedError"のDOMExceptionを返す。 ユーザー同意なしに識別情報漏洩を防ぐため、lifetimeTimerが期限切れになる前にこのステップを実行してはならない（詳細は§ 14.5.1 登録式のプライバシー参照）。

上記処理中、ユーザーエージェントはユーザーが認証器選択や認証を行う際にUIで案内すべきです。

5.1.4. 既存の認証情報を使用してアサーションを作成する - PublicKeyCredential の [[Get]](options) メソッド

WebAuthn Relying Party は navigator.credentials.get({publicKey:..., ...}) を呼び出し、 既存の 公開鍵認証情報を、ユーザーの同意のもとで発見・利用します。Relying Party のスクリプトは、許容される認証情報ソースの基準をオプションで指定できます。クライアントプラットフォームは、指定された基準に一致する認証情報ソースを見つけ、スクリプトが使用を許可するものをユーザーに選択させます。ユーザーは、認証情報ソースが存在しても、プライバシー保護などの理由で一連の操作自体を拒否することができます。ユーザーが認証情報ソースを選択した場合、ユーザーエージェントは § 6.3.3 authenticatorGetAssertion 操作 を利用し、Relying Party が提供したチャレンジやその他収集されたデータに署名してアサーションを作成し、これが 認証情報として利用されます。

get() 実装は [CREDENTIAL-MANAGEMENT-1] により PublicKeyCredential.[[CollectFromCredentialStore]]() を呼び出し、 ユーザー媒介不要（概ね本仕様の 認可ジェスチャー）で利用可能な認証情報を収集します。これに該当するものが1つだけ存在しない場合、 PublicKeyCredential.[[DiscoverFromExternalSource]]() を呼び出して、 ユーザーに認証情報ソースの選択を促します。

本仕様は 認可ジェスチャーが必要で認証情報を作成するため、 PublicKeyCredential.[[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) 内部メソッドは、デフォルトの Credential.[[CollectFromCredentialStore]]() の動作を継承し、空集合を返します。

このnavigator.credentials.get() 操作は、AbortController を活用することで中断できます。 詳細な手順は DOM §3.3 AbortController と AbortSignal をAPIで利用する方法 を参照してください。

5.1.4.1. PublicKeyCredential の [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) メソッド

この 内部メソッドは、3つの引数を受け取ります：

origin

この引数は、呼び出し元の 関連設定オブジェクトの origin です。これは get() 実装によって決定されます。すなわち、CredentialsContainer の Request a Credential 抽象操作です。

options

この引数は CredentialRequestOptions オブジェクトであり、 options.publicKey メンバーには、発見したい 公開鍵認証情報の希望属性を指定する PublicKeyCredentialRequestOptions オブジェクトが入ります。

sameOriginWithAncestors

この引数は Boolean 値で、呼び出し元の 環境設定オブジェクトが祖先と同一オリジンである場合のみ true となります。呼び出し元がクロスオリジンの場合は false です。

注: この 内部メソッドが呼び出されることは、パーミッションポリシーで許可されたことを示します。これは [CREDENTIAL-MANAGEMENT-1] レベルで評価されます。 詳細は § 5.9 パーミッションポリシー統合 を参照してください。

注: このアルゴリズムは同期的です: Promise の解決・拒否は navigator.credentials.get() により制御されます。

注: このアルゴリズムで使用される全ての BufferSource オブジェクトはアルゴリズム開始時にスナップショット化され、同期の問題を避ける必要があります。アルゴリズム実装はバッファソースが保持するバイト列のコピーを取得し、そのコピーをアルゴリズムの該当部分で利用してください。

このメソッドが呼び出されると、ユーザーエージェントは以下のアルゴリズムを必ず実行しなければなりません：

  1. アサート: options.publicKey が存在すること。

  2. options を options.publicKey の値とする。

  3. options の timeout メンバーが存在する場合、その値がクライアントで定義される合理的な範囲内かを確認し、範囲外の場合は最も近い範囲内の値に修正する。 この調整後の値でタイマー lifetimeTimer を設定する。 timeout メンバーが存在しない場合は、lifetimeTimer をクライアント固有のデフォルト値に設定する。

    timeout メンバーの推奨範囲とデフォルト値は以下の通り。 options.userVerification

    が discouraged の場合

    推奨範囲: 30000ミリ秒～180000ミリ秒。

    推奨デフォルト値: 120000ミリ秒（2分）。

    が required または preferred の場合

    推奨範囲: 30000ミリ秒～600000ミリ秒。

    推奨デフォルト値: 300000ミリ秒（5分）。

    注: ユーザーエージェントは、特別なニーズを持つユーザーのためのタイムアウトについて認知的ガイドラインを考慮する必要があります。

  4. callerOrigin を origin とする。 callerOrigin が 不透明オリジンの場合、名前が "NotAllowedError" の DOMException を返し、このアルゴリズムを終了する。

  5. effectiveDomain を callerOrigin の 有効ドメインとする。 有効ドメインが 有効なドメインでない場合、名前が "SecurityError" の DOMException を返し、このアルゴリズムを終了する。

    注: 有効ドメインは ホストに解決される場合があり、ドメイン、IPv4アドレス、IPv6アドレス、不透明ホスト、空ホスト など様々な形式で表現される。 ここでは ドメイン形式のみ許可される。これは簡易化のためであり、PKIベースのセキュリティとIPアドレス識別の併用に関する様々な問題も考慮している。

  6. options.rpId が存在しない場合、rpId を effectiveDomain に設定する。

    それ以外の場合：

    1. options.rpId が 有効ドメインの登録可能なサフィックスでも等しくもない場合、名前が "SecurityError" の DOMException を返し、このアルゴリズムを終了する。

    2. rpId を options.rpId に設定する。

      注: rpIdは呼び出し元のRP IDを表す。RP IDは、呼び出し元のoriginの有効ドメインがデフォルトとなり、呼び出し時に options.rpId が明示的に指定された場合はそれが使用される。

  7. clientExtensions を新しいマップとし、authenticatorExtensions を新しいマップとする。

  8. options の extensions メンバーが存在する場合は、各 extensionId → clientExtensionInput の options.extensions について：

    1. extensionId がこのクライアントプラットフォームでサポートされていない、または認証拡張でない場合、次へ。

    2. clientExtensions[extensionId] に clientExtensionInput をセットする。

    3. extensionId が認証器拡張でない場合、次へ。

    4. authenticatorExtensionInput を (CBOR) で extensionId の クライアント拡張処理アルゴリズムを clientExtensionInput に適用した結果とする。エラーの場合は 次へ。

    5. authenticatorExtensions[extensionId] に base64urlエンコーディングした authenticatorExtensionInput をセットする。

  9. collectedClientData を、新しい CollectedClientData インスタンスとし、次のフィールドを持つ：

    type

    文字列 "webauthn.get"。

    challenge

    base64urlエンコーディングした options.challenge

    origin

    callerOriginのシリアライズ

    crossOrigin

    この内部メソッドに渡された sameOriginWithAncestors 引数の値の逆。

    tokenBinding

    クライアントと callerOrigin 間の Token Bindingのステータスおよび Token Binding ID（利用可能な場合）。

  10. clientDataJSON を クライアントデータのJSON互換シリアライズで collectedClientData から構築する。

  11. clientDataHash を シリアライズされたクライアントデータのハッシュで clientDataJSON を表現する。

  12. options.signal が存在し、その aborted flag が true の場合、名前が "AbortError" の DOMException を返し、このアルゴリズムを終了する。

  13. issuedRequests を新しい順序集合とする。

  14. savedCredentialIds を新しいマップとする。

  15. authenticators を現時点で利用可能なクライアントプラットフォーム固有のハンドルの集合とする。各項目は現在このクライアントプラットフォームで利用可能な認証器を識別する。

    注: どのような認証器が「利用可能」とみなされるかは明示的には規定されていません。これは、認証器がUSB等でホットプラグされたり、NFCやBluetooth等で発見されたり、またはクライアントに恒久的に組み込まれている場合など様々な機構を表します。

  16. lifetimeTimer を開始する。

  17. lifetimeTimer が期限切れでない間、次の処理を lifetimeTimer や状態、各 authenticator の応答に応じて行う：

    lifetimeTimer が期限切れの場合

    各 authenticator について issuedRequests 内で authenticatorCancel 操作を呼び出し、issuedRequests から削除する。

    ユーザーがユーザーエージェントのUIオプションで処理をキャンセルした場合

    各 authenticator について issuedRequests 内で authenticatorCancel 操作を呼び出し、issuedRequests から削除する。名前が "NotAllowedError" の DOMException を返す。

    signal メンバーが存在し、その aborted flag が true の場合

    各 authenticator について issuedRequests 内で authenticatorCancel 操作を呼び出し、issuedRequests から削除する。その後、名前が "AbortError" の DOMException を返し、このアルゴリズムを終了する。

    issuedRequests が空であり、 options.allowCredentials が空でなく、いずれの authenticator も 公開鍵認証情報に対して利用可能にならない場合

    ユーザーに利用可能な認証情報がないことを通知し、ユーザーがダイアログを確認したら名前が "NotAllowedError" の DOMException を返す。

    注: クライアントプラットフォームが authenticator が利用可能にならないことを判断する一例は、現在の transports メンバーや PublicKeyCredentialDescriptor の項目を調査することなど。例えば、全ての PublicKeyCredentialDescriptor の項目が internal のみを挙げているが、すべてのプラットフォーム認証器が試されている場合、要求を満たす可能性はない。あるいは、全ての PublicKeyCredentialDescriptor の項目が、クライアントプラットフォームがサポートしない transports を挙げている場合など。

    認証器がこのクライアントデバイス上で利用可能になった場合

    注: これは lifetimeTimer 開始時に認証器が既に利用可能な場合も含みます。

    1. options.userVerification が required で、authenticator が ユーザー検証に対応していない場合、次へ。

    2. アサーションのための実効ユーザー検証要件（Boolean値）を次のように決定する。options.userVerification

      required の場合

      userVerification を true とする。

      preferred の場合

      この authenticator

      ユーザー検証に対応している場合

      userVerification を true とする。

      ユーザー検証に対応していない場合

      userVerification を false とする。

      discouraged の場合

      userVerification を false とする。

    3. options.allowCredentials

      空でない場合

      1. allowCredentialDescriptorList を新しい リストとする。

      2. クライアントプラットフォーム固有の手順を実行し、options.allowCredentials で記述された 公開鍵認証情報のうち、authenticator に rpId、options.allowCredentials.id、options.allowCredentials.type でマッチするものをフィルタし、allowCredentialDescriptorList にセットする。

      3. allowCredentialDescriptorList が 空の場合、次へ。

      4. distinctTransports を新しい 順序集合とする。

      5. allowCredentialDescriptorList が1つの値のみの場合、 savedCredentialIds[authenticator] に allowCredentialDescriptorList[0].id の値をセットする（詳細は こちら § 6.3.3 authenticatorGetAssertion 操作 参照）。

      6. 各 credential descriptor C について allowCredentialDescriptorList 内で、C.transports の各値（もしあれば）を distinctTransports に追加する。

        注: これは authenticator（この認証器）に対して transports のみを distinctTransports に集約する（順序集合の性質による）。

      7. distinctTransports

        空でない場合

        クライアントは distinctTransports から1つの transport 値を選択し、ローカル設定情報を考慮して authenticator に使用する適切なトランスポートを選択しても良い。

        その後 transport を使って authenticator に対し、rpId、clientDataHash、allowCredentialDescriptorList、userVerification、authenticatorExtensions をパラメータとして authenticatorGetAssertion 操作を呼び出す。

        空の場合

        ローカル設定情報を考慮して authenticator に使用する適切なトランスポートを選択し、rpId、clientDataHash、allowCredentialDescriptorList、userVerification、authenticatorExtensions をパラメータとして authenticatorGetAssertion 操作を呼び出す。

      空の場合

      ローカル設定情報を考慮して authenticator に使用する適切なトランスポートを選択し、rpId、clientDataHash、userVerification、authenticatorExtensions をパラメータとして authenticatorGetAssertion 操作を呼び出す。

      注: この場合、Relying Partyは許容する認証情報ディスクリプタのリストを指定していません。したがって、認証器は rpId で識別される Relying Partyにスコープされた任意の認証情報を利用するよう求められます。

    4. authenticator を issuedRequests に追加する。

    認証器がこのクライアントデバイスで利用不可になった場合

    authenticator を issuedRequests から削除する。

    認証器がユーザーによる操作キャンセルを示すステータスを返した場合

    1. authenticator を issuedRequests から削除する。

    2. 残りの authenticator について issuedRequests 内で authenticatorCancel 操作を呼び出し、issuedRequests から削除する。

      注: 認証器は「ユーザーが操作全体をキャンセルした」旨を返す場合がある。ユーザーエージェントがこれをどうユーザーに示すかは規定されていない。

    認証器がエラーステータスを返した場合

    authenticator を issuedRequests から削除する。

    認証器が成功を示した場合

    1. authenticator を issuedRequests から削除する。

    2. assertionCreationData を 構造体とし、次の項目を持つ：

      credentialIdResult

      savedCredentialIds[authenticator] が存在する場合、credentialIdResult の値を savedCredentialIds[authenticator] のバイト列に設定する。存在しない場合は、成功した authenticatorGetAssertion 操作から返されたcredential IDのバイト列に設定する（詳細は§ 6.3.3 authenticatorGetAssertion 操作参照）。

      clientDataJSONResult

      値は clientDataJSON のバイト列。

      authenticatorDataResult

      値は、認証器データ（認証器が返す）のバイト列。

      signatureResult

      値は、認証器が返す署名値のバイト列。

      userHandleResult

      認証器がuser handleを返した場合、そのバイト列をuserHandleResultの値とし、返さない場合はnull。

      clientExtensionResults

      値は AuthenticationExtensionsClientOutputs オブジェクトで、extension identifier → client extension output のエントリーを含む。各拡張のクライアント拡張処理アルゴリズムを実行してclient extension outputsを作成する。対象は options.extensions 内の各client extension。

    3. constructAssertionAlg を、global object global を引数に取り、次の手順を持つアルゴリズムとする：

      1. pubKeyCred を新しい PublicKeyCredential オブジェクト（globalに紐付く）とし、フィールドは次の通り：

        [[identifier]]

        globalの%ArrayBuffer%を使い、assertionCreationData.credentialIdResult のバイト列で新しい ArrayBuffer を作成する。

        response

        globalに紐付く新しい AuthenticatorAssertionResponse オブジェクトで、フィールドは次の通り：

        clientDataJSON

        globalの%ArrayBuffer%を使い、assertionCreationData.clientDataJSONResult のバイト列で新しい ArrayBuffer を作成する。

        authenticatorData

        globalの%ArrayBuffer%を使い、assertionCreationData.authenticatorDataResult のバイト列で新しい ArrayBuffer を作成する。

        signature

        globalの%ArrayBuffer%を使い、assertionCreationData.signatureResult のバイト列で新しい ArrayBuffer を作成する。

        userHandle

        assertionCreationData.userHandleResult がnullならこのフィールドもnull。そうでなければ、globalの%ArrayBuffer%を使い、assertionCreationData.userHandleResult のバイト列で新しい ArrayBuffer を作成する。

        [[clientExtensionsResults]]

        globalの%ArrayBuffer%を使い、assertionCreationData.clientExtensionResults のバイト列で新しい ArrayBuffer を作成する。

      2. pubKeyCred を返す。

    4. 残りの authenticator について issuedRequests 内で authenticatorCancel 操作を呼び出し、issuedRequests から削除する。

    5. constructAssertionAlg を返し、このアルゴリズムを終了する。

  18. 名前が "NotAllowedError" の DOMException を返す。 ユーザーの同意なしに識別情報漏洩を防ぐため、このステップは lifetimeTimer が期限切れになるまで実行してはならない。詳細は § 14.5.2 認証式プライバシー参照。

上記の処理中、ユーザーエージェントはユーザーに対して、認証器の選択および認可の操作を完了するためのガイドとなるUIを表示すべきです。

5.1.5. 既存の認証情報の保存 - PublicKeyCredential の [[Store]](credential, sameOriginWithAncestors) メソッド

[[Store]](credential, sameOriginWithAncestors) メソッドは Web Authentication の PublicKeyCredential 型に対してサポートされていませんので、常にエラーを返します。

注: このアルゴリズムは同期的です。Promise の解決・拒否は navigator.credentials.store() によって制御されます。

この内部メソッドは2つの引数を受け取ります：

credential

この引数は PublicKeyCredential オブジェクトです。

sameOriginWithAncestors

この引数は Boolean 値であり、呼び出し元の 環境設定オブジェクトが祖先と同一オリジンの場合のみ true となります。

このメソッドが呼び出されると、ユーザーエージェントは以下のアルゴリズムを必ず実行しなければなりません：

  1. 名前が "NotSupportedError" の DOMException を返し、このアルゴリズムを終了する。

5.1.6. 既存認証情報へのサイレントアクセス防止 - PublicKeyCredential の [[preventSilentAccess]](credential, sameOriginWithAncestors) メソッド

[[preventSilentAccess]](credential, sameOriginWithAncestors) メソッドを呼び出しても、認可ジェスチャーを必要とする認証器には影響はありませんが、このフラグを設定することでユーザー操作なしで動作可能な認証器が除外される可能性があります。

この内部メソッドは引数を受け取りません。

5.1.7. ユーザー検証型プラットフォーム認証器の利用可能性 - PublicKeyCredential の isUserVerifyingPlatformAuthenticatorAvailable() メソッド

WebAuthn Relying Party はこのメソッドを使い、ユーザー検証型プラットフォーム認証器を使って新しい認証情報を作成できるかどうかを判定します。 呼び出し時、クライアントはクライアントプラットフォーム固有の手順で利用可能なユーザー検証型プラットフォーム認証器を発見します。 いずれかが発見された場合、promise は true で解決されます。 見つからない場合は false で解決されます。 結果に応じて、Relying Party はユーザーに認証情報を作成するよう促すなどの追加対応が可能です。

このメソッドは引数を持たず、Boolean値を返します。

PublicKeyCredential/isUserVerifyingPlatformAuthenticatorAvailable

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
OperaNoneEdge79+
Edge (Legacy)18IENone
Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung InternetNoneOpera MobileNone 
partial interface PublicKeyCredential {
    static Promise<boolean> isUserVerifyingPlatformAuthenticatorAvailable();
};

注: ブラウジングコンテキストからこのメソッドを呼び出し、Web Authentication API が allowed to use アルゴリズム（すなわち パーミッションポリシー）によって「無効化」されている場合、promise は名前が "NotAllowedError" の DOMException で拒否されます。 詳細は § 5.9 パーミッションポリシー統合 も参照してください。

5.2. 認証器レスポンス（インターフェース AuthenticatorResponse）

AuthenticatorResponse

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
OperaNoneEdge79+
Edge (Legacy)18IENone
Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung InternetNoneOpera MobileNone

認証器は Relying Party のリクエストに対し、AuthenticatorResponse インターフェースから派生したオブジェクトを返します：

[SecureContext, Exposed=Window]
interface AuthenticatorResponse {
    [SameObject] readonly attribute ArrayBuffer      clientDataJSON;
};

AuthenticatorResponse/clientDataJSON

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
OperaNoneEdge79+
Edge (Legacy)18IENone
Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung InternetNoneOpera MobileNone

clientDataJSON, 型は ArrayBuffer、readonly

この属性には、JSON互換シリアライズされた クライアントデータが含まれます。その ハッシュ値が、 クライアントから認証器へ create() または get() を呼び出した際に渡されます（つまり、クライアントデータ自体は認証器に送信されません）。

5.2.1. 公開鍵認証情報に関する情報（インターフェース AuthenticatorAttestationResponse）

AuthenticatorAttestationResponse

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
OperaNoneEdge79+
Edge (Legacy)18IENone
Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet10.0+Opera MobileNone

AuthenticatorAttestationResponse インターフェースは、クライアントが新しい 公開鍵認証情報の作成をリクエストした際に認証器から返されるレスポンスを表します。後で利用するために認証情報を識別できる情報や、登録時に WebAuthn Relying Party が認証情報の特徴を評価するためのメタデータを含みます。

AuthenticatorAttestationResponse/getTransports

現行標準のどのエンジンでも利用不可。

FirefoxNoneSafariNoneChromeNone
OperaNoneEdgeNone
Edge (Legacy)NoneIENone
Firefox for AndroidNoneiOS SafariNoneChrome for AndroidNoneAndroid WebViewNoneSamsung InternetNoneOpera MobileNone 
[SecureContext, Exposed=Window]
interface AuthenticatorAttestationResponse : AuthenticatorResponse {
    [SameObject] readonly attribute ArrayBuffer      attestationObject;
    sequence<DOMString>                              getTransports();
    ArrayBuffer                                      getAuthenticatorData();
    ArrayBuffer?                                     getPublicKey();
    COSEAlgorithmIdentifier                          getPublicKeyAlgorithm();
};
clientDataJSON

この属性は AuthenticatorResponse から継承されており、認証器がこの認証情報を生成するためにクライアントから渡された クライアントデータのJSON互換シリアライズ を含みます（詳細は § 6.5 認証証明 参照）。このJSONシリアライズは厳密に保存されなければなりません。なぜなら、シリアライズされたクライアントデータのハッシュ値がこの内容で計算されているためです。

AuthenticatorAttestationResponse/attestationObject

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
OperaNoneEdge79+
Edge (Legacy)18IENone
Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet10.0+Opera MobileNone

attestationObject, 型は ArrayBuffer、readonly

この属性には 認証証明オブジェクトが含まれます。このオブジェクトはクライアントからは不透明であり、改ざんに対して暗号的に保護されています。認証証明オブジェクトは 認証器データと 認証証明文の両方を含みます。前者には AAGUID（認証器識別子）、一意な 認証情報ID、認証情報公開鍵が含まれます。認証証明文の内容は認証器が使用する認証証明文フォーマットによって決まります。また、Relying Party のサーバーが認証証明文の検証や 認証器データのデコード・検証、および クライアントデータのJSON互換シリアライズの検証に必要な追加情報も含みます。詳細は § 6.5 認証証明、§ 6.5.4 認証証明オブジェクトの生成、 図6 を参照してください。

getTransports()

この操作は [[transports]] の値を返します。

getAuthenticatorData()

この操作は attestationObject に含まれる 認証器データを返します。詳細は § 5.2.1.1 認証情報データの容易な取得 を参照してください。

getPublicKey()

この操作は新しい認証情報の DER形式の SubjectPublicKeyInfo を返します。取得できない場合は null を返します。詳細は § 5.2.1.1 認証情報データの容易な取得 を参照してください。

getPublicKeyAlgorithm()

この操作は新しい認証情報の COSEAlgorithmIdentifier を返します。詳細は § 5.2.1.1 認証情報データの容易な取得 を参照してください。

[[transports]]

この内部スロットには、辞書順で並んだ0個以上の一意な DOMString のシーケンスが格納されます。これらの値は認証器が対応すると考えられるトランスポート種別、または情報が取得できなければ空シーケンスです。値は AuthenticatorTransport のメンバーであるべきですが、Relying Party は未知の値を無視しなければなりません。

5.2.1.1. 認証情報データの容易な取得

[[Create]](origin, options, sameOriginWithAncestors) メソッドを利用する全てのユーザーは、将来の認証アサーションの検証のため、返された 認証情報公開鍵 をパースして保存する必要があります。しかし、認証情報公開鍵は [RFC8152]（COSE）フォーマットであり、attestedCredentialData の credentialPublicKey メンバー内、さらに authenticator data 内、さらに attestation object 内に格納されています。この attestation object は AuthenticatorAttestationResponse の attestationObject から取得できます。 Relying Party が 認証証明を利用したい場合は、attestationObjectをパースし 認証情報公開鍵 を取得する必要があります。なぜなら、この公開鍵コピーが 認証器によって 署名されたからです。しかし、WebAuthnの多くの有効なユースケースでは 認証証明は不要です。これらの用途では、ユーザーエージェントがパース処理を行い、authenticator data を直接公開したり、認証情報公開鍵をより便利な形式で変換して提供できます。

getPublicKey() 操作は、認証情報公開鍵を SubjectPublicKeyInfo 形式で返します。この ArrayBuffer は、例えば Java の java.security.spec.X509EncodedKeySpec、.NET の System.Security.Cryptography.ECDsa.ImportSubjectPublicKeyInfo、Go の crypto/x509.ParsePKIXPublicKey などに渡すことができます。

getPublicKey() を利用する場合、いくつかの制限があります：pubKeyCredParams を使うことで、Relying Partyはユーザーエージェントが理解できない公開鍵アルゴリズムを認証器とネゴシエートすることが可能です。しかし、その場合はユーザーエージェントが 認証情報公開鍵を SubjectPublicKeyInfo 形式に変換できず getPublicKey() の戻り値は null となります。

ユーザーエージェントは、認証情報公開鍵の COSEAlgorithmIdentifier が次の値の場合、getPublicKey() で非null値を返せなければなりません：

SubjectPublicKeyInfo には、COSE公開鍵に含まれる署名アルゴリズム（例：使用するハッシュ関数等）の情報は含まれていません。これを提供するために、getPublicKeyAlgorithm() は 認証情報公開鍵の COSEAlgorithmIdentifier を返します。

多くの場合CBORのパース自体が不要となるように、getAuthenticatorData() は attestationObject から authenticator data を返します。authenticator data には他にもバイナリ形式でエンコードされたフィールドがありますが、これらを取得する補助関数は提供されません。なぜなら、Relying Partyは アサーション取得時にこれらのフィールドを既に抽出する必要があるためです。認証情報作成（credential creation）とは対照的に、署名検証は オプションですが、Relying Partyは常にアサーションの署名を検証すべきであり、署名付き authenticator data からフィールド抽出が必要です。同じ関数が認証情報作成時にも役立ちます。

注: getPublicKey() および getAuthenticatorData() は本仕様のレベル2で追加されました。Relying Partyは、'getPublicKey' in AuthenticatorAttestationResponse.prototype でこれらの関数の有無を判定するフィーチャーディテクションを利用すべきです。この関数が必要な Relying Partyは、古いユーザーエージェントとの相互運用性が失われる可能性があります。

5.2.2. Web認証アサーション（インターフェース AuthenticatorAssertionResponse）

AuthenticatorAssertionResponse

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
OperaNoneEdge79+
Edge (Legacy)18IENone
Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung InternetNoneOpera MobileNone

AuthenticatorAssertionResponse インターフェースは、クライアントが WebAuthn Relying Party からのチャレンジおよび認証情報リスト（オプション）を受け取り、新しい 認証アサーションの生成をリクエストした際の認証器レスポンスを表します。このレスポンスには、認証情報秘密鍵の保有証明となる暗号署名と、オプションで特定トランザクションへのユーザー同意の証拠が含まれます。

[SecureContext, Exposed=Window]
interface AuthenticatorAssertionResponse : AuthenticatorResponse {
    [SameObject] readonly attribute ArrayBuffer      authenticatorData;
    [SameObject] readonly attribute ArrayBuffer      signature;
    [SameObject] readonly attribute ArrayBuffer?     userHandle;
};
clientDataJSON

この属性は AuthenticatorResponse から継承されており、認証器がこのアサーションを生成するためにクライアントから渡された クライアントデータのJSON互換シリアライズ（詳細は § 5.8.1 WebAuthn署名に使用されるクライアントデータ（dictionary CollectedClientData）参照）が含まれます。このJSONシリアライズは厳密に保存されなければなりません。なぜなら、シリアライズされたクライアントデータのハッシュ値がこの内容で計算されているためです。

AuthenticatorAssertionResponse/authenticatorData

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
OperaNoneEdge79+
Edge (Legacy)18IENone
Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung InternetNoneOpera MobileNone

authenticatorData, 型は ArrayBuffer、readonly

この属性は、認証器が返す authenticator data を含みます。詳細は § 6.1 認証器データ を参照してください。

AuthenticatorAssertionResponse/signature

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
OperaNoneEdge79+
Edge (Legacy)18IENone
Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung InternetNoneOpera MobileNone

signature, 型は ArrayBuffer、readonly

この属性は認証器が返す生の署名値を含みます。詳細は § 6.3.3 authenticatorGetAssertion操作 を参照してください。

AuthenticatorAssertionResponse/userHandle

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
OperaNoneEdge79+
Edge (Legacy)18IENone
Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung InternetNoneOpera MobileNone

userHandle, 型は ArrayBuffer、readonly, nullable

この属性は認証器が返す user handle を含みます。認証器が user handle を返さなかった場合は null となります。詳細は § 6.3.3 authenticatorGetAssertion操作 を参照してください。

5.3. 認証情報生成のためのパラメータ（dictionary PublicKeyCredentialParameters）

dictionary PublicKeyCredentialParameters {
    required DOMString                    type;
    required COSEAlgorithmIdentifier      alg;
};
このdictionaryは新しい認証情報を作成する際に追加パラメータを指定するために使用されます。
type, 型 DOMString

このメンバーは作成する認証情報の種類を指定します。値は PublicKeyCredentialType のメンバーであるべきですが、クライアントプラットフォームは未知の値を無視し、未知の PublicKeyCredentialParameters は無視しなければなりません。

alg, 型 COSEAlgorithmIdentifier

このメンバーは新たに生成される認証情報で使用する暗号署名アルゴリズム、および生成される非対称鍵ペアの種別（例：RSAや楕円曲線）を指定します。

注: このメンバー名が"algorithm"ではなく"alg"なのは、認証器へのメッセージとしてシリアライズされる際に低帯域通信を考慮したためです。

5.4. 認証情報作成のためのオプション（dictionary PublicKeyCredentialCreationOptions）

PublicKeyCredentialCreationOptions

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
Opera54+Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewNoneSamsung InternetNoneOpera Mobile48+ 
dictionary PublicKeyCredentialCreationOptions {
    required PublicKeyCredentialRpEntity         rp;
    required PublicKeyCredentialUserEntity       user;

    required BufferSource                             challenge;
    required sequence<PublicKeyCredentialParameters>  pubKeyCredParams;

    unsigned long                                timeout;
    sequence<PublicKeyCredentialDescriptor>      excludeCredentials = [];
    AuthenticatorSelectionCriteria               authenticatorSelection;
    DOMString                                    attestation = "none";
    AuthenticationExtensionsClientInputs         extensions;
};

PublicKeyCredentialCreationOptions/rp

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
Opera54+Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewNoneSamsung InternetNoneOpera Mobile48+

rp, 型 PublicKeyCredentialRpEntity

このメンバーはリクエストの責任を持つRelying Partyに関するデータを含みます。

値の name メンバーは必須です。詳細は § 5.4.1 公開鍵エンティティの説明（dictionary PublicKeyCredentialEntity）を参照してください。

値の id メンバーは、認証情報がRP IDにスコープされるべきことを指定します。省略された場合、値は CredentialsContainer オブジェクトの 関連設定オブジェクトの origin の 有効ドメインになります。詳細は § 5.4.2 認証情報生成のRelying Partyパラメータ（dictionary PublicKeyCredentialRpEntity）を参照してください。

PublicKeyCredentialCreationOptions/user

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
Opera54+Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewNoneSamsung InternetNoneOpera Mobile48+

user, 型 PublicKeyCredentialUserEntity

このメンバーは、Relying Partyが認証証明を要求するユーザーアカウントに関するデータを含みます。

値の name、 displayName 、 id メンバーは必須です。詳細は § 5.4.1 公開鍵エンティティの説明（dictionary PublicKeyCredentialEntity）および § 5.4.3 認証情報生成のユーザーアカウントパラメータ（dictionary PublicKeyCredentialUserEntity）を参照してください。

PublicKeyCredentialCreationOptions/challenge

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
Opera54+Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewNoneSamsung InternetNoneOpera Mobile48+

challenge, 型 BufferSource

このメンバーは、新しく作成された認証情報の認証証明オブジェクト生成に使われるチャレンジを含みます。セキュリティ考慮事項は § 13.4.3 暗号チャレンジ を参照してください。

PublicKeyCredentialCreationOptions/pubKeyCredParams

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
Opera54+Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewNoneSamsung InternetNoneOpera Mobile48+

pubKeyCredParams, 型 sequence<PublicKeyCredentialParameters>

このメンバーは生成される認証情報の希望するプロパティを含みます。シーケンスは希望度の高い順で並んでいます。クライアントはできる限り希望度の高い認証情報の生成を試みます。

PublicKeyCredentialCreationOptions/timeout

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
Opera54+Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewNoneSamsung InternetNoneOpera Mobile48+

timeout, 型 unsigned long

このメンバーは呼び出し元が完了まで待つ許容時間（ミリ秒）を指定します。これはヒントとして扱われ、クライアントによって上書きされる場合があります。

PublicKeyCredentialCreationOptions/excludeCredentials

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
Opera54+Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewNoneSamsung InternetNoneOpera Mobile48+

excludeCredentials, 型 sequence<PublicKeyCredentialDescriptor>, 既定値 []

このメンバーは、同じ認証器で同一アカウントに対して複数の認証情報作成を制限したいRelying Party向けです。新しい認証情報がこのパラメータで列挙された認証情報と同じ認証器で作成される場合、クライアントはエラーを返すよう要求されます。

PublicKeyCredentialCreationOptions/authenticatorSelection

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
Opera54+Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewNoneSamsung InternetNoneOpera Mobile48+

authenticatorSelection, 型 AuthenticatorSelectionCriteria

このメンバーは、Relying Partyが作成処理に参加させたい認証器を選択するために利用します。

PublicKeyCredentialCreationOptions/attestation

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
Opera54+Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewNoneSamsung InternetNoneOpera Mobile48+

attestation, 型 DOMString、既定値 "none"

このメンバーはRelying Partyがattestationの伝達方法に関する希望を示すために利用します。 値は AttestationConveyancePreference のメンバーであるべきです。 クライアントプラットフォームは未知の値を無視し、未知の値は メンバーが存在しないかのように扱わなければなりません。 既定値は "none" です。

extensions, 型 AuthenticationExtensionsClientInputs

このメンバーはクライアントや認証器に追加処理を要求する追加パラメータを含みます。例えば、呼び出し元は特定の機能を持つ認証器のみで認証情報を作成するよう要求したり、認証証明オブジェクトに特定情報の返却を要求する場合があります。いくつかの拡張は § 9 WebAuthn拡張で定義されており、最新の拡張リストは [IANA-WebAuthn-Registries]（[RFC8809]により設立）で確認できます。

5.4.1. 公開鍵エンティティの説明（dictionary PublicKeyCredentialEntity）

PublicKeyCredentialEntity 辞書は、ユーザーアカウントまたは WebAuthn Relying Party を記述するもので、公開鍵認証情報が紐付けられる、またはスコープされる対象となります。 

dictionary PublicKeyCredentialEntity {
    required DOMString    name;
};
name, 型 DOMString

エンティティの人間が判別しやすい名前です。役割は PublicKeyCredentialEntity が何を表すかによって異なります：

クライアント、クライアントプラットフォーム、認証器がname値を表示する場合、必ずUI要素で表示値の明確な枠を提供し、他要素へのオーバーフローを許してはなりません [css-overflow-3]。

認証器はname値を保存する場合、64バイト以内に収まるように値を切り詰めても構いません。詳細は § 6.4.1 文字列切り詰めを参照してください。

5.4.2. 認証情報生成のためのRelying Partyパラメータ（dictionary PublicKeyCredentialRpEntity）

PublicKeyCredentialRpEntity 辞書は新しい認証情報作成時に追加の Relying Party属性を指定するために使用されます。

dictionary PublicKeyCredentialRpEntity : PublicKeyCredentialEntity {
    DOMString      id;
};
id, 型 DOMString

Relying Partyエンティティの一意の識別子で、RP IDを設定します。

5.4.3. 認証情報生成のためのユーザーアカウントパラメータ（dictionary PublicKeyCredentialUserEntity）

PublicKeyCredentialUserEntity 辞書は新しい認証情報作成時に追加のユーザーアカウント属性を指定するために使用されます。

dictionary PublicKeyCredentialUserEntity : PublicKeyCredentialEntity {
    required BufferSource   id;
    required DOMString      displayName;
};
id, 型 BufferSource

ユーザーアカウントエンティティのuser handleです。 user handleは最大64バイトの不透明なバイト列であり、ユーザーへ表示することは想定されていません。

安全な運用のため、認証および認可の判断はこのid メンバーに基づいて行う必要があり、displayNameやnameメンバーを基にしてはなりません。詳細は [RFC8266] Section 6.1 参照。

user handleにはユーザー名やメールアドレスなどの個人識別情報を含めてはなりません。詳細は § 14.6.1 ユーザーハンドルの内容参照。user handleは空であってはなりませんが、nullであっても構いません。

注: user handleは、非発見可能認証情報であっても、異なるアカウント間で定数値とすべきではありません。なぜなら、一部認証器は常に発見可能認証情報を作成するため、定数のuser handleでは、ユーザーが同じ認証器を使って同じRelying Partyで複数アカウントを利用できなくなります。

displayName, 型 DOMString

ユーザーアカウントの人間が判別しやすい名前で、表示専用です。例: "Alex Müller" や "田中倫" など。Relying Partyはユーザーにこの値を選択させ、必要以上に制限すべきではありません。

クライアント、クライアントプラットフォーム、認証器がdisplayName値を表示する場合、必ずUI要素で表示値の明確な枠を提供し、他要素へのオーバーフローを許してはなりません [css-overflow-3]。

認証器はdisplayName値を64バイト以上格納できなければならず、64バイト以内に収まるように値を切り詰めても構いません。詳細は § 6.4.1 文字列切り詰め参照。

5.4.4. 認証器選択基準（dictionary AuthenticatorSelectionCriteria）

WebAuthn Relying Partyは AuthenticatorSelectionCriteria 辞書を使って認証器属性に関する要件を指定できます。

dictionary AuthenticatorSelectionCriteria {
    DOMString                    authenticatorAttachment;
    DOMString                    residentKey;
    boolean                      requireResidentKey = false;
    DOMString                    userVerification = "preferred";
};
authenticatorAttachment, 型 DOMString

このメンバーが存在する場合、適格な認証器は指定された § 5.4.5 認証器接続種別（enum AuthenticatorAttachment） で接続されているものだけに絞り込まれます。値は AuthenticatorAttachment のメンバーであるべきですが、クライアントプラットフォームは未知の値を無視し、未知の値は メンバーが存在しないかのように扱わなければなりません。

residentKey, 型 DOMString

Relying Partyがクライアントサイド発見可能認証情報をどの程度希望するかを指定します。歴史的な理由で"resident"用語が使われていますが、これは廃止予定です。値は ResidentKeyRequirement のメンバーであるべきですが、クライアントプラットフォームは未知の値を無視し、未知の値は メンバーが存在しないかのように扱わなければなりません。値が指定されない場合、requireResidentKey が true なら required、 falseまたは未指定なら discouraged となります。

ResidentKeyRequirement で residentKeyの値と意味を説明しています。

requireResidentKey, 型 boolean、既定値 false

このメンバーはWebAuthn Level 1との後方互換性のために残されており、歴史的な理由で"resident"用語が使われています（発見可能認証情報のこと）。Relying Partyは、residentKey が requiredのときのみ true にすべきです。

userVerification, 型 DOMString、既定値 "preferred"

このメンバーは Relying Partyが create() 操作においてユーザー検証に関する要件を記述します。適格な認証器はこの要件を満たせるものだけに絞り込まれます。値は UserVerificationRequirement のメンバーであるべきですが、クライアントプラットフォームは未知の値を無視し、未知の値は メンバーが存在しないかのように扱わなければなりません。

5.4.5. 認証器接続種別（enum AuthenticatorAttachment）

この列挙型の値は認証器の接続様式を表します。Relying Partyは、navigator.credentials.create() を呼び出して認証情報を作成する際、希望する認証器接続様式を表明するためにこれを使います。

enum AuthenticatorAttachment {
    "platform",
    "cross-platform"
};

注: AuthenticatorAttachment 列挙型は意図的に参照されていません。詳細は § 2.1.1 DOMString型列挙について参照。

platform

この値はプラットフォーム接続を示します。

cross-platform

この値はクロスプラットフォーム接続を示します。

注: 認証器接続様式選択オプションは [[Create]](origin, options, sameOriginWithAncestors) 操作でのみ利用可能です。Relying Partyは例えば、他のクライアントデバイスで認証するためのローミング認証情報を確保したり、特定のクライアントデバイスで容易に再認証できるようプラットフォーム認証情報を登録したりするためにこれを利用できます。[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)操作では認証器接続様式選択オプションはありません。そのため、Relying Partyはユーザーが登録した認証情報をすべて受け入れるべきです。クライアントとユーザーは、その時点で利用可能かつ便利なものを利用します。

5.4.6. リジデントキー要件列挙型（enum ResidentKeyRequirement）

enum ResidentKeyRequirement {
    "discouraged",
    "preferred",
    "required"
};

注: ResidentKeyRequirement 列挙型は意図的に参照されていません。詳細は § 2.1.1 DOMString型列挙について参照。

この列挙型の値はRelying Partyがクライアントサイド発見可能認証情報（旧称：リジデント認証情報またはリジデントキー）に対して求める要件を表します：

discouraged

この値は Relying Partyがサーバーサイド認証情報の作成を好むことを示しますが、クライアントサイド発見可能認証情報も許容します。

注: Relying Partyは作成された認証情報がサーバーサイド認証情報であることを強制できず、Credential Properties Extensionは rk プロパティの値を返さない場合があります。そのため、認証情報がサーバーサイド認証情報かどうか分からず、同じuser handleで2つ目を作ると1つ目が消える場合もあります。

preferred

この値は Relying Partyがクライアントサイド発見可能認証情報の作成を強く希望しますが、サーバーサイド認証情報も許容します。例えば、この場合ユーザーエージェントはユーザー検証の設定を案内すべきです（発見可能認証情報作成時）。この値はuserVerificationの設定より優先されます。

required

この値は Relying Partyがクライアントサイド発見可能認証情報の作成を必須とし、作成できない場合はエラーを受け入れることを意味します。

注: Relying Partyは認証器がクライアントサイド発見可能認証情報を作成したかどうかを、Credential Properties Extensionの返り値と options.authenticatorSelection.residentKey で判断できます。 discouraged や preferred を options.authenticatorSelection.residentKey に設定した場合、認証器はどちらも作成し得ます。

5.4.7. 認証証明伝達希望列挙型（enum AttestationConveyancePreference）

WebAuthn Relying Partyは、認証情報生成時の認証証明伝達に関する希望を AttestationConveyancePreference で指定できます。

enum AttestationConveyancePreference {
    "none",
    "indirect",
    "direct",
    "enterprise"
};

注: AttestationConveyancePreference 列挙型は意図的に参照されていません。詳細は § 2.1.1 DOMString型列挙について参照。

none

この値はRelying Partyが認証器の認証証明に関心がないことを示します。例えば、ユーザーの同意を得て識別情報をRelying Partyに中継する必要を避けたり、認証証明CAや匿名化CAへの往復通信を省略したりする場合です。

これが既定値です。

indirect

この値はRelying Partyが検証可能な認証証明の取得を希望するが、取得方法はクライアント側に委ねることを示します。クライアントは、認証器が生成した認証証明文を匿名化CAで生成したものに置き換えることもでき、これによりユーザーのプライバシー保護や、異種環境での認証証明検証の補助が可能になります。

注: この場合、Relying Partyが検証可能な認証証明文を必ず取得できる保証はありません。例えば認証器が自己認証証明を使う場合などです。

direct

この値はRelying Partyが認証器が生成した認証証明文をそのまま受け取りたいことを示します。

enterprise

この値はRelying Partyが一意に識別可能な情報を含む認証証明文の取得を希望することを示します。これは企業内の管理された展開で、特定認証器への登録を紐付けたい場合に用いられます。ユーザーエージェントは、ユーザーエージェントまたは認証器の設定が要求されたRP IDに対して許可されている場合以外、こうした認証証明の提供を行ってはなりません。

許可された場合、ユーザーエージェントは認証器に（呼び出し時）企業認証証明が要求されていることを通知すべきであり、結果のAAGUIDおよび認証証明文を加工せずRelying Partyに伝えるべきです。

5.5. アサーション生成のためのオプション（dictionary PublicKeyCredentialRequestOptions）

PublicKeyCredentialRequestOptions

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
Opera54+Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetNoneOpera Mobile48+

PublicKeyCredentialRequestOptions 辞書は get() にアサーション生成に必要なデータを渡します。challenge メンバーは必須であり、その他のメンバーは任意です。

dictionary PublicKeyCredentialRequestOptions {
    required BufferSource                challenge;
    unsigned long                        timeout;
    USVString                            rpId;
    sequence<PublicKeyCredentialDescriptor> allowCredentials = [];
    DOMString                            userVerification = "preferred";
    AuthenticationExtensionsClientInputs extensions;
};

PublicKeyCredentialRequestOptions/challenge

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
Opera54+Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetNoneOpera Mobile48+

challenge, 型 BufferSource

このメンバーは、選択された認証器が認証アサーション生成時に他データとともに署名するチャレンジを表します。セキュリティ考慮事項は§ 13.4.3 暗号チャレンジ参照。

PublicKeyCredentialRequestOptions/timeout

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
Opera54+Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetNoneOpera Mobile48+

timeout, 型 unsigned long

この任意メンバーは、呼び出し元が完了まで待つ許容時間（ミリ秒）を指定します。これはヒントとして扱われ、クライアントによって上書きされる場合があります。

PublicKeyCredentialRequestOptions/rpId

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
Opera54+Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetNoneOpera Mobile48+

rpId, 型 USVString

この任意メンバーは、呼び出し元が主張するRelying Party識別子を指定します。省略された場合、値は CredentialsContainer オブジェクトの 関連設定オブジェクトの origin の 有効ドメインとなります。

PublicKeyCredentialRequestOptions/allowCredentials

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
Opera54+Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetNoneOpera Mobile48+

allowCredentials, 型 sequence<PublicKeyCredentialDescriptor>、 既定値 []

この任意メンバーは、呼び出し元が許容する公開鍵認証情報を表す PublicKeyCredentialDescriptor オブジェクトのリストです。リストは呼び出し元の希望度が高い順（先頭ほど優先度が高い認証情報）となります。

PublicKeyCredentialRequestOptions/userVerification

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
Opera54+Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetNoneOpera Mobile48+

userVerification, 型 DOMString、既定値 "preferred"

この任意メンバーは、Relying Partyが get() 操作においてユーザー検証に関する要件を記述します。値は UserVerificationRequirement のメンバーであるべきですが、クライアントプラットフォームは未知の値を無視し、未知の値は メンバーが存在しないかのように扱わなければなりません。適格な認証器はこの要件を満たせるものだけに絞り込まれます。

PublicKeyCredentialCreationOptions/extensions

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
Opera54+Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetNoneOpera Mobile48+

PublicKeyCredentialRequestOptions/extensions

現行標準の全てのエンジンで利用可能。

Firefox60+Safari13+Chrome67+
Opera54+Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetNoneOpera Mobile48+

extensions, 型 AuthenticationExtensionsClientInputs

この任意メンバーは、クライアントや認証器に追加処理を要求する追加パラメータを含みます。例えば、トランザクション確認をユーザーから取得したい場合、プロンプト文字列を拡張として含めることがあります。

5.6. AbortSignalによる操作の中断

開発者は、AbortController を利用して [[Create]](origin, options, sameOriginWithAncestors) や [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) の操作を管理することが推奨されます。 詳しい手順については DOM §3.3 AbortControllerとAbortSignalオブジェクトのAPI統合のセクションを参照してください。

注: DOM §3.3 AbortControllerとAbortSignalオブジェクトのAPI統合のセクションでは、AbortControllerと統合されたWebプラットフォームAPIは、aborted flagがセットされた時点でpromiseを即座にrejectしなければならないと規定されています。 [[Create]](origin, options, sameOriginWithAncestors) と [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) のメソッドは複雑な継承構造と並列処理構造を持つため、両APIのアルゴリズムは aborted flag を3箇所でチェックすることでこの要件を満たしています。[[Create]](origin, options, sameOriginWithAncestors) の場合、最初は Credential Management 1 §2.5.4 Credentialの作成で [[Create]](origin, options, sameOriginWithAncestors) を呼び出す直前、 次に § 5.1.3 新規認証情報の作成 - PublicKeyCredentialの[[Create]](origin, options, sameOriginWithAncestors)メソッドで認証器セッション開始直前、 最後に認証器セッション中です。[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) でも同様です。

visibilityおよびfocusの状態は、Windowオブジェクトに対して、[[Create]](origin, options, sameOriginWithAncestors) や [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) の操作を継続するかどうかを決定します。関連づけられた [Document] のWindowオブジェクトがフォーカスを失った場合、[[Create]](origin, options, sameOriginWithAncestors) や [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) の操作は中断すべきです。

WHATWG HTML WGでは、ブラウジングコンテキストがフォーカスを獲得・喪失した際にフックを提供するか議論中です。フックが提供された場合は上記の段落が更新されます。 詳細は WHATWG HTML WG Issue #2711 を参照してください。

5.7. WebAuthn拡張の入力と出力

以下のサブセクションでは、WebAuthn拡張の入力・出力に使われるデータ型を定義します。

注: 認証器拡張出力は認証器データ（表1参照）の一部として伝達されます。

注: 以下で定義される型 — AuthenticationExtensionsClientInputs および AuthenticationExtensionsClientOutputs — は、登録拡張と認証拡張の両方に適用されます。「Authentication...」という名前の部分は「WebAuthentication...」と読み替えてください。

5.7.1. 認証拡張クライアント入力（dictionary AuthenticationExtensionsClientInputs）

dictionary AuthenticationExtensionsClientInputs {
};

これは、0個以上のWebAuthn拡張に対するクライアント拡張入力値を格納する辞書です。

5.7.2. 認証拡張クライアント出力（dictionary AuthenticationExtensionsClientOutputs）

dictionary AuthenticationExtensionsClientOutputs {
};

これは、0個以上のWebAuthn拡張に対するクライアント拡張出力値を格納する辞書です。

5.7.3. 認証拡張認証器入力（CDDL型 AuthenticationExtensionsAuthenticatorInputs）

AuthenticationExtensionsAuthenticatorInputs = {
  * $$extensionInput .within ( tstr => any )
}

CDDL型 AuthenticationExtensionsAuthenticatorInputsは、0個以上のWebAuthn拡張に対する認証器拡張入力値を格納するCBORマップを定義します。 拡張は § 9.3 拡張リクエストパラメータの拡張で説明されているようにメンバーを追加できます。

この型はRelying Partyには公開されませんが、クライアントおよび認証器で使用されます。

5.7.4. 認証拡張認証器出力（CDDL型 AuthenticationExtensionsAuthenticatorOutputs）

AuthenticationExtensionsAuthenticatorOutputs = {
  * $$extensionOutput .within ( tstr => any )
}

CDDL型 AuthenticationExtensionsAuthenticatorOutputsは、0個以上のWebAuthn拡張に対する認証器拡張出力値を格納するCBORマップを定義します。 拡張は § 9.3 拡張リクエストパラメータの拡張で説明されているようにメンバーを追加できます。

5.8. 補助データ構造

公開鍵認証情報型は、補助仕様で定義されたいくつかのデータ構造を利用します。以下に示します。

5.8.1. WebAuthn署名に使用されるクライアントデータ（dictionary CollectedClientData）

クライアントデータは、WebAuthn Relying Partyとクライアントの文脈的な結び付きを表します。キーが文字列となるキー-値マッピングであり、値はJSONとして有効なエンコーディングを持つ任意の型です。構造は以下のWeb IDLで定義されます。

注: CollectedClientData は将来的に拡張される可能性があります。そのためパース時には未知のキーやキーの順序変更にも寛容にすることが重要です。また、§ 5.8.1.2 制限付き検証アルゴリズムも参照してください。

dictionary CollectedClientData {
    required DOMString           type;
    required DOMString           challenge;
    required DOMString           origin;
    boolean                      crossOrigin;
    TokenBinding                 tokenBinding;
};

dictionary TokenBinding {
    required DOMString status;
    DOMString id;
};

enum TokenBindingStatus { "present", "supported" };
type, 型 DOMString

このメンバーには認証情報作成時は "webauthn.create"、既存認証情報からアサーション取得時は "webauthn.get" の文字列が入ります。このメンバーは署名の混同攻撃（攻撃者が正当な署名を別のものとすり替える）を防ぐ目的があります。

challenge, 型 DOMString

このメンバーにはRelying Partyが提供したチャレンジのbase64urlエンコーディングが入ります。セキュリティ考慮事項は§ 13.4.3 暗号チャレンジ参照。

origin, 型 DOMString

このメンバーにはリクエスター（要求元）の完全修飾オリジンが入り、クライアントから認証器へ [RFC6454] で定義された構文で渡されます。

crossOrigin, 型 boolean

このメンバーには sameOriginWithAncestors 引数値の逆（not）値が入ります。これは内部メソッドに渡されたものです。

tokenBinding, 型 TokenBinding

この任意メンバーには、Token Bindingプロトコル [TokenBinding] の状態情報が含まれます。Relying Partyとの通信時に使われます。欠落している場合はクライアントがToken Bindingに未対応であることを示します。

status, 型 DOMString

このメンバーは TokenBindingStatus のメンバーであるべきですが、クライアントプラットフォームは未知の値を無視し、未知の値は tokenBindingメンバーが存在しないものとして扱わなければなりません。既知の場合は以下のいずれかです：

supported

クライアントがToken Bindingをサポートするが、Relying Partyとの通信時にネゴシエートされなかったことを示します。

present

Relying Partyとの通信時にToken Bindingが利用されたことを示します。この場合、idメンバーが必須です。

注: TokenBindingStatus列挙型は意図的に参照されていません。詳細は§ 2.1.1 DOMString型列挙について参照。

id, 型 DOMString

このメンバーは status が present の場合に必須であり、base64urlエンコーディングされた、Relying Partyとの通信時に利用されたToken Binding IDです。

注: Token Binding IDの取得はクライアントプラットフォーム固有の処理です。

CollectedClientData 構造体は、クライアントが以下の値を計算するために使用します：

クライアントデータのJSON互換シリアライズ

これはCollectedClientData 辞書に対しJSON互換シリアライズアルゴリズムを実行した結果です。

シリアライズされたクライアントデータのハッシュ値

これはクライアントが構築したクライアントデータのJSON互換シリアライズにSHA-256で計算したハッシュ値です。

5.8.1.1. シリアライズ

CollectedClientData のシリアライズは、JSON をバイト列にシリアライズするアルゴリズムのサブセットです。すなわち、CollectedClientData の有効な JSON エンコーディングを生成しますが、検証者がフルの JSON パーサーを組み込まずとも良いような追加構造も提供します。検証者は標準的な JSON パーシングを推奨されますが、フル JSON パーサーが大きすぎる場合は以下のより限定されたアルゴリズムを利用できます。この検証アルゴリズムでは base64url エンコーディング、バイト列の連結（固定テンプレートへの書き込みなど）、および 3 つの条件分岐のみを必要とします（入力がエスケープ不要であることが前提の場合）。

シリアライズアルゴリズムは、空の部分結果から始めて、順次バイト列を追加し完全な結果になるまで進みます。

  1. result を空のバイト列とする。

  2. 0x7b2274797065223a ({"type":) を result に追加する。

  3. CCDToString(type) を result に追加する。

  4. 0x2c226368616c6c656e6765223a (,"challenge":) を result に追加する。

  5. CCDToString(challenge) を result に追加する。

  6. 0x2c226f726967696e223a (,"origin":) を result に追加する。

  7. CCDToString(origin) を result に追加する。

  8. 0x2c2263726f73734f726967696e223a (,"crossOrigin":) を result に追加する。

  9. crossOrigin が存在しない、または false の場合：

    1. 0x66616c7365 (false) を result に追加する。

  10. それ以外の場合：

    1. 0x74727565 (true) を result に追加する。

  11. CollectedClientData の一時コピーを作成し、type、 challenge、 origin、 crossOrigin を（存在する場合は）削除する。

  12. 一時コピーにフィールドが残っていない場合：

    1. 0x7d (}) を result に追加する。

  13. それ以外の場合：

    1. 一時コピーに対しJSON をバイト列にシリアライズを実行し、バイト列 remainder を得る。

    2. 0x2c (,) を result に追加する。

    3. remainder の先頭バイトを削除する。

    4. remainder を result に追加する。

  14. シリアライズの結果は result の値である。

上記アルゴリズムで使われる関数 CCDToString の定義：

  1. encoded を空のバイト列とする。

  2. 0x22 (") を encoded に追加する。

  3. 与えられたオブジェクトに ToString を呼び出し文字列へ変換する。

  4. 得られた文字列の各コードポイントについて、コードポイントが：

    {U+0020, U+0021, U+0023–U+005B, U+005D–U+10FFFF} のいずれか

    そのコードポイントの UTF-8 エンコーディングを encoded に追加する。

    U+0022 の場合

    0x5c22 (\") を encoded に追加する。

    U+005C の場合

    0x5c5c (\\) を encoded に追加する。

    その他の場合

    0x5c75 (\u) を encoded に追加し、続けてそのコードポイントを 16 進数（小文字）で表した 4 桁を追加する。

  5. 0x22 (") を encoded に追加する。

  6. この関数の結果は encoded の値である。

5.8.1.2. 限定的な検証アルゴリズム

検証者は、フルの JSON パーサーをサポートできない場合、次のアルゴリズムでエンコード済み CollectedClientData を検証できます：

  1. アルゴリズムの入力：

    1. バイト列 clientDataJSON ：検証対象のシリアライズ済み clientDataJSON

    2. 文字列 type ：期待する type

    3. バイト列 challenge ：PublicKeyCredentialRequestOptions または PublicKeyCredentialCreationOptions で与えられたチャレンジのバイト列

    4. 文字列 origin ：リクエスト発行元の期待する origin

    5. 真偽値 crossOrigin ：リクエストがクロスオリジンiframe内で実行されるべき場合のみ true

  2. expected を空のバイト列とする。

  3. 0x7b2274797065223a ({"type":) を expected に追加する。

  4. CCDToString(type) を expected に追加する。

  5. 0x2c226368616c6c656e6765223a (,"challenge":) を expected に追加する。

  6. challenge に base64url エンコーディング を施し、challengeBase64 を得る。

  7. CCDToString(challengeBase64) を expected に追加する。

  8. 0x2c226f726967696e223a (,"origin":) を expected に追加する。

  9. CCDToString(origin) を expected に追加する。

  10. 0x2c2263726f73734f726967696e223a (,"crossOrigin":) を expected に追加する。

  11. crossOrigin が true の場合：

    1. 0x74727565 (true) を expected に追加する。

  12. それ以外、すなわち crossOrigin が false の場合：

    1. 0x66616c7365 (false) を expected に追加する。

  13. expected が clientDataJSON のプレフィックスでない場合、検証は失敗。

  14. clientDataJSON の長さが expected より 1 バイト以上長くない場合、検証は失敗。

  15. expected の長さと同じオフセットの clientDataJSON のバイトが：

    0x7d の場合

    検証は成功。

    0x2c の場合

    検証は成功。

    その他の場合

    検証は失敗。

5.8.1.3. 将来の拡張

限定的な検証アルゴリズムとの互換性を保つため、本仕様の将来バージョンでは type、 challenge、 origin、 crossOrigin のいずれも CollectedClientData から削除してはならず、これらのフィールドのシリアライズ順序を変更してはなりません。

もし CollectedClientData に追加フィールドが加えられた場合、限定的な検証アルゴリズムを利用する検証者は、両方のアルゴリズムが更新されるまでそれらのフィールドを考慮できません。更新後は追加フィールドも前述の制限を継承します。アルゴリズムの更新時には、以前のバージョンで生成されたシリアライズも扱えるようにする必要があります。すなわち、追加された5番目のキー・値の組が必ずしも5番目（あるいは存在する）とは限らない場合でも正しく扱う必要があります。

5.8.2. 認証情報種別列挙型（enum PublicKeyCredentialType）

enum PublicKeyCredentialType {
    "public-key"
};

注: PublicKeyCredentialType 列挙型は意図的に参照されていません。詳細は § 2.1.1 DOMString型列挙について参照。

この列挙型は有効な認証情報種別を定義します。今後新しい認証情報種別が定義される場合、値が追加される拡張ポイントとなります。この列挙型の値は、認証器の種類に応じて認証アサーションや証明構造のバージョニングに使われます。

現在定義されている認証情報種別は "public-key" のみです。

5.8.3. 認証情報デスクリプタ（dictionary PublicKeyCredentialDescriptor）

dictionary PublicKeyCredentialDescriptor {
    required DOMString                    type;
    required BufferSource                 id;
    sequence<DOMString>                   transports;
};

この辞書は、公開鍵認証情報を create() や get() メソッドの入力パラメータとして参照する際に指定される属性を格納します。後者のメソッドから返される PublicKeyCredential オブジェクトのフィールドを反映しています。

type, 型 DOMString

このメンバーは呼び出し元が参照する公開鍵認証情報の種別です。値は PublicKeyCredentialType のメンバーであるべきですが、クライアントプラットフォームは未知の PublicKeyCredentialDescriptor や未知の type を無視しなければなりません。

id, 型 BufferSource

このメンバーは呼び出し元が参照する公開鍵認証情報の認証情報IDです。

transports, 型 sequence<DOMString>

この任意メンバーは、呼び出し元が参照する公開鍵認証情報の管理認証器とクライアントとの通信手段のヒントを含みます。値は AuthenticatorTransport のメンバーであるべきですが、クライアントプラットフォームは未知の値を無視しなければなりません。

getTransports() 操作はこのメンバーに適した値を返すことができます。 新規認証情報登録時には、Relying Partyは getTransports() の戻り値を保存すべきです。 その認証情報の PublicKeyCredentialDescriptor を作成する際には、 Relying Partyはその保存値を取得し transports メンバーに設定すべきです。

5.8.4. 認証器トランスポート列挙型（enum AuthenticatorTransport）

enum AuthenticatorTransport {
    "usb",
    "nfc",
    "ble",
    "internal"
};

注: AuthenticatorTransport 列挙型は意図的に参照されていません。詳細は § 2.1.1 DOMString型列挙について参照。

認証器は、トランスポートを使ってクライアントと通信できます。この列挙型は、特定認証器でアサーション取得時にクライアントがどう通信するかのヒントを定義します。これらのヒントはWebAuthn Relying Partyの認識に過ぎません。Relying Partyは通常、公開鍵認証情報の対応トランスポートを getTransports() で知ります。
usb

この値は該当認証器が取り外し可能なUSB経由で通信可能であることを示します。

nfc

この値は該当認証器が近距離無線通信（NFC）経由で通信可能であることを示します。

ble

この値は該当認証器がBluetooth Smart（Bluetooth Low Energy / BLE）経由で通信可能であることを示します。

internal

この値は該当認証器がクライアントデバイス固有のトランスポートで通信されること、すなわちプラットフォーム認証器であることを示します。 これら認証器はクライアントデバイスから取り外し不可です。

5.8.5. 暗号アルゴリズム識別子（typedef COSEAlgorithmIdentifier）

typedef long COSEAlgorithmIdentifier;
COSEAlgorithmIdentifier の値は暗号アルゴリズムを識別する数値です。 アルゴリズム識別子は IANA COSE Algorithms registry [IANA-COSE-ALGS-REG] に登録された値であるべきです。例えば "ES256" は -7、"RS256" は -257 などです。

COSEアルゴリズムレジストリは他のパラメータで細かく指定できるようになっていますが、相互運用性のため本仕様では認証情報公開鍵に関して以下の追加保証を行います：

  1. ES256（-7）アルゴリズムの鍵は crv パラメータに P-256（1）を指定し、圧縮点形式は使用してはなりません。

  2. ES384（-35）アルゴリズムの鍵は crv パラメータに P-384（2）を指定し、圧縮点形式は使用してはなりません。

  3. ES512（-36）アルゴリズムの鍵は crv パラメータに P-521（3）を指定し、圧縮点形式は使用してはなりません。

  4. EdDSA（-8）アルゴリズムの鍵は crv パラメータに Ed25519（6）を指定しなければなりません（COSEでは常に圧縮形式です）。

注: これらアルゴリズムで署名検証を正しく実装するには多くの検査が必要です。特に、非圧縮楕円曲線点を扱う場合は、点が本当に曲線上にあるかどうかの検証が重要です。これは暗号ライブラリと他のコード間で抜け漏れが生じやすいため特に強調しています。

5.8.6. ユーザー検証要件列挙型（enum UserVerificationRequirement）

enum UserVerificationRequirement {
    "required",
    "preferred",
    "discouraged"
};

WebAuthn Relying Partyは、ある操作ではユーザー検証を必須とし、他の操作では不要とする場合があり、この型で要件を表現できます。

注: UserVerificationRequirement 列挙型は意図的に参照されていません。詳細は § 2.1.1 DOMString型列挙について参照。

required

この値は Relying Partyが当該操作でユーザー検証を必須とし、レスポンスのUVフラグがセットされていない場合は失敗とすることを示します。

preferred

この値は Relying Partyが可能ならユーザー検証を希望するが、レスポンスのUVフラグがセットされていなくても失敗としないことを示します。

discouraged

この値は Relying Partyが当該操作でユーザー検証を用いたくない（例：ユーザー体験の阻害を最小化したい場合）ことを示します。

5.9. Permissions Policyの統合

Headers/Feature-Policy/publickey-credentials-get

現行標準の1つのエンジンのみ利用可能。

FirefoxNoneSafariNoneChrome84+
OperaNoneEdge84+
Edge (Legacy)NoneIENone
Firefox for AndroidNoneiOS SafariNoneChrome for Android84+Android WebView84+Samsung InternetNoneOpera MobileNone

本仕様は、feature-identifierトークン"publickey-credentials-get"で識別されるポリシー制御機能を1つ定義します。その既定の許可リストは'self'です。[Permissions-Policy]

Documentのpermissions policyは、その文書内のすべてのコンテンツが、Web認証API（例：navigator.credentials.get({publicKey:..., ...})）を使って新たな公開鍵認証情報を作成できるかを決定します。文書で無効化されている場合、その文書内のいかなるコンテンツもこれらのメソッドを使用許可されません。使用しようとするとエラーが返されます。

注: [CREDENTIAL-MANAGEMENT-1]で規定されるアルゴリズムが実際のpermissions policy評価を行います。これは評価処理がcurrent settings objectへのアクセス時に行われる必要があるためです。[[Create]](origin, options, sameOriginWithAncestors) および [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 内部メソッドは並列で呼び出されるため、そうしたアクセスはありません（[CREDENTIAL-MANAGEMENT-1]参照）。

5.10. iframe要素内でのWeb認証利用

Web認証APIは、クロスオリジン iframeでは既定で無効化されています。 この既定ポリシーを上書きし、クロスオリジン iframeでWeb認証APIの [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) メソッドを許可するには、 allow 属性に publickey-credentials-get フィーチャ識別トークンを含めて指定してください。

埋め込みコンテキストでWebAuthn APIを利用するRelying Partyは、§ 13.4.2 埋め込み利用時の可視性に関する考慮事項で説明されるUIレドレッシングとその対策について確認してください。

6. WebAuthn 認証器モデル

Web認証APIは、WebAuthn認証器の抽象的な機能モデルを暗示しています。このセクションでは、その認証器モデルについて説明します。

クライアントプラットフォームは、この抽象モデルを任意の方法で実装・公開しても構いません。ただし、そのクライアントプラットフォームがサポートする認証器に対してWeb認証APIの動作が§ 5 Web認証APIで規定される動作と区別できないものでなければなりません。

注: [FIDO-CTAP]はこのモデルの具体的な実装例ですが、返すデータとWebAuthn APIのアルゴリズムが期待するデータには違いがあります。CTAP2のレスポンスメッセージは、同じオブジェクトでも本仕様の文字列キーではなく整数キーを使ってCBORマップで構築されます。クライアントはこの変換処理を行う必要があります。[FIDO-CTAP]仕様では、CTAP2整数キーとWebAuthn文字列キーのマッピングは§6.2. Responsesに詳細があります。

認証器について、このモデルはクライアントやWebAuthn Relying Partyに公開される論理操作とデータ形式を定義します。ただし、認証器がクライアントデバイスと通信する詳細は、相互運用に必要な場合を除き定義しません。例えば、USBやNFCなどのトランスポートで認証器とクライアントを接続するプロトコルは定義しません。同様に、具体的なエラーコードや返却方法も定義しませんが、クライアントの要件に基づくエラー動作は定義します。そのため、特定のエラーコードが他と区別できる（または区別できない）必要がある場合、それが準拠かつ安全なクライアント実装に必要なので明記されています。

Relying Partyは、認証情報作成時やアサーション生成時に認証情報作成オプションやアサーション生成オプションを使って、必要に応じてさまざまな認証器特性を指定することで認証器選択に影響を与えることができます。Web認証APIの基礎アルゴリズムは、これらのオプションをまとめて、下記で定義する該当認証器操作に渡します。

この抽象モデルでは、認証器は鍵管理と暗号署名を提供します。WebAuthnクライアント内に埋め込まれている場合も、完全に別のデバイスに収められていても構いません。認証器自身は、認証器の他部分より高いセキュリティレベルで動作する暗号モジュールを含むことがあります。これは特にWebAuthnクライアントに埋め込み型の場合に重要であり、その場合この暗号モジュール（例：TPM）は認証器の他部分よりも信頼できると見なされることがあります。

各認証器は、(rpId, [userHandle]) から公開鍵認証情報ソースへのcredentials map（順序付きマップ）を保持します。

さらに、各認証器にはAAGUID（128ビットの識別子）があり、認証器の種類（メーカー・モデル等）を示します。AAGUIDは製造者が、その製造者による本質的に同一な認証器では同一、他のすべての認証器とは高い確率で異なる値となるように選ばなければなりません。AAGUIDはランダム生成することが推奨されます。Relying Partyは、AAGUIDから認証器の認証レベルや鍵保護強度などのプロパティを他情報と組み合わせて推測可能です。

認証器の主な役割は、さまざまな文脈データに紐づいたWebAuthn署名を提供することです。 署名要求がサーバから認証器へ進む過程で、スタックの各レベルでこれらのデータが付与されます。サーバは署名検証時にこれらの結び付きを期待値と照合します。文脈データは2つに分かれます：Relying Partyまたはクライアントが付与するクライアントデータと、認証器が付与する認証器データです。認証器はクライアントデータに署名しますが、その内容自体には関心を持ちません。帯域や処理負荷を減らすため、クライアントはクライアントデータをハッシュ化し、その結果だけを認証器に送ります。認証器は、シリアライズされたクライアントデータのハッシュ値と自身の認証器データの組み合わせに署名します。

この設計の目標は以下の通りです。

認証器は2つの目的で暗号署名を生成します：

  1. 認証証明署名は、新規公開鍵認証情報がauthenticatorMakeCredential操作で作成されるとき生成されます。認証証明署名は、認証器および認証情報の特定プロパティの暗号的証明を提供します。例えば、認証証明署名は認証器の種類（AAGUID）や認証情報公開鍵を証明します。署名は認証証明秘密鍵で署名され、希望する認証証明の種類に応じて選ばれます。詳細は§ 6.5 認証証明参照。

  2. アサーション署名は、authenticatorGetAssertionメソッド呼び出し時に生成されます。これは、認証器がユーザーの特定トランザクション（例：ログインや購入）への同意を表明します。アサーション署名は、特定の認証情報秘密鍵を持つ認証器が、同じユーザーがその認証情報の作成に同意したことを示します。さらに、クライアントデータなど追加情報（同意取得方法や認証器が表示したプロンプト等）も含まれます。アサーション署名の形式は下記図4で示します。

WebAuthn署名は、認証証明署名とアサーション署名の両方を指します。 これらの署名形式や生成手順は下記で規定されます。

6.1. 認証器データ

認証器データ構造体は、認証器によって行われる文脈的バインディングをエンコードします。これらのバインディングは認証器自身によって制御され、その信頼性はWebAuthn Relying Partyが認証器のセキュリティ特性をどう評価するかに依存します。極端な例として、認証器がクライアント内蔵の場合はそのバインディングはクライアントデータと同程度しか信頼できません。逆に、認証器が高セキュリティのハードウェア・ソフトウェアを備えた独立デバイスとして安全なチャネル越しにクライアントに接続されている場合もあります。どちらの場合でも、Relying Partyは同じフォーマットの認証器データを受信し、認証器への知識に基づいて信頼判断を行います。

認証器データはコンパクトで拡張性のあるエンコーディングを持ちます。認証器が能力や電力が限られ、クライアントプラットフォームよりはるかに単純なソフトウェアスタックを持つデバイスであることが多いためです。

認証器データ構造体は37バイト以上のバイト列で、表の通りレイアウトされます。

名称 長さ（バイト数） 説明
rpIdHash 32 認証情報がスコープされるRP IDのSHA-256ハッシュ
flags 1 フラグ（ビット0が最下位ビット）：
signCount 4 署名カウンター、32ビット符号なしビッグエンディアン整数
attestedCredentialData 可変（存在する場合） 認証証明付きデータ（存在する場合）。詳細は§ 6.5.1 認証証明付きデータ参照。長さは認証情報ID長や認証情報ID、認証情報公開鍵に依存
extensions 可変（存在する場合） 拡張定義の認証器データ。これはCBOR [RFC8949]マップで、拡張識別子がキー、 認証器拡張出力が値。詳細は§ 9 WebAuthn拡張参照
認証器データレイアウト。名称欄の名前は本書内のみの参照用で、認証器データの実際の表現には含まれません。

RP IDは認証情報作成時にクライアントから受け取り、アサーション生成時にも再度受け取ります。ただし、他のクライアントデータとは重要な違いがあります。まず、クライアントデータと異なり、認証情報のRP IDは操作間で変わらず、その認証情報の存続期間中同じです。さらに、authenticatorGetAssertion操作時には、要求された認証情報がスコープされているRP IDがクライアントから供給されたRP IDと完全一致することを認証器が検証します。

認証器は以下の手順で認証器データ構造体を生成します：

図は認証器データ構造体の視覚表現です。

認証器データレイアウト。
注: 認証器データは自身の長さを記述します。AT・EDフラグがセットされていなければ常に37バイトです。 認証証明付きデータ（ATフラグがセットされている場合のみ）は自身の長さを記述します。EDフラグがセットされている場合、全体の長さは37バイト+認証証明付きデータ（ATフラグがセットされていれば）+後続の拡張出力（CBORマップ）長です。

認証証明付きデータの長さ（可変）を決定するには、先行する認証情報ID長から認証情報公開鍵の開始位置を決め、その認証情報公開鍵の長さを決定します（RFC8152 Section 7も参照）。

6.1.1. 署名カウンターに関する考慮事項

認証器は署名カウンター機能を実装すべきです。これらのカウンターは認証器が各認証情報ごと、もしくは認証器全体でグローバルに保持しているものと考えられます。認証情報の初期署名カウンター値は、signCount値として認証器データで返されます（authenticatorMakeCredential）。署名カウンターは、authenticatorGetAssertion操作が成功するごとに正の値で増加し、後続の値が再びWebAuthn Relying Partyへ認証器データ内で返却されます。署名カウンターの目的は、Relying Partyが認証器の複製（クローン）を検出できるよう支援することです。クローン検出は保護手段の限られた認証器でより重要です。

Relying Partyは、直近のauthenticatorGetAssertion操作の署名カウンター値を保存します。（認証情報でまだauthenticatorGetAssertionが実行されていない場合は、authenticatorMakeCredential操作のカウンター値を使用します。）後続のauthenticatorGetAssertion操作では、保存済み署名カウンター値と新たなアサーションのsignCount値を比較します。どちらかがゼロでなければ、そして新しいsignCount値が保存値以下の場合、認証器の複製が存在するか、認証器が故障している可能性があります。

署名カウンターの不一致を検知しても、その操作が複製認証器によるものか元の認証器によるものかは判別できません。Relying Partyは自組織のリスク許容度に応じて適切に対処すべきです。

認証器は：

6.1.2. FIDO U2F署名形式との互換性

アサーション署名の形式（認証器データ構造体とシリアライズされたクライアントデータのハッシュ値の連結に署名）は、FIDO U2F認証署名形式と互換性があります（Section 5.4、[FIDO-U2F-Message-Formats]参照）。

これは、FIDO U2F認証レスポンスメッセージで署名されるデータの先頭37バイトが有効な認証器データ構造体であり、残りの32バイトがシリアライズされたクライアントデータのハッシュ値であるためです。この認証器データ構造体では、rpIdHashはFIDO U2Fのapplication parameterに該当し、flagsはUP以外常にゼロ、attestedCredentialDataやextensionsは存在しません。FIDO U2F認証署名は、他のアサーション署名（authenticatorMakeCredential操作で生成されるもの）と同じ手順で検証できます。

6.2. 認証器分類

多くのユースケースは、利用される認証器の能力に依存します。 このセクションでは、これらの能力、重要な組み合わせ、およびそれらが可能にするユースケースについて用語を定義します。

例えば：

これらの例は、主要な認証器タイプの特徴を示しています：

これらの特徴は独立しており、理論上どのようにも組み合わせ可能ですが、表には特に重要な認証器タイプの組み合わせと名称を示します。

認証器タイプ 認証器接続様式 認証情報保存様式 認証要素能力
第二要素プラットフォーム認証器 プラットフォーム いずれか 単要素対応
ユーザー検証対応プラットフォーム認証器 プラットフォーム いずれか 多要素対応
第二要素ローミング認証器 クロスプラットフォーム サーバーサイド保存 単要素対応
第一要素ローミング認証器 クロスプラットフォーム クライアントサイド保存 多要素対応
主要な認証器タイプの名称定義。

第二要素プラットフォーム認証器は、同じクライアントデバイスでの再認証に便利であり、新規セッション開始時にも既存セッション再開時にもセキュリティ層を追加できます。 第二要素ローミング認証器は、初めてそのクライアントデバイスで認証する場合や、複数ユーザーで共有されるクライアントデバイスで利用される場合が多いです。

ユーザー検証対応プラットフォーム認証器および第一要素ローミング認証器はパスワードレス多要素認証を可能にします。 認証情報秘密鍵の所有証明に加え、これら認証器はPINや生体認証などのユーザー検証も第二認証要素としてサポートします。 認証器は2種類の認証要素として機能でき、パスワードをRelying Partyと共有しなくても多要素認証が実現できます。

上記表に名前のない4つの組み合わせは、目立ったユースケースが少ないです：

以下のサブセクションで、認証器接続様式、認証情報保存様式、および認証要素能力を詳しく定義します。

6.2.1. 認証器接続様式

クライアントは、さまざまな仕組みで認証器と通信できます。例えば、クライアントはクライアントデバイス固有のAPIを用いて、そのデバイスに物理的に結びついた認証器と通信することができます。一方で、クライアントはBluetooth（§ 5.8.4 認証器トランスポート列挙型参照）などの標準化されたクロスプラットフォーム・トランスポートプロトコルを利用して、クロスプラットフォーム接続された認証器を探索・通信することもできます。認証器がクライアントデバイスの一部である場合、これをプラットフォーム認証器、クロスプラットフォーム・トランスポート経由で到達可能な場合はローミング認証器と呼びます。

一部のプラットフォーム認証器は、状況によってローミング認証器としても動作可能です。例えば、モバイルデバイス内蔵のプラットフォーム認証器がBluetooth経由で外部デバイスとして提供される場合、モバイルデバイス上のクライアントはこれをプラットフォーム認証器と認識し、他のクライアントデバイス上のクライアントはBluetooth経由で同じ認証器を ローミング認証器と認識します。

プラットフォーム認証器の主なユースケースは、特定のクライアントデバイスを「信頼済みデバイス」として登録し、今後の認証のために所持物（認証要素）として機能させることです。これにより、ユーザーは今後の認証手続きでローミング認証器を探す必要がなくなり、利便性が向上します（例：キーフォブやスマートフォンを探す必要がなくなります）。

ローミング認証器のユースケースには、新しいクライアントデバイスで初めて認証する場合、たまにしか使わないクライアントデバイス、複数ユーザーで共有するクライアントデバイス、プラットフォーム認証器を含まないクライアントデバイスでの認証、または方針や好みにより認証器を利用デバイスから分離したい場合などがあります。また、他の認証器紛失時のバックアップとしてローミング認証器に認証情報を保持することもできます。

6.2.2. 認証情報保存様式

認証器は、公開鍵認証情報ソースを次のいずれかの方法で保存できます：

  1. 認証器・クライアント・クライアントデバイスの埋め込み永続ストレージ（例：セキュアエレメント）に保存する方法。これはクライアントサイド発見可能公開鍵認証情報ソースの技術的要件です。

  2. 認証情報秘密鍵を暗号化（ラッピング）し、該当する認証器のみが復号（アンラップ）可能なようにし、その暗号文を認証情報IDとして利用する方法。認証情報IDはRelying Partyによって保存され、allowCredentials オプション経由でget()に渡され、認証器が復号・使用できるようになります。

    この方法により、認証器は無制限に認証情報秘密鍵を保存できます（暗号化された秘密鍵はRelying Partyが保存するため）。ただし、この方法で保存された認証情報は認証器が使用する前にRelying Partyから取得する必要があります。

これらどちらの保存戦略を採用するかが、認証器の認証情報保存様式を規定します：

発見可能認証情報対応の認証器は両方の保存戦略をサポートする場合もあります。この場合、認証器は個々の認証情報ごとに異なる戦略を使うこともできますが、residentKeyやrequireResidentKeyオプションに従う必要があります（create()参照）。

6.2.3. 認証要素能力

本人確認（authentication factor）には、認証手続きで使える3つの大きなクラスがあります：所持物、知識、生体。例えば、物理キー、パスワード、指紋などがそれぞれ該当します。

全てのWebAuthn認証器は所持物クラスに属しますが、ユーザー検証をサポートする認証器は追加で1〜2種類の認証要素にもなれます。例えば、PINの検証ができるならPINは知識、生体認証器は 生体に該当します。よって、ユーザー検証をサポートする認証器は多要素対応です。逆に、多要素対応でない認証器は単要素対応です。なお、1つの多要素対応認証器が複数のユーザー検証モードをサポートし、3種類すべての認証要素になれる場合もあります。

ユーザー検証は認証器内部でローカル実行され、Relying Partyが直接行うものではありませんが、認証器は署名レスポンスで UVフラグをセットすることでユーザー検証したか示します。Relying PartyはこのUVフラグで追加 認証要素が使われたことを登録・認証手続きで検証可能です。UVフラグの正当性は、認証器の認証証明文を調べることで評価できます。

6.3. 認証器操作

WebAuthnクライアントは、認証器のいずれかの操作を呼び出すには認証器と接続しなければなりません。この接続が認証器セッションです。認証器はセッション間の隔離を維持しなければなりません。その方法として、同時に1つのセッションしか存在できないようにしたり、より複雑なセッション管理を提供することもできます。

認証器セッション内でクライアントから呼び出せる操作は以下の通りです。

6.3.1. 認証情報IDによる認証情報ソース検索アルゴリズム

credential idの検索結果は、認証器authenticatorで認証情報IDcredentialIdを検索した結果であり、以下のアルゴリズムとなります：

  1. もしauthenticatorがcredentialIdを復号し、公開鍵認証情報ソースcredSourceを得られる場合：

    1. credSource.idにcredentialIdをセットする。

    2. credSourceを返す。

  2. 各公開鍵認証情報ソースcredSourceについて、authenticatorのcredentials mapを：

    1. もしcredSource.idがcredentialIdなら、credSourceを返す。

  3. nullを返す。

6.3.2. authenticatorMakeCredential操作

以下の入力パラメータを受け取ります：

hash

クライアントが提供するシリアライズされたクライアントデータのハッシュ値

rpEntity

Relying PartyのPublicKeyCredentialRpEntity

userEntity

ユーザーアカウントのPublicKeyCredentialUserEntity（user handleを含む）

requireResidentKey

認証情報作成時の実効residentKey要件（Boolean値、クライアントで決定）

requireUserPresence

定数Boolean値true。WebAuthnではユーザー存在テストが必須ですが、抽象モデルの実装でオプション化したい場合の便宜のために疑似パラメータとしています。

requireUserVerification

認証情報作成時の実効ユーザー検証要件（Boolean値、クライアントで決定）

credTypesAndPubKeyAlgs

Relying Partyが要求したPublicKeyCredentialTypeと公開鍵アルゴリズム（COSEAlgorithmIdentifier）のペアの列。優先度の高い順で、認証器は可能な限り最も優先度の高い認証情報を作成する。

excludeCredentialDescriptorList

Relying Partyが提供するPublicKeyCredentialDescriptorオブジェクトのリスト（該当認証器に既知の場合、新規認証情報を作成すべきでない）。既知認証情報のリスト。

enterpriseAttestationPossible

認証器が個別識別可能な認証証明を返す可能性があることを示すBoolean値。

extensions

クライアントがRelying Partyから要求された拡張をもとに作成した、拡張識別子→認証器拡張入力のCBORマップ

注: この操作を行う前に、認証器セッション内で進行中の他の操作はすべてauthenticatorCancel操作を実行して中断しなければなりません。

この操作が呼び出された場合、認証器は以下の手順を実行しなければなりません：

  1. すべてのパラメータが構文的に正しく、長さも適切か確認。不正ならエラーコード"UnknownError"を返し、操作を終了。

  2. credTypesAndPubKeyAlgsで指定されたPublicKeyCredentialTypeと暗号パラメータの組み合わせが1つ以上サポートされているか確認。なければエラーコード"NotSupportedError"を返し、操作を終了。

  3. 各descriptorについて、excludeCredentialDescriptorListを：

    1. この認証器でdescriptor.idを検索し、nullでなく返り値のRP ID・typeが rpEntity.idと excludeCredentialDescriptorList.type に一致する場合、 認可ジェスチャで新規認証情報作成へのユーザー同意を取得する。認可ジェスチャはユーザー存在テストを含まなければならない。もしユーザーが

      新規認証情報作成に同意する

      エラーコード"InvalidStateError"を返し、操作を終了。

      新規認証情報作成に同意しない

      エラーコード"NotAllowedError"を返し、操作を終了。

      注: この認可ジェスチャの目的は認証情報作成の続行ではなく、プライバシー保護のため、descriptor.idがこの認証器に結び付けられている事実の開示を同意するものです。ユーザーが同意すればクライアント・Relying Partyはそれを検知し、別の認証器を使うよう案内できます。同意しなければ認証器は結び付けの有無を示さず、単に同意拒否と同じ応答になります。

  4. requireResidentKeyがtrueかつ認証器がクライアントサイド発見可能公開鍵認証情報ソースを保存できない場合、エラーコード"ConstraintError"を返し、操作を終了。

  5. requireUserVerificationがtrueかつ認証器がユーザー検証できない場合、エラーコード"ConstraintError"を返し、操作を終了。

  6. 認可ジェスチャが完了しユーザー同意を得たら、新しい認証情報オブジェクトを生成：

    1. この認証器がサポートする最初のPublicKeyCredentialTypeと暗号パラメータの組み合わせで、新たな暗号鍵対(publicKey, privateKey)を生成する。

    2. userHandleをuserEntity.idとする。

    3. credentialSourceを新規公開鍵認証情報ソースとし、以下のフィールドを持たせる：

      type

      public-key

      privateKey

      privateKey

      rpId

      rpEntity.id

      userHandle

      userHandle

      otherUI

      認証器が任意で追加するその他情報

    4. requireResidentKeyがtrue、または認証器がクライアントサイド発見可能公開鍵認証情報ソースを作成する場合：

      1. credentialIdを新規認証情報IDとする。

      2. credentialSource.idにcredentialIdをセットする。

      3. credentialsをこの認証器のcredentials mapとする。

      4. Set credentials[(rpEntity.id, userHandle)] = credentialSource

    5. それ以外の場合：

      1. credentialIdをcredentialSourceをシリアライズ・暗号化した値（この認証器のみ復号可能）とする。

  7. 新規認証情報オブジェクト作成中にエラーが発生した場合、エラーコード"UnknownError"を返し、操作を終了。

  8. processedExtensionsを、extensions内の各拡張識別子→拡張入力について認証器拡張処理で得る。

  9. 認証器が：

    U2Fデバイスの場合

    新規認証情報の署名カウンター値はゼロとする（U2Fデバイスは署名カウンターをサポートすることもあるが、認証情報作成時にはカウンターを返さない。[FIDO-U2F-Message-Formats]参照）。

    グローバル署名カウンター対応の場合

    認証器データ生成時にグローバル署名カウンターの実値を使用。

    認証情報ごとの署名カウンター対応の場合

    カウンターを割り当て、新規認証情報に関連付け、初期値はゼロ。

    署名カウンター非対応の場合

    新規認証情報の署名カウンター値は常にゼロ。

  10. attestedCredentialDataを、credentialIdとpublicKeyを含む認証証明付きデータのバイト列とする。

  11. authenticatorDataを、§ 6.1 認証器データで規定されるバイト列とし、attestedCredentialData（存在する場合）とprocessedExtensions（存在する場合）を含める。

  12. 新規認証情報の認証証明オブジェクトを、§ 6.5.4 認証証明オブジェクト生成に従って、認証器が選択した認証証明文形式・authenticatorData・hash・enterpriseAttestationPossibleを使って作成する。詳細は§ 6.5 認証証明参照。

この操作が正常に完了すると、認証器は認証証明オブジェクトをクライアントへ返します。

6.3.3. authenticatorGetAssertion 操作

以下の入力パラメータを受け取ります：

rpId

呼び出し元の RP ID。ユーザーエージェントとクライアントによって決定されます。

hash

クライアントによって提供される、シリアライズされたクライアントデータのハッシュ。

allowCredentialDescriptorList

OPTIONALな リスト。PublicKeyCredentialDescriptor の インスタンスで、Relying Party（クライアントによってフィルタされる場合もあり）が受け入れる認証情報を記述します（存在する場合）。

requireUserPresence

定数ブール値 true。 この抽象的な認証器モデルを、WebAuthnでは必須だが実装によってはユーザーの存在テストをオプションとしたい場合に適用しやすくするための疑似パラメータです。

requireUserVerification

アサーションの実効ユーザー検証要件。クライアントから提供されるブール値です。

extensions

クライアントがRelying Partyから要求された拡張に基づき作成した、CBORのマップ。拡張識別子からそれぞれの認証器拡張入力への対応付け（存在する場合）。

注記:この操作を実行する前に、認証器セッション内の進行中の他のすべての操作は、authenticatorCancel 操作を実行して中止しなければなりません。

このメソッドが呼び出されると、認証器は次の手順を実行しなければなりません：

  1. すべての入力パラメータが構文的に正しく、かつ正しい長さであることを確認します。そうでない場合、"UnknownError" に相当するエラーコードを返し、操作を終了します。

  2. credentialOptions を新しい空のセットとして作成します。セットの要素は公開鍵認証情報ソースです。

  3. allowCredentialDescriptorList が指定されている場合、各 allowCredentialDescriptorList の descriptor について：

    1. credSource を、この認証器内で credential-idの検索により descriptor.id で得られる結果とします。

    2. credSource が null でなければ、credentialOptions に追加します。

  4. そうでない場合（allowCredentialDescriptorList が指定されていない場合）、この認証器の認証情報マップの 各 key → credSource について、credentialOptionsに追加します。

  5. credentialOptionsから、rpIdがrpIdと一致しないものを除去します。

  6. credentialOptions が空の場合、"NotAllowedError" に相当するエラーコードを返し、操作を終了します。

  7. ユーザーに credentialOptions から 公開鍵認証情報ソース（selectedCredential）を選択するよう促します。 selectedCredentialの使用にユーザーの同意を確認する認可ジェスチャを収集します。 認可ジェスチャのプロンプトは、認証器が独自の出力機能を持つ場合は認証器自身が、そうでなければユーザーエージェントが表示します。

    requireUserVerification が true の場合、認可ジェスチャはユーザー検証を含まなければなりません。

    requireUserPresence が true の場合、認可ジェスチャはユーザー存在テストを含まなければなりません。

    ユーザーが同意しなかった場合、"NotAllowedError" に相当するエラーコードを返し、操作を終了します。

  8. processedExtensions を、認証器拡張処理で各サポートされている拡張識別子 → 認証器拡張入力に対して得られる結果とします。

  9. 認証情報に関連付けられたシグネチャカウンター、またはグローバルなシグネチャカウンター値を、認証器がどちらの方式を実装しているかに応じて、正の値でインクリメントします。 認証器がシグネチャカウンターを実装していない場合、値は0のままとします。

  10. authenticatorData を バイト配列として生成します。詳細は § 6.1 認証器データ を参照。processedExtensionsがあればこれも含めます（ extensions ）、attestedCredentialDataは含めません。

  11. signature を アサーション署名として、authenticatorData || hash の連結を selectedCredentialのprivateKey で署名して生成します。下図を参照。 ここでは区切りなしの単純な連結を使用していますが、認証器データが自身の長さを記述しているため安全です。シリアライズされたクライアントデータのハッシュ（可変長）は常に最後に配置されます。

    アサーション署名の生成。

  12. アサーション署名の生成中にエラーが発生した場合、"UnknownError" に相当するエラーコードを返し、操作を終了します。

  13. ユーザーエージェントへ返却する値：

    • クライアントによりallowCredentialDescriptorListが2つ以上指定された場合、またはリストが指定されなかった場合、selectedCredential.id を返却します。

      注記: allowCredentialDescriptorList内でクライアントがちょうど1つの認証情報を指定し、それが正常に利用された場合、その認証情報IDは返却されません。クライアントが既に知っているためです。これは、制約された接続環境で頻繁に発生するケースで、バイト数の送信を節約するためです。

    • authenticatorData

    • signature

    • selectedCredential.userHandle

      注記:返却されるuserHandle値はnullの可能性があります。詳細はuserHandleResult参照。

指定されたRelying Partyに対応する、指定された条件に一致する認証情報が認証器で見つからない場合、操作は終了し、エラーを返します。

6.3.4. authenticatorCancel 操作

この操作は入力パラメータを受け取らず、結果も返しません。

この操作がクライアントによって認証器セッション内で呼び出されると、その認証器セッションで進行中のauthenticatorMakeCredentialまたはauthenticatorGetAssertion 操作を終了する効果があります。認証器は中止された操作に関連するユーザー入力の促しや受付を停止します。 クライアントは中止された操作に対する認証器からの応答を無視します。

進行中のauthenticatorMakeCredentialまたはauthenticatorGetAssertion 操作が存在しない認証器セッションで呼び出された場合、この操作は無視されます。

6.4. 文字列の取扱い

認証器はRelying Partyによって選ばれた任意の文字列を保存する必要がある場合があります。例えば name や displayName （PublicKeyCredentialUserEntity 内）。この節では、人間に提示される可能性のある任意の文字列を扱う際の実際的な影響について説明します。

6.4.1. 文字列の切り詰め

APIの各任意文字列は、認証器で利用可能なリソースが制限されている可能性に配慮した何らかの措置が講じられます。もし切り詰め（トランケーション）が選択された場合、認証器は指定された最小対応長以上に収めるために文字列値を切り詰めても構いません。この切り詰めはUTF-8のシーケンス境界または書記素クラスタ境界も考慮すべきです。これが許容される最大限の切り詰め方法であり、認証器はそれ以上切り詰めてはなりません。

例えば、図では、文字列が65バイトです。64バイトに切り詰める場合、最終の0x88バイトは容量の都合で削除されます。これにより部分的なUTF-8シーケンスが残る場合は、残りも削除します。さらにそれが部分的な書記素クラスタであれば、その残りも削除することができます。

UTF-8エンコード文字列末尾と各種切り詰め境界の位置。

適合ユーザーエージェントは、Relying Partyから見た認証器の振る舞いが 文字列処理に関してこの現行標準に適合することを保証する責任があります。例えば、認証器が大きな文字列保存時に誤動作する場合、ユーザーエージェントは認証器の代わりに切り詰め処理を行うべきです。その場合は書記素クラスタ境界で切り詰めを行うべきです。

UTF-8シーケンスのみで切り詰めると、書記素クラスタが途中で途切れることがあります。これにより、クラスタが別のグリフとして描画され、文字列の意味が変わる場合があります（グリフ自体が完全に消えるのではなく）。

さらに、バイト境界のみで切り詰めると次の既知の問題が発生します：認証器が[FIDO-CTAP]を使用している場合、認証器からの将来のメッセージに無効なCBORが含まれることがあります。CBOR文字列型は有効なUTF-8である必要があるためです。ユーザーエージェントは、認証器に文字エンコーディングやUnicode特性の理解を強いることなくこれを処理すべきです。したがって、認証器を扱う際、ユーザーエージェントは以下を行うべきです：

  1. 認証器へ送る全ての文字列が正しくエンコードされていることを保証する。

  2. 切り詰めにより無効なエンコーディングとなった場合の処理を行う。例えば末尾に部分コードポイントが残った場合、それを削除するか U+FFFD に置き換える。

6.4.2. 言語・方向のエンコーディング

適切な文脈で表示するために、文字列の言語と基本方向を指定する必要がある場合があります。このAPIの文字列は固定機能の認証器に書き込まれ、後で異なるプラットフォームで読み出して表示される可能性があるため、言語・方向のメタデータは文字列自体にエンコードされ、アトミックに転送されるようにしています。

言語・方向メタデータを許可された文字列にエンコードするには、二つのコードポイントシーケンスを末尾に付加します：

一つ目は言語タグをU+E0001の後にASCII値をU+E0000だけシフトして並べます。例えば言語タグ「en-US」はU+E0001, U+E0065, U+E006E, U+E002D, U+E0055, U+E0053となります。

二つ目は、U+200E（「左から右マーク」）、U+200F（「右から左マーク」）、U+E007F（「CANCEL TAG」）のいずれか一つのコードポイントです。最初の二つは方向性を示すためですが、正しい表示結果に必要な場合のみ使うべきです（例えばRTL文字列で先頭がLTRの強い文字の場合など）。U+E007Fは方向に依存しない言語タグの終端を示します。

よって、“حبیب الرحمان”という文字列は、言語エンコードの有無で2つのDOMString値を持ちます（この例では方向が明確なので方向マーカーは不要です）。

言語・方向がエンコードされた可能性のある文字列の利用者は、切り詰めによって言語タグが異なるが有効な言語に変わる可能性がある点に注意すべきです。最終の方向マーカーまたはCANCEL TAGコードポイントは切り詰めの有無を明確に示します。

6.5. アテステーション

認証器は可能であれば何らかのアテステーションを提供すべきです。 認証器がそれを提供する場合、基本要件は認証器が各認証情報公開鍵についてアテステーション文を生成でき、 WebAuthn Relying Partyが検証できることです。通常、アテステーション文にはアテステーション秘密鍵による署名が含まれ、 アテストされる認証情報公開鍵とチャレンジ、およびアテステーション公開鍵の来歴情報を提供する 証明書などが含まれます。これによりRelying Partyが信頼判断できます。しかしアテステーション鍵ペアが利用できない場合、認証器は自己アテステーションで 認証情報公開鍵を対応する認証情報秘密鍵で署名するか、 あるいはアテステーションなしを行ってもよいです。 これらの情報は新しい公開鍵認証情報が生成されるたびに アテステーションオブジェクトとして認証器から返されます。 アテステーションオブジェクトと 認証器データ （アテスト認証情報データを含む）、 アテステーション文の関係は 下図で示されています。

認証器が自己アテステーションまたはアテステーションなしを用いる場合、 Relying Partyが信頼判断の根拠とする来歴情報は提供されません。 こうした場合、認証器は自身の動作について Relying Partyに何の保証もしません。

アテステーションオブジェクトの構成。 認証器データ（アテスト認証情報データを含む）と アテステーション文が含まれる。
この図はpacked型のアテステーション文フォーマットのみを示します。 他にも複数のアテステーション文フォーマットが § 8 定義済みアテステーション文フォーマットで定義されています。

アテステーションオブジェクトの重要な構成要素が アテステーション文です。 これは署名付きデータオブジェクトの一種で、公開鍵認証情報自体やそれを作成した認証器に関する情報を含みます。 通常は認証機関の鍵（アテステーション署名）で署名されますが、自己アテステーションの場合は認証情報秘密鍵で署名されます。 アテステーション文を正しく解釈するためには、 Relying Partyはアテステーションの2つの側面を理解する必要があります：

  1. アテステーション文フォーマットは、署名や様々な文脈情報が 認証器によってアテステーション文にどう表現・組み込まれるかを定義します。言い換えれば文の構文です。 TPMやAndroid OS等、既存のコンポーネントやOSプラットフォームはアテステーション文フォーマットを定義しています。 本仕様は§ 6.5.2 アテステーション文フォーマットで拡張可能な形で複数のフォーマットをサポートします。 フォーマットは§ 8.1 アテステーション文フォーマット識別子で示す文字列で識別されます。

  2. アテステーション型は アテステーション文とその信頼モデルの意味論を定義します。 具体的には、Relying Partyが特定のアテステーション文の信頼性を、暗号的検証後にどのように確立するかを示します。 本仕様は§ 6.5.3 アテステーション型で複数のアテステーション型をサポートします。

一般に、アテステーション文フォーマットとアテステーション型の間に単純な対応関係はありません。 例えば、packed型のアテステーション文フォーマットは 全てのアテステーション型で利用できますが、 他のフォーマットや型は適用範囲が限定されます。

アテステーションのプライバシー・セキュリティ・運用特性は以下に依存します：

多くの認証器は少数のアテステーション型と アテステーション文フォーマットのみをサポートし、 Relying Partyは自らのポリシーで受容可能なアテステーション型を決定します。 また、Relying Partyは 信頼する認証器の特性も把握しておく必要があります。例えばFIDO Metadata Service [FIDOMetadataService]などが情報取得手段となります。

6.5.1. アテスト認証情報データ

アテスト認証情報データは 認証器データ生成時に追加される可変長バイト配列で、 特定認証情報のアテステーションオブジェクトに含まれます。 その形式は下表を参照。

名称 長さ（バイト） 説明
aaguid 16 認証器のAAGUID
credentialIdLength 2 Credential IDのバイト長L（16ビット符号なしビッグエンディアン整数）
credentialId L Credential ID
credentialPublicKey 可変 認証情報公開鍵（COSE_Key形式）。RFC8152 §7参照、CTAP2標準CBORエンコーディング使用。 COSE_Keyエンコード済み認証情報公開鍵は必ず"alg"パラメータを含み、 他のOPTIONALパラメータは含めてはならない。"alg"はCOSEAlgorithmIdentifier値。 また、"kty"や"alg"ごとのREQUIREDパラメータも含めること（RFC8152 §8参照）。
アテスト認証情報データの構成。名称欄は文書内参照用で、 実際のアテスト認証情報データ表現には含まれません。
6.5.1.1. credentialPublicKey値のCOSE_Key形式エンコード例

この節では、ES256・PS256・RS256署名アルゴリズム用COSE_Keyエンコード済み楕円曲線およびRSA公開鍵の例を示します。各例は上記credentialPublicKey値の規則に従い、 CDDL形式（RFC8610）で表記しています。

[RFC8152] §7で COSE_Keyエンコード全般の枠組みを定義しています。 アルゴリズムごとの鍵型は、RFC8152他の節や別仕様で定義されています。

下記はEC2形式（RFC8152 §13.1）・P-256曲線・ES256（ECDSA/SHA-256, RFC8152 §8.1）用COSE_Keyエンコード済み楕円曲線公開鍵の例です：

{
  1:   2,  ; kty: EC2 key type
  3:  -7,  ; alg: ES256 signature algorithm
 -1:   1,  ; crv: P-256 curve
 -2:   x,  ; x-coordinate as byte string 32 bytes in length
           ; e.g., in hex: 65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c08551d
 -3:   y   ; y-coordinate as byte string 32 bytes in length
           ; e.g., in hex: 1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd0084d19c
}

上記楕円曲線公開鍵のCTAP2標準CBORエンコーディング例（CDDL表記に合わせ空白・改行あり）：

A5
   01  02

   03  26

   20  01

   21  58 20   65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c08551d

   22  58 20   1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd0084d19c

下記はPS256署名アルゴリズム（RSASSA-PSS/SHA-256, RFC8230 §2）用2048ビットRSA公開鍵のCOSE_Keyエンコード例（RFC8230 §4）：

{
  1:   3,  ; kty: RSA key type
  3: -37,  ; alg: PS256
 -1:   n,  ; n:   RSA modulus n byte string 256 bytes in length
           ;      e.g., in hex (middle bytes elided for brevity): DB5F651550...6DC6548ACC3
 -2:   e   ; e:   RSA public exponent e byte string 3 bytes in length
           ;      e.g., in hex: 010001
}

下記は同じRSA公開鍵のRS256署名アルゴリズム（RSASSA-PKCS1-v1_5/SHA-256）用COSE_Keyエンコード例：

{
  1:   3,  ; kty: RSA key type
  3:-257,  ; alg: RS256
 -1:   n,  ; n:   RSA modulus n byte string 256 bytes in length
           ;      e.g., in hex (middle bytes elided for brevity): DB5F651550...6DC6548ACC3
 -2:   e   ; e:   RSA public exponent e byte string 3 bytes in length
           ;      e.g., in hex: 010001
}

6.5.2. アテステーション文フォーマット

前述のとおり、アテステーション文フォーマットとは、認証器による暗号署名を文脈的な情報束上に表現するデータフォーマットです。各アテステーション文フォーマットは以下のテンプレートで定義されなければなりません：

規定済みアテステーション文フォーマットの初期リストは§ 8 定義済みアテステーション文フォーマットにあります。

6.5.3. アテステーション型

WebAuthnは複数のアテステーション型をサポートしており、各アテステーション文とその信頼モデルの意味論を定義します：

注記: この仕様は認証器が用いるアテステーション型を明示的に表現するデータ構造を定義しません。 Relying Partyが アテステーション文の検証を行う場合 （すなわちnavigator.credentials.create()呼び出し時に アテステーション伝達にnone以外を選択し、 受信したアテステーション文を検証する場合）、使用されているアテステーション型は 検証の一環として決定されます。§ 8 定義済みアテステーション文フォーマットの "Verification procedure"節参照。§ 14.4.1 アテステーションのプライバシーも参照。 本節で定義されるアテステーション型のうち Selfおよび None以外については、 Relying Partyの検証後、 信頼パスが§ 7.1 新しい認証情報の登録の手順21に従い 適切なルート証明書にマッチするか確認されます。これらアテステーション型の区別は、アテステーションが Relying Partyのポリシーで許容されるかどうか判断する際に主に役立ちます。

基本アテステーション (Basic)

基本アテステーションの場合 [UAFProtocol]、認証器のアテステーション鍵ペアは 認証器「モデル」（バッチ）ごとに固有です。同じまたは類似モデルの認証器は同じアテステーション鍵ペアを共有することが多いです。詳細は§ 14.4.1 アテステーションのプライバシー参照。

基本アテステーションはバッチアテステーションとも呼ばれます。

自己アテステーション (Self)

自己アテステーションの場合（サロゲート基本アテステーションとも呼ばれる [UAFProtocol]）、認証器は特定のアテステーション鍵ペアを持たず、代わりに認証情報秘密鍵でアテステーション署名を生成します。 意味のある保護機構を持たない認証器はこの型を用います。

アテステーションCA (AttCA)

この場合、認証器はTPMをベースとし、認証器固有の「エンドースメントキー（EK）」を保持します。この鍵で信頼できる第三者アテステーションCA [TCG-CMCProfile-AIKCertEnroll]（旧称「プライバシーCA」）と安全に通信。 認証器は複数のアテステーションID鍵ペア（AIK）を生成し、それぞれについてアテステーションCAにAIK証明書発行を要求できます。 この方法ではEK（グローバルな相関ハンドル）の露出をCAに制限できます。各認証器生成公開鍵認証情報ごとにAIKを要求することも可能です。 AIK証明書はRelying Partyにアテステーション証明書として伝達されます。

注記: この仕組みでは複数のアテステーション証明書が典型的に発行されます。最新に要求されたものが「アクティブ」と呼ばれます。

匿名化CA (AnonCA)

この場合、認証器は匿名化CAを利用し、 クレデンシャルごとにアテステーション証明書を動的生成。 アテステーション文がRelying Partyに一意に識別可能な情報を提供しないようにします（トラッキング等対策）。

注記: アテステーション文で伝達されるアテステーションの 型が AttCAまたはAnonCAの場合、 データ構造自体はBasic型と同じなので、3種の型は外部知識がないと証明書内容でしか区別できません。

アテステーション文なし (None)

この場合、アテステーション情報は利用できません。§ 8.7 Noneアテステーション文フォーマットも参照。

6.5.4. アテステーションオブジェクトの生成

アテステーションオブジェクト（図6参照）を以下の情報から生成する：

attestationFormat

アテステーション文フォーマット

authData

認証器データを含むバイト配列

hash

シリアライズされたクライアントデータのハッシュ

認証器は次の手順を実行しなければなりません：

  1. attStmtを、authDataとhashを入力としてattestationFormatの署名手順を実行した結果とする。

  2. fmtをattestationFormatのアテステーション文フォーマット識別子とする。

  3. 以下の構文で変数を埋めてアテステーションオブジェクト（CBORマップ）を返却：

        attObj = {
                authData: bytes,
                $$attStmtType
             }

    attStmtTemplate = (
                          fmt: text,
                          attStmt: { * tstr => any } ; Map is filled in by each concrete attStmtType
                      )

    ; Every attestation statement format must have the above fields
    attStmtTemplate .within $$attStmtType

6.5.5. Packedアテステーション・FIDO U2Fアテステーション・アサーション署名の署名形式

新しいアテステーションフォーマット定義時はASN.1エンコーディングを避け、署名は構造を持たない固定長バイト配列で表現することが推奨されます（COSE署名の表現を使用、[RFC8152]および[RFC8230]参照）。

以下の署名形式定義はこの要件を満たす例であり、他の未記載署名アルゴリズムについても同様の形で導出可能です：

7. WebAuthn Relying Partyの操作

登録または認証セレモニーは、WebAuthn Relying Partyが それぞれPublicKeyCredentialCreationOptionsまたは PublicKeyCredentialRequestOptions オブジェクトを作成することから始まります。これにはセレモニーのパラメータがエンコードされます。Relying Partyはこの段階で機密情報が漏洩しないよう注意すべきです。詳細は§ 14.6.2 ユーザー名列挙を参照してください。

create() またはget()の 実行が成功すると、Relying Partyのスクリプトは クライアントからPublicKeyCredential を受け取ります。その中にはAuthenticatorAttestationResponse またはAuthenticatorAssertionResponse 構造体が含まれています。これをRelying Partyサーバーに 外部手段で渡す必要があります（この仕様の範囲外）。本節では、Relying Partyがこれらの構造体を受け取った際に 実行すべき操作について説明します。

7.1. 新しい認証情報の登録

登録セレモニーを実施するために、Relying Partyは以下の手順を踏まなければなりません：

  1. optionsを、セレモニーのためにRelying Partyの要件に合わせて設定した新しいPublicKeyCredentialCreationOptions構造体とする。

  2. navigator.credentials.create() を呼び出し、optionsを publicKey オプションとして渡します。 成功したPromiseの結果をcredentialとします。 Promiseがrejectされた場合は、ユーザーに分かる形でエラー表示するか、状況に応じてユーザー体験を誘導します。 例えばPromiseが"InvalidStateError"相当の エラーコードでrejectされた場合、ユーザーに別の認証器の利用を促すことが考えられます。 各種エラー状況については§ 6.3.2 authenticatorMakeCredential操作参照。

  3. responseを credential.response とします。 responseがAuthenticatorAttestationResponse のインスタンスでなければ、セレモニーをユーザー向けエラーで中断します。

  4. clientExtensionResultsを credential.getClientExtensionResults() の呼び出し結果とします。

  5. JSONtextを response.clientDataJSON の値に対してUTF-8デコードを実行した結果とします。

    注記: どのUTF-8デコード実装でも、UTF-8 decodeアルゴリズムと同じ結果になれば問題ありません。特に先頭のバイトオーダーマーク（BOM）は必ず除去してください。

  6. C（認証情報生成時に収集されたとされるクライアントデータ）を、JSONtextに対して実装依存のJSONパーサーを実行した結果とします。

    注記: Cは実装依存のデータ構造でも構いませんが、本アルゴリズムで参照できるように構成要素がアクセス可能である必要があります。

  7. C.type の値がwebauthn.createであることを検証します。

  8. C.challenge の値が options.challenge のbase64urlエンコード値と一致することを検証します。

  9. C.origin の値がRelying Partyのオリジンと一致することを検証します。

  10. C.tokenBinding.status の値が、Token Bindingが取得されたTLS接続の状態と一致することを検証します。TLS接続でToken Bindingが使用されていた場合は、 C.tokenBinding.id がその接続のbase64urlエンコードされたToken Binding IDと一致することも検証します。

  11. hashを response.clientDataJSON に対してSHA-256でハッシュを計算した結果とします。

  12. attestationObject フィールド（AuthenticatorAttestationResponse構造体）の CBORデコードを実行し、アテステーション文フォーマットfmt、authenticator dataauthData、アテステーション文attStmtを取得します。

  13. rpIdHashが authData内でRP IDのSHA-256ハッシュ値と一致することを検証します。

  14. User Presentビットが flags（authData内）でセットされていることを検証します。

  15. この登録でユーザー検証が必要な場合、 flagsのUser Verifiedビットがセットされていることも検証します。

  16. authData内のcredential public keyの"alg"パラメータが、 alg 属性と一致することを、options.pubKeyCredParams内の 各項目に対して検証します。

  17. clientExtensionResults内のクライアント拡張出力値と authDataのextensions内の認証器拡張出力値が、 options.extensions で指定されたクライアント拡張入力値やRelying Partyのポリシー（未指定拡張の扱い）に照らして 期待通りであることを検証します。一般的に「期待通り」の意味はRelying Partyと利用拡張によって異なります。

    注記: クライアントプラットフォームは追加の認証器拡張やクライアント拡張を設定するローカルポリシーを持つ場合があり、 options.extensions で指定されていない値が認証器拡張出力やクライアント拡張出力に現れることもあります。Relying Partyは こうした状況にも対応できるようにし、未指定拡張を無視するかアテステーションを拒否するかはポリシーと利用拡張によって判断できます。

    注記: 全ての拡張はクライアント・認証器の双方でOPTIONALなので、Relying Partyは 要求した拡張が全く・一部のみしか反映されない場合にも対応できるようにすべきです。

  18. アテステーション文フォーマットを、fmtとWebAuthn Attestation Statement Format Identifier値群とのUSASCII大文字小文字区別一致で判定します。 最新のWebAuthn Attestation Statement Format Identifier値リストは IANA "WebAuthn Attestation Statement Format Identifiers"レジストリ[IANA-WebAuthn-Registries]で管理されています（[RFC8809]）。

  19. attStmtが正しいアテステーション文で、正当なアテステーション署名を伝達していることを、 fmtのアテステーション文フォーマットの検証手順で attStmt, authData, hashを用いて検証します。

    注記: 各アテステーション文フォーマットは 独自の検証手順を持ちます。 規定済みフォーマットについては§ 8 定義済みアテステーション文フォーマットおよび 最新情報は[IANA-WebAuthn-Registries]を参照してください。

  20. 検証が成功した場合、そのアテステーション型・フォーマットfmtに対し許容される信頼アンカー（アテステーションルート証明書）のリストを 信頼できる情報源またはポリシーから取得します。例えばFIDO Metadata Service[FIDOMetadataService]は aaguid （attestedCredentialData、authData内）を使い こうした情報取得手段の一つとなります。

  21. 手順19の検証手順の出力に基づき、アテステーションの信頼性を評価します：

  22. credentialId が他のユーザーに既に登録されていないことを確認します。 既登録の認証情報で新規登録を要求された場合、Relying Partyは この登録セレモニーを失敗させるべきですが、例えば旧登録を削除しつつ受け入れることも可能です。

  23. アテステーション文attStmtが正常に検証され、信頼できると判断された場合は、 options.userで 指定されたアカウントに新しい認証情報を登録します：

    推奨事項：

  24. アテステーション文attStmtが正常に検証されたが手順21で信頼できない場合、Relying Partyは この登録セレモニーを失敗させるべきです。

    注記: ただし、ポリシーで許されていれば、Relying Partyは credential IDと認証情報公開鍵を登録して 自己アテステーションと扱うこともできます（§ 6.5.3 アテステーション型参照）。 この場合、Relying Partyは 公開鍵認証情報が特定の認証器モデルで生成されたという暗号的証明がないことを表明することになります。 詳細は[FIDOSecRef]および[UAFProtocol]参照。

アテステーションオブジェクトの検証には、手順20で許容信頼アンカーを判定できる信頼手段が必要です。 また証明書を利用する場合、Relying Partyは中間CA証明書のステータス情報にアクセスできなければなりません。 Relying Partyは、クライアントがアテステーション情報に証明書チェーンを含めていない場合にも チェーン構築ができる必要があります。

7.2. 認証アサーションの検証

認証セレモニーを実施するために、Relying Partyは以下の手順を踏まなければなりません：

  1. optionsをPublicKeyCredentialRequestOptions 構造体として新規作成し、セレモニーの要件に合わせて設定します。

    もし options.allowCredentials が存在する場合、 各項目のtransports メンバーは、 登録時に credential.response.getTransports() の返値で設定すべきです。

  2. navigator.credentials.get() を呼び出し、optionsを publicKey オプションとして渡します。 成功したPromiseの結果をcredentialとします。 Promiseがrejectされた場合は、ユーザーに分かる形でエラー表示するか、状況に応じてユーザー体験を誘導します。 各種エラー状況については§ 6.3.3 authenticatorGetAssertion操作参照。

  3. responseを credential.response とします。 responseがAuthenticatorAssertionResponse のインスタンスでなければ、セレモニーをユーザー向けエラーで中断します。

  4. clientExtensionResultsを credential.getClientExtensionResults() の呼び出し結果とします。

  5. options.allowCredentials が空でない場合、 credential.id が options.allowCredentials のリストに含まれる 公開鍵認証情報の一つであることを確認します。

  6. 認証されるユーザーを特定し、このユーザーがcredential.id で特定される 公開鍵認証情報ソース credentialSourceの所有者であることを検証します：

    認証セレモニー開始前にユーザーが特定されている場合（例：ユーザー名やCookieなど）

    特定されたユーザーがcredentialSourceの所有者であることを検証します。もし response.userHandle が存在すれば、その値をuserHandleとし、userHandleも同じユーザーに対応していることを検証します。

    認証セレモニー開始前にユーザーが特定されていない場合

    response.userHandle が存在し、その値で特定されるユーザーがcredentialSourceの所有者であることを検証します。

  7. credential.id （用途によりcredential.rawIdでも可）を用いて、 対応する認証情報公開鍵を検索し、credentialPublicKeyとします。

  8. cData、authData、sigを responseの clientDataJSON、 authenticatorData、 signature の値とします。

  9. JSONtextをcDataの値に対してUTF-8デコードした結果とします。

    注記: どのUTF-8デコード実装でも、UTF-8 decodeアルゴリズムと同じ結果になれば問題ありません。特に先頭のバイトオーダーマーク（BOM）は必ず除去してください。

  10. C（署名に用いられたとされるクライアントデータ）を、JSONtextに対して実装依存のJSONパーサーを実行した結果とします。

    注記: Cは実装依存のデータ構造でも構いませんが、本アルゴリズムで参照できるように構成要素がアクセス可能である必要があります。

  11. C.type の値が文字列webauthn.getであることを検証します。

  12. C.challenge の値が options.challenge のbase64urlエンコード値と一致することを検証します。

  13. C.origin の値がRelying Partyのオリジンと一致することを検証します。

  14. C.tokenBinding.status の値が、アテステーション取得時のTLS接続のToken Bindingの状態と一致することを検証します。TLS接続でToken Bindingが使用されていた場合は、 C.tokenBinding.id がその接続のbase64urlエンコードされたToken Binding IDと一致することも検証します。

  15. rpIdHashが authData内でRP IDのSHA-256ハッシュ値と一致することを検証します。

    注記: appid拡張を使う場合、このステップは特殊な処理が必要です。詳細は§ 10.1 FIDO AppID拡張（appid）参照。

  16. User Presentビットが flags（authData内）でセットされていることを検証します。

  17. このアサーションでユーザー検証が必要な場合、 flagsのUser Verifiedビットがセットされていることも検証します。

  18. clientExtensionResults内のクライアント拡張出力値と authDataのextensions内の認証器拡張出力値が、 options.extensions で指定されたクライアント拡張入力値やRelying Partyのポリシー（未指定拡張の扱い）に照らして 期待通りであることを検証します。一般的に「期待通り」の意味はRelying Partyと利用拡張によって異なります。

    注記: クライアントプラットフォームは追加の認証器拡張やクライアント拡張を設定するローカルポリシーを持つ場合があり、 options.extensions で指定されていない値が認証器拡張出力やクライアント拡張出力に現れることもあります。Relying Partyは こうした状況にも対応できるようにし、未指定拡張を無視するかアサーションを拒否するかはポリシーと利用拡張によって判断できます。

    注記: 全ての拡張はクライアント・認証器の双方でOPTIONALなので、Relying Partyは 要求した拡張が全く・一部のみしか反映されない場合にも対応できるようにすべきです。

  19. hashをcDataに対してSHA-256でハッシュを計算した結果とします。

  20. credentialPublicKeyを使い、sigがauthDataとhashのバイナリ連結に対する正当な署名であることを検証します。

    注記: この検証ステップはFIDO U2F認証器が生成した署名とも互換性があります。§ 6.1.2 FIDO U2F署名形式互換性参照。

  21. storedSignCountを credential.id に関連付けられた保存済み署名カウンター値とします。 authData.signCount またはstoredSignCountが非ゼロの場合、以下のサブステップを実行します：

    • authData.signCount が

      保存済みstoredSignCountより大きい場合:
      storedSignCountをauthData.signCountの値で更新します。
      保存済みstoredSignCount以下の場合:
      認証器が複製された可能性のシグナルであり、少なくとも 認証情報秘密鍵が2つ以上存在し並列利用されているかもしれません。 Relying Partyはこの情報をリスク評価に活用すべきです。 Relying Partyがこの場合にstoredSignCountを更新するか、認証セレモニーを失敗させるかは Relying Partyごとに異なります。

  22. 以上のステップがすべて成功した場合、認証セレモニーを適切に継続します。失敗した場合は認証セレモニーを失敗とします。

8. 定義済みアテステーション文フォーマット

WebAuthnはプラグイン可能なアテステーション文フォーマットをサポートします。この節では初期のフォーマットセットを定義します。

8.1. アテステーション文フォーマット識別子

アテステーション文フォーマットは、そのアテステーション文フォーマットの作者が選択した文字列、すなわちアテステーション文フォーマット識別子によって識別されます。

アテステーション文フォーマット識別子は IANA "WebAuthn Attestation Statement Format Identifiers" レジストリ[IANA-WebAuthn-Registries]（[RFC8809]で設立）に登録すべきです。 登録済みのアテステーション文フォーマット識別子は当然すべてユニークです。

未登録の識別子は、ユニーク性を保証するため、開発者が登録したドメイン名を利用し、小文字の逆ドメイン形式で命名すべきです。 すべてのアテステーション文フォーマット識別子は最大32オクテットまで、印刷可能なUSASCII文字（バックスラッシュとダブルクォートを除く）で構成されなければなりません。これは [RFC5234]のVCHARから%x22および%x5cを除いたものです。

注記: ドメイン名ベースの識別子はLDHラベルのみ含めなければなりません（[RFC5890]参照）。

実装はWebAuthnアテステーション文フォーマット識別子を大文字・小文字区別で一致させなければなりません。

複数バージョンが存在する可能性があるフォーマットは、識別子にバージョンを含めるべきです。事実上、異なるバージョンは異なるフォーマットとして扱われます（例：packed2は § 8.2 Packed Attestation Statement Formatの新バージョン）。

以下のセクションでは、現在定義され登録済みのアテステーション文フォーマットとその識別子を示します。 最新のWebAuthn拡張リストは IANA "WebAuthn Attestation Statement Format Identifiers" レジストリ[IANA-WebAuthn-Registries]（[RFC8809]）で管理されています。

8.2. Packedアテステーション文フォーマット

これはWebAuthn最適化のアテステーション文フォーマットです。非常にコンパクトかつ拡張性のあるエンコーディング方式を使用します。 限られたリソース（例：セキュアエレメント）しか持たない認証器でも実装可能です。

アテステーション文フォーマット識別子

packed

対応アテステーション型

Basic, Self, AttCA

構文

Packedアテステーション文の構文は次のCDDLで定義されます：

    $$attStmtType //= (
                          fmt: "packed",
                          attStmt: packedStmtFormat
                      )

    packedStmtFormat = {
                           alg: COSEAlgorithmIdentifier,
                           sig: bytes,
                           x5c: [ attestnCert: bytes, * (caCert: bytes) ]
                       } //
                       {
                           alg: COSEAlgorithmIdentifier
                           sig: bytes,
                       }

各フィールドの意味は以下のとおりです：

alg

COSEAlgorithmIdentifier 署名生成に用いたアルゴリズムの識別子

sig

アテステーション署名のバイト列

x5c

この配列の要素は、X.509形式でエンコードされたattestnCertとその証明書チェーン（存在する場合）を含みます。 アテステーション証明書attestnCertは配列の最初の要素でなければなりません。

attestnCert

X.509形式でエンコードされたアテステーション証明書

署名手順

このアテステーション文フォーマットの署名手順は アサーション署名生成手順と類似です。

  1. authenticatorDataをアテステーション用認証器データ、 clientDataHashをシリアライズされたクライアントデータのハッシュとする。

  2. BasicまたはAttCA型アテステーションの場合、 認証器はauthenticatorDataとclientDataHashを連結し、 認証器固有の仕組みで選択されたアテステーション秘密鍵で署名しsigとする。 x5cはattestnCertと関連証明書チェーン（存在する場合）をセットする。 algはアテステーション秘密鍵のアルゴリズムをセットする。

  3. 自己アテステーションの場合、 認証器はauthenticatorDataとclientDataHashを連結し、認証情報秘密鍵で署名してsigとする。 algは認証情報秘密鍵のアルゴリズムをセットし、他のフィールドは省略する。

検証手順

検証手順入力（attStmt、authenticatorData、clientDataHash）が与えられた場合の 検証手順は以下の通り：

  1. attStmtが上記構文に従った有効なCBORであることを検証し、CBORデコードしてフィールドを抽出する。

  2. x5cが存在する場合：

  3. x5cがない場合は自己アテステーション型。

8.2.1. Packedアテステーション証明書要件

アテステーション証明書には以下のフィールド/拡張が必要です：

8.3. TPMアテステーション文フォーマット

このアテステーション文フォーマットは、暗号エンジンとしてTrusted Platform Module（TPM）を利用する認証器で一般的に使われます。

アテステーション文フォーマット識別子

tpm

対応アテステーション型

AttCA

構文

TPMアテステーション文の構文は以下の通りです：

    $$attStmtType // = (
                           fmt: "tpm",
                           attStmt: tpmStmtFormat
                       )

    tpmStmtFormat = {
                        ver: "2.0",
                        (
                            alg: COSEAlgorithmIdentifier,
                            x5c: [ aikCert: bytes, * (caCert: bytes) ]
                        )
                        sig: bytes,
                        certInfo: bytes,
                        pubArea: bytes
                    }

上記フィールドの意味は以下の通り：

ver

署名が準拠するTPM仕様のバージョン。

alg

COSEAlgorithmIdentifier 署名生成に用いたアルゴリズムの識別子。

x5c

aikCert（X.509エンコード）とその証明書チェーン。

aikCert

アテステーションに用いるAIK証明書（X.509エンコード）。

sig

アテステーション署名（TPMv2-Part2 §11.3.4で規定されるTPMT_SIGNATURE構造体）。

certInfo

上記署名が計算されたTPMS_ATTEST構造体（TPMv2-Part2 §10.12.8参照）。

pubArea

TPMが認証情報公開鍵を表現するTPMT_PUBLIC構造体（TPMv2-Part2 §12.2.4参照）。

署名手順

authenticatorDataをアテステーション用認証器データ、 clientDataHashをシリアライズされたクライアントデータのハッシュとする。

authenticatorDataとclientDataHashを連結してattToBeSignedを作成。

[TPMv2-Part3] §18.2で規定される手順でアテステーション秘密鍵を使い署名を生成。 extraDataパラメータにはattToBeSignedのハッシュ（署名アルゴリズム"alg"に対応するハッシュ、RS256ならSHA-256）を設定。

pubAreaフィールドには認証情報公開鍵の公開領域、certInfoフィールドには同名の出力パラメータ、sigフィールドには上記手順で得た署名値をセット。

検証手順

検証手順入力（attStmt、authenticatorData、clientDataHash）が与えられた場合の 検証手順は以下の通り：

attStmtが上記構文に従った有効なCBORであることを検証し、CBORデコードしてフィールドを抽出。

pubAreaのparametersとuniqueフィールドで指定された公開鍵が、 authenticatorData内のattestedCredentialData のcredentialPublicKey と一致することを検証。

authenticatorDataとclientDataHashを連結してattToBeSignedを作成。

certInfoの妥当性を検証：

  • magicがTPM_GENERATED_VALUEにセットされていること。

  • typeがTPM_ST_ATTEST_CERTIFYにセットされていること。

  • extraDataがattToBeSignedのハッシュ（"alg"で用いるハッシュ）にセットされていること。

  • attestedがTPMv2-Part2 §10.12.3で規定されるTPMS_CERTIFY_INFO構造体を含み、 そのnameフィールドがpubAreaの有効なName（pubAreaのnameAlgフィールドに従いTPMv2-Part1 §16の手順で算出）を持つこと。

  • x5cが存在すること。

  • 「Standard Attestation Structure」（TPMv2-Part1 §31.2）の残りフィールド qualifiedSigner、clockInfo、firmwareVersionは無視してよい。 これらはリスクエンジンの入力に利用されてもよい。

  • sigがcertInfoに対してaikCertのアテステーション公開鍵とalgで署名検証に成功すること。

  • aikCertが§ 8.3.1 TPMアテステーション証明書要件を満たすこと。

  • aikCertにOID1.3.6.1.4.1.45724.1.1.4（id-fido-gen-ce-aaguid）拡張がある場合、 この値がauthenticatorData内の aaguid と一致することを検証。

  • 成功した場合、アテステーション型AttCAと アテステーション信頼パスx5cを実装依存値として返す。

8.3.1. TPMアテステーション証明書要件

TPMアテステーション証明書は以下のフィールド/拡張が必須です：

8.4. Androidキーアテステーション文フォーマット

対象となる認証器がAndroid "N"以降のプラットフォーム上のプラットフォーム認証器である場合、 アテステーション文はAndroidキーアテステーションに基づきます。この場合、アテステーション文は セキュアな実行環境で動作するコンポーネントによって生成されますが、アテステーション用認証器データはこの環境外で生成されます。WebAuthn Relying Partyは、アテステーションに使用されたとされる認証器データが アテステーション証明書の拡張データのフィールドと一致していることを確認することが期待されます。

アテステーション文フォーマット識別子

android-key

対応アテステーション型

Basic

構文

Androidキーアテステーション文は単にAndroidアテステーション文（DERエンコードのX.509証明書列）から成ります。Android開発者ドキュメント参照。 構文は以下の通り定義されます：

    $$attStmtType //= (
                          fmt: "android-key",
                          attStmt: androidStmtFormat
                      )

    androidStmtFormat = {
                          alg: COSEAlgorithmIdentifier,
                          sig: bytes,
                          x5c: [ credCert: bytes, * (caCert: bytes) ]
                        }
署名手順

authenticatorDataをアテステーション用認証器データ、 clientDataHashをシリアライズされたクライアントデータのハッシュとする。

Android Key AttestationはkeyStore.getCertificateChain(myKeyUUID)を呼び出し、 clientDataHashをチャレンジ値として渡します（例： setAttestationChallenge利用）。x5cにはその返値をセットします。

認証器はauthenticatorDataとclientDataHashを連結し、 認証情報秘密鍵で署名してsigを生成します。algには署名フォーマットのアルゴリズムをセットします。

検証手順

検証手順入力 （attStmt、authenticatorData、clientDataHash）が与えられた場合の 検証手順は以下の通り：

  • attStmtが上記構文に従った有効なCBORであることを検証し、CBORデコードしてフィールドを抽出する。

  • sigが、authenticatorDataとclientDataHashの連結に対し、 x5cの最初の証明書の公開鍵とalgで署名検証に成功することを確認する。

  • x5cの最初の証明書の公開鍵が、 attestedCredentialData 内のcredentialPublicKey と一致することを確認する。

  • アテステーション証明書拡張データ内のattestationChallengeフィールドが clientDataHashと一致することを確認する。

  • アテステーション証明書拡張データの適切なauthorization listを使って以下を検証：

    • AuthorizationList.allApplicationsフィールドがいずれのauthorization list （softwareEnforced・teeEnforced）にも存在しないこと。PublicKeyCredentialはRP IDにスコープされていなければならない。

    • 以下について、RPが信頼実行環境のみ受け入れたい場合はteeEnforcedのみ、それ以外は両方または合算で検証：

      • AuthorizationList.originフィールド値がKM_ORIGIN_GENERATEDであること。

      • AuthorizationList.purposeフィールド値がKM_PURPOSE_SIGNであること。

  • 成功した場合、アテステーション型Basicと アテステーション信頼パスx5cを実装依存値として返す。

8.4.1. Androidキーアテステーション文証明書の要件

Androidキーアテステーションアテステーション証明書のAndroidキーアテステーション証明書拡張データはOID1.3.6.1.4.1.11129.2.1.17で識別され、 スキーマはAndroid開発者ドキュメントに定義されています。

8.5. Android SafetyNetアテステーション文フォーマット

対象の認証器が、特定のAndroidプラットフォーム上のプラットフォーム認証器である場合、 アテステーション文はSafetyNet APIに基づく可能性があります。 この場合、認証器データはSafetyNet APIの呼び出し元（通常はAndroid上のアプリ）が完全に制御し、 アテステーション文はプラットフォームの健全性やアプリケーションのIDに関する情報を提供します。 （詳細はSafetyNetのドキュメント参照）。

アテステーション文フォーマット識別子

android-safetynet

対応アテステーション型

Basic

構文

Androidアテステーション文の構文は以下の通りです：

    $$attStmtType //= (
                          fmt: "android-safetynet",
                          attStmt: safetynetStmtFormat
                      )

    safetynetStmtFormat = {
                              ver: text,
                              response: bytes
                          }

各フィールドの意味は以下の通り：

ver

SafetyNet APIを提供するGoogle Play Servicesのバージョン番号。

response

SafetyNet APIのgetJwsResult()呼び出しのUTF-8エンコード結果。この値はJWS[RFC7515]オブジェクト（SafetyNetオンラインドキュメント参照） のCompact Serialization形式です。

署名手順

authenticatorDataをアテステーション用認証器データ、 clientDataHashをシリアライズされたクライアントデータのハッシュとする。

authenticatorDataとclientDataHashを連結し、SHA-256ハッシュを計算し、 その結果をattToBeSignedとする。

SafetyNetアテステーションをリクエストし、attToBeSignedをnonce値として渡す。responseにはその結果を、 verには認証器で実行中のGoogle Play Servicesのバージョンをセットする。

検証手順

検証手順入力 （attStmt、authenticatorData、clientDataHash）が与えられた場合の 検証手順は以下の通り：

  • attStmtが上記構文に従った有効なCBORであることを検証し、CBORデコードしてフィールドを抽出する。

  • responseがバージョンverの有効なSafetyNetレスポンスであることを、 SafetyNetオンラインドキュメントの手順に従って検証する。 現時点ではSafetyNetレスポンスのフォーマットは1つだけであり、verは将来のために予約されています。

  • responseペイロード内のnonce属性が、 authenticatorDataとclientDataHashの連結のSHA-256ハッシュのBase64エンコード値と一致することを検証する。

  • SafetyNetレスポンスが実際にSafetyNetサービス由来であることを、 SafetyNetオンラインドキュメントの手順に従って検証する。

  • 成功した場合、アテステーション型Basicと アテステーション信頼パスx5cを実装依存値として返す。

8.6. FIDO U2Fアテステーション文フォーマット

このアテステーション文フォーマットは、[FIDO-U2F-Message-Formats]で定義されるフォーマットを使用するFIDO U2F認証器と共に利用されます。

アテステーション文フォーマット識別子

fido-u2f

対応アテステーション型

Basic, AttCA

構文

FIDO U2Fアテステーション文の構文は以下の通りです：

    $$attStmtType //= (
                          fmt: "fido-u2f",
                          attStmt: u2fStmtFormat
                      )

    u2fStmtFormat = {
                        x5c: [ attestnCert: bytes ],
                        sig: bytes
                    }

各フィールドの意味は以下の通り：

x5c

X.509形式のアテステーション証明書を1つだけ含む配列。

sig

アテステーション署名。 署名は、認証器からクライアントが受信した（生の）U2F登録レスポンスメッセージ [FIDO-U2F-Message-Formats]上で計算されています。

署名手順

対象のアテスト認証情報の認証情報公開鍵がアルゴリズム-7（ES256）でない場合はエラーで終了します。 そうでなければ、authenticatorDataをアテステーション用認証器データ、 clientDataHashをシリアライズされたクライアントデータのハッシュとする。 （SHA-256でハッシュ化されるため、clientDataHashは32バイト長です。）

[FIDO-U2F-Message-Formats]の Section 4.3に従って登録レスポンスメッセージを生成します。 applicationパラメータには、対象認証情報がスコープされているRP IDのSHA-256ハッシュを、 challengeパラメータにはclientDataHashを、 key handleパラメータには対象認証情報IDを設定します。 この登録レスポンスメッセージの生署名部分（user public key, key handle, 証明書除く）をsig、 アテステーション公開鍵の証明書をx5cとします。

検証手順

検証手順入力 （attStmt、authenticatorData、clientDataHash）が与えられた場合の 検証手順は以下の通り：

  1. attStmtが上記構文に従った有効なCBORであることを検証し、CBORデコードしてフィールドを抽出する。

  2. x5cが要素1つであることを確認し、attCertとする。certificate public keyはattCertで伝達される公開鍵。 certificate public keyがP-256曲線上のEC公開鍵でない場合はエラーで終了。

  3. authenticatorDataからrpIdHashを抽出し、 authenticatorData.attestedCredentialDataから credentialIdとcredentialPublicKeyを抽出。

  4. COSE_KEY形式のcredentialPublicKey（RFC8152 §7参照）をRaw ANSI X9.62公開鍵形式（FIDO-Registry §3.6.2参照）に変換：

    • xをcredentialPublicKey内の"-2"キー（x座標）値として抽出し、32バイト長であることを確認。 サイズが異なるか"-2"キーが無い場合はエラー。

    • yをcredentialPublicKey内の"-3"キー（y座標）値として抽出し、32バイト長であることを確認。 サイズが異なるか"-3"キーが無い場合はエラー。

    • publicKeyU2Fを0x04 || x || yで連結。

      注記: これは非圧縮ECCキー形式であることを意味します。

  5. verificationDataを 0x00 || rpIdHash || clientDataHash || credentialId || publicKeyU2F で連結する（FIDO-U2F-Message-Formats Section 4.3参照）。

  6. Section 4.1.4（SEC1）に従い、SHA-256をハッシュ関数としてverificationDataとcertificate public keyでsigを検証。

  7. 必要に応じてx5cを外部知識と照合し、attStmtがBasic型かAttCA型か判断する。

  8. 成功した場合、アテステーション型Basic、AttCAまたは不明、 アテステーション信頼パスx5cを実装依存値として返す。

8.7. Noneアテステーション文フォーマット

noneアテステーション文フォーマットは、WebAuthn Relying Partyがアテステーション情報の受信を希望しないことを示した場合（§ 5.4.7 Attestation Conveyance Preference Enumeration (enum AttestationConveyancePreference)参照）、認証器が提供するアテステーション文を置き換えるために使用されます。

認証器がアテステーションをサポートしない場合、この形式のアテステーション文を直接生成しても構いません。

アテステーション文フォーマット識別子

none

対応アテステーション型

None

構文

noneアテステーション文の構文は以下の通りです：

    $$attStmtType //= (
                          fmt: "none",
                          attStmt: emptyMap
                      )

    emptyMap = {}
署名手順

上記で定義された固定のアテステーション文を返します。

検証手順

アテステーション型Noneおよび空のアテステーション信頼パスを表す実装依存値を返します。

8.8. Apple匿名アテステーション文フォーマット

このアテステーション文フォーマットは、WebAuthnをサポートする特定のAppleデバイスでAppleが専用に使用します。

アテステーション文フォーマット識別子

apple

対応アテステーション型

匿名化CA

構文

Appleアテステーション文の構文は以下の通りです：

    $$attStmtType //= (
                          fmt: "apple",
                          attStmt: appleStmtFormat
                      )

    appleStmtFormat = {
                          x5c: [ credCert: bytes, * (caCert: bytes) ]
                      }

各フィールドの意味は以下の通り：

x5c

X.509形式でエンコードされたcredCertおよび証明書チェーン。

credCert

アテステーションに用いる認証情報公開鍵証明書（X.509形式でエンコード）。

署名手順

  1. authenticatorDataをアテステーション用認証器データ、clientDataHashをシリアライズされたクライアントデータのハッシュとする。

  2. authenticatorDataとclientDataHashを連結し、nonceToHashとする。

  3. nonceToHashにSHA-256ハッシュを実行してnonceを生成。

  4. Apple匿名アテステーションCAが認証情報公開鍵用のX.509証明書を生成し、nonceをOID1.2.840.113635.100.8.2の証明書拡張として含める。 credCertはこの証明書を指す。credCertがアテステーションの証拠となり、nonceによりアテステーションのライブ性も証明される。さらに、nonceはauthenticatorDataとクライアントデータの完全性を保護する。

  5. x5cにcredCertおよび証明書チェーンを設定。

検証手順

検証手順入力（attStmt、authenticatorData、clientDataHash）が与えられた場合の検証手順は以下の通り：

  1. attStmtが上記構文に従った有効なCBORであることを検証し、CBORデコードしてフィールドを抽出する。

  2. authenticatorDataとclientDataHashを連結し、nonceToHashとする。

  3. nonceToHashにSHA-256ハッシュを実行してnonceを生成。

  4. nonceがcredCert内のOID1.2.840.113635.100.8.2拡張値と一致することを検証。

  5. 認証情報公開鍵がcredCertのSubject Public Keyと一致することを検証。

  6. 成功した場合、アテステーション型匿名化CAとアテステーション信頼パスx5cを表す実装依存値を返す。

9. WebAuthn拡張

公開鍵認証情報の生成や、認証アサーションの要求・生成の仕組みは、§ 5 Web認証APIで定義されている通り、特定のユースケースに合わせて拡張することができます。 各ケースは、登録拡張および認証拡張を定義することで対応します。

すべての拡張はクライアント拡張です。つまり拡張はクライアントとの通信や処理を伴います。 クライアント拡張は以下の手順とデータを定義します：

公開鍵認証情報を作成する場合や認証アサーションを要求する場合、 WebAuthn Relying Partyは拡張のセットを要求できます。 これらの拡張は、クライアントやWebAuthn認証器がサポートしていれば、要求された操作中に呼び出されます。 Relying Partyは各拡張に対するクライアント拡張入力を get() （認証拡張用）またはcreate() （登録拡張用）でクライアントに送信します。 クライアントは、サポートする各拡張についてクライアント拡張処理を行い、 指定された各拡張に従いクライアントデータを拡張し、 拡張識別子とクライアント拡張出力値を含めます。

拡張は認証器拡張でもあり得ます。つまり認証器との通信や処理を伴います。 認証器拡張は以下の手順とデータを定義します：

認証器拡張の場合、クライアント拡張処理の一部として、クライアントは各拡張のCBOR形式の認証器拡張入力値も生成します（多くの場合対応するクライアント拡張入力値に基づく）。 これらはcreate() （登録拡張用）またはget() （認証拡張用）で認証器に渡されます。 これらの認証器拡張入力値は、 CBORで名前と値のペアとして表現され、名前は拡張識別子、値は対応する認証器拡張入力値です。 認証器はサポートする拡張について追加処理を行い、各拡張に定義された方法でCBOR形式の認証器拡張出力値を返します。 クライアント拡張処理の一部として、認証器拡張の認証器拡張出力値をクライアント拡張出力値生成の入力として利用します。

すべてのWebAuthn拡張はクライアント・認証器双方でOPTIONALです。 したがって、Relying PartyがAPI呼び出しで拡張を指定しても、クライアントのブラウザやOSで無視され認証器に渡されない場合や、認証器で無視される場合があります。 拡張が無視されてもWebAuthn API処理の失敗とはみなされないため、Relying Partyは拡張指定時に、 それらの一部または全部が無視される場合にも対応できるようにしておく必要があります。

最大限多くの拡張に対応したいクライアントは、認識しない拡張をそのまま認証器に渡し、クライアント拡張入力をCBORで単純にエンコードして認証器拡張入力値にしても構いません。すべてのWebAuthn拡張はこの実装選択がユーザーのセキュリティやプライバシーを損なわないよう定義されなければなりません。 例えば拡張がクライアント処理を要求する場合、単純なパススルーでは意味的に無効な認証器拡張入力値となるよう定義でき、 その結果認証器が拡張を無視します。すべてOPTIONALなのでAPI動作で機能的な失敗にはなりません。同様に、クライアントは認識しない拡張の出力についても、 認証器拡張出力値をJSONにエンコードするだけでクライアント拡張出力値を生成できます（CBOR出力がJSONに存在する型のみの場合）。

クライアントが認識しない拡張をパススルーする場合、 クライアント拡張入力内のJavaScript値はCBOR値へ変換されて認証器拡張入力となります。 JavaScript値が%ArrayBuffer%の場合はCBORバイト配列に変換されます。 非整数の数値はCBOR 64ビット浮動小数点数に変換されます。 その他、JavaScript型がJSON型に対応する場合は、[RFC8949] §6.2（JSON→CBOR）に従い変換しますが、入力はJSON型値ではなくJavaScript型値です。 変換後、CBORの正規化はCTAP2正規CBORエンコーディング形式で行う必要があります。

JavaScript数値変換規則の結果、クライアントが認識しない拡張をパススルーした場合、拡張が浮動小数点値を使うときでも、その値が整数なら 認証器はCBOR整数として受け取る準備が必要です。 認証器がクライアントサポートなしでも拡張を常に動作させたい場合にこれは起こります。

同様に、クライアントが認識しない拡張の出力を受け取る場合、認証器拡張出力内のCBOR値は、クライアント拡張出力のJavaScript値に変換されます。 CBOR値がバイト列ならJavaScript%ArrayBuffer%（base64url文字列ではなく）に変換されます。 その他、CBOR型がJSON型に対応する場合は[RFC8949] §6.1（CBOR→JSON）に従い変換しますが、出力はJSON型値ではなくJavaScript型値です。

一部クライアントは、このパススルー機能を機能フラグ下で実装する場合もあります。 この機能はイノベーションを促進し、認証器が新しい拡張を試したり、クライアントの明示的なサポート前にRelying Partyが利用可能にすることを可能にします。

最新の登録済みWebAuthn拡張一覧はIANA "WebAuthn Extension Identifiers"レジストリ [IANA-WebAuthn-Registries]（[RFC8809]）を参照してください。

9.1. 拡張識別子

拡張は、拡張作者が選択した文字列、すなわち拡張識別子で識別されます。

拡張識別子は IANA "WebAuthn Extension Identifiers"レジストリ[IANA-WebAuthn-Registries]（[RFC8809]）に登録すべきです。 登録済み拡張識別子は当然すべてユニークです。

未登録の拡張識別子は、定義主体（例：myCompany_extension）を含めることでグローバルな一意性を目指すべきです。

すべての拡張識別子は最大32オクテットまで、印刷可能なUSASCII文字（バックスラッシュとダブルクォートを除く）で構成されなければなりません（RFC5234のVCHARから%x22および%x5cを除く）。 実装はWebAuthn拡張識別子を大文字・小文字区別で一致させなければなりません。

複数バージョンがあり得る拡張は、識別子にバージョンを含めるよう注意すべきです。事実上、異なるバージョンは別拡張として扱われます（例：myCompany_extension_01）。

§ 10 定義済み拡張で追加の拡張とその識別子を定義しています。 最新のWebAuthn Extension IdentifiersはIANAレジストリ[IANA-WebAuthn-Registries]（[RFC8809]）を参照してください。

9.2. 拡張の定義

拡張の定義には、拡張識別子、get() またはcreate() 呼び出しで送信されるクライアント拡張入力引数、 クライアント拡張処理の規則、 クライアント拡張出力値を指定しなければなりません。 拡張が認証器と通信する場合（認証器拡張である場合）は、 CBOR形式の認証器拡張入力引数（authenticatorGetAssertionまたはauthenticatorMakeCredential呼び出しで送信）、 認証器拡張処理の規則、 CBOR形式の認証器拡張出力値も指定しなければなりません。

クライアントで処理されるクライアント拡張は、WebAuthn Relying Partyが拡張がクライアントで処理されたと知ることができるよう、 クライアント拡張出力値を必ず返さなければなりません。同様に認証器処理が必要な拡張は 認証器拡張出力値を返し、Relying Partyが認証器で処理されたと知ることができるようにします。 結果値が特に必要ない場合は、JSONのBoolean型クライアント拡張出力（trueで理解・処理済みを示す）を返すよう定義すべきです。 同様に、結果値不要な認証器拡張は値を返す必要があり、CBOR Boolean型認証器拡張出力（trueで理解・処理済みを示す）を返すべきです。

9.3. リクエストパラメータの拡張

拡張は1つまたは2つのリクエスト引数を定義します。クライアント拡張入力はJSONでエンコード可能な値で、 WebAuthn Relying Partyからクライアントに get() またはcreate() 呼び出しで渡されます。 一方、CBOR形式の認証器拡張入力は、 クライアントから認証器に認証器拡張の処理中に渡されます。

Relying Partyは 拡張の利用要求と同時にクライアント拡張入力を設定します。これは extensions オプション内に、 create() または get() 呼び出しへと含めて指定します。 エントリーキーは拡張識別子、値はクライアント拡張入力です。

注記: 他の文書では拡張入力が常に拡張識別子をエントリーキーとして使わない場合もあります。 新しい拡張は上記の慣例に従うべきです。

var assertionPromise = navigator.credentials.get({
    publicKey: {
        // 他のメンバーは省略
        extensions: {
            // "webauthnExample_foobar"拡張を識別する"エントリーキー"で、 
            // 値は2つの入力パラメータを持つマップ：
            "webauthnExample_foobar": {
              foo: 42,
              bar: "barfoo"
            }
        }
    }
});

拡張定義は、そのクライアント拡張入力の有効値も指定しなければなりません。 クライアントは無効なクライアント拡張入力の拡張を無視すべきです。拡張がRelying Partyからパラメータを必要としない場合は、 Boolean型のクライアント引数（trueで拡張が要求されたことを示す）として定義すべきです。

クライアント処理にのみ影響する拡張は認証器拡張入力を指定する必要はありません。 認証器処理がある拡張は、認証器拡張入力をクライアント拡張入力から計算する方法を規定し、 CDDL型 AuthenticationExtensionsAuthenticatorInputs および AuthenticationExtensionsAuthenticatorOutputs に対し、$$extensionInputや$$extensionOutput グループソケットに拡張識別子をエントリーキーとして追加する形で定義しなければなりません。 パラメータ不要な拡張（Boolean型trueで要求）は、認証器拡張入力も定数Boolean値true（CBORメジャータイプ7、値21）として定義すべきです。

以下の例は、識別子webauthnExample_foobarの拡張がunsigned integer型の認証器拡張入力を受け取り、少なくとも1つのバイト列からなる配列を認証器拡張出力として返すことを定義します：

$$extensionInput //= (
  webauthnExample_foobar: uint
)
$$extensionOutput //= (
  webauthnExample_foobar: [+ bytes]
)

注記: 拡張は認証器引数ができるだけ小さくなるように定義すべきです。 一部認証器はBluetooth Low-EnergyやNFCなど低帯域リンクで通信します。

9.4. クライアント拡張処理

拡張は資格情報生成やアサーション生成時に、クライアントに追加処理要件を定義することもできます。 拡張のクライアント拡張入力がクライアント処理の入力となります。 サポートする各クライアント拡張について、 クライアントはclientExtensions マップに対し、 拡張識別子をキー、拡張のクライアント拡張入力を値として追加します。

同様に、クライアント拡張出力は getClientExtensionResults() の結果に辞書形式で表現され、拡張識別子がキー、各拡張のクライアント拡張出力値が値となります。 クライアント拡張入力同様、 クライアント拡張出力もJSONでエンコード可能な値です。 無視された拡張に対して値を返してはなりません。

認証器処理が必要な拡張は、 クライアント拡張入力からCBOR形式の認証器拡張入力を決定する方法、 CBOR形式の認証器拡張出力からクライアント拡張出力を決定する方法を定義しなければなりません。

9.5. 認証器拡張処理

各処理された認証器拡張のCBOR形式の認証器拡張入力値は、 authenticatorMakeCredentialやauthenticatorGetAssertion 操作のextensionsパラメータに含まれます。 extensionsはCBORマップで、各キーが拡張識別子、対応する値がその拡張の認証器拡張入力です。

同様に、拡張出力はextensions部分（認証器データ内）で表現されます。 extensions部分は認証器データ内のCBORマップで、 各キーが拡張識別子、対応する値がその拡張の認証器拡張出力です。

サポートする各拡張について、その認証器拡張処理規則に従い、 認証器拡張入力や他の入力から認証器拡張出力を生成します。 無視された拡張に対して値を返してはなりません。

10. 定義済み拡張

このセクションでは、IANA "WebAuthn Extension Identifiers"レジストリ[IANA-WebAuthn-Registries]（[RFC8809]）に登録される追加の拡張セットを定義します。 これらは広範な相互運用性を目指すユーザーエージェントで実装可能です。

10.1. FIDO AppID 拡張（appid）

この拡張は、WebAuthn Relying Partyが、従来のFIDO U2F JavaScript API[FIDOU2FJavaScriptAPI]で登録された認証情報を使ってアサーションを要求できるようにします。 FIDO APIはRelying Party用の代替識別子AppID（[FIDO-APPID]）を使い、それらAPIで作成された認証情報はその識別子にスコープされます。 この拡張がなければ、WebAuthnで使うためには再登録が必要です。

appid 拡張入力の設定に加え、U2F登録済み認証情報でユーザーが認証できるようにするため、Relying Partyは追加処理が必要です：

  1. 希望するU2F認証情報をallowCredentials オプションでget() メソッドに列挙する：

    • type メンバーをpublic-keyに設定。

    • id メンバーに対象認証情報のU2Fキーハンドルを設定。U2Fキーハンドルは通常base64urlでエンコードされていますが、利用時はバイナリにデコードしてidに使う必要があります。

    allowCredentials にはWebAuthn認証情報IDとU2Fキーハンドルの両方を混在させても構いません。 この拡張でappid を指定しても、rpIdでスコープされたWebAuthn認証情報の利用は妨げません。

  2. アサーション検証時、rpIdHashがAppIDのハッシュとなる場合があることに注意します（RP IDではない）。

この拡張はFIDO互換認証情報の新規作成はできません。WebAuthnで作成された認証情報は、FIDO JavaScript APIとの後方互換性がありません。

注記: appid にはRelying Partyが従来FIDO APIで利用していたAppIDを設定してください。 これはWebAuthnのRP IDをAppID形式に変換したものと同じとは限りません。例：従来AppIDが「https://accounts.example.com」、現在のRP IDが「example.com」など。

拡張識別子

appid

適用操作

認証

クライアント拡張入力

FIDO AppIDを指定するUSVString。

partial dictionary AuthenticationExtensionsClientInputs {
  USVString appid;
};
クライアント拡張処理

  1. facetIdを、呼び出し元のoriginをFIDOの「呼び出しアプリケーションのFacetID決定」アルゴリズムに渡して得る。

  2. appIdを拡張入力値とする。

  3. facetIdとappIdをFIDOの「callerのFacetIDがAppIDに対して認可されているか判定」アルゴリズムに渡す。拒否された場合は"SecurityError"DOMExceptionを返す。

  4. allowCredentialDescriptorList作成時、 U2F認証器が認証情報が不適用であることを示した場合（SW_WRONG_DATA返却）、クライアントはU2F applicationパラメータをappIdのSHA-256ハッシュにして再試行し、それで適用可能な認証情報が得られれば、allowCredentialDescriptorListに追加する。appIdはauthenticatorGetAssertionのrpIdパラメータの代わりとなる。

  5. outputをBoolean値falseとする。

  6. assertionCreationData作成時、 U2F認証器でappIdのSHA-256ハッシュをU2F applicationパラメータに使いアサーションが作成された場合、outputをtrueにする。

注記: 実際には、いくつかの実装は「callerのFacetIDがAppIDに対して認可されているか判定」アルゴリズムの4ステップ目以降を実装していません。代わりに3ステップ目で、ホストの比較を同一サイトで許容しています。

クライアント拡張出力

outputの値を返す。trueの場合、AppIDが使用されたことを示し、アサーション検証時はrpIdHashがAppIDのハッシュとなることを期待する必要がある。 

partial dictionary AuthenticationExtensionsClientOutputs {
  boolean appid;
};
認証器拡張入力

なし。

認証器拡張処理

なし。

認証器拡張出力

なし。

10.2. FIDO AppID除外拡張（appidExclude）

この登録拡張は、WebAuthn Relying Partyが従来のFIDO U2F JavaScript API[FIDOU2FJavaScriptAPI]で作成された指定認証情報を含む認証器を除外できるようにします。

FIDO U2F JavaScript APIからの移行時、Relying Partyにはすでに従来認証情報が登録済みのユーザーがいる場合があります。appid拡張はサインインフローの移行を円滑にしますが、登録フロー移行時には、excludeCredentialsフィールドが従来認証情報を除外できません（WebAuthn認証情報として扱われるため）。この拡張はクライアントプラットフォームに対し、excludeCredentialsの内容をWebAuthn・従来FIDO認証情報の両方として扱うことを指示します。U2Fキーハンドルは通常base64urlエンコードですが、利用時にはバイナリにデコードしてexcludeCredentialsに使う必要があります。

拡張識別子

appidExclude

適用操作

登録

クライアント拡張入力

FIDO AppIDを指定するUSVString。

partial dictionary AuthenticationExtensionsClientInputs {
  USVString appidExclude;
};
クライアント拡張処理

新しい認証情報を作成時：

  1. RP ID 特定直後に下記手順：

    1. facetIdを呼び出し元のoriginをFIDOの「呼び出しアプリケーションのFacetID決定」アルゴリズムに渡して得る。

    2. appIdを拡張入力値appidExcludeとする。

    3. facetIdとappIdをFIDOの「callerのFacetIDがAppIDに対して認可されているか判定」アルゴリズムに渡す。拒否された場合は"SecurityError" DOMExceptionを返して、新しい認証情報を作成アルゴリズムとこれら手順を終了する。

      注記: 実際には、いくつかの実装は上記アルゴリズムの4ステップ目以降を実装していません。代わりに3ステップ目でホストの比較を同一サイトで許容しています。

    4. それ以外は通常処理継続。

  2. authenticatorMakeCredential呼び出し直前に下記手順：

    1. authenticatorがU2Fプロトコル[FIDO-U2F-Message-Formats]をサポートする場合、excludeCredentialDescriptorListの各Cについて：

      1. CがU2Fでauthenticator上で作成されたかチェックするため、authenticatorにU2F_AUTHENTICATEメッセージを送信、"5つのパート"は次の値：

        制御バイト

        0x07（check-only）

        チャレンジパラメータ

        32バイトランダム

        アプリケーションパラメータ

        appIdのSHA-256ハッシュ

        キーハンドル長

        C.idのバイト長

        キーハンドル

        C.idの値（認証情報ID）

      2. authenticatorがmessage:error:test-of-user-presence-required（成功）を返したら、その認証器の通常処理を停止し、プラットフォーム固有で利用不可を示す（例：UI表示、ユーザー同意要求→受領時はInvalidStateErrorとして扱う）。ユーザー同意は制御バイトを0x03（enforce-user-presence-and-sign）にして再送・応答は無視。

    2. 通常処理継続。

クライアント拡張出力

trueを返し、Relying Partyに拡張が処理されたことを示します。

partial dictionary AuthenticationExtensionsClientOutputs {
  boolean appidExclude;
};
認証器拡張入力

なし。

認証器拡張処理

なし。

認証器拡張出力

なし。

10.3. ユーザー検証方式拡張（uvm）

この拡張はユーザー検証方式の利用を可能にします。

拡張識別子

uvm

適用操作

登録および認証

クライアント拡張入力

この拡張をRelying Partyが要求したことを示すBoolean値true。

partial dictionary AuthenticationExtensionsClientInputs {
  boolean uvm;
};
クライアント拡張処理

特になし（クライアント拡張入力から認証器拡張入力を生成する以外）。

クライアント拡張出力

認証器拡張出力内のファクターをエンコードした数値3要素配列のJSON配列を返します。

typedef sequence<unsigned long> UvmEntry;
typedef sequence<UvmEntry> UvmEntries;

partial dictionary AuthenticationExtensionsClientOutputs {
  UvmEntries uvm;
};
認証器拡張入力

CBOR（メジャータイプ7、値21）でエンコードされたBoolean値true。

    $$extensionInput //= (
      uvm: true,
    )
認証器拡張処理

認証器は認証器拡張出力に、ユーザーが操作承認に用いた方式（複数可）をセットします（下記定義参照）。 この拡張はアテステーションオブジェクトやアサーションに追加可能です。

認証器拡張出力

認証器は1認証インスタンスで最大3種のユーザー検証方式（ファクター）をCBOR構文で報告できます：

    $$extensionOutput //= (
      uvm: [ 1*3 uvmEntry ],
    )

    uvmEntry = [
                   userVerificationMethod: uint .size 4,
                   keyProtectionType: uint .size 2,
                   matcherProtectionType: uint .size 2
               ]

各uvmEntryフィールドの意味：

userVerificationMethod

認証器がユーザー検証に用いた認証方式・ファクター。利用可能な値はFIDO-Registry §3.1参照。

keyProtectionType

FIDO登録秘密鍵材料の保護方式。利用可能な値はFIDO-Registry §3.2参照。

matcherProtectionType

ユーザー検証を行うマッチャーの保護方式。利用可能な値はFIDO-Registry §3.3参照。

認証インスタンスで4以上のファクターが使われる場合、認証器ベンダーはサーバーにとって最も重要と思われる3つをUVMに含める必要があります。

2ファクター利用の多要素認証インスタンスでUVM拡張を含む認証器データの例：

...                    -- RP IDハッシュ（32バイト）
81                     -- UP/EDセット済み
00 00 00 01            -- (初期)署名カウンター
...                    -- 公開鍵alg等
A1                     -- 拡張: CBORマップ1要素
    63                 -- キー1: CBORテキスト文字列3バイト
        75 76 6d       -- "uvm"（UTF-8エンコード）
    82                 -- 値1: 長さ2のCBOR配列（2ファクター利用）
        83              -- 項目1: 長さ3のCBOR配列
            02           -- サブ項目1: 指紋によるユーザー検証方式
            04           -- サブ項目2: Key Protection Type TEE
            02           -- サブ項目3: Matcher Protection Type TEE
        83              -- 項目2: 長さ3のCBOR配列
            04           -- サブ項目1: パスコードによるユーザー検証方式
            01           -- サブ項目2: Key Protection Type Software
            01           -- サブ項目3: Matcher Protection Type Software

10.4. 認証情報プロパティ拡張（credProps）

このクライアント登録拡張は、クライアントが知る特定の認証情報プロパティを、WebAuthn Relying Partyに公開鍵認証情報ソース（public key credential source）作成時に報告できるようにします（登録セレモニーの結果）。

現時点では、1つの認証情報プロパティが定義されています：レジデントキー認証情報プロパティ（すなわちクライアント側発見可能認証情報プロパティ）。

拡張識別子

credProps

適用操作

登録

クライアント拡張入力

この拡張をRelying Partyが要求したことを示すBoolean値true。

partial dictionary AuthenticationExtensionsClientInputs {
    boolean credProps;
};
クライアント拡張処理

認証情報プロパティを出力で報告する以外、特になし。

クライアント拡張出力

Set clientExtensionResults["credProps"]["rk"] をauthenticatorMakeCredential操作の呼び出しに使われたrequireResidentKeyパラメータの値に設定します。 

dictionary CredentialPropertiesOutput {
    boolean rk;
};

partial dictionary AuthenticationExtensionsClientOutputs {
    CredentialPropertiesOutput credProps;
};
rk, 型 boolean

このOPTIONALプロパティ（抽象的にはレジデントキー認証情報プロパティ（すなわちクライアント側発見可能認証情報プロパティ））は、PublicKeyCredentialが登録セレモニーの結果として返された場合に、その認証情報がクライアント側発見可能認証情報かを示すBoolean値です。 rkがtrueなら発見可能認証情報、 rkがfalseならサーバー側認証情報です。 rkが未記載なら、発見可能認証情報かサーバー側認証情報かは不明です。

注記: 一部認証器はクライアントプラットフォームが要求しなくても発見可能認証情報を作成します。そのため、クライアントプラットフォームはrkプロパティを省略せざるを得ない場合があります。Relying PartyはcredProps拡張がサポートされていれば、rkプロパティの設定に努めると考えるべきです。よって、rkが欠落している場合、作成された認証情報は非発見可能認証情報である可能性が高いです。

認証器拡張入力

なし。

認証器拡張処理

なし。

認証器拡張出力

なし。

10.5. 大容量バイナリ保存拡張（largeBlob）

このクライアント登録拡張および認証拡張は、Relying Partyが認証情報に関連付けて不透明データを保存できるようにします。認証器は少量しかデータを保存できず、多くのRelying Partyはオンラインサービスでユーザーごとに任意の量の状態を保持できるため、これは特定用途に限り有用です。例えば、Relying Partyが認証サービスの代わりに証明書を発行したい場合などが考えられます。

注記: Relying Partyは、不透明データが容量制限デバイスに書き込まれる際に圧縮されると想定できるため、事前に圧縮する必要はありません。

証明書システムでは認証情報の公開鍵に署名する必要がありますが、その公開鍵は作成後でないと取得できません。このため、この拡張は登録文脈でバイナリ書き込み機能は追加しません。ただし、Relying Partyが後で認証拡張を使いたい場合は、認証情報作成時に登録拡張の利用を推奨します。

証明書は通常の認証器の保存能力に比べて大きいため、ユーザーエージェントはユーザーがこの限られたリソースを割り当てる際の案内や確認を慎重に設計し、乱用防止も考慮すべきです。

注記: 実際の相互運用のため、[FIDO-CTAP]で規定された方法に従い、認証器上に大容量バイナリを保存する必要があります。

拡張識別子

largeBlob

適用操作

登録および認証

クライアント拡張入力 
partial dictionary AuthenticationExtensionsClientInputs {
    AuthenticationExtensionsLargeBlobInputs largeBlob;
};

enum LargeBlobSupport {
  "required",
  "preferred",
};

dictionary AuthenticationExtensionsLargeBlobInputs {
    DOMString support;
    boolean read;
    BufferSource write;
};
support, 型 DOMString

値はLargeBlobSupportのいずれか。(§ 2.1.1 DOMString型としての列挙型参照) 登録時のみ有効。

read, 型 boolean

この認証情報に関連付けて以前保存したバイナリ（blob）を取得したい場合に設定。認証時のみ有効。

write, 型 BufferSource

この認証情報に関連付けて保存したい不透明バイト列。認証時のみ有効。

クライアント拡張処理（登録）

  1. read またはwrite が指定されている場合：

    1. “NotSupportedError”名のDOMExceptionを返す。

  2. support がrequiredの場合：

    1. supported をtrueにセット。

      注記: 将来的に大容量バイナリ保存対応認証器が利用可能になることを見越しての処理。[[Create]]()のStep 11で発生。満足な認証器が見つからなければAuthenticationExtensionsLargeBlobOutputsは破棄される。

    2. 候補認証器が利用可能になった場合（[[Create]]()のStep 19）、 options評価前に、その認証器が大容量バイナリ保存に非対応ならcontinue（候補認証器を無視）する。

  3. それ以外（support未指定またはpreferredの場合）：

    1. 選択認証器が大容量バイナリ保存対応ならsupportedをtrueに、それ以外ならfalseにセット。

クライアント拡張処理（認証）

  1. support が指定されている場合：

    1. “NotSupportedError”名のDOMExceptionを返す。

  2. read とwrite が両方指定されている場合：

    1. “NotSupportedError”名のDOMExceptionを返す。

  3. read がtrueの場合：

    1. クライアント拡張出力でlargeBlobを初期化。

    2. 認証器が[[DiscoverFromExternalSource]]()で成功を示した場合、認証情報に関連付けられたlargeBlobデータの読み取りを試みる。

    3. 成功した場合、blobにその値をセット。

      注記: 読み取り失敗時はlargeBlobはAuthenticationExtensionsClientOutputsに現れるがblobは未記載。

  4. write が指定されている場合：

    1. allowCredentials が1要素でない場合：

      1. “NotSupportedError”名のDOMExceptionを返す。

    2. アサーション操作が成功した場合、writeの内容を認証器で指定認証情報に保存する。

    3. 成功ならwrittenをtrue、失敗ならfalseにセット。

クライアント拡張出力 
partial dictionary AuthenticationExtensionsClientOutputs {
    AuthenticationExtensionsLargeBlobOutputs largeBlob;
};

dictionary AuthenticationExtensionsLargeBlobOutputs {
    boolean supported;
    ArrayBuffer blob;
    boolean written;
};
supported, 型 boolean

作成された認証情報が大容量バイナリ保存対応ならtrue。登録時のみ。

blob, 型 ArrayBuffer

指定認証情報（rawId）に関連付けられた不透明バイト列。readがtrueの時のみ有効。

written, 型 boolean

writeの内容が認証器で指定認証情報に保存できたかどうか。

認証器拡張処理

本拡張は、ユーザーエージェントが認証器に大容量バイナリの保存・取得処理を行うことを指示します。したがって、Relying Party向けの直接的な認証器処理は規定しません。

11. ユーザーエージェントによる自動化

ユーザーエージェントの自動化やウェブアプリケーションのテストのために、この文書では複数の[WebDriver] 拡張コマンドを定義します。

11.1. WebAuthn WebDriver拡張機能

以下で定義される拡張コマンドの利用可能性を通知するため、新たな拡張機能を定義します。

機能 キー 値型 説明
仮想認証器サポート "webauthn:virtualAuthenticators" boolean エンドポイントノードが全ての仮想認証器コマンドをサポートしているかを示す。

機能検証時、拡張固有のサブステップとして"webauthn:virtualAuthenticators"のvalueを検証する手順は以下の通りです：

  1. valueがbooleanでなければ、WebDriver Error（WebDriver error code invalid argument）を返す。

  2. それ以外の場合、deserializedにvalueをセットする。

機能マッチング時、拡張固有の手順として"webauthn:virtualAuthenticators"のvalueをマッチさせる手順は以下です：

  1. valueがtrueで、エンドポイントノードがいずれかの仮想認証器コマンドをサポートしない場合、マッチは失敗。

  2. それ以外はマッチ成功。

11.1.1. 認証器拡張機能

さらに、本仕様で定義されている各認証器拡張（認証器拡張処理が定義されているもの）についても、拡張機能が定義されます：

機能 キー 値型 説明
ユーザー検証方式拡張サポート "webauthn:extension:uvm" boolean エンドポイントノードのWebAuthn WebDriver実装がユーザー検証方式拡張をサポートしているか示す。
大容量バイナリ保存拡張サポート "webauthn:extension:largeBlob" boolean エンドポイントノードのWebAuthn WebDriver実装がlargeBlob拡張をサポートしているか示す。

機能検証時、拡張固有のサブステップとして認証器拡張機能keyのvalueを検証する手順：

  1. valueがbooleanでなければ、WebDriver Error（WebDriver error code invalid argument）を返す。

  2. それ以外の場合、deserializedにvalueをセットする。

機能マッチング時、拡張固有の手順として認証器拡張機能keyのvalueをマッチさせる手順：

  1. valueがtrueで、WebAuthn WebDriver実装のエンドポイントノードがkeyで示される認証器拡張をサポートしない場合、マッチは失敗。

  2. それ以外はマッチ成功。

定義済み認証器拡張を実装するユーザーエージェントは、対応する認証器拡張機能も実装すべきです。

11.2. 仮想認証器

これらWebDriver拡張コマンドは、仮想認証器（認証器モデルのソフトウェア実装）を作成・操作します。仮想認証器は仮想認証器データベースに格納されます。 格納される各仮想認証器には、以下のプロパティがあります：

authenticatorId

最大48文字のunreserved生成規則（[RFC3986]付録A）から構成される非null文字列。各仮想認証器を一意に識別します。

protocol

この仮想認証器が利用するプロトコル（"ctap1/u2f"、"ctap2"、"ctap2_1"のいずれか）。[FIDO-CTAP]参照。

transport

AuthenticatorTransport のシミュレーション値。transportがinternalの場合はプラットフォームアタッチメントを、それ以外はクロスプラットフォームアタッチメントをシミュレートします。

hasResidentKey

trueの場合、認証器はクライアント側発見可能認証情報をサポート。

hasUserVerification

trueなら認証器はユーザー検証をサポート。

isUserConsenting

全てのユーザー同意認可ジェスチャ、および拡張としてユーザー存在テストの結果を決定します。trueならユーザー同意は常に許可、falseなら許可されません。

isUserVerified

この仮想認証器で行われるユーザー検証の結果を決定します。trueなら常に成功、falseなら失敗。

注記: hasUserVerificationがfalseの場合、このプロパティは効果がありません。

extensions

この仮想認証器がサポートする拡張識別子の文字列配列。

仮想認証器はextensions配列に含まれる全ての認証器拡張をサポートしなければなりません。extensions配列にない認証器拡張はサポートしてはなりません。

uvm

UvmEntries 配列。ユーザー検証方式拡張処理時に認証器拡張出力としてセット。

注記: このプロパティは仮想認証器がユーザー検証方式拡張をサポートしない場合は効果がありません。

11.3. 仮想認証器の追加

仮想認証器の追加WebDriver拡張コマンドは、ソフトウェアの仮想認証器を作成します。定義は以下の通りです：

HTTPメソッド URIテンプレート
POST /session/{session id}/webauthn/authenticator

認証器構成はJSONObjectで、リモートエンドステップにparametersとして渡されます。以下のkeyとvalueペアを含みます：

キー 値型 有効値 デフォルト
protocol string "ctap1/u2f", "ctap2", "ctap2_1" なし
transport string AuthenticatorTransport値 なし
hasResidentKey boolean true, false false
hasUserVerification boolean true, false false
isUserConsenting boolean true, false true
isUserVerified boolean true, false false
extensions string array 拡張識別子の配列 空配列
uvm UvmEntries 最大3件のユーザー検証方式エントリ 空配列

リモートエンドステップは以下の通りです：

  1. parametersがJSONObjectでない場合、WebDriverエラー（WebDriver error code invalid argument）を返す。

    注記: parametersは認証器構成オブジェクトです。

  2. authenticatorを新しい仮想認証器として生成。

  3. parametersの列挙可能な独自プロパティごとに：

    1. keyをプロパティ名とする。

    2. valueをparametersからkey名で取得した値とする。

    3. keyがparametersに一致するkeyを持たない場合、WebDriverエラー（WebDriver error code invalid argument）を返す。

    4. valueがそのkeyの有効値のいずれでもない場合、WebDriverエラー（WebDriver error code invalid argument）を返す。

    5. プロパティkeyをvalueにauthenticator上でセットする。

  4. 認証器構成の各プロパティについて、デフォルト値がある場合：

    1. keyがauthenticatorの定義済みプロパティでない場合、プロパティkeyにdefaultをauthenticatorにセットする。

  5. 認証器構成の各プロパティについて：

    1. keyがauthenticatorの定義済みプロパティでない場合、WebDriverエラー（WebDriver error code invalid argument）を返す。

  6. authenticator.extensionsの各extensionについて：

    1. extensionが拡張識別子であり、エンドポイントノードのWebAuthn WebDriver実装がサポートしていなければ、WebDriverエラー（WebDriver error code unsupported operation）を返す。

  7. 有効な一意のauthenticatorIdを生成。

  8. プロパティauthenticatorIdをauthenticatorIdにauthenticator上でセット。

  9. authenticatorを仮想認証器データベースに格納。

  10. 成功（データはauthenticatorId）を返す。

11.4. 仮想認証器の削除

仮想認証器の削除WebDriver拡張コマンドは、作成済みの仮想認証器を削除します。 定義は以下の通りです：

HTTPメソッド URIテンプレート
DELETE /session/{session id}/webauthn/authenticator/{authenticatorId}

リモートエンドステップは以下：

  1. authenticatorIdが仮想認証器（仮想認証器データベース格納）と一致しない場合、WebDriverエラー（WebDriver error code invalid argument）を返す。

  2. authenticatorIdで識別される仮想認証器を仮想認証器データベースから削除。

  3. 成功を返す。

11.5. 認証情報の追加

認証情報の追加WebDriver 拡張コマンドは、公開鍵認証情報ソースを既存の仮想認証器に注入します。定義は以下の通りです。

HTTPメソッド URIテンプレート
POST /session/{session id}/webauthn/authenticator/{authenticatorId}/credential

認証情報パラメータは、JSONObjectであり、リモートエンドステップにparametersとして渡されます。以下のkeyとvalueペアを含みます：

キー 説明 値型
credentialId 認証情報ID。Base64urlエンコーディングでエンコード。 string
isResidentCredential trueの場合、クライアント側発見可能認証情報を作成。falseの場合はサーバー側認証情報を作成。 boolean
rpId 認証情報がスコープされるRelying Party ID。 string
privateKey 非対称鍵パッケージ（秘密鍵1つ）[RFC5958]形式。Base64urlエンコーディングでエンコード。 string
userHandle 認証情報に関連付けられるuserHandle。Base64urlエンコーディングでエンコード。未定義可。 string
signCount この公開鍵認証情報ソースに関連付ける署名カウンターの初期値。 number
largeBlob 大容量バイナリ（認証情報ごと）。Base64urlエンコーディングでエンコード。未定義可。 string

リモートエンドステップは以下：

  1. parametersがJSONObjectでなければ、WebDriverエラー（WebDriver error code invalid argument）を返す。

    注記: parametersは認証情報パラメータオブジェクトです。

  2. credentialIdにparametersのcredentialIdプロパティをBase64urlエンコード解除した結果を代入。

  3. credentialIdが失敗なら、WebDriverエラー（WebDriver error code invalid argument）を返す。

  4. isResidentCredentialにparametersのisResidentCredentialプロパティを代入。

  5. isResidentCredentialが未定義なら、WebDriverエラー（WebDriver error code invalid argument）を返す。

  6. rpIdにparametersのrpIdプロパティを代入。

  7. rpIdが有効なRP IDでなければ、WebDriverエラー（WebDriver error code invalid argument）を返す。

  8. privateKeyにparametersのprivateKeyプロパティをBase64urlエンコード解除した結果を代入。

  9. privateKeyが失敗なら、WebDriverエラー（WebDriver error code invalid argument）を返す。

  10. privateKeyが有効なP-256楕円曲線ECDSA秘密鍵パッケージ（[RFC5958]）でなければ、WebDriverエラー（WebDriver error code invalid argument）を返す。

  11. parametersのuserHandleプロパティが定義されている場合：

    1. userHandleにparametersのuserHandleプロパティをBase64urlエンコード解除した結果を代入。

    2. userHandleが失敗なら、WebDriverエラー（WebDriver error code invalid argument）を返す。

  12. それ以外：

    1. isResidentCredentialがtrueなら、WebDriverエラー（WebDriver error code invalid argument）を返す。

    2. userHandleにnullを代入。

  13. authenticatorIdが仮想認証器（仮想認証器データベース格納）と一致しなければ、WebDriverエラー（WebDriver error code invalid argument）を返す。

  14. authenticatorにauthenticatorIdで一致する仮想認証器を代入。

  15. isResidentCredentialがtrueかつauthenticatorのhasResidentKeyがfalseなら、WebDriverエラー（WebDriver error code invalid argument）を返す。

  16. authenticatorがlargeBlob拡張をサポートし、parametersのlargeBlobが定義されている場合：

    1. largeBlobにparametersのlargeBlobプロパティをBase64urlエンコード解除した結果を代入。

    2. largeBlobが失敗なら、WebDriverエラー（WebDriver error code invalid argument）を返す。

  17. それ以外：

    1. largeBlobにnullを代入。

  18. credentialに、isResidentCredentialがtrueなら新たなクライアント側発見可能公開鍵認証情報ソース、そうでなければサーバー側公開鍵認証情報ソースを次の値で作成：

    type

    public-key

    id

    credentialId

    privateKey

    privateKey

    rpId

    rpId

    userHandle

    userHandle

  19. credentialに、署名カウンターcounterを関連付ける。初期値はparametersのsignCountまたは0（signCountがnullの場合）。

  20. largeBlobがnullでなければ、credentialに関連付けられた大容量バイナリをlargeBlobにセット。

  21. credentialとcounterをauthenticatorのデータベースに格納する。

  22. 成功を返す。

11.6. 認証情報の取得

認証情報の取得WebDriver拡張コマンドは、仮想認証器に保存されているすべての公開鍵認証情報ソースについて、1つの認証情報パラメータオブジェクトを返します。これは認証情報の追加やnavigator.credentials.create()で保存された場合も含みます。定義は以下の通りです：

HTTPメソッド URIテンプレート
GET /session/{session id}/webauthn/authenticator/{authenticatorId}/credentials

リモートエンドステップは以下：

  1. authenticatorIdが仮想認証器（仮想認証器データベース格納）と一致しなければ、WebDriverエラー（WebDriver error code invalid argument）を返す。

  2. credentialsArrayを空配列として用意。

  3. authenticatorIdで識別される認証器が管理する各公開鍵認証情報ソースcredentialについて、対応する認証情報パラメータオブジェクトを作成し、credentialsArrayに追加。

  4. 成功（データはcredentialsArray）を返す。

11.7. 認証情報の削除

認証情報の削除WebDriver拡張コマンドは、仮想認証器に保存されている公開鍵認証情報ソースを削除します。定義は以下の通りです：

HTTPメソッド URIテンプレート
DELETE /session/{session id}/webauthn/authenticator/{authenticatorId}/credentials/{credentialId}

リモートエンドステップは以下：

  1. authenticatorIdが仮想認証器（仮想認証器データベース格納）と一致しなければ、WebDriverエラー（WebDriver error code invalid argument）を返す。

  2. authenticatorにauthenticatorIdで識別される仮想認証器を代入。

  3. credentialIdがauthenticatorが管理する公開鍵認証情報ソースと一致しなければ、WebDriverエラー（WebDriver error code invalid argument）を返す。

  4. authenticatorが管理するcredentialIdで識別される公開鍵認証情報ソースを削除。

  5. 成功を返す。

11.8. 全認証情報の削除

全認証情報の削除WebDriver拡張コマンドは、仮想認証器に保存されたすべての公開鍵認証情報ソースを削除します。定義は以下の通りです：

HTTPメソッド URIテンプレート
DELETE /session/{session id}/webauthn/authenticator/{authenticatorId}/credentials

リモートエンドステップは以下：

  1. authenticatorIdが仮想認証器（仮想認証器データベース格納）と一致しなければ、WebDriverエラー（WebDriver error code invalid argument）を返す。

  2. authenticatorIdで識別される仮想認証器が管理するすべての公開鍵認証情報ソースを削除。

  3. 成功を返す。

11.9. ユーザー検証状態の設定

ユーザー検証状態の設定拡張コマンドは、仮想認証器のisUserVerifiedプロパティを設定します。定義は以下の通りです：

HTTPメソッド URIテンプレート
POST /session/{session id}/webauthn/authenticator/{authenticatorId}/uv

リモートエンドステップは以下：

  1. parametersがJSONObjectでなければ、WebDriverエラー（WebDriver error code invalid argument）を返す。

  2. authenticatorIdが仮想認証器（仮想認証器データベース格納）と一致しなければ、WebDriverエラー（WebDriver error code invalid argument）を返す。

  3. isUserVerifiedがparametersの定義済みプロパティでなければ、WebDriverエラー（WebDriver error code invalid argument）を返す。

  4. authenticatorにauthenticatorIdで識別される仮想認証器を代入。

  5. authenticatorのisUserVerifiedプロパティにparametersのisUserVerifiedプロパティの値をセット。

  6. 成功を返す。

12. IANA関連事項

12.1. WebAuthnアテステーション文フォーマット識別子登録更新

本節は、IANA "WebAuthn Attestation Statement Format Identifiers"レジストリ[IANA-WebAuthn-Registries]（[RFC8809]）に登録されている、§ 8 定義済みアテステーション文フォーマットで定義された下記アテステーション文フォーマットを、本仕様への参照に更新します。これらは[WebAuthn-1]で最初に登録されたものです。

12.2. WebAuthnアテステーション文フォーマット識別子登録

本節では、IANA "WebAuthn Attestation Statement Format Identifiers"レジストリ[IANA-WebAuthn-Registries]（[RFC8809]）に新規登録される、§ 8 定義済みアテステーション文フォーマットで新たに定義された下記フォーマットを登録します。

12.3. WebAuthn拡張識別子登録更新

本節では、IANA "WebAuthn Extension Identifiers"レジストリ[IANA-WebAuthn-Registries]（[RFC8809]）に登録されている、§ 10 定義済み拡張で定義された下記拡張識別子値を、本仕様への参照に更新します。これらは[WebAuthn-1]で最初に登録されたものです。

12.4. WebAuthn拡張識別子登録

本節では、IANA "WebAuthn Extension Identifiers"レジストリ[IANA-WebAuthn-Registries]（[RFC8809]）に新規登録される、§ 10 定義済み拡張で新たに定義された下記拡張識別子値を登録します。

13. セキュリティに関する考慮事項

本仕様はWeb APIと暗号的なピアエンティティ認証プロトコルを定義します。 Web認証APIは、Web開発者（すなわち"著者"）が、 登録および認証のセレモニーでWeb認証プロトコルを利用できるようにします。 Web認証プロトコルのエンドポイントとなるエンティティは、ユーザーが管理するWebAuthn認証器と WebAuthn Relying Partyの Relying Partyのウェブアプリケーションをホストする計算環境です。 このモデルでは、ユーザーエージェントとWebAuthnクライアントが 認証器とRelying Partyの仲介者となります。 また、認証器はアテステーションを通じて自身の出所をRelying Partyに証明できます。

現時点で本仕様には詳細なセキュリティ考慮事項はありませんが、[FIDOSecRef]文書が本仕様にも適用可能なセキュリティ分析を提供しています。 また、[FIDOAuthnrSecReqs]文書群は認証器のセキュリティ特性に関する有益な情報も提供します。

以下のサブセクションは、現時点のWeb認証固有のセキュリティ考慮事項です。 対象者ごとに分けられています； 一般的な考慮事項は本節の直下に記載し、 認証器、クライアント、Relying Partyの実装者向けはそれぞれのサブセクションにまとめています。

13.1. 認証情報IDは署名されない

認証情報IDは署名されません。 これは問題になりません。なぜなら、認証器が誤った認証情報IDを返した場合や、 攻撃者が認証情報IDを改ざんした場合でも、 WebAuthn Relying Partyは 正しい認証情報公開鍵で署名済み認証器データ （すなわちアサーション）を検証できなくなり、やり取りはエラーとなるからです。

13.2. クライアントと認証器の物理的近接性

WebAuthnの認証器モデルでは、通常ローミング認証器はクライアントの近くに物理的に存在し、直接通信することが想定されています。 この構成には重要な利点があります。

クライアントと認証器の物理的近接性は、持っているもの認証要素の大きな強みです。 例えば、ローミング認証器がUSBやBluetoothのみで通信する場合、 これらの通信範囲の制限により、悪意ある第三者は認証器とやり取りするために物理的にその範囲内にいる必要があります。 これは、リモートで呼び出せる認証器には必ずしも当てはまりません—— たとえ認証器がユーザーの存在を確認しても、 ユーザーがリモート発信の悪意あるリクエストに騙されて認可する可能性があります。

クライアントと認証器が直接通信できる場合、クライアントはスコープ制限を認証情報に対して強制できます。 一方、クライアントと認証器の通信が第三者によって仲介される場合、 クライアントはその第三者がスコープ制限の強制と認証器へのアクセス制御を担うことを信頼しなければなりません。 いずれかが不十分だと、悪意あるRelying Partyが他のRelying Party用の認証アサーションを受け取ったり、悪意あるユーザーが他人の認証アサーションを取得したりする恐れがあります。

認証器がクライアントと物理的に近接する必要がない設計や、クライアントと認証器が直接通信しない設計を考える場合は、 スコープ制限の強制方法と認証器の認証要素としての強度にどう影響するかを十分に検討すべきです。

13.3. 認証器に関するセキュリティ考慮事項

13.3.1. アテステーション証明書の階層構造

アテステーション証明書には3階層（アテステーションルート、発行CA、アテステーション証明書）が推奨されます。各WebAuthn認証器デバイス系（モデル）ごとに個別の発行CAを使うことで、特定バージョンの認証器モデルに関する問題の切り分けが容易になります。

アテステーションルート証明書が単一のWebAuthn認証器デバイス系（AAGUID）専用でない場合は、 AAGUIDを証明書自体に明記し、認証器データと照合できるようにすべきです。

13.3.2. アテステーション証明書・CAの漏洩時の対応

アテステーション証明書を発行した中間CAやルートCAが漏洩した場合でも、WebAuthn認証器のアテステーション鍵ペア自体は安全ですが、証明書は信頼できなくなります。認証器の製造者が自身のアテステーション公開鍵を記録していれば、新しい中間CAやルートCAから新規証明書を発行できます。ルートCAが変わる場合は、WebAuthn Relying Partyは信頼するルート証明書を更新する必要があります。

アテステーション証明書の秘密鍵が漏洩した場合は、発行CAによる証明書の失効が必須です。 製造者はファームウェアアップデート等で新しい秘密鍵・証明書を既存認証器に注入する必要がある場合があります（具体的手順は本仕様の範囲外）。 もしその機能がなければ、Relying Partyは、該当認証器からの以降のアテステーション文を信頼できなくなる場合があります。

関連するRelying Party向けの考慮事項は§ 13.4.5 失効済みアテステーション証明書も参照してください。

13.4. Relying Partyに関するセキュリティ考慮事項

13.4.1. WebAuthn Relying Partyのセキュリティ上の利点

本仕様がWebAuthn Relying Partyにもたらす主な利点は以下の通りです：

  1. ユーザーとアカウントを広範な互換性を持つ使いやすい多要素認証で保護できる。

  2. Relying Partyはユーザーに認証器ハードウェアを配布する必要はありません。各ユーザーは任意の準拠認証器を自分で取得でき、同じ認証器を複数のRelying Partyで利用できます。 また、Relying Partyは認証器のセキュリティ特性要件を、 アテステーション文で検査し強制することも可能です。

  3. 認証セレモニーは中間者攻撃に耐性があります。 登録セレモニーについては、下記§ 13.4.4 アテステーションの限界参照。

  4. Relying Partyは、PIN、生体認証、将来の方式など複数種類のユーザー検証をほぼコード変更無しで自動的にサポートでき、各ユーザーが利用認証器の選択によって好みの方法を選べる。

  5. Relying Partyは上記利点を得るために追加の秘密情報を保存する必要がない。

適合性節で述べた通り、Relying Partyは§ 7 WebAuthn Relying Partyの操作通りに動作することで上記セキュリティ上の利点を享受できます。ただし、下記§ 13.4.4 アテステーションの限界のユースケースでは若干異なる点があります。

13.4.2. 埋め込み利用時のUI可視性に関する考慮事項

WebAuthnを埋め込み文脈で単純に使う（例：§ 5.10 iframe要素内でのWeb認証利用記載の iframeなど）は、 UIリドレッシング攻撃（別名「クリックジャッキング」）の脆弱性となる場合があります。これは攻撃者が自身のUIをRelying PartyのUI上に重ね表示し、ユーザーに意図しない操作をさせようとするものです。たとえば、攻撃者がこの技術でユーザーに誤って購入や送金などをさせる危険もあります。

WebAuthn固有のUIは通常クライアントプラットフォームが処理するためUIリドレッシングの脆弱性はありませんが、WebAuthnを埋め込んだRelying Partyは自分のUIがユーザーに見えていることを保証することが重要となる場合があります。新たな手法として、実験的なIntersection Observer v2のisVisible属性の状態を監視する方法があります。例えば、埋め込み文脈で動作するRelying Partyのスクリプトは、isVisibleがfalseになったことを検知したら、事前に自分自身をポップアップウィンドウでロードすることでUIの隠蔽を回避できます。

13.4.3. 暗号チャレンジに関する考慮事項

暗号プロトコルとして、Web認証はリプレイ攻撃防止のためランダム化チャレンジに依存します。そのため、 PublicKeyCredentialCreationOptions.challenge およびPublicKeyCredentialRequestOptions.challenge の値は、Relying Partyが信頼できる環境（例：サーバー側）でランダム生成し、 クライアントのレスポンスで返されたchallenge 値と一致する必要があります。これはクライアントの挙動に依存せずに実施すべきであり、例えばRelying Partyは一時的にチャレンジを保存し、操作が完了するまで保持するべきです。不一致を許容するとプロトコルの安全性が損なわれます。

リプレイ攻撃防止のため、チャレンジは推測困難なだけのエントロピーを持つ必要があります。チャレンジは16バイト以上を推奨します。

13.4.4. アテステーションの限界

このセクションは規範的ではありません。

新しい認証情報を登録する際、アテステーション文が存在する場合、 WebAuthn Relying Partyが認証器の様々な特性（例：認証器モデルや認証情報秘密鍵の保存・保護方法）についての保証を得られる場合があります。 ただし、アテステーション文自体だけでは、 Relying Partyが アテステーションオブジェクトが ユーザーが意図した認証器で生成されたか、 中間者攻撃者によるものではないかを確認できません。 例えば、攻撃者がRelying Partyのスクリプトに悪意あるコードを注入する可能性もあります。 そのため、Relying PartyはTLS等の技術を用いて アテステーションオブジェクトを 中間者攻撃から保護する必要があります。

登録セレモニーが安全に完了し、認証器が認証情報秘密鍵の機密性を維持している場合、 その後の認証セレモニーは 公開鍵認証情報を用いることで 中間者攻撃に耐性を持ちます。

上記の議論はすべてのアテステーション型に当てはまります。 いずれの場合でも、中間者攻撃者が PublicKeyCredential オブジェクト（アテステーション文や認証情報公開鍵を含む）を置換し、 以後同じRelying Party・同じ攻撃者経由でスコープされた認証アサーションを改ざんすることが可能です。

この攻撃は検知可能な場合があります。 なぜなら、Relying Partyは 攻撃者の認証情報公開鍵を登録してしまい、 以降の全ての認証セレモニーで 攻撃者による改ざんがなければ失敗し、攻撃が露呈する可能性があるからです。

自己アテステーションやNone以外のアテステーション型はこのような攻撃の難易度を上げます。 これは、Relying Partyが認証器情報（モデル名等）をユーザーに表示できるためです。 攻撃者はユーザーの認証器と同じモデルの本物の認証器を使う必要があったり、 ユーザーがRelying Partyの報告する認証器モデルが違うことに気づく可能性もあります。

注記: 上記の中間者攻撃のいずれのバリエーションも、 従来のパスワード認証に対する中間者攻撃よりも攻撃者にとっては困難です。

13.4.5. 失効済みアテステーション証明書

アテステーション証明書の検証が 中間アテステーションCA証明書の失効により失敗し、Relying Partyのポリシーが そのような場合の登録・認証リクエスト拒否を要求する場合、Relying Partyは CA漏洩日以降に同一中間CAにチェーンされたアテステーション証明書で登録された 公開鍵認証情報も 登録解除（または「自己アテステーション」と同等の信頼レベルに）することが推奨されます。 このため、Relying Partyは 登録時に中間アテステーションCA証明書を記録し、失効後の登録情報を解除できるようにすべきです。

関連する認証器側の考慮事項は§ 13.3.2 アテステーション証明書・CAの漏洩時の対応も参照してください。

13.4.6. 認証情報の喪失と鍵の移動性

本仕様は認証情報秘密鍵のバックアップや複数認証器間での共有プロトコルを規定しません。 通常、認証情報秘密鍵は作成した認証器から決して出ません。 認証器を紛失した場合、一般的にはその認証器にバインドされた全ての認証情報も失われ、 1つしか登録していない場合はアカウントにアクセスできなくなる可能性があります。 Web認証APIでは秘密鍵のバックアップや共有の代わりに、同じユーザーに複数の認証情報を登録可能としています。 例えばユーザーは普段使うクライアントデバイスにプラットフォーム認証情報を、 予備や新規・稀なデバイス用にローミング認証情報を登録できます。

Relying Partyは、 同一アカウントに複数の認証情報の登録を許容・推奨すべきです。 また、excludeCredentials と user.id オプションを活用し、異なる認証情報が異なる認証器にバインドされるようにすべきです。

13.4.7. 保護されていないアカウントの検出

このセクションは規範的ではありません。

このセキュリティ考慮事項は、 認証セレモニーを 非空のallowCredentials 引数で初回認証ステップとしてサポートするRelying Partyに適用されます。 例えば、サーバー側認証情報を使った認証を初回ステップにする場合です。

この場合、allowCredentials 引数により、どのユーザーアカウントがWebAuthn認証情報を登録済みか、 そうでないかの情報が漏洩しうるため、アカウント保護強度のシグナルとなる場合があります。 例えば、攻撃者がユーザー名だけで認証セレモニーを開始でき、 Relying Partyが一部ユーザーには非空allowCredentials を返し、他のユーザーには失敗やパスワードチャレンジを返す場合、 攻撃者は後者のユーザーアカウントがWebAuthnアサーション不要と推測し、攻撃を弱いアカウントに集中できます。

この問題は、§ 14.6.2 ユーザー名列挙および§ 14.6.3 認証情報IDによるプライバシー漏洩で説明されている問題と類似しており、同様の対策で緩和できます。

14. プライバシーに関する考慮事項

[FIDO-Privacy-Principles]のプライバシー原則は本仕様にも適用されます。

本セクションは対象者ごとに分けています。 一般的なプライバシー考慮事項は本セクションの直下に、 認証器・クライアント・Relying Partyの実装者向けはそれぞれのサブセクションにまとめています。

14.1. 匿名性解除防止策

このセクションは規範的ではありません。

Web認証APIの設計には多くのプライバシーへの配慮が盛り込まれています。主な懸念は、ユーザーの個人識別（つまり人間の識別や異なるIDが同一人物であることの関連付け）の保護です。Web認証API自体はグローバルIDを利用・提供しませんが、以下のような潜在的に関連付け可能な識別子が使われます：

上記情報の一部は必ずRelying Partyと共有されます。以降のセクションでは悪意あるRelying Partyがユーザーの個人識別を特定するのを防ぐための措置を説明します。

14.2. 匿名・スコープ済み・非相関の公開鍵認証情報

このセクションは規範的ではありません。

認証情報IDや認証情報公開鍵は強力な認証のために必ずWebAuthn Relying Partyに共有されますが、ユーザーの識別性を最小化するよう設計されており、Relying Party間で共有されません。

さらに、クライアント側発見可能公開鍵認証情報ソースにはuser handle（Relying Party指定）が含まれる場合があります。これにより、認証情報がユーザーの識別と認証両方に使え、プライバシー重視のRelying Partyは伝統的なユーザー名なしでアカウント作成を許可できます。これによりRelying Party間の非相関性がさらに高まります。

14.3. 認証器ローカルの生体認証

生体認証器は生体認証を認証器内部で処理します（ただしプラットフォーム認証器の場合は実装によってはクライアントにも見える場合あり）。生体データはWebAuthn Relying Partyに公開されず、ローカルでユーザー検証のためだけに使われ、登録や認証時の公開鍵認証情報作成・利用の認可に使われます。悪意あるRelying Partyは生体データでユーザーを特定できず、Relying Partyのセキュリティ侵害でも他のRelying Partyへの偽装ログインに生体データを使われません。

Relying Partyが生体認証を要求する場合、ローカルの生体認証器がユーザー検証を行い、その結果を署名済みアサーションレスポンスのUVフラグで通知し、生体データ自体はRelying Partyに公開されません。

14.4. 認証器に関するプライバシー考慮事項

14.4.1. アテステーションのプライバシー

アテステーション証明書やアテステーション鍵ペアはユーザー追跡や複数オンラインIDの関連付けに使われる場合があります。 これを緩和する方法例：

14.4.2. 認証器に保存される個人識別情報のプライバシー

認証器は、本仕様で定義される情報以外にも、クライアントに追加情報を提供できる場合があります（例：認証セレモニーでどの認証情報を使うか選択できるリッチUI）。この場合、成功したユーザー検証を経ない限り個人識別情報を公開すべきではありません。また、複数ユーザー同時登録に対応する認証器は、現在検証済みユーザー以外の個人識別情報を公開すべきではありません。ユーザー検証非対応の認証器は個人識別情報を保存すべきではありません。

ここでいうuser handle（id）は個人識別情報とはみなされません（詳細は§ 14.6.1 User Handle Contents参照）。

これらの推奨は、認証器への物理アクセスを得た攻撃者が登録ユーザーの個人識別情報を抽出するのを防ぐためのものです。

14.5. クライアントに関するプライバシー考慮事項

14.5.1. 登録セレモニーのプライバシー

ユーザーが同意しない限り識別されないよう、[[Create]](origin, options, sameOriginWithAncestors) 実装は、悪意あるWebAuthn Relying Partyが以下のケース（excluded：Relying Party指定のexcludeCredentialsに含まれる認証情報が認証器にバインド済み）を識別できないよう漏洩防止に注意が必要です：

上記ケースを区別できると、悪意あるRelying Partyがどの認証情報が利用可能か探ってユーザー識別できてしまいます。例えば、excludedな認証器が利用可能になった瞬間にクライアントが即失敗を返すと、特にexcludedがプラットフォーム認証器の場合、Relying Partyはタイムアウト前やユーザーによる手動キャンセル前にセレモニーが終了したことを検出し、excludeCredentialsパラメータ内の認証情報が少なくとも1つ利用可能と推測できます。

ただし、ユーザーが区別可能なエラー返却前に新規認証情報作成に同意していれば、漏洩してもユーザーは意図して情報共有したことになるため問題ありません。

14.5.2. 認証セレモニーのプライバシー

ユーザーが同意しない限り識別されないよう、[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 実装は、悪意あるWebAuthn Relying Partyが以下のケース（named：Relying Party指定のallowCredentials内の認証情報）の区別ができないよう漏洩防止に注意が必要です：

上記ケースを区別できると、悪意あるRelying Partyがどの認証情報が利用可能か探ってユーザー識別できてしまいます。例えば、ユーザーが同意を拒否した瞬間にクライアントが失敗を返すと、Relying Partyはユーザー自身によるキャンセルかタイムアウトかを区別でき、allowCredentialsパラメータ内の認証情報が少なくとも1つ利用可能と推測できます。

14.5.3. OSアカウント間のプライバシー

プラットフォーム認証器が複数ユーザーOSのクライアントデバイスに搭載されている場合、プラットフォーム認証器とデバイスは、そのプラットフォーム認証情報の存在が作成したOSユーザー以外に漏れないよう協調すべきです。

14.6. Relying Partyに関するプライバシー考慮事項

14.6.1. user handleの内容

user handleは§ 14.4.2 認証器に保存される個人識別情報のプライバシーで個人識別情報とはみなされないため、Relying Partyはメールアドレスやユーザー名等の個人識別情報をuser handleに含めてはなりません（ハッシュ値も不可、ただしハッシュがRelying Party固有のsaltでソルトされていれば除く。ハッシュだけでは推測される入力値の探索を防げません）。user handleは64バイトのランダム値とし、ユーザーアカウントに保存することを推奨します。

14.6.2. ユーザー名列挙

登録や認証セレモニー開始時、WebAuthn Relying Partyが登録ユーザーに関する機微な情報を漏洩するリスクがあります。例えば、Relying Partyがメールアドレスをユーザー名とし、攻撃者が"alex.mueller@example.com"で認証セレモニー開始して失敗し、"j.doe@example.com"では成功した場合、攻撃者は"j.doe@example.com"がこのRelying Partyに登録されていることを知ることになります。

以下は、このような攻撃による情報漏洩を緩和・防止するためにRelying Partyが実施できる非規範的・非網羅的な対策例です：

14.6.3. 認証情報IDによるプライバシー漏洩

このセクションは規範的ではありません。

このプライバシー考慮事項は、 非空のallowCredentials 引数で初回認証ステップを行うRelying Party（例：サーバー側認証情報を初回認証ステップで使う場合）に適用されます。

この場合、allowCredentials 引数により、ユーザーの認証情報IDが認証前の相手に漏洩するリスクがあります。認証情報IDはRelying Party間で相関できないよう設計されていますが、 認証情報IDの長さなどから、どの種類の認証器が生成したか推測される場合があります。 また、ユーザーが複数のRelying Partyで同じユーザー名や認証器を使う場合、 allowCredentials内の認証情報ID数や長さが、ユーザー匿名性を解除するグローバルな相関手掛かりとなる恐れがあります。 一時的に物理アクセスできれば、認証情報IDを知ることでユーザー識別の推測が可能になる場合もあります。

このような情報漏洩を防ぐため、Relying Partyは例えば以下の対策を取ることができます：

上記防止策が取れない場合（ユーザー名だけでallowCredentialsを公開する必要がある場合）、 Relying Partyは § 14.6.2 ユーザー名列挙で述べたように、 ダミーの認証情報IDを返すことでプライバシー漏洩を緩和できます。

15. アクセシビリティに関する考慮事項

ユーザー検証対応の認証器（ローミング・プラットフォームどちらも）は、複数のユーザー検証方式（例：指紋・PIN入力など）をユーザーに提供すべきです。選択した方式が使えない場合に代替手段として他方式に切り替え可能だからです。ローミング認証器の場合、認証器とプラットフォームが連携してPIN入力等のユーザー検証手段を提供する場合もあります [FIDO-CTAP]。

Relying Partyは登録時、今後の認可ジェスチャを正しく完了できるよう支援すべきです。例えば、認証器に名前を付ける、画像やメモを関連付ける等が考えられます。

セレモニーでタイミング依存（例：登録セレモニーのtimeoutや、認証セレモニーのtimeout）がある場合、[WCAG21]のガイドライン2.2 十分な時間に従うべきです。クライアントプラットフォームがRelying Party指定のタイムアウトが上記ガイドラインに適合しないと判定した場合、タイムアウトを適切に調整しても構いません。

16. 謝辞

この仕様のレビューや貢献に感謝します: Yuriy Ackermann, James Barclay, Richard Barnes, Dominic Battré, Julien Cayzac, Domenic Denicola, Rahul Ghosh, Brad Hill, Jing Jin, Wally Jones, Ian Kilpatrick, Axel Nennker, Yoshikazu Nojima, Kimberly Paulhamus, Adam Powers, Yaron Sheffer, Ki-Eun Shin, Anne van Kesteren, Johan Verrept, そして Boris Zbarsky.

認証・登録フロー図（Figure 1およびFigure 2）の作成にAdam Powers氏へ感謝します。

Anthony Nadalin, John Fontana, Richard Barnes 各氏にはWeb Authentication Working Group共同議長としての貢献に感謝します。

Wendy Seltzer, Samuel Weiler, Harry Halpin 各氏にはW3Cチームコンタクトとしての貢献に感謝します。

索引

本仕様で定義されている用語

参照で定義される用語

参考文献

規範的参考文献

[BCP47]
A. Phillips; M. Davis. 言語識別タグ。2009年9月。IETF Best Current Practice。URL: https://tools.ietf.org/html/bcp47
[CREDENTIAL-MANAGEMENT-1]
Mike West. Credential Management Level 1。2019年1月17日。WD。URL: https://www.w3.org/TR/credential-management-1/
[DOM4]
Anne van Kesteren. DOM現行標準。URL: https://dom.spec.whatwg.org/
[ECMAScript]
ECMAScript言語仕様。URL: https://tc39.es/ecma262/
[ENCODING]
Anne van Kesteren. Encoding現行標準。URL: https://encoding.spec.whatwg.org/
[FETCH]
Anne van Kesteren. Fetch現行標準。URL: https://fetch.spec.whatwg.org/
[FIDO-APPID]
D. Balfanz; 他。FIDO AppIDとファセット仕様。2018年2月27日。FIDO Alliance Implementation Draft。URL: https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-appid-and-facets-v2.0-id-20180227.html
[FIDO-CTAP]
M. Antoine; 他。Client to Authenticator Protocol。2018年2月27日。FIDO Alliance Implementation Draft。URL: https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html
[FIDO-Privacy-Principles]
FIDO Alliance。FIDO プライバシー原則。FIDO Alliance Whitepaper。URL: https://fidoalliance.org/wp-content/uploads/2014/12/FIDO_Alliance_Whitepaper_Privacy_Principles.pdf
[FIDO-Registry]
R. Lindemann; D. Baghdasaryan; B. Hill。FIDO 事前定義値レジストリ。2018年2月27日。FIDO Alliance Implementation Draft。URL: https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-registry-v2.0-id-20180227.html
[FIDO-U2F-Message-Formats]
D. Balfanz; J. Ehrensvard; J. Lang。FIDO U2F Raw Message Formats。FIDO Alliance Implementation Draft。URL: https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-raw-message-formats-v1.1-id-20160915.html
[FileAPI]
Marijn Kruisselbrink; Arun Ranganathan。File API。2019年9月11日。WD。URL: https://www.w3.org/TR/FileAPI/
[HTML]
Anne van Kesteren; 他。HTML現行標準。URL: https://html.spec.whatwg.org/multipage/
[IANA-COSE-ALGS-REG]
IANA CBORオブジェクト署名・暗号(COSE)アルゴリズムレジストリ。URL: https://www.iana.org/assignments/cose/cose.xhtml#algorithms
[IANA-WebAuthn-Registries]
IANA。Web認証(WebAuthn)レジストリ。URL: https://www.iana.org/assignments/webauthn/
[INFRA]
Anne van Kesteren; Domenic Denicola。Infra現行標準。URL: https://infra.spec.whatwg.org/
[PAGE-VISIBILITY]
Jatinder Mann; Arvind Jain。Page Visibility (第2版)。2013年10月29日。REC。URL: https://www.w3.org/TR/page-visibility/
[Permissions-Policy]
Ian Clelland。Permissions Policy。2020年7月16日。WD。URL: https://www.w3.org/TR/permissions-policy-1/
[RFC2119]
S. Bradner。RFCで要求レベルを示すキーワード。1997年3月。Best Current Practice。URL: https://tools.ietf.org/html/rfc2119
[RFC3986]
T. Berners-Lee; R. Fielding; L. Masinter。URI: 一般構文。2005年1月。Internet Standard。URL: https://tools.ietf.org/html/rfc3986
[RFC4648]
S. Josefsson。Base16, Base32, Base64データエンコーディング。2006年10月。Proposed Standard。URL: https://tools.ietf.org/html/rfc4648
[RFC4949]
R. Shirey。インターネットセキュリティ用語集 第2版。2007年8月。Informational。URL: https://tools.ietf.org/html/rfc4949
[RFC5234]
D. Crocker, Ed.; P. Overell。構文仕様用拡張BNF: ABNF。2008年1月。Internet Standard。URL: https://tools.ietf.org/html/rfc5234
[RFC5280]
D. Cooper; 他。X.509公開鍵証明書・失効リスト(CRL)プロファイル。2008年5月。Proposed Standard。URL: https://tools.ietf.org/html/rfc5280
[RFC5890]
J. Klensin。国際化ドメイン名(IDNA): 定義と文書構成。2010年8月。Proposed Standard。URL: https://tools.ietf.org/html/rfc5890
[RFC6454]
A. Barth。Webオリジン概念。2011年12月。Proposed Standard。URL: https://tools.ietf.org/html/rfc6454
[RFC7515]
M. Jones; J. Bradley; N. Sakimura。JSON Web Signature (JWS)。2015年5月。Proposed Standard。URL: https://tools.ietf.org/html/rfc7515
[RFC8152]
J. Schaad。CBORオブジェクト署名・暗号(COSE)。2017年7月。Proposed Standard。URL: https://tools.ietf.org/html/rfc8152
[RFC8230]
M. Jones。RSAアルゴリズムのCOSEメッセージへの利用。2017年9月。Proposed Standard。URL: https://tools.ietf.org/html/rfc8230
[RFC8264]
P. Saint-Andre; M. Blanchet。PRECISフレームワーク: 国際化文字列の準備・適用・比較。2017年10月。Proposed Standard。URL: https://tools.ietf.org/html/rfc8264
[RFC8265]
P. Saint-Andre; A. Melnikov。ユーザー名・パスワードの国際化文字列の準備・適用・比較。2017年10月。Proposed Standard。URL: https://tools.ietf.org/html/rfc8265
[RFC8266]
P. Saint-Andre。ニックネームの国際化文字列の準備・適用・比較。2017年10月。Proposed Standard。URL: https://tools.ietf.org/html/rfc8266
[RFC8610]
H. Birkholz; C. Vigano; C. Bormann。CDDL: CBOR・JSONデータ構造表現記法。2019年6月。IETF Proposed Standard。URL: https://tools.ietf.org/html/rfc8610
[RFC8809]
Jeff Hodges; Giridhar Mandyam; Michael B. Jones。Web認証(WebAuthn)レジストリ。2020年8月。IETF Proposed Standard。URL: https://www.rfc-editor.org/rfc/rfc8809
[RFC8949]
C. Bormann; P. Hoffman。CBOR: Concise Binary Object Representation。2020年12月。Internet Standard。URL: https://tools.ietf.org/html/rfc8949
[SEC1]
SEC1: 楕円曲線暗号(第2版)。URL: http://www.secg.org/sec1-v2.pdf
[SECURE-CONTEXTS]
Mike West。Secure Contexts。2016年9月15日。CR。URL: https://www.w3.org/TR/secure-contexts/
[SP800-800-63r3]
Paul A. Grassi; Michael E. Garcia; James L. Fenton。NIST Special Publication 800-63: デジタルIDガイドライン。2017年6月。URL: https://pages.nist.gov/800-63-3/sp800-63-3.html
[TCG-CMCProfile-AIKCertEnroll]
Scott Kelly; 他。TCG Infrastructure Working Group: AIK証明書登録用CMCプロファイル。2011年3月24日。Published。URL: https://trustedcomputinggroup.org/wp-content/uploads/IWG_CMC_Profile_Cert_Enrollment_v1_r7.pdf
[TokenBinding]
A. Popov; 他。Token Binding Protocol Version 1.0。2018年10月。IETF Proposed Standard。URL: https://tools.ietf.org/html/rfc8471
[TPMv2-EK-Profile]
TCG EK Credential Profile for TPM Family 2.0。URL: https://www.trustedcomputinggroup.org/wp-content/uploads/Credential_Profile_EK_V2.0_R14_published.pdf
[TPMv2-Part1]
Trusted Platform Module Library, Part 1: Architecture。URL: https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.38.pdf
[TPMv2-Part2]
Trusted Platform Module Library, Part 2: Structures。URL: https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-2-Structures-01.38.pdf
[TPMv2-Part3]
Trusted Platform Module Library, Part 3: Commands。URL: https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-3-Commands-01.38.pdf
[URL]
Anne van Kesteren。URL現行標準。URL: https://url.spec.whatwg.org/
[UTR29]
UNICODEテキストセグメンテーション。URL: http://www.unicode.org/reports/tr29/
[WCAG21]
Andrew Kirkpatrick; 他。ウェブコンテンツアクセシビリティガイドライン(WCAG) 2.1。2018年6月5日。REC。URL: https://www.w3.org/TR/WCAG21/
[WebDriver]
Simon Stewart; David Burns。WebDriver。2018年6月5日。REC。URL: https://www.w3.org/TR/webdriver1/
[WebIDL]
Boris Zbarsky。Web IDL。2016年12月15日。ED。URL: https://heycam.github.io/webidl/

参考情報

[Ceremony]
Carl Ellison。Ceremony Design and Analysis。2007年。URL: https://eprint.iacr.org/2007/399.pdf
[CSS-OVERFLOW-3]
David Baron; Elika Etemad; Florian Rivoal。CSS Overflow Module Level 3。2020年6月3日。WD。URL: https://www.w3.org/TR/css-overflow-3/
[EduPersonObjectClassSpec]
EduPerson。継続中。URL: https://refeds.org/eduperson
[FIDO-Transports-Ext]
FIDO Alliance。FIDO U2F認証器トランスポート拡張。FIDO Alliance Proposed Standard。URL: https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-authenticator-transports-extension-v1.2-ps-20170411.html
[FIDO-UAF-AUTHNR-CMDS]
R. Lindemann; J. Kemp。FIDO UAF認証器コマンド。FIDO Alliance Implementation Draft。URL: https://fidoalliance.org/specs/fido-uaf-v1.1-id-20170202/fido-uaf-authnr-cmds-v1.1-id-20170202.html
[FIDOAuthnrSecReqs]
D. Biggs; 他。FIDO 認証器セキュリティ要件。FIDO Alliance Final Documents。URL: https://fidoalliance.org/specs/fido-security-requirements-v1.0-fd-20170524/
[FIDOMetadataService]
R. Lindemann; B. Hill; D. Baghdasaryan。FIDO メタデータサービス。2018年2月27日。FIDO Alliance Implementation Draft。URL: https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-metadata-service-v2.0-id-20180227.html
[FIDOSecRef]
R. Lindemann; 他。FIDO セキュリティリファレンス。2018年2月27日。FIDO Alliance Implementation Draft。URL: https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-security-ref-v2.0-id-20180227.html
[FIDOU2FJavaScriptAPI]
D. Balfanz; A. Birgisson; J. Lang。FIDO U2F JavaScript API。FIDO Alliance Proposed Standard。URL: https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-javascript-api-v1.2-ps-20170411.html
[ISOBiometricVocabulary]
ISO/IEC JTC1/SC37。情報技術 — 用語集 — 生体認証。2012年12月15日。国際標準: ISO/IEC 2382-37:2012(E) 第1版。URL: http://standards.iso.org/ittf/PubliclyAvailableStandards/c055194_ISOIEC_2382-37_2012.zip
[RFC3279]
L. Bassham; W. Polk; R. Housley。X.509公開鍵基盤証明書と失効リスト(CRL)用アルゴリズムと識別子。2002年4月。Proposed Standard。URL: https://tools.ietf.org/html/rfc3279
[RFC5958]
S. Turner。非対称鍵パッケージ。2010年8月。Proposed Standard。URL: https://tools.ietf.org/html/rfc5958
[RFC6265]
A. Barth。HTTPステート管理メカニズム。2011年4月。Proposed Standard。URL: https://httpwg.org/specs/rfc6265.html
[RFC8017]
K. Moriarty, Ed.; 他。PKCS #1: RSA暗号仕様 v2.2。2016年11月。Informational。URL: https://tools.ietf.org/html/rfc8017
[UAFProtocol]
R. Lindemann; 他。FIDO UAFプロトコル仕様 v1.0。FIDO Alliance Proposed Standard。URL: https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-uaf-protocol-v1.0-ps-20141208.html
[WebAuthn-1]
Dirk Balfanz; 他。Web Authentication: 公開鍵認証情報アクセスAPI Level 1。2019年3月4日。REC。URL: https://www.w3.org/TR/webauthn-1/
[WebAuthnAPIGuide]
Web Authentication APIガイド。実験的。URL: https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API

IDL索引

[SecureContext, Exposed=Window]
interface PublicKeyCredential : Credential {
    [SameObject] readonly attribute ArrayBuffer              rawId;
    [SameObject] readonly attribute AuthenticatorResponse    response;
    AuthenticationExtensionsClientOutputs getClientExtensionResults();
};

partial dictionary CredentialCreationOptions {
    PublicKeyCredentialCreationOptions      publicKey;
};

partial dictionary CredentialRequestOptions {
    PublicKeyCredentialRequestOptions      publicKey;
};

partial interface PublicKeyCredential {
    static Promise<boolean> isUserVerifyingPlatformAuthenticatorAvailable();
};

[SecureContext, Exposed=Window]
interface AuthenticatorResponse {
    [SameObject] readonly attribute ArrayBuffer      clientDataJSON;
};

[SecureContext, Exposed=Window]
interface AuthenticatorAttestationResponse : AuthenticatorResponse {
    [SameObject] readonly attribute ArrayBuffer      attestationObject;
    sequence<DOMString>                              getTransports();
    ArrayBuffer                                      getAuthenticatorData();
    ArrayBuffer?                                     getPublicKey();
    COSEAlgorithmIdentifier                          getPublicKeyAlgorithm();
};

[SecureContext, Exposed=Window]
interface AuthenticatorAssertionResponse : AuthenticatorResponse {
    [SameObject] readonly attribute ArrayBuffer      authenticatorData;
    [SameObject] readonly attribute ArrayBuffer      signature;
    [SameObject] readonly attribute ArrayBuffer?     userHandle;
};

dictionary PublicKeyCredentialParameters {
    required DOMString                    type;
    required COSEAlgorithmIdentifier      alg;
};

dictionary PublicKeyCredentialCreationOptions {
    required PublicKeyCredentialRpEntity         rp;
    required PublicKeyCredentialUserEntity       user;

    required BufferSource                             challenge;
    required sequence<PublicKeyCredentialParameters>  pubKeyCredParams;

    unsigned long                                timeout;
    sequence<PublicKeyCredentialDescriptor>      excludeCredentials = [];
    AuthenticatorSelectionCriteria               authenticatorSelection;
    DOMString                                    attestation = "none";
    AuthenticationExtensionsClientInputs         extensions;
};

dictionary PublicKeyCredentialEntity {
    required DOMString    name;
};

dictionary PublicKeyCredentialRpEntity : PublicKeyCredentialEntity {
    DOMString      id;
};

dictionary PublicKeyCredentialUserEntity : PublicKeyCredentialEntity {
    required BufferSource   id;
    required DOMString      displayName;
};

dictionary AuthenticatorSelectionCriteria {
    DOMString                    authenticatorAttachment;
    DOMString                    residentKey;
    boolean                      requireResidentKey = false;
    DOMString                    userVerification = "preferred";
};

enum AuthenticatorAttachment {
    "platform",
    "cross-platform"
};

enum ResidentKeyRequirement {
    "discouraged",
    "preferred",
    "required"
};

enum AttestationConveyancePreference {
    "none",
    "indirect",
    "direct",
    "enterprise"
};

dictionary PublicKeyCredentialRequestOptions {
    required BufferSource                challenge;
    unsigned long                        timeout;
    USVString                            rpId;
    sequence<PublicKeyCredentialDescriptor> allowCredentials = [];
    DOMString                            userVerification = "preferred";
    AuthenticationExtensionsClientInputs extensions;
};

dictionary AuthenticationExtensionsClientInputs {
};

dictionary AuthenticationExtensionsClientOutputs {
};

dictionary CollectedClientData {
    required DOMString           type;
    required DOMString           challenge;
    required DOMString           origin;
    boolean                      crossOrigin;
    TokenBinding                 tokenBinding;
};

dictionary TokenBinding {
    required DOMString status;
    DOMString id;
};

enum TokenBindingStatus { "present", "supported" };

enum PublicKeyCredentialType {
    "public-key"
};

dictionary PublicKeyCredentialDescriptor {
    required DOMString                    type;
    required BufferSource                 id;
    sequence<DOMString>                   transports;
};

enum AuthenticatorTransport {
    "usb",
    "nfc",
    "ble",
    "internal"
};

typedef long COSEAlgorithmIdentifier;

enum UserVerificationRequirement {
    "required",
    "preferred",
    "discouraged"
};

partial dictionary AuthenticationExtensionsClientInputs {
  USVString appid;
};

partial dictionary AuthenticationExtensionsClientOutputs {
  boolean appid;
};

partial dictionary AuthenticationExtensionsClientInputs {
  USVString appidExclude;
};

partial dictionary AuthenticationExtensionsClientOutputs {
  boolean appidExclude;
};

partial dictionary AuthenticationExtensionsClientInputs {
  boolean uvm;
};

typedef sequence<unsigned long> UvmEntry;
typedef sequence<UvmEntry> UvmEntries;

partial dictionary AuthenticationExtensionsClientOutputs {
  UvmEntries uvm;
};

partial dictionary AuthenticationExtensionsClientInputs {
    boolean credProps;
};

dictionary CredentialPropertiesOutput {
    boolean rk;
};

partial dictionary AuthenticationExtensionsClientOutputs {
    CredentialPropertiesOutput credProps;
};

partial dictionary AuthenticationExtensionsClientInputs {
    AuthenticationExtensionsLargeBlobInputs largeBlob;
};

enum LargeBlobSupport {
  "required",
  "preferred",
};

dictionary AuthenticationExtensionsLargeBlobInputs {
    DOMString support;
    boolean read;
    BufferSource write;
};

partial dictionary AuthenticationExtensionsClientOutputs {
    AuthenticationExtensionsLargeBlobOutputs largeBlob;
};

dictionary AuthenticationExtensionsLargeBlobOutputs {
    boolean supported;
    ArrayBuffer blob;
    boolean written;
};

課題索引

WHATWG HTML WGでは、ブラウジングコンテキストがフォーカスを得たり失ったりする際にフックを提供するか議論中です。フックが提供された場合、上記の段落はそのフックを含むように更新されます。 詳細は WHATWG HTML WG Issue #2711 を参照してください。 ↵