Web Authentication: 公開鍵クレデンシャルにアクセスするための API

1. はじめに

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

この仕様は、ユーザーを強力に認証することを目的として、強力で、アテステーション済みの、スコープが設定された、公開鍵ベースのクレデンシャルをWeb アプリケーションが作成および使用できるようにする API を定義します。公開鍵クレデンシャルは、 WebAuthn リライングパーティの要求に応じ、ユーザーの同意を条件として、WebAuthn 認証器によって作成および保存されます。その後、公開鍵クレデンシャルには、そのリライングパーティに属するオリジンのみがアクセスできます。このスコープ設定は、適合ユーザーエージェントと認証器によって共同で強制されます。さらに、リライングパーティ間のプライバシーが維持されます。リライングパーティは、他のリライングパーティにスコープが設定されたクレデンシャルについて、いかなる特性も、さらにはその存在さえも検出できません。

リライングパーティは、ユーザーが関与する、異なるものの関連する 2 つのセレモニーでWeb Authentication APIを使用します。1 つ目は登録であり、ここでは公開鍵クレデンシャルが認証器上に作成され、現在のユーザーのアカウント（アカウントはすでに存在している場合も、この時点で作成される場合もあります）とともにリライングパーティにスコープが設定されます。2 つ目は認証であり、ここではリライングパーティに、公開鍵クレデンシャルを登録したユーザーの存在および同意を証明する認証アサーションが提示されます。機能的には、Web Authentication APIは、Credential Management API [CREDENTIAL-MANAGEMENT-1] を拡張する PublicKeyCredential と、それらのクレデンシャルを navigator.credentials.create() および navigator.credentials.get() とともに使用できるようにする基盤で構成されます。前者は登録中に使用され、後者は認証中に使用されます。

概して、適合する認証器は公開鍵クレデンシャルを保護し、ユーザーエージェントと対話してWeb Authentication APIを実装します。適合する認証器は、 (a) 汎用コンピューティングデバイス上、 (b) デバイス上の Secure Execution Environment、Trusted Platform Module (TPM)、または Secure Element (SE) 上、または (c) デバイス外で実行されるソフトウェアとして実装できます。デバイス上に実装される認証器はプラットフォーム認証器と呼ばれます。デバイス外に実装される認証器（ローミング認証器）には、Universal Serial Bus (USB)、Bluetooth Low Energy (BLE)、Near Field Communications (NFC) などのトランスポートを介してアクセスできます。

1.1. 仕様ロードマップ

多くの W3C 仕様は主としてユーザーエージェント開発者、および Web アプリケーション開発者（すなわち「Web 作者」）を対象としていますが、Web Authentication の性質上、この仕様は以下で説明するように、複数の対象者によって正しく使用される必要があります。

すべての対象者は、§ 1.2 ユースケース、§ 1.3 API 使用シナリオの例、および § 4 用語から読み始めるのが望ましく、全体的なチュートリアルとして [WebAuthnAPIGuide] も参照すべきです。それ以外に、この文書が対象とする主な読者層は次のとおりです。

リライングパーティの Web アプリケーション開発者。特に、リライングパーティのWeb アプリケーションのログインフロー、アカウント復旧フロー、ユーザーアカウントデータベースの内容などを担当する開発者。
Web フレームワーク開発者
- 上記 2 つの対象者は、特に § 7 WebAuthn リライングパーティの操作を参照すべきです。 § 5 Web Authentication API の導入部も役立つ場合がありますが、 § 5 Web Authentication API セクションは Web アプリケーション開発者ではなく、特にユーザーエージェント開発者を対象としていることに注意してください。さらに、認証器のアテステーションを検証する予定であれば、§ 6.5 アテステーションおよび§ 8 定義済みアテステーションステートメント形式も関連します。拡張を利用する場合は、§ 9 WebAuthn 拡張および§ 10 定義済み拡張も重要です。最後に、§ 13.4 リライングパーティに関するセキュリティ上の考慮事項および§ 14.6 リライングパーティに関するプライバシー上の考慮事項を読み、どの課題が自身のアプリケーションおよびユーザーに当てはまるかを検討すべきです。
ユーザーエージェント開発者
OS プラットフォーム開発者。プラットフォーム固有の認証器 API、プラットフォームのWebAuthn クライアントのインスタンス化などに関する OS プラットフォーム API の設計および実装を担当する開発者。
- 上記 2 つの対象者は、拡張をサポートする予定であれば § 9 WebAuthn 拡張とともに、§ 5 Web Authentication APIを非常に注意深く読むべきです。また、§ 14.5 クライアントに関するプライバシー上の考慮事項も注意深く読むべきです。
認証器開発者。これらの読者は、§ 6 WebAuthn 認証器モデル、§ 8 定義済みアテステーションステートメント形式、§ 9 WebAuthn 拡張、および § 10 定義済み拡張に特に注意を払う必要があります。また、§ 13.3 認証器に関するセキュリティ上の考慮事項および§ 14.4 認証器に関するプライバシー上の考慮事項も注意深く読むべきです。

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

各コンポーネント、すなわちリライングパーティサーバー、クライアント、および認証器の役割、ならびに § 13 セキュリティに関する考慮事項および§ 14 プライバシーに関する考慮事項をすべての対象者が理解することは、Web Authentication の展開におけるエンドツーエンドのセキュリティにとって重要です。

1.2. ユースケース

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

1.2.1. 登録

電話の場合:
- ユーザーはブラウザーで example.com に移動し、それまで使用していた任意の方法（パスワードなどのレガシーな方法の場合もあります）を使用して既存のアカウントにサインインするか、新しいアカウントを作成します。
- 電話が「このデバイスを example.com に登録しますか？」と尋ねます。
- ユーザーが同意します。
- 電話は、事前に設定された認可ジェスチャー（PIN、生体認証など）をユーザーに求め、ユーザーがこれを提供します。
- Web サイトに「登録が完了しました。」というメッセージが表示されます。

1.2.2. 認証

ラップトップまたはデスクトップの場合:
- ユーザーは Bluetooth を介して電話をラップトップまたはデスクトップとペアリングします。
- ユーザーはブラウザーで example.com に移動し、サインインを開始します。
- ユーザーはブラウザーから「この操作を電話で完了してください。」というメッセージを受け取ります。
次に、電話上で:
- ユーザーには「example.com にサインイン」という個別のプロンプトまたは通知が表示されます。
- ユーザーはこのプロンプト / 通知を選択します。
- ユーザーには example.com の ID の一覧が表示されます。例: 「Mohamed としてサインイン / 张三としてサインイン」。
- ユーザーは ID を選び、認可ジェスチャー（PIN、生体認証など）を求められ、それを提供します。
次に、ラップトップに戻ると:
- Web ページには選択されたユーザーがサインインしたことが表示され、サインイン済みページに移動します。

1.2.3. 新しいデバイスの登録

このユースケースシナリオでは、リライングパーティが、ローミング認証器（例: USB セキュリティキーフォブ）とプラットフォーム認証器（例: 内蔵指紋センサー）の組み合わせを活用し、ユーザーが次のものを持つようにする方法を示します。

ユーザーにとって新しいクライアントデバイス（例: ラップトップ、デスクトップ）、またはプラットフォーム認証器を備えていないそのようなクライアントデバイスで認証するために使用する「主要な」ローミング認証器、および
プラットフォーム認証器を備えたクライアントデバイス上で、強力な再認証を低い負担で行う手段。

注: 1 つのアカウントに複数の認証器を登録するこの方法は、アカウント復旧のユースケースでも有用です。

まず、デスクトップコンピューター（プラットフォーム認証器を備えていない）上で:
- ユーザーはブラウザーで example.com に移動し、それまで使用していた任意の方法（パスワードなどのレガシーな方法の場合もあります）を使用して既存のアカウントにサインインするか、新しいアカウントを作成します。
- ユーザーはアカウントのセキュリティ設定に移動し、「セキュリティキーを登録」を選択します。
- Web サイトはユーザーに USB セキュリティキーフォブを接続するよう促し、ユーザーはそれを接続します。
- USB セキュリティキーが点滅して、ボタンを押す必要があることを示し、ユーザーはボタンを押します。
- Web サイトに「登録が完了しました。」というメッセージが表示されます。
注: このコンピューターはプラットフォーム認証器を備えていないため、Web サイトはユーザーに USB セキュリティキーを時々、またはユーザーが Web サイトを操作するたびに提示するよう要求する場合があります。これは Web サイトの裁量に委ねられます。
その後、ラップトップ（プラットフォーム認証器を備えている）上で:
- ユーザーはブラウザーで example.com に移動し、サインインを開始します。
- Web サイトはユーザーに USB セキュリティキーを接続するよう促します。
- ユーザーは以前に登録した USB セキュリティキーを接続し、ボタンを押します。
- Web サイトにはユーザーがサインインしたことが表示され、サインイン済みページに移動します。
- Web サイトが「このコンピューターを example.com に登録しますか？」と尋ねます。
- ユーザーが同意します。
- ラップトップは、事前に設定された認可ジェスチャー（PIN、生体認証など）をユーザーに求め、ユーザーがそれを提供します。
- Web サイトに「登録が完了しました。」というメッセージが表示されます。
- ユーザーはサインアウトします。
さらに後で、再びラップトップ上で:
- ユーザーはブラウザーで example.com に移動し、サインインを開始します。
- Web サイトに「コンピューターの指示に従ってサインインを完了してください。」というメッセージが表示されます。
- ラップトップはユーザーに認可ジェスチャー（PIN、生体認証など）を求め、ユーザーがそれを提供します。
- Web サイトにはユーザーがサインインしたことが表示され、サインイン済みページに移動します。

1.2.4. その他のユースケースおよび構成

次のものを含む（ただしこれらに限定されない）さまざまな追加のユースケースおよび構成も可能です。

ユーザーがラップトップで example.com に移動し、電話上でクレデンシャルを作成して登録するフローへ案内されます。
ユーザーが、USB または USB+NFC/BLE 接続オプションを備えた「フォブ」などの独立したローミング認証器を入手し、ラップトップまたは電話のブラウザーで example.com を読み込み、そのフォブ上でクレデンシャルを作成して登録するフローへ案内されます。
リライングパーティが、支払いまたはその他の金融取引など、単一の取引を認可するために、ユーザーに認可ジェスチャーを求めます。

1.3. API 使用シナリオの例

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

このセクションでは、公開鍵クレデンシャルのライフサイクルにおけるいくつかのイベントを、この API を使用するための対応するサンプルコードとともに順に説明します。これはフローの一例であり、 API の使用方法の範囲を制限するものではないことに注意してください。

前のセクションと同様に、このフローは独自のディスプレイを備えた第一要素ローミング認証器を使用するユースケースに焦点を当てています。このような認証器の一例はスマートフォンです。クライアントプラットフォームによる実装を条件として、他の認証器の種類もこの API でサポートされます。たとえば、このフローは、クライアントデバイスに組み込まれた認証器の場合でも変更なしで機能します。また、このフローは、独自のディスプレイを備えない認証器（スマートカードに似たもの）の場合にも、特定の実装上の考慮事項を条件として機能します。具体的には、クライアントプラットフォームは、本来なら認証器によって表示されるすべてのプロンプトを表示する必要があり、認証器はクライアントプラットフォームが認証器のすべてのクレデンシャルを列挙できるようにして、クライアントが適切なプロンプトを表示するための情報を得られるようにする必要があります。

1.3.1. 登録

これは、新しいクレデンシャルが作成され、サーバーに登録される初回のフローです。このフローでは、WebAuthn リライングパーティは、プラットフォーム認証器またはローミング認証器のいずれについても優先設定を持ちません。

ユーザーは example.com にアクセスし、そこからスクリプトが提供されます。この時点で、ユーザーはすでにレガシーなユーザー名とパスワード、追加の認証器、またはリライングパーティが許容するその他の手段を使用してログインしている場合があります。または、ユーザーが新しいアカウントを作成している途中である場合もあります。
リライングパーティのスクリプトが以下のコードスニペットを実行します。
クライアントプラットフォームが認証器を検索して特定します。
クライアントが認証器に接続し、必要であればペアリング操作を実行します。
認証器は、ユーザーが生体認証またはその他の認可ジェスチャーを提供するための適切な UI を表示します。
認証器はクライアントにレスポンスを返し、クライアントはさらにリライングパーティのスクリプトにレスポンスを返します。ユーザーが認証器の選択または認可の提供を拒否した場合は、適切なエラーが返されます。
新しいクレデンシャルが作成された場合、
- リライングパーティのスクリプトは、新しく生成されたクレデンシャル公開鍵を、認証器の来歴および特性に関するアテステーションなどの追加情報とともにサーバーに送信します。
- サーバーはクレデンシャル公開鍵をデータベースに保存し、ユーザーおよびアテステーションによって示された認証の特性と関連付け、後で使用するための分かりやすい名前も保存します。
- スクリプトは、将来の UX を改善するため、クレデンシャル IDなどのデータをローカルストレージに保存して、ユーザーに提示するクレデンシャルの選択肢を絞り込む場合があります。

新しい鍵を生成して登録するためのサンプルコードは次のとおりです。

if (!window.PublicKeyCredential) { /* クライアントには対応能力がありません。エラーを処理します。 */ }

var publicKey = {
  // チャレンジはサーバーによって生成されます。セキュリティに関する考慮事項を参照してください
  challenge: new Uint8Array([21,31,105 /* サーバーによって生成されたランダムなバイトがさらに 29 個 */]),

  // リライングパーティ:
  rp: {
    name: "ACME Corporation"
  },

  // ユーザー:
  user: {
    id: Uint8Array.from(window.atob("MIIBkzCCATigAwIBAjCCAZMwggE4oAMCAQIwggGTMII="), c=>c.charCodeAt(0)),
    name: "alex.mueller@example.com",
    displayName: "Alex Müller",
  },

  // このリライングパーティは ES256 または RS256 のいずれのクレデンシャルも受け入れますが、
  // ES256 クレデンシャルを優先します。
  pubKeyCredParams: [
    {
      type: "public-key",
      alg: -7 // IANA COSE Algorithms レジストリに登録されている "ES256"
    },
    {
      type: "public-key",
      alg: -257 // この仕様によって "RS256" 用に登録された値
    }
  ],

  authenticatorSelection: {
    // 可能であれば UV を使用します。これはデフォルトでもあります。
    userVerification: "preferred"
  },

  timeout: 360000,  // 6 分
  excludeCredentials: [
    // これらのクレデンシャルのいずれかを持つ認証器を再登録しない
    {"id": Uint8Array.from(window.atob("ufJWp8YGlibm1Kd9XQBWN1WAw2jy5In2Xhon9HAqcXE="), c=>c.charCodeAt(0)), "type": "public-key"},
    {"id": Uint8Array.from(window.atob("E/e1dhZc++mIsz4f9hb6NifAzJpF1V4mEtRlIPBiWdY="), c=>c.charCodeAt(0)), "type": "public-key"}
  ],

  // excludeCredentials のチェックを U2F で登録されたクレデンシャルと後方互換にする
  extensions: {"appidExclude": "https://acme.example.com"}
};

// 注: 次の呼び出しにより、認証器が UI を表示します。
navigator.credentials.create({ publicKey })
  .then(function (newCredentialInfo) {
    // 新しいクレデンシャル情報を検証および登録のためサーバーに送信します。
  }).catch(function (err) {
    // 受け入れ可能な認証器がないか、ユーザーが同意を拒否しました。適切に処理します。
  });

1.3.2. ユーザー検証プラットフォーム認証器を特に使用する登録

これは、WebAuthn リライングパーティが、特にユーザー検証プラットフォーム認証器を使用して公開鍵クレデンシャルを作成することを希望する場合のフロー例です。

ユーザーは example.com にアクセスしてログインボタンをクリックし、login.example.com にリダイレクトされます。
ユーザーはログインするためにユーザー名とパスワードを入力します。ログインに成功すると、ユーザーは example.com にリダイレクトされます。
リライングパーティのスクリプトが以下のコードスニペットを実行します。
1. ユーザーエージェントは、ユーザー検証プラットフォーム認証器が利用可能かどうかを確認します。利用できない場合、このフローを終了します。
2. リライングパーティは、それを使用してクレデンシャルを作成するかどうかをユーザーに尋ねます。作成しない場合、このフローを終了します。
3. ユーザーエージェントおよび/またはオペレーティングシステムは適切な UI を表示し、利用可能なプラットフォーム認証器のいずれかを使用してクレデンシャルを作成するようユーザーを案内します。
4. クレデンシャルの作成に成功すると、リライングパーティのスクリプトは新しいクレデンシャルをサーバーに送信します。

if (!window.PublicKeyCredential) { /* クライアントはこの API に対応していません。エラーを処理します。 */ }

PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()
    .then(function (uvpaAvailable) {
        // ユーザー検証プラットフォーム認証器が存在する場合
        if (uvpaAvailable) {
            // RP 固有の UI をレンダリングし、Boolean 値の Promise を取得する
            return askIfUserWantsToCreateCredential();
        }
    }).then(function (userSaidYes) {
        // ユーザー検証プラットフォーム認証器が存在し、
        // かつユーザーがクレデンシャルの作成を希望する場合
        if (userSaidYes) {
            var publicKeyOptions = { /* 公開鍵クレデンシャル作成オプション。 */};
            return navigator.credentials.create({ "publicKey": publicKeyOptions });
        }
    }).then(function (newCredentialInfo) {
        if (newCredentialInfo) {
            // 新しいクレデンシャル情報を検証および登録のためサーバーに送信します。
        }
    }).catch(function (err) {
        // 問題が発生しました。適切に処理します。
    });

1.3.3. 認証

これは、すでに登録済みのクレデンシャルを持つユーザーが Web サイトにアクセスし、そのクレデンシャルを使用して認証しようとする場合のフローです。

ユーザーは example.com にアクセスし、そこからスクリプトが提供されます。
スクリプトはクライアントに認証アサーションを要求し、ユーザーにとって受け入れ可能なクレデンシャルの選択肢を絞り込むため、可能な限り多くの情報を提供します。これは、登録後にローカルに保存されたデータから取得するか、ユーザーにユーザー名を入力させるなどの別の手段によって取得できます。
リライングパーティのスクリプトが以下のコードスニペットのいずれかを実行します。
クライアントプラットフォームが認証器を検索して特定します。
クライアントが認証器に接続し、必要であればペアリング操作を実行します。
認証器はユーザーに、注意が必要であることを示す通知を表示します。通知を開くと、ユーザーには、クレデンシャルの作成時に提供されたアカウント情報を使用して受け入れ可能なクレデンシャルを選択するための分かりやすいメニューと、これらの鍵を要求しているオリジンに関する情報が表示されます。
認証器はユーザーから生体認証またはその他の認可ジェスチャーを取得します。
認証器はクライアントにレスポンスを返し、クライアントはさらにリライングパーティのスクリプトにレスポンスを返します。ユーザーがクレデンシャルの選択または認可の提供を拒否した場合は、適切なエラーが返されます。
アサーションが正常に生成されて返された場合、
- スクリプトはアサーションをサーバーに送信します。
- サーバーはアサーションを調べ、クレデンシャル IDを抽出し、データベース内の登録済みクレデンシャル公開鍵を検索して、アサーション署名を検証します。有効であれば、アサーションのクレデンシャル IDに関連付けられた ID を検索し、その ID は認証済みとなります。クレデンシャル IDがサーバーによって認識されない場合（例: 非アクティブであるため登録解除されている場合）、認証は失敗します。各リライングパーティは、これを独自の方法で処理します。
- サーバーは、認証成功時に通常行う処理、つまり成功ページを返す、認証 Cookie を設定するなどを実行します。

リライングパーティのスクリプトに、クレデンシャルの一覧を絞り込むために利用できるヒント（例: ローカルに保存されたデータ）がない場合、このような認証を実行するサンプルコードは次のようになります。

if (!window.PublicKeyCredential) { /* クライアントには対応能力がありません。エラーを処理します。 */ }

// credentialId は認証器によって生成される不透明なランダムバイト配列です
var credentialId = new Uint8Array([183, 148, 245 /* 認証器によって以前に生成されたランダムなバイトがさらに続く */]);
var options = {
  // チャレンジはサーバーによって生成されます。セキュリティに関する考慮事項を参照してください
  challenge: new Uint8Array([4,101,15 /* サーバーによって生成されたランダムなバイトがさらに 29 個 */]),
  timeout: 120000,  // 2 分
  allowCredentials: [{ type: "public-key", id: credentialId }]
};

navigator.credentials.get({ "publicKey": options })
    .then(function (assertion) {
    // アサーションを検証のためサーバーに送信します
}).catch(function (err) {
    // 受け入れ可能なクレデンシャルがないか、ユーザーが同意を拒否しました。適切に処理します。
});

一方、リライングパーティのスクリプトにクレデンシャルの一覧を絞り込むためのヒントがある場合、そのような認証を実行するサンプルコードは次のようになります。このサンプルでは、クレデンシャルプロパティ拡張の使用方法も示していることに注意してください。

if (!window.PublicKeyCredential) { /* クライアントには対応能力がありません。エラーを処理します。 */ }

var encoder = new TextEncoder();
var acceptableCredential1 = {
    type: "public-key",
    id: encoder.encode("BA44712732CE")
};
var acceptableCredential2 = {
    type: "public-key",
    id: encoder.encode("BG35122345NF")
};

var options = {
  // チャレンジはサーバーによって生成されます。セキュリティに関する考慮事項を参照してください
  challenge: new Uint8Array([8,18,33 /* サーバーによって生成されたランダムなバイトがさらに 29 個 */]),
  timeout: 120000,  // 2 分
  allowCredentials: [acceptableCredential1, acceptableCredential2],
  extensions: { 'credProps': true }
};

navigator.credentials.get({ "publicKey": options })
    .then(function (assertion) {
    // アサーションを検証のためサーバーに送信します
}).catch(function (err) {
    // 受け入れ可能なクレデンシャルがないか、ユーザーが同意を拒否しました。適切に処理します。
});

1.3.4. 認証操作の中止

以下の例は、開発者が AbortSignal パラメーターを使用してクレデンシャル登録操作を中止する方法を示しています。同様の手順が認証操作にも適用されます。

const authAbortController = new AbortController();
const authAbortSignal = authAbortController.signal;

authAbortSignal.onabort = function () {
    // ページが中止の開始を認識したら、中止を試みていることをユーザーに通知します。
}

var options = {
    // オプションの一覧。
}

navigator.credentials.create({
    publicKey: options,
    signal: authAbortSignal})
    .then(function (attestation) {
        // ユーザーを登録します。
    }).catch(function (error) {
        if (error == "AbortError") {
            // クレデンシャルが作成されなかったことをユーザーに通知します。
            // 鍵が作成されなかったことをサーバーに通知します。
        }
    });

// 認証が行われるたびにウィジェットが表示されるものとします。
if (widget == "disappear") {
    authAbortController.abort();
}

1.3.5. 廃止

以下は、クレデンシャルの廃止が望まれる可能性のある状況です。これらはすべてサーバー側で処理され、ここで規定する API によるサポートを必要としないことに注意してください。

可能性 #1 -- ユーザーがクレデンシャルの紛失を報告する。
- ユーザーは server.example.net にアクセスして認証し、紛失/盗難された認証器を報告するためのリンクをたどります。
- サーバーは、登録時に設定された分かりやすい名前を付けた登録済みクレデンシャルの一覧を表示するページを返します。
- ユーザーはクレデンシャルを選択し、サーバーはそれをデータベースから削除します。
- 以後、リライングパーティのスクリプトは、受け入れ可能なクレデンシャルのいかなる一覧にもこのクレデンシャルを指定せず、このクレデンシャルによって署名されたアサーションは拒否されます。
可能性 #2 -- 非アクティブであるため、サーバーがクレデンシャルの登録を解除する。
- サーバーはメンテナンス作業中にクレデンシャルをデータベースから削除します。
- 以後、リライングパーティのスクリプトは、受け入れ可能なクレデンシャルのいかなる一覧にもこのクレデンシャルを指定せず、このクレデンシャルによって署名されたアサーションは拒否されます。
可能性 #3 -- ユーザーが認証器からクレデンシャルを削除する。
- ユーザーは、認証器固有の方法（例: デバイス設定 UI）を使用して、自身の認証器からクレデンシャルを削除します。
- この時点以降、このクレデンシャルはいかなる選択プロンプトにも表示されず、それを使用してアサーションを生成することもできません。
- その後のある時点で、非アクティブであるため、サーバーがこのクレデンシャルの登録を解除します。

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

この仕様は、一般的な場合に Web Authentication を使用する方法を定義します。特定のプラットフォームのサポート（例: アプリ）と関連して Web Authentication を使用する場合は、追加のガイダンスおよび制限についてプラットフォーム固有の文書およびガイドを参照することを推奨します。

2. 適合性

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

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

ユーザーエージェントが適合していると見なされるためには、§ 5 Web Authentication API に記載されているとおりに動作しなければなりません。適合ユーザーエージェントは、最終的な結果がこの仕様のアルゴリズムによって得られる結果と区別できない限り、この仕様で示されるアルゴリズムを任意の方法で実装してもよいものとします。

適合ユーザーエージェントは、「Web IDL」仕様に記載されているとおり、この仕様の IDL 断片の適合実装でもなければなりません。 [WebIDL]

2.1.1. DOMString 型としての列挙型

列挙型は Web IDL の他の部分から参照されません。これは、参照するとこの仕様およびその実装を更新せずに他の値を使用できなくなるためです。後方互換性のため、クライアントプラットフォームおよびリライングパーティが未知の値を処理することが重要です。この仕様の列挙型は、文書化およびレジストリとしてここに存在します。列挙型が他の場所で表現される場合、それらは DOMString 型として扱われます。たとえば transports が該当します。

2.2. 認証器

WebAuthn 認証器は、§ 6 WebAuthn 認証器モデルで定義される操作を提供しなければならず、それらの操作はそこで説明されているとおりに動作しなければなりません。これは、認証器が適合ユーザーエージェントによって使用可能であるための機能およびセキュリティ要件の集合です。

§ 1.2 ユースケースで説明されているとおり、認証器はユーザーエージェントの基盤となるオペレーティングシステム内、外部ハードウェア内、またはその両方の組み合わせとして実装できます。

2.2.1. FIDO U2F との後方互換性

認証器が § 8.6 FIDO U2F アテステーションステートメント形式のみをサポートしている場合、ユーザーハンドルを保存する仕組みがないため、返される 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: アテステーションステートメントや拡張を含む、この仕様の多くの構造は、 CTAP2 正規 CBOR エンコーディング形式を使用して Compact Binary Object Representation (CBOR) [RFC8949] でエンコードされます。これは [FIDO-CTAP] で定義されています。
CDDL: この仕様では、すべての CBOR エンコードデータの構文を CBOR Data Definition Language (CDDL) [RFC8610] を使用して記述します。
COSE: CBOR Object Signing and Encryption (COSE) [RFC8152]。この仕様によって確立された IANA COSE Algorithms レジストリ [IANA-COSE-ALGS-REG] も使用されます。
Credential Management: この文書で説明される API は、[CREDENTIAL-MANAGEMENT-1] で定義される Credential 概念の拡張です。
DOM: DOMException およびこの仕様で使用される DOMException 値は、[DOM4] で定義されています。
ECMAScript: %ArrayBuffer% は [ECMAScript] で定義されています。
HTML: 閲覧コンテキスト、オリジン、不透明なオリジン、タプルオリジン、関連設定オブジェクト、および登録可能なドメインサフィックスであるか等しいという概念は、[HTML] で定義されています。
URL: 同一サイトという概念は [URL] で定義されています。
Web IDL: この仕様の多くのインターフェイス定義およびすべての IDL は、[WebIDL] に依存しています。この更新版の Web IDL 標準では Promise のサポートが追加されており、現在ではすべての新しい Web API における非同期対話の推奨メカニズムとなっています。
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 証明書です。登録時に、認証器はアテステーション秘密鍵を使用して、 authenticatorMakeCredential 操作を介して生成して返す、リライングパーティ固有のクレデンシャル公開鍵（および追加データ）に署名します。リライングパーティは、アテステーション証明書で伝達されるアテステーション公開鍵を使用して、アテステーション署名を検証します。自己アテステーションの場合、認証器には独立したアテステーションキーペアもアテステーション証明書も存在しないことに注意してください。詳細については、自己アテステーションを参照してください。

認証

認証セレモニー

ユーザーと、そのユーザーのクライアント（少なくとも 1 つの認証器を含む）が協調して、以前に登録された公開鍵クレデンシャル（登録を参照）のクレデンシャル秘密鍵をユーザーが制御していることをリライングパーティに暗号学的に証明するセレモニーです。これにはユーザープレゼンスのテストまたはユーザー検証が含まれることに注意してください。

WebAuthn の認証セレモニーは、§ 7.2 認証アサーションの検証で定義されており、リライングパーティが navigator.credentials.get() を publicKey 引数とともに呼び出すことで開始されます。導入的な概要については § 5 Web Authentication API を、実装例については § 1.3.3 認証を参照してください。

認証アサーション

アサーション

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

これは、[CREDENTIAL-MANAGEMENT-1] 仕様の単回使用クレデンシャルに対応します。

認証器

WebAuthn 認証器

ハードウェアまたはソフトウェアとして存在する暗号学的エンティティであり、ユーザーを特定のリライングパーティに登録し、その後、リライングパーティから要求されたときに、登録された公開鍵クレデンシャルを所有していることをアサートでき、任意でユーザーを検証できます。認証器は、登録中のアテステーションを介して、自身の種類およびセキュリティ特性に関する情報を報告できます。

WebAuthn 認証器は、ローミング認証器、クライアントデバイスに統合された専用ハードウェアサブシステム、またはクライアントもしくはクライアントデバイスのソフトウェアコンポーネントである場合があります。

一般に、認証器には 1 人のユーザーしかいないものと想定されます。複数の自然人が認証器へのアクセスを共有する場合、その認証器のコンテキストでは、同じユーザーを表すものと見なされます。認証器の実装が、分離された区画で複数のユーザーをサポートする場合、各区画は、他のユーザーのクレデンシャルにアクセスできない単一ユーザーを持つ個別の認証器と見なされます。

認可ジェスチャー

認可ジェスチャーとは、登録や認証などのセレモニーの一部として、ユーザーが認証器に対して行う物理的な操作です。このような認可ジェスチャーを行うことで、ユーザーはセレモニーの続行について同意を与えます（すなわち、認可します）。使用される認証器にその能力がある場合、これにはユーザー検証が含まれてもよく、または単純なユーザープレゼンスのテストが含まれてもよいものとします。

生体認識

生物学的および行動的特性に基づいて個人を自動的に認識すること [ISOBiometricVocabulary]。

生体認証器

生体認識を実装する任意の認証器。

バインドされたクレデンシャル

公開鍵クレデンシャルソースまたは公開鍵クレデンシャルは、その管理認証器にバインドされていると言います。これは、管理認証器のみが、それにバインドされた公開鍵クレデンシャルソースに対するアサーションを生成できることを意味します。

セレモニー

セレモニー [Ceremony] という概念は、ネットワークプロトコルの概念を拡張したものであり、コンピューターノードに加えて人間のノードも含み、通信リンクにはユーザーインターフェイス、人間同士の通信、およびデータを運ぶ物理オブジェクトの移動が含まれます。プロトコルにとって帯域外であるものは、セレモニーにとっては帯域内です。この仕様では、登録および認証がセレモニーであり、認可ジェスチャーは、しばしばそれらのセレモニーの構成要素です。

クライアント

WebAuthn クライアント

ここでは単にクライアントとも呼びます。適合ユーザーエージェントも参照してください。WebAuthn クライアントは、通常、ユーザーエージェント内に（全体または一部として）実装される仲介エンティティです。概念的には、 Web Authentication API の基盤となり、[[Create]](origin, options, sameOriginWithAncestors) および [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 内部メソッドの実装を具現化します。基礎となる認証器操作への入力をマーシャリングすることと、後者の操作の結果をWeb Authentication API の呼び出し元へ返すことの両方を担います。

WebAuthn クライアントは、 WebAuthn クライアントデバイス上で動作し、それとは別個のものです。

クライアントデバイス

WebAuthn クライアントデバイス

WebAuthn クライアントが動作するハードウェアデバイス、たとえばスマートフォン、ラップトップコンピューター、デスクトップコンピューター、およびそのハードウェア上で動作するオペレーティングシステムです。

WebAuthn クライアントデバイスとクライアントの相違点は次のとおりです。

単一のクライアントデバイスは、複数のクライアント、すなわちブラウザー実装の実行をサポートしてもよく、それらはすべて、そのクライアントデバイスで利用可能な同じ認証器にアクセスでき、かつ
プラットフォーム認証器は、WebAuthn クライアントではなくクライアントデバイスにバインドされます。

クライアントデバイスとクライアントは、一体となってクライアントプラットフォームを構成します。

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

クライアントデバイスとクライアントは、一体となってクライアントプラットフォームを構成します。単一のハードウェアデバイスは、異なるオペレーティングシステムおよび/またはクライアントを実行することにより、異なる時点で複数の別個のクライアントプラットフォームの一部となってもよいものとします。

クライアント側

一般に、ユーザーのクライアントプラットフォーム、認証器、およびそれらすべてを結び付けるあらゆるものの組み合わせを指します。

クライアント側で検出可能な公開鍵クレデンシャルソース

クライアント側で検出可能なクレデンシャル

検出可能なクレデンシャル

[非推奨] 常駐クレデンシャル

[非推奨] 常駐キー

注: 歴史的に、クライアント側で検出可能なクレデンシャルは、常駐クレデンシャルまたは常駐キーとして知られていました。 ResidentKey および residentKey という語句が、 WebAuthn API と認証器モデルの両方で広く使用されているため（たとえば、辞書メンバー名、アルゴリズムの変数名、および操作パラメーター内）、後方互換性のため、それらの名前に含まれる resident の使用は変更されていません。また、常駐キーという用語は、ここではクライアント側で検出可能なクレデンシャルと同等のものとして定義されています。

クライアント側で検出可能な公開鍵クレデンシャルソース、略して検出可能なクレデンシャルとは、 検出可能であり、リライングパーティがクレデンシャル IDを提供しない認証セレモニーで使用できる公開鍵クレデンシャルソースです。すなわち、リライングパーティは、空の allowCredentials 引数を指定して navigator.credentials.get() を呼び出します。これは、リライングパーティが必ずしも最初にユーザーを識別する必要がないことを意味します。

その結果、検出可能なクレデンシャルに対応する認証器は、 RP ID のみが与えられた場合でも、検出可能なクレデンシャルについてアサーション署名を生成できます。そのため、公開鍵クレデンシャルソースは、認証器またはクライアントプラットフォームに保存されている必要があります。これは、サーバー側公開鍵クレデンシャルソースとは対照的です。後者では、認証器にRP IDとクレデンシャル IDの両方を与える必要がありますが、公開鍵クレデンシャルソースをクライアント側に保存する必要はありません。

次も参照してください: クライアント側クレデンシャル保存方式および検出不可能なクレデンシャル。

注: クライアント側で検出可能なクレデンシャルは、クレデンシャル IDが与えられる認証セレモニーでも使用できます。すなわち、navigator.credentials.get() を、非空の allowCredentials 引数とともに呼び出す場合です。

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

基礎となるクライアントデバイスと協調して、Web Authentication APIおよびこの仕様で示されるアルゴリズムを実装し、認証器とリライングパーティ間の通信を処理するユーザーエージェント。

クレデンシャル ID

公開鍵クレデンシャルソースおよびその認証アサーションを識別する、確率的に一意なバイト列。

クレデンシャル ID は、認証器によって次の 2 つの形式で生成されます。

少なくとも 100 ビットのエントロピーを含む、少なくとも 16 バイト、または
公開鍵クレデンシャルソースから、そのクレデンシャル ID および可変項目を除いたものを、その管理認証器だけが復号できるように暗号化したもの。この形式では、リライングパーティに必要な状態を保存させることで、認証器をほぼステートレスにできます。

注: [FIDO-UAF-AUTHNR-CMDS] には、 "Security Guidelines" の下に暗号化技法に関するガイダンスが含まれています。

リライングパーティは、これら 2 つのクレデンシャル ID形式を区別する必要はありません。

クレデンシャルキーペア

クレデンシャル秘密鍵

クレデンシャル公開鍵

ユーザー公開鍵

クレデンシャルキーペアは、認証器によって生成され、特定のWebAuthn リライングパーティにスコープ設定された非対称暗号鍵のペアです。これは公開鍵クレデンシャルの中心的な部分です。

クレデンシャル公開鍵は、クレデンシャルキーペアの公開鍵部分です。クレデンシャル公開鍵は、登録セレモニー中にリライングパーティへ返されます。

クレデンシャル秘密鍵は、クレデンシャルキーペアの秘密鍵部分です。クレデンシャル秘密鍵は、特定の認証器、すなわちその管理認証器にバインドされ、認証器の所有者に対してさえも、他のいかなる当事者にも公開されないことが期待されます。

自己アテステーションの場合、クレデンシャルキーペアがアテステーションキーペアとしても使用されることに注意してください。詳細は自己アテステーションを参照してください。

注: クレデンシャル公開鍵は、FIDO UAF [UAFProtocol]、FIDO U2F [FIDO-U2F-Message-Formats] およびそれに関連するこの仕様の一部では、ユーザー公開鍵と呼ばれます。

クレデンシャルプロパティ

クレデンシャルプロパティとは、公開鍵クレデンシャルソースの何らかの特性的なプロパティであり、たとえばそれがクライアント側で検出可能なクレデンシャルであるか、サーバー側クレデンシャルであるかなどです。

人間にとっての扱いやすさ

人間にとって扱いやすい識別子とは、たとえばランダムに生成されたビット列のような識別子とは対照的に、一般的な人間のユーザーが記憶して再現できることを意図したものです [EduPersonObjectClassSpec]。

検出不可能なクレデンシャル

これはクライアント側で検出可能ではないため、navigator.credentials.get() を呼び出す際に、そのクレデンシャル IDを allowCredentials で指定しなければならないクレデンシャルです。サーバー側クレデンシャルも参照してください。

公開鍵クレデンシャルソース

認証器が認証アサーションを生成するために使用するクレデンシャルソース（[CREDENTIAL-MANAGEMENT-1]）。公開鍵クレデンシャルソースは、次の項目を持つ構造体で構成されます。

type: 値の型は PublicKeyCredentialType であり、デフォルトは public-key です。
id: クレデンシャル ID。
privateKey: クレデンシャル秘密鍵。
rpId: この公開鍵クレデンシャルソースがスコープ設定されているリライングパーティのリライングパーティ識別子。
userHandle: この公開鍵クレデンシャルソースが作成されたときに関連付けられたユーザーハンドル。この項目は null 許容です。
otherUI: 認証器が UI に情報を提供するために使用する任意のその他の情報。たとえば、ユーザーの displayName が含まれる場合があります。 otherUI は可変項目であり、 otherUIの更新を妨げるような方法で、公開鍵クレデンシャルソースにバインドすべきではありません。

authenticatorMakeCredential 操作は、管理認証器にバインドされた公開鍵クレデンシャルソースを作成し、そのクレデンシャル秘密鍵に関連付けられたクレデンシャル公開鍵を返します。リライングパーティは、このクレデンシャル公開鍵を使用して、この公開鍵クレデンシャルソースによって作成された認証アサーションを検証できます。

公開鍵クレデンシャル

一般に、クレデンシャルとは、あるエンティティが別のエンティティに対して自身を認証するために提示するデータです [RFC4949]。公開鍵クレデンシャルという用語は、次のいずれかを指します。公開鍵クレデンシャルソース、公開鍵クレデンシャルソースに対応する、場合によってはアテステーションされたクレデンシャル公開鍵、または認証アサーション。どれを指すかは通常、コンテキストによって決まります。

注: これは [RFC4949] に対する意図的な違反です。英語では、"credential" は、 a) ある主張を証明するために提示されるものと、b) 複数回使用されることを意図したものの両方を意味します。公開鍵システムでは、単一のデータ片で両方の基準を安全に満たすことは不可能です。[RFC4949] は、クレデンシャルを複数回使用できるもの（公開鍵）として定義することを選択していますが、この仕様では "credential" に英語の用語としての柔軟性を持たせています。この仕様では、[RFC4949] のクレデンシャルに関連するデータを識別するために、より具体的な用語を使用します。

"認証情報"（秘密鍵を含む場合があります）: 公開鍵クレデンシャルソース
"署名された値": 認証アサーション
[RFC4949] の "クレデンシャル": クレデンシャル公開鍵またはアテステーションオブジェクト

登録時に、認証器は非対称キーペアを作成し、その秘密鍵部分およびリライングパーティからの情報を公開鍵クレデンシャルソースに保存します。公開鍵部分はリライングパーティに返され、リライングパーティはそれを現在のユーザーのアカウントと関連付けて保存します。その後、そのリライングパーティだけが、そのRP IDによって識別され、get() メソッドを介して公開鍵クレデンシャルを認証セレモニーで使用できます。リライングパーティは、保存しているクレデンシャル公開鍵のコピーを使用して、結果として得られる認証アサーションを検証します。

レート制限

一定期間内に連続して失敗する認証試行の回数を制限することにより、認証器が総当たり攻撃に対する制御を実装するプロセス（スロットリングとも呼ばれます）。制限に達した場合、認証器は試行が続くごとに指数関数的に増加する遅延を課すか、現在の認証方式を無効にして、利用可能であれば別の認証要素を提供すべきです。レート制限は、多くの場合ユーザー検証の一側面として実装されます。

登録

登録セレモニー

ユーザー、リライングパーティ、およびユーザーのクライアント（少なくとも 1 つの認証器を含む）が協調して公開鍵クレデンシャルを作成し、それをユーザーのリライングパーティアカウントに関連付けるセレモニーです。これにはユーザープレゼンスのテストまたはユーザー検証の利用が含まれることに注意してください。登録セレモニーが成功すると、ユーザーは認証セレモニーによって認証できます。

WebAuthn の登録セレモニーは、§ 7.1 新しいクレデンシャルの登録で定義され、リライングパーティが navigator.credentials.create() を publicKey 引数とともに呼び出すことで開始されます。導入的な概要については § 5 Web Authentication API を、実装例については § 1.3.1 登録を参照してください。

リライングパーティ

WebAuthn リライングパーティを参照してください。

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

RP ID

WebAuthn API のコンテキストでは、リライングパーティ識別子とは、特定の登録または認証セレモニーがその代理で実行されるWebAuthn リライングパーティを識別する有効なドメイン文字列です。公開鍵クレデンシャルは、それが登録されたのと同じエンティティ（RP IDによって識別される）との認証にのみ使用できます。

デフォルトでは、WebAuthn 操作のRP IDは、呼び出し元のオリジンの実効ドメインに設定されます。このデフォルト値は、呼び出し元が指定したRP IDの値が、呼び出し元のオリジンの実効ドメインの登録可能なドメインサフィックスであるか等しい限り、呼び出し元によって上書きされてもよいものとします。§ 5.1.3 新しいクレデンシャルの作成 - PublicKeyCredential の [[Create]](origin, options, sameOriginWithAncestors) メソッドおよび§ 5.1.4 既存のクレデンシャルを使用してアサーションを作成する - PublicKeyCredential の [[Get]](options) メソッドも参照してください。

注: RP IDは、ホストのドメイン名に基づきます。それ自体には、オリジンとは異なり、スキームやポートは含まれません。公開鍵クレデンシャルのRP IDは、そのスコープを決定します。すなわち、次のように公開鍵クレデンシャルを使用できるオリジンの集合を決定します。

RP IDは、オリジンの実効ドメインと等しいか、オリジンの実効ドメインの登録可能なドメインサフィックスでなければなりません。
オリジンのスキームは https でなければなりません。
オリジンのポートには制限がありません。

たとえば、オリジンが https://login.example.com:1337 であるリライングパーティの場合、次のRP IDが有効です: login.example.com （デフォルト）および example.com。ただし、m.login.example.com および com は無効です。

これは、広く展開されているアンビエントクレデンシャル（例: Cookie、[RFC6265]）の動作に一致させるために行われます。これは、document.domain の setter が提供するものよりも、 "same-origin" 制限を大幅に緩和するものであることに注意してください。

オリジン値に対するこれらの制限は、WebAuthn クライアントに適用されます。

Web 以外のプラットフォーム（例: ネイティブモバイルアプリケーション）で WebAuthn の公開鍵クレデンシャルを利用可能にするためにWebAuthn APIを模倣する他の仕様は、呼び出し元をリライングパーティ識別子にバインドするための異なる規則を定義してもよいものとします。ただし、RP IDの構文は、有効なドメイン文字列または URI [RFC3986] [URL] のいずれかに適合しなければなりません。

サーバー側公開鍵クレデンシャルソース

サーバー側クレデンシャル

[非推奨] 非常駐クレデンシャル

注: 歴史的に、サーバー側クレデンシャルは非常駐クレデンシャルとして知られていました。後方互換性のため、名前にさまざまな形の resident を含む、さまざまなWebAuthn APIおよび認証器モデルのコンポーネントは変更されていません。

サーバー側公開鍵クレデンシャルソース、略してサーバー側クレデンシャルとは、リライングパーティが navigator.credentials.get() の allowCredentials 引数でそのクレデンシャル IDを指定した場合にのみ認証セレモニーで使用できる公開鍵クレデンシャルソースです。これは、リライングパーティがクレデンシャルの保存および検出を管理し、さらに navigator.credentials.get() の呼び出しで指定するクレデンシャル IDを検出するために、最初にユーザーを識別できなければならないことを意味します。

サーバー側クレデンシャルでは、公開鍵クレデンシャルソースをクライアント側に保存する必要はありません。これは、ユーザーのクレデンシャル IDを navigator.credentials.get() の呼び出しに指定するために、最初にユーザーを識別する必要がないクライアント側で検出可能なクレデンシャルとは対照的です。

次も参照してください: サーバー側クレデンシャル保存方式および検出不可能なクレデンシャル。

ユーザープレゼンスのテスト

ユーザープレゼンスのテストは、単純な形式の認可ジェスチャーおよび技術的プロセスであり、ユーザーが（通常は）単に認証器に触れることで対話し（他の方式も存在する場合があります）、Boolean の結果を得ます。これはユーザー検証を構成しないことに注意してください。なぜなら、ユーザープレゼンスのテストは、定義上、生体認識を行う能力がなく、またパスワードや PIN のような共有秘密の提示も伴わないためです。

ユーザーの同意

ユーザーの同意とは、求められている内容にユーザーが同意することを意味します。すなわち、プロンプトを読んで理解することを含みます。認可ジェスチャーは、ユーザーの同意を示すためにしばしば使用されるセレモニーの構成要素です。

ユーザーハンドル

ユーザーハンドルは、リライングパーティによって user.id の値として指定され、特定の公開鍵クレデンシャルを、リライングパーティの特定のユーザーアカウントに対応付けるために使用されます。認証器はさらに、 RP IDとユーザーハンドルのペアを公開鍵クレデンシャルソースに対応付けます。

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

ユーザー検証

認証器が、authenticatorMakeCredential およびauthenticatorGetAssertion 操作の呼び出しを ローカルに認可する技術的プロセスです。ユーザー検証は、さまざまな認可ジェスチャー方式によって開始されてもよいものとします。たとえば、タッチと PIN コード、パスワード入力、または生体認識（例: 指紋の提示） [ISOBiometricVocabulary] などです。その意図は、個々のユーザーを区別することです。

ユーザー検証は、リライングパーティにユーザーの具体的な身元を与えるものではありませんが、そのクレデンシャルを使用してユーザー検証を伴う 2 回以上のセレモニーが行われた場合、それらすべてを実行したのが同じユーザーであったことを表します。ただし、複数の自然人が同じ認証器へのアクセスを共有している場合、同じユーザーが常に同じ自然人であるとは限りません。

注: 自然人を区別できるかどうかは、かなりの部分、クライアントプラットフォームおよび認証器の能力に依存します。たとえば、一部のデバイスは 1 人の個人による使用を意図していますが、複数の自然人が指紋を登録したり同じ PIN を知ったりすることを許可し、その結果、そのデバイスを使用して同じリライングパーティのアカウントにアクセスできる場合があります。

注: authenticatorMakeCredential およびauthenticatorGetAssertion 操作の呼び出しは、認証器によって管理される鍵素材の使用を意味します。

また、セキュリティのため、ユーザー検証およびクレデンシャル秘密鍵の使用は、すべて認証器を定義する論理的なセキュリティ境界内で行われなければなりません。

ユーザー検証手順は、総当たり攻撃に対する保護としてレート制限を実装してもよいものとします。

ユーザープレゼント

UP

ユーザープレゼンスのテストが正常に完了すると、そのユーザーは "プレゼント" であると言います。

ユーザー検証済み

UV

ユーザー検証プロセスが正常に完了すると、そのユーザーは "検証済み" であると言います。

WebAuthn リライングパーティ

その Web アプリケーションが、ユーザーを登録および認証するためにWeb Authentication APIを利用するエンティティ。

リライングパーティの実装は通常、クライアント内でWeb Authentication APIを呼び出すクライアント側スクリプトと、リライングパーティ操作およびその他のアプリケーションロジックを実行するサーバー側コンポーネントの両方で構成されます。 2 つのコンポーネント間の通信には HTTPS または同等のトランスポートセキュリティを使用しなければなりませんが、それ以外についてはこの仕様の範囲外です。

注: リライングパーティという用語は、他のコンテキスト（例: X.509 や OAuth）でもよく使用されますが、あるコンテキストでリライングパーティとして機能するエンティティが、他のコンテキストでも必ずしもリライングパーティであるとは限りません。この仕様では、 WebAuthn リライングパーティという用語は、多くの場合単にリライングパーティと短縮され、WebAuthn のコンテキストにおけるリライングパーティを明示的に指します。具体的なインスタンス化では、WebAuthn のコンテキストが、たとえば OAuth に基づくものなど、より広い全体的なコンテキストに組み込まれる場合があることに注意してください。

5. Web Authentication API

このセクションでは、公開鍵クレデンシャルを作成および使用するための API を規範的に規定します。基本的な考え方は、クレデンシャルはユーザーに属し、管理するのは WebAuthn 認証器であり、WebAuthn リライングパーティはクライアントプラットフォームを介してこれと対話するというものです。リライングパーティのスクリプトは（ユーザーの同意を得て）将来リライングパーティが使用する新しいクレデンシャルを作成するようブラウザーに要求できます。以下の図を参照してください。

スクリプトは、既存のクレデンシャルを使用して認証操作を実行するためのユーザーの許可を要求することもできます。以下の図を参照してください。

このような操作はすべて認証器内で実行され、ユーザーに代わってクライアントプラットフォームによって仲介されます。スクリプトがクレデンシャル自体にアクセスできることは一切なく、オブジェクトの形式でクレデンシャルに関する情報を取得するだけです。

上記のスクリプトインターフェイスに加えて、認証器は管理用のユーザーインターフェイスを実装してもよく（または、それを実装するクライアントソフトウェアを伴ってもよく）、そのようなインターフェイスは、たとえば認証器を初期状態にリセットしたり、認証器の現在の状態を確認したりするために使用してもよいものとします。言い換えると、そのようなインターフェイスは、履歴、保存されたパスワード、Cookie などのユーザー状態を管理するためにブラウザーが提供するユーザーインターフェイスに似ています。クレデンシャルの削除などの認証器管理操作は、そのようなユーザーインターフェイスの責任であると見なされ、スクリプトに公開される API からは意図的に除外されています。

この API のセキュリティ特性は、クライアントと認証器が連携することによって提供されます。クレデンシャルを保持し、管理する認証器は、すべての操作が特定のオリジンにスコープ設定され、異なるオリジンに対して再利用できないことを、そのレスポンスにオリジンを組み込むことによって保証します。具体的には、§ 6.3 認証器操作で定義されているとおり、リクエスト元の完全なオリジンが、新しいクレデンシャルの作成時に生成されるアテステーションオブジェクト、および WebAuthn クレデンシャルによって生成されるすべてのアサーションに含められ、署名対象となります。

さらに、ユーザーのプライバシーを維持し、悪意のあるリライングパーティが他のリライングパーティに属する公開鍵クレデンシャルの存在を探査できないようにするため、各クレデンシャルにはリライングパーティ識別子、すなわち RP ID へのスコープも設定されます。このRP IDは、すべての操作についてクライアントから認証器へ提供され、認証器は、あるリライングパーティによって作成されたクレデンシャルが、同じRP IDによって要求された操作でのみ使用できることを保証します。このようにオリジンとRP IDを分離することにより、単一のリライングパーティが複数のオリジンを維持する場合にも API を使用できます。

クライアントは、各操作についてリライングパーティのオリジンおよびRP IDを認証器に提供することで、これらのセキュリティ対策を支援します。これは WebAuthn セキュリティモデルの不可欠な部分であるため、ユーザーエージェントはこの API をセキュアコンテキスト内の呼び出し元にのみ公開します。特に Web コンテキストについては、エラーなしで確立された安全なトランスポート（例: TLS）を介してアクセスされるもののみが含まれます。

Web Authentication API は、以下のセクションで示される Web IDL 断片の和集合によって定義されます。結合された IDL の一覧はIDL 索引に示されています。

5.1. `PublicKeyCredential` インターフェイス

PublicKeyCredential

現在のすべてのエンジンで利用できます。

Firefox60+Safari13+Chrome67+

OperaなしEdge79+

Edge (Legacy)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 (Legacy)18IEなし

Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung InternetなしOpera Mobileなし

PublicKeyCredential/rawId

現在のすべてのエンジンで利用できます。

Firefox60+Safari13+Chrome67+

OperaなしEdge79+

Edge (Legacy)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 は Credential の getter を上書きし、代わりにオブジェクトの [[identifier]] 内部スロットに含まれるデータのbase64url エンコーディングを返します。

rawId

この属性は [[identifier]] 内部スロットに含まれる ArrayBuffer を返します。

PublicKeyCredential/response 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ OperaなしEdge79+ Edge (Legacy)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]] の値を返します。これは、拡張のクライアント拡張処理によって生成された拡張識別子 → クライアント拡張出力のエントリを含むマップです。

[[type]]

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

注: これは Credential から継承された type 属性 getter を介して反映されます。

[[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 API での AbortController および AbortSignal オブジェクトの使用を参照してください。

この内部メソッドは 3 つの引数を受け入れます。

origin

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

options

この引数は CredentialCreationOptions オブジェクトであり、その options.publicKey メンバーには、作成予定の公開鍵クレデンシャルに望まれる属性を指定する PublicKeyCredentialCreationOptions オブジェクトが含まれます。

sameOriginWithAncestors

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

注: この内部メソッドの呼び出しは、 [CREDENTIAL-MANAGEMENT-1] レベルで評価されるPermissions Policyによって許可されたことを示します。 § 5.9 Permissions Policy との統合を参照してください。

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

注: このアルゴリズムで使用されるすべての BufferSource オブジェクトは、潜在的な同期の問題を回避するため、アルゴリズムの開始時にスナップショットを取得しなければなりません。アルゴリズムの実装は、バッファーソースが保持するバイトのコピーを取得し、アルゴリズムの関連部分でそのコピーを使用すべきです。

このメソッドが呼び出された場合、ユーザーエージェントは次のアルゴリズムを実行しなければなりません。

表明: options.publicKey が存在する。
sameOriginWithAncestors が false の場合、"NotAllowedError" DOMException を返します。

注: この "sameOriginWithAncestors" 制限は、 Issue #1336 で提起されたトラッキングに関する懸念に対処することを目的としています。この仕様の将来のバージョンで改訂される可能性があります。
options を options.publicKey の値とします。
options の timeout メンバーが存在する場合、その値がクライアントによって定義された妥当な範囲内にあるか確認し、範囲外であればその範囲内で最も近い値に補正します。タイマー lifetimeTimer をこの補正後の値に設定します。options の timeout メンバーが存在しない場合は、lifetimeTimer をクライアント固有のデフォルト値に設定します。

options の timeout メンバーについて推奨される範囲およびデフォルト値は次のとおりです。 options.authenticatorSelection.userVerification が

discouraged に設定されている

推奨範囲: 30000 ミリ秒から 180000 ミリ秒。

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

required または preferred に設定されている

推奨範囲: 30000 ミリ秒から 600000 ミリ秒。

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

注: ユーザーエージェントは、特別なニーズを持つユーザーのタイムアウトについて、認知に関するガイドラインを考慮すべきです。
options.user.id の長さが 1 バイト以上 64 バイト以下でない場合、TypeError を返します。
callerOrigin を origin とします。 callerOrigin が不透明なオリジンである場合、名前が "NotAllowedError" である DOMException を返し、このアルゴリズムを終了します。
effectiveDomain を callerOrigin の実効ドメインとします。実効ドメインが有効なドメインでない場合、名前が "SecurityError" である DOMException を返し、このアルゴリズムを終了します。

注: 実効ドメインはホストへ解決される場合があり、それはドメイン、IPv4 アドレス、 IPv6 アドレス、不透明なホスト、または空のホストなど、さまざまな形で表現できます。ここでは、ホストのドメイン形式のみが許可されます。これは簡略化のためであり、また PKI ベースのセキュリティと組み合わせて直接 IP アドレス識別を使用することに関するさまざまな問題を考慮したものでもあります。
options.rp.id が

存在する

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

存在しない

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

注: options.rp.id は呼び出し元の RP IDを表します。RP IDのデフォルトは呼び出し元のオリジンの実効ドメインですが、呼び出し元が create() を呼び出す際に options.rp.id を明示的に設定した場合はその限りではありません。
credTypesAndPubKeyAlgs を新しいリストとし、その項目は PublicKeyCredentialType と COSEAlgorithmIdentifier のペアとします。
options.pubKeyCredParams のサイズが
ゼロである
次の PublicKeyCredentialType と COSEAlgorithmIdentifier の値のペアを credTypesAndPubKeyAlgs に追加します。
- public-key と -7 ("ES256")。
- public-key と -257 ("RS256")。
ゼロではない
options.pubKeyCredParams の各 current について反復します。
1. current.type がこの実装でサポートされる PublicKeyCredentialType を含まない場合は、続行します。
2. alg を current.alg とします。
3. current.type と alg のペアを credTypesAndPubKeyAlgs に追加します。
credTypesAndPubKeyAlgs が空である場合、名前が "NotSupportedError" である DOMException を返し、このアルゴリズムを終了します。
clientExtensions を新しいマップとし、 authenticatorExtensions を新しいマップとします。
options の extensions メンバーが存在する場合、 options.extensions の各 extensionId → clientExtensionInput について反復します。
1. extensionId がこのクライアントプラットフォームでサポートされていないか、登録拡張ではない場合は、続行します。
2. clientExtensions[extensionId] を clientExtensionInput に設定します。
3. extensionId が認証器拡張でない場合は、続行します。
4. authenticatorExtensionInput を、extensionId のクライアント拡張処理アルゴリズムを clientExtensionInput に対して実行した（CBOR）結果とします。アルゴリズムがエラーを返した場合は、続行します。
5. authenticatorExtensions[extensionId] を authenticatorExtensionInput のbase64url エンコーディングに設定します。
collectedClientData を、フィールドが次のとおりである新しい CollectedClientData インスタンスとします。

type

文字列 "webauthn.create"。

challenge

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

origin

callerOrigin のシリアル化。

crossOrigin

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

tokenBinding

クライアントと callerOrigin の間のToken Binding の状態、および利用可能であれば callerOrigin に関連付けられたToken Binding ID。
clientDataJSON を、collectedClientData から構築されたクライアントデータの JSON 互換シリアル化とします。
clientDataHash を、clientDataJSON によって表されるシリアル化されたクライアントデータのハッシュとします。
options.signal が存在し、そのaborted フラグが true に設定されている場合、名前が "AbortError" である DOMException を返し、このアルゴリズムを終了します。
issuedRequests を新しい順序付き集合とします。
authenticators は、任意の時点で集合である値を表すものとし、その各項目は、その時点でこのクライアントプラットフォーム上で現在利用可能な認証器を識別する、クライアントプラットフォーム固有のハンドルです。

注: 何をもって認証器を「利用可能」とするかは意図的に規定されていません。これは、認証器がさまざまな仕組みによってクライアントへ（例: USB 経由で）ホットプラグされたり、（例: NFC や Bluetooth 経由で）検出されたり、またはクライアントに恒久的に組み込まれたりすることを表すためのものです。
lifetimeTimer を開始します。
lifetimeTimer が期限切れになるまで、lifetimeTimer、および authenticators 内の各 authenticator の状態とレスポンスに応じて、次の処理を繰り返します。
lifetimeTimer が期限切れになった場合、

issuedRequests 内の各 authenticator について、反復し、authenticator に対してauthenticatorCancel 操作を呼び出し、 issuedRequests から authenticator を削除します。

ユーザーが、処理をキャンセルするためのユーザーエージェントのユーザーインターフェイスオプションを実行した場合、

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

options.signal が存在し、そのaborted フラグが true に設定されている場合、

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

authenticator がこのクライアントデバイス上で利用可能になった場合、
注: これには、 lifetimeTimer の開始時点ですでに authenticator が利用可能だった場合も含まれます。
1. この authenticator を候補認証器とします。
2. options.authenticatorSelection が存在する場合:
  1. options.authenticatorSelection.authenticatorAttachment が存在し、その値が authenticator の認証器アタッチメント方式と等しくない場合は、続行します。
  2. options.authenticatorSelection.residentKey が
    
    存在し、required に設定されている
    
    authenticator がクライアント側で検出可能な公開鍵クレデンシャルソースを保存できない場合は、続行します。
    
    存在し、preferred または discouraged に設定されている
    
    影響なし。
    
    存在しない
    
    options.authenticatorSelection.requireResidentKey が true に設定され、かつ authenticator がクライアント側で検出可能な公開鍵クレデンシャルソースを保存できない場合は、続行します。
  3. options.authenticatorSelection.userVerification が required に設定され、かつ authenticator がユーザー検証を実行できない場合は、続行します。
3. requireResidentKey を、次のように定義される 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 に設定されている
  
  ユーザーエージェントが options.rp.id についてエンタープライズアテステーションをサポートすることを希望する場合（上のステップ 8を参照）、 enterpriseAttestationPossible を true とします。それ以外の場合は false です。
  
  それ以外
  
  enterpriseAttestationPossible を false とします。
6. excludeCredentialDescriptorList を新しいリストとします。
7. options.excludeCredentials 内の各クレデンシャル記述子 C について反復します。
  1. C.transports が空ではなく、 authenticator が C.transports に記載されていないトランスポート経由で接続されている場合、クライアントは続行してもよいものとします。
    
    注: クライアントが続行することを選択した場合、 C.transports 内のトランスポートヒントが正確でなければ、同じ認証器にバインドされた複数のクレデンシャルを誤って登録する可能性があります。たとえば、ソフトウェアアップグレードによって新しい接続オプションが追加された結果、保存済みのトランスポートヒントが不正確になる場合があります。
  2. それ以外の場合、C を excludeCredentialDescriptorList に追加します。
  3. authenticator に対してauthenticatorMakeCredential 操作を呼び出し、clientDataHash、 options.rp、 options.user、 requireResidentKey、userVerification、 credTypesAndPubKeyAlgs、 excludeCredentialDescriptorList、 enterpriseAttestationPossible、および authenticatorExtensions をパラメーターとして渡します。
8. authenticator を issuedRequests に追加します。
authenticator がこのクライアントデバイス上で利用できなくなった場合、

authenticator を issuedRequests から削除します。

いずれかの authenticator が、ユーザーが操作をキャンセルしたことを示すステータスを返した場合、
1. authenticator を issuedRequests から削除します。
2. issuedRequests 内の残りの各 authenticator について反復し、authenticator に対してauthenticatorCancel 操作を呼び出し、 issuedRequests からそれを削除します。
  
  注: 認証器は、「ユーザーが操作全体をキャンセルした」ことを示す情報を返す場合があります。ユーザーエージェントがこの状態をユーザーにどのように示すかは規定されていません。
いずれかの authenticator が "InvalidStateError" と同等のエラーステータスを返した場合、
1. authenticator を issuedRequests から削除します。
2. issuedRequests 内の残りの各 authenticator について反復し、authenticator に対してauthenticatorCancel 操作を呼び出し、 issuedRequests からそれを削除します。
3. 名前が "InvalidStateError" である DOMException を返し、このアルゴリズムを終了します。
注: このエラーステータスは、 excludeCredentialDescriptorList が authenticator にバインドされたクレデンシャルを識別し、かつユーザーが操作に同意した場合にのみ authenticator が返すため、別個に処理されます。この明示的な同意があるため、このケースをリライングパーティが区別できることは許容されます。
いずれかの authenticator が "InvalidStateError" と同等ではないエラーステータスを返した場合、

authenticator を issuedRequests から削除します。

注: このケースは、操作についてユーザーの同意があったことを意味しないため、潜在的な識別情報の漏洩を防ぐため、エラーの詳細はリライングパーティから隠されます。詳細は § 14.5.1 登録セレモニーのプライバシーを参照してください。

いずれかの authenticator が成功を示した場合、
1. authenticator を issuedRequests から削除します。この認証器を選択された認証器とします。
2. credentialCreationData を、構造体とし、その項目は次のとおりとします。
  
  attestationObjectResult
  
  その値は、成功したauthenticatorMakeCredential 操作から返されたバイトです。
  
  注: この値は、§ 6.5.4 アテステーションオブジェクトの生成で定義される attObj です。
  
  clientDataJSONResult
  
  その値は clientDataJSON のバイトです。
  
  attestationConveyancePreferenceOption
  
  その値は options.attestation の値です。
  
  clientExtensionResults
  
  その値は、拡張識別子 → クライアント拡張出力のエントリを含む AuthenticationExtensionsClientOutputs オブジェクトです。エントリは、 options.extensions 内の各クライアント拡張について、各拡張のクライアント拡張処理アルゴリズムを実行してクライアント拡張出力を作成することにより生成されます。
3. constructCredentialAlg を、グローバルオブジェクト global を受け取るアルゴリズムとし、その手順を次のとおりとします。
  1. credentialCreationData.attestationConveyancePreferenceOption の値が
    
    "none"
    
    一意に識別できる可能性のある情報を、同じ情報の識別不能なバージョンに置き換えます。
    
    アテステーション済みクレデンシャルデータ内のAAGUIDが 16 個のゼロバイトで、 credentialCreationData.attestationObjectResult.fmt が "packed" であり、かつ credentialCreationData.attestationObjectResult に "x5c" が存在しない場合、自己アテステーションが使用されており、これ以上の処理は必要ありません。
    
    それ以外の場合
    
    アテステーション済みクレデンシャルデータ内のAAGUIDを 16 個のゼロバイトに置き換えます。
    
    credentialCreationData.attestationObjectResult.fmt の値を "none" に設定し、 credentialCreationData.attestationObjectResult.attStmt の値を空のCBOR マップに設定します。（§ 8.7 None アテステーションステートメント形式および§ 6.5.4 アテステーションオブジェクトの生成を参照）。
    
    "indirect"
    
    クライアントは、AAGUIDおよびアテステーションステートメントを、同じデータのよりプライバシーに配慮したおよび/またはより検証しやすいバージョンに置き換えてもよいものとします（たとえば、匿名化 CAを使用することによって）。
    
    "direct" または "enterprise"
    
    認証器のAAGUIDおよびアテステーションステートメントを変更せずにリライングパーティへ伝達します。
  2. attestationObject を、新しい ArrayBuffer とし、global の%ArrayBuffer%を使用して作成し、 credentialCreationData.attestationObjectResult の値のバイトを含めます。
  3. id を attestationObject.authData.attestedCredentialData.credentialId とします。
  4. pubKeyCred を、global に関連付けられた新しい PublicKeyCredential オブジェクトとし、そのフィールドを次のとおりとします。
    
    [[identifier]]
    
    id
    
    response
    
    global に関連付けられた新しい AuthenticatorAttestationResponse オブジェクトであり、そのフィールドは次のとおりです。
    
    clientDataJSON
    
    global の%ArrayBuffer%を使用して作成された新しい ArrayBufferであり、 credentialCreationData.clientDataJSONResult のバイトを含みます。
    
    attestationObject
    
    attestationObject
    
    [[transports]]
    
    authenticator がサポートしていると考えられる、辞書順に並べられた 0 個以上の一意な DOMString のシーケンス。値は AuthenticatorTransport のメンバーであるべきですが、クライアントプラットフォームは未知の値を無視しなければなりません。
    
    ユーザーエージェントがこの情報を開示したくない場合、プライバシーを保護するよう設計された任意のシーケンスに置き換えてもよいものとします。このシーケンスも依然として有効でなければならず、すなわち辞書順にソートされ、重複があってはなりません。たとえば、空のシーケンスを使用できます。いずれの場合も、このケースではユーザーエージェントはリライングパーティの動作が最適でなくなる可能性を引き受けます。
    
    ユーザーエージェントがトランスポート情報を持たない場合、このフィールドを空のシーケンスに設定すべきです。
    
    注: ユーザーエージェントが特定の認証器によってサポートされるトランスポートをどのように検出するかはこの仕様の範囲外ですが、アテステーション証明書からの情報（たとえば [FIDO-Transports-Ext]）、 CTAP2 などの認証器プロトコルで伝達されるメタデータ、またはプラットフォーム認証器に関する特別な知識が含まれる場合があります。
    
    [[clientExtensionsResults]]
    
    global の%ArrayBuffer%を使用して作成された新しい ArrayBufferであり、 credentialCreationData.clientExtensionResults のバイトを含みます。
  5. pubKeyCred を返します。
4. issuedRequests 内の残りの各 authenticator について反復し、authenticator に対してauthenticatorCancel 操作を呼び出し、 issuedRequests からそれを削除します。
5. constructCredentialAlg を返し、このアルゴリズムを終了します。
名前が "NotAllowedError" である DOMException を返します。同意なしにユーザーを識別し得る情報の漏洩を防ぐため、このステップは lifetimeTimer が期限切れになる前に実行してはなりません。詳細は § 14.5.1 登録セレモニーのプライバシーを参照してください。

上記の処理中、ユーザーエージェントは、認証器を選択して認可するプロセスをユーザーに案内するため、何らかの UI を表示すべきです。

5.1.4. 既存のクレデンシャルを使用したアサーションの作成 - PublicKeyCredential の `[[Get]](options)` メソッド

WebAuthn リライングパーティは、 navigator.credentials.get({publicKey:..., ...}) を呼び出して、ユーザーの同意を得たうえで、既存の公開鍵クレデンシャルを検出して使用します。リライングパーティのスクリプトは、任意でいくつかの基準を指定し、どのクレデンシャルソースを受け入れ可能とするかを示します。クライアントプラットフォームは、指定された基準に一致するクレデンシャルソースを特定し、スクリプトが使用を許可されるものをユーザーが選択できるよう案内します。たとえばプライバシーを維持するため、クレデンシャルソースが存在する場合でも、ユーザーは対話全体を拒否することを選択できます。ユーザーがクレデンシャルソースを選択すると、ユーザーエージェントは § 6.3.3 authenticatorGetAssertion 操作を使用して、リライングパーティから提供されたチャレンジおよびその他の収集データに署名してアサーションを作成し、そのアサーションはクレデンシャルとして使用されます。

get() の実装 [CREDENTIAL-MANAGEMENT-1] は、 PublicKeyCredential.[[CollectFromCredentialStore]]() を呼び出して、ユーザーの介在なしで利用可能であるべきクレデンシャル（大まかには、この仕様における認可ジェスチャー）を収集し、それらをちょうど 1 つ見つけられなかった場合は、 PublicKeyCredential.[[DiscoverFromExternalSource]]() を呼び出して、ユーザーにクレデンシャルソースを選択させます。

この仕様では、いかなるクレデンシャルを作成する場合にも認可ジェスチャーが必要とされるため、 PublicKeyCredential.[[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) 内部メソッドは、空の集合を返す Credential.[[CollectFromCredentialStore]]() のデフォルト動作を継承します。

この navigator.credentials.get() 操作は AbortController を利用して中止できます。詳細な手順については、DOM §3.3 API での AbortController および AbortSignal オブジェクトの使用を参照してください。

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

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

origin

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

options

この引数は CredentialRequestOptions オブジェクトであり、その options.publicKey メンバーには、検出する公開鍵クレデンシャルの望ましい属性を指定する PublicKeyCredentialRequestOptions オブジェクトが含まれます。

sameOriginWithAncestors

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

このメソッドが呼び出された場合、ユーザーエージェントは次のアルゴリズムを実行しなければなりません。

表明: options.publicKey が存在する。
options を options.publicKey の値とします。
options の timeout メンバーが存在する場合、その値がクライアントによって定義された妥当な範囲内にあるか確認し、範囲外であればその範囲内で最も近い値に補正します。タイマー lifetimeTimer をこの補正後の値に設定します。options の timeout メンバーが存在しない場合は、lifetimeTimer をクライアント固有のデフォルト値に設定します。

options の timeout メンバーについて推奨される範囲およびデフォルト値は次のとおりです。 options.userVerification が

discouraged に設定されている

推奨範囲: 30000 ミリ秒から 180000 ミリ秒。

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

required または preferred に設定されている

推奨範囲: 30000 ミリ秒から 600000 ミリ秒。

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

注: ユーザーエージェントは、特別なニーズを持つユーザーのタイムアウトについて、認知に関するガイドラインを考慮すべきです。
callerOrigin を origin とします。 callerOrigin が不透明なオリジンである場合、名前が "NotAllowedError" である DOMException を返し、このアルゴリズムを終了します。
effectiveDomain を callerOrigin の実効ドメインとします。実効ドメインが有効なドメインでない場合、名前が "SecurityError" である DOMException を返し、このアルゴリズムを終了します。

注: 実効ドメインはホストへ解決される場合があり、それはドメイン、IPv4 アドレス、IPv6 アドレス、不透明なホスト、または空のホストなど、さまざまな形で表現できます。ここでは、ホストのドメイン形式のみが許可されます。これは簡略化のためであり、また PKI ベースのセキュリティと組み合わせて直接 IP アドレス識別を使用することに関するさまざまな問題を考慮したものでもあります。
options.rpId が存在しない場合、rpId を effectiveDomain に設定します。
それ以外の場合:
1. options.rpId が effectiveDomain の登録可能なドメインサフィックスでもなく、等しくもない場合、名前が "SecurityError" である DOMException を返し、このアルゴリズムを終了します。
2. rpId を options.rpId に設定します。
  
  注: rpId は呼び出し元のRP IDを表します。RP IDのデフォルトは、呼び出し元のオリジンの実効ドメインですが、呼び出し元が get() を呼び出す際に options.rpId を明示的に設定した場合はその限りではありません。
clientExtensions を新しいマップとし、 authenticatorExtensions を新しいマップとします。
options の extensions メンバーが存在する場合、 options.extensions の各 extensionId → clientExtensionInput について反復します。
1. extensionId がこのクライアントプラットフォームでサポートされていないか、認証拡張ではない場合は、続行します。
2. clientExtensions[extensionId] を clientExtensionInput に設定します。
3. extensionId が認証器拡張ではない場合は、続行します。
4. authenticatorExtensionInput を、extensionId のクライアント拡張処理アルゴリズムを clientExtensionInput に対して実行した（CBOR）結果とします。アルゴリズムがエラーを返した場合は、続行します。
5. authenticatorExtensions[extensionId] を authenticatorExtensionInput のbase64url エンコーディングに設定します。
collectedClientData を、フィールドが次のとおりである新しい CollectedClientData インスタンスとします。

type

文字列 "webauthn.get"。

challenge

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

origin

callerOrigin のシリアル化。

crossOrigin

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

tokenBinding

クライアントと callerOrigin の間のToken Binding の状態、および利用可能であれば callerOrigin に関連付けられたToken Binding ID。
clientDataJSON を、collectedClientData から構築されたクライアントデータの JSON 互換シリアル化とします。
clientDataHash を、clientDataJSON によって表されるシリアル化されたクライアントデータのハッシュとします。
options.signal が存在し、そのaborted フラグが true に設定されている場合、名前が "AbortError" である DOMException を返し、このアルゴリズムを終了します。
issuedRequests を新しい順序付き集合とします。
savedCredentialIds を新しいマップとします。
authenticators は、任意の時点で集合である値を表すものとし、その各項目は、その時点でこのクライアントプラットフォーム上で現在利用可能な認証器を識別する、クライアントプラットフォーム固有のハンドルです。

注: 何をもって認証器を「利用可能」とするかは意図的に規定されていません。これは、認証器がさまざまな仕組みによってクライアントへ（例: USB 経由で）ホットプラグされたり、（例: NFC や Bluetooth 経由で）検出されたり、またはクライアントに恒久的に組み込まれたりすることを表すためのものです。
lifetimeTimer を開始します。
lifetimeTimer が期限切れになるまで、lifetimeTimer、および authenticators 内の各 authenticator の状態とレスポンスに応じて、次の処理を繰り返します。
lifetimeTimer が期限切れになった場合、

issuedRequests 内の各 authenticator について反復し、authenticator に対してauthenticatorCancel 操作を呼び出し、 issuedRequests から authenticator を削除します。

ユーザーが、処理をキャンセルするためのユーザーエージェントのユーザーインターフェイスオプションを実行した場合、

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

signal メンバーが存在し、aborted フラグが true に設定されている場合、

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

issuedRequests が空であり、 options.allowCredentials が空ではなく、かつその中のいずれの公開鍵クレデンシャルについても利用可能になる authenticator がない場合、

適格なクレデンシャルが見つからなかったことをユーザーに示します。ユーザーがダイアログを確認したら、名前が "NotAllowedError" である DOMException を返します。

注: クライアントプラットフォームが authenticator が利用可能にならないことを判断する方法の 1 つは、 options.allowCredentials に現在存在する PublicKeyCredentialDescriptor 項目の transports メンバーがある場合、それを調べることです。たとえば、すべての PublicKeyCredentialDescriptor 項目が internal のみを列挙しており、すべてのプラットフォーム authenticatorが試行済みである場合、リクエストを満たす可能性はありません。あるいは、すべての PublicKeyCredentialDescriptor 項目が、クライアントプラットフォームでサポートされていない transports を列挙している場合もあります。

authenticator がこのクライアントデバイス上で利用可能になった場合、
注: これには、 lifetimeTimer の開始時点ですでに authenticator が利用可能だった場合も含まれます。
1. options.userVerification が required に設定され、かつ authenticator がユーザー検証を実行できない場合は、続行します。
2. userVerification を、次のように定義される Boolean 値であるアサーションにおける実効ユーザー検証要件とします。 options.userVerification が
  
  required に設定されている
  
  userVerification を true とします。
  
  preferred に設定されている
  
  authenticator が
  
  ユーザー検証を実行できる
  
  userVerification を true とします。
  
  ユーザー検証を実行できない
  
  userVerification を false とします。
  
  discouraged に設定されている
  
  userVerification を false とします。
3. options.allowCredentials が
  空ではない
  
  allowCredentialDescriptorList を新しいリストとします。
  
  options.allowCredentials で記述されている公開鍵クレデンシャルのうち、どれがこの authenticator にバインドされているかを判断するため、 rpId、 options.allowCredentials.id、および options.allowCredentials.type を照合する、クライアントプラットフォーム固有の手順を実行します。 allowCredentialDescriptorList を、このフィルタリングされたリストに設定します。
  
  allowCredentialDescriptorList が空である場合は、続行します。
  
  distinctTransports を新しい順序付き集合とします。
  
  allowCredentialDescriptorList がちょうど 1 つの値を持つ場合、 savedCredentialIds[authenticator] を allowCredentialDescriptorList[0].id の値に設定します（詳細については、§ 6.3.3 authenticatorGetAssertion 操作のこちらを参照してください）。
  
  allowCredentialDescriptorList 内の各クレデンシャル記述子 C について反復し、 C.transports の各値が存在する場合、それぞれを distinctTransports に追加します。
  
  注: 順序付き集合の性質により、 distinctTransports には、この認証器に関する transports の異なる値のみが集約されます。
  
  distinctTransports が
  
  空ではない
  
  クライアントは distinctTransports から 1 つの transport 値を選択します。その際、 authenticator で使用する適切なトランスポートに関するローカル構成の知識を選択に組み込む場合があります。
  
  次に、transport を使用して、 authenticator に対してauthenticatorGetAssertion 操作を呼び出し、rpId、clientDataHash、 allowCredentialDescriptorList、 userVerification、および authenticatorExtensions をパラメーターとして渡します。
  
  空である
  
  authenticator で使用する適切なトランスポートに関するローカル構成の知識を使用して、 authenticator に対してauthenticatorGetAssertion 操作を呼び出し、rpId、clientDataHash、 allowCredentialDescriptorList、 userVerification、および authenticatorExtensions をパラメーターとして渡します。
  
  空である
  
  authenticator で使用する適切なトランスポートに関するローカル構成の知識を使用して、authenticator に対してauthenticatorGetAssertion 操作を呼び出し、rpId、 clientDataHash、userVerification、および authenticatorExtensions をパラメーターとして渡します。
  
  注: この場合、リライングパーティは受け入れ可能なクレデンシャル記述子のリストを提供していません。したがって、認証器には、rpId によって識別されるリライングパーティにスコープ設定された、自身が保持する任意のクレデンシャルを使用するよう求めています。
4. authenticator を issuedRequests に追加します。
authenticator がこのクライアントデバイス上で利用できなくなった場合、

authenticator を issuedRequests から削除します。

いずれかの authenticator が、ユーザーが操作をキャンセルしたことを示すステータスを返した場合、
1. authenticator を issuedRequests から削除します。
2. issuedRequests 内の残りの各 authenticator について反復し、authenticator に対してauthenticatorCancel 操作を呼び出し、issuedRequests からそれを削除します。
  
  注: 認証器は、「ユーザーが操作全体をキャンセルした」ことを示す情報を返す場合があります。ユーザーエージェントがこの状態をユーザーにどのように示すかは規定されていません。
いずれかの authenticator がエラーステータスを返した場合、

authenticator を issuedRequests から削除します。

いずれかの authenticator が成功を示した場合、
1. authenticator を issuedRequests から削除します。
2. assertionCreationData を構造体とし、その項目は次のとおりとします。
  
  credentialIdResult
  
  savedCredentialIds[authenticator] が存在する場合、credentialIdResult の値を savedCredentialIds[authenticator] のバイトに設定します。それ以外の場合、credentialIdResult の値を、§ 6.3.3 authenticatorGetAssertion 操作で定義されている、成功したauthenticatorGetAssertion 操作から返されたクレデンシャル IDのバイトに設定します。
  
  clientDataJSONResult
  
  その値は clientDataJSON のバイトです。
  
  authenticatorDataResult
  
  その値は、認証器によって返された認証器データのバイトです。
  
  signatureResult
  
  その値は、認証器によって返された署名値のバイトです。
  
  userHandleResult
  
  認証器がユーザーハンドルを返した場合、userHandleResult の値を、返されたユーザーハンドルのバイトに設定します。それ以外の場合、userHandleResult の値を null に設定します。
  
  clientExtensionResults
  
  その値は、拡張識別子 → クライアント拡張出力のエントリを含む AuthenticationExtensionsClientOutputs オブジェクトです。エントリは、 options.extensions 内の各クライアント拡張について、各拡張のクライアント拡張処理アルゴリズムを実行してクライアント拡張出力を作成することにより生成されます。
3. constructAssertionAlg を、グローバルオブジェクト global を受け取るアルゴリズムとし、その手順を次のとおりとします。
  1. pubKeyCred を、global に関連付けられた新しい PublicKeyCredential オブジェクトとし、そのフィールドを次のとおりとします。
    
    [[identifier]]
    
    global の%ArrayBuffer%を使用して作成された新しい ArrayBufferであり、 assertionCreationData.credentialIdResult のバイトを含みます。
    
    response
    
    global に関連付けられた新しい AuthenticatorAssertionResponse オブジェクトであり、そのフィールドは次のとおりです。
    
    clientDataJSON
    
    global の%ArrayBuffer%を使用して作成された新しい ArrayBufferであり、 assertionCreationData.clientDataJSONResult のバイトを含みます。
    
    authenticatorData
    
    global の%ArrayBuffer%を使用して作成された新しい ArrayBufferであり、 assertionCreationData.authenticatorDataResult のバイトを含みます。
    
    signature
    
    global の%ArrayBuffer%を使用して作成された新しい ArrayBufferであり、 assertionCreationData.signatureResult のバイトを含みます。
    
    userHandle
    
    assertionCreationData.userHandleResult が null の場合、このフィールドを null に設定します。それ以外の場合、このフィールドを、global の%ArrayBuffer%を使用して作成された新しい ArrayBuffer に設定し、 assertionCreationData.userHandleResult のバイトを含めます。
    
    [[clientExtensionsResults]]
    
    global の%ArrayBuffer%を使用して作成された新しい ArrayBufferであり、 assertionCreationData.clientExtensionResults のバイトを含みます。
  2. pubKeyCred を返します。
4. issuedRequests 内の残りの各 authenticator について反復し、authenticator に対してauthenticatorCancel 操作を呼び出し、issuedRequests からそれを削除します。
5. constructAssertionAlg を返し、このアルゴリズムを終了します。
名前が "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 です。

このメソッドが呼び出された場合、ユーザーエージェントは次のアルゴリズムを実行しなければなりません。

名前が "NotSupportedError" である DOMException を返し、このアルゴリズムを終了します

5.1.6. 既存のクレデンシャルへのサイレントアクセスの防止 - PublicKeyCredential の `[[preventSilentAccess]](credential, sameOriginWithAncestors)` メソッド

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

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

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

WebAuthn リライングパーティは、このメソッドを使用して、ユーザー検証プラットフォーム認証器を使用して新しいクレデンシャルを作成できるかどうかを判断します。呼び出されると、クライアントは、クライアントプラットフォーム固有の手順を使用して、利用可能なユーザー検証プラットフォーム認証器を検出します。いずれかが検出された場合、Promise は true の値で解決されます。それ以外の場合、Promise は false の値で解決されます。その結果に基づいて、リライングパーティは、ユーザーがクレデンシャルを作成できるよう案内するためのさらなる処理を行うことができます。

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

PublicKeyCredential/isUserVerifyingPlatformAuthenticatorAvailable

現在のすべてのエンジンで利用できます。

Firefox60+Safari13+Chrome67+

OperaなしEdge79+

Edge (Legacy)18IEなし

Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung InternetなしOpera Mobileなし

partial interface PublicKeyCredential {
    static Promise<boolean> isUserVerifyingPlatformAuthenticatorAvailable();
};

注: Web Authentication API が、使用を許可されているアルゴリズム、すなわちPermissions Policyによって「無効化」されている閲覧コンテキストからこのメソッドを呼び出すと、Promise は名前が "NotAllowedError" である DOMException で拒否されます。 § 5.9 Permissions Policy との統合も参照してください。

5.2. 認証器レスポンス (インターフェイス `AuthenticatorResponse`)

AuthenticatorResponse

現在のすべてのエンジンで利用できます。

Firefox60+Safari13+Chrome67+

OperaなしEdge79+

Edge (Legacy)18IEなし

Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung InternetなしOpera Mobileなし

認証器は、リライングパーティからの要求に対して、 AuthenticatorResponse インターフェイスから派生したオブジェクトを返すことで応答します。

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

AuthenticatorResponse/clientDataJSON 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ OperaなしEdge79+ Edge (Legacy)18IEなし Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung InternetなしOpera Mobileなし clientDataJSON, 型は ArrayBuffer、読み取り専用: この属性にはJSON 互換シリアル化されたクライアントデータが含まれ、そのハッシュは、クライアントが create() または get() を呼び出す際に認証器へ渡されます（すなわち、クライアントデータ自体は認証器へ送信されません）。

5.2.1. 公開鍵クレデンシャルに関する情報 (インターフェイス `AuthenticatorAttestationResponse`)

AuthenticatorAttestationResponse

現在のすべてのエンジンで利用できます。

Firefox60+Safari13+Chrome67+

OperaなしEdge79+

Edge (Legacy)18IEなし

Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet10.0+Opera Mobileなし

AuthenticatorAttestationResponse インターフェイスは、新しい公開鍵クレデンシャルの作成を求めるクライアントの要求に対する認証器のレスポンスを表します。このレスポンスには、後で使用する際に新しいクレデンシャルを識別するために使用できる情報と、登録時にクレデンシャルの特性を評価するためにWebAuthn リライングパーティが使用できるメタデータが含まれます。

AuthenticatorAttestationResponse/getTransports

現在のどのエンジンでも利用できません。

FirefoxなしSafariなしChromeなし

OperaなしEdgeなし

Edge (Legacy)なしIEなし

Firefox for AndroidなしiOS SafariなしChrome for AndroidなしAndroid WebViewなしSamsung InternetなしOpera Mobileなし

[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 シリアル化に対して計算されているため、その JSON シリアル化をそのまま保持しなければなりません。
AuthenticatorAttestationResponse/attestationObject 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ OperaなしEdge79+ Edge (Legacy)18IEなし Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet10.0+Opera Mobileなし attestationObject, 型は ArrayBuffer、読み取り専用: この属性には、クライアントにとって不透明であり、クライアントによる改ざんから暗号学的に保護されたアテステーションオブジェクトが含まれます。アテステーションオブジェクトには、認証器データとアテステーションステートメントの両方が含まれます。前者には AAGUID、一意なクレデンシャル ID、およびクレデンシャル公開鍵が含まれます。アテステーションステートメントの内容は、認証器が使用するアテステーションステートメント形式によって決まります。また、リライングパーティのサーバーがアテステーションステートメントを検証し、さらに認証器データをクライアントデータの 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 のメンバーであるべきですが、リライングパーティは未知の値を無視しなければなりません。

5.2.1.1. クレデンシャルデータへの容易なアクセス

[[Create]](origin, options, sameOriginWithAncestors) メソッドを使用するすべての利用者は、将来の認証アサーションを検証するため、返されたクレデンシャル公開鍵を解析して保存する必要があります。しかし、クレデンシャル公開鍵は、AuthenticatorAttestationResponse.attestationObject によって伝達されるアテステーションオブジェクト内の認証器データ内のattestedCredentialData 内のcredentialPublicKey メンバーに、[RFC8152] (COSE) 形式で格納されています。アテステーションを利用したいリライングパーティは、 attestationObject を解析してクレデンシャル公開鍵を取得する必要があります。なぜなら、その公開鍵のコピーが認証器によって署名されたものだからです。しかし、有効な WebAuthn のユースケースの多くはアテステーションを必要としません。そのような用途では、ユーザーエージェントが解析を行い、認証器データを直接公開し、クレデンシャル公開鍵をより便利な形式に変換できます。

したがって、getPublicKey() 操作はクレデンシャル公開鍵をSubjectPublicKeyInfo として返します。この ArrayBuffer は、たとえば Java の java.security.spec.X509EncodedKeySpec、.NET の System.Security.Cryptography.ECDsa.ImportSubjectPublicKeyInfo、または Go の crypto/x509.ParsePKIXPublicKey に渡すことができます。

getPublicKey() の使用にはいくつかの制限があります。pubKeyCredParams を使用することで、リライングパーティは、ユーザーエージェントが理解できない可能性のある公開鍵アルゴリズムを使用するよう認証器とネゴシエートできます。しかし、リライングパーティがそうした場合、ユーザーエージェントは結果として得られるクレデンシャル公開鍵をSubjectPublicKeyInfo 形式に変換できず、getPublicKey() の返り値は null になります。

クレデンシャル公開鍵の COSEAlgorithmIdentifier の値が次のいずれかである場合、ユーザーエージェントは getPublicKey() に対して null ではない値を返すことができなければなりません。

-7 (ES256)。kty は 2（非圧縮点）、crv は 1 (P-256)。
-257 (RS256)。
-8 (EdDSA)。crv は 6 (Ed25519)。

SubjectPublicKeyInfo には、COSE 公開鍵に含まれる署名アルゴリズムに関する情報（たとえば、どのハッシュ関数を使用するか）は含まれません。これを提供するため、 getPublicKeyAlgorithm() はクレデンシャル公開鍵の COSEAlgorithmIdentifier を返します。

多くの場合に CBOR をまったく解析する必要をなくすため、getAuthenticatorData() は attestationObject から認証器データを返します。認証器データには、バイナリ形式でエンコードされたその他のフィールドが含まれます。しかし、リライングパーティはアサーションを取得する際にすでにそれらのフィールドを抽出する必要があるため、それらへアクセスするためのヘルパー関数は提供されません。署名検証が任意であるクレデンシャル作成とは対照的に、リライングパーティはアサーションからの署名を常に検証すべきであり、そのため署名された認証器データからフィールドを抽出しなければなりません。そこで使用する同じ関数は、クレデンシャル作成時にも使用できます。

注: getPublicKey() および getAuthenticatorData() は、この仕様のレベル 2 で初めて追加されました。リライングパーティは、これらの関数を使用する前に 'getPublicKey' in AuthenticatorAttestationResponse.prototype の値をテストして機能検出を行うべきです。この関数の存在を必要とするリライングパーティは、古いユーザーエージェントと相互運用できない可能性があります。

5.2.2. Web Authentication アサーション (インターフェイス `AuthenticatorAssertionResponse`)

AuthenticatorAssertionResponse

現在のすべてのエンジンで利用できます。

Firefox60+Safari13+Chrome67+

OperaなしEdge79+

Edge (Legacy)18IEなし

Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung InternetなしOpera Mobileなし

AuthenticatorAssertionResponse インターフェイスは、WebAuthn リライングパーティのチャレンジおよび把握している任意のクレデンシャル一覧を与えたうえで、新しい認証アサーションを生成するというクライアントの要求に対する認証器のレスポンスを表します。このレスポンスには、クレデンシャル秘密鍵を所有していることを証明する暗号学的署名と、任意で特定のトランザクションに対するユーザーの同意の証拠が含まれます。

[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 署名で使用されるクライアントデータ (辞書 CollectedClientData)を参照）が含まれます。シリアル化されたクライアントデータのハッシュはこの正確な JSON シリアル化に対して計算されているため、その JSON シリアル化をそのまま保持しなければなりません。
AuthenticatorAssertionResponse/authenticatorData 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ OperaなしEdge79+ Edge (Legacy)18IEなし Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung InternetなしOpera Mobileなし authenticatorData, 型は ArrayBuffer、読み取り専用: この属性には、認証器によって返された認証器データが含まれます。§ 6.1 認証器データを参照してください。
AuthenticatorAssertionResponse/signature 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ OperaなしEdge79+ Edge (Legacy)18IEなし Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung InternetなしOpera Mobileなし signature, 型は ArrayBuffer、読み取り専用: この属性には、認証器から返された生の署名が含まれます。§ 6.3.3 authenticatorGetAssertion 操作を参照してください。
AuthenticatorAssertionResponse/userHandle 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ OperaなしEdge79+ Edge (Legacy)18IEなし Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung InternetなしOpera Mobileなし userHandle, 型は ArrayBuffer、読み取り専用、null 許容: この属性には、認証器から返されたユーザーハンドルが含まれ、認証器がユーザーハンドルを返さなかった場合は null になります。§ 6.3.3 authenticatorGetAssertion 操作を参照してください。

5.3. クレデンシャル生成用パラメーター (辞書 `PublicKeyCredentialParameters`)

dictionary PublicKeyCredentialParameters {
    required DOMString                    type;
    required COSEAlgorithmIdentifier      alg;
};

この辞書は、新しいクレデンシャルを作成するときに追加のパラメーターを指定するために使用されます。

type, 型は DOMString: このメンバーは、作成するクレデンシャルの種類を指定します。値は PublicKeyCredentialType のメンバーであるべきですが、クライアントプラットフォームは未知の値を無視し、未知の type を持つすべての PublicKeyCredentialParameters を無視しなければなりません。
alg, 型は COSEAlgorithmIdentifier: このメンバーは、新しく生成されたクレデンシャルで使用する暗号署名アルゴリズムを指定し、したがって生成する非対称キーペアの種類、たとえば RSA や楕円曲線も指定します。

注: 後者のメンバー名には "algorithm" と完全に記述するのではなく "alg" を使用します。これは、低帯域幅のリンクを介して送信される可能性のある認証器へのメッセージにシリアル化されるためです。

5.4. クレデンシャル作成用オプション (辞書 `PublicKeyCredentialCreationOptions`)

PublicKeyCredentialCreationOptions

現在のすべてのエンジンで利用できます。

Firefox60+Safari13+Chrome67+

Opera54+Edge79+

Edge (Legacy)なしIEなし

Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewなしSamsung InternetなしOpera 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)なしIEなし Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewなしSamsung InternetなしOpera Mobile48+ rp, 型は PublicKeyCredentialRpEntity

このメンバーには、要求を担当するリライングパーティに関するデータが含まれます。

その値の name メンバーは必須です。詳細については、§ 5.4.1 公開鍵エンティティの説明 (辞書 PublicKeyCredentialEntity)を参照してください。

その値の id メンバーは、クレデンシャルのスコープを設定する RP ID を指定します。省略した場合、その値は CredentialsContainer オブジェクトの関連設定オブジェクトのオリジンの実効ドメインになります。詳細については、§ 5.4.2 クレデンシャル生成用リライングパーティパラメーター (辞書 PublicKeyCredentialRpEntity)を参照してください。

PublicKeyCredentialCreationOptions/user 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)なしIEなし Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewなしSamsung InternetなしOpera Mobile48+ user, 型は PublicKeyCredentialUserEntity

このメンバーには、リライングパーティがアテステーションを要求しているユーザーアカウントに関するデータが含まれます。

その値の name、 displayName および id メンバーは必須です。詳細については、§ 5.4.1 公開鍵エンティティの説明 (辞書 PublicKeyCredentialEntity)および§ 5.4.3 クレデンシャル生成用ユーザーアカウントパラメーター (辞書 PublicKeyCredentialUserEntity)を参照してください。

PublicKeyCredentialCreationOptions/challenge 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)なしIEなし Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewなしSamsung InternetなしOpera Mobile48+ challenge, 型は BufferSource

このメンバーには、新しく作成されるクレデンシャルのアテステーションオブジェクトを生成するために使用することを意図したチャレンジが含まれます。§ 13.4.3 暗号学的チャレンジのセキュリティ上の考慮事項を参照してください。

PublicKeyCredentialCreationOptions/pubKeyCredParams 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)なしIEなし Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewなしSamsung InternetなしOpera Mobile48+ pubKeyCredParams, 型は sequence<PublicKeyCredentialParameters>

このメンバーには、作成するクレデンシャルに望まれる特性に関する情報が含まれます。シーケンスは最も優先度の高いものから最も低いものの順に並べられます。クライアントは、作成可能な中で最も優先度の高いクレデンシャルを作成するよう最善を尽くします。

PublicKeyCredentialCreationOptions/timeout 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)なしIEなし Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewなしSamsung InternetなしOpera Mobile48+ timeout, 型は unsigned long

このメンバーは、呼び出し元が呼び出しの完了を待つ意思のある時間をミリ秒単位で指定します。これはヒントとして扱われ、クライアントによって上書きされてもよいものとします。

PublicKeyCredentialCreationOptions/excludeCredentials 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)なしIEなし Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewなしSamsung InternetなしOpera Mobile48+ excludeCredentials, 型は sequence<PublicKeyCredentialDescriptor>、デフォルトは []

このメンバーは、単一の認証器上で同じアカウントに対して複数のクレデンシャルが作成されることを制限したいリライングパーティが使用することを意図しています。新しいクレデンシャルが、このパラメーターに列挙されているクレデンシャルのいずれかをすでに含む認証器上に作成される場合、クライアントにはエラーを返すことが要求されます。

PublicKeyCredentialCreationOptions/authenticatorSelection 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)なしIEなし Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewなしSamsung InternetなしOpera Mobile48+ authenticatorSelection, 型は AuthenticatorSelectionCriteria

このメンバーは、create() 操作に参加する適切な認証器を選択したいリライングパーティが使用することを意図しています。

PublicKeyCredentialCreationOptions/attestation 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)なしIEなし Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewなしSamsung InternetなしOpera Mobile48+ attestation, 型は DOMString、デフォルトは "none"

このメンバーは、アテステーション伝達に関する設定を表明したいリライングパーティが使用することを意図しています。その値は AttestationConveyancePreference のメンバーであるべきです。クライアントプラットフォームは未知の値を無視し、未知の値をメンバーが存在しないものとして扱わなければなりません。デフォルト値は "none" です。

extensions, 型は AuthenticationExtensionsClientInputs

このメンバーには、クライアントおよび認証器による追加処理を要求する追加パラメーターが含まれます。たとえば、呼び出し元は、特定の能力を持つ認証器のみをクレデンシャルの作成に使用することや、特定の情報をアテステーションオブジェクトで返すことを要求できます。一部の拡張は § 9 WebAuthn 拡張で定義されています。登録済みのWebAuthn 拡張の最新一覧については、[RFC8809] によって確立された IANA "WebAuthn Extension Identifiers" レジストリ [IANA-WebAuthn-Registries] を参照してください。

5.4.1. 公開鍵エンティティの説明 (辞書 `PublicKeyCredentialEntity`)

PublicKeyCredentialEntity 辞書は、公開鍵クレデンシャルがそれぞれ関連付けられるユーザーアカウント、またはWebAuthn リライングパーティであり、あるいはそれぞれスコープ設定される対象を記述します。

dictionary PublicKeyCredentialEntity {
    required DOMString    name;
};

name, 型は DOMString

エンティティの人間にとって扱いやすい名前。その機能は、PublicKeyCredentialEntity が何を表すかによって異なります。

PublicKeyCredentialRpEntity に継承される場合、これはリライングパーティの人間にとって扱いやすい識別子であり、表示のみを目的とします。たとえば、"ACME Corporation"、"Wonderful Widgets, Inc."、または "ОАО Примертех" です。
- リライングパーティは、name の値を設定する際、またはその値をユーザーに表示する際に、PRECIS FreeformClass [RFC8264] の Nickname Profile について [RFC8266] のセクション 2.3 で規定されているとおりに適用を行うべきです。
- この文字列には言語および方向のメタデータを含めてもよいものとします。リライングパーティは、この情報を提供することを検討すべきです。このメタデータのエンコード方法については、§ 6.4.2 言語および方向のエンコーディングを参照してください。
- クライアントは、値をユーザーに表示する前、またはauthenticatorMakeCredential 操作のパラメーターとしてその値を含める前に、name の値に対して、PRECIS FreeformClass [RFC8264] の Nickname Profile について [RFC8266] のセクション 2.3 で規定されているとおりに適用を行うべきです。
PublicKeyCredentialUserEntity に継承される場合、これはユーザーアカウントの人間にとって扱いやすい識別子です。これは表示のみを目的とし、すなわち、類似した displayName を持つユーザーアカウントの違いをユーザーが判別するのを支援します。たとえば、"alexm"、"alex.mueller@example.com" または "+14255551234" です。
- リライングパーティは、この値をユーザーに選択させてもよいものとします。リライングパーティは、name の値を設定する際、またはその値をユーザーに表示する際に、PRECIS IdentifierClass [RFC8264] の UsernameCasePreserved Profile について [RFC8265] のセクション 3.4.3 で規定されているとおりに適用を行うべきです。
- この文字列には言語および方向のメタデータを含めてもよいものとします。リライングパーティは、この情報を提供することを検討すべきです。このメタデータのエンコード方法については、§ 6.4.2 言語および方向のエンコーディングを参照してください。
- クライアントは、値をユーザーに表示する前、またはauthenticatorMakeCredential 操作のパラメーターとしてその値を含める前に、name の値に対して、PRECIS IdentifierClass [RFC8264] の UsernameCasePreserved Profile について [RFC8265] のセクション 3.4.3 で規定されているとおりに適用を行うべきです。

クライアント、クライアントプラットフォーム、または認証器が name の値を表示する場合、表示される値の周囲に明確な境界を設けるため常に UI 要素を使用し、他の要素へのオーバーフローを許可すべきではありません [css-overflow-3]。

認証器が値を保存する場合、name メンバーの値を 64 バイト以内に収まるよう切り詰めてもよいものとします。切り詰めおよびその他の考慮事項については、§ 6.4.1 文字列の切り詰めを参照してください。

5.4.2. クレデンシャル生成用リライングパーティパラメーター (辞書 `PublicKeyCredentialRpEntity`)

PublicKeyCredentialRpEntity 辞書は、新しいクレデンシャルを作成する際に、追加のリライングパーティ属性を指定するために使用されます。

dictionary PublicKeyCredentialRpEntity : PublicKeyCredentialEntity {
    DOMString      id;
};

id, 型は DOMString: RP ID を設定する、リライングパーティエンティティの一意な識別子。

5.4.3. クレデンシャル生成用ユーザーアカウントパラメーター (辞書 `PublicKeyCredentialUserEntity`)

PublicKeyCredentialUserEntity 辞書は、新しいクレデンシャルを作成する際に追加のユーザーアカウント属性を指定するために使用されます。

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

id, 型は BufferSource

ユーザーアカウントエンティティのユーザーハンドル。ユーザーハンドルは、最大サイズ 64 バイトの不透明なバイト列であり、ユーザーに表示することを意図したものではありません。

安全な動作を保証するため、認証および認可の判断は、この id メンバーに基づいて行わなければならず、displayName または name メンバーに基づいて行ってはなりません。[RFC8266] のセクション 6.1 を参照してください。

ユーザーハンドルには、ユーザー名や電子メールアドレスなど、ユーザーを個人的に識別する情報を含めてはなりません。詳細については、§ 14.6.1 ユーザーハンドルの内容を参照してください。ユーザーハンドルは空であってはなりませんが、null であってもよいものとします。

注: 一部の認証器は常に検出可能なクレデンシャルを作成するため、検出不可能なクレデンシャルであっても、異なるアカウント間でユーザーハンドルは定数値であるべきではありません。したがって、一定のユーザーハンドルを使用すると、ユーザーがそのような認証器をリライングパーティで複数のアカウントに使用できなくなります。

displayName, 型は DOMString

ユーザーアカウントの人間にとって扱いやすい名前であり、表示のみを目的とします。たとえば、"Alex Müller" または "田中倫" です。リライングパーティはユーザーにこれを選択させるべきであり、その選択を必要以上に制限すべきではありません。

リライングパーティは、displayName の値を設定する際、またはその値をユーザーに表示する際に、PRECIS FreeformClass [RFC8264] の Nickname Profile について [RFC8266] のセクション 2.3 で規定されているとおりに適用を行うべきです。
この文字列には言語および方向のメタデータを含めてもよいものとします。リライングパーティは、この情報を提供することを検討すべきです。このメタデータのエンコード方法については、§ 6.4.2 言語および方向のエンコーディングを参照してください。
クライアントは、値をユーザーに表示する前、またはauthenticatorMakeCredential 操作のパラメーターとしてその値を含める前に、displayName の値に対して、PRECIS FreeformClass [RFC8264] の Nickname Profile について [RFC8266] のセクション 2.3 で規定されているとおりに適用を行うべきです。

クライアント、クライアントプラットフォーム、または認証器が displayName の値を表示する場合、表示される値の周囲に明確な境界を設けるため常に UI 要素を使用し、他の要素へのオーバーフローを許可すべきではありません [css-overflow-3]。

認証器は、 displayName メンバーの値について、少なくとも 64 バイトの長さを受け入れて保存しなければなりません。認証器は displayName メンバーの値を 64 バイト以内に収まるよう切り詰めてもよいものとします。切り詰めおよびその他の考慮事項については、§ 6.4.1 文字列の切り詰めを参照してください。

5.4.4. 認証器選択基準 (辞書 `AuthenticatorSelectionCriteria`)

WebAuthn リライングパーティは、認証器の属性に関する要件を指定するために AuthenticatorSelectionCriteria 辞書を使用してもよいものとします。

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

authenticatorAttachment, 型は DOMString

このメンバーが存在する場合、適格な認証器は、指定された § 5.4.5 認証器アタッチメント列挙型 (enum AuthenticatorAttachment) でアタッチされた認証器のみにフィルタリングされます。値は AuthenticatorAttachment のメンバーであるべきですが、クライアントプラットフォームは未知の値を無視し、未知の値をメンバーが存在しないものとして扱わなければなりません。

residentKey, 型は DOMString

リライングパーティがクライアント側で検出可能なクレデンシャルを作成することをどの程度望んでいるかを指定します。歴史的な理由により、名前には非推奨の「resident」という用語が残されています。値は ResidentKeyRequirement のメンバーであるべきですが、クライアントプラットフォームは未知の値を無視し、未知の値をメンバーが存在しないものとして扱わなければなりません。値が指定されない場合、requireResidentKey が true なら実効値は required となり、false または存在しない場合は discouraged となります。

residentKey の値および意味の説明については、ResidentKeyRequirement を参照してください。

requireResidentKey, 型は boolean、デフォルトは false

このメンバーは WebAuthn レベル 1 との後方互換性のために保持されており、歴史的な理由により、その名前には検出可能なクレデンシャルについて非推奨の「resident」という用語が残されています。リライングパーティは、residentKey が required に設定されている場合に限り、これを true に設定すべきです。

userVerification, 型は DOMString、デフォルトは "preferred"

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

5.4.5. 認証器アタッチメント列挙型 (enum `AuthenticatorAttachment`)

この列挙型の値は、認証器のアタッチメント方式を記述します。リライングパーティは、クレデンシャルを作成するために navigator.credentials.create() を呼び出す際、優先する認証器アタッチメント方式を表明するためにこれを使用します。

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

注: AuthenticatorAttachment 列挙型は意図的に参照されません。§ 2.1.1 DOMString 型としての列挙型を参照してください。

platform: この値はプラットフォームアタッチメントを示します。
cross-platform: この値はクロスプラットフォームアタッチメントを示します。

注: 認証器アタッチメント方式の選択オプションは、[[Create]](origin, options, sameOriginWithAncestors) 操作でのみ利用できます。リライングパーティは、たとえば、別のクライアントデバイスで認証するためのローミングクレデンシャルをユーザーが持つことを保証するため、または特定のクライアントデバイスを使用した再認証を容易にするためにプラットフォームクレデンシャルを明示的に登録するために、これを使用できます。[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 操作には認証器アタッチメント方式の選択オプションがないため、リライングパーティは、ユーザーが登録したクレデンシャルのいずれでも受け入れるべきです。その後、クライアントとユーザーは、その時点で利用可能かつ便利なものを使用します。

5.4.6. 常駐キー要件列挙型 (enum `ResidentKeyRequirement`)

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

注: ResidentKeyRequirement 列挙型は意図的に参照されません。§ 2.1.1 DOMString 型としての列挙型を参照してください。

この列挙型の値は、クライアント側で検出可能なクレデンシャル（以前は常駐クレデンシャルまたは常駐キーと呼ばれていました）に関するリライングパーティの要件を記述します。

discouraged

この値は、リライングパーティがサーバー側クレデンシャルの作成を優先するものの、クライアント側で検出可能なクレデンシャルも受け入れることを示します。

注: リライングパーティは、作成されるクレデンシャルがサーバー側クレデンシャルであることを要求できず、クレデンシャルプロパティ拡張は rk プロパティの値を返さない場合があります。このため、クレデンシャルがサーバー側クレデンシャルであるかどうかを認識できず、その結果、同じユーザーハンドルで 2 つ目のクレデンシャルを作成すると最初のクレデンシャルが追い出されるかどうかも分からない場合があります。

preferred

この値は、リライングパーティがクライアント側で検出可能なクレデンシャルの作成を強く優先するものの、サーバー側クレデンシャルも受け入れることを示します。たとえば、この場合、クライアント側で検出可能なクレデンシャルを作成するために必要であれば、ユーザーエージェントはユーザー検証を設定するようユーザーを案内すべきです。これは userVerification の設定より優先されます。

required

この値は、リライングパーティがクライアント側で検出可能なクレデンシャルを必要とし、クライアント側で検出可能なクレデンシャルを作成できない場合にエラーを受け取る用意があることを示します。

注: リライングパーティは、 options.authenticatorSelection.residentKey に指定した値を考慮して、クレデンシャルプロパティ拡張の返り値を調べることにより、認証器がクライアント側で検出可能なクレデンシャルを作成したかどうかに関する情報を得ることができます。これは、 options.authenticatorSelection.residentKey に discouraged または preferred の値を使用する場合に有用です。なぜなら、この場合、認証器はクライアント側で検出可能なクレデンシャルまたはサーバー側クレデンシャルのいずれかを作成できるためです。

5.4.7. アテステーション伝達設定列挙型 (enum `AttestationConveyancePreference`)

WebAuthn リライングパーティは、クレデンシャル生成中のアテステーション伝達に関する設定を指定するため、AttestationConveyancePreference を使用してもよいものとします。

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

注: AttestationConveyancePreference 列挙型は意図的に参照されません。§ 2.1.1 DOMString 型としての列挙型を参照してください。

none

この値は、リライングパーティが認証器のアテステーションに関心がないことを示します。たとえば、識別情報をリライングパーティへ中継するためにユーザーの同意を得る必要が生じる可能性を回避したり、アテステーション CAまたは匿名化 CAへのラウンドトリップを省くためです。

これはデフォルト値です。

indirect

この値は、リライングパーティが検証可能なアテステーションステートメントをもたらすアテステーション伝達を優先するものの、そのようなアテステーションステートメントをどのように取得するかはクライアントに決定を委ねることを示します。クライアントは、ユーザーのプライバシーを保護するため、または異種混在のエコシステムにおけるアテステーション検証でリライングパーティを支援するために、認証器が生成したアテステーションステートメントを匿名化 CAによって生成されたアテステーションステートメントに置き換えてもよいものとします。

注: この場合、リライングパーティが検証可能なアテステーションステートメントを取得できる保証はありません。たとえば、認証器が自己アテステーションを使用する場合です。

direct

この値は、リライングパーティが認証器によって生成されたままのアテステーションステートメントを受け取ることを望んでいることを示します。

enterprise

この値は、リライングパーティが一意な識別情報を含む可能性のあるアテステーションステートメントを受け取ることを望んでいることを示します。これは、組織が登録を特定の認証器に関連付けることを望む、企業内の管理された展開を目的としています。ユーザーエージェントまたは認証器の構成が、要求されたRP IDについてそれを許可しない限り、ユーザーエージェントはこのようなアテステーションを提供してはなりません。

許可されている場合、ユーザーエージェントは（呼び出し時に）エンタープライズアテステーションが要求されていることを認証器に通知し、結果として得られるAAGUIDおよびアテステーションステートメントを変更せずにリライングパーティへ伝達すべきです。

5.5. アサーション生成用オプション (辞書 `PublicKeyCredentialRequestOptions`)

PublicKeyCredentialRequestOptions

現在のすべてのエンジンで利用できます。

Firefox60+Safari13+Chrome67+

Opera54+Edge79+

Edge (Legacy)なしIEなし

Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetなしOpera 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)なしIEなし Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetなしOpera Mobile48+ challenge, 型は BufferSource: このメンバーは、選択された認証器が認証アサーションを生成する際に、他のデータとともに署名するチャレンジを表します。§ 13.4.3 暗号学的チャレンジのセキュリティ上の考慮事項を参照してください。
PublicKeyCredentialRequestOptions/timeout 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)なしIEなし Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetなしOpera Mobile48+ timeout, 型は unsigned long: この任意のメンバーは、呼び出し元が呼び出しの完了を待つ意思のある時間をミリ秒単位で指定します。値はヒントとして扱われ、クライアントによって上書きされてもよいものとします。
PublicKeyCredentialRequestOptions/rpId 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)なしIEなし Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetなしOpera Mobile48+ rpId, 型は USVString: この任意のメンバーは、呼び出し元が主張するリライングパーティ識別子を指定します。省略した場合、その値は CredentialsContainer オブジェクトの関連設定オブジェクトのオリジンの実効ドメインになります。
PublicKeyCredentialRequestOptions/allowCredentials 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)なしIEなし Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetなしOpera Mobile48+ allowCredentials, 型は sequence<PublicKeyCredentialDescriptor>、デフォルトは []: この任意のメンバーには、呼び出し元が受け入れ可能な公開鍵クレデンシャルを表す PublicKeyCredentialDescriptor オブジェクトのリストが、呼び出し元の優先度の降順で含まれます（リストの最初の項目が最も優先されるクレデンシャルであり、以下同様です）。
PublicKeyCredentialRequestOptions/userVerification 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)なしIEなし Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetなしOpera Mobile48+ userVerification, 型は DOMString、デフォルトは "preferred": この任意のメンバーは、get() 操作におけるユーザー検証に関するリライングパーティの要件を記述します。値は UserVerificationRequirement のメンバーであるべきですが、クライアントプラットフォームは未知の値を無視し、未知の値をメンバーが存在しないものとして扱わなければなりません。適格な認証器は、この要件を満たすことができるものだけにフィルタリングされます。
PublicKeyCredentialCreationOptions/extensions 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)なしIEなし Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewなしSamsung InternetなしOpera Mobile48+ PublicKeyCredentialRequestOptions/extensions 現在のすべてのエンジンで利用できます。 Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)なしIEなし Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetなしOpera Mobile48+ extensions, 型は AuthenticationExtensionsClientInputs: この任意のメンバーには、クライアントおよび認証器による追加処理を要求する追加パラメーターが含まれます。たとえば、ユーザーにトランザクション確認を求める場合、プロンプト文字列を拡張として含めることができます。

5.6. `AbortSignal` による操作の中止

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

注: DOM § 3.3 API での AbortController および AbortSignal オブジェクトの使用セクションでは、AbortController と統合する Web プラットフォーム API は、aborted フラグが設定された時点で直ちに Promise を拒否しなければならないと規定しています。 [[Create]](origin, options, sameOriginWithAncestors) および [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) メソッドの複雑な継承および並列化構造を考慮し、2 つの API のアルゴリズムは、 3 か所でaborted フラグを確認することでこの要件を満たします。[[Create]](origin, options, sameOriginWithAncestors) の場合、aborted フラグはまず Credential Management 1 § 2.5.4 クレデンシャルの作成で [[Create]](origin, options, sameOriginWithAncestors) を呼び出す直前に確認され、次に § 5.1.3 新しいクレデンシャルの作成 - PublicKeyCredential の [[Create]](origin, options, sameOriginWithAncestors) メソッドで認証器セッションが開始される直前に確認され、最後に認証器セッション中に確認されます。[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) についても同様です。

可視性およびフォーカスの状態によって、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. 認証拡張クライアント入力 (辞書 `AuthenticationExtensionsClientInputs`)

dictionary AuthenticationExtensionsClientInputs {
};

これは、0 個以上のWebAuthn 拡張のクライアント拡張入力値を含む辞書です。

5.7.2. 認証拡張クライアント出力 (辞書 `AuthenticationExtensionsClientOutputs`)

dictionary AuthenticationExtensionsClientOutputs {
};

これは、0 個以上のWebAuthn 拡張のクライアント拡張出力値を含む辞書です。

5.7.3. 認証拡張認証器入力 (CDDL 型 `AuthenticationExtensionsAuthenticatorInputs`)

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

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

この型はリライングパーティには公開されませんが、クライアントおよび認証器によって使用されます。

5.7.4. 認証拡張認証器出力 (CDDL 型 `AuthenticationExtensionsAuthenticatorOutputs`)

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

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

5.8. 補助データ構造

公開鍵クレデンシャル型は、補助仕様で規定される特定のデータ構造を使用します。これらは次のとおりです。

5.8.1. WebAuthn 署名で使用されるクライアントデータ (辞書 `CollectedClientData`)

クライアントデータは、 WebAuthn リライングパーティとクライアントの両方のコンテキスト上のバインディングを表します。これは、キーが文字列であるキー・値マッピングです。値には、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

このメンバーには、リライングパーティによって提供されたチャレンジの base64url エンコーディングが含まれます。 § 13.4.3 暗号学的チャレンジのセキュリティ上の考慮事項を参照してください。

origin, 型は DOMString

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

crossOrigin, 型は boolean

このメンバーには、内部メソッドに渡された sameOriginWithAncestors 引数値の反転が含まれます。

tokenBinding, 型は TokenBinding

この任意のメンバーには、リライングパーティとの通信時に使用されるToken Binding プロトコル [TokenBinding] の状態に関する情報が含まれます。このメンバーが存在しない場合、クライアントが Token Binding をサポートしていないことを示します。

status, 型は DOMString

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

supported: クライアントが Token Binding をサポートしているものの、リライングパーティとの通信時にはネゴシエートされなかったことを示します。
present: リライングパーティとの通信時に Token Binding が使用されたことを示します。この場合、 id メンバーが存在しなければなりません。

注: TokenBindingStatus 列挙型は意図的に参照されません。§ 2.1.1 DOMString 型としての列挙型を参照してください。

id, 型は DOMString

status が present の場合、このメンバーは存在しなければならず、リライングパーティとの通信時に使用されたToken Binding ID のbase64url エンコーディングでなければなりません。

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

CollectedClientData 構造体は、次の量を計算するためにクライアントによって使用されます。

クライアントデータの JSON 互換シリアル化: これは、CollectedClientData 辞書に対してJSON 互換シリアル化アルゴリズムを実行した結果です。
シリアル化されたクライアントデータのハッシュ: これは、クライアントによって構築されたクライアントデータの JSON 互換シリアル化のハッシュ（SHA-256 を使用して計算）です。

5.8.1.1. シリアル化

CollectedClientData のシリアル化は、JSON をバイトへシリアル化するアルゴリズムの一部です。すなわち、CollectedClientData の有効な JSON エンコーディングを生成しますが、完全な JSON パーサーの統合を避けるために検証側が利用できる追加の構造も提供します。検証側は標準の JSON 解析を行うことが推奨されますが、完全な JSON パーサーが大きすぎるコンテキストでは、以下のより限定的なアルゴリズムを使用できます。この検証アルゴリズムでは、base64url エンコーディング、バイト文字列の追加（固定テンプレートへ書き込むことで実装可能）、および 3 つの条件チェックのみが必要です（入力にエスケープが不要であることが既知であると仮定します）。

シリアル化アルゴリズムは、完全な結果が得られるまで、最初は空の部分結果へ順にバイト文字列を追加することで動作します。

result を空のバイト文字列とします。
0x7b2274797065223a ({"type":) を result に追加します。
CCDToString(type) を result に追加します。
0x2c226368616c6c656e6765223a (,"challenge":) を result に追加します。
CCDToString(challenge) を result に追加します。
0x2c226f726967696e223a (,"origin":) を result に追加します。
CCDToString(origin) を result に追加します。
0x2c2263726f73734f726967696e223a (,"crossOrigin":) を result に追加します。
crossOrigin が存在しないか、false の場合:
1. 0x66616c7365 (false) を result に追加します。
それ以外の場合:
1. 0x74727565 (true) を result に追加します。
CollectedClientData の一時的なコピーを作成し、フィールド type、 challenge、 origin、および crossOrigin （存在する場合）を削除します。
一時コピーにフィールドが残っていない場合:
1. 0x7d (}) を result に追加します。
それ以外の場合:
1. 一時コピーに対してJSON をバイトへシリアル化するを呼び出し、バイト文字列 remainder を生成します。
2. 0x2c (,) を result に追加します。
3. remainder から先頭のバイトを削除します。
4. remainder を result に追加します。
シリアル化の結果は result の値です。

関数 CCDToString は上記のアルゴリズムで使用され、次のように定義されます。

encoded を空のバイト文字列とします。
0x22 (") を encoded に追加します。
指定されたオブジェクトに対して ToString を呼び出し、文字列へ変換します。
結果の文字列内の各コードポイントについて、コードポイントが:

集合 {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 桁の小文字 16 進数字を追加します。
0x22 (") を encoded に追加します。
この関数の結果は encoded の値です。

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

完全な JSON パーサーをサポートできない場合、検証側はエンコードされた CollectedClientData を検証するため、次のアルゴリズムを使用できます。

アルゴリズムへの入力は次のとおりです。
1. clientDataJSON — 検証するシリアル化された CollectedClientData — を含むバイト文字列 clientDataJSON。
2. 期待される type を含む文字列 type。
3. PublicKeyCredentialRequestOptions または PublicKeyCredentialCreationOptions で指定されたチャレンジのバイト文字列を含むバイト文字列 challenge。
4. ユーザーエージェントへリクエストを発行した、期待される origin を含む文字列 origin。
5. リクエストがクロスオリジンの iframe 内で実行されるべきであった場合に限り true となる Boolean 値 crossOrigin。
expected を空のバイト文字列とします。
0x7b2274797065223a ({"type":) を expected に追加します。
CCDToString(type) を expected に追加します。
0x2c226368616c6c656e6765223a (,"challenge":) を expected に追加します。
challenge にbase64url エンコーディングを実行し、文字列 challengeBase64 を生成します。
CCDToString(challengeBase64) を expected に追加します。
0x2c226f726967696e223a (,"origin":) を expected に追加します。
CCDToString(origin) を expected に追加します。
0x2c2263726f73734f726967696e223a (,"crossOrigin":) を expected に追加します。
crossOrigin が true の場合:
1. 0x74727565 (true) を expected に追加します。
それ以外、すなわち crossOrigin が false の場合:
1. 0x66616c7365 (false) を expected に追加します。
expected が clientDataJSON の接頭辞でない場合、検証は失敗します。
clientDataJSON が expected より少なくとも 1 バイト長くない場合、検証は失敗します。
clientDataJSON の、expected の長さに等しいオフセット位置のバイトが:

0x7d である

検証は成功します。

0x2c である

検証は成功します。

それ以外

検証は失敗します。

5.8.1.3. 将来の開発

限定検証アルゴリズムとの互換性を維持するため、この仕様の将来のバージョンでは、CollectedClientData からフィールド type、 challenge、 origin、または crossOrigin のいずれも削除してはなりません。また、これらのフィールドがシリアル化される順序を変更するようにシリアル化アルゴリズムを変更してはなりません。

CollectedClientData に追加のフィールドが追加された場合、限定検証アルゴリズムを使用する検証側は、上記 2 つのアルゴリズムがそれらを含むよう更新されるまで、そのフィールドを考慮できません。このような更新が行われると、追加されたフィールドは前の段落で説明したものと同じ制限を継承します。このようなアルゴリズムの更新は、以前のバージョンによって生成されたシリアル化に対応する必要があります。すなわち、検証アルゴリズムは、以前のバージョンを使用するユーザーエージェントによって生成された場合、5 番目のキー・値ペアが 5 番目に現れない（またはまったく現れない）可能性があることを処理しなければなりません。

5.8.2. クレデンシャル型列挙型 (enum `PublicKeyCredentialType`)

enum PublicKeyCredentialType {
    "public-key"
};

注: PublicKeyCredentialType 列挙型は意図的に参照されません。§ 2.1.1 DOMString 型としての列挙型を参照してください。

この列挙型は有効なクレデンシャル型を定義します。これは拡張ポイントであり、より多くのクレデンシャル型が定義されるにつれて、将来値を追加できます。この列挙型の値は、認証器の型に応じて Authentication Assertion およびアテステーション構造をバージョン管理するために使用されます。

現在、1 つのクレデンシャル型、すなわち "public-key" が定義されています。

5.8.3. クレデンシャル記述子 (辞書 `PublicKeyCredentialDescriptor`)

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

この辞書には、create() または get() メソッドへの入力パラメーターとして公開鍵クレデンシャルを参照する際に、呼び出し元が指定する属性が含まれます。これは、これらのメソッドによって返される PublicKeyCredential オブジェクトのフィールドを反映します。

type, 型は DOMString

このメンバーには、呼び出し元が参照している公開鍵クレデンシャルの型が含まれます。値は PublicKeyCredentialType のメンバーであるべきですが、クライアントプラットフォームは未知の type を持つすべての PublicKeyCredentialDescriptor を無視しなければなりません。

id, 型は BufferSource

このメンバーには、呼び出し元が参照している公開鍵クレデンシャルのクレデンシャル IDが含まれます。

transports, 型は sequence<DOMString>

この任意のメンバーには、呼び出し元が参照している公開鍵クレデンシャルの管理認証器とクライアントがどのように通信できるかについてのヒントが含まれます。値は AuthenticatorTransport のメンバーであるべきですが、クライアントプラットフォームは未知の値を無視しなければなりません。

getTransports() 操作は、このメンバーに適した値を提供できます。新しいクレデンシャルを登録する際、リライングパーティは getTransports() から返された値を保存すべきです。そのクレデンシャルの PublicKeyCredentialDescriptor を作成する際、リライングパーティはその保存された値を取得し、 transports メンバーの値として設定すべきです。

5.8.4. 認証器トランスポート列挙型 (enum `AuthenticatorTransport`)

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

注: AuthenticatorTransport 列挙型は意図的に参照されません。§ 2.1.1 DOMString 型としての列挙型を参照してください。

認証器は、クライアントと通信するためにさまざまなトランスポートを実装できます。この列挙型は、特定のクレデンシャルのアサーションを取得するため、クライアントが特定の認証器とどのように通信できるかについてのヒントを定義します。これらのヒントは、認証器へ到達する方法についてのWebAuthn リライングパーティの最善の推測を表すことに注意してください。リライングパーティは通常、公開鍵クレデンシャルについてサポートされるトランスポートを getTransports() を介して知ります。

usb: 該当する認証器にリムーバブル USB 経由で接続できることを示します。
nfc: 該当する認証器に Near Field Communication (NFC) 経由で接続できることを示します。
ble: 該当する認証器に Bluetooth Smart (Bluetooth Low Energy / BLE) 経由で接続できることを示します。
internal: 該当する認証器にクライアントデバイス固有のトランスポートを使用して接続すること、すなわち、それがプラットフォーム認証器であることを示します。これらの認証器はクライアントデバイスから取り外すことができません。

5.8.5. 暗号アルゴリズム識別子 (typedef `COSEAlgorithmIdentifier`)

typedef long COSEAlgorithmIdentifier;

COSEAlgorithmIdentifier の値は、暗号アルゴリズムを識別する数値です。アルゴリズム識別子は IANA COSE Algorithms レジストリ [IANA-COSE-ALGS-REG] に登録された値であるべきです。たとえば、"ES256" には -7、"RS256" には -257 を使用します。

COSE アルゴリズムレジストリでは、COSE 鍵の他のパラメーターによって指定される自由度が残されています。相互運用性を促進するため、この仕様ではクレデンシャル公開鍵について次の追加保証を設けます。

アルゴリズム ES256 (-7) の鍵は、crv パラメーターとして P-256 (1) を指定しなければならず、圧縮点形式を使用してはなりません。
アルゴリズム ES384 (-35) の鍵は、crv パラメーターとして P-384 (2) を指定しなければならず、圧縮点形式を使用してはなりません。
アルゴリズム ES512 (-36) の鍵は、crv パラメーターとして P-521 (3) を指定しなければならず、圧縮点形式を使用してはなりません。
アルゴリズム EdDSA (-8) の鍵は、crv パラメーターとして Ed25519 (6) を指定しなければなりません。（これらは COSE では常に圧縮形式を使用します。）

注: これらのアルゴリズムを使用して署名検証を正しく実装するには、多くの確認が必要です。その 1 つは、非圧縮楕円曲線点を処理する際、実装はその点が実際に曲線上にあることを確認すべきであるというものです。この確認は、暗号ライブラリと他のコードとの間の隙間から抜け落ちる特に高いリスクがあると判断されるため、ここで強調されています。

5.8.6. ユーザー検証要件列挙型 (enum `UserVerificationRequirement`)

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

WebAuthn リライングパーティは、一部の操作ではユーザー検証を要求し、他の操作では要求しない場合があり、この型を使用してその要求を表明できます。

注: UserVerificationRequirement 列挙型は意図的に参照されません。§ 2.1.1 DOMString 型としての列挙型を参照してください。

required: この値は、リライングパーティが操作にユーザー検証を要求し、レスポンスに UV フラグが設定されていない場合は操作を失敗させることを示します。
preferred: この値は、リライングパーティが可能であれば操作にユーザー検証を使用することを優先するものの、レスポンスに UV フラグが設定されていなくても操作を失敗させないことを示します。
discouraged: この値は、リライングパーティが操作中にユーザー検証を使用することを望まないことを示します（たとえば、ユーザーの対話フローへの中断を最小限にするため）。

5.9. Permissions Policy との統合

Headers/Feature-Policy/publickey-credentials-get

現在のエンジンのうち 1 つでのみ利用できます。

FirefoxなしSafariなしChrome84+

OperaなしEdge84+

Edge (Legacy)なしIEなし

Firefox for AndroidなしiOS SafariなしChrome for Android84+Android WebView84+Samsung InternetなしOpera Mobileなし

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

Document の Permissions Policyは、その文書内のコンテンツが Web Authentication API を正常に呼び出すことを許可されているか、すなわち navigator.credentials.get({publicKey:..., ...}) を介して利用できるかどうかを決定します。いずれかの文書で無効化されている場合、その文書内のコンテンツはいずれも上記のメソッドを使用することを許可されません。使用を試みるとエラーが返されます。

注: [CREDENTIAL-MANAGEMENT-1] で規定されるアルゴリズムが、実際の Permissions Policy 評価を実行します。これは、このようなポリシー評価を現在の設定オブジェクトへアクセスできる時点で行う必要があるためです。[[Create]](origin, options, sameOriginWithAncestors) および [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 内部メソッドには、[CREDENTIAL-MANAGEMENT-1] で規定されたアルゴリズムによって並列に呼び出されるため、そのようなアクセスはありません。

5.10. `iframe` 要素内での Web Authentication の使用

Web Authentication API は、クロスオリジンの iframeではデフォルトで無効になっています。このデフォルトポリシーを上書きし、クロスオリジンの iframe が Web Authentication API の [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) メソッドを呼び出すことを許可されていることを示すには、 allow 属性を iframe 要素に指定し、 publickey-credentials-get feature-identifier トークンを allow 属性の値に含めます。

埋め込みコンテキストで WebAuthn API を利用するリライングパーティは、 UI リドレッシングとその可能な緩和策について、§ 13.4.2 埋め込み使用に関する可視性の考慮事項を確認すべきです。

6. WebAuthn 認証器モデル

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

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

注: [FIDO-CTAP] はこのモデルの具体的な実体化の一例ですが、返されるデータと WebAuthn API のアルゴリズムが期待するデータとの間に相違があります。CTAP2 レスポンスメッセージは、同じオブジェクトについてこの仕様で定義されている文字列キーではなく、整数キーを使用して構築される CBOR マップです。クライアントは、そのようなデータに対して必要な変換を行うことが期待されます。[FIDO-CTAP] 仕様では、CTAP2 の整数キーと WebAuthn の文字列キーとの対応を、セクション §6.2. レスポンスで詳述しています。

認証器について、このモデルは認証器がサポートしなければならない論理操作と、クライアントおよびWebAuthn リライングパーティに公開するデータ形式を定義します。ただし、リライングパーティとの相互運用性に必要でない限り、認証器がクライアントデバイスと通信する方法の詳細は定義しません。たとえば、この抽象モデルは USB や NFC などのトランスポートを介して認証器をクライアントへ接続するプロトコルを定義しません。同様に、この抽象モデルは具体的なエラーコードやそれらを返す方法を定義しませんが、クライアントのニーズという観点からエラー動作を定義します。したがって、適合かつ安全なクライアント実装を可能にするために、どのエラー条件を互いに区別できなければならないか（または区別できてはならないか）を示す手段として、具体的なエラーコードが言及されます。

リライングパーティは、必要と判断した場合、クレデンシャル作成オプションまたはアサーション生成オプションをそれぞれ使用し、クレデンシャルを作成する際および/またはアサーションを生成する際にさまざまな認証器特性を指定することで、認証器の選択に影響を与えることができます。 WebAuthn API の基礎となるアルゴリズムは、これらのオプションを整理して以下で定義される該当する認証器操作へ渡します。

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

各認証器はクレデンシャルマップを保存します。これは、(rpId, [userHandle]) から公開鍵クレデンシャルソースへのマップです。

さらに、各認証器には AAGUID があり、これは認証器の種類（例: メーカーおよびモデル）を示す 128 ビット識別子です。AAGUID は、製造元が製造した実質的に同一のすべての認証器で同一となり、他のすべての種類の認証器の AAGUID とは（高い確率で）異なるよう、製造元が選択しなければなりません。これを保証するため、所与の認証器型の AAGUID はランダムに生成すべきです。リライングパーティは、他のソースからの情報を使用して、認証レベルや鍵保護の強度など、認証器の特定の特性を推測するために AAGUID を使用してもよいものとします。

認証器の主要な機能は、さまざまなコンテキストデータにバインドされるWebAuthn 署名を提供することです。これらのデータは、署名要求がサーバーから認証器へ渡される際に、スタックの異なるレベルで観測され追加されます。サーバーは署名を検証する際、これらのバインディングを期待値と照合します。これらのコンテキスト上のバインディングは 2 つに分かれます。リライングパーティまたはクライアントによって追加され、クライアントデータと呼ばれるものと、認証器によって追加され、認証器データと呼ばれるものです。認証器はクライアントデータを署名対象としますが、それ以外ではその内容に関心を持ちません。認証器の帯域幅と処理要件を節約するため、クライアントはクライアントデータをハッシュし、その結果のみを認証器へ送信します。認証器は、シリアル化されたクライアントデータのハッシュと、自身の認証器データの組み合わせを署名対象とします。

この設計の目標は次のように要約できます。

署名を生成する仕組みは、クライアントデバイスと認証器との間のリンクが帯域幅および/または遅延の面で非常に制約されている場合にも対応すべきです。例として Bluetooth Low Energy や Near-Field Communication があります。
認証器が処理するデータは小さく、低レベルコードで解釈しやすいものであるべきです。特に、認証器は JSON のような高レベルのエンコーディングを解析する必要がないようにすべきです。
クライアントと認証器の両方が、必要に応じてコンテキスト上のバインディングを追加できる柔軟性を持つべきです。
この設計は、採用と実装を支援するため、既存のエンコーディング形式を可能な限り再利用することを目指しています。

認証器は 2 つの異なる目的のために暗号署名を生成します。

アテステーション署名は、authenticatorMakeCredential 操作を介して新しい公開鍵クレデンシャルが作成されるときに生成されます。アテステーション署名は、認証器およびクレデンシャルの特定の特性に関する暗号学的証明を提供します。たとえば、アテステーション署名は、認証器の種類（その AAGUID で示される）およびクレデンシャル公開鍵を表明します。アテステーション署名は、求めるアテステーションの種類に応じて選択されるアテステーション秘密鍵で署名されます。アテステーションの詳細については、§ 6.5 アテステーションを参照してください。
アサーション署名は、authenticatorGetAssertion メソッドが呼び出されたときに生成されます。これは、ログインや購入の完了など、特定のトランザクションにユーザーが同意したことを認証器が表明するものです。したがって、アサーション署名は、特定のクレデンシャル秘密鍵を所有する認証器が、その能力の及ぶ限りにおいて、このトランザクションを要求しているユーザーが、その特定の公開鍵クレデンシャルの作成に同意したユーザーと同じであることを確認したと表明します。また、ユーザーの同意が提供された手段や、認証器がユーザーに表示したプロンプトなど、呼び出し元に有用な可能性があるクライアントデータと呼ばれる追加情報も表明します。アサーション署名形式は、以下の図 4に示されています。

WebAuthn 署名という用語は、アテステーション署名とアサーション署名の両方を指します。これらの署名の形式と、それらを生成する手順は以下で規定されます。

6.1. 認証器データ

認証器データ構造は、認証器によって行われたコンテキスト上のバインディングをエンコードします。これらのバインディングは認証器自身によって制御され、その信頼性は、認証器のセキュリティ特性に対するWebAuthn リライングパーティの評価に由来します。一方の極端な場合では、認証器はクライアントに組み込まれており、そのバインディングはクライアントデータと同程度しか信頼できない可能性があります。他方の極端な場合では、認証器は高セキュリティのハードウェアとソフトウェアを備え、安全なチャネルを介してクライアントに接続された独立したエンティティである可能性があります。どちらの場合でも、リライングパーティは認証器データを同じ形式で受け取り、認証器についての知識を使用して信頼性を判断します。

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

認証器データ構造は 37 バイト以上のバイト配列であり、表に示すように配置されます。

名前	長さ（バイト単位）	説明
rpIdHash	32	クレデンシャルのスコープが設定された RP ID の SHA-256 ハッシュ。
フラグ	1	フラグ（ビット 0 が最下位ビット）: ビット 0: ユーザー存在（UP）の結果。 `1` はユーザーが存在していることを意味します。 `0` はユーザーが存在していないことを意味します。ビット 1: 将来の使用のために予約（`RFU1`）。ビット 2: ユーザー検証済み（UV）の結果。 `1` はユーザーが検証済みであることを意味します。 `0` はユーザーが検証済みではないことを意味します。ビット 3-5: 将来の使用のために予約（`RFU2`）。ビット 6: アテステーション済みクレデンシャルデータを含む（`AT`）。認証器がアテステーション済みクレデンシャルデータを追加したかどうかを示します。ビット 7: 拡張データを含む（`ED`）。認証器データに拡張が含まれるかどうかを示します。
signCount	4	署名カウンター。32 ビット符号なしビッグエンディアン整数。
attestedCredentialData	可変（存在する場合）	アテステーション済みクレデンシャルデータ（存在する場合）。詳細については、§ 6.5.1 アテステーション済みクレデンシャルデータを参照してください。その長さは、アテステーション対象のクレデンシャル IDの長さおよびクレデンシャル公開鍵によって異なります。
拡張	可変（存在する場合）	拡張によって定義される認証器データ。これは、拡張識別子をキー、認証器拡張出力を値とするCBOR [RFC8949] マップです。詳細については、§ 9 WebAuthn 拡張を参照してください。

認証器データのレイアウト。名前列の名前はこの文書内での参照のためだけのものであり、実際の認証器データの表現には存在しません。

RP ID は、クレデンシャルの作成時にクライアントから最初に受け取られ、アサーションの生成時に再び受け取られます。ただし、他のクライアントデータとはいくつかの重要な点で異なります。第一に、クライアントデータとは異なり、クレデンシャルのRP IDは、操作間で変更されず、そのクレデンシャルの存続期間中同じままです。第二に、 authenticatorGetAssertion 操作中に認証器によって検証されます。これは、要求されたクレデンシャルにスコープ設定された RP IDが、クライアントによって提供されたRP IDと完全に一致することを確認することで行われます。

認証器は、次の手順を実行して認証器データ構造を生成します。

RP ID を SHA-256 でハッシュして rpIdHash を生成します。
認証器がユーザー存在のテストを実行した場合に限り、UP フラグを設定しなければなりません。認証器がユーザー検証を実行した場合に限り、UV フラグを設定しなければなりません。 RFU ビットはゼロに設定しなければなりません。

注: 認証器がユーザー存在のテストとユーザー検証の両方を実行した場合、それらが 1 回の認可ジェスチャーにまとめられていた可能性があっても、認証器は UP フラグと UV フラグの両方を設定します。
アテステーション署名の場合、認証器は AT フラグを設定し、attestedCredentialDataを含めなければなりません。アサーション署名の場合、AT フラグを設定してはならず、 attestedCredentialData を含めてはなりません。
認証器が拡張データを含めない場合、ED フラグをゼロに設定しなければならず、拡張データを含める場合は 1 に設定しなければなりません。

図は、認証器データ構造を視覚的に表したものです。

注: 認証器データは自身の長さを記述します。AT および ED フラグが設定されていない場合、その長さは常に 37 バイトです。アテステーション済みクレデンシャルデータ（AT フラグが設定されている場合にのみ存在します）は自身の長さを記述します。ED フラグが設定されている場合、合計の長さは 37 バイトに、アテステーション済みクレデンシャルデータの長さ（AT フラグが設定されている場合）、さらに後続する拡張出力（CBOR マップ）の長さを加えたものです。

可変長のアテステーション済みクレデンシャルデータの長さを決定するには、先行する credentialIdの長さを基に credentialPublicKeyの開始位置を決定し、その後 credentialPublicKeyの長さを決定する必要があります（[RFC8152] のセクション 7も参照）。

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

認証器は署名カウンター機能を実装すべきです。概念上、これらのカウンターは認証器によってクレデンシャルごとに保存されるか、認証器全体についてグローバルに保存されます。クレデンシャルの署名カウンターの初期値は、 authenticatorMakeCredential によって返される認証器データの signCount 値で指定されます。署名カウンターは、成功した各authenticatorGetAssertion 操作ごとに何らかの正の値だけ増加し、後続の値は再び認証器データ内でWebAuthn リライングパーティへ返されます。署名カウンターの目的は、リライングパーティが複製された認証器を検出するのを支援することです。複製検出は、保護対策が限られた認証器ではより重要です。

リライングパーティは、直近のauthenticatorGetAssertion 操作の署名カウンターを保存します。（または、クレデンシャルに対してauthenticatorGetAssertion が一度も実行されていない場合は、authenticatorMakeCredential 操作のカウンターです。）後続のauthenticatorGetAssertion 操作では、リライングパーティは、保存された署名カウンター値と、アサーションの認証器データで返された新しい signCount 値を比較します。いずれかがゼロではなく、新しい signCount 値が保存された値以下である場合、複製された認証器が存在するか、認証器が誤動作している可能性があります。

署名カウンターの不一致を検出しても、現在の操作が複製された認証器と元の認証器のどちらによって実行されたかは分かりません。リライングパーティは、それぞれの状況、すなわちリスク許容度に応じて、この状況に適切に対処すべきです。

認証器:

クレデンシャルごとの署名カウンターを実装すべきです。これにより、署名カウンター値がリライングパーティ間で共有され、ユーザーを関連付けるためのハンドルとして使用される可能性を防ぎます。認証器は、認証器単位のグローバルな署名カウンターを実装してもよいものとしますが、これはユーザーのプライバシーの面で劣ります。
署名カウンター値が誤って減少しないこと（例: ハードウェア障害による）を保証すべきです。

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

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

これは、FIDO U2F 認証レスポンスメッセージ内の署名対象データの最初の 37 バイトが有効な認証器データ構造を構成し、残りの 32 バイトがシリアル化されたクライアントデータのハッシュであるためです。この認証器データ構造では、 rpIdHash は FIDO U2F のアプリケーションパラメーターであり、 UP を除くすべての フラグは常にゼロであり、 attestedCredentialData および 拡張 は存在しません。したがって、FIDO U2F 認証署名は、authenticatorMakeCredential 操作によって生成される他のアサーション署名と同じ手順で検証できます。

6.2. 認証器の分類

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

例:

特定のクライアントデバイスで初めて認証する場合、ユーザーはそのクライアントデバイスにまだプラットフォームクレデンシャルを持っていないため、通常はローミング認証器が必要です。
同じクライアントデバイスでその後再認証する場合、プラットフォーム認証器は、ユーザーが探さなければならない可能性のある別個のデバイスではなく、クライアントデバイスに直接組み込まれているため、最も便利である可能性が高いです。
従来のユーザー名とパスワードに加えて第 2 要素認証を行う場合、任意の認証器を使用できます。
パスワードレスの多要素認証には、ユーザー検証を実行できる認証器が必要であり、場合によっては検出可能なクレデンシャルに対応可能であることも必要です。
ノートパソコンは USB および Bluetooth を介してローミング認証器への接続をサポートする一方、携帯電話は NFC のみをサポートする場合があります。

上記の例は、主要な認証器型の特性を示しています。

認証器がローミング認証器かプラットフォーム認証器か — 認証器アタッチメント方式。ローミング認証器は、クライアントと通信するための 1 つ以上のトランスポートをサポートできます。
認証器がユーザー検証を実行できるかどうか — 認証要素能力。
認証器が検出可能なクレデンシャルに対応可能かどうか — クレデンシャル保存方式。

これらの特性は独立しており、理論上はどのような方法でも組み合わせることができますが、表では、特に重要な認証器型のいくつかを列挙し、名前を付けています。

認証器型	認証器アタッチメント方式	クレデンシャル保存方式	認証要素能力
第 2 要素プラットフォーム認証器	プラットフォーム	いずれか	単一要素対応
ユーザー検証プラットフォーム認証器	プラットフォーム	いずれか	多要素対応
第 2 要素ローミング認証器	クロスプラットフォーム	サーバー側保存	単一要素対応
第 1 要素ローミング認証器	クロスプラットフォーム	クライアント側保存	多要素対応

一部の認証器型の名称の定義。

第 2 要素プラットフォーム認証器は、同じクライアントデバイスでの再認証に便利であり、新しいセッションを開始するときと既存のセッションを再開するときの両方で、追加のセキュリティ層を加えるために使用できます。第 2 要素ローミング認証器は、特定のクライアントデバイスで初めて認証する場合、または複数のユーザーで共有されるクライアントデバイスで使用される可能性が高くなります。

ユーザー検証プラットフォーム認証器および第 1 要素ローミング認証器は、パスワードレスの多要素認証を可能にします。クレデンシャル秘密鍵を所有していることの証明に加えて、これらの認証器は第 2 の認証要素としてユーザー検証をサポートします。通常は PIN または生体認識です。したがって、認証器は 2 種類の認証要素として動作でき、多要素認証を可能にしながら、リライングパーティとパスワードを共有する必要をなくします。

表で名前が付けられていない 4 つの組み合わせは、際立ったユースケースが少なくなります。

クレデンシャル保存方式は、ローミング認証器よりもプラットフォーム認証器では重要度が低くなります。これは、プラットフォーム認証器を使用するユーザーは、通常、セッション Cookie など（すなわち、アンビエントクレデンシャル）によって識別できるためです。
検出可能なクレデンシャルに対応可能だが多要素対応ではないローミング認証器は、ユーザー名なしの単一要素認証に使用できます。この場合、ユーザーはユーザーハンドルによって自動的に識別され、クレデンシャル秘密鍵の所有が唯一の認証要素として使用されます。これは状況によっては有用ですが、ユーザーは認証器の盗難に対して特に脆弱になります。
多要素対応だが検出可能なクレデンシャルに対応可能ではないローミング認証器は、多要素認証に使用できますが、最初にユーザーを識別する必要があり、個人を識別する情報が漏洩するリスクがあります。§ 14.6.3 クレデンシャル ID によるプライバシー漏洩を参照してください。

以下のサブセクションでは、認証器アタッチメント方式、クレデンシャル保存方式、および認証要素能力の各側面について、さらに詳しく定義します。

6.2.1. 認証器アタッチメント方式

クライアントは、さまざまな仕組みを使用して認証器と通信できます。たとえば、クライアントは、クライアントデバイス固有の API を使用して、クライアントデバイスに物理的に結び付けられた認証器と通信してもよいものとします。一方、クライアントは、 Bluetooth などの標準化されたさまざまなクロスプラットフォームトランスポートプロトコル（§ 5.8.4 認証器トランスポート列挙型 (enum AuthenticatorTransport)を参照）を使用して、クロスプラットフォームでアタッチされた認証器を検出し通信できます。クライアントデバイスの一部である認証器をプラットフォーム認証器と呼び、クロスプラットフォームトランスポートプロトコルを介して到達可能なものをローミング認証器と呼びます。

プラットフォーム認証器は、プラットフォームアタッチメントと呼ばれるクライアントデバイス固有のトランスポートを使用してアタッチされ、通常はクライアントデバイスから取り外すことができません。プラットフォーム認証器にバインドされた公開鍵クレデンシャルをプラットフォームクレデンシャルと呼びます。
ローミング認証器は、クロスプラットフォームアタッチメントと呼ばれるクロスプラットフォームトランスポートを使用してアタッチされます。このクラスの認証器はクライアントデバイスから取り外すことができ、クライアントデバイス間を「ローミング」できます。ローミング認証器にバインドされた公開鍵クレデンシャルをローミングクレデンシャルと呼びます。

一部のプラットフォーム認証器は、コンテキストによってはローミング認証器としても動作できる可能性があります。たとえば、モバイルデバイスに統合されたプラットフォーム認証器は、Bluetooth を介して自身をローミング認証器として利用可能にできる場合があります。この場合、モバイルデバイス上で実行されるクライアントは、その認証器をプラットフォーム認証器として認識しますが、別のクライアントデバイス上で実行され、Bluetooth 経由で同じ認証器と通信するクライアントは、それをローミング認証器として認識します。

プラットフォーム認証器の主要なユースケースは、特定のクライアントデバイスを「信頼済みデバイス」として登録し、クライアントデバイス自体が、将来の認証における所有しているものという認証要素として機能するようにすることです。これにより、ユーザーは将来の認証セレモニーでローミング認証器を必要としないという利便性を得られます。たとえば、ユーザーはキーフォブや電話を探すためにポケットを探る必要がなくなります。

ローミング認証器のユースケースには、次のものがあります。新しいクライアントデバイスで初めて認証する場合、使用頻度の低いクライアントデバイス、複数のユーザーで共有されるクライアントデバイス、またはプラットフォーム認証器を備えていないクライアントデバイスで認証する場合、また、ポリシーまたは設定によって、認証器を、それとともに使用するクライアントデバイスから分離して保持する必要がある場合です。ローミング認証器は、別の認証器を紛失した場合に備えて、バックアップクレデンシャルを保持するためにも使用できます。

6.2.2. クレデンシャル保存方式

認証器は、公開鍵クレデンシャルソースを次の 2 つの方法のいずれかで保存できます。

認証器、クライアント、またはクライアントデバイスに組み込まれた永続ストレージ、たとえばセキュアエレメントに保存します。これはクライアント側で検出可能な公開鍵クレデンシャルソースの技術的要件です。
クレデンシャル秘密鍵を暗号化（すなわちラップ）して、この認証器だけがそれを復号（すなわちアンラップ）できるようにし、得られた暗号文を公開鍵クレデンシャルソースのクレデンシャル IDとします。クレデンシャル IDはリライングパーティによって保存され、 get() の allowCredentials オプションを介して認証器に返されます。これにより、認証器はクレデンシャル秘密鍵を復号して使用できます。

これにより、暗号化されたクレデンシャル秘密鍵が認証器ではなくリライングパーティによって保存されるため、認証器はクレデンシャル秘密鍵について無制限の保存容量を持つことができます。ただし、これはこの方法で保存されたクレデンシャルは、認証器が使用できるようになる前にリライングパーティから取得しなければならないことを意味します。

認証器がどの保存戦略をサポートするかによって、認証器のクレデンシャル保存方式は次のように定義されます。

認証器がクライアント側で検出可能な公開鍵クレデンシャルソースをサポートする場合、クライアント側クレデンシャル保存方式を持ちます。クライアント側クレデンシャル保存方式を持つ認証器は、検出可能なクレデンシャルに対応可能とも呼ばれます。
クライアント側クレデンシャル保存方式を持たない認証器は、サーバー側クレデンシャル保存方式を持ちます。すなわち、クレデンシャル秘密鍵をクレデンシャル ID内の暗号文として保存する方法のみをサポートします。

検出可能なクレデンシャルに対応可能な認証器は、両方の保存戦略をサポートしてもよいことに注意してください。この場合、認証器は、 create() の residentKey または requireResidentKey オプションの制約を受けつつ、その裁量で異なるクレデンシャルに異なる保存戦略を使用してもよいものとします。

6.2.3. 認証要素能力

認証セレモニー中に本人性を証明するために使用できる認証要素には、大きく 3 つの種類があります。所有しているもの、知っているもの、および本人そのものです。例として、それぞれ物理鍵、パスワード、指紋があります。

すべてのWebAuthn 認証器は所有しているもののクラスに属しますが、ユーザー検証をサポートする認証器は、さらに 1 つまたは 2 つの種類の認証要素としても動作できます。たとえば、認証器が PIN を検証できる場合、その PIN は知っているものであり、生体認証器は本人そのものを検証できます。したがって、ユーザー検証をサポートする認証器は多要素対応です。逆に、多要素対応ではない認証器は単一要素対応です。単一の多要素対応認証器が複数のユーザー検証方式をサポートする可能性があり、その場合は 3 種類すべての認証要素として動作できることに注意してください。

ユーザー検証はリライングパーティではなく認証器上でローカルに実行されますが、認証器は、リライングパーティに返される署名済みレスポンスの UV フラグを設定することで、ユーザー検証が実行されたかどうかを示します。したがって、リライングパーティは UV フラグを使用して、登録または認証セレモニーで追加の認証要素が使用されたことを検証できます。さらに、認証器のアテステーションステートメントを調べることで、UV フラグの真正性を評価できます。

6.3. 認証器操作

WebAuthn クライアントは、認証器のいずれかの操作を呼び出すために認証器へ接続しなければなりません。この接続によって認証器セッションが定義されます。認証器はセッション間の分離を維持しなければなりません。これは、一度に 1 つのセッションしか存在できないようにするか、より複雑なセッション管理を提供することで実現できます。

以下の操作は、認証器セッション内でクライアントによって呼び出すことができます。

6.3.1. クレデンシャル ID によるクレデンシャルソース検索アルゴリズム

認証器 authenticator でクレデンシャル ID credentialId を検索する結果は、次のアルゴリズムの結果です。

authenticator が credentialId を公開鍵クレデンシャルソース credSource に復号できる場合:
1. credSource.id を credentialId に設定します。
2. credSource を返します。
authenticator のクレデンシャルマップ内の各公開鍵クレデンシャルソース credSource について反復します。
1. credSource.id が credentialId である場合、 credSource を返します。
null を返します。

6.3.2. authenticatorMakeCredential 操作

次の入力パラメーターを取ります。

hash: クライアントによって提供されるシリアル化されたクライアントデータのハッシュ。
rpEntity: リライングパーティの PublicKeyCredentialRpEntity。
userEntity: リライングパーティによって与えられたユーザーハンドルを含む、ユーザーアカウントの PublicKeyCredentialUserEntity。
requireResidentKey: クライアントによって決定される Boolean 値である、クレデンシャル作成における実効常駐キー要件。
requireUserPresence: 定数 Boolean 値 true。これは、WebAuthn では任意ではないユーザー存在のテストを任意にしたい実装にこの抽象認証器モデルを適用することを簡素化するため、疑似パラメーターとしてここに含まれています。
requireUserVerification: クライアントによって決定される Boolean 値である、クレデンシャル作成における実効ユーザー検証要件。
credTypesAndPubKeyAlgs: リライングパーティによって要求された PublicKeyCredentialType と公開鍵アルゴリズム（COSEAlgorithmIdentifier）のペアのシーケンス。このシーケンスは最も優先度の高いものから最も低いものの順に並べられます。認証器は、作成可能な中で最も優先度の高いクレデンシャルを作成するよう最善を尽くします。
excludeCredentialDescriptorList: リライングパーティによって提供される任意の PublicKeyCredentialDescriptor オブジェクトのリストであり、これらのいずれかが認証器に既知である場合、新しいクレデンシャルを作成すべきではないことを意図します。 excludeCredentialDescriptorList には、既知のクレデンシャルのリストが含まれます。
enterpriseAttestationPossible: 個別識別可能なアテステーションを認証器が返してもよいことを示す Boolean 値。
extensions: 拡張がある場合、リライングパーティによって要求された拡張に基づいてクライアントが作成した、拡張識別子からそれぞれの認証器拡張入力への CBOR マップ。

注: この操作を実行する前に、認証器セッションで進行中の他のすべての操作は、 authenticatorCancel 操作を実行して中止しなければなりません。

この操作が呼び出された場合、認証器は次の手順を実行しなければなりません。

提供されたすべてのパラメーターが構文的に整形式であり、正しい長さであるか確認します。そうでない場合、 "UnknownError" と同等のエラーコードを返し、操作を終了します。
credTypesAndPubKeyAlgs で指定された PublicKeyCredentialType と暗号パラメーターの組み合わせのうち、少なくとも 1 つがサポートされているか確認します。サポートされていない場合、"NotSupportedError" と同等のエラーコードを返し、操作を終了します。
excludeCredentialDescriptorList の各 descriptor について反復します。
1. この認証器で descriptor.id を検索した結果が null ではなく、返された項目のRP IDとtypeがそれぞれ rpEntity.id および excludeCredentialDescriptorList.type と一致する場合、新しいクレデンシャルの作成に対するユーザーの同意を確認する認可ジェスチャーを収集します。認可ジェスチャーにはユーザー存在のテストを含めなければなりません。ユーザーが
  
  新しいクレデンシャルを作成することに同意したことを確認する
  
  "InvalidStateError" と同等のエラーコードを返し、操作を終了します。
  
  新しいクレデンシャルを作成することに同意しない
  
  "NotAllowedError" と同等のエラーコードを返し、操作を終了します。
  
  注: この認可ジェスチャーの目的はクレデンシャルの作成を進めることではなく、プライバシー上の理由から descriptor.id がこの認証器にバインドされているという事実の開示を認可することです。ユーザーが同意した場合、クライアントとリライングパーティはこれを検出し、別の認証器を使用するようユーザーを案内できます。ユーザーが同意しない場合、認証器は descriptor.id が自身にバインドされていることを明らかにせず、ユーザーが単にクレデンシャルの作成への同意を拒否したかのように応答します。
requireResidentKey が true で、認証器がクライアント側で検出可能な公開鍵クレデンシャルソースを保存できない場合、 "ConstraintError" と同等のエラーコードを返し、操作を終了します。
requireUserVerification が true で、認証器がユーザー検証を実行できない場合、"ConstraintError" と同等のエラーコードを返し、操作を終了します。
新しいクレデンシャルの作成に対するユーザーの同意を確認する認可ジェスチャーを収集します。認可ジェスチャーのプロンプトは、認証器が独自の出力機能を持つ場合は認証器によって表示され、それ以外の場合はユーザーエージェントによって表示されます。可能であれば、プロンプトには rpEntity.id、 rpEntity.name、 userEntity.name および userEntity.displayName を表示すべきです。
requireUserVerification が true の場合、認可ジェスチャーにはユーザー検証を含めなければなりません。

requireUserPresence が true の場合、認可ジェスチャーにはユーザー存在のテストを含めなければなりません。

ユーザーが同意しない場合、またはユーザー検証に失敗した場合、"NotAllowedError" と同等のエラーコードを返し、操作を終了します。
認可ジェスチャーが完了し、ユーザーの同意が得られたら、新しいクレデンシャルオブジェクトを生成します。
1. (publicKey, privateKey) を、 credTypesAndPubKeyAlgs 内でこの認証器がサポートする最初の項目によって表される PublicKeyCredentialType と暗号パラメーターの組み合わせを使用した、新しい暗号鍵のペアとします。
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 をこの認証器のクレデンシャルマップとします。
  4. credentials[(rpEntity.id, userHandle)] を credentialSource に設定します。
5. それ以外の場合:
  1. credentialId を、credentialSource をシリアル化して暗号化し、この認証器だけが復号できるようにした結果とします。
新しいクレデンシャルオブジェクトの作成中にエラーが発生した場合、 "UnknownError" と同等のエラーコードを返し、操作を終了します。
processedExtensions を、extensions 内のサポートされる各拡張識別子 → 認証器拡張入力について認証器拡張処理を実行した結果とします。
認証器が:

U2F デバイスである

新しいクレデンシャルの署名カウンター値をゼロとします。（U2F デバイスは署名カウンターをサポートする場合がありますが、クレデンシャル作成時にはカウンターを返しません。 [FIDO-U2F-Message-Formats]を参照してください。）

グローバルな署名カウンターをサポートする

認証器データを生成する際、グローバルな署名カウンターの実際の値を使用します。

クレデンシャルごとの署名カウンターをサポートする

カウンターを割り当て、新しいクレデンシャルに関連付け、カウンター値をゼロに初期化します。

署名カウンターをサポートしない

新しいクレデンシャルの署名カウンター値を常にゼロとします。
attestedCredentialData を、credentialId および publicKey を含むアテステーション済みクレデンシャルデータのバイト配列とします。
authenticatorData を、§ 6.1 認証器データで規定されたバイト配列とし、 attestedCredentialData を attestedCredentialData として含め、processedExtensions がある場合は 拡張 として含めます。
新しいクレデンシャルのアテステーションオブジェクトを、§ 6.5.4 アテステーションオブジェクトの生成で規定された手順を使用して作成します。認証器が選択したアテステーションステートメント形式、authenticatorData、および hash を使用し、さらに enterpriseAttestationPossible の値を考慮します。アテステーションの詳細については、§ 6.5 アテステーションを参照してください。

この操作が正常に完了すると、認証器はアテステーションオブジェクトをクライアントへ返します。

6.3.3. authenticatorGetAssertion 操作

次の入力パラメーターを取ります。

rpId: ユーザーエージェントとクライアントによって決定された、呼び出し元のRP ID。
hash: クライアントによって提供されるシリアル化されたクライアントデータのハッシュ。
allowCredentialDescriptorList: 存在する場合、リライングパーティに受け入れ可能なクレデンシャルを記述する、任意のリストの PublicKeyCredentialDescriptor。（クライアントによってフィルタリングされている可能性があります。）
requireUserPresence: 定数 Boolean 値 true。これは、WebAuthn では任意ではないユーザー存在のテストを任意にしたい実装にこの抽象認証器モデルを適用することを簡素化するため、疑似パラメーターとしてここに含まれています。
requireUserVerification: クライアントによって提供される Boolean 値である、アサーションにおける実効ユーザー検証要件。
extensions: 拡張がある場合、リライングパーティによって要求された拡張に基づいてクライアントが作成した、拡張識別子からそれぞれの認証器拡張入力への CBOR マップ。

注: この操作を実行する前に、認証器セッションで進行中の他のすべての操作は、authenticatorCancel 操作を実行して中止しなければなりません。

このメソッドが呼び出された場合、認証器は次の手順を実行しなければなりません。

提供されたすべてのパラメーターが構文的に整形式であり、正しい長さであるか確認します。そうでない場合、 "UnknownError" と同等のエラーコードを返し、操作を終了します。
credentialOptions を、公開鍵クレデンシャルソースの新しい空の集合とします。
allowCredentialDescriptorList が提供された場合、allowCredentialDescriptorList の各 descriptor について反復します。
1. credSource を、この認証器で descriptor.id を検索した結果とします。
2. credSource が null でない場合、credentialOptions にそれを追加します。
それ以外の場合（allowCredentialDescriptorList が提供されなかった場合）、この認証器のクレデンシャルマップの各 key → credSource について反復し、 credentialOptions に credSource を追加します。
rpId が rpId と等しくない項目を credentialOptions から削除します。
credentialOptions が空になった場合、"NotAllowedError" と同等のエラーコードを返し、操作を終了します。
credentialOptions から公開鍵クレデンシャルソース selectedCredential を選択するようユーザーに求めます。 selectedCredential を使用することへのユーザーの同意を確認する認可ジェスチャーを収集します。認可ジェスチャーのプロンプトは、独自の出力機能を持つ場合は認証器によって、それ以外の場合はユーザーエージェントによって表示されてもよいものとします。

requireUserVerification が true の場合、認可ジェスチャーにはユーザー検証を含めなければなりません。

requireUserPresence が true の場合、認可ジェスチャーにはユーザー存在のテストを含めなければなりません。

ユーザーが同意しない場合、"NotAllowedError" と同等のエラーコードを返し、操作を終了します。
processedExtensions を、extensions 内のサポートされる各拡張識別子 → 認証器拡張入力について認証器拡張処理を実行した結果とします。
認証器が実装している方法に応じて、クレデンシャルに関連付けられた署名カウンターまたはグローバルな署名カウンター値を何らかの正の値だけ増加させます。認証器が署名カウンターを実装していない場合、署名カウンター値を常にゼロのままとします。
authenticatorData を、§ 6.1 認証器データで規定されたバイト配列とし、 processedExtensions がある場合は 拡張 として含め、 attestedCredentialData は含めません。
signature を、以下の図に示すように、 selectedCredential のprivateKeyを使用した、連結 authenticatorData || hash のアサーション署名とします。単純な区切りなしの連結をここで安全に使用できるのは、認証器データが自身の長さを記述するためです。シリアル化されたクライアントデータのハッシュ（可変長である可能性があります）は常に最後の要素です。

アサーション署名の生成。
アサーション署名の生成中にエラーが発生した場合、 "UnknownError" と同等のエラーコードを返し、操作を終了します。
ユーザーエージェントに次を返します。
- クライアントによって長さ 2 以上のクレデンシャル一覧（すなわち allowCredentialDescriptorList）が提供された場合、またはそのような一覧が提供されなかった場合、 selectedCredential.id。
  
  注: allowCredentialDescriptorList 内で、クライアントがちょうど 1 つのクレデンシャルを提供し、それが正常に使用された場合、そのクレデンシャル IDは、クライアントがすでに知っているため返されません。これは、一般的である可能性の高いケースにおいて、制約のある可能性がある接続を介してこれらのバイトを送信する必要をなくします。
- authenticatorData
- signature
- selectedCredential.userHandle
  
  注: 返されるuserHandle 値は null の場合があります。userHandleResultを参照してください。

認証器が、指定されたリライングパーティに対応し、指定された基準に一致するクレデンシャルを見つけられない場合、操作を終了してエラーを返します。

6.3.4. authenticatorCancel 操作

この操作は入力パラメーターを取らず、結果も返しません。

この操作が認証器セッション内でクライアントによって呼び出されると、その認証器セッション内で現在進行中のauthenticatorMakeCredential または authenticatorGetAssertion 操作を終了する効果があります。認証器は、キャンセルされた操作の認可に関連するユーザー入力を求めたり受け付けたりすることを停止します。クライアントは、キャンセルされた操作について認証器から送られるその後のレスポンスをすべて無視します。

この操作が、現在進行中のauthenticatorMakeCredential または authenticatorGetAssertion 操作を持たない認証器セッション内で呼び出された場合、この操作は無視されます。

6.4. 文字列の処理

認証器は、リライングパーティによって選択された任意の文字列、たとえば name や displayName を PublicKeyCredentialUserEntity 内に保存する必要がある場合があります。このセクションでは、人間に提示される可能性のある任意の文字列を扱うことによる実際上のいくつかの影響について説明します。

6.4.1. 文字列の切り詰め

API 内の各任意文字列には、認証器で利用可能なリソースが限られている可能性に対応する何らかの仕組みがあります。文字列値の切り詰めが選択された対応方法である場合、認証器は、指定された最小サポート長以上の長さに文字列が収まるよう切り詰めてもよいものとします。このような切り詰めでは、 UTF-8 シーケンス境界または書記素クラスタ境界 [UTR29] も尊重すべきです。これは許可される最大の切り詰めを定義するものであり、認証器はそれ以上切り詰めてはなりません。

たとえば、図では、文字列の長さは 65 バイトです。64 バイトに切り詰める場合、最後の 0x88 バイトは純粋に容量上の理由から削除しなければなりません。そうすると不完全な UTF-8 シーケンスが残るため、そのシーケンスの残りも削除してもよいものとします。さらに、それによって不完全な書記素クラスタが残るため、認証器はそのクラスタの残りを削除してもよいものとします。

適合ユーザーエージェントは、リライングパーティから観測される認証器の動作が、文字列処理に関してこの仕様に適合することを保証する責任を負います。たとえば、認証器が大きな文字列を保存するよう要求されたときに正しく動作しないことが分かっている場合、ユーザーエージェントはリライングパーティの観点からモデルを維持するため、その認証器に代わって切り詰めを実行すべきです。これを行うユーザーエージェントは、書記素クラスタ境界で切り詰めるべきです。

UTF-8 シーケンスのみに基づく切り詰めでは、書記素クラスタが切り詰められる場合があります。これにより、グリフ全体が削除されるのではなく、その書記素クラスタが別のグリフとして描画され、文字列の意味が変わる可能性があります。

さらに、バイト境界だけで切り詰めると、ユーザーエージェントが認識しておくべき既知の問題が発生します。認証器が [FIDO-CTAP] を使用している場合、その値は CBOR 文字列として型付けされており、有効な UTF-8 であることが要求されるため、認証器からの将来のメッセージに無効な CBOR が含まれる可能性があります。認証器に文字エンコーディングや Unicode 文字プロパティを理解させる負担をかけないため、これを処理する責任はユーザーエージェントにあります。したがって、認証器を扱う際、ユーザーエージェントは次のようにすべきです。

認証器へ送信されるすべての文字列が有効にエンコードされていることを保証します。
文字列が切り詰められた結果、無効なエンコーディングになった場合を処理します。たとえば、末尾の不完全なコードポイントを削除するか、U+FFFD に置き換えることができます。

6.4.2. 言語および方向のエンコーディング

コンテキスト内で正しく表示するため、文字列の言語と基本方向が必要になる場合があります。この API の文字列は、固定機能の認証器へ書き込まれ、その後別のプラットフォームで読み戻され表示される必要がある場合があります。したがって、言語および方向のメタデータは、一体として転送されることを保証するため文字列自体にエンコードされます。

言語および方向のメタデータを含めることが許可されていると文書化された文字列にそれらをエンコードするには、そのコードポイントの末尾に 2 つのコードポイントシーケンスを付加します。

最初のシーケンスは言語タグをエンコードします。コードポイント U+E0001 の後に、言語タグの各 ASCII 値を U+E0000 だけ上方へシフトした値を続けます。たとえば、言語タグ “en-US” は、コードポイント U+E0001、U+E0065、U+E006E、 U+E002D、U+E0055、U+E0053 になります。

2 番目のシーケンスは、U+200E（“LEFT-TO-RIGHT MARK”）、U+200F （“RIGHT-TO-LEFT MARK”）、または U+E007F（“CANCEL TAG”）のいずれか 1 つのコードポイントで構成されます。最初の 2 つは方向性を示すために使用できますが、正しい結果を生成するために必要な場合にのみ使用すべきです。（たとえば、LTR 強文字で始まる RTL 文字列。）値 U+E007F は、言語タグの終端を示す、方向に依存しない標識です。

したがって、文字列 “حبیب الرحمان” は、言語がエンコードされているかどうかに応じて 2 つの異なる DOMString 値を持つことができます。（方向は曖昧ではないため、この例では方向性マーカーは不要です。）

装飾なしの文字列: U+FEA2, U+FE92, U+FBFF, U+FE91, U+20, U+FE8E, U+FEDF, U+FEAE, U+FEA4, U+FEE3, U+FE8E, U+FEE7
言語 “ar-SA” をエンコードした場合: U+FEA2, U+FE92, U+FBFF, U+FE91, U+20, U+FE8E, U+FEDF, U+FEAE, U+FEA4, U+FEE3, U+FE8E, U+FEE7, U+E0001, U+E0061, U+E0072, U+E002D, U+E0053, U+E0041, U+E007F

言語および方向がエンコードされる可能性のある文字列の利用者は、切り詰めによって言語タグが、別の有効な言語へ切り詰められる可能性があることに注意すべきです。最後の方向性マーカーまたは CANCEL TAG コードポイントは、切り詰めを曖昧さなく示します。

6.5. アテステーション

認証器は、可能であれば何らかの形式のアテステーションも提供すべきです。認証器がこれを行う場合、基本的な要件は、認証器が各クレデンシャル公開鍵について、WebAuthn リライングパーティによって検証可能なアテステーションステートメントを生成できることです。通常、このアテステーションステートメントには、アテステーション対象のクレデンシャル公開鍵およびチャレンジに対するアテステーション秘密鍵による署名と、アテステーション公開鍵の来歴情報を提供する証明書または同様のデータが含まれ、リライングパーティが信頼性を判断できるようにします。ただし、アテステーションキーペアが利用できない場合、認証器は対応するクレデンシャル秘密鍵を使用してクレデンシャル公開鍵の自己アテステーションを実行するか、そうでなければアテステーションを行わないことができます。これらの情報はすべて、新しい公開鍵クレデンシャルが生成されるたびに、認証器から、全体としてアテステーションオブジェクトの形式で返されます。アテステーションオブジェクトと認証器データ（アテステーション済みクレデンシャルデータを含む）およびアテステーションステートメントとの関係は、以下の図に示されています。

認証器が自己アテステーションまたはアテステーションなしを使用する場合、リライングパーティが信頼性の判断の基礎とする来歴情報は提供されません。これらの場合、認証器は、その動作についてリライングパーティに何の保証も提供しません。

アテステーションオブジェクトのレイアウト。含まれる認証器データ（アテステーション済みクレデンシャルデータを含む）およびアテステーションステートメントを示します。

この図は packed アテステーションステートメント形式のみを示しています。追加の複数のアテステーションステートメント形式が § 8 定義済みアテステーションステートメント形式で定義されています。

アテステーションオブジェクトの重要な構成要素は、アテステーションステートメントです。これは、公開鍵クレデンシャル自体およびそれを作成した認証器についての表明を含む、特定の種類の署名済みデータオブジェクトです。これには、アテステーション機関の鍵を使用して作成されたアテステーション署名が含まれます（自己アテステーションの場合を除き、その場合はクレデンシャル秘密鍵を使用して作成されます）。アテステーションステートメントを正しく解釈するため、リライングパーティは、アテステーションの次の 2 つの側面を理解する必要があります。

アテステーションステートメント形式は、署名がどのように表現され、さまざまなコンテキスト上のバインディングが認証器によってアテステーションステートメントに組み込まれるかを定義します。言い換えると、これはステートメントの構文を定義します。既存のさまざまなコンポーネントや OS プラットフォーム（TPM や Android OS など）は、以前からアテステーションステートメント形式を定義しています。この仕様は、 § 6.5.2 アテステーションステートメント形式で定義されるように、そのようなさまざまな形式を拡張可能な方法でサポートします。形式自体は、§ 8.1 アテステーションステートメント形式識別子で説明される文字列によって識別されます。
アテステーション型は、アテステーションステートメントの意味論と、その基礎となる信頼モデルを定義します。具体的には、リライングパーティが、暗号学的に有効であることを検証した後に、特定のアテステーションステートメントへの信頼をどのように確立するかを定義します。この仕様は、アテステーション型を複数サポートし、 § 6.5.3 アテステーション型で説明されています。

一般に、アテステーションステートメント形式とアテステーション型との間に単純な対応関係はありません。たとえば、 § 8.2 Packed アテステーションステートメント形式で定義される "packed" アテステーションステートメント形式は、すべてのアテステーション型と組み合わせて使用できますが、他の形式と型にはより限定的な適用範囲があります。

アテステーションのプライバシー、セキュリティ、および運用上の特性は、次の要素に依存します。

信頼モデルを決定するアテステーション型、
アテステーションステートメントで表現できる内容を制限することによって、アテステーションの強度を制約する場合があるアテステーションステートメント形式、および
構造、全部または一部が安全な実行環境で動作するかどうかなど、個々の認証器の特性。

ほとんどの認証器は少数のアテステーション型とアテステーションステートメント形式をサポートし、一方でリライングパーティはポリシーにより、どのアテステーション型を受け入れ可能とするかを決定すると予想されます。リライングパーティはまた、信頼する認証器の特性を、それらの認証器について持っている情報に基づいて理解する必要があります。たとえば、FIDO Metadata Service [FIDOMetadataService] は、そのような情報へアクセスする方法の 1 つを提供します。

6.5.1. アテステーション済みクレデンシャルデータ

アテステーション済みクレデンシャルデータは、所与のクレデンシャルについてアテステーションオブジェクトを生成するときに認証器データへ追加される可変長のバイト配列です。その形式は表に示されています。

名前	長さ（バイト単位）	説明
aaguid	16	認証器の AAGUID。
credentialIdLength	2	クレデンシャル ID のバイト長 L。16 ビット符号なしビッグエンディアン整数。
credentialId	L	クレデンシャル ID
credentialPublicKey	可変	[RFC8152] のセクション 7で定義される COSE_Key 形式でエンコードされたクレデンシャル公開鍵であり、CTAP2 正規 CBOR エンコーディング形式を使用します。 COSE_Key でエンコードされたクレデンシャル公開鍵は "alg" パラメーターを含まなければならず、他の任意パラメーターを含んではなりません。"alg" パラメーターは `COSEAlgorithmIdentifier` 値を含まなければなりません。エンコードされたクレデンシャル公開鍵はまた、関連する鍵型仕様によって規定される追加の必須パラメーター、すなわち鍵型 "kty" およびアルゴリズム "alg" に対して必須のものを含まなければなりません（[RFC8152] のセクション 8 を参照）。

アテステーション済みクレデンシャルデータのレイアウト。名前列の名前はこの文書内で参照するためだけのものであり、実際のアテステーション済みクレデンシャルデータの表現には存在しません。

6.5.1.1. COSE_Key 形式でエンコードされた `credentialPublicKey` 値の例

このセクションでは、ES256、PS256、および RS256 署名アルゴリズム用の COSE_Key エンコードされた楕円曲線および RSA 公開鍵の例を示します。これらの例は、上記で定義したcredentialPublicKey 値の規則に従い、明確さのため CDDL [RFC8610] で示されています。

[RFC8152] のセクション 7は、すべての COSE_Key エンコードされた鍵の一般的な枠組みを定義します。特定のアルゴリズム用の特定の鍵型は、以下で示すように、[RFC8152] の他のセクションや他の仕様で定義されています。

以下は、P-256 曲線上の、EC2 形式（[RFC8152] のセクション 13.1を参照）の COSE_Key エンコードされた楕円曲線公開鍵の例であり、 ES256 署名アルゴリズム（SHA-256 を使用する ECDSA、[RFC8152] のセクション 8.1を参照）で使用します。

{
  1:   2,  ; kty: EC2 鍵t型
  3:  -7,  ; alg: ES256 署名アルゴリズム
 -1:   1,  ; crv: P-256 曲線
 -2:   x,  ; x-座標をバイト列として、長さ 32 バイト
           ; 例: 16進数: 65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c08551d
 -3:   y   ; y-座標をバイト列として、長さ 32 バイト
           ; 例: 16進数: 1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd0084d19c
}

以下は、上記の楕円曲線公開鍵をCTAP2 正規 CBOR エンコーディング形式でエンコードしたものです。空白と改行は、明確さのため、および上記の CDDL [RFC8610] の表現に合わせるために含まれています。

A5
   01  02

   03  26

   20  01

   21  58 20   65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c08551d

   22  58 20   1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd0084d19c

以下は、PS256 署名アルゴリズムで使用する COSE_Key エンコードされた 2048 ビット RSA 公開鍵（[RFC8230] のセクション 4を参照）の例です。（SHA-256 を使用する RSASSA-PSS、[RFC8230] のセクション 2を参照）:

{
  1:   3,  ; kty: RSA 鍵t型
  3: -37,  ; alg: PS256
 -1:   n,  ; n:   RSA 法n、長さ 256 バイトのバイト列
           ;      例: 16進数（簡潔にするため中間バイトを省略）: DB5F651550...6DC6548ACC3
 -2:   e   ; e:   RSA 公開指数 e、長さ 3 バイトのバイト列
           ;      例: 16進数: 010001
}

以下は、上記と同じ COSE_Key エンコードされた RSA 公開鍵を、 RS256 署名アルゴリズム（SHA-256 を使用する RSASSA-PKCS1-v1_5）で使用する例です。

{
  1:   3,  ; kty: RSA 鍵t型
  3:-257,  ; alg: RS256
 -1:   n,  ; n:   RSA 法n、長さ 256 バイトのバイト列
           ;      例: 16進数（簡潔にするため中間バイトを省略）: DB5F651550...6DC6548ACC3
 -2:   e   ; e:   RSA 公開指数 e、長さ 3 バイトのバイト列
           ;      例: 16進数: 010001
}

6.5.2. アテステーションステートメント形式

上記で説明したように、アテステーションステートメント形式は、一連のコンテキスト上のバインディングに対する認証器による暗号署名を表現するデータ形式です。各アテステーションステートメント形式は、次のテンプレートを使用して定義しなければなりません。

アテステーションステートメント形式識別子:
サポートされるアテステーション型:
構文: この形式で生成されるアテステーションステートメントの構文。§ 6.5.4 アテステーションオブジェクトの生成で定義される拡張ポイント $attStmtFormatについて、CDDL [RFC8610]を使用して定義します。
署名手順: アテステーション対象の公開鍵クレデンシャル、アテステーション用の認証器データを含む認証器データ構造、およびシリアル化されたクライアントデータのハッシュが与えられたとき、この形式のアテステーションステートメントを計算するための署名手順。
検証手順: アテステーションステートメントを検証するための手順で、次の検証手順の入力を取ります。
- attStmt: アテステーションステートメント構造
- authenticatorData: アテステーションに使用されたと主張される認証器データ
- clientDataHash: シリアル化されたクライアントデータのハッシュ
この手順は次のいずれかを返します。
- アテステーションが無効であることを示すエラー、または
- アテステーション型および信頼パスを表す実装固有の値。このアテステーション信頼パスは、空（自己アテステーションの場合）か、X.509 証明書の集合です。

最初に規定されるアテステーションステートメント形式の一覧は、§ 8 定義済みアテステーションステートメント形式にあります。

6.5.3. アテステーション型

WebAuthn は、アテステーションステートメントの意味論と、その基礎となる信頼モデルを定義する、複数のアテステーション型をサポートします。

注: この仕様は、認証器によって使用されるアテステーション型を明示的に表すデータ構造を定義しません。アテステーションステートメントの検証を行うリライングパーティ — すなわち、 navigator.credentials.create() を呼び出す際に none 以外のアテステーション伝達を選択し、受け取ったアテステーションステートメントを検証する場合 — は、検証の一部として、使用されたアテステーション型を決定します。 § 8 定義済みアテステーションステートメント形式の「検証手順」サブセクションを参照してください。§ 14.4.1 アテステーションのプライバシーも参照してください。このセクションで定義されるアテステーション型のうち、自己およびなしを除くすべてについて、リライングパーティによる検証の後、 § 7.1 新しいクレデンシャルの登録のステップ 21 に従って、信頼パスを許容可能なルート証明書と照合します。これらのアテステーション型を区別することは、主としてリライングパーティのポリシー上、アテステーションが許容可能かどうかを判断する手段として有用になります。

基本アテステーション (Basic)

基本アテステーション [UAFProtocol] の場合、認証器のアテステーションキーペアは、認証器の「モデル」、すなわち認証器の「バッチ」に固有です。したがって、同じまたは類似したモデルの認証器は、しばしば同じアテステーションキーペアを共有します。詳細については、§ 14.4.1 アテステーションのプライバシーを参照してください。

基本アテステーションは、バッチアテステーションとも呼ばれます。

自己アテステーション (Self)

自己アテステーション（代替基本アテステーション [UAFProtocol] とも呼ばれます）の場合、認証器は固有のアテステーションキーペアを持ちません。代わりに、クレデンシャル秘密鍵を使用してアテステーション署名を作成します。アテステーション秘密鍵に対する有意な保護対策を持たない認証器は、通常このアテステーション型を使用します。

アテステーション CA (AttCA)

この場合、認証器は Trusted Platform Module (TPM) を基盤とし、認証器固有の「エンドースメント鍵」(EK) を保持します。この鍵は、信頼された第三者であるアテステーション CA [TCG-CMCProfile-AIKCertEnroll]（以前は「Privacy CA」と呼ばれていました）と安全に通信するために使用されます。認証器は複数のアテステーション ID キーペア (AIK) を生成し、各 AIK についてアテステーション CAに AIK 証明書の発行を要求できます。この方式を使用すると、このような認証器は、EK（グローバルな相関ハンドル）の露出をアテステーション CA に限定できます。AIK は、認証器が生成した各公開鍵クレデンシャルごとに個別に要求でき、リライングパーティへアテステーション証明書として伝達できます。

注: この概念では通常、複数のアテステーション証明書が生成されます。直近に要求されたアテステーション証明書は「active」と呼ばれます。

匿名化 CA (AnonCA)

この場合、認証器は、匿名化 CAを使用して、クレデンシャルごとのアテステーション証明書を動的に生成し、アテステーションステートメントがリライングパーティに提示されても、例えば追跡目的で使用される可能性のある一意に識別可能な情報を提供しないようにします。

注: AttCA または AnonCA 型のアテステーションを伝達するアテステーションステートメントは、型 Basic のものと同じデータ構造を使用するため、3 つのアテステーション型は一般に、アテステーションステートメントで伝達されるアテステーション証明書の内容について外部から提供される知識によってのみ区別できます。

アテステーションステートメントなし (None)

この場合、アテステーション情報は利用できません。§ 8.7 None アテステーションステートメント形式も参照してください。

6.5.4. アテステーションオブジェクトの生成

次の値が与えられたとき、アテステーションオブジェクト（図 6を参照）を生成するには:

attestationFormat: アテステーションステートメント形式。
authData: 認証器データを含むバイト配列。
hash: シリアル化されたクライアントデータのハッシュ。

認証器は次の処理を行わなければなりません。

attStmt を、authData と hash を与えて attestationFormat の署名手順を実行した結果とします。
fmt を attestationFormat のアテステーションステートメント形式識別子とします。

このアルゴリズムで初期化された変数を設定した、次の構文を持つ CBOR マップとしてアテステーションオブジェクトを返します。

    attObj = {
                authData: bytes,
                $$attStmtType
             }

    attStmtTemplate = (
                          fmt: text,
                          attStmt: { * tstr => any } ; マップは各具体的な attStmtType によって設定される
                      )

    ; すべてのアテステーションステートメント形式は上記のフィールドを持たなければならない
    attStmtTemplate .within $$attStmtType

6.5.5. Packed アテステーション、FIDO U2F アテステーション、およびアサーション署名の署名形式

COSEAlgorithmIdentifier -7 (ES256) およびその他の ECDSA ベースのアルゴリズムについて、sig 値は [RFC3279] セクション 2.2.3 で定義される ASN.1 DER Ecdsa-Sig-Value としてエンコードしなければなりません。

        例:
        30 44                                ; SEQUENCE (68 バイト)
            02 20                            ; INTEGER (32 バイト)
            |  3d 46 28 7b 8c 6e 8c 8c  26 1c 1b 88 f2 73 b0 9a
            |  32 a6 cf 28 09 fd 6e 30  d5 a7 9f 26 37 00 8f 54
            02 20                            ; INTEGER (32 バイト)
            |  4e 72 23 6e a3 90 a9 a1  7b cf 5f 7a 09 d6 3a b2
            |  17 6c 92 bb 8e 36 c0 41  98 a2 7b 90 9b 6e 8f 13

注: CTAP1/U2F 認証器はすでにこの形式で署名値を生成しているため、一貫性のため CTAP2 認証器も同じ形式で署名値を生成します。

新たに定義されるアテステーション形式では ASN.1 エンコーディングを使用せず、代わりに、[RFC8152] および [RFC8230] で定義される COSE 署名と同じ表現を使用して、内部構造を持たない同等の固定長バイト配列として署名を表現することが推奨されます。

以下の署名形式定義はこの要件を満たし、ここで明示的に言及されていない他の署名アルゴリズムについて同様の形式を導出するための例として機能します。

COSEAlgorithmIdentifier -257 (RS256) の場合、sig は、 SHA-256 をハッシュ関数として使用し、[RFC8017] のセクション 8.2.1 で定義される RSASSA-PKCS1-v1_5 署名方式を使用して生成された署名を含まなければなりません。署名は ASN.1 でラップされません。
COSEAlgorithmIdentifier -37 (PS256) の場合、sig は、 SHA-256 をハッシュ関数として使用し、[RFC8017] のセクション 8.1.1 で定義される RSASSA-PSS 署名方式を使用して生成された署名を含まなければなりません。署名は ASN.1 でラップされません。

7. WebAuthn リライングパーティの操作

登録または認証セレモニーは、WebAuthn リライングパーティがそれぞれ PublicKeyCredentialCreationOptions または PublicKeyCredentialRequestOptions オブジェクトを作成することから始まります。これらはセレモニーのパラメーターをエンコードします。リライングパーティは、この段階で機密情報を漏洩しないよう注意すべきです。詳細については、§ 14.6.2 ユーザー名列挙を参照してください。

create() または get() が正常に実行されると、リライングパーティのスクリプトはクライアントから、それぞれ AuthenticatorAttestationResponse または AuthenticatorAssertionResponse 構造を含む PublicKeyCredential を受け取ります。次に、この構造の内容を、この仕様の範囲外の方法を使用してリライングパーティのサーバーへ送信しなければなりません。このセクションでは、これらの構造を受け取った際にリライングパーティが実行しなければならない操作について説明します。

7.1. 新しいクレデンシャルの登録

登録セレモニーを実行するには、リライングパーティは次のように進めなければなりません。

options を、セレモニーにおけるリライングパーティの要件に合わせて構成された、新しい PublicKeyCredentialCreationOptions 構造とします。
navigator.credentials.create() を呼び出し、options を publicKey オプションとして渡します。 credential を、正常に解決された Promise の結果とします。 Promise が拒否された場合は、ユーザーに見えるエラーを表示してセレモニーを中止するか、拒否された Promise で利用可能なコンテキストから判断できる場合は、それに応じてユーザー体験を案内します。たとえば、Promise が "InvalidStateError" と同等のエラーコードで拒否された場合、ユーザーに別の認証器を使用するよう案内できます。さまざまなエラーコンテキストと、それらが発生する状況については、§ 6.3.2 authenticatorMakeCredential 操作を参照してください。
response を credential.response とします。 response が AuthenticatorAttestationResponse のインスタンスでない場合、ユーザーに見えるエラーを表示してセレモニーを中止します。
clientExtensionResults を、 credential.getClientExtensionResults() を呼び出した結果とします。
JSONtext を、 response.clientDataJSON の値にUTF-8 デコードを実行した結果とします。

注: UTF-8 デコードアルゴリズムによって得られるものと同じ結果が得られる限り、任意の UTF-8 デコード実装を使用して構いません。特に、先頭のバイトオーダーマーク (BOM) はすべて除去しなければなりません。
C を、クレデンシャル作成中に収集されたと主張されるクライアントデータとし、JSONtext に対して実装固有の JSON パーサーを実行した結果とします。

注: このアルゴリズムで必要とされるように、 C の構成要素を参照できる限り、C は任意の実装固有のデータ構造表現で構いません。
C.type の値が webauthn.create であることを検証します。
C.challenge の値が options.challenge の base64url エンコーディングと等しいことを検証します。
C.origin の値がリライングパーティのオリジンと一致することを検証します。
C.tokenBinding.status の値が、アサーションを取得した TLS 接続におけるToken Binding の状態と一致することを検証します。その TLS 接続でToken Binding が使用された場合は、 C.tokenBinding.id が、接続のToken Binding ID のbase64url エンコーディングと一致することも検証します。
hash を、 response.clientDataJSON に対して SHA-256 を使用してハッシュを計算した結果とします。
AuthenticatorAttestationResponse 構造の attestationObject フィールドを CBOR デコードして、アテステーションステートメント形式 fmt、認証器データ authData、およびアテステーションステートメント attStmt を取得します。
authData 内の rpIdHash が、リライングパーティが期待するRP ID の SHA-256 ハッシュであることを検証します。
authData 内の flags のユーザー存在ビットが設定されていることを検証します。
この登録でユーザー検証が必要な場合、authData 内の flags のユーザー検証済みビットが設定されていることを検証します。
authData 内のクレデンシャル公開鍵の "alg" パラメーターが、 options.pubKeyCredParams 内のいずれかの項目の alg 属性と一致することを検証します。
clientExtensionResults 内のクライアント拡張出力の値と、 authData 内の extensions にある認証器拡張出力の値が、options.extensions に与えられたクライアント拡張入力値、および要求されていない拡張、すなわち options.extensions の一部として指定されなかった拡張に関するリライングパーティ固有のポリシーを考慮したうえで、期待どおりであることを検証します。一般的な場合、「期待どおり」の意味は、リライングパーティおよび使用中の拡張に固有です。

注: クライアントプラットフォームは、追加の認証器拡張またはクライアント拡張を設定するローカルポリシーを実施してもよく、その結果、元々 options.extensions の一部として指定されていなかった値が、認証器拡張出力またはクライアント拡張出力に現れる場合があります。リライングパーティは、要求されていない拡張を無視するか、アテステーションを拒否するかにかかわらず、そのような状況を処理できるよう準備しなければなりません。リライングパーティは、ローカルポリシーと使用中の拡張に基づいてこの判断を行えます。

注: すべての拡張はクライアントと認証器の両方にとって任意であるため、リライングパーティは、要求された拡張のいずれも、またはすべてが処理されなかった場合にも対応できるよう準備しなければなりません。
fmt を、サポートされる WebAuthn アテステーションステートメント形式識別子値の集合と USASCII の大文字小文字を区別する照合を行うことによって、アテステーションステートメント形式を決定します。登録済み WebAuthn アテステーションステートメント形式識別子値の最新一覧は、 [RFC8809] によって確立された IANA "WebAuthn Attestation Statement Format Identifiers" レジストリ [IANA-WebAuthn-Registries] で管理されています。
attStmt、authData、および hash を指定して、アテステーションステートメント形式 fmt の検証手順を使用することにより、attStmt が有効なアテステーション署名を伝達する正しいアテステーションステートメントであることを検証します。

注: 各アテステーションステートメント形式は独自の検証手順を規定します。最初に定義された形式については§ 8 定義済みアテステーションステートメント形式を、最新の一覧については [IANA-WebAuthn-Registries] を参照してください。
検証が成功した場合、そのアテステーション型およびアテステーションステートメント形式 fmt に対して許容可能な信頼アンカー（すなわちアテステーションルート証明書）の一覧を、信頼されたソースまたはポリシーから取得します。たとえば、FIDO Metadata Service [FIDOMetadataService] は、 authData 内の attestedCredentialData に含まれる aaguidを使用して、そのような情報を取得する方法の 1 つを提供します。
ステップ 19 の検証手順の出力を使用して、次のようにアテステーションの信頼性を評価します。
- アテステーションが提供されなかった場合、 None アテステーションがリライングパーティのポリシーで許容されることを検証します。
- 自己アテステーションが使用された場合、自己アテステーションがリライングパーティのポリシーで許容されることを検証します。
- それ以外の場合、検証手順からアテステーション信頼パスとして返された X.509 証明書を使用して、アテステーション公開鍵が許容可能なルート証明書まで正しく連鎖すること、またはそれ自体が許容可能な証明書であること（すなわち、これとステップ 20 で取得されたルート証明書が同一であってもよい）を検証します。
credentialId がまだ他のユーザーに登録されていないことを確認します。すでに別のユーザーに登録されているクレデンシャルについて登録が要求された場合、リライングパーティはこの登録セレモニーを失敗させるべきですが、たとえば古い登録を削除しつつ登録を受け入れることを決定してもよいものとします。
アテステーションステートメント attStmt が正常に検証され、信頼できると判断された場合、 options.user で示されたアカウントに新しいクレデンシャルを登録します。
- ユーザーのアカウントを、 authData.attestedCredentialData 内の credentialId および credentialPublicKey と、リライングパーティのシステムに適した方法で関連付けます。
- credentialId を、 authData.signCount の値で初期化された新しい保存済み署名カウンター値と関連付けます。
次の処理も行うことが推奨されます。
- credential.response.getTransports() を呼び出して返されたトランスポートヒントを credentialId と関連付けます。この値は保存の前後で変更すべきではありません。将来の get() 呼び出しで、適切な認証器を見つける方法をクライアントが判断するのを支援するため、この値を allowCredentials オプションの transports に設定することが推奨されます。
アテステーションステートメント attStmt が正常に検証されたものの、上記のステップ 21 に従って信頼できない場合、リライングパーティは登録セレモニーを失敗させるべきです。

注: ただし、ポリシーで許可される場合、リライングパーティはクレデンシャル IDおよびクレデンシャル公開鍵を登録してもよいものとしますが、そのクレデンシャルを自己アテステーションを持つものとして扱います（§ 6.5.3 アテステーション型を参照）。その場合、リライングパーティは、公開鍵クレデンシャルが特定の認証器モデルによって生成されたという暗号学的証明が存在しないと表明することになります。より詳細な説明については、[FIDOSecRef] および [UAFProtocol] を参照してください。

アテステーションオブジェクトの検証には、上記のステップ 20 で許容可能な信頼アンカーを決定するための信頼できる方法をリライングパーティが持っている必要があります。また、証明書が使用されている場合、リライングパーティは中間 CA 証明書の証明書ステータス情報へアクセスできなければなりません。クライアントがアテステーション情報でこのチェーンを提供しなかった場合、リライングパーティはアテステーション証明書チェーンを構築できなければなりません。

7.2. 認証アサーションの検証

認証セレモニーを実行するには、リライングパーティは次のように進めなければなりません。

options を、セレモニーにおけるリライングパーティの要件に合わせて構成された、新しい PublicKeyCredentialRequestOptions 構造とします。

options.allowCredentials が存在する場合、各項目の transports メンバーは、対応するクレデンシャルが登録されたときに credential.response.getTransports() によって返された値に設定すべきです。
navigator.credentials.get() を呼び出し、options を publicKey オプションとして渡します。 credential を、正常に解決された Promise の結果とします。 Promise が拒否された場合は、ユーザーに見えるエラーを表示してセレモニーを中止するか、拒否された Promise で利用可能なコンテキストから判断できる場合は、それに応じてユーザー体験を案内します。さまざまなエラーコンテキストと、それらが発生する状況については、§ 6.3.3 authenticatorGetAssertion 操作を参照してください。
response を credential.response とします。 response が AuthenticatorAssertionResponse のインスタンスでない場合、ユーザーに見えるエラーを表示してセレモニーを中止します。
clientExtensionResults を、 credential.getClientExtensionResults() を呼び出した結果とします。
options.allowCredentials が空でない場合、 credential.id が options.allowCredentials に列挙された公開鍵クレデンシャルのいずれかを識別することを検証します。
認証されるユーザーを識別し、このユーザーが credential.id によって識別される公開鍵クレデンシャルソース credentialSource の所有者であることを検証します。

認証セレモニーが開始される前に、たとえばユーザー名や Cookie によってユーザーが識別されていた場合、

識別されたユーザーが credentialSource の所有者であることを検証します。 response.userHandle が存在する場合、 userHandle をその値とします。userHandle も同じユーザーに対応することを検証します。

認証セレモニーが開始される前にユーザーが識別されていなかった場合、

response.userHandle が存在し、この値によって識別されるユーザーが credentialSource の所有者であることを検証します。
credential.id （または、ユースケースにbase64url エンコーディングが適切でない場合は credential.rawId）を使用して、対応するクレデンシャル公開鍵を検索し、 credentialPublicKey をそのクレデンシャル公開鍵とします。
cData、authData および sig をそれぞれ response の clientDataJSON、 authenticatorData、および signature の値とします。
JSONtext を、cData の値にUTF-8 デコードを実行した結果とします。

注: UTF-8 デコードアルゴリズムによって得られるものと同じ結果が得られる限り、任意のUTF-8 デコード実装を使用して構いません。特に、先頭のバイトオーダーマーク (BOM) はすべて除去しなければなりません。
C を、署名に使用されたと主張されるクライアントデータとし、JSONtext に対して実装固有の JSON パーサーを実行した結果とします。

注: このアルゴリズムで必要とされるように、 C の構成要素を参照できる限り、C は任意の実装固有のデータ構造表現で構いません。
C.type の値が文字列 webauthn.get であることを検証します。
C.challenge の値が options.challenge の base64url エンコーディングと等しいことを検証します。
C.origin の値がリライングパーティのオリジンと一致することを検証します。
C.tokenBinding.status の値が、アテステーションを取得した TLS 接続におけるToken Binding の状態と一致することを検証します。その TLS 接続でToken Binding が使用された場合は、 C.tokenBinding.id が、接続のToken Binding ID のbase64url エンコーディングと一致することも検証します。
authData 内の rpIdHash が、リライングパーティが期待するRP ID の SHA-256 ハッシュであることを検証します。
注: appid 拡張を使用する場合、このステップには特別なロジックが必要です。詳細については、§ 10.1 FIDO AppID 拡張 (appid)を参照してください。
authData 内の flags のユーザー存在ビットが設定されていることを検証します。
このアサーションでユーザー検証が必要な場合、authData 内の flags のユーザー検証済みビットが設定されていることを検証します。
clientExtensionResults 内のクライアント拡張出力の値と、 authData 内の extensions にある認証器拡張出力の値が、options.extensions に与えられたクライアント拡張入力値、および要求されていない拡張、すなわち options.extensions の一部として指定されなかった拡張に関するリライングパーティ固有のポリシーを考慮したうえで、期待どおりであることを検証します。一般的な場合、「期待どおり」の意味は、リライングパーティおよび使用中の拡張に固有です。

注: クライアントプラットフォームは、追加の認証器拡張またはクライアント拡張を設定するローカルポリシーを実施してもよく、その結果、元々 options.extensions の一部として指定されていなかった値が、認証器拡張出力またはクライアント拡張出力に現れる場合があります。リライングパーティは、要求されていない拡張を無視するか、アサーションを拒否するかにかかわらず、そのような状況を処理できるよう準備しなければなりません。リライングパーティは、ローカルポリシーと使用中の拡張に基づいてこの判断を行えます。

注: すべての拡張はクライアントと認証器の両方にとって任意であるため、リライングパーティは、要求された拡張のいずれも、またはすべてが処理されなかった場合にも対応できるよう準備しなければなりません。
hash を、cData に対して SHA-256 を使用してハッシュを計算した結果とします。
credentialPublicKey を使用して、sig が authData と hash のバイナリ連結に対する有効な署名であることを検証します。

注: この検証ステップは FIDO U2F 認証器によって生成される署名と互換性があります。§ 6.1.2 FIDO U2F 署名形式との互換性を参照してください。
storedSignCount を、 credential.id に関連付けられた保存済み署名カウンター値とします。 authData.signCount がゼロでないか、storedSignCount がゼロでない場合、次のサブステップを実行します。
- authData.signCount が
  
  storedSignCount より大きい:
  storedSignCount を authData.signCount の値に更新します。
  storedSignCount 以下:
  これは、認証器が複製されている可能性、すなわち少なくとも 2 つのクレデンシャル秘密鍵のコピーが存在し、並行して使用されている可能性を示すシグナルです。リライングパーティはこの情報をリスク評価に組み込むべきです。この場合にリライングパーティが storedSignCount を更新するかどうか、または認証セレモニーを失敗させるかどうかは、リライングパーティ固有です。
上記のすべてのステップが成功した場合、適切に認証セレモニーを続行します。それ以外の場合、認証セレモニーを失敗させます。

8. 定義済みアテステーションステートメント形式

WebAuthn は、プラグイン可能なアテステーションステートメント形式をサポートします。このセクションでは、そのような形式の初期セットを定義します。

8.1. アテステーションステートメント形式識別子

アテステーションステートメント形式は、アテステーションステートメント形式識別子と呼ばれる文字列によって識別され、アテステーションステートメント形式の作者によって選択されます。

アテステーションステートメント形式識別子は、 [RFC8809] によって確立された IANA "WebAuthn Attestation Statement Format Identifiers" レジストリ [IANA-WebAuthn-Registries] に登録すべきです。登録されたすべてのアテステーションステートメント形式識別子は、当然ながら互いに一意です。

未登録のアテステーションステートメント形式識別子は、識別子の一意性を保証するため、開発者が登録したドメイン名を使用し、小文字の逆ドメイン名形式の命名を使用すべきです。すべてのアテステーションステートメント形式識別子は最大 32 オクテット長でなければならず、バックスラッシュおよび二重引用符を除く印字可能な USASCII 文字のみ、すなわち [RFC5234] で定義される VCHAR から %x22 および %x5c を除いた文字のみで構成されなければなりません。

注: これは、ドメイン名に基づくアテステーションステートメント形式識別子は LDH Label [RFC5890] のみを組み込まなければならないことを意味します。

実装は、WebAuthn アテステーションステートメント形式識別子を大文字小文字を区別して照合しなければなりません。

複数のバージョンが存在し得るアテステーションステートメント形式は、その識別子にバージョンを含めるべきです。実質的に、異なるバージョンは異なる形式として扱われます。たとえば、§ 8.2 Packed アテステーションステートメント形式の新しいバージョンとして packed2 があります。

以下のセクションでは、現在定義され登録されているアテステーションステートメント形式とその識別子の集合を示します。登録されたWebAuthn 拡張の最新一覧は、 [RFC8809] によって確立された IANA "WebAuthn Attestation Statement Format Identifiers" レジストリ [IANA-WebAuthn-Registries] で管理されています。

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: この配列の要素には attestnCert とその証明書チェーン（存在する場合）が含まれ、それぞれ X.509 形式でエンコードされます。アテステーション証明書 attestnCert は配列の最初の要素でなければなりません。
attestnCert: X.509 形式でエンコードされたアテステーション証明書。

署名手順

このアテステーションステートメント形式の署名手順は、アサーション署名を生成する手順と同様です。

authenticatorData をアテステーション用の認証器データとし、 clientDataHash をシリアル化されたクライアントデータのハッシュとします。
Basic または AttCA アテステーションを使用する場合、認証器は authenticatorData と clientDataHash を連結し、認証器固有の仕組みによって選択されたアテステーション秘密鍵を使用して結果に署名することで sig を生成します。x5c を attestnCert とし、その後に関連する証明書チェーン（存在する場合）を続けます。alg をアテステーション秘密鍵のアルゴリズムに設定します。
自己アテステーションを使用する場合、認証器は authenticatorData と clientDataHash を連結し、クレデンシャル秘密鍵を使用して結果に署名することで sig を生成します。alg をクレデンシャル秘密鍵のアルゴリズムに設定し、その他のフィールドを省略します。

検証手順

検証手順の入力 attStmt、 authenticatorData および clientDataHash が与えられた場合、検証手順は次のとおりです。

attStmt が上記で定義された構文に適合する有効な CBOR であることを検証し、 CBOR デコードを実行して含まれるフィールドを抽出します。
x5c が存在する場合:
- sig が、alg で指定されたアルゴリズムを使用し、 attestnCert 内のアテステーション公開鍵による authenticatorData と clientDataHash の連結に対する有効な署名であることを検証します。
- attestnCert が§ 8.2.1 Packed アテステーションステートメント証明書要件を満たすことを検証します。
- attestnCert に OID 1.3.6.1.4.1.45724.1.1.4 (id-fido-gen-ce-aaguid) の拡張が含まれている場合、この拡張の値が authenticatorData 内の aaguid と一致することを検証します。
- 任意で、x5c を調べ、外部から提供された知識を参照して、 attStmt がBasic または AttCA アテステーションのどちらを伝達しているかを判断します。
- 成功した場合、アテステーション型 Basic、AttCA または不確定を表す実装固有の値、およびアテステーション信頼パス x5c を返します。
x5c が存在しない場合、自己アテステーションが使用されています。
- alg が authenticatorData 内の credentialPublicKey のアルゴリズムと一致することを検証します。
- sig が、alg とクレデンシャル公開鍵を使用した authenticatorData と clientDataHash の連結に対する有効な署名であることを検証します。
- 成功した場合、アテステーション型 Self および空のアテステーション信頼パスを表す実装固有の値を返します。

8.2.1. Packed アテステーションステートメント証明書要件

アテステーション証明書には、次のフィールド/拡張が含まれていなければなりません。

Version は 3（値 2 の ASN.1 INTEGER で示される）に設定されていなければなりません。
Subject フィールドは次のように設定されていなければなりません。

Subject-C

認証器ベンダーが法人化されている国を指定する ISO 3166 コード (PrintableString)

Subject-O

認証器ベンダーの法的名称 (UTF8String)

Subject-OU

リテラル文字列 “Authenticator Attestation” (UTF8String)

Subject-CN

ベンダーが選択する UTF8String
関連するアテステーションルート証明書が複数の認証器モデルに使用される場合、Extension OID 1.3.6.1.4.1.45724.1.1.4 (id-fido-gen-ce-aaguid) が存在しなければならず、 AAGUID を 16 バイトの OCTET STRING として含んでいなければなりません。この拡張を critical としてマークしてはなりません。

X.509 Extension は、値の DER エンコーディングを OCTET STRING 内にエンコードすることに注意してください。したがって、有効にするには AAGUID を 2 つの OCTET STRING でラップしなければなりません。以下は、エンコードされた Extension 構造の例です。
```
30 21                                     -- SEQUENCE
  06 0b 2b 06 01 04 01 82 e5 1c 01 01 04  -- 1.3.6.1.4.1.45724.1.1.4
  04 12                                   -- OCTET STRING
    04 10                                 -- OCTET STRING
      cd 8c 39 5c 26 ed ee de             -- AAGUID
      65 3b 00 79 7d 03 ca 3c
```
Basic Constraints 拡張の CA コンポーネントは false に設定されていなければなりません。
多くのアテステーション証明書のステータスは認証器メタデータサービスを通じて利用できるため、エントリ id-ad-ocsp を持つ Authority Information Access (AIA) 拡張と CRL Distribution Point 拡張 [RFC5280] はどちらも任意です。たとえば、FIDO Metadata Service [FIDOMetadataService] を参照してください。

8.3. TPM アテステーションステートメント形式

このアテステーションステートメント形式は通常、Trusted Platform Module を暗号エンジンとして使用する認証器によって使用されます。

アテステーションステートメント形式識別子

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: アテステーションに使用される、X.509 エンコーディングの AIK 証明書。
sig: [TPMv2-Part2] セクション 11.3.4 で規定される TPMT_SIGNATURE 構造形式のアテステーション署名。
certInfo: [TPMv2-Part2] セクション 10.12.8 で規定される、上記の署名が計算された TPMS_ATTEST 構造。
pubArea: クレデンシャル公開鍵を表すために TPM が使用する TPMT_PUBLIC 構造（[TPMv2-Part2] セクション 12.2.4 を参照）。

署名手順

authenticatorData をアテステーション用の認証器データとし、 clientDataHash をシリアル化されたクライアントデータのハッシュとします。

authenticatorData と clientDataHash を連結して attToBeSigned を形成します。

[TPMv2-Part3] セクション 18.2 で規定された手順を使用して署名を生成します。アテステーション秘密鍵を使用し、 extraData パラメーターを、"alg" 署名アルゴリズムに対応するハッシュアルゴリズムを使用した attToBeSigned のダイジェストに設定します。（"RS256" アルゴリズムの場合、これは SHA-256 ダイジェストになります。）

pubArea フィールドをクレデンシャル公開鍵の public area に、 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 が、"alg" で使用されるハッシュアルゴリズムによる attToBeSigned のハッシュに設定されていることを検証します。
attested が、[TPMv2-Part2] セクション 10.12.3 で規定される TPMS_CERTIFY_INFO 構造を含み、その name フィールドが pubArea の有効な Name を含むことを検証します。この Name は、pubArea の nameAlg フィールドのアルゴリズムを使用し、[TPMv2-Part1] セクション 16 で規定される手順に従って計算されます。
x5c が存在することを検証します。
「Standard Attestation Structure」[TPMv2-Part1] セクション 31.2 の残りのフィールド、すなわち qualifiedSigner、clockInfo および firmwareVersion は無視されることに注意してください。これらのフィールドはリスクエンジンへの入力として使用してもよいものとします。
sig が、alg で指定されたアルゴリズムを使用し、 aikCert 内のアテステーション公開鍵による certInfo に対する有効な署名であることを検証します。
aikCert が § 8.3.1 TPM アテステーションステートメント証明書要件を満たすことを検証します。
aikCert に OID 1.3.6.1.4.1.45724.1.1.4 (id-fido-gen-ce-aaguid) の拡張が含まれている場合、この拡張の値が authenticatorData 内の aaguid と一致することを検証します。
成功した場合、アテステーション型 AttCA およびアテステーション信頼パス x5c を表す実装固有の値を返します。

8.3.1. TPM アテステーションステートメント証明書要件

TPM アテステーション証明書には、次のフィールド/拡張が含まれていなければなりません。

Version は 3 に設定されていなければなりません。
Subject フィールドは空に設定されていなければなりません。
Subject Alternative Name 拡張は、[TPMv2-EK-Profile] セクション 3.2.9 で定義されているとおりに設定されていなければなりません。
Extended Key Usage 拡張には OID 2.23.133.8.3 ("joint-iso-itu-t(2) internationalorganizations(23) 133 tcg-kp(8) tcg-kp-AIKCertificate(3)") が含まれていなければなりません。
Basic Constraints 拡張の CA コンポーネントは false に設定されていなければなりません。
多くのアテステーション証明書のステータスはメタデータサービスを通じて利用できるため、エントリ id-ad-ocsp を持つ Authority Information Access (AIA) 拡張と CRL Distribution Point 拡張 [RFC5280] はどちらも任意です。たとえば、FIDO Metadata Service [FIDOMetadataService] を参照してください。

8.4. Android Key アテステーションステートメント形式

対象の認証器が Android "N" 以降のプラットフォーム上のプラットフォーム認証器である場合、アテステーションステートメントはAndroid key アテステーションに基づきます。この場合、アテステーションステートメントは安全な実行環境で動作するコンポーネントによって生成されますが、アテステーション用の認証器データはこの環境の外部で生成されます。WebAuthn リライングパーティは、アテステーションに使用されたと主張される認証器データが、アテステーション証明書の拡張データのフィールドと整合していることを確認することが期待されます。

アテステーションステートメント形式識別子

android-key

サポートされるアテステーション型

Basic

構文

Android key アテステーションステートメントは、単に Android アテステーションステートメント、すなわち一連の DER エンコードされた X.509 証明書で構成されます。Android 開発者向けドキュメントを参照してください。その構文は次のように定義されます。

    $$attStmtType //= (
                          fmt: "android-key",
                          attStmt: androidStmtFormat
                      )

    androidStmtFormat = {
                          alg: COSEAlgorithmIdentifier,
                          sig: bytes,
                          x5c: [ credCert: bytes, * (caCert: bytes) ]
                        }

署名手順

authenticatorData をアテステーション用の認証器データとし、 clientDataHash をシリアル化されたクライアントデータのハッシュとします。

clientDataHash をチャレンジ値として指定して keyStore.getCertificateChain(myKeyUUID) を呼び出し、Android Key Attestation を要求します（たとえば、 setAttestationChallenge を使用します）。x5c を返された値に設定します。

認証器は authenticatorData と clientDataHash を連結し、クレデンシャル秘密鍵を使用して結果に署名することで sig を生成します。alg を署名形式のアルゴリズムに設定します。

検証手順

検証手順の入力 attStmt、authenticatorData および clientDataHash が与えられた場合、検証手順は次のとおりです。

attStmt が上記で定義された構文に準拠する有効な CBOR であることを検証し、 CBOR デコードを実行して含まれるフィールドを抽出します。
sig が、alg で指定されたアルゴリズムを使用し、 x5c の最初の証明書内の公開鍵による authenticatorData と clientDataHash の連結に対する有効な署名であることを検証します。
x5c の最初の証明書内の公開鍵が、 authenticatorData 内の attestedCredentialData 内の credentialPublicKey と一致することを検証します。
アテステーション証明書の拡張データ内の attestationChallenge フィールドが clientDataHash と同一であることを検証します。
アテステーション証明書の拡張データ内の適切な認可リストを使用して、次を検証します。
- PublicKeyCredential はRP ID にスコープ設定されなければならないため、 AuthorizationList.allApplications フィールドがどちらの認可リスト（softwareEnforced と teeEnforced のいずれにも）存在しないこと。
- 以下について、RP が信頼された実行環境からの鍵のみを受け入れたい場合は teeEnforced 認可リストのみを使用し、それ以外の場合は teeEnforced と softwareEnforced の和集合を使用します。
  - AuthorizationList.origin フィールドの値が KM_ORIGIN_GENERATED と等しいこと。
  - AuthorizationList.purpose フィールドの値が KM_PURPOSE_SIGN と等しいこと。
成功した場合、アテステーション型 Basic およびアテステーション信頼パス x5c を表す実装固有の値を返します。

8.4.1. Android Key アテステーションステートメント証明書要件

Android Key Attestation アテステーション証明書のAndroid key アテステーション証明書拡張データは OID 1.3.6.1.4.1.11129.2.1.17 によって識別され、そのスキーマは Android 開発者向けドキュメントで定義されています。

8.5. Android SafetyNet アテステーションステートメント形式

認証器が、特定の Android プラットフォーム上のプラットフォーム認証器である場合、アテステーションステートメントは SafetyNet API に基づく場合があります。この場合、認証器データは SafetyNet API の呼び出し元（通常は Android プラットフォーム上で実行されるアプリケーション）によって完全に制御され、アテステーションステートメントはプラットフォームの健全性および呼び出し元アプリケーションの識別情報についていくつかの表明を提供します（詳細については 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 エンコードしたもの。この値は Compact Serialization の JWS [RFC7515] オブジェクトです（SafetyNet オンラインドキュメントを参照）。

署名手順

authenticatorData をアテステーション用の認証器データとし、 clientDataHash をシリアル化されたクライアントデータのハッシュとします。

authenticatorData と clientDataHash を連結し、連結した文字列の SHA-256 ハッシュを計算して、そのハッシュ結果を attToBeSigned とします。

attToBeSigned を nonce 値として指定して SafetyNet アテステーションを要求します。 response をその結果に、ver を認証器で実行されている Google Play Services のバージョンに設定します。

検証手順

検証手順の入力 attStmt、authenticatorData および clientDataHash が与えられた場合、検証手順は次のとおりです。

attStmt が上記で定義された構文に準拠する有効な CBOR であることを検証し、 CBOR デコードを実行して含まれるフィールドを抽出します。
SafetyNet オンラインドキュメントで示された手順に従って、response がバージョン ver の有効な 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 形式のアテステーション証明書を含む単一要素の配列。
sig: アテステーション署名。この署名は、[FIDO-U2F-Message-Formats] の（生の）U2F 登録レスポンスメッセージに対して計算されたものであり、このメッセージはクライアントが認証器から受信したものです。

署名手順

アテステーション対象クレデンシャルのクレデンシャル公開鍵がアルゴリズム -7 ("ES256") でない場合、停止してエラーを返します。それ以外の場合、authenticatorData をアテステーション用の認証器データとし、 clientDataHash をシリアル化されたクライアントデータのハッシュとします。（SHA-256 がシリアル化されたクライアントデータのハッシュに使用されるため、 clientDataHash の長さは 32 バイトになります。）

[FIDO-U2F-Message-Formats] のセクション 4.3 で規定される Registration Response Message を生成します。application parameter は、所与のクレデンシャルがスコープ設定されるRP ID の SHA-256 ハッシュに設定し、challenge parameter は clientDataHash に、 key handle parameter は所与のクレデンシャルのクレデンシャル IDに設定します。この Registration Response Message の生の署名部分（すなわち、ユーザー公開鍵、 key handle、およびアテステーション証明書を除く）を sig とし、アテステーション公開鍵のアテステーション証明書を x5c に設定します。

検証手順

検証手順の入力 attStmt、authenticatorData および clientDataHash が与えられた場合、検証手順は次のとおりです。

attStmt が上記で定義された構文に準拠する有効な CBOR であることを検証し、 CBOR デコードを実行して含まれるフィールドを抽出します。
x5c がちょうど 1 つの要素を持つことを確認し、attCert をその要素とします。 certificate public key を attCert によって伝達される公開鍵とします。 certificate public key が P-256 曲線上の Elliptic Curve (EC) 公開鍵でない場合、このアルゴリズムを終了して適切なエラーを返します。
authenticatorData から主張された rpIdHash を抽出し、 authenticatorData.attestedCredentialData から主張された credentialId および credentialPublicKey を抽出します。
COSE_KEY 形式の credentialPublicKey（セクション 7、[RFC8152] を参照）を Raw ANSI X9.62 公開鍵形式（[FIDO-Registry] のセクション 3.6.2 公開鍵表現形式の ALG_KEY_ECC_X962_RAW を参照）に変換します。
- x を credentialPublicKey 内の "-2" キー（x 座標を表す）に対応する値とし、そのサイズが 32 バイトであることを確認します。サイズが異なるか "-2" キーが見つからない場合、このアルゴリズムを終了して適切なエラーを返します。
- y を credentialPublicKey 内の "-3" キー（y 座標を表す）に対応する値とし、そのサイズが 32 バイトであることを確認します。サイズが異なるか "-3" キーが見つからない場合、このアルゴリズムを終了して適切なエラーを返します。
- publicKeyU2F を連結 0x04 || x || y とします。
  
  注: これは非圧縮 ECC 鍵形式を示します。
verificationData を (0x00 || rpIdHash || clientDataHash || credentialId || publicKeyU2F) の連結とします（セクション 4.3、[FIDO-U2F-Message-Formats] を参照）。
verificationData と certificate public key を使用し、[SEC1] のセクション 4.1.4 に従って sig を検証します。ステップ 2 で使用するハッシュ関数は SHA-256 とします。
任意で、x5c を調べ、外部から提供された知識を参照して、 attStmt がBasic または AttCA アテステーションのどちらを伝達しているかを判断します。
成功した場合、アテステーション型 Basic、AttCA または不確定、およびアテステーション信頼パス x5c を表す実装固有の値を返します。

8.7. None アテステーションステートメント形式

none アテステーションステートメント形式は、WebAuthn リライングパーティがアテステーション情報を受け取りたくないと示した場合に、認証器が提供するアテステーションステートメントを置き換えるために使用されます。§ 5.4.7 アテステーション伝達設定列挙型 (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: credCert と、それに続く証明書チェーン。それぞれ X.509 形式でエンコードされます。
credCert: アテステーションに使用される、X.509 形式でエンコードされたクレデンシャル公開鍵証明書。

署名手順

authenticatorData をアテステーション用の認証器データとし、 clientDataHash をシリアル化されたクライアントデータのハッシュとします。
authenticatorData と clientDataHash を連結して nonceToHash を形成します。
nonceToHash の SHA-256 ハッシュを計算して nonce を生成します。
Apple 匿名アテステーション CA にクレデンシャル公開鍵の X.509 証明書を生成させ、 nonce を OID 1.2.840.113635.100.8.2 の証明書拡張として含めます。 credCert はこの証明書を表します。したがって credCert はアテステーションの証明として機能し、含まれる nonce はアテステーションがライブであることを証明します。さらに、 nonce は authenticatorData およびクライアントデータの完全性も保護します。
x5c を credCert と、それに続く証明書チェーンに設定します。

検証手順

検証手順の入力 attStmt、authenticatorData および clientDataHash が与えられた場合、検証手順は次のとおりです。

attStmt が上記で定義された構文に準拠する有効な CBOR であることを検証し、 CBOR デコードを実行して含まれるフィールドを抽出します。
authenticatorData と clientDataHash を連結して nonceToHash を形成します。
nonceToHash の SHA-256 ハッシュを計算して nonce を生成します。
nonce が credCert 内の OID 1.2.840.113635.100.8.2 を持つ拡張の値と等しいことを検証します。
クレデンシャル公開鍵が credCert の Subject Public Key と等しいことを検証します。
成功した場合、アテステーション型匿名化 CAおよびアテステーション信頼パス x5c を表す実装固有の値を返します。

9. WebAuthn 拡張

§ 5 Web Authentication API で定義される、公開鍵クレデンシャルを生成し、Authentication アサーションを要求および生成する仕組みは、特定のユースケースに適合するよう拡張できます。各ケースは、登録拡張および/または認証拡張を定義することで対応します。

すべての拡張はクライアント拡張です。つまり、拡張にはクライアントとの通信およびクライアントによる処理が伴います。クライアント拡張は次の手順とデータを定義します。

登録拡張用の navigator.credentials.create() 拡張リクエストパラメーターおよびレスポンス値。
認証拡張用の navigator.credentials.get() 拡張リクエストパラメーターおよびレスポンス値。
登録拡張および認証拡張用のクライアント拡張処理。

公開鍵クレデンシャルを作成する場合、または認証アサーションを要求する場合、WebAuthn リライングパーティは、一連の拡張の使用を要求できます。これらの拡張は、クライアントおよび/またはWebAuthn 認証器によってサポートされている場合、要求された操作中に呼び出されます。リライングパーティは、各拡張のクライアント拡張入力を get() 呼び出し（認証拡張の場合）または create() 呼び出し（登録拡張の場合）でクライアントに送信します。クライアントは、クライアントプラットフォームがサポートする各拡張についてクライアント拡張処理を実行し、各拡張で規定されるとおり、拡張識別子およびクライアント拡張出力値を含めることで、クライアントデータを拡張します。

拡張は認証器拡張でもあり得ます。これは、拡張に認証器との通信および認証器による処理が伴うことを意味します。認証器拡張は次の手順とデータを定義します。

登録拡張用のauthenticatorMakeCredential 拡張リクエストパラメーターおよびレスポンス値。
認証拡張用のauthenticatorGetAssertion 拡張リクエストパラメーターおよびレスポンス値。
登録拡張および認証拡張用の認証器拡張処理。

認証器拡張について、クライアント拡張処理の一部として、クライアントは各拡張について CBOR 認証器拡張入力値も作成し（多くの場合、対応するクライアント拡張入力値に基づきます）、 create() 呼び出し（登録拡張の場合）または get() 呼び出し（認証拡張の場合）で認証器に渡します。これらの認証器拡張入力値は CBOR で表現され、名前と値のペアとして渡されます。名前は拡張識別子であり、値は対応する認証器拡張入力です。一方、認証器はサポートする拡張について追加処理を実行し、各拡張で規定されるCBOR 認証器拡張出力を返します。認証器拡張のクライアント拡張処理の一部は、認証器拡張出力をクライアント拡張出力の作成への入力として使用することです。

すべてのWebAuthn 拡張は、クライアントと認証器の両方にとって任意です。したがって、リライングパーティによって要求された拡張は、クライアントのブラウザーまたは OS によって無視されて認証器へまったく渡されない場合もあれば、認証器によって無視される場合もあります。拡張を無視することは WebAuthn API 処理では決して失敗とは見なされないため、リライングパーティが API 呼び出しに拡張を含める場合、一部またはすべての拡張が無視される場合を処理できるよう準備しなければなりません。

可能な限り広範な拡張をサポートしたいクライアントは、認識しない拡張を認証器へそのまま渡し、クライアント拡張入力を単純に CBOR でエンコードして認証器拡張入力を生成してもよいものとします。すべてのWebAuthn 拡張は、この実装上の選択によってユーザーのセキュリティまたはプライバシーが危険にさらされないよう定義されなければなりません。たとえば、拡張にクライアント処理が必要な場合、そのような単純なパススルーによって意味論的に無効な認証器拡張入力値が生成され、結果として認証器によって拡張が無視されることを保証するよう定義できます。すべての拡張は任意であるため、これは API 操作の機能的な失敗を引き起こしません。同様に、クライアントは、CBOR 出力が JSON に存在する型のみを使用していることを条件に、認識しない拡張について認証器拡張出力値を JSON にエンコードしてクライアント拡張出力値を生成することを選択できます。

クライアントが認識しない拡張をそのまま渡すことを選択する場合、クライアント拡張入力内の JavaScript 値は、認証器拡張入力内のCBOR 値へ変換されます。 JavaScript 値が%ArrayBuffer% の場合、CBOR バイト配列に変換されます。 JavaScript 値が整数ではない数値の場合、64 ビット CBOR 浮動小数点数に変換されます。それ以外で JavaScript 型が JSON 型に対応する場合、変換は [RFC8949] のセクション 6.2 （JSON から CBOR への変換）で定義された規則を使用して行われますが、JSON 型値の入力ではなく JavaScript 型値の入力に対して処理します。これらの変換が完了したら、結果として得られたCBORの正規化を、CTAP2 正規 CBOR エンコーディング形式を使用して実行しなければなりません。

JavaScript の数値変換規則には、クライアントが認識しない拡張をそのまま渡す際、その拡張が浮動小数点値を使用する場合、認証器はそれらの値をCBOR 整数として受信する可能性に備える必要があるという結果があることに注意してください。これは、認証器が、実際のクライアントによるサポートなしでも拡張が常に動作することを望む場合に必要です。使用される浮動小数点値がたまたま整数である場合にこれが発生します。

同様に、クライアントが認識せずそのまま渡した拡張から出力を受け取る場合、認証器拡張出力内のCBOR 値は、クライアント拡張出力内の JavaScript 値へ変換されます。 CBOR 値がバイト文字列の場合、base64url エンコード文字列ではなく JavaScript %ArrayBuffer% に変換されます。それ以外で CBOR 型が JSON 型に対応する場合、変換は [RFC8949] のセクション 6.1 （CBOR から JSON への変換）で定義された規則を使用して行われますが、JSON 型値の出力ではなく JavaScript 型値の出力を生成します。

一部のクライアントは、このパススルー機能を feature flag の下で実装することを選択する場合があることに注意してください。この機能をサポートすると、認証器が新しい拡張を試験でき、リライングパーティがクライアントに明示的なサポートが存在する前にそれらを使用できるため、イノベーションを促進できます。

[RFC8809] によって確立された IANA "WebAuthn Extension Identifiers" レジストリ [IANA-WebAuthn-Registries] を参照すると、登録済みWebAuthn 拡張の最新一覧を確認できます。

9.1. 拡張識別子

拡張は、拡張の作者によって選択された拡張識別子と呼ばれる文字列によって識別されます。

拡張識別子は、 [RFC8809] によって確立された IANA "WebAuthn Extension Identifiers" レジストリ [IANA-WebAuthn-Registries] に登録すべきです。登録済みのすべての拡張識別子は、当然ながら互いに一意です。

未登録の拡張識別子は、たとえば myCompany_extension のように定義主体を含めることで、グローバルに一意となることを目指すべきです。

すべての拡張識別子は最大 32 オクテット長でなければならず、印字可能な USASCII 文字のみで構成されなければなりません。バックスラッシュおよび二重引用符を除きます。すなわち、[RFC5234] で定義される VCHAR から %x22 と %x5c を除いたものです。実装は WebAuthn 拡張識別子を大文字小文字を区別して照合しなければなりません。

複数のバージョンが存在し得る拡張は、識別子にバージョンを含めるよう注意すべきです。実質的に、異なるバージョンは異なる拡張として扱われます。たとえば myCompany_extension_01

§ 10 定義済み拡張では、追加の拡張セットとその識別子を定義します。登録済み WebAuthn Extension Identifier の最新一覧については、[RFC8809] によって確立された IANA "WebAuthn Extension Identifiers" レジストリ [IANA-WebAuthn-Registries] を参照してください。

9.2. 拡張の定義

拡張の定義では、拡張識別子、get() または create() 呼び出しを介して送信されるクライアント拡張入力引数、クライアント拡張処理規則、およびクライアント拡張出力値を指定しなければなりません。拡張が認証器と通信する場合（つまり認証器拡張である場合）、 authenticatorGetAssertion または authenticatorMakeCredential 呼び出しを介して送信されるCBOR 認証器拡張入力引数、認証器拡張処理規則、および CBOR 認証器拡張出力値も指定しなければなりません。

クライアントによって処理されるすべてのクライアント拡張は、 WebAuthn リライングパーティが拡張がクライアントによって処理されたことを把握できるよう、クライアント拡張出力値を返さなければなりません。同様に、認証器処理を必要とする拡張は、リライングパーティが拡張が認証器によって処理されたことを把握できるよう、認証器拡張出力を返さなければなりません。拡張がそれ以外の結果値を必要としない場合、拡張を理解して処理したことを示すために true に設定された JSON Boolean のクライアント拡張出力結果を返すよう定義すべきです。同様に、それ以外の結果値を必要としない認証器拡張は値を返さなければならず、拡張を理解して処理したことを示すために true に設定された CBOR Boolean の認証器拡張出力結果を返すべきです。

9.3. リクエストパラメーターの拡張

拡張は 1 つまたは 2 つのリクエスト引数を定義します。JSON でエンコード可能な値であるクライアント拡張入力は、 get() または create() 呼び出しでWebAuthn リライングパーティからクライアントへ渡されます。一方、CBOR 認証器拡張入力は、これらの呼び出しの処理中、認証器拡張についてクライアントから認証器へ渡されます。

リライングパーティは、 extensions オプションにエントリを含めて create() または get() を呼び出すことで、拡張の使用を要求すると同時に、そのクライアント拡張入力を設定します。エントリのキーは拡張識別子であり、値はクライアント拡張入力です。

注: 他の文書では、拡張入力が必ずしも拡張識別子をエントリキーとして使用しない拡張が規定されています。新しい拡張は上記の慣例に従うべきです。

var assertionPromise = navigator.credentials.get({
    publicKey: {
        // 簡潔にするため他のメンバーは省略
        extensions: {
            // "webauthnExample_foobar" 拡張を識別する「エントリキー」。
            // その値は 2 つの入力パラメーターを持つマップ:
            "webauthnExample_foobar": {
              foo: 42,
              bar: "barfoo"
            }
        }
    }
});

拡張の定義では、そのクライアント拡張入力の有効な値を指定しなければなりません。クライアントは無効なクライアント拡張入力を持つ拡張を無視すべきです。拡張がリライングパーティからのパラメーターを必要としない場合、リライングパーティがその拡張を要求していることを示すため、 true に設定された Boolean のクライアント引数を取るよう定義すべきです。

クライアント処理のみに影響する拡張は、認証器拡張入力を指定する必要はありません。認証器処理を持つ拡張は、クライアント拡張入力から認証器拡張入力を計算する方法を指定しなければならず、CDDL 型 AuthenticationExtensionsAuthenticatorInputs および AuthenticationExtensionsAuthenticatorOutputs について、拡張識別子をエントリキーとして使用し、$$extensionInput および $$extensionOutput グループソケットに追加の選択肢を定義することで拡張を定義しなければなりません。入力パラメーターを必要とせず、したがって true に設定された Boolean のクライアント拡張入力値を取るよう定義された拡張は、認証器拡張入力も定数 Boolean 値 true（CBOR major type 7、value 21）として定義すべきです。

次の例では、識別子 webauthnExample_foobar を持つ拡張が、符号なし整数を認証器拡張入力として受け取り、少なくとも 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. 定義済み拡張

このセクションでは、[RFC8809] によって確立された IANA "WebAuthn Extension Identifiers" レジストリ [IANA-WebAuthn-Registries] に登録する追加の拡張セットを定義します。これらは広範な相互運用性を目指すユーザーエージェントによって実装してもよいものとします。

10.1. FIDO AppID 拡張 (appid)

この拡張により、従来の FIDO U2F JavaScript API [FIDOU2FJavaScriptAPI] を使用して以前にクレデンシャルを登録したWebAuthn リライングパーティは、アサーションを要求できます。 FIDO API は、AppID [FIDO-APPID] と呼ばれるリライングパーティの代替識別子を使用し、これらの API を使用して作成されたクレデンシャルはすべてその識別子にスコープ設定されます。この拡張がなければ、 RP ID にスコープ設定するために再登録する必要があります。

appid 拡張入力を設定することに加えて、この拡張を使用するには、ユーザーが登録済み U2F クレデンシャルを使用して認証できるようにするため、リライングパーティによる追加処理が必要です。

目的の U2F クレデンシャルを get() メソッドの allowCredentials オプションに列挙します。
- type メンバーを public-key に設定します。
- id メンバーを、目的のクレデンシャルそれぞれの U2F key handle に設定します。U2F key handle は一般にbase64url エンコーディングを使用しますが、id で使用する際にはバイナリ形式へデコードしなければならないことに注意してください。
allowCredentials には、WebAuthn クレデンシャル IDと U2F key handle の両方を混在させてもよいものとします。この拡張を介して appid を指定しても、ユーザーが rpId で指定されたRP ID にスコープ設定された WebAuthn 登録済みクレデンシャルを使用することは妨げられません。
アサーションを検証する際、 rpIdHash がRP IDではなく AppID のハッシュである場合があることを想定します。

この拡張では FIDO 互換クレデンシャルを作成できません。したがって、 WebAuthn で作成されたクレデンシャルには FIDO JavaScript API との後方互換性はありません。

注: appid は、リライングパーティが従来の 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;
};

クライアント拡張処理

facetId を、呼び出し元のオリジンを、呼び出し元アプリケーションの FacetID を決定するための FIDO アルゴリズムに渡した結果とします。
appId を拡張入力とします。
facetId と appId を、呼び出し元の FacetID が AppID に対して認可されているかを決定するための FIDO アルゴリズムに渡します。そのアルゴリズムが appId を拒否した場合、"SecurityError" DOMException を返します。
allowCredentialDescriptorList を構築する際、 U2F 認証器がクレデンシャルが適用不能であることを示した場合（すなわち SW_WRONG_DATA を返した場合）、クライアントは U2F application parameter を appId の SHA-256 ハッシュに設定して再試行しなければなりません。この結果、適用可能なクレデンシャルとなった場合、クライアントはそのクレデンシャルを allowCredentialDescriptorList に含めなければなりません。その後、appId の値がauthenticatorGetAssertion の rpId パラメーターを置き換えます。
output を Boolean 値 false とします。
assertionCreationData を作成する際、アサーションが、 U2F application parameter をRP ID の SHA-256 ハッシュではなく appId の SHA-256 ハッシュに設定した U2F 認証器によって作成された場合、output を true に設定します。

注: 実際には、いくつかの実装は呼び出し元の FacetID が AppID に対して認可されているかを決定するアルゴリズムのステップ 4 以降を実装していません。代わりに、ステップ 3 では、ホストの比較を緩和し、同一サイト上のホストを受け入れます。

クライアント拡張出力

output の値を返します。true の場合、AppID が使用されたため、アサーションを検証する際、リライングパーティは rpIdHash がRP IDではなく AppID のハッシュであることを想定しなければなりません。

partial dictionary AuthenticationExtensionsClientOutputs {
  boolean appid;
};

認証器拡張入力

なし。

認証器拡張処理

なし。

認証器拡張出力

なし。

10.2. FIDO AppID 除外拡張 (appidExclude)

この登録拡張により、WebAuthn リライングパーティは、従来の FIDO U2F JavaScript API [FIDOU2FJavaScriptAPI] で作成された指定のクレデンシャルを含む認証器を除外できます。

FIDO U2F JavaScript API からの移行中、リライングパーティには、従来のクレデンシャルをすでに登録しているユーザーが存在する場合があります。appid 拡張によりサインインフローを円滑に移行できますが、登録フローを移行する際、excludeCredentials フィールドの内容は WebAuthn クレデンシャルとして扱われるため、従来のクレデンシャルを持つ認証器を除外する目的では有効に機能しません。この拡張は、クライアントプラットフォームに、excludeCredentials の内容を WebAuthn と従来の FIDO の両方のクレデンシャルとして考慮するよう指示します。U2F key handle は一般にbase64url エンコーディングを使用しますが、excludeCredentials で使用する際にはバイナリ形式へデコードしなければならないことに注意してください。

拡張識別子

appidExclude

適用可能な操作

登録

クライアント拡張入力

FIDO AppID を指定する単一の USVString。

partial dictionary AuthenticationExtensionsClientInputs {
  USVString appidExclude;
};

クライアント拡張処理

新しいクレデンシャルを作成する際:

RP ID を確立した直後に、次の手順を実行します。
1. facetId を、呼び出し元のオリジンを、呼び出し元アプリケーションの FacetID を決定するための FIDO アルゴリズムへ渡した結果とします。
2. appId を、拡張入力 appidExclude の値とします。
3. facetId と appId を、呼び出し元の FacetID が AppID に対して認可されているかを決定するための FIDO アルゴリズムへ渡します。後者のアルゴリズムが appId を拒否した場合、 "SecurityError" DOMException を返し、これらの手順とともに新しいクレデンシャルを作成するアルゴリズムも終了します。
  
  注: 実際には、いくつかの実装は、呼び出し元の FacetID が AppID に対して認可されているかを決定するアルゴリズムのステップ 4 以降を実装していません。代わりに、ステップ 3 では、ホストの比較を緩和して、同一サイト上のホストを受け入れます。
4. それ以外の場合、通常の処理を続行します。
authenticatorMakeCredential を呼び出す直前に、次の手順を実行します。
1. authenticator が U2F プロトコル [FIDO-U2F-Message-Formats] をサポートする場合、excludeCredentialDescriptorList 内の各クレデンシャル記述子 C について:
  1. 次の値を「5 つの部分」に設定した U2F_AUTHENTICATE メッセージを authenticator に送信することで、C が authenticator 上で U2F を使用して作成されたかどうかを確認します。
    
    control byte
    
    0x07 ("check-only")
    
    challenge parameter
    
    32 個のランダムバイト
    
    application parameter
    
    appId の SHA-256 ハッシュ
    
    key handle length
    
    C.id の長さ（バイト単位）
    
    key handle
    
    C.id の値、すなわちクレデンシャル ID。
  2. authenticator が message:error:test-of-user-presence-required（すなわち成功）で応答した場合: この authenticator の通常処理を停止し、プラットフォーム固有の方法で認証器が適用不能であることを示します。たとえば、これは UI の形式であってもよく、または authenticator からユーザーの同意を要求し、それを受け取った時点で、認証器が InvalidStateError を返したかのように扱うこともできます。ユーザーの同意は、上記と同様に別の U2F_AUTHENTICATE メッセージを authenticator へ送信し、 control byte を 0x03 ("enforce-user-presence-and-sign") に設定して、レスポンスを無視することで要求できます。
2. 通常の処理を続行します。

クライアント拡張出力

拡張が処理されたことをリライングパーティに示すため、値 true を返します。

partial dictionary AuthenticationExtensionsClientOutputs {
  boolean appidExclude;
};

認証器拡張入力

なし。

認証器拡張処理

なし。

認証器拡張出力

なし。

10.3. ユーザー検証方式拡張 (uvm)

この拡張により、ユーザー検証方式を使用できます。

拡張識別子

uvm

適用可能な操作

登録および認証

クライアント拡張入力

この拡張がリライングパーティによって要求されていることを示す Boolean 値 true。

partial dictionary AuthenticationExtensionsClientInputs {
  boolean uvm;
};

クライアント拡張処理

クライアント拡張入力から認証器拡張入力を作成することを除き、ありません。

クライアント拡張出力

認証器拡張出力の要素をエンコードした、3 要素の数値配列からなる JSON 配列を返します。

typedef sequence<unsigned long> UvmEntry;
typedef sequence<UvmEntry> UvmEntries;

partial dictionary AuthenticationExtensionsClientOutputs {
  UvmEntries uvm;
};

認証器拡張入力

CBOR（major type 7、value 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 登録秘密鍵マテリアルを保護するために認証器が使用する方式。利用可能な値は、セクション 3.2 鍵保護型、[FIDO-Registry] で定義されています。
matcherProtectionType: ユーザー検証を実行するマッチャーを保護するために認証器が使用する方式。利用可能な値は、セクション 3.3 マッチャー保護型、[FIDO-Registry] で定義されています。

1 回の認証インスタンスで 3 を超える要素を使用できる場合、認証器ベンダーは、サーバーに最も関連すると考える 3 つの要素を選択して UVM に含めなければなりません。

2 つの要素が使用された多要素認証インスタンスについて、1 つの UVM 拡張を含む認証器データの例:

...                    -- RP ID ハッシュ (32 バイト)
81                     -- UP と ED が設定されている
00 00 00 01            -- （初期）署名カウンター
...                    -- すべての公開鍵 alg など
A1                     -- 拡張: 1 要素の CBOR マップ
    63                 -- キー 1: 3 バイトの CBOR テキスト文字列
        75 76 6d       -- "uvm" [=UTF-8 encoded=] 文字列
    82                 -- 値 1: 2 要素の使用を示す長さ 2 の CBOR 配列
        83              -- 項目 1: 長さ 3 の CBOR 配列
            02           -- サブ項目 1: ユーザー検証方式 Fingerprint の CBOR 整数
            04           -- サブ項目 2: 鍵保護型 TEE の CBOR short
            02           -- サブ項目 3: マッチャー保護型 TEE の CBOR short
        83              -- 項目 2: 長さ 3 の CBOR 配列
            04           -- サブ項目 1: ユーザー検証方式 Passcode の CBOR 整数
            01           -- サブ項目 2: 鍵保護型 Software の CBOR short
            01           -- サブ項目 3: マッチャー保護型 Software の CBOR short

10.4. クレデンシャルプロパティ拡張 (credProps)

このクライアント登録拡張は、登録セレモニーの結果として公開鍵クレデンシャルソースを作成した際に、クライアントが把握している特定のクレデンシャルプロパティを、要求元のWebAuthn リライングパーティへ報告しやすくします。

現時点では、1 つのクレデンシャルプロパティが定義されています。すなわち、常駐キークレデンシャルプロパティ（すなわち、クライアント側で検出可能なクレデンシャルプロパティ）です。

拡張識別子

credProps

適用可能な操作

登録

クライアント拡張入力

この拡張がリライングパーティによって要求されていることを示す Boolean 値 true。

partial dictionary AuthenticationExtensionsClientInputs {
    boolean credProps;
};

クライアント拡張処理

出力でクレデンシャルプロパティについて報告すること以外はありません。

クライアント拡張出力

clientExtensionResults["credProps"]["rk"] を、呼び出し時に使用された authenticatorMakeCredential 操作の requireResidentKey パラメーターの値に設定します。

dictionary CredentialPropertiesOutput {
    boolean rk;
};

partial dictionary AuthenticationExtensionsClientOutputs {
    CredentialPropertiesOutput credProps;
};

rk, 型は boolean

この任意のプロパティは、抽象的には常駐キークレデンシャルプロパティ（すなわち、クライアント側で検出可能なクレデンシャルプロパティ）と呼ばれ、登録セレモニーの結果として返された PublicKeyCredential がクライアント側で検出可能なクレデンシャルであるかどうかを示す Boolean 値です。 rk が true の場合、クレデンシャルは検出可能なクレデンシャルです。 rk が false の場合、クレデンシャルはサーバー側クレデンシャルです。 rk が存在しない場合、クレデンシャルが検出可能なクレデンシャルなのか、サーバー側クレデンシャルなのかは不明です。

注: 一部の認証器は、クライアントプラットフォームによって要求されていない場合でも検出可能なクレデンシャルを作成します。このため、クライアントプラットフォームは、false に設定できるという確信がないため、rk プロパティを省略せざるを得ない場合があります。リライングパーティは、credProps 拡張がサポートされている場合、クライアントプラットフォームが rk プロパティを設定するよう努めると想定すべきです。したがって、rk が存在しない場合、作成されたクレデンシャルはほぼ確実に検出不可能なクレデンシャルであることを示します。

認証器拡張入力

なし。

認証器拡張処理

なし。

認証器拡張出力

なし。

10.5. Large blob ストレージ拡張 (largeBlob)

このクライアント登録拡張および認証拡張により、リライングパーティは、クレデンシャルに関連付けられた不透明なデータを保存できます。認証器は少量のデータしか保存できず、ほとんどのリライングパーティはユーザーについて任意の量の状態を保存できるオンラインサービスであるため、これは特定の場合にのみ有用です。たとえば、リライングパーティは、集中型認証サービスを運用する代わりに証明書を発行したい場合があります。

注: リライングパーティは、不透明なデータが容量の限られたデバイスへ書き込まれる際に圧縮されると想定できるため、自身で圧縮する必要はありません。

証明書システムではクレデンシャルの公開鍵に対して署名する必要があり、その公開鍵は作成後にのみ利用可能になるため、この拡張は登録コンテキストで blob を書き込む機能を追加しません。ただし、リライングパーティは、後で認証拡張を使用したい場合、クレデンシャルを作成する際に登録拡張を使用すべきです。

証明書は一般的な認証器の保存能力に比べて大きいため、ユーザーエージェントは、この限られたリソースの割り当てについてユーザーを最適に案内し、悪用を防止するために、どのような表示や確認が適切かを考慮すべきです。

注: 相互運用のため、[FIDO-CTAP] を使用して認証器上に large blob を保存するユーザーエージェントは、その仕様で詳述されているクレデンシャルごとの大きな blobを保存するための規定を使用することが期待されます。

拡張識別子

largeBlob

適用可能な操作

登録および認証

クライアント拡張入力

partial dictionary AuthenticationExtensionsClientInputs {
    AuthenticationExtensionsLargeBlobInputs largeBlob;
};

enum LargeBlobSupport {
  "required",
  "preferred",
};

dictionary AuthenticationExtensionsLargeBlobInputs {
    DOMString support;
    boolean read;
    BufferSource write;
};

support, 型は DOMString: LargeBlobSupport のいずれかの値を取る DOMString。（§ 2.1.1 DOMString 型としての列挙型を参照。）登録時のみ有効です。
read, 型は boolean: リライングパーティが、アサーション対象クレデンシャルに関連付けられた以前に書き込まれた blob を取得したいことを示す Boolean 値。認証時のみ有効です。
write, 型は BufferSource: リライングパーティが既存のクレデンシャルとともに保存したい不透明なバイト文字列。認証時のみ有効です。

クライアント拡張処理 (登録)

read または write が存在する場合:
1. 名前が “NotSupportedError” である DOMException を返します。
support が存在し、その値が required の場合:
1. supported を true に設定します。
  
  注: これは、large blob を保存可能な認証器が利用可能になることを見越したものです。これは [[Create]]() のステップ 11 の拡張処理中に発生します。満足できる認証器が利用可能にならない場合、AuthenticationExtensionsLargeBlobOutputs は破棄されます。
2. 候補認証器が利用可能になった場合（[[Create]]() のステップ 19）、options を評価する前に、候補認証器が large blob を保存できない場合は続行します（すなわち候補認証器を無視します）。
それ以外の場合（すなわち support が存在しないか、その値が preferred の場合）:
1. 認証器が選択され、その選択された認証器が large blob をサポートする場合、supported を true に設定し、それ以外の場合は false に設定します。

クライアント拡張処理 (認証)

support が存在する場合:
1. 名前が “NotSupportedError” である DOMException を返します。
read と write の両方が存在する場合:
1. 名前が “NotSupportedError” である DOMException を返します。
read が存在し、その値が true の場合:
1. クライアント拡張出力 largeBlob を初期化します。
2. いずれかの認証器が（[[DiscoverFromExternalSource]]() で）成功を示した場合、アサーション対象クレデンシャルに関連付けられた largeBlob データがあれば、それを読み取ろうとします。
3. 成功した場合、blob をその結果に設定します。
  
  注: 読み取りに成功しなかった場合、largeBlob は AuthenticationExtensionsClientOutputs に存在しますが、blob メンバーは存在しません。
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: 作成されたクレデンシャルが large blob の保存をサポートする場合、かつその場合に限り true。登録出力にのみ存在します。
blob, 型は ArrayBuffer: rawId によって識別されるクレデンシャルに関連付けられていた不透明なバイト文字列。 read が true の場合にのみ有効です。
written, 型は boolean: write の内容が、指定されたクレデンシャルに関連付けられて認証器に正常に保存されたことを示す Boolean 値。

認証器拡張処理

この拡張は、ユーザーエージェントに large blob を認証器へ保存するか、認証器から取得するよう指示します。したがって、リライングパーティ向けの認証器との直接的なやり取りは規定しません。

11. ユーザーエージェントの自動化

ユーザーエージェントの自動化およびWeb アプリケーションのテストを目的として、この文書では多数の [WebDriver] 拡張コマンドを定義します。

11.1. WebAuthn WebDriver 拡張 capability

以下で定義される拡張コマンドが利用可能であることを通知するため、新しい拡張 capabilityを定義します。

Capability	キー	値の型	説明
仮想認証器のサポート	`"webauthn:virtualAuthenticators"`	boolean	エンドポイントノードがすべての仮想認証器コマンドをサポートするかどうかを示します。

capability を検証する際、 "webauthn:virtualAuthenticators" を value で検証する拡張固有のサブステップは次のとおりです。

value がbooleanでない場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
それ以外の場合、deserialized を value に設定します。

capability を照合する際、 "webauthn:virtualAuthenticators" を value と照合する拡張固有の手順は次のとおりです。

value が true であり、エンドポイントノードが仮想認証器コマンドを一切サポートしていない場合、照合は失敗します。
それ以外の場合、照合は成功します。

11.1.1. 認証器拡張 capability

さらに、この仕様で定義される各認証器拡張（すなわち認証器拡張処理を定義するもの）について、拡張 capabilityも定義されます。

Capability	キー	値の型	説明
ユーザー検証方式拡張のサポート	`"webauthn:extension:uvm"`	boolean	エンドポイントノードの WebAuthn WebDriver 実装がユーザー検証方式拡張をサポートするかどうかを示します。
Large Blob ストレージ拡張のサポート	`"webauthn:extension:largeBlob"`	boolean	エンドポイントノードの WebAuthn WebDriver 実装が largeBlob 拡張をサポートするかどうかを示します。

capability を検証する際、認証器拡張 capability key を value で検証する拡張固有のサブステップは次のとおりです。

value がbooleanでない場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
それ以外の場合、deserialized を value に設定します。

capability を照合する際、認証器拡張 capability key を value と照合する拡張固有の手順は次のとおりです。

value が true であり、エンドポイントノードの WebAuthn WebDriver 実装が key によって識別される認証器拡張をサポートしていない場合、照合は失敗します。
それ以外の場合、照合は成功します。

定義済みの認証器拡張を実装するユーザーエージェントは、対応する認証器拡張 capabilityを実装すべきです。

11.2. 仮想認証器

これらの WebDriver 拡張コマンドは、認証器モデルのソフトウェア実装である仮想認証器を作成し、それと対話します。仮想認証器は仮想認証器データベースに保存されます。保存される各仮想認証器には、次のプロパティがあります。

authenticatorId

[RFC3986] の付録 A で定義される unreserved 生成規則の文字を最大 48 文字使用して作成された 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`

認証器構成は、parameters としてリモートエンドの手順へ渡される JSON Object です。これには次の 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 つのユーザー検証方式エントリ	空の配列

リモートエンドの手順は次のとおりです。

parameters が JSON Object でない場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。

注: parameters は認証器構成オブジェクトです。
authenticator を新しい仮想認証器とします。
parameters 内の列挙可能な各own property について:
1. key をプロパティの名前とします。
2. value を、parameters から key という名前のプロパティを取得した結果とします。
3. parameters 内に key と一致する key がない場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
4. value がその key の valid values のいずれでもない場合、 WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
5. authenticator 上でプロパティ key を value に設定します。
認証器構成内でデフォルトが定義されている各プロパティについて:
1. key が authenticator の定義済みプロパティでない場合、authenticator 上で key を default に設定します。
認証器構成内の各プロパティについて:
1. key が authenticator の定義済みプロパティでない場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
authenticator.extensions 内の各 extension について:
1. extension がエンドポイントノードの WebAuthn WebDriver 実装でサポートされる拡張識別子でない場合、WebDriver エラーコード unsupported operation を持つWebDriver エラーを返します。
有効で一意なauthenticatorId を生成します。
authenticator 上でプロパティ authenticatorId を authenticatorId に設定します。
authenticator を仮想認証器データベースに保存します。
データ authenticatorId とともに成功を返します。

11.4. 仮想認証器の削除

仮想認証器の削除 WebDriver 拡張コマンドは、以前に作成された仮想認証器を削除します。これは次のように定義されます。

HTTP メソッド	URI テンプレート
DELETE	`/session/{session id}/webauthn/authenticator/{authenticatorId}`

リモートエンドの手順は次のとおりです。

authenticatorId が仮想認証器データベースに保存されているいずれの仮想認証器とも一致しない場合、 WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
authenticatorId によって識別される仮想認証器を仮想認証器データベースから削除します。
成功を返します。

11.5. クレデンシャルの追加

クレデンシャルの追加 WebDriver 拡張コマンドは、既存の仮想認証器に公開鍵クレデンシャルソースを注入します。これは次のように定義されます。

HTTP メソッド	URI テンプレート
POST	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credential`

クレデンシャルパラメーターは、parameters としてリモートエンドの手順へ渡される JSON Object です。これには次の key と value のペアが含まれます。

キー	説明	値の型
`credentialId`	Base64url エンコーディングでエンコードされたクレデンシャル ID。	string
`isResidentCredential`	`true` に設定されている場合、クライアント側で検出可能なクレデンシャルが作成されます。`false` に設定されている場合、代わりにサーバー側クレデンシャルが作成されます。	boolean
`rpId`	クレデンシャルがスコープ設定されるリライングパーティ ID。	string
`privateKey`	[RFC5958] に従った単一の秘密鍵を含む非対称鍵パッケージで、Base64url エンコーディングを使用してエンコードされます。	string
`userHandle`	クレデンシャルに関連付けられたuserHandleをBase64url エンコーディングでエンコードしたもの。このプロパティは定義されていない場合があります。	string
`signCount`	公開鍵クレデンシャルソースに関連付けられた署名カウンターの初期値。	number
`largeBlob`	クレデンシャルごとの大きな blobで、公開鍵クレデンシャルソースに関連付けられ、Base64url エンコーディングを使用してエンコードされます。このプロパティは定義されていない場合があります。	string

リモートエンドの手順は次のとおりです。

parameters が JSON Object でない場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。

注: parameters はクレデンシャルパラメーターオブジェクトです。
credentialId を、parameters の credentialId プロパティに対してBase64url エンコーディングをデコードした結果とします。
credentialId が失敗の場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
isResidentCredential を parameters の isResidentCredential プロパティとします。
isResidentCredential が定義されていない場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
rpId を parameters の rpId プロパティとします。
rpId が有効なRP ID でない場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
privateKey を、parameters の privateKey プロパティに対してBase64url エンコーディングをデコードした結果とします。
privateKey が失敗の場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
privateKey が、[RFC5958] に従った P-256 曲線上の単一の ECDSA 秘密鍵を含む、有効にエンコードされた非対称鍵パッケージでない場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
parameters の userHandle プロパティが定義されている場合:
1. userHandle を、parameters の userHandle プロパティに対してBase64url エンコーディングをデコードした結果とします。
2. userHandle が失敗の場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
それ以外の場合:
1. isResidentCredential が true の場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
2. userHandle を null とします。
authenticatorId が仮想認証器データベースに保存されたどの仮想認証器とも一致しない場合、 WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
authenticator を、authenticatorId と一致する仮想認証器とします。
isResidentCredential が true であり、authenticator の hasResidentKey プロパティが false の場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
authenticator がlargeBlob 拡張をサポートし、parameters の largeBlob 機能が定義されている場合:
1. largeBlob を、parameters の largeBlob プロパティに対してBase64url エンコーディングをデコードした結果とします。
2. largeBlob が失敗の場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
それ以外の場合:
1. largeBlob を null とします。
isResidentCredential が true の場合、credential を新しいクライアント側で検出可能な公開鍵クレデンシャルソースとし、それ以外の場合は新しいサーバー側公開鍵クレデンシャルソースとし、その項目を次のとおりとします。

type

public-key

id

credentialId

privateKey

privateKey

rpId

rpId

userHandle

userHandle
開始値が parameters の signCount と等しい、または signCount が null の場合は 0 である署名カウンター counter を credential に関連付けます。
largeBlob が null でない場合、credential に関連付けられたクレデンシャルごとの大きな blobを largeBlob に設定します。
credential と counter を authenticator のデータベースに保存します。
成功を返します。

11.6. クレデンシャルの取得

クレデンシャルの取得 WebDriver 拡張コマンドは、仮想認証器に保存されている各公開鍵クレデンシャルソースについて、クレデンシャルの追加または navigator.credentials.create() のどちらを使用して保存されたかにかかわらず、1 つのクレデンシャルパラメーターオブジェクトを返します。これは次のように定義されます。

HTTP メソッド	URI テンプレート
GET	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credentials`

リモートエンドの手順は次のとおりです。

authenticatorId が仮想認証器データベースに保存されたどの仮想認証器とも一致しない場合、 WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
credentialsArray を空の配列とします。
authenticatorId によって識別される認証器によって管理される各公開鍵クレデンシャルソース credential について、対応するクレデンシャルパラメーター Object を構築し、credentialsArray に追加します。
credentialsArray を含むデータとともに成功を返します。

11.7. クレデンシャルの削除

クレデンシャルの削除 WebDriver 拡張コマンドは、仮想認証器に保存された公開鍵クレデンシャルソースを削除します。これは次のように定義されます。

HTTP メソッド	URI テンプレート
DELETE	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credentials/{credentialId}`

リモートエンドの手順は次のとおりです。

authenticatorId が仮想認証器データベースに保存されたどの仮想認証器とも一致しない場合、 WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
authenticator を、authenticatorId によって識別される仮想認証器とします。
credentialId が authenticator によって管理されるいずれの公開鍵クレデンシャルソースとも一致しない場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
authenticator によって管理され、credentialId によって識別される公開鍵クレデンシャルソースを削除します。
成功を返します。

11.8. すべてのクレデンシャルの削除

すべてのクレデンシャルの削除 WebDriver 拡張コマンドは、仮想認証器に保存されたすべての公開鍵クレデンシャルソースを削除します。これは次のように定義されます。

HTTP メソッド	URI テンプレート
DELETE	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credentials`

リモートエンドの手順は次のとおりです。

authenticatorId が仮想認証器データベースに保存されたどの仮想認証器とも一致しない場合、 WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
authenticatorId によって識別される仮想認証器によって管理されるすべての公開鍵クレデンシャルソースを削除します。
成功を返します。

11.9. ユーザー検証済みの設定

ユーザー検証済みの設定拡張コマンドは、仮想認証器上の isUserVerified プロパティを設定します。これは次のように定義されます。

HTTP メソッド	URI テンプレート
POST	`/session/{session id}/webauthn/authenticator/{authenticatorId}/uv`

リモートエンドの手順は次のとおりです。

parameters が JSON Object でない場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
authenticatorId が仮想認証器データベースに保存されたどの仮想認証器とも一致しない場合、 WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
isUserVerified が parameters の定義済みプロパティでない場合、WebDriver エラーコード invalid argument を持つWebDriver エラーを返します。
authenticator を、authenticatorId によって識別される仮想認証器とします。
authenticator の isUserVerified プロパティを、parameters の isUserVerified プロパティに設定します。
成功を返します。

12. IANA に関する考慮事項

12.1. WebAuthn アテステーションステートメント形式識別子登録の更新

このセクションでは、セクション § 8 定義済みアテステーションステートメント形式で定義され、[WebAuthn-1] で最初に登録された、以下に列挙するアテステーションステートメント形式について、[RFC8809] によって確立された IANA "WebAuthn Attestation Statement Format Identifiers" レジストリ [IANA-WebAuthn-Registries] の参照先をこの仕様に更新します。

WebAuthn アテステーションステートメント形式識別子: packed
説明: "packed" アテステーションステートメント形式は、アテステーション用に WebAuthn 向けに最適化された形式です。非常にコンパクトでありながら拡張可能なエンコーディング方式を使用します。この形式は、リソースが限られた認証器（たとえばセキュアエレメント）でも実装できます。
仕様文書: この仕様のセクション § 8.2 Packed アテステーションステートメント形式
WebAuthn アテステーションステートメント形式識別子: tpm
説明: TPM アテステーションステートメント形式は、rawData および署名フィールドの計算方法は異なりますが、packed アテステーションステートメント形式と同じ形式でアテステーションステートメントを返します。
仕様文書: この仕様のセクション § 8.3 TPM アテステーションステートメント形式
WebAuthn アテステーションステートメント形式識別子: android-key
説明: バージョン "N" 以降のプラットフォーム認証器は、この独自の "hardware attestation" ステートメントを提供する場合があります。
仕様文書: この仕様のセクション § 8.4 Android Key アテステーションステートメント形式
WebAuthn アテステーションステートメント形式識別子: android-safetynet
説明: Android ベースのプラットフォーム認証器は、Android SafetyNet API に基づくアテステーションステートメントを生成してもよいものとします。
仕様文書: この仕様のセクション § 8.5 Android SafetyNet アテステーションステートメント形式
WebAuthn アテステーションステートメント形式識別子: fido-u2f
説明: FIDO U2F 認証器で使用されます
仕様文書: この仕様のセクション § 8.6 FIDO U2F アテステーションステートメント形式

12.2. WebAuthn アテステーションステートメント形式識別子の登録

このセクションでは、セクション § 8 定義済みアテステーションステートメント形式で新たに定義された、以下に列挙するアテステーションステートメント形式を、[RFC8809] によって確立された IANA "WebAuthn Attestation Statement Format Identifiers" レジストリ [IANA-WebAuthn-Registries] に登録します。

WebAuthn アテステーションステートメント形式識別子: apple
説明: Apple デバイスのプラットフォーム認証器で使用されます
仕様文書: この仕様のセクション § 8.8 Apple 匿名アテステーションステートメント形式
WebAuthn アテステーションステートメント形式識別子: none
説明: WebAuthn リライングパーティがアテステーション情報の受信を望まないことを示した場合に、認証器が提供するアテステーションステートメントを置き換えるために使用されます。
仕様文書: この仕様のセクション § 8.7 None アテステーションステートメント形式

12.3. WebAuthn 拡張識別子登録の更新

このセクションでは、セクション § 10 定義済み拡張で定義され、[WebAuthn-1] で最初に登録された、以下に列挙する拡張識別子値について、[RFC8809] によって確立された IANA "WebAuthn Extension Identifiers" レジストリ [IANA-WebAuthn-Registries] の参照先をこの仕様に更新します。

WebAuthn 拡張識別子: appid
説明: この認証拡張により、従来の FIDO JavaScript API を使用して以前にクレデンシャルを登録したWebAuthn リライングパーティは、アサーションを要求できます。
仕様文書: この仕様のセクション § 10.1 FIDO AppID 拡張 (appid)
WebAuthn 拡張識別子: uvm
説明: この登録拡張および認証拡張により、ユーザー検証方式を使用できます。ユーザー検証方式拡張は、WebAuthn 操作に使用されたユーザー検証方式（要素）をWebAuthn リライングパーティに返します。
仕様文書: この仕様のセクション § 10.3 ユーザー検証方式拡張 (uvm)

12.4. WebAuthn 拡張識別子の登録

このセクションでは、セクション § 10 定義済み拡張で新たに定義された、以下に列挙する拡張識別子値を、[RFC8809] によって確立された IANA "WebAuthn Extension Identifiers" レジストリ [IANA-WebAuthn-Registries] に登録します。

WebAuthn 拡張識別子: appidExclude
説明: この登録拡張により、WebAuthn リライングパーティは、従来の FIDO U2F JavaScript API [FIDOU2FJavaScriptAPI] で作成された指定のクレデンシャルを含む認証器を除外できます。
仕様文書: この仕様のセクション § 10.2 FIDO AppID 除外拡張 (appidExclude)
WebAuthn 拡張識別子: credProps
説明: このクライアント登録拡張により、新たに作成されたクレデンシャルのプロパティを、クライアントによる判断に基づき、呼び出し元のWebAuthn リライングパーティのWeb アプリケーションに報告できます。
仕様文書: この仕様のセクション § 10.4 クレデンシャルプロパティ拡張 (credProps)
WebAuthn 拡張識別子: largeBlob
説明: このクライアント登録拡張および認証拡張により、リライングパーティは、クレデンシャルに関連付けられた不透明なデータを保存できます。
仕様文書: この仕様のセクション § 10.5 Large blob ストレージ拡張 (largeBlob)

13. セキュリティに関する考慮事項

この仕様は、Web API と暗号学的なピアエンティティ認証プロトコルを定義します。 Web Authentication API により、Web 開発者（すなわち「作者」）は、Web Authentication プロトコルを自身の登録および認証セレモニーで利用できます。 Web Authentication プロトコルのエンドポイントを構成するエンティティは、ユーザーが制御するWebAuthn 認証器と、WebAuthn リライングパーティのリライングパーティのWeb アプリケーションをホストするコンピューティング環境です。このモデルでは、ユーザーエージェントはWebAuthn クライアントとともに、認証器とリライングパーティとの間の仲介者を構成します。さらに、認証器はその来歴についてリライングパーティにアテステーションできます。

現時点では、この仕様には詳細なセキュリティ上の考慮事項は含まれていません。ただし、[FIDOSecRef] 文書は、この仕様に全体として適用可能なセキュリティ分析を提供しています。また、[FIDOAuthnrSecReqs] 文書群は、認証器のセキュリティ特性に関する有用な情報を提供します。

以下のサブセクションは、現在の Web Authentication 固有のセキュリティ上の考慮事項を構成します。これらは対象読者ごとに分けられており、一般的なセキュリティ上の考慮事項はこのセクションの直接のサブセクションとして、認証器、クライアント、およびリライングパーティの実装者に固有のセキュリティ上の考慮事項は、それぞれ対応するサブセクションにまとめられています。

13.1. クレデンシャル ID は署名されない

クレデンシャル IDは署名されません。これは問題ではありません。なぜなら、認証器が誤ったクレデンシャル IDを返した場合、または攻撃者がクレデンシャル IDを傍受して改変した場合に起こるのは、WebAuthn リライングパーティが、返された署名済み認証器データ（別名アサーション）を検証するための正しいクレデンシャル公開鍵を検索できず、その結果、相互作用がエラーで終了することだけだからです。

13.2. クライアントと認証器の物理的近接性

WebAuthn の認証器モデルでは、一般にローミング認証器はクライアントの物理的近くにあり、直接通信すると想定されています。この構成には重要な利点がいくつかあります。

クライアントと認証器の物理的近接性が保証されることは、所有しているものという認証要素の主要な強みです。たとえば、ローミング認証器が USB または Bluetooth のみで通信できる場合、これらのトランスポートの限られた通信範囲により、悪意ある主体が認証器と相互作用するには、物理的にその範囲内にいなければならないことが保証されます。リモートから呼び出せる認証器では、必ずしもこれは当てはまりません — 認証器がユーザー存在を検証する場合でも、ユーザーは、リモートから開始された悪意ある要求を認可するよう騙される可能性があります。

クライアントと認証器が直接通信することで、クライアントはクレデンシャルに対するスコープ制限を強制できます。これに対し、クライアントと認証器の通信が第三者によって仲介される場合、クライアントは、その第三者がスコープ制限を強制し、認証器へのアクセスを制御することを信頼しなければなりません。そのいずれかに失敗すると、悪意あるリライングパーティが他のリライングパーティに対して有効な認証アサーションを受け取ったり、悪意あるユーザーが他のユーザーの認証アサーションへアクセスしたりする可能性があります。

認証器がクライアントの物理的近くにある必要がない、またはクライアントと認証器が直接通信しないソリューションを設計する場合、設計者は、これがスコープ制限の強制と、認証器の所有しているものという認証要素としての強度にどのような影響を与えるかを検討すべきです。

13.3. 認証器に関するセキュリティ上の考慮事項

13.3.1. アテステーション証明書階層

アテステーション証明書には 3 層階層（すなわち、アテステーションルート、アテステーション発行 CA、アテステーション証明書）が推奨されます。また、各WebAuthn 認証器デバイスライン（すなわちモデル）ごとに、別個の発行 CA を使用し、特定バージョンの認証器モデルに関する問題を分離しやすくすることも推奨されます。

アテステーションルート証明書が単一のWebAuthn 認証器デバイスライン（すなわち AAGUID）専用でない場合、AAGUID はアテステーション証明書自体に指定し、認証器データと照合して検証できるようにすべきです。

13.3.2. アテステーション証明書およびアテステーション証明書 CA の侵害

アテステーション証明書の発行に使用される中間 CA またはルート CA が侵害された場合でも、WebAuthn 認証器のアテステーションキーペア自体は安全ですが、その証明書はもはや信頼できません。自身の認証器モデルのアテステーション公開鍵を記録しているWebAuthn 認証器製造者は、新しい中間 CA または新しいルート CA から、これらの鍵に対する新しいアテステーション証明書を発行できます。ルート CA が変更された場合、WebAuthn リライングパーティは、信頼するルート証明書をそれに応じて更新しなければなりません。

WebAuthn 認証器のアテステーション証明書は、その秘密鍵が侵害された場合、発行 CA によって失効させなければなりません。WebAuthn 認証器製造者は、露出の原因がファームウェアの欠陥であった場合、ファームウェア更新を配布し、すでに製造済みのWebAuthn 認証器へ新しいアテステーション秘密鍵と証明書を注入する必要がある場合があります。（これを行うプロセスはこの仕様の範囲外です。）WebAuthn 認証器製造者がこの能力を持たない場合、リライングパーティが、影響を受けたWebAuthn 認証器からの今後のアテステーションステートメントを信頼することは不可能になる場合があります。

§ 13.4.5 失効したアテステーション証明書にある、リライングパーティに関する関連するセキュリティ上の考慮事項も参照してください。

13.4. リライングパーティに関するセキュリティ上の考慮事項

13.4.1. WebAuthn リライングパーティにとってのセキュリティ上の利点

この仕様がWebAuthn リライングパーティにもたらす主な利点には、次のものがあります。

広範に互換性があり、使いやすい多要素認証を使用して、ユーザーとアカウントを保護できます。
リライングパーティは、ユーザーへ認証器ハードウェアを配布する必要がありません。代わりに、各ユーザーは任意の適合認証器を独自に入手し、同じ認証器を任意の数のリライングパーティで使用できます。リライングパーティは、認証器から返されるアテステーションステートメントを調べることで、認証器のセキュリティプロパティに対する要件を任意で強制できます。
認証セレモニーは中間者攻撃への耐性があります。登録セレモニーについては、以下の§ 13.4.4 アテステーションの制限を参照してください。
リライングパーティは、ほとんどまたはまったくコードを変更することなく、複数種類のユーザー検証（たとえば PIN、生体認証、および/または将来の方式）を自動的にサポートでき、各ユーザーは認証器を選択することによって、使用したい方式を決定できます。
リライングパーティは、上記の利点を得るために追加の秘密情報を保存する必要がありません。

適合性セクションで述べられているように、リライングパーティは、上記のすべてのセキュリティ上の利点を得るため、§ 7 WebAuthn リライングパーティの操作で説明されるとおりに動作しなければなりません。ただし、これからわずかに外れる注目すべきユースケースが、以下の§ 13.4.4 アテステーションの制限で説明されています。

13.4.2. 埋め込み使用に関する可視性の考慮事項

§ 5.10 iframe 要素内での Web Authentication の使用で説明されているように、埋め込みコンテキスト、たとえば iframe内で WebAuthn を単純に使用すると、ユーザーがUI リドレッシング攻撃、別名「クリックジャッキング」に対して脆弱になる場合があります。これは、攻撃者が自身の UI をリライングパーティの意図した UI の上に重ね、ユーザーを騙してリライングパーティで意図しない操作を実行させようとするものです。たとえば、これらの手法を使用することで、攻撃者はユーザーを騙して商品の購入、送金などを行わせられる場合があります。

WebAuthn 固有の UI は通常クライアントプラットフォームによって処理されるためUI リドレッシングには脆弱ではありませんが、WebAuthn を使用する埋め込みコンテンツを持つリライングパーティにとって、そのコンテンツの UI がユーザーに見えることを保証することは重要である可能性が高いです。そのための新しい手段の 1 つは、実験的なIntersection Observer v2 の isVisible 属性の状態を監視することです。たとえば、埋め込みコンテキストで実行されるリライングパーティのスクリプトは、isVisble が false に設定されていることを検出した場合、自身を先回りしてポップアップウィンドウに読み込むことで、コンテンツが隠されることを回避できます。

13.4.3. 暗号学的チャレンジ

暗号プロトコルとして、Web Authentication はリプレイ攻撃を回避するため、ランダム化されたチャレンジに依存します。したがって、PublicKeyCredentialCreationOptions.challenge と PublicKeyCredentialRequestOptions.challenge の両方の値は、リライングパーティが信頼する環境（たとえばサーバー側）でランダムに生成しなければならず、クライアントのレスポンスで返される challenge 値は、生成された値と一致しなければなりません。これは、クライアントの動作に依存しない方法で行うべきです。たとえば、リライングパーティは操作が完了するまでチャレンジを一時的に保存すべきです。不一致を許容すると、プロトコルのセキュリティが損なわれます。

リプレイ攻撃を防ぐため、チャレンジには推測を実行不可能にするのに十分なエントロピーが含まれていなければなりません。したがって、チャレンジは少なくとも 16 バイトの長さであるべきです。

13.4.4. アテステーションの制限

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

新しいクレデンシャルを登録する際、アテステーションステートメントが存在する場合、それによってWebAuthn リライングパーティは、さまざまな認証器の特性について保証を導出できる場合があります。たとえば、認証器のモデルや、クレデンシャル秘密鍵をどのように保存し保護するかなどです。ただし、アテステーションステートメント単独では、リライングパーティが、アテステーションオブジェクトがユーザーの意図した認証器によって生成され、中間者攻撃者によって生成されたものではないことを検証する手段を提供しないことに注意することが重要です。たとえば、そのような攻撃者はリライングパーティのスクリプトに注入された悪意あるコードを使用できる可能性があります。したがって、リライングパーティは、アテステーションオブジェクトを中間者攻撃から保護するため、TLS や関連技術などの他の手段に依存しなければなりません。

登録セレモニーが安全に完了し、認証器がクレデンシャル秘密鍵の機密性を維持するという前提のもとでは、その公開鍵クレデンシャルを使用する後続の認証セレモニーは、中間者攻撃への耐性があります。

上記の議論は、すべてのアテステーション型に当てはまります。すべての場合において、中間者攻撃者が PublicKeyCredential オブジェクト（アテステーションステートメントおよび登録されるクレデンシャル公開鍵を含む）を置き換え、その後、同じリライングパーティにスコープ設定され、同じ攻撃者を通過する将来の認証アサーションを改変することが可能です。

このような攻撃は検出できる可能性があります。リライングパーティはユーザーのものではなく攻撃者のクレデンシャル公開鍵を登録しているため、攻撃者はそのリライングパーティとの後続のすべての認証セレモニーを改変しなければなりません。改変されなかったセレモニーは失敗し、攻撃が明らかになる可能性があります。

自己アテステーションおよびNone 以外のアテステーション型は、このような攻撃の難易度を上げることができます。なぜなら、リライングパーティが認証器のモデル名などの認証器情報をユーザーに表示できる可能性があるためです。したがって、攻撃者はユーザーの認証器と同じモデルの真正な認証器を使用する必要がある場合があり、またはユーザーが、リライングパーティが予想していたものと異なる認証器モデルを報告していることに気付く可能性があります。

注: 上記で説明した中間者攻撃のすべての変種は、従来のパスワード認証に対する中間者攻撃よりも、攻撃者にとって実行が困難です。

13.4.5. 失効したアテステーション証明書

アテステーション証明書の検証が、失効した中間アテステーション CA 証明書によって失敗し、リライングパーティのポリシーがこのような状況で登録/認証要求を拒否することを要求する場合、リライングパーティは、 CA 侵害日より後に、同じ中間 CA に連鎖するアテステーション証明書を使用して登録された公開鍵クレデンシャルも、登録解除する（または「自己アテステーション」と同等の信頼レベルとしてマークする）ことが推奨されます。したがって、リライングパーティは、このような証明書が失効した後に登録が実行された場合に関連する公開鍵クレデンシャルを登録解除できるよう、登録時に中間アテステーション CA 証明書を記憶しておくことが推奨されます。

§ 13.3.2 アテステーション証明書およびアテステーション証明書 CA の侵害にある、認証器に関する関連するセキュリティ上の考慮事項も参照してください。

13.4.6. クレデンシャルの喪失と鍵の移動性

この仕様は、クレデンシャル秘密鍵をバックアップするためのプロトコルも、認証器間で共有するためのプロトコルも定義しません。一般に、クレデンシャル秘密鍵は、それを作成した認証器から決して出ないことが想定されています。したがって、一般に認証器を失うことは、失われた認証器にバインドされたすべてのクレデンシャルを失うことを意味します。ユーザーがリライングパーティに登録したクレデンシャルを 1 つしか持たない場合、アカウントへアクセスできなくなる可能性があります。秘密鍵をバックアップまたは共有する代わりに、 Web Authentication API では、同じユーザーについて複数のクレデンシャルを登録できます。たとえば、ユーザーは頻繁に使用するクライアントデバイスにプラットフォームクレデンシャルを登録し、バックアップ用、および新しいか使用頻度の低いクライアントデバイスで使用するため、1 つ以上のローミングクレデンシャルを登録できます。

リライングパーティは、ユーザーが同じアカウントに複数のクレデンシャルを登録することを許可し、推奨すべきです。リライングパーティは、これらの異なるクレデンシャルが異なる認証器にバインドされることを保証するため、 excludeCredentials および user.id オプションを利用すべきです。

13.4.7. 保護されていないアカウントの検出

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

このセキュリティ上の考慮事項の適用対象は、リライングパーティであり、認証セレモニーを非-空の allowCredentials 引数とともに最初の認証ステップとしてサポートするものです。たとえば、最初の認証ステップとしてサーバー側クレデンシャルによる認証を使用する場合です。

この場合、allowCredentials 引数によって、どのユーザーアカウントに WebAuthn クレデンシャルが登録されているか、またどれには登録されていないかという情報が漏洩する危険があり、これはアカウント保護強度のシグナルになる可能性があります。たとえば、攻撃者がユーザー名だけを提供して認証セレモニーを開始でき、リライングパーティが一部のユーザーには空でない allowCredentials で応答し、他のユーザーには失敗またはパスワードチャレンジで応答するとします。攻撃者は、後者のユーザーアカウントでは認証成功のために WebAuthn アサーションが必要ではない可能性が高いと推測でき、より弱い可能性のあるそれらのアカウントに攻撃を集中できます。

この問題は、§ 14.6.2 ユーザー名列挙および§ 14.6.3 クレデンシャル ID によるプライバシー漏洩で説明される問題と類似しており、同様の方法で緩和できます。

14. プライバシーに関する考慮事項

[FIDO-Privacy-Principles] のプライバシー原則もこの仕様に適用されます。

このセクションは対象読者ごとに分けられており、一般的なプライバシー上の考慮事項はこのセクションの直接のサブセクションとして、認証器、クライアント、およびリライングパーティの実装者に固有のプライバシー上の考慮事項は、それぞれ対応するサブセクションにまとめられています。

14.1. 匿名性解除の防止策

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

Web Authentication API の設計の多くの側面は、プライバシー上の懸念によって動機付けられています。この仕様で考慮される主な懸念は、ユーザーの個人的な識別情報、すなわち人間の識別、または別々の識別情報が同じ人間に属するものとして関連付けられることからの保護です。Web Authentication API はいかなる形式のグローバルな識別情報も使用または提供しませんが、次の種類の潜在的に関連付け可能な識別子を使用します。

ユーザーのクレデンシャル IDおよびクレデンシャル公開鍵。

これらはWebAuthn リライングパーティによって登録され、その後対応するクレデンシャル秘密鍵を所有していることをユーザーが証明するために使用されます。これらはまた、クライアントと認証器との通信においてクライアントからも見えます。
各リライングパーティに固有のユーザー識別情報、たとえばユーザー名やユーザーハンドル。

これらの識別情報は、当然ながら各リライングパーティが自身のシステム内でユーザーを識別するために使用します。また、クライアントと認証器との通信において、クライアントからも見えます。
ユーザーの生体特性、たとえば指紋または顔認識データ [ISOBiometricVocabulary]。

これは任意で認証器がユーザー検証を実行するために使用します。リライングパーティには開示されませんが、プラットフォーム認証器の場合、実装によってはクライアントから見える可能性があります。
ユーザーの認証器のモデル、たとえば製品名。

これは登録中にリライングパーティへ提供されるアテステーションステートメントで公開されます。また、クライアントと認証器との通信において、クライアントからも見えます。
ユーザーの認証器の識別情報、たとえばシリアル番号。

これは、クライアントが認証器との通信を可能にするために使用する可能性がありますが、リライングパーティには公開されません。

上記の情報の一部は、必然的にリライングパーティと共有されます。以下のセクションでは、悪意あるリライングパーティがそれを使用してユーザーの個人的な識別情報を発見することを防ぐための対策について説明します。

14.2. 匿名で、スコープ設定され、相関不可能な公開鍵クレデンシャル

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

クレデンシャル IDおよびクレデンシャル公開鍵は強力な認証を可能にするためWebAuthn リライングパーティと共有する必要がありますが、それらは識別性を最小限に抑え、リライングパーティ間で共有されないよう設計されています。

クレデンシャル IDおよびクレデンシャル公開鍵は、単独では意味を持ちません。これらはクレデンシャルキーペアのみを識別し、ユーザーを直接識別しないためです。
各公開鍵クレデンシャルは、特定のリライングパーティに厳密にスコープ設定され、クライアントは、その存在が他のリライングパーティに明らかにならないことを保証します。したがって、悪意あるリライングパーティは、クライアントにユーザーの他の識別情報を開示するよう要求できません。
クライアントはまた、公開鍵クレデンシャルの存在が、ユーザーの同意なしにリライングパーティに明らかにならないことを保証します。これについては、§ 14.5.1 登録セレモニーのプライバシーおよび§ 14.5.2 認証セレモニーのプライバシーでさらに詳しく説明されています。したがって、悪意あるリライングパーティは、ユーザーが公開鍵クレデンシャルを登録し利用可能であっても、ユーザーを密かに識別できません。
認証器は、異なる公開鍵クレデンシャルのクレデンシャル IDとクレデンシャル公開鍵が、同じユーザーに属するものとして相関できないことを保証します。したがって、悪意ある 2 つのリライングパーティは、意図的に再利用されたユーザー名や電子メールアドレスなどの追加情報なしに、システム間でユーザーを関連付けることができません。
認証器は、そのアテステーション証明書が単一の認証器または少数の認証器のグループを識別できるほど一意でないことを保証します。これについては、 § 14.4.1 アテステーションのプライバシーでさらに詳しく説明されています。したがって、悪意ある 2 つのリライングパーティは、個々の認証器を追跡することでシステム間のユーザーを関連付けることができません。

さらに、クライアント側で検出可能な公開鍵クレデンシャルソースには、任意でリライングパーティによって指定されたユーザーハンドルを含めることができます。その後、クレデンシャルを使用してユーザーの識別と認証の両方を行うことができます。これは、プライバシーを重視するリライングパーティが、従来のユーザー名なしでユーザーにアカウントを作成させることができ、リライングパーティ間の非相関性をさらに向上できることを意味します。

14.3. 認証器ローカルの生体認識

生体認証器は、生体認識を認証器内部で実行します。ただし、プラットフォーム認証器では、実装によっては生体データがクライアントから見える場合もあります。生体データは WebAuthn リライングパーティには開示されません。これは、公開鍵クレデンシャルの作成および登録、またはそれを使用する認証を認可するためのユーザー検証をローカルに実行するためだけに使用されます。したがって、悪意あるリライングパーティは、生体データを介してユーザーの個人的な識別情報を発見できず、リライングパーティでセキュリティ侵害が発生しても、攻撃者が他のリライングパーティでログインを偽造するために使用できる生体データが露出することはありません。

リライングパーティが生体認識を要求する場合、これは生体認証器がユーザー検証を実行することでローカルに行われ、その後、署名済みアサーションレスポンス内のUV フラグを設定して結果を通知します。生体データ自体をリライングパーティに開示することはありません。

14.4. 認証器に関するプライバシー上の考慮事項

14.4.1. アテステーションのプライバシー

アテステーション証明書およびアテステーションキーペアは、ユーザーを追跡したり、同じユーザーのさまざまなオンライン識別情報を関連付けたりするために使用される可能性があります。これは、次を含むいくつかの方法で緩和できます。

WebAuthn 認証器製造者は、バッチ内の認証器が同じアテステーション証明書を共有するようなバッチで認証器を出荷することを選択できます（基本アテステーションまたはバッチアテステーションと呼ばれます）。これにより、秘密鍵が侵害された場合に特定のアテステーション証明書を失効できないというリスクと引き換えに、ユーザーを匿名化できます。認証器製造者は、有意な匿名化を提供するのに十分な大きさのバッチであることを保証しつつ、アテステーション秘密鍵が侵害された場合に影響を受けるユーザー数を制限するため、バッチサイズも最小限に抑えるべきです。

[UAFProtocol] では、十分に大きなグループを生成するため、少なくとも 100,000 台の認証器デバイスが同じアテステーション証明書を共有することを要求しています。これは、適切なバッチサイズに関する指針として利用できます。
WebAuthn 認証器は、匿名化 CA方式で説明されているように、クレデンシャルごとに異なるアテステーションキーペアを動的に生成し（関連する証明書を要求する）能力を持つ場合があります。たとえば、認証器には、マスターアテステーション秘密鍵（および証明書）を搭載でき、クラウドで運用される匿名化 CAと組み合わせることで、クレデンシャルごとのアテステーションキーペアおよびアテステーション証明書を動的に生成できます。

注: この仕様以外のさまざまな場所では、ここで匿名化 CAと呼んでいるものを指すために "Privacy CA" という用語が使用されています。Trusted Computing Group (TCG) も "Privacy CA" という用語を、現在 TCG がアテステーション CA (ACA) [TCG-CMCProfile-AIKCertEnroll] と呼ぶものを指すために使用していたため、この仕様では特定のコンテキストでの混乱を軽減するため、ここでは匿名化 CAという用語を使用しています。

14.4.2. 認証器に保存される個人識別情報のプライバシー

認証器は、この仕様で定義されるもの以外の追加情報をクライアントへ提供してもよいものとします。たとえば、ユーザーがクレデンシャルを選択して認証セレモニーに使用できる豊富な UI をクライアントが提供できるようにする場合です。認証器がそうすることを選択した場合、正常なユーザー検証が実行されない限り、個人を識別する情報を公開すべきではありません。認証器が、同時に登録された複数のユーザーについてユーザー検証をサポートする場合、認証器は、現在検証済みのユーザー以外のユーザーの個人識別情報を公開すべきではありません。したがって、認証器がユーザー検証を実行できない場合、個人識別情報を保存すべきではありません。

この議論の目的上、PublicKeyCredentialUserEntity の id メンバーとして伝達されるユーザーハンドルは個人識別情報とは見なされません。§ 14.6.1 ユーザーハンドルの内容を参照してください。

これらの推奨事項は、認証器に物理的にアクセスできる攻撃者が、認証器に登録されたユーザーに関する個人識別情報を抽出することを防ぐためのものです。

14.5. クライアントに関するプライバシー上の考慮事項

14.5.1. 登録セレモニーのプライバシー

ユーザーが同意なしに識別されることを防ぐため、[[Create]](origin, options, sameOriginWithAncestors) メソッドの実装は、悪意あるWebAuthn リライングパーティが次のケースを区別できるような情報を漏洩しないよう注意する必要があります。ここで「除外される」とは、リライングパーティが excludeCredentials に列挙したクレデンシャルの少なくとも 1 つが認証器にバインドされていることを意味します。

認証器が存在しない。
少なくとも 1 つの認証器が存在し、存在する少なくとも 1 つの認証器が除外されている。

上記のケースを区別できる場合、悪意あるリライングパーティが、どのクレデンシャルが利用可能かを調べることでユーザーを識別できる情報が漏洩します。たとえば、そのような情報漏洩の 1 つは、除外された認証器が利用可能になるとすぐにクライアントが失敗レスポンスを返す場合です。この場合、特に除外された認証器がプラットフォーム認証器である場合、リライングパーティは、セレモニーがタイムアウト前かつユーザーが手動でキャンセルできるほどの時間が経つ前にキャンセルされたことを検出でき、その結果 excludeCredentials パラメーターに列挙されたクレデンシャルの少なくとも 1 つがユーザーに利用可能であると推論できます。

ただし、区別可能なエラーが返される前にユーザーが新しいクレデンシャルの作成に同意した場合、上記は問題になりません。なぜならこの場合、ユーザーは漏洩する情報を共有する意思を確認しているためです。

14.5.2. 認証セレモニーのプライバシー

ユーザーが同意なしに識別されることを防ぐため、[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) メソッドの実装は、悪意あるWebAuthn リライングパーティが次のケースを区別できるような情報を漏洩しないよう注意する必要があります。ここで「指定済み」とは、リライングパーティが allowCredentials にクレデンシャルを列挙していることを意味します。

指定されたクレデンシャルが利用できない。
指定されたクレデンシャルは利用可能だが、ユーザーがそれを使用することに同意しない。

上記のケースを区別できる場合、悪意あるリライングパーティが、どのクレデンシャルが利用可能かを調べることでユーザーを識別できる情報が漏洩します。たとえば、そのような情報漏洩の 1 つは、ユーザーが認証セレモニーを続行することへの同意を拒否するとすぐにクライアントが失敗レスポンスを返す場合です。この場合、リライングパーティは、セレモニーがタイムアウトではなくユーザーによってキャンセルされたことを検出でき、その結果 allowCredentials パラメーターに列挙されたクレデンシャルの少なくとも 1 つがユーザーに利用可能であると推論できます。

14.5.3. オペレーティングシステムアカウント間のプライバシー

プラットフォーム認証器が、マルチユーザーオペレーティングシステムを持つクライアントデバイスに含まれる場合、プラットフォーム認証器とクライアントデバイスは連携して、いずれのプラットフォームクレデンシャルの存在も、そのプラットフォームクレデンシャルを作成したオペレーティングシステムユーザーにのみ明らかになるよう保証すべきです。

14.6. リライングパーティに関するプライバシー上の考慮事項

14.6.1. ユーザーハンドルの内容

§ 14.4.2 認証器に保存される個人識別情報のプライバシーでは、ユーザーハンドルは個人識別情報とは見なされないため、リライングパーティは、電子メールアドレスやユーザー名などの個人識別情報をユーザーハンドルに含めてはなりません。これには個人識別情報のハッシュ値も含まれます。ただし、ハッシュ関数がリライングパーティに非公開のソルト値でソルト付けされている場合を除きます。これは、ハッシュ化しても推測可能な入力値の探索は防げないためです。ユーザーハンドルを 64 個のランダムバイトとし、その値をユーザーのアカウントに保存することが推奨されます。

14.6.2. ユーザー名列挙

登録または認証セレモニーを開始する際、 WebAuthn リライングパーティが登録済みユーザーに関する機密情報を漏洩する危険があります。たとえば、リライングパーティが電子メールアドレスをユーザー名として使用し、攻撃者が "alex.mueller@example.com" について認証セレモニーを開始しようとして、リライングパーティが失敗で応答したものの、その後 "j.doe@example.com" について認証セレモニーを正常に開始した場合、攻撃者は "j.doe@example.com" は登録済みで、"alex.mueller@example.com" は登録されていないと推論できます。したがって、リライングパーティは、"j.doe@example.com" がこのリライングパーティにアカウントを持つという、機密である可能性のある情報を漏洩したことになります。

以下は、このような攻撃による情報漏洩を緩和または防止するためにリライングパーティが実装してもよい、非規範的かつ網羅的ではない対策の一覧です。

登録セレモニーの場合:
- リライングパーティがユーザーを識別するためにリライングパーティ固有のユーザー名を使用する場合:
  - 登録セレモニーを開始する際、構文的に有効な電子メールアドレスであるユーザー名の登録を禁止します。
    
    注: この提案の動機は、この場合、ユーザーがすでに登録されているユーザー名を登録しようとすると、リライングパーティは登録セレモニーを失敗させる以外に選択肢がない可能性が高く、そのため情報漏洩を避けられない場合があるためです。電子メールアドレスをユーザー名として禁止することで、このリライングパーティと他のリライングパーティでユーザーが同じユーザー名を持つ可能性が低くなるため、漏洩の影響を軽減できます。
- リライングパーティが電子メールアドレスを使用してユーザーを識別する場合:
  - 登録セレモニーを開始する際、電子メールアドレスが提供された後にユーザーとのやり取りを中断し、予測不可能なワンタイムコードと、それを使用してセレモニーを続行する方法の説明を含むメッセージをこのアドレスに送信します。送信された電子メールの内容や、この電子メールアドレスがすでに登録されているかどうかにかかわらず、Web インターフェイスでは同じメッセージをユーザーに表示します。
    
    注: この提案は、国民識別番号やクレジットカード番号など、他の外部的に意味のある識別子にも同様に適用できます — たとえば通常の郵便住所のような同様の帯域外連絡情報を提供する場合です。
認証セレモニーの場合:
- 認証セレモニーを開始する際、提供されたユーザー名に一致するアカウントが存在しない場合、もっともらしい架空の値を設定した、構文的に有効な PublicKeyCredentialRequestOptions オブジェクトを使用して navigator.credentials.get() を呼び出すことでセレモニーを続行します。
  
  この方式は allowCredentials を介した情報漏洩を緩和するためにも使用できます。§ 13.4.7 保護されていないアカウントの検出および§ 14.6.3 クレデンシャル ID によるプライバシー漏洩を参照してください。
  
  注: ユーザー名はさまざまなリライングパーティ固有の方法で「提供」される場合があります。ログインフォーム、セッション Cookie などです。
  
  注: 返される架空の値が実際の値と明確に異なる場合、巧妙な攻撃者はそれらを識別でき、その結果、実際のアカウントの存在を確認できる可能性があります。明確に異なる値の例には、すべてのユーザー名入力に対して値が常に同じである場合や、同じユーザー名入力で繰り返し試行した際に異なる場合があります。したがって、allowCredentials メンバーには、たとえばユーザー名から決定論的に導出した疑似ランダム値を設定できます。
- 認証器からの AuthenticatorAssertionResponse レスポンスを検証する際、署名が無効であるために検証が失敗したのか、そのようなユーザーまたはクレデンシャルが登録されていないために失敗したのかを区別できないようにします。
- 複数ステップの認証セレモニーを実行します。たとえば、WebAuthn セレモニーを後続ステップとして開始する前に、ユーザー名とパスワード、またはセッション Cookie の提供から開始します。これにより、ユーザー名列挙の問題を WebAuthn ステップから先行する認証ステップへ移し、そこで解決しやすくなる可能性があります。

14.6.3. クレデンシャル ID によるプライバシー漏洩

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

このプライバシー上の考慮事項は、リライングパーティで、認証セレモニーを非-空の allowCredentials 引数とともに最初の認証ステップとしてサポートするものに適用されます。たとえば、最初の認証ステップとしてサーバー側クレデンシャルによる認証を使用する場合です。

この場合、allowCredentials 引数は、認証されていない呼び出し元にユーザーのクレデンシャル IDを公開するため、個人識別情報を漏洩する危険があります。クレデンシャル IDはリライングパーティ間で相関できないよう設計されていますが、クレデンシャル IDの長さは、どの種類の認証器が作成したかの手掛かりになる可能性があります。ユーザーは複数のリライングパーティで同じユーザー名と一連の認証器を使用する可能性が高いため、allowCredentials 内のクレデンシャル IDの数とその長さは、ユーザーの匿名性を解除するためのグローバルな相関ハンドルとして機能する可能性があります。ユーザーのクレデンシャル IDを知ることで、ユーザーの認証器の 1 つに一時的に物理アクセスできるだけでも、ユーザーの識別情報に関する推測を確認できるようになります。

このような情報漏洩を防ぐため、リライングパーティは、たとえば次を行えます。

WebAuthn 認証セレモニーを開始してユーザーのクレデンシャル IDを公開する前に、ユーザー名とパスワードによる認証やセッション Cookie による認証など、別個の認証ステップを実行します。
クライアント側で検出可能なクレデンシャルを使用し、 allowCredentials 引数を不要にします。

上記の防止策が利用できない場合、すなわち、ユーザー名だけを与えられた状態で allowCredentials を公開する必要がある場合、リライングパーティは、§ 14.6.2 ユーザー名列挙で説明されている、架空のクレデンシャル IDを返すのと同じ手法を使用して、プライバシー漏洩を緩和できます。

15. アクセシビリティに関する考慮事項

ユーザー検証対応の認証器は、ローミングであるかプラットフォームであるかにかかわらず、複数のユーザー検証方式をユーザーに提供すべきです。たとえば、指紋検出と PIN 入力の両方です。これにより、選択したユーザー検証手段が何らかの理由で機能しない場合、他の手段へフォールバックできます。ローミング認証器の場合、認証器とプラットフォームが連携して、PIN 入力のようなユーザー検証方式を提供する場合があることに注意してください [FIDO-CTAP]。

リライングパーティは、登録時に、ユーザーが将来の認可ジェスチャーを正しく完了できるようにするための手掛かりを提供すべきです。これには、認証器に名前を付けること、デバイスに関連付ける画像を選択すること、または自由形式のテキストによる指示を入力すること（たとえば自分自身へのリマインダー）が含まれる場合があります。

タイミングに依存するセレモニー、たとえば登録セレモニー（timeout を参照）または認証セレモニー（timeout を参照）は、 [WCAG21] のガイドライン 2.2 十分な時間に従うべきです。クライアントプラットフォームが、リライングパーティによって指定されたタイムアウトが、後者の [WCAG21] ガイドラインに適切に準拠していないと判断した場合、クライアントプラットフォームは、それに応じてタイムアウトを調整してもよいものとします。

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。

全体的な登録および認証フロー図（図 1および図 2）を作成した Adam Powers に感謝します。

また、 Anthony Nadalin, John Fontana, および Richard Barnes の Web Authentication Working Group 共同議長としての貢献に感謝します。

さらに、 Wendy Seltzer, Samuel Weiler, および Harry Halpin の W3C Team Contacts としての貢献に感謝します。

概要

この文書のステータス

1. はじめに

1.1. 仕様ロードマップ

1.2. ユースケース

1.2.1. 登録

1.2.2. 認証

1.2.3. 新しいデバイスの登録

1.2.4. その他のユースケースおよび構成

1.3. API 使用シナリオの例

1.3.1. 登録

1.3.2. ユーザー検証プラットフォーム 認証器を特に使用する登録

1.3.3. 認証

1.3.4. 認証操作の中止

1.3.5. 廃止

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

2. 適合性

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

2.1.1. DOMString 型としての列挙型

2.2. 認証器

2.2.1. FIDO U2F との後方互換性

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

2.4. すべての適合クラス

3. 依存関係

4. 用語

5. Web Authentication API

5.1. PublicKeyCredential インターフェイス

5.1.1. CredentialCreationOptions 辞書 拡張

5.1.2. CredentialRequestOptions 辞書 拡張

5.1.3. 新しいクレデンシャルの作成 - PublicKeyCredential の [[Create]](origin, options, sameOriginWithAncestors) メソッド

5.1.4. 既存のクレデンシャルを使用したアサーションの作成 - PublicKeyCredential の [[Get]](options) メソッド

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

5.1.5. 既存のクレデンシャルの保存 - PublicKeyCredential の [[Store]](credential, sameOriginWithAncestors) メソッド

5.1.6. 既存のクレデンシャルへのサイレントアクセスの防止 - PublicKeyCredential の [[preventSilentAccess]](credential, sameOriginWithAncestors) メソッド

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

5.2. 認証器レスポンス (インターフェイス AuthenticatorResponse)

5.2.1. 公開鍵クレデンシャルに関する情報 (インターフェイス AuthenticatorAttestationResponse)

5.2.1.1. クレデンシャルデータへの容易なアクセス

5.2.2. Web Authentication アサーション (インターフェイス AuthenticatorAssertionResponse)

5.3. クレデンシャル生成用パラメーター (辞書 PublicKeyCredentialParameters)

5.4. クレデンシャル作成用オプション (辞書 PublicKeyCredentialCreationOptions)

5.4.1. 公開鍵エンティティの説明 (辞書 PublicKeyCredentialEntity)

5.4.2. クレデンシャル生成用リライングパーティパラメーター (辞書 PublicKeyCredentialRpEntity)

5.4.3. クレデンシャル生成用ユーザーアカウントパラメーター (辞書 PublicKeyCredentialUserEntity)

5.4.4. 認証器選択基準 (辞書 AuthenticatorSelectionCriteria)

5.4.5. 認証器アタッチメント列挙型 (enum AuthenticatorAttachment)

5.4.6. 常駐キー要件列挙型 (enum ResidentKeyRequirement)

5.4.7. アテステーション伝達設定列挙型 (enum AttestationConveyancePreference)

5.5. アサーション生成用オプション (辞書 PublicKeyCredentialRequestOptions)

5.6. AbortSignal による操作の中止

5.7. WebAuthn 拡張の入力および出力

5.7.1. 認証拡張クライアント入力 (辞書 AuthenticationExtensionsClientInputs)

5.7.2. 認証拡張クライアント出力 (辞書 AuthenticationExtensionsClientOutputs)

5.7.3. 認証拡張認証器入力 (CDDL 型 AuthenticationExtensionsAuthenticatorInputs)

5.7.4. 認証拡張認証器出力 (CDDL 型 AuthenticationExtensionsAuthenticatorOutputs)

5.8. 補助データ構造

5.8.1. WebAuthn 署名で使用されるクライアントデータ (辞書 CollectedClientData)

5.8.1.1. シリアル化

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

5.8.1.3. 将来の開発

5.8.2. クレデンシャル型列挙型 (enum PublicKeyCredentialType)

5.8.3. クレデンシャル記述子 (辞書 PublicKeyCredentialDescriptor)

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

5.8.5. 暗号アルゴリズム識別子 (typedef COSEAlgorithmIdentifier)

5.8.6. ユーザー検証要件列挙型 (enum UserVerificationRequirement)

5.9. Permissions Policy との統合

5.10. iframe 要素内での Web Authentication の使用

6. WebAuthn 認証器モデル

6.1. 認証器データ

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

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

6.2. 認証器の分類

6.2.1. 認証器アタッチメント 方式

6.2.2. クレデンシャル保存方式

6.2.3. 認証要素能力

6.3. 認証器操作

6.3.1. クレデンシャル ID によるクレデンシャルソース検索 アルゴリズム

6.3.2. authenticatorMakeCredential 操作

6.3.3. authenticatorGetAssertion 操作

6.3.4. authenticatorCancel 操作

1.3.2. ユーザー検証プラットフォーム認証器を特に使用する登録

5.1. `PublicKeyCredential` インターフェイス

5.1.1. `CredentialCreationOptions` 辞書拡張

5.1.2. `CredentialRequestOptions` 辞書拡張

5.1.3. 新しいクレデンシャルの作成 - PublicKeyCredential の `[[Create]](origin, options, sameOriginWithAncestors)` メソッド

5.1.4. 既存のクレデンシャルを使用したアサーションの作成 - PublicKeyCredential の `[[Get]](options)` メソッド

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

5.1.5. 既存のクレデンシャルの保存 - PublicKeyCredential の `[[Store]](credential, sameOriginWithAncestors)` メソッド

5.1.6. 既存のクレデンシャルへのサイレントアクセスの防止 - PublicKeyCredential の `[[preventSilentAccess]](credential, sameOriginWithAncestors)` メソッド

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

5.2. 認証器レスポンス (インターフェイス `AuthenticatorResponse`)

5.2.1. 公開鍵クレデンシャルに関する情報 (インターフェイス `AuthenticatorAttestationResponse`)

5.2.2. Web Authentication アサーション (インターフェイス `AuthenticatorAssertionResponse`)

5.3. クレデンシャル生成用パラメーター (辞書 `PublicKeyCredentialParameters`)

5.4. クレデンシャル作成用オプション (辞書 `PublicKeyCredentialCreationOptions`)

5.4.1. 公開鍵エンティティの説明 (辞書 `PublicKeyCredentialEntity`)

5.4.2. クレデンシャル生成用リライングパーティパラメーター (辞書 `PublicKeyCredentialRpEntity`)

5.4.3. クレデンシャル生成用ユーザーアカウントパラメーター (辞書 `PublicKeyCredentialUserEntity`)

5.4.4. 認証器選択基準 (辞書 `AuthenticatorSelectionCriteria`)

5.4.5. 認証器アタッチメント列挙型 (enum `AuthenticatorAttachment`)

5.4.6. 常駐キー要件列挙型 (enum `ResidentKeyRequirement`)

5.4.7. アテステーション伝達設定列挙型 (enum `AttestationConveyancePreference`)

5.5. アサーション生成用オプション (辞書 `PublicKeyCredentialRequestOptions`)

5.6. `AbortSignal` による操作の中止

5.7.1. 認証拡張クライアント入力 (辞書 `AuthenticationExtensionsClientInputs`)

5.7.2. 認証拡張クライアント出力 (辞書 `AuthenticationExtensionsClientOutputs`)

5.7.3. 認証拡張認証器入力 (CDDL 型 `AuthenticationExtensionsAuthenticatorInputs`)

5.7.4. 認証拡張認証器出力 (CDDL 型 `AuthenticationExtensionsAuthenticatorOutputs`)

5.8.1. WebAuthn 署名で使用されるクライアントデータ (辞書 `CollectedClientData`)

5.8.2. クレデンシャル型列挙型 (enum `PublicKeyCredentialType`)

5.8.3. クレデンシャル記述子 (辞書 `PublicKeyCredentialDescriptor`)

5.8.4. 認証器トランスポート列挙型 (enum `AuthenticatorTransport`)

5.8.5. 暗号アルゴリズム識別子 (typedef `COSEAlgorithmIdentifier`)

5.8.6. ユーザー検証要件列挙型 (enum `UserVerificationRequirement`)

5.10. `iframe` 要素内での Web Authentication の使用

6.2.1. 認証器アタッチメント方式

6.3.1. クレデンシャル ID によるクレデンシャルソース検索アルゴリズム

6.5.1.1. COSE_Key 形式でエンコードされた `credentialPublicKey` 値の例

6.5.5. Packed アテステーション、FIDO U2F アテステーション、およびアサーション署名の署名形式

8.2.1. Packed アテステーションステートメント証明書要件

9.5. 認証器拡張処理