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.5 依存パーティに関するセキュリティ上の考慮事項および§ 14.6 依存パーティに関するプライバシー上の考慮事項を読み、どの課題が自身のアプリケーションおよびユーザーに当てはまるかを検討するべきである。
ユーザーエージェント開発者
OS プラットフォーム開発者。プラットフォーム固有の認証器 API、プラットフォームWebAuthn クライアントのインスタンス化などに関する OS プラットフォーム API の設計および実装を担当する者。
- 上記 2 つの対象者は、§ 5 Web Authentication APIを非常に注意深く読み、拡張をサポートする場合は§ 9 WebAuthn 拡張も読むべきである。また、 § 14.5 クライアントに関するプライバシー上の考慮事項も注意深く読むべきである。
認証器開発者。これらの読者は、§ 6 WebAuthn 認証器モデル、 § 8 定義済みアテステーションステートメント形式、§ 9 WebAuthn 拡張、および§ 10 定義済み拡張に特に注意を払うことになる。また、§ 13.3 認証器に関するセキュリティ上の考慮事項および§ 14.4 認証器に関するプライバシー上の考慮事項も注意深く読むべきである。

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

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

1.2. ユースケース

以下のユースケースシナリオは、2 つの一般的な配備形態にわたる、非常に異なる 2 種類の認証器およびクレデンシャルの使用を示すとともに、さらなるシナリオの概要も示す。サンプルコードを含む追加のシナリオは、後の§ 1.3 API 使用シナリオ例に示されている。これらの例は説明のみを目的とするものであり、機能の利用可能性はクライアントと認証器の実装によって異なる場合がある。

1.2.1. マルチデバイスクレデンシャルを使用する消費者

このユースケースは、消費者向けの依存パーティが、ユーザーのデバイスに組み込まれた認証器を利用して、マルチデバイスクレデンシャル（一般に同期されたパスキーと呼ばれる）を使用したフィッシング耐性のあるサインインを提供する方法を示す。

1.2.1.1. 登録

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

1.2.1.2. 認証

ノート PC またはデスクトップ上で:
- ユーザーはブラウザーで example.com に移動し、サインインを開始する。
- マルチデバイスクレデンシャル（一般に同期されたパスキーと呼ばれる）がデバイス上で利用可能な場合:
  - ブラウザーまたはオペレーティングシステムは、事前に設定された認可ジェスチャー（PIN、生体認証など）をユーザーに求め、ユーザーはこれを提供する。
  - Web ページは、選択されたユーザーがサインインしたことを表示し、サインイン済みページへ移動する。
- 同期されたパスキーがデバイス上で利用できない場合:
  - ブラウザーまたはオペレーティングシステムは、スマートフォンやセキュリティキーなどの外部認証器をユーザーに求める。
  - ユーザーは、以前にリンクしたスマートフォンを選択する。
次に、スマートフォン上で:
- ユーザーには、「example.com にサインイン」という独立したプロンプトまたは通知が表示される。
- ユーザーはこのプロンプト / 通知を選択する。
- ユーザーには、example.com の ID の一覧が表示される。例: 「Mohamed としてサインイン / 张三としてサインイン」。
- ユーザーは ID を選択し、認可ジェスチャー（PIN、生体認証など）を求められ、それを提供する。
ここで、ノート PC に戻る:
- Web ページは、選択されたユーザーがサインインしたことを表示し、サインイン済みページへ移動する。

1.2.2. シングルデバイスクレデンシャルを使用する従業員

このユースケースは、従業員向けの依存パーティが、ローミング認証器（例: USB セキュリティキー）とプラットフォーム認証器（例: 組み込み指紋センサー）の組み合わせを利用して、ユーザーが次を持てるようにする方法を示す。

ユーザーにとって新しいクライアントデバイス（例: ノート PC、デスクトップ）上、またはプラットフォーム認証器を備えていないそのようなクライアントデバイス上で認証するために使用する「主要な」ローミング認証器、および
プラットフォーム認証器を備えるクライアントデバイス上で、少ない手間で強力に再認証する手段、または
シングルデバイスクレデンシャル（一般にデバイスバウンドパスキーと呼ばれる）をサポートしないパスキープラットフォーム認証器を備えるクライアントデバイス上で、強力に再認証する手段。

1.2.2.1. 登録

この例では、ユーザーの雇用主が、デバイスバウンドパスキーで事前設定されたセキュリティキーを郵送する。

一時的な PIN は、帯域外（例: RCS メッセージ経由）でユーザーに送信されている。

1.2.2.2. 認証

ノート PC またはデスクトップ上で:
- ユーザーはブラウザーで corp.example.com に移動し、サインインを開始する。
- ブラウザーまたはオペレーティングシステムは、ユーザーにセキュリティキーを求める。
- ユーザーは USB セキュリティキーを接続する。
- USB セキュリティキーが点滅して、ユーザーがそのボタンを押すべきことを示し、ユーザーはそれを行う。
- ブラウザーまたはオペレーティングシステムは、ユーザーに PIN の入力を求める。
- ユーザーは提供された一時 PIN を入力して続行する。
- ブラウザーまたはオペレーティングシステムは、PIN を変更する必要があることをユーザーに通知し、新しい PIN を求める。
- ユーザーは新しい PIN を入力して続行する。
- ブラウザーまたはオペレーティングシステムは認証フローを再開し、ユーザーに PIN の入力を求める。
- ユーザーは新しい PIN を入力し、セキュリティキーに触れる。
- Web ページは、選択されたユーザーがサインインしたことを表示し、サインイン済みページへ移動する。

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

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

ユーザーがノート PC で example.com に移動し、スマートフォン上でクレデンシャルを作成および登録するフローへ案内される。
ユーザーが、USB および/または NFC 接続オプションを備えたセキュリティキーなどの独立したローミング認証器を入手し、ノート PC またはスマートフォンのブラウザーで 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",
  },

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

  authenticatorSelection: {
    // 可能であれば UV を使用する。これは既定値でもある。
    userVerification: "preferred"
  },

  timeout: 300000,  // 5 分
  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: 300000,  // 5 分
  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: 300000,  // 5 分
  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.name === "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で説明されているとおりに動作しなければならない（MUST）。適合ユーザーエージェントは、最終結果がこの仕様のアルゴリズムによって得られる結果と区別できない限り、この仕様で示されるアルゴリズムを任意の方法で実装してもよい（MAY）。

適合ユーザーエージェントは、「Web IDL」仕様で説明されているように、この仕様の IDL 断片の適合実装でもなければならない（MUST）。 [WebIDL]

2.1.1. DOMString 型としての列挙

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

2.2. 認証器

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

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

2.2.1. FIDO U2F との後方互換性

認証器のうち、 § 8.6 FIDO U2F アテステーションステートメント形式のみをサポートするものには、ユーザーハンドルを保存する仕組みがないため、返されるuserHandle は常に null となる。

2.3. WebAuthn 依存パーティ

WebAuthn 依存パーティは、この仕様によって提供されるすべてのセキュリティ上の利点を得るために、 § 7 WebAuthn 依存パーティの操作で説明されているとおりに動作しなければならない（MUST）。これについてのさらなる議論は、 § 13.5.1 WebAuthn 依存パーティに対するセキュリティ上の利点を参照すること。

2.4. すべての適合クラス

上記の適合クラスのメンバーが実行するすべてのCBORエンコーディングは、 CTAP2 正規 CBOR エンコーディング形式を使用して行わなければならない（MUST）。上記の適合クラスのすべてのデコーダーは、CTAP2 正規 CBOR エンコーディング形式で有効にエンコードされていない CBOR を拒否するべきであり（SHOULD）、重複するマップキーを持つメッセージも拒否するべきである（SHOULD）。

3. 依存関係

この仕様は、以下および参照によって定義される用語に列挙されている、いくつかの基礎となる他の仕様に依存する。

Base64url エンコーディング: Base64url エンコーディングという用語は、[RFC4648]の第 5 節で定義された URL およびファイル名に安全な文字集合を使用する base64 エンコーディングを指し、末尾のすべての '=' 文字を省略し（第 3.2 節で許可されているとおり）、改行、空白、またはその他の追加文字を一切含まない。
CBOR: アテステーションステートメントおよび拡張を含む、この仕様の多くの構造は、 Compact Binary Object Representation（CBOR）[RFC8949]の CTAP2 正規 CBOR エンコーディング形式を使用してエンコードされる。これは[FIDO-CTAP]で定義されている。
CDDL: この仕様は、CBOR Data Definition Language（CDDL）[RFC8610]を使用して、すべてのCBORエンコードされたデータの構文を記述する。
COSE: CBOR Object Signing and Encryption (COSE) [RFC9052] [RFC9053]。 IANA COSE Algorithms レジストリ[IANA-COSE-ALGS-REG] も使用される。このレジストリはもともと[RFC8152]によって確立され、これらの仕様によって更新されたものである。
Credential Management: この文書で説明される API は、[CREDENTIAL-MANAGEMENT-1]で定義されるCredential 概念の拡張である。
DOM: DOMException およびこの仕様で使用される DOMException の値は、[DOM4]で定義される。
ECMAScript: %ArrayBuffer%は、[ECMAScript]で定義される。
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"、 "NOT RECOMMENDED"、"MAY"、および "OPTIONAL" は、ここに示すように、すべて大文字で記述されている場合に限り、BCP 14 [RFC2119] [RFC8174]で説明されているとおりに解釈されるものとする。

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 認証器は、ローミング認証器、クライアントデバイスに統合された専用ハードウェアサブシステム、またはクライアントもしくはクライアントデバイスのソフトウェアコンポーネントであり得る。WebAuthn 認証器は、必ずしもローカルコンテキスト内での動作に限定されず、クライアント側ハードウェアの外部にあるサーバーでクレデンシャル鍵ペアを生成または保存できる。

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

認可ジェスチャー

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

バックアップ済み

公開鍵クレデンシャルソースは、その生成認証器以外の認証器にも存在できるよう、何らかの方法でバックアップされる場合がある。バックアップは、ピアツーピア同期、クラウド同期、ローカルネットワーク同期、手動インポート/エクスポートなどの仕組みによって行うことができる。§ 6.1.3 クレデンシャルのバックアップ状態も参照すること。

バックアップ適格性

バックアップ適格

公開鍵クレデンシャルソースの生成認証器は、その公開鍵クレデンシャルソースがバックアップを許可されるかどうかを作成時に決定する。バックアップ適格性は、現在のバックアップ状態とともに、認証器データのフラグで通知される。バックアップ適格性はクレデンシャルプロパティであり、特定の公開鍵クレデンシャルソースについて恒久的である。バックアップ適格な公開鍵クレデンシャルソースはマルチデバイスクレデンシャルと呼ばれ、一方、バックアップ適格でないものはシングルデバイスクレデンシャルと呼ばれる。§ 6.1.3 クレデンシャルのバックアップ状態も参照すること。

バックアップ状態

現在の管理認証器によって決定される、マルチデバイスクレデンシャルの現在のバックアップ状態。バックアップ状態は認証器データのフラグで通知され、時間の経過とともに変化する場合がある。バックアップ適格性および§ 6.1.3 クレデンシャルのバックアップ状態も参照すること。

生体認証器

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

生体認識

生物学的および行動的特徴に基づく個人の自動認識[ISOBiometricVocabulary]。

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

"認証器がクレデンシャルを含む"

"認証器上で作成されたクレデンシャル"

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

これは、「管理認証器がバインドされたクレデンシャルを含む」、または「バインドされたクレデンシャルが、その管理認証器上で作成された」とも表現できる。ただし、サーバー側クレデンシャルは、認証器内部の永続メモリに物理的に保存されていない場合があるため、「バインドされる」が主要な用語であることに注意すること。 § 6.2.2 クレデンシャル保存モダリティを参照すること。

セレモニー

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

クライアント

WebAuthn クライアント

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

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

クライアントデバイス

WebAuthn クライアントデバイス

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

WebAuthn クライアントデバイスとクライアントの違いは次のとおりである。

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

クライアントデバイスとクライアントは、ともにクライアントプラットフォームを構成する。

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

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

クライアント側

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

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

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

発見可能なクレデンシャル

パスキー

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

[非推奨] 常駐キー

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

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

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

次も参照すること: クライアント側クレデンシャル保存モダリティおよび発見不能なクレデンシャル。

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

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

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

クレデンシャル ID

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

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

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

注: [FIDO-UAF-AUTHNR-CMDS]には、「セキュリティガイドライン」の項に暗号化技法に関するガイダンスが含まれている。

依存パーティは、この 2 つのクレデンシャル ID形式を区別する必要はない。

クレデンシャル鍵ペア

クレデンシャル秘密鍵

クレデンシャル公開鍵

ユーザー公開鍵

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

クレデンシャル公開鍵とは、クレデンシャル鍵ペアの公開鍵部分である。クレデンシャル公開鍵は、登録セレモニー中に依存パーティへ返される。

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

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

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

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

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

クレデンシャルレコード

§ 7 WebAuthn 依存パーティの操作で定義されるアルゴリズムを実装するために、依存パーティは、登録済みの公開鍵クレデンシャルソースのいくつかのプロパティを保存しなければならない（MUST）。クレデンシャルレコード構造体は、ユーザーアカウントに保存されるこれらのプロパティを抽象化したものである。クレデンシャルレコードは登録セレモニー中に作成され、その後の認証セレモニーで使用される。依存パーティは、必要に応じて、またはユーザーから要求された場合にクレデンシャルレコードを削除してもよい（MAY）。

§ 7.1 新しいクレデンシャルの登録および§ 7.2 認証アサーションの検証のすべての手順を定義どおりに実装するため、次の項目が推奨される（RECOMMENDED）。

type

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

id

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

publicKey

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

signCount

公開鍵クレデンシャルソースを使用する任意のセレモニーの認証器データにおける署名カウンターの最新値。

transports

公開鍵クレデンシャルソースが登録されたときにgetTransports() から返された値。

注: getTransports() から返された値から項目を変更または削除すると、ユーザーエクスペリエンスに悪影響を及ぼしたり、対応するクレデンシャルを使用できなくなったりする可能性がある。

uvInitialized

この公開鍵クレデンシャルソースからのいずれかのクレデンシャルについて、 UV フラグが設定されたことがあるかどうかを示す Boolean 値。

これがtrueの場合、依存パーティは、認証セレモニーにおいて、UV フラグを認証要素と見なしてもよい（MAY）。たとえば、依存パーティは、uvInitializedが true であり、UV フラグが設定されている場合、ユーザー検証が要求されていなかった場合でも、パスワード入力を省略することができる。

これがfalseの場合、これがtrueへ更新される認証セレモニーを含め、 UV フラグを認証要素として信頼してはならない（MUST NOT）。これは、公開鍵クレデンシャルソースが初めてUV フラグを 1 に設定する時点では、依存パーティと認証器のユーザー検証との間にまだ信頼関係が確立されていないためである。したがって、uvInitializedを falseからtrueへ更新するには、 WebAuthn のユーザー検証と同等の追加の認証要素による認可を要求するべきである（SHOULD）。

backupEligible

公開鍵クレデンシャルソースが作成されたときのBE フラグの値。

backupState

公開鍵クレデンシャルソースを使用する任意のセレモニーの認証器データにおけるBS フラグの最新値。

次の項目は任意である（OPTIONAL）。

attestationObject: 公開鍵クレデンシャルソースが登録されたときのattestationObject 属性の値。これを保存することで、依存パーティは後でクレデンシャルのアテステーションステートメントを参照できる。
attestationClientDataJSON: 公開鍵クレデンシャルソースが登録されたときのclientDataJSON 属性の値。これを上記のattestationObject 項目と組み合わせて保存することで、依存パーティは後でアテステーション署名を再検証できる。
rpId: クレデンシャル登録中のcreate() 操作で指定された rp.id パラメーターの値。この値は、クレデンシャルをどこで使用できるかを決定する、そのクレデンシャルの中核的なプロパティである。登録時にこの値を保存しておくと、将来、その使用状況を監査したり、それを使用した認証の問題をトラブルシューティングしたり、後で関連オリジンを介して異なるドメイン間で使用したりする際に役立つ。

WebAuthn 拡張は、拡張を処理するために必要な追加の項目を定義してもよい（MAY）。依存パーティは、必要に応じて任意の追加の項目を含めてもよく（MAY）、その実装に不要な項目を省略してもよい（MAY）。

クレデンシャルレコードのクレデンシャル記述子は、次の内容を持つPublicKeyCredentialDescriptor 値である。

type: クレデンシャルレコードのtype。
id: クレデンシャルレコードのid。
transports: クレデンシャルレコードのtransports。

生成認証器

生成認証器とは、特定の公開鍵クレデンシャルソースの作成をもたらしたauthenticatorMakeCredential操作に関与した認証器である。生成認証器は、シングルデバイスクレデンシャルについては管理認証器と同一である。マルチデバイスクレデンシャルについては、生成認証器は、特定の認証操作に参加している現在の管理認証器と同一である場合も、異なる場合もある。

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

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

発見不能なクレデンシャル

これは、クライアント側で発見可能ではないため、navigator.credentials.get() を呼び出す際に、そのクレデンシャル IDをallowCredentials で提供しなければならないクレデンシャルである。サーバー側クレデンシャルも参照すること。

登録可能オリジンラベル

ドメインの登録可能ドメインの最初のドメインラベル、または登録可能ドメインが null の場合は null。たとえば、co.ukおよびdeの両方が公開サフィックスである場合、 example.co.ukとwww.example.deの両方の登録可能オリジンラベルはexampleである。

公開鍵クレデンシャル

一般に、クレデンシャルとは、あるエンティティが別のエンティティに対して前者を後者へ認証するために提示するデータである [RFC4949]。公開鍵クレデンシャルという用語は、次のいずれかを指す: 公開鍵クレデンシャルソース、公開鍵クレデンシャルソースに対応する、場合によってはアテステーション済みのクレデンシャル公開鍵、または認証アサーション。どれを指すかは、一般に文脈によって決まる。

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

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

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

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

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

type: その値はPublicKeyCredentialType型であり、既定値はpublic-keyである。
id: クレデンシャル ID。
privateKey: クレデンシャル秘密鍵。
rpId: この公開鍵クレデンシャルソースがスコープ設定される依存パーティの依存パーティ識別子。これは、create() 操作の rp.id パラメーターによって決定される。
userHandle: この公開鍵クレデンシャルソースが作成されたときに関連付けられたユーザーハンドル。この項目は null 許容であるが、発見可能なクレデンシャルではユーザーハンドルを常に設定しなければならない（MUST）。
otherUI: 認証器がその UI に情報を提供するために使用する任意（OPTIONAL）のその他の情報。たとえば、これにはユーザーの displayName が含まれる場合がある。 otherUIは可変項目であり、 otherUIの更新を妨げるような方法で公開鍵クレデンシャルソースにバインドするべきではない（SHOULD NOT）。

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

レート制限

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

登録

登録セレモニー

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

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

依存パーティ

WebAuthn 依存パーティ

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

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

注: 依存パーティという用語は他の文脈（たとえば X.509 や OAuth）でもよく使用されるが、ある文脈で依存パーティとして動作するエンティティが、他の文脈でも必ず依存パーティであるとは限らない。この仕様では、 WebAuthn 依存パーティという用語はしばしば単に依存パーティと短縮され、WebAuthn の文脈における依存パーティを明示的に指す。具体的な実体化では、 WebAuthn の文脈が、たとえば OAuth に基づく、より広範な全体コンテキストに埋め込まれる場合があることに注意すること。

依存パーティ識別子

RP ID

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

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

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

RP IDは、オリジンの有効ドメインと等しいか、オリジンの有効ドメインの登録可能ドメインサフィックスでなければならない。
次のいずれかが真でなければならない。
- オリジンのスキームがhttpsである。
- オリジンのホストがlocalhost であり、そのスキームがhttpである。
オリジンのポートには制限がない。

たとえば、オリジンが https://login.example.com:1337である依存パーティの場合、次のRP IDは有効である: login.example.com（既定値）およびexample.com。ただし、 m.login.example.comおよびcomは無効である。有効なオリジンの別の例として、オリジンが localhostであることにより、http://localhost:8000がある。

これは、広範に配備されているアンビエントクレデンシャル（たとえば、 Cookie、[RFC6265]）の動作と一致させるためである。これは、 document.domainの setter が提供するものよりも「同一オリジン」制約を大きく緩和するものであることに注意すること。

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

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

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

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

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

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

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

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

次も参照すること: サーバー側クレデンシャル保存モダリティおよび発見不能なクレデンシャル。

ユーザー存在のテスト

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

ユーザーアカウント

この仕様の文脈では、ユーザーアカウントとは、依存パーティによって維持および認可される、クレデンシャルの集合[CREDENTIAL-MANAGEMENT-1] から依存パーティのリソースの（部分）集合への対応付けを指す。依存パーティは、クレデンシャルのユーザーハンドルにユーザーアカウント固有の値を割り当て、そのクレデンシャルのクレデンシャルレコードをユーザーアカウントに保存することにより、特定の公開鍵クレデンシャルをユーザーアカウントへ対応付ける。この対応付け、クレデンシャルの集合、およびそれらの認可は、時間の経過とともに変化する場合がある。特定のユーザーアカウントには、 1 人以上の自然人（「ユーザー」とも呼ばれる）がアクセスする場合があり、 1 人の自然人が 1 つ以上のユーザーアカウントへアクセスする場合もある。これはユーザーおよび依存パーティの行動によって異なる。

ユーザーの同意

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

ユーザーハンドル

ユーザーハンドルとは、ユーザーアカウントの識別子であり、依存パーティによって、登録中に user.id として指定される。発見可能なクレデンシャルはこの識別子を保存し、空のリストである allowCredentials 引数で開始された認証セレモニーでは、 response.userHandle としてこれを返さなければならない（MUST）。

ユーザーハンドルの主な用途は、そのような認証セレモニーにおいてユーザーアカウントを識別することであるが、クレデンシャル IDを代わりに使用することもできる。主な違いは、クレデンシャル IDは認証器によって選択され、各クレデンシャルごとに一意であるのに対し、ユーザーハンドルは依存パーティによって選択され、同じユーザーアカウントに登録されたすべてのクレデンシャルについて同じであることが望ましい点である。

認証器は、 RP IDとユーザーハンドルのペアを公開鍵クレデンシャルソースに対応付ける。その結果、認証器は、依存パーティごと、ユーザーハンドルごとに、最大 1 つの発見可能なクレデンシャルを保存する。したがって、ユーザーハンドルの副次的な用途は、登録セレモニー中に、既存の発見可能なクレデンシャルを新しいものに置き換えるべき時点を認証器が判断できるようにすることである。

ユーザーハンドルは最大サイズ 64 バイトの不透明なバイトシーケンスであり、ユーザーに表示することを意図していない。個人識別情報を含んではならない（MUST NOT）。§ 14.6.1 ユーザーハンドルの内容を参照すること。

ユーザー存在

ユーザー存在テストが正常に完了すると、ユーザーは「存在する」という。

ユーザー検証

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

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

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

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

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

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

ユーザー検証済み

ユーザー検証プロセスが正常に完了すると、ユーザーは「検証済み」であるという。

5. Web Authentication API

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

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

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

上記のスクリプトインターフェースに加えて、認証器は管理用のユーザーインターフェースを実装してもよい（MAY）（またはそれを実装するクライアントソフトウェアが付属していてもよい）。このようなインターフェースは、たとえば、認証器をクリーンな状態にリセットしたり、認証器の現在の状態を確認したりするために使用してもよい（MAY）。言い換えると、このようなインターフェースは、履歴、保存されたパスワード、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 インターフェースは、Credential [CREDENTIAL-MANAGEMENT-1]から継承し、新しいクレデンシャルが作成されたとき、または新しいアサーションが要求されたときに呼び出し元へ返される属性を含む。

[SecureContext, Exposed=Window]
interface PublicKeyCredential : Credential {
    [SameObject] readonly attribute ArrayBuffer              rawId;
    [SameObject] readonly attribute AuthenticatorResponse    response;
    readonly attribute DOMString?                            authenticatorAttachment;
    AuthenticationExtensionsClientOutputs getClientExtensionResults();
    static Promise<boolean> isConditionalMediationAvailable();
    PublicKeyCredentialJSON toJSON();
};

id

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

rawId

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

response, 型は AuthenticatorResponse、readonly

この属性には、公開鍵クレデンシャルを作成するか、認証アサーションを生成するよう求めるクライアントの要求に対する認証器の応答が含まれる。PublicKeyCredentialが create()への応答として作成された場合、この属性の値はAuthenticatorAttestationResponseとなる。それ以外の場合、 PublicKeyCredentialはget()への応答として作成されており、この属性の値は AuthenticatorAssertionResponseとなる。

authenticatorAttachment, 型は DOMString、readonly、nullable

この属性は、 navigator.credentials.create() または navigator.credentials.get() メソッドが正常に完了した時点で有効であった認証器アタッチメントモダリティを報告する。属性の値はAuthenticatorAttachmentのメンバーであるべきである（SHOULD）。依存パーティは未知の値を null であるかのように扱うべきである（SHOULD）。

注: 登録または認証セレモニーの結果として、authenticatorAttachmentの値が "cross-platform" であり、同時にisUserVerifyingPlatformAuthenticatorAvailable がtrueを返す場合、利用可能なプラットフォーム認証器が存在するにもかかわらず、ユーザーはこのセレモニーでローミング認証器を使用したことになる。したがって、依存パーティには、利用可能なプラットフォーム認証器を登録するようユーザーに促す機会があり、これにより、より簡素化されたユーザーエクスペリエンスフローが可能になる場合がある。

認証器のアタッチメントモダリティは、時間の経過とともに変化する可能性がある。たとえば、ある携帯電話が当初はプラットフォームアタッチメントのみをサポートしていたものの、後に更新を受けてクロスプラットフォームアタッチメントもサポートするようになる場合がある。

getClientExtensionResults()

この操作は[[clientExtensionsResults]]の値を返す。これは、拡張のクライアント拡張処理によって生成された拡張識別子 → クライアント拡張出力のエントリを含むマップである。

isConditionalMediationAvailable()

PublicKeyCredentialは、 navigator.credentials.get()中のconditional 仲介の利用可能性を示すため、このメソッドを上書きする。 WebAuthn 依存パーティは、 options.mediation をconditionalに設定しようとする前に、利用可能性を確認するべきである（SHOULD）。

呼び出されると Promise が返され、conditional ユーザー仲介が利用可能な場合はtrue、それ以外の場合はfalseで解決される。

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

conditionalGet 機能は、この Promise がtrueで解決されることと同等である。

注: このメソッドが存在しない場合、conditional ユーザー仲介は navigator.credentials.get()では利用できない。

注: このメソッドは、navigator.credentials.create()でconditional ユーザー仲介が利用可能かどうかを示すものではない。それについては、getClientCapabilities()のconditionalCreate 機能を参照すること。

toJSON()

この操作は、RegistrationResponseJSON またはAuthenticationResponseJSONを返す。これらはPublicKeyCredentialを反映するJSON 型表現であり、 application/jsonペイロードとして依存パーティサーバーへ送信するのに適している。クライアントは、通常どおり値を JSON 型にシリアル化する責任を負うが、まずすべてのArrayBuffer 値をbase64url エンコーディングを使用してDOMString 値へエンコードするための追加の手順を実行しなければならない（MUST）。

RegistrationResponseJSON.clientExtensionResults または AuthenticationResponseJSON.clientExtensionResults メンバーは、getClientExtensionResults()の出力に設定しなければならず（MUST）、すべてのArrayBuffer 値は base64url エンコーディングを使用してDOMString 値にエンコードされる。これには、IANA "WebAuthn Extension Identifiers" レジストリ[IANA-WebAuthn-Registries]に登録されているが、 § 9 WebAuthn 拡張では定義されていない拡張からのArrayBuffer 値が含まれてもよい（MAY）。

AuthenticatorAttestationResponseJSON.transports メンバーは、getTransports()の出力に設定しなければならない（MUST）。

AuthenticatorAttestationResponseJSON.publicKey メンバーは、getPublicKey()の出力に設定しなければならない（MUST）。

AuthenticatorAttestationResponseJSON.publicKeyAlgorithm メンバーは、getPublicKeyAlgorithm()の出力に設定しなければならない（MUST）。

typedef DOMString Base64URLString;
// このオブジェクトの構造は次のいずれかになる
// RegistrationResponseJSON または AuthenticationResponseJSON
typedef object PublicKeyCredentialJSON;

dictionary RegistrationResponseJSON {
    required DOMString id;
    required Base64URLString rawId;
    required AuthenticatorAttestationResponseJSON response;
    DOMString authenticatorAttachment;
    required AuthenticationExtensionsClientOutputsJSON clientExtensionResults;
    required DOMString type;
};

dictionary AuthenticatorAttestationResponseJSON {
    required Base64URLString clientDataJSON;
    required Base64URLString authenticatorData;
    required sequence<DOMString> transports;
    // pubKeyCredParams が、ユーザーエージェントが
    // 理解しない公開鍵アルゴリズムのネゴシエーションに使用された場合、publicKey フィールドは存在しない。
    // （ユーザーエージェントがサポートしなければならないアルゴリズムの
    // 一覧については、「クレデンシャルデータへの容易なアクセス」の節を参照。）このような
    // アルゴリズムを使用する場合、公開鍵は
    // attestationObject または authenticatorData から直接解析しなければならない。
    Base64URLString publicKey;
    required COSEAlgorithmIdentifier publicKeyAlgorithm;
    // この値には上記フィールドの一部のコピーが含まれる。以下を参照:
    // 「クレデンシャルデータへの容易なアクセス」の節。
    required Base64URLString attestationObject;
};

dictionary AuthenticationResponseJSON {
    required DOMString id;
    required Base64URLString rawId;
    required AuthenticatorAssertionResponseJSON response;
    DOMString authenticatorAttachment;
    required AuthenticationExtensionsClientOutputsJSON clientExtensionResults;
    required DOMString type;
};

dictionary AuthenticatorAssertionResponseJSON {
    required Base64URLString clientDataJSON;
    required Base64URLString authenticatorData;
    required Base64URLString signature;
    Base64URLString userHandle;
};

dictionary AuthenticationExtensionsClientOutputsJSON {
};

[[type]]

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

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

[[discovery]]

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

[[identifier]]

この内部スロットには、認証器によって選択されたクレデンシャル IDが含まれる。クレデンシャル IDは、使用するクレデンシャルを検索するために使用されるため、すべての認証器にわたる同一型のすべてのクレデンシャル間で、高い確率でグローバルに一意であることが期待される。

この API は、この識別子の形式を制約しない。ただし、1023 バイトを超えてはならず（MUST NOT）、認証器が鍵を一意に選択するのに十分でなければならない（MUST）。たとえば、オンボードストレージを持たない認証器は、認証器に焼き込まれた対称鍵でラップされたクレデンシャル秘密鍵を含む識別子を作成する場合がある。

[[clientExtensionsResults]]

この内部スロットには、依存パーティが navigator.credentials.create() または navigator.credentials.get()のいずれかを呼び出した際に、依存パーティによって要求されたクライアント拡張を処理した結果が含まれる。

PublicKeyCredentialのインターフェースオブジェクトは、Credentialによる [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors)の実装を継承し、 [[Create]](origin, options, sameOriginWithAncestors)、 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)、および [[Store]](credential, sameOriginWithAncestors) のそれぞれについて独自の実装を定義する。

CredentialsContainerの preventSilentAccess() メソッドを呼び出しても、 PublicKeyCredential クレデンシャルには影響しない。これらは常にユーザー操作を必要とするためである。

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()を呼び出して、認証器にバインドされた新しい公開鍵クレデンシャルソースの作成を要求できる。

options.mediation をconditionalに設定することで、依存パーティは、ユーザーがすでにクレデンシャルの作成に同意している場合に、目立つモーダル UI を使用せずにクレデンシャルを登録したいことを示すことができる。依存パーティは、この機能が利用できない場合にユーザーに表示されるエラーを防ぐため、まずgetClientCapabilities() を使用して、クライアントが conditionalCreate 機能をサポートすることを確認するべきである（SHOULD）。クライアントは、 options.mediation がconditional に設定されている場合、セレモニー中に明示的に実行できる場合を除き、 requireUserPresenceとrequireUserVerificationの両方を FALSEに設定しなければならない（MUST）。

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

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

origin

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

options

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

sameOriginWithAncestors

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

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

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

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

このメソッドが呼び出されたとき、ユーザーエージェントは次のアルゴリズムを実行しなければならない（MUST）。

表明: options.publicKey が存在する。
sameOriginWithAncestorsがfalseの場合:
1. options.mediation が存在し、その値が conditionalである場合:
  1. "NotAllowedError" DOMExceptionをスローする
2. 呼び出し元の create() 実装によって決定される関連グローバルオブジェクトが、一時的なアクティベーションを持たない場合:
  1. "NotAllowedError" DOMExceptionをスローする。
3. 関連グローバルオブジェクトのユーザーアクティベーションを消費する。
4. クレデンシャルを作成しているオリジンが、関連グローバルオブジェクトのトップレベルオリジンと異なる場合（すなわち、ユーザーがアドレスバーで確認できるものとは異なるオリジンである場合）、クライアントはこの事実をユーザーに明確にするべきである（SHOULD）。
pkOptionsを options.publicKeyの値とする。
pkOptions.timeout が存在する場合、その値がクライアントによって定義された妥当な範囲内にあるか確認し、そうでなければその範囲内にある最も近い値へ修正する。タイマー lifetimeTimerをこの調整済みの値に設定する。 pkOptions.timeout が存在しない場合は、lifetimeTimerをクライアント固有の既定値に設定する。

pkOptions.timeoutの妥当な範囲および既定値を決定するためのガイダンスについては、WebAuthn セレモニータイムアウトの推奨範囲および既定値を参照すること。

クライアントは、特別なニーズを持つユーザーのタイムアウトに関して認知的ガイドラインを考慮するべきである（SHOULD）。
pkOptions.user.id の長さが 1 バイト以上 64 バイト以下でない場合、TypeErrorをスローする。
callerOriginをoriginとする。 callerOriginが不透明なオリジンである場合、"NotAllowedError" DOMExceptionをスローする。
effectiveDomainをcallerOriginの有効ドメインとする。有効ドメインが有効なドメインでない場合、 "SecurityError" DOMExceptionをスローする。

注: 有効ドメインはホストとして解決される場合があり、これはドメイン、IPv4 アドレス、 IPv6 アドレス、不透明なホスト、または空のホストなど、さまざまな方法で表現できる。ここでは、ホストのドメイン形式のみが許可される。これは簡略化のためであり、また PKI ベースのセキュリティと直接 IP アドレス識別を併用する際のさまざまな問題を考慮したものである。
pkOptions.rp.id が
存在する
pkOptions.rp.id がeffectiveDomainの登録可能ドメインサフィックスではなく、かつ等しくもない場合で、クライアントが
関連オリジン要求をサポートする
rpIdRequestedを pkOptions.rp.idの値とする。

callerOriginおよびrpIdRequestedを引数として、関連オリジン検証手順を実行する。結果がfalseの場合、"SecurityError" DOMExceptionをスローする。
関連オリジン要求をサポートしない

"SecurityError" DOMExceptionをスローする。
存在しない

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

type

文字列 "webauthn.create"。

challenge

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

origin

callerOriginのシリアル化。

crossOrigin

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

topOrigin

この内部メソッドに渡された sameOriginWithAncestors 引数がfalseの場合は、callerOriginのトップレベルオリジンのシリアル化。それ以外の場合はundefined。
clientDataJSONを、collectedClientDataから構築されたクライアントデータの JSON 互換シリアル化とする。
clientDataHashを、clientDataJSONによって表されるシリアル化されたクライアントデータのハッシュとする。
options.signal が存在し、中止済みである場合、 options.signalの中止理由をスローする。
issuedRequestsを新しい順序付き集合とする。
authenticatorsを、任意の時点において集合となる値とする。この集合はクライアントプラットフォーム固有のハンドルからなり、各項目は、その時点でこのクライアントプラットフォーム上で現在利用可能な認証器を識別する。

注: 認証器が「利用可能」と見なされる条件は意図的に規定されていない。これは、さまざまな仕組みにより認証器を（たとえば USB 経由で）ホットプラグしたり、クライアントが（たとえば NFC や Bluetooth 経由で）発見したり、クライアントに恒久的に組み込んだりできることを表すことを意図している。
options.mediation が存在し、その値が conditionalである場合:
1. ユーザーエージェントが最近認証を仲介していない場合、その認証のオリジンがcallerOriginでない場合、またはユーザーがこの種類のクレデンシャル作成に同意しない場合、"NotAllowedError" DOMExceptionをスローする。
  
  認証セレモニーが完了したと判断する時点はユーザーエージェントに委ねられる。その認証セレモニーは、 Web Authentication API以外の手段で実行されてもよい（MAY）。
hintsの値を考慮し、ユーザーエージェントが適切と判断するようにユーザーインターフェースを構成する。
lifetimeTimerを開始する。
lifetimeTimerが期限切れでない間、 lifetimeTimer、ならびにauthenticators内の各 authenticatorの状態および応答に応じて、次の処理を繰り返し実行する。
lifetimeTimerが期限切れになった場合、

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

ユーザーがプロセスをキャンセルするためにユーザーエージェントのユーザーインターフェースオプションを使用した場合、

issuedRequests内の各authenticatorについてそれぞれ、 authenticator上でauthenticatorCancel操作を呼び出し、 authenticatorをissuedRequestsから削除する。"NotAllowedError" DOMExceptionをスローする。

options.signal が存在し、中止済みである場合、

issuedRequests内の各authenticatorについてそれぞれ、 authenticator上でauthenticatorCancel 操作を呼び出し、authenticatorをissuedRequestsから削除する。その後、 options.signalの中止理由をスローする。

authenticatorがこのクライアントデバイス上で利用可能になった場合、
注: これには、 lifetimeTimerの開始時点ですでにauthenticatorが利用可能であった場合も含まれる。
1. このauthenticatorを、以後候補認証器とする。
2. pkOptions.authenticatorSelection が存在する場合:
  1. pkOptions.authenticatorSelection.authenticatorAttachment が存在し、その値がauthenticatorの認証器アタッチメントモダリティと等しくない場合、続行する。
  2. pkOptions.authenticatorSelection.residentKey が
    
    存在し、requiredに設定されている
    
    authenticatorがクライアント側で発見可能な公開鍵クレデンシャルソースを保存できない場合、続行する。
    
    存在し、preferred またはdiscouragedに設定されている
    
    影響なし。
    
    存在しない
    
    pkOptions.authenticatorSelection.requireResidentKey がtrueに設定され、かつauthenticatorがクライアント側で発見可能な公開鍵クレデンシャルソースを保存できない場合、続行する。
  3. pkOptions.authenticatorSelection.userVerification がrequiredに設定され、 authenticatorがユーザー検証を実行できない場合、続行する。
3. requireResidentKeyを、次のように決定される Boolean 値であるクレデンシャル作成のための有効な常駐キー要件とする。
  
  pkOptions.authenticatorSelection.residentKey が
  
  存在し、requiredに設定されている
  
  requireResidentKeyをtrueとする。
  
  存在し、preferredに設定されている
  
  authenticatorが
  
  クライアント側クレデンシャル保存モダリティに対応している
  
  requireResidentKeyをtrueとする。
  
  クライアント側クレデンシャル保存モダリティに対応していないか、クライアントが認証器の能力を判定できない
  
  requireResidentKeyをfalseとする。
  
  存在し、discouragedに設定されている
  
  requireResidentKeyをfalseとする。
  
  存在しない
  
  requireResidentKeyを pkOptions.authenticatorSelection.requireResidentKeyの値とする。
4. userVerificationを、次のように決定される Boolean 値であるクレデンシャル作成のための有効なユーザー検証要件とする。 pkOptions.authenticatorSelection.userVerification が
  requiredに設定されている
  
  options.mediation がconditionalに設定されており、セレモニー中にユーザー検証を取得できない場合、 ConstraintError DOMExceptionをスローする。
  
  userVerificationをtrueとする。
  
  preferredに設定されている
  
  authenticatorが
  
  ユーザー検証に対応している
  
  userVerificationをtrueとする。
  
  ユーザー検証に対応していない
  
  userVerificationをfalseとする。
  
  discouragedに設定されている
  
  userVerificationをfalseとする。
5. enterpriseAttestationPossibleを、次のように決定される Boolean 値とする。 pkOptions.attestation が
  
  enterpriseに設定されている
  
  ユーザーエージェントが pkOptions.rp.id に対してエンタープライズアテステーションをサポートしようとする場合（上記の手順 8を参照）、 enterpriseAttestationPossibleをtrueとする。それ以外の場合は falseとする。
  
  それ以外
  
  enterpriseAttestationPossibleをfalseとする。
6. attestationFormatsを文字列のリストとし、その初期値を pkOptions.attestationFormatsの値とする。
7. pkOptions.attestation が
  
  noneに設定されている
  
  attestationFormatsを文字列 “none” のみを含む単一要素のリストに設定する
8. excludeCredentialDescriptorListを新しいリストとする。
9. pkOptions.excludeCredentials内の各クレデンシャル記述子Cについてそれぞれ:
  1. C.transports が空ではなく、 authenticatorが C.transportsに記載されていないトランスポートで接続されている場合、クライアントは続行してもよい（MAY）。
    
    注: クライアントが続行することを選択した場合、 C.transports内のトランスポートヒントが正確でなければ、同じ認証器にバインドされた複数のクレデンシャルを誤って登録する可能性がある。たとえば、保存されたトランスポートヒントは、新しい接続オプションを追加するソフトウェアアップグレードによって不正確になる場合がある。
  2. それ以外の場合、Cを excludeCredentialDescriptorListに追加する。
  3. authenticator上でauthenticatorMakeCredential 操作を呼び出し、 clientDataHash、 pkOptions.rp、 pkOptions.user、 requireResidentKey、 userVerification、 credTypesAndPubKeyAlgs、 excludeCredentialDescriptorList、 enterpriseAttestationPossible、 attestationFormats、およびauthenticatorExtensionsをパラメーターとして渡す。
10. 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
  
  その値はpkOptions.attestationの値である。
  
  clientExtensionResults
  
  その値は、拡張識別子 → クライアント拡張出力エントリを含むAuthenticationExtensionsClientOutputs オブジェクトである。これらのエントリは、 pkOptions.extensions内の各クライアント拡張について、各拡張のクライアント拡張処理アルゴリズムを実行してクライアント拡張出力を作成することによって生成される。
3. constructCredentialAlgを、グローバルオブジェクト globalを受け取り、次の手順を持つアルゴリズムとする。
  1. credentialCreationData.attestationConveyancePreferenceOptionの値が
    
    none
    
    一意な識別につながる可能性のある情報を、同じ情報の識別につながらないバージョンで置き換える。
    
    アテステーション済みクレデンシャルデータ内のaaguid が 16 個のゼロバイトであり、 credentialCreationData.attestationObjectResult.fmt が "packed" であり、かつ credentialCreationData.attestationObjectResultに "x5c" が存在しない場合、自己アテステーションが使用されており、それ以上の処理は不要である。
    
    それ以外の場合:
    
    credentialCreationData.attestationObjectResult.fmt の値を "none" に設定し、 credentialCreationData.attestationObjectResult.attStmt の値を空のCBOR マップに設定する。（§ 8.7 None アテステーションステートメント形式および§ 6.5.4 アテステーションオブジェクトの生成を参照）。
    
    indirect
    
    クライアントは、aaguid およびアテステーションステートメントを、同じデータの、よりプライバシーに配慮したおよび/またはより容易に検証可能なバージョンで置き換えてもよい（MAY）（たとえば、匿名化 CAを使用する）。
    
    direct またはenterprise
    
    認証器のAAGUIDおよびアテステーションステートメントを変更せず依存パーティへ伝達する。
  2. attestationObjectを、globalの%ArrayBuffer%を使用して作成された新しいArrayBufferとし、 credentialCreationData.attestationObjectResultの値のバイトを格納する。
  3. idを attestationObject.authData.attestedCredentialData.credentialIdとする。
  4. pubKeyCredをglobalに関連付けられた新しいPublicKeyCredential オブジェクトとし、そのフィールドは次のとおりとする。
    
    [[identifier]]
    
    id
    
    authenticatorAttachment
    
    authenticatorの現在の認証器アタッチメントモダリティに一致するAuthenticatorAttachment 値。
    
    response
    
    globalに関連付けられた新しいAuthenticatorAttestationResponse オブジェクトであり、そのフィールドは次のとおりとする。
    
    clientDataJSON
    
    globalの%ArrayBuffer%を使用して作成された新しいArrayBufferであり、 credentialCreationData.clientDataJSONResultのバイトを格納する。
    
    attestationObject
    
    attestationObject
    
    [[transports]]
    
    authenticatorがサポートすると考えられる、辞書順に並べられた 0 個以上の一意なDOMStringのシーケンス。値はAuthenticatorTransportのメンバーであるべきだが（SHOULD）、クライアントプラットフォームは未知の値を無視しなければならない（MUST）。
    
    ユーザーエージェントがこの情報を開示したくない場合、プライバシーを保持するよう設計された任意のシーケンスで置き換えてもよい（MAY）。このシーケンスは引き続き有効でなければならず（MUST）、すなわち辞書順にソートされ、重複があってはならない。たとえば、空のシーケンスを使用してもよい。いずれの場合でも、この場合、ユーザーエージェントは依存パーティの動作が最適でなくなるリスクを負う。
    
    ユーザーエージェントがトランスポート情報を一切持たない場合、このフィールドを空のシーケンスに設定するべきである（SHOULD）。
    
    注: ユーザーエージェントが特定の認証器によってサポートされるトランスポートをどのように発見するかは、この仕様の範囲外であるが、アテステーション証明書からの情報（たとえば[FIDO-Transports-Ext]）、 CTAP2 などの認証器プロトコルで伝達されるメタデータ、またはプラットフォーム認証器に関する特殊な知識を含む場合がある。
    
    [[clientExtensionsResults]]
    
    globalの%ArrayBuffer%を使用して作成された新しいArrayBufferであり、 credentialCreationData.clientExtensionResultsのバイトを格納する。
  5. pubKeyCredを返す。
4. issuedRequests内の残りの各authenticatorについてそれぞれ、 authenticator上でauthenticatorCancel操作を呼び出し、それをissuedRequestsから削除する。
5. constructCredentialAlgを返し、このアルゴリズムを終了する。
"NotAllowedError" DOMExceptionをスローする。

上記の処理中、ユーザーエージェントは、認証器を選択および認可するプロセスをユーザーに案内するため、何らかの UI を表示するべきである（SHOULD）。 options.mediation がconditionalに設定されている場合、ユーザーエージェントによって決定された手段を介してクレデンシャル作成への同意が以前に得られている場合を除き、目立つモーダル UI を表示するべきではない。

5.1.3.1. 作成要求の例外

この節は規範的ではない。

WebAuthn 依存パーティは、navigator.credentials.create()の呼び出しによって、さまざまな例外に遭遇する可能性がある。一部の例外には発生した理由が複数存在する可能性があり、 WebAuthn 依存パーティは、WebAuthn の使用方法に基づいて実際の理由を推測する必要がある。

注: この仕様の外部で定義されたものを含め、任意のWebAuthn 拡張の処理中に発生する可能性のある例外は、ここには列挙されていない。

次のDOMException 例外が発生する可能性がある。

AbortError: セレモニーがAbortControllerによってキャンセルされた。 § 5.6 AbortSignal による操作の中止および§ 1.3.4 認証操作の中止を参照すること。
ConstraintError: residentKey がrequiredに設定されているものの、利用可能な認証器のいずれも常駐キーをサポートしていないか、またはuserVerification がrequiredに設定されているものの、利用可能な認証器のいずれもユーザー検証を実行できなかった。
InvalidStateError: セレモニーで使用された認証器が、ユーザーがクレデンシャルの登録に同意した後に、excludeCredentials 内のエントリを認識した。
NotSupportedError: pubKeyCredParams 内のどのエントリにもtype プロパティとしてpublic-keyが含まれていなかったか、または認証器が pubKeyCredParamsで指定された署名アルゴリズムのいずれもサポートしていなかった。
SecurityError: 有効ドメインが有効なドメインではなかったか、または rp.id が有効ドメインと等しくも、その登録可能ドメインサフィックスでもなかった。後者の場合、クライアントが関連オリジン要求をサポートしていないか、関連オリジン検証手順が失敗した。
NotAllowedError: ユーザーがセレモニーをキャンセルした場合などの一般的なものを含む、幅広い考えられる理由を包括するエラー。これらの原因の一部はこの仕様全体で文書化されており、その他はクライアント固有である。

次の単純例外が発生する可能性がある。

TypeError: options引数が有効な CredentialCreationOptions 値ではなかったか、または user.id の値が空であるか、64 バイトを超えていた。

5.1.4. 既存のクレデンシャルを使用してアサーションを作成する

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

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

この仕様では、任意のアサーションを作成するために認可ジェスチャーを必要とするため、 PublicKeyCredential は、空の集合を返す[[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) の既定の動作を継承する。 PublicKeyCredentialによる [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) の実装は次の節で規定される。

一般に、ユーザーエージェントは、操作を完了するための認証器の選択および認可についてユーザーを案内する何らかの UI を表示するべきである（SHOULD）。 options.mediation をconditionalに設定することで、依存パーティは、クレデンシャルが発見された場合を除き、目立つモーダル UI を表示するべきではないことを示すことができる。依存パーティは、この機能が利用できない場合にユーザーに表示されるエラーを防ぐため、まずisConditionalMediationAvailable() またはgetClientCapabilities() を使用して、クライアントがconditionalGet 機能をサポートすることを確認するべきである（SHOULD）。

任意の 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()によって処理される。

このメソッドが呼び出されたとき、ユーザーエージェントは次のアルゴリズムを実行しなければならない（MUST）。

表明: options.publicKey が存在する。
pkOptionsを options.publicKeyの値とする。
options.mediation が存在し、その値が conditionalである場合:
1. credentialIdFilterを pkOptions.allowCredentialsの値とする。
2. pkOptions.allowCredentials を空に設定する。
  
  注: これにより、発見不能なクレデンシャルが conditional 要求中に使用されることを防ぐ。
3. タイマーlifetimeTimerを無限大の値に設定する。
  
  注: lifetimeTimerを無限大の値に設定することで、ユーザーはDocumentの存続期間全体にわたって、 "webauthn"自動入力詳細トークンが付けられた任意の input フォームコントロールと対話できる。たとえば、ユーザーがそのような入力フィールドをクリックすると、ユーザーエージェントは発見されたクレデンシャルの一覧をレンダリングしてユーザーに選択させることができ、場合によっては「別の方法を試す」オプションもユーザーに提供できる。
それ以外の場合:
1. credentialIdFilterを空のリストとする。
2. pkOptions.timeout が存在する場合、その値がクライアントによって定義された妥当な範囲内にあるか確認し、そうでなければその範囲内にある最も近い値へ修正する。タイマーlifetimeTimerをこの調整済みの値に設定する。 pkOptions.timeout が存在しない場合は、lifetimeTimerをクライアント固有の既定値に設定する。
  
  pkOptions.timeoutの妥当な範囲および既定値を決定するためのガイダンスについては、WebAuthn セレモニータイムアウトの推奨範囲および既定値を参照すること。
  
  ユーザーエージェントは、特別なニーズを持つユーザーのタイムアウトに関して認知的ガイドラインを考慮するべきである（SHOULD）。
callerOriginをoriginとする。 callerOriginが不透明なオリジンである場合、"NotAllowedError" DOMExceptionをスローする。
effectiveDomainをcallerOriginの有効ドメインとする。有効ドメインが有効なドメインでない場合、 "SecurityError" DOMExceptionをスローする。

注: 有効ドメインはホストとして解決される場合があり、これは、ドメイン、IPv4 アドレス、IPv6 アドレス、不透明なホスト、または空のホストなど、さまざまな方法で表現できる。ここでは、ホストのドメイン形式のみが許可される。これは簡略化のためであり、また PKI ベースのセキュリティと直接 IP アドレス識別を併用する際のさまざまな問題を考慮したものである。
pkOptions.rpId が
存在する
pkOptions.rpId がeffectiveDomainの登録可能ドメインサフィックスではなく、かつ等しくもない場合で、クライアントが
関連オリジン要求をサポートする
rpIdRequestedを pkOptions.rpIdの値とする。

callerOriginおよびrpIdRequestedを引数として、関連オリジン検証手順を実行する。結果がfalseの場合、"SecurityError" DOMExceptionをスローする。
関連オリジン要求をサポートしない

"SecurityError" DOMExceptionをスローする。
存在しない

pkOptions.rpId をeffectiveDomainに設定する。
注: rpIdは呼び出し元のRP IDを表す。RP IDは、呼び出し元が get()を呼び出す際に pkOptions.rpId を明示的に設定していない限り、既定では呼び出し元のオリジンの有効ドメインとなる。
clientExtensionsを新しいマップとし、 authenticatorExtensionsを新しいマップとする。
pkOptions.extensions が存在する場合、 pkOptions.extensionsの各extensionId → clientExtensionInputについてそれぞれ:
1. extensionIdがこのクライアントプラットフォームによってサポートされていないか、認証拡張でない場合、続行する。
2. clientExtensions[extensionId]を clientExtensionInputに設定する。
3. extensionIdが認証器拡張でない場合、続行する。
4. authenticatorExtensionInputを、clientExtensionInputに対してextensionIdのクライアント拡張処理アルゴリズムを実行した（CBOR）結果とする。アルゴリズムがエラーを返した場合、続行する。
5. authenticatorExtensions[extensionId]を、 authenticatorExtensionInputのbase64url エンコーディングに設定する。
collectedClientDataを、次のフィールドを持つ新しいCollectedClientData インスタンスとする。

type

文字列 "webauthn.get"。

challenge

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

origin

callerOriginのシリアル化。

crossOrigin

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

topOrigin

この内部メソッドに渡された sameOriginWithAncestors 引数がfalseの場合は、callerOriginのトップレベルオリジンのシリアル化。それ以外の場合はundefined。
clientDataJSONを、collectedClientDataから構築されたクライアントデータの JSON 互換シリアル化とする。
clientDataHashを、clientDataJSONによって表されるシリアル化されたクライアントデータのハッシュとする。
options.signal が存在し、中止済みである場合、 options.signalの中止理由をスローする。
issuedRequestsを新しい順序付き集合とする。
savedCredentialIdsを新しいマップとする。
authenticatorsを、任意の時点において集合となる値とする。この集合はクライアントプラットフォーム固有のハンドルからなり、各項目は、その時点でこのクライアントプラットフォーム上で現在利用可能な認証器を識別する。

注: 認証器が「利用可能」と見なされる条件は意図的に規定されていない。これは、認証器を（たとえば USB 経由で）ホットプラグしたり、クライアントが（たとえば NFC や Bluetooth 経由で）さまざまな仕組みにより発見したり、クライアントに恒久的に組み込んだりできることを表すことを意図している。
silentlyDiscoveredCredentialsを、DiscoverableCredentialMetadata → 認証器という形式のエントリを持つ新しいマップとする。
hints の値を考慮し、ユーザーエージェントが適切と判断するようにユーザーインターフェースを構成する。
lifetimeTimerを開始する。
lifetimeTimerが期限切れでない間、 lifetimeTimer、ならびにauthenticators内の各 authenticatorの状態および応答に応じて、次の処理を繰り返し実行する。
lifetimeTimerが期限切れになった場合、

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

ユーザーがプロセスをキャンセルするためにユーザーエージェントのユーザーインターフェースオプションを使用した場合、

issuedRequests内の各authenticatorについてそれぞれ、 authenticator上でauthenticatorCancel操作を呼び出し、 authenticatorをissuedRequestsから削除する。"NotAllowedError" DOMExceptionをスローする。

options.signal が存在し、中止済みである場合、

issuedRequests内の各authenticatorについてそれぞれ、 authenticator上でauthenticatorCancel操作を呼び出し、 authenticatorをissuedRequestsから削除する。その後、 options.signalの中止理由をスローする。

options.mediation がconditional であり、ユーザーが input または textarea フォームコントロールと対話し、その autocomplete 属性の非自動入力クレデンシャル型が "webauthn"である場合、
注: "webauthn"自動入力詳細トークンは、 "Normal" または "Contact" 型の最後の自動入力詳細トークンの直後に現れなければならない。たとえば:
- "username webauthn"
- "current-password webauthn"
1. silentlyDiscoveredCredentialsが空でない場合:
  1. silentlyDiscoveredCredentialsからDiscoverableCredentialMetadata を任意で選択するようユーザーに促す。プロンプトには、各DiscoverableCredentialMetadataの otherUIから、 name やdisplayNameなどの値を表示するべきである（SHOULD）。
    
    credentialMetadataを、存在する場合はユーザーが選択したDiscoverableCredentialMetadata とする。
  2. ユーザーがcredentialMetadataを選択した場合、
    
    publicKeyOptionsを pkOptionsの一時的なコピーとする。
    
    authenticatorを silentlyDiscoveredCredentials[credentialMetadata]の値とする。
    
    publicKeyOptions.allowCredentials を、単一のPublicKeyCredentialDescriptor 項目を含むリストに設定する。その項目のidの値はcredentialMetadataのidの値に設定し、type の値はcredentialMetadataのtypeに設定する。
    
    authenticator、savedCredentialIds、 publicKeyOptions、rpId、 clientDataHash、および authenticatorExtensionsを引数として、認証器へのクレデンシャル要求の発行アルゴリズムを実行する。
    
    これがfalseを返す場合、続行する。
    
    authenticatorをissuedRequestsに追加する。
options.mediation がconditionalではなく、 issuedRequestsが空で、 pkOptions.allowCredentials が空ではなく、かつその中のどの公開鍵クレデンシャルについてもauthenticatorが利用可能になることがない場合、

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

注: クライアントプラットフォームがauthenticatorが利用可能にならないことを判定する方法の 1 つは、存在する PublicKeyCredentialDescriptor 項目の transports メンバーを、 pkOptions.allowCredentials 内で確認することである。たとえば、すべての PublicKeyCredentialDescriptor 項目が internalのみを列挙しているが、すべてのプラットフォームauthenticatorが試行済みである場合、その要求を満たす可能性はない。または、すべての PublicKeyCredentialDescriptor 項目が、クライアントプラットフォームがサポートしない transports を列挙している場合もある。

authenticatorがこのクライアントデバイス上で利用可能になった場合、
注: これには、 lifetimeTimerの開始時点ですでにauthenticatorが利用可能であった場合も含まれる。
1. options.mediation がconditional であり、authenticatorがsilentCredentialDiscovery 操作をサポートする場合:
  1. collectedDiscoveredCredentialMetadataを、 rpIdをパラメーターとしてauthenticator上でsilentCredentialDiscovery 操作を呼び出した結果とする。
  2. collectedDiscoveredCredentialMetadataの各credentialMetadataについてそれぞれ:
    
    credentialIdFilterが空であるか、 credentialIdFilterが、 credentialMetadataのidに idの値が設定された項目を含む場合、 silentlyDiscoveredCredentials[credentialMetadata]を authenticatorに設定する。
    
    注: 特定の UI コンテキストとの対話を介してユーザーがクレデンシャルを選択すると、この認証器に要求が発行される（詳細はこちらを参照）。
2. それ以外の場合:
  1. authenticator、savedCredentialIds、 pkOptions、rpId、clientDataHash、および authenticatorExtensionsを引数として、認証器へのクレデンシャル要求の発行アルゴリズムを実行する。
    
    これがfalseを返す場合、続行する。
    
    注: この分岐は、 options.mediation がconditional であり、authenticatorがsilentCredentialDiscovery 操作をサポートしない場合に採用され、このような認証器を conditional ユーザー仲介要求中にも使用できるようにする。
  2. 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 の値を、成功した authenticatorGetAssertion 操作から返されたクレデンシャル IDのバイトに設定する。これは§ 6.3.3 authenticatorGetAssertion 操作で定義されている。
  
  clientDataJSONResult
  
  その値はclientDataJSONのバイトである。
  
  authenticatorDataResult
  
  その値は、認証器から返された認証器データのバイトである。
  
  signatureResult
  
  その値は、認証器から返された署名値のバイトである。
  
  userHandleResult
  
  認証器がユーザーハンドルを返した場合、userHandleResult の値を、返されたユーザーハンドルのバイトに設定する。それ以外の場合、userHandleResult の値を null に設定する。
  
  clientExtensionResults
  
  その値は、拡張識別子 → クライアント拡張出力エントリを含むAuthenticationExtensionsClientOutputs オブジェクトである。これらのエントリは、 pkOptions.extensions内の各クライアント拡張について、各拡張のクライアント拡張処理アルゴリズムを実行してクライアント拡張出力を作成することによって生成される。
3. credentialIdFilterが空ではなく、 credentialIdFilterに、 credentialIdResultの値に idの値が設定された項目が含まれない場合、続行する。
4. credentialIdFilterが空であり、かつuserHandleResultが null の場合、続行する。
5. settingsを現在の設定オブジェクトとする。 globalをsettingsのグローバルオブジェクトとする。
6. pubKeyCredをglobalに関連付けられた新しいPublicKeyCredential オブジェクトとし、そのフィールドは次のとおりとする。
  
  [[identifier]]
  
  globalの%ArrayBuffer%を使用して作成された新しいArrayBufferであり、 assertionCreationData.credentialIdResultのバイトを格納する。
  
  authenticatorAttachment
  
  authenticatorの現在の認証器アタッチメントモダリティに一致するAuthenticatorAttachment 値。
  
  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のバイトを格納する。
7. issuedRequests内の残りの各authenticatorについてそれぞれ、 authenticator上でauthenticatorCancel操作を呼び出し、それをissuedRequestsから削除する。
8. pubKeyCredを返し、このアルゴリズムを終了する。
"NotAllowedError" DOMExceptionをスローする。

5.1.4.2. 認証器へのクレデンシャル要求の発行

[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) のこのサブアルゴリズムは、指定されたPublicKeyCredentialRequestOptionsを使用して、指定された認証器からクレデンシャルを要求するために必要な、特定の UI コンテキストに依存しない手順を包含する。これは、現在の認証セレモニーがどのユーザー仲介（例: conditional 仲介）を受けるかに応じて、[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) からさまざまな箇所で呼び出される。

このアルゴリズムは次の引数を受け取る。

authenticator: このクライアントプラットフォーム上で現在利用可能な認証器を識別する、クライアントプラットフォーム固有のハンドル。
savedCredentialIds: 認証器 → クレデンシャル IDを含むマップ。この引数はこのアルゴリズム内で変更される。
pkOptions: この引数は、発見する公開鍵クレデンシャルの望ましい属性を指定するPublicKeyCredentialRequestOptions オブジェクトである。
rpId: 要求のRP ID。
clientDataHash: clientDataJSONによって表されるシリアル化されたクライアントデータのハッシュ。
authenticatorExtensions: 拡張識別子から、認証器拡張用のクライアント拡張処理出力のbase64url エンコーディングへの対応付けを含むマップ。

このアルゴリズムは、クライアントがauthenticatorは要求を処理できないと判定した場合はfalseを、要求が正常に発行された場合はtrueを返す。

認証器へのクレデンシャル要求の発行の手順は次のとおりである。

pkOptions.userVerification が required に設定され、authenticatorがユーザー検証を実行できない場合、 falseを返す。
userVerificationを、次のように決定される Boolean 値であるアサーションのための有効なユーザー検証要件とする。 pkOptions.userVerification が

requiredに設定されている

userVerificationをtrueとする。

preferredに設定されている

authenticatorが

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

userVerificationをtrueとする。

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

userVerificationをfalseとする。

discouragedに設定されている

userVerificationをfalseとする。
pkOptions.allowCredentials が
空ではない
1. allowCredentialDescriptorListを新しいリストとする。
2. クライアントプラットフォーム固有の手順を実行し、 pkOptions.allowCredentials によって記述された公開鍵クレデンシャルのうち、どれがこのauthenticatorにバインドされているかを、 rpId、 pkOptions.allowCredentials.id、および pkOptions.allowCredentials.type と照合して判定する。 allowCredentialDescriptorListをこのフィルター済みリストに設定する。
3. allowCredentialDescriptorListが空である場合、falseを返す。
4. distinctTransportsを新しい順序付き集合とする。
5. allowCredentialDescriptorListにちょうど 1 つの値しかない場合、 savedCredentialIds[authenticator]を allowCredentialDescriptorList[0].idの値に設定する（詳細については、§ 6.3.3 authenticatorGetAssertion 操作のこちらを参照）。
6. allowCredentialDescriptorList内の各クレデンシャル記述子Cについてそれぞれ、 C.transports の各値が存在する場合、それをdistinctTransportsに追加する。
  
  注: 順序付き集合の特性により、 distinctTransportsには、この認証器について、 transportsの一意な値のみが集約される。
7. 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によって識別される依存パーティにスコープ設定された、保有している任意のクレデンシャルを使用するよう要求されている。
trueを返す。

5.1.4.3. 取得要求の例外

この節は規範的ではない。

WebAuthn 依存パーティは、navigator.credentials.get()の呼び出しによって、さまざまな例外に遭遇する可能性がある。一部の例外には発生した理由が複数存在する可能性があり、 WebAuthn 依存パーティは、WebAuthn の使用方法に基づいて実際の理由を推測する必要がある。

注: この仕様の外部で定義されたものを含め、任意のWebAuthn 拡張の処理中に発生する可能性のある例外は、ここには列挙されていない。

次のDOMException 例外が発生する可能性がある。

AbortError: セレモニーがAbortControllerによってキャンセルされた。 § 5.6 AbortSignal による操作の中止および§ 1.3.4 認証操作の中止を参照すること。
SecurityError: 有効ドメインが有効なドメインではなかったか、または rp.id が有効ドメインと等しくも、その登録可能ドメインサフィックスでもなかった。後者の場合、クライアントが関連オリジン要求をサポートしていないか、関連オリジン検証手順が失敗した。
NotAllowedError: ユーザーがセレモニーをキャンセルした場合などの一般的なものを含む、幅広い考えられる理由を包括するエラー。これらの原因の一部はこの仕様全体で文書化されており、その他はクライアント固有である。

次の単純例外が発生する可能性がある。

TypeError: options引数が有効な CredentialRequestOptions値ではなかった。

5.1.5. 既存のクレデンシャルを保存する - PublicKeyCredential の `[[Store]](credential, sameOriginWithAncestors)` 内部メソッド

[[Store]](credential, sameOriginWithAncestors) メソッドは、Web Authentication のPublicKeyCredential 型ではサポートされていないため、 [[Store]](credential, sameOriginWithAncestors) 内部メソッドの実装は常にエラーをスローする。

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

この内部メソッドは 2 つの引数を受け取る。

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

このメソッドが呼び出されたとき、ユーザーエージェントは次のアルゴリズムを実行しなければならない（MUST）。

"NotSupportedError" DOMExceptionをスローする。

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

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

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

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

5.1.7. クライアント機能の利用可能性 - PublicKeyCredential の `getClientCapabilities()` メソッド

WebAuthn 依存パーティは、このメソッドを使用して、限定された一連のクライアント機能の利用可能性を判定し、特定のワークフローおよびエクスペリエンスをユーザーに提供する。たとえば、RP は、 hybrid トランスポートのみが利用可能なクライアント、またはconditional 仲介が利用できないクライアントで、ユーザー名フィールドを表示する代わりにサインインボタンを提供してもよい。

呼び出されると、クライアントは、これらの機能の利用可能性を発見するためのクライアントプラットフォーム固有の手順を使用する。

このメソッドは引数を取らず、機能キーから Boolean 値へのレコードを返す。

partial interface PublicKeyCredential {
    static Promise<PublicKeyCredentialClientCapabilities> getClientCapabilities();
};

typedef record<DOMString, boolean> PublicKeyCredentialClientCapabilities;

PublicKeyCredentialClientCapabilities 内のキーは、辞書順の昇順に並べなければならない（MUST）。キーの集合には、ClientCapabilityの列挙値の集合を含めるべきである（SHOULD）が、クライアントは必要と判断したキーを省略してもよい（MAY）。§ 14.5.4 クライアント機能の開示を参照すること。

特定の機能の値がtrueの場合、その機能は現在クライアントによってサポートされていることが既知である。特定の機能の値がfalseの場合、その機能は現在クライアントによってサポートされていないことが既知である。機能がキーとして存在しない場合、そのクライアント機能が利用可能かどうかは不明である。

キーの集合には、クライアントによって実装される各拡張についてもキーを含めるべきであり（SHOULD）、そのキーは文字列extension:を拡張識別子の前に付けることで形成される。実装されている各拡張に関連付けられる値は trueであるべきである（SHOULD）。getClientCapabilities()がクライアントによってサポートされているが、ある拡張がtrueの値に対応付けられていない場合、依存パーティは、その拡張に対するクライアント処理手順がこのクライアントによって実行されず、その拡張が認証器へ転送されない可能性があると仮定してもよい（MAY）。

拡張がtrueに対応付けられている場合でも、特定の操作で使用される認証器がその拡張をサポートしていない可能性があることに注意すること。したがって、依存パーティは、それだけを根拠として、その拡張に対する認証器処理手順が実行されると仮定してはならない（MUST NOT）。

5.1.8. 登録セレモニーのオプションを逆シリアル化する - PublicKeyCredential の `parseCreationOptionsFromJSON()` メソッド

WebAuthn 依存パーティは、このメソッドを使用して、 navigator.credentials.create() のオプションのJSON 型表現を PublicKeyCredentialCreationOptionsに変換する。

呼び出されると、クライアントは、 options 引数を、新しい、同一構造のPublicKeyCredentialCreationOptions オブジェクトに変換しなければならない（MUST）。その際、base64url エンコーディングを使用して、 PublicKeyCredentialCreationOptionsJSON 内のDOMString 属性のうち、 PublicKeyCredentialCreationOptions 内のバッファソース型属性に対応するものをデコードする。この変換は、クライアントによって処理される任意のクライアント拡張入力にも適用しなければならない（MUST）。

AuthenticationExtensionsClientInputsJSON には、IANA の "WebAuthn Extension Identifiers" レジストリ[IANA-WebAuthn-Registries]に登録されているが、 § 9 WebAuthn 拡張では定義されていない拡張が含まれてもよい（MAY）。

クライアントが、 JSON 型表現のいずれかを解析する際に問題に遭遇した場合、互換性のない値の説明を含む "EncodingError" DOMException をスローし、操作を終了しなければならない（MUST）。

partial interface PublicKeyCredential {
    static PublicKeyCredentialCreationOptions parseCreationOptionsFromJSON(PublicKeyCredentialCreationOptionsJSON options);
};

dictionary PublicKeyCredentialCreationOptionsJSON {
    required PublicKeyCredentialRpEntity                    rp;
    required PublicKeyCredentialUserEntityJSON              user;
    required Base64URLString                                challenge;
    required sequence<PublicKeyCredentialParameters>        pubKeyCredParams;
    unsigned long                                           timeout;
    sequence<PublicKeyCredentialDescriptorJSON>             excludeCredentials = [];
    AuthenticatorSelectionCriteria                          authenticatorSelection;
    sequence<DOMString>                                     hints = [];
    DOMString                                               attestation = "none";
    sequence<DOMString>                                     attestationFormats = [];
    AuthenticationExtensionsClientInputsJSON                extensions;
};

dictionary PublicKeyCredentialUserEntityJSON {
    required Base64URLString        id;
    required DOMString              name;
    required DOMString              displayName;
};

dictionary PublicKeyCredentialDescriptorJSON {
    required DOMString              type;
    required Base64URLString        id;
    sequence<DOMString>             transports;
};

dictionary AuthenticationExtensionsClientInputsJSON {
};

5.1.9. 認証セレモニーのオプションを逆シリアル化する - PublicKeyCredential の `parseRequestOptionsFromJSON()` メソッド

WebAuthn 依存パーティは、このメソッドを使用して、 navigator.credentials.get() のオプションのJSON 型表現を PublicKeyCredentialRequestOptionsに変換する。

呼び出されると、クライアントは、 options 引数を、新しい、同一構造のPublicKeyCredentialRequestOptions オブジェクトに変換しなければならない（MUST）。その際、base64url エンコーディングを使用して、 PublicKeyCredentialRequestOptionsJSON 内のDOMString 属性のうち、 PublicKeyCredentialRequestOptions 内のバッファソース型属性に対応するものをデコードする。この変換は、クライアントによって処理される任意のクライアント拡張入力にも適用しなければならない（MUST）。

partial interface PublicKeyCredential {
    static PublicKeyCredentialRequestOptions parseRequestOptionsFromJSON(PublicKeyCredentialRequestOptionsJSON options);
};

dictionary PublicKeyCredentialRequestOptionsJSON {
    required Base64URLString                                challenge;
    unsigned long                                           timeout;
    DOMString                                               rpId;
    sequence<PublicKeyCredentialDescriptorJSON>             allowCredentials = [];
    DOMString                                               userVerification = "preferred";
    sequence<DOMString>                                     hints = [];
    AuthenticationExtensionsClientInputsJSON                extensions;
};

5.1.10. クレデンシャルの変更を認証器に通知する - PublicKeyCredential のシグナルメソッド

partial interface PublicKeyCredential {
    static Promise<undefined> signalUnknownCredential(UnknownCredentialOptions options);
    static Promise<undefined> signalAllAcceptedCredentials(AllAcceptedCredentialsOptions options);
    static Promise<undefined> signalCurrentUserDetails(CurrentUserDetailsOptions options);
};

dictionary UnknownCredentialOptions {
    required DOMString                     rpId;
    required Base64URLString               credentialId;
};

dictionary AllAcceptedCredentialsOptions {
    required DOMString                     rpId;
    required Base64URLString               userId;
    required sequence<Base64URLString>     allAcceptedCredentialIds;
};

dictionary CurrentUserDetailsOptions {
    required DOMString                     rpId;
    required Base64URLString               userId;
    required DOMString                     name;
    required DOMString                     displayName;
};

WebAuthn 依存パーティは、これらのシグナルメソッドを使用して、認証器に公開鍵クレデンシャルの状態を通知し、不正または失効したクレデンシャルを更新、削除、または非表示にできる。クライアントは、この機能を状況に応じて提供する。これは、認証器が自身のクレデンシャルマップの更新をサポートしていない場合や、要求が行われた時点で接続されていない場合があるためである。さらに、ユーザーの同意なしにユーザーのクレデンシャルに関する情報を明らかにすることを避けるため、シグナルメソッドは、操作が成功したかどうかを示さない。Promise が正常に解決されたことは、 optionsオブジェクトが適切に構成されていたことだけを意味する。

各シグナルメソッドには、認証器アクションが含まれる。認証器は、本仕様で示される認証器アクションから逸脱することを選択してもよい（MAY）。たとえば、ユーザーの意向に反すると合理的に考えられる変更を無視したり、変更を行う前にユーザーに確認したりしてもよい。したがって、認証器アクションは、シグナルメソッドを処理するための推奨方法として提供される。

認証器が認証器アクションを処理する能力を持たない場合、クライアントは、[FIDO-CTAP]の authenticatorCredentialManagement コマンドなど、既存の基盤を使用して同等の効果を実現することを選択してもよい（MAY）。

注: シグナルメソッドは、意図的に認証器が認証器アクションの実行を完了するのを待たない。この措置は、要求のタイミングに基づいて、WebAuthn 依存パーティがユーザーの同意なしに自身のクレデンシャルの利用可能性に関する情報を得ることからユーザーを保護する。

5.1.10.1. 非同期 RP ID 検証アルゴリズム

非同期 RP ID 検証アルゴリズムにより、シグナルメソッドは RP IDを並列に検証できる。このアルゴリズムはDOMString rpIdを入力として受け取り、検証が失敗した場合に拒否される Promise を返す。手順は次のとおりである。

effectiveDomainを、関連設定オブジェクトのオリジンの有効ドメインとする。 effectiveDomainが有効なドメインでない場合、"SecurityError" DOMExceptionで拒否された Promiseを返す。
rpIdがeffectiveDomainの登録可能ドメインサフィックスであるか、等しい場合、 undefined で解決された Promiseを返す。
クライアントが関連オリジン要求をサポートしない場合、"SecurityError" DOMExceptionで拒否された Promiseを返す。
pを新しい Promiseとする。
次の手順を並列に実行する。
1. callerOriginおよびrpIdを引数として関連オリジン検証手順を実行した結果がtrueの場合、pを解決する。
2. それ以外の場合、"SecurityError" DOMExceptionで pを拒否する。
pを返す。

5.1.10.2. `signalUnknownCredential(options)`

signalUnknownCredential メソッドは、クレデンシャル IDがWebAuthn 依存パーティによって認識されなかったこと、たとえばユーザーによって削除されたことを通知する。signalAllAcceptedCredentials(options)とは異なり、このメソッドでは、受け入れられるクレデンシャル IDの一覧全体と userHandleを渡す必要がなく、未認証の呼び出し元へのプライバシー漏えいを回避する（§ 14.6.3 クレデンシャル ID を介したプライバシー漏えいを参照）。

signalUnknownCredential(options) が呼び出されると、クライアントは次の手順を実行する。

options.credentialIdを base64url デコードした結果がエラーの場合、TypeErrorで拒否された Promiseを返す。
pを、 options.rpIdを使用して非同期 RP ID 検証アルゴリズムを実行した結果とする。
pが履行されたら、次の手順を並列に実行する。
1. このクライアントプラットフォーム上で現在利用可能なすべての認証器について、 optionsを入力としてunknownCredentialId 認証器アクションを呼び出す。
pを返す。

unknownCredentialId 認証器アクションはUnknownCredentialOptions optionsを受け取り、次のように動作する。

認証器のクレデンシャルマップ内の各公開鍵クレデンシャルソースcredentialについてそれぞれ:
1. credentialのrpIdが options.rpId と等しく、かつ credentialのidが options.credentialIdを base64url デコードした結果と等しい場合、 credentialをクレデンシャルマップから削除するか、認証器固有の手順を使用して、今後の認証セレモニーから非表示にする。

ユーザーがWebAuthn 依存パーティによって提供された UI 上でクレデンシャルを削除する。その後、 WebAuthn 依存パーティに空の allowCredentialsで認証しようとすると、認証器の UI は、以前削除したクレデンシャルを提示する。ユーザーはそのクレデンシャルを選択する。サインイン試行を拒否した後、WebAuthn 依存パーティは次を実行する。

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc"  // ユーザーが直前に試したクレデンシャル ID、base64url
});

その後、認証器は、今後の認証セレモニーからクレデンシャルを削除または非表示にする。

5.1.10.3. `signalAllAcceptedCredentials(options)`

特定のユーザーについて、クレデンシャル IDの完全な一覧を通知する。WebAuthn 依存パーティは、ユーザーが認証済みで、したがってプライバシー漏えいのリスクがない場合（§ 14.6.3 クレデンシャル ID を介したプライバシー漏えいを参照）、 signalUnknownCredential()よりもこのメソッドを優先するべきである（SHOULD）。これは、この一覧がユーザーの公開鍵クレデンシャルの完全なスナップショットを提供し、現在接続されている認証器にまだ報告されていない変更も反映する可能性があるためである。

signalAllAcceptedCredentials(options) が呼び出されると、クライアントは次の手順を実行する。

options.userIdを base64url デコードした結果がエラーの場合、TypeErrorで拒否された Promiseを返す。
options.allAcceptedCredentialIds内の各credentialIdについてそれぞれ:
1. credentialIdをbase64url デコードした結果がエラーの場合、 TypeErrorで拒否された Promiseを返す。
pを、 options.rpIdを使用して非同期 RP ID 検証アルゴリズムを実行した結果とする。
pが履行されたら、次の手順を並列に実行する。
1. このクライアントプラットフォーム上で現在利用可能なすべての認証器について、 optionsを入力としてallAcceptedCredentialIds 認証器アクションを呼び出す。
pを返す。

allAcceptedCredentialIds 認証器アクションはAllAcceptedCredentialsOptions optionsを受け取り、次のように動作する。

userIdを、 options.userIdを base64url デコードした結果とする。
表明: userIdはエラーではない。
credentialを クレデンシャルマップ[options.rpId, userId]とする。
credentialが存在しない場合、これらの手順を中止する。
options.allAcceptedCredentialIds が、credentialのidをbase64url エンコードした結果を含まない場合、 credentialをクレデンシャルマップから削除するか、認証器固有の手順を使用して、今後の認証セレモニーから非表示にする。
それ以外の場合で、credentialが認証器固有の手順によって非表示にされている場合、そのアクションを元に戻し、credentialが今後の認証セレモニーに存在するようにする。

ユーザーは、base64url エンコードすると aaおよびbbになるクレデンシャル IDを持つ 2 つのクレデンシャルを持っている。ユーザーは、WebAuthn 依存パーティによって提供された UI 上でクレデンシャルaaを削除する。 WebAuthn 依存パーティは次を実行する。

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "aabbcc",  // ユーザーハンドル、base64url。
    allAcceptedCredentialIds: [
        "bb",
    ]
});

実行時に認証器が接続されている場合、今後の認証セレモニーから、aaに対応するクレデンシャルを削除または非表示にする。

注: signalAllAcceptedCredentials(options) が実行される時点で、認証器が接続されていない場合がある。したがって、WebAuthn 依存パーティは、 signalAllAcceptedCredentials(options) を定期的に、たとえばサインインのたびに実行することを選択してもよい。

注: allAcceptedCredentialIds に存在しないクレデンシャルは削除または非表示になり、元に戻せない可能性がある。依存パーティは、有効なクレデンシャル ID を一覧から決して省略しないよう注意しなければならない。有効なクレデンシャル IDを誤って省略した場合、依存パーティは、認証器がサポートしているなら、それを「再表示」するため、可能な限り速やかに signalAllAcceptedCredentials(options) に再び含めるべきである。

認証器は可能な限り、有効なクレデンシャル IDをWebAuthn 依存パーティが誤って allAcceptedCredentialIds から省略した場合の復旧を容易にするため、公開鍵クレデンシャルを恒久的に削除する代わりに一定期間非表示にすることを優先するべきである（SHOULD）。

5.1.10.4. `signalCurrentUserDetails(options)`

signalCurrentUserDetails メソッドは、ユーザーの現在の name およびdisplayNameを通知する。

signalCurrentUserDetails(options) が呼び出されると、クライアントは次の手順を実行する。

options.userIdを base64url デコードした結果がエラーの場合、 TypeErrorで拒否された Promiseを返す。
pを、 options.rpIdを使用して非同期 RP ID 検証アルゴリズムを実行した結果とする。
pが履行されたら、次の手順を並列に実行する。
1. このクライアントプラットフォーム上で現在利用可能なすべての認証器について、 optionsを入力としてcurrentUserDetails 認証器アクションを呼び出す。
pを返す。

currentUserDetails 認証器アクションはCurrentUserDetailsOptions optionsを受け取り、次のように動作する。

userIdを、 options.userIdを base64url デコードした結果とする。
表明: userIdはエラーではない。
credentialを クレデンシャルマップ[options.rpId, userId]とする。
credentialが存在しない場合、これらの手順を中止する。
credentialのotherUIを、 options.name および options.displayName に一致するよう更新する。

ユーザーがWebAuthn 依存パーティによって提供された UI 上で名前を更新する。WebAuthn 依存パーティは次を実行する。

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "aabbcc",  // ユーザーハンドル、base64url。
    name: "New user name",
    displayName: "New display name",
});

その後、認証器は、一致するクレデンシャルのotherUIを更新する。

注: signalCurrentUserDetails(options) が実行される時点で、認証器が接続されていない場合がある。したがって、WebAuthn 依存パーティは、 signalCurrentUserDetails(options) を定期的に、たとえばサインインのたびに実行することを選択してもよい。

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

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

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

clientDataJSON, 型は ArrayBuffer、readonly: この属性には、クライアントデータのJSON 互換シリアル化が含まれる。そのハッシュは、クライアントがcreate() またはget() のいずれかを呼び出す際に認証器へ渡される（すなわち、クライアントデータそのものは認証器へ送信されない）。

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

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

[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 シリアル化を保持しなければならない（MUST）。
attestationObject, 型は ArrayBuffer、readonly: この属性にはアテステーションオブジェクトが含まれる。これはクライアントには不透明であり、クライアントによる改ざんに対して暗号学的に保護されている。アテステーションオブジェクトには、認証器データとアテステーションステートメントの両方が含まれる。前者には 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 のメンバーであるべきだが（SHOULD）、依存パーティは未知の値を受け入れて保存するべきである（SHOULD）。

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

[[Create]](origin, options, sameOriginWithAncestors) メソッドのすべての利用者は、将来の認証アサーションを検証するため、返されたクレデンシャル公開鍵を解析して保存する必要がある。しかし、クレデンシャル公開鍵は COSE 形式[RFC9052]であり、認証器データ内の attestedCredentialDataの credentialPublicKeyメンバー内にあり、さらにそれはAuthenticatorAttestationResponse.attestationObjectによって伝達されるアテステーションオブジェクト内にある。アテステーションを使用しようとする依存パーティは、 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 でない値を返せなければならない（MUST）。

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

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

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

依存パーティは、これらの関数を使用する前に 'getPublicKey' in AuthenticatorAttestationResponse.prototypeの値をテストして、機能検出を行うべきである（SHOULD）。

注: getPublicKey() およびgetAuthenticatorData() は、この仕様のレベル 2 で初めて追加された。これらの関数が存在することを要求する依存パーティは、古いユーザーエージェントと相互運用できない可能性がある。

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

AuthenticatorAssertionResponse インターフェースは、WebAuthn 依存パーティのチャレンジと、認識しているクレデンシャルの任意（OPTIONAL）の一覧を与えられた場合に、新しい認証アサーションを生成するというクライアントの要求に対する認証器の応答を表す。この応答には、クレデンシャル秘密鍵を所有していることを証明する暗号署名と、任意で、特定の取引に対するユーザーの同意の証拠が含まれる。

[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 シリアル化を保持しなければならない（MUST）。
authenticatorData, 型は ArrayBuffer、readonly: この属性には、認証器から返された認証器データが含まれる。 § 6.1 認証器データを参照すること。
signature, 型は ArrayBuffer、readonly: この属性には、認証器から返された生の署名が含まれる。§ 6.3.3 authenticatorGetAssertion 操作を参照すること。
userHandle, 型は ArrayBuffer、readonly、nullable: この属性には、認証器から返されたユーザーハンドルが含まれ、認証器がユーザーハンドルを返さなかった場合は null となる。 § 6.3.3 authenticatorGetAssertion 操作を参照すること。認証セレモニーで使用されたallowCredentials オプションが空の場合、認証器は常にユーザーハンドルを返さなければならず（MUST）、それ以外の場合は返してもよい（MAY）。

5.3. クレデンシャル生成のためのパラメーター（辞書 `PublicKeyCredentialParameters`）

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

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

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

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

5.4. クレデンシャル作成のためのオプション（辞書 `PublicKeyCredentialCreationOptions`）

dictionary PublicKeyCredentialCreationOptions {
    required PublicKeyCredentialRpEntity         rp;
    required PublicKeyCredentialUserEntity       user;

    required BufferSource                             challenge;
    required sequence<PublicKeyCredentialParameters>  pubKeyCredParams;

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

rp, 型は PublicKeyCredentialRpEntity

このメンバーには、要求を担当する依存パーティの名前と識別子が含まれる。

その値のname メンバーは必須（REQUIRED）である。詳細については§ 5.4.1 公開鍵エンティティの記述（辞書 PublicKeyCredentialEntity）を参照すること。

その値のid メンバーは、クレデンシャルをスコープ設定するRP IDを指定する。省略された場合、その値はCredentialsContainer オブジェクトの関連設定オブジェクトのオリジンの有効ドメインとなる。詳細については§ 5.4.2 クレデンシャル生成のための依存パーティパラメーター（辞書 PublicKeyCredentialRpEntity）を参照すること。

user, 型は PublicKeyCredentialUserEntity

このメンバーには、登録を実行するユーザーアカウントの名前と識別子が含まれる。

その値のname、 displayName および id メンバーは必須（REQUIRED）である。 id は、将来の一部の認証セレモニーでuserHandle として返される場合があり、同じ認証器上で同じ rp.id および user.id を持つ既存の発見可能なクレデンシャルを上書きするために使用される。 name およびdisplayName は、将来の認証セレモニーで、ユーザーがクレデンシャルを選択するのを支援するために、認証器およびクライアントによって使用されてもよい（MAY）が、将来の認証セレモニーの結果として依存パーティへ返されることはない。

詳細については、§ 5.4.1 公開鍵エンティティの記述（辞書 PublicKeyCredentialEntity）および§ 5.4.3 クレデンシャル生成のためのユーザーアカウントパラメーター（辞書 PublicKeyCredentialUserEntity）を参照すること。

challenge, 型は BufferSource

このメンバーは、新しく作成されたクレデンシャルのアテステーションオブジェクトを生成する際に、認証器が他のデータとともに署名するチャレンジを指定する。認証器。 § 13.5.3 暗号学的チャレンジのセキュリティ上の考慮事項を参照すること。

pubKeyCredParams, 型は sequence<PublicKeyCredentialParameters>

このメンバーは、依存パーティがサポートする鍵の種類と署名アルゴリズムを、最も優先されるものから最も優先されないものの順に列挙する。重複は許可されるが、実質的には無視される。クライアントと認証器は、可能な限り最も優先される型のクレデンシャルを作成するよう最善を尽くす。列挙された型のいずれも作成できない場合、create() 操作は失敗する。

広範な認証器をサポートしたい依存パーティは、少なくとも次のCOSEAlgorithmIdentifier 値を含めるべきである（SHOULD）。

-8 (EdDSA)
-7 (ES256)
-257 (RS256)

必要に応じて追加の署名アルゴリズムを含めることができる。

[RFC9864] によって導入された次の完全指定COSEAlgorithmIdentifier 値は、 pubKeyCredParamsでは推奨されない（NOT RECOMMENDED）。

-9 (ESP256)。代わりに、または追加で -7 (ES256) を使用する。
-51 (ESP384)。代わりに、または追加で -35 (ES384) を使用する。
-52 (ESP512)。代わりに、または追加で -36 (ES512) を使用する。
-19 (Ed25519)。代わりに、または追加で -8 (EdDSA) を使用する。

注: WebAuthn 内では、値 -9 (ESP256)、-51 (ESP384)、-52 (ESP512)、および -19 (Ed25519) は、 § 5.8.5 暗号アルゴリズム識別子（typedef COSEAlgorithmIdentifier）に記載された追加の制約により、それぞれ -7 (ES256)、-35 (ES384)、-36 (ES512)、および -8 (EdDSA) と同じものを表す。しかし、多くの実装が後者の識別子をサポートする一方で前者はサポートしないため、実際には相互置換できない。したがって、後方互換性のため、pubKeyCredParamsでは後者の識別子が優先される。

timeout, 型は unsigned long

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

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

依存パーティは、この任意（OPTIONAL）のメンバーを使用して、このユーザーアカウント（user.idによって識別される）に対応付けられた既存のクレデンシャルを列挙するべきである（SHOULD）。これにより、新しいクレデンシャルが、このユーザーアカウントに対応付けられたクレデンシャルをすでに含む認証器上に作成されることを防ぐ。そのようになる場合、クライアントには、代わりに別の認証器を使用するようユーザーを案内するか、それに失敗した場合はエラーを返すことが要求される。

authenticatorSelection, 型は AuthenticatorSelectionCriteria

依存パーティは、この任意（OPTIONAL）のメンバーを使用して、 create() 操作に参加するために認証器が満たさなければならない（MUST）、または満たすべき（SHOULD）能力および設定を指定してもよい（MAY）。 § 5.4.4 認証器選択基準（辞書 AuthenticatorSelectionCriteria）を参照すること。

hints, 型は sequence<DOMString>、既定値は []

この任意（OPTIONAL）のメンバーには、ユーザーエージェントがユーザーと対話する際のガイドとなる、PublicKeyCredentialHint の 0 個以上の要素が含まれる。要素はその列挙型から取得されるにもかかわらず、型がDOMStringであることに注意すること。§ 2.1.1 DOMString 型としての列挙を参照すること。

attestation, 型は DOMString、既定値は "none"

依存パーティは、この任意（OPTIONAL）のメンバーを使用して、アテステーション伝達に関する選好を指定してもよい（MAY）。その値はAttestationConveyancePreferenceのメンバーであるべきである（SHOULD）。クライアントプラットフォームは未知の値を無視し、未知の値をメンバーが存在しないかのように扱わなければならない（MUST）。

既定値はnoneである。

attestationFormats, 型は sequence<DOMString>、既定値は []

依存パーティは、この任意（OPTIONAL）のメンバーを使用して、認証器が使用するアテステーションステートメント形式に関する選好を指定してもよい（MAY）。値は、[RFC8809]によって確立された IANA "WebAuthn Attestation Statement Format Identifiers" レジストリ[IANA-WebAuthn-Registries]から取得するべきである（SHOULD）。値は最も優先されるものから最も優先されないものの順に並べられる。重複は許可されるが、実質的には無視される。このパラメーターは助言的なものであり、認証器は、このパラメーターに列挙されていないアテステーションステートメントを使用してもよい（MAY）。

既定値は空のリストであり、選好がないことを示す。

extensions, 型は AuthenticationExtensionsClientInputs

依存パーティは、この任意（OPTIONAL）のメンバーを使用して、クライアントおよび認証器による追加処理を要求するクライアント拡張入力を提供してもよい（MAY）。たとえば、依存パーティは、作成されたクレデンシャルに関する追加情報をクライアントが返すよう要求してもよい。

拡張フレームワークは§ 9 WebAuthn 拡張で定義される。一部の拡張は§ 10 定義済み拡張で定義されている。登録済みの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."、または "ОАО Примертех"。

このメンバーは、多くのクライアントが表示しないため非推奨となっているが、後方互換性のため、引き続き必須の辞書メンバーである。依存パーティは、安全な既定値として、これをRP IDと等しく設定してもよい（MAY）。
- 依存パーティは、 nameの値を設定する際、またはその値をユーザーに表示する際に、 PRECIS FreeformClass [RFC8264]の Nickname Profile について、 [RFC8266] の第 2.3 節で規定されているとおりに適用処理を行うべきである（SHOULD）。
- クライアントは、 nameの値をユーザーに表示する前、またはauthenticatorMakeCredential 操作のパラメーターとして含める前に、 PRECIS FreeformClass [RFC8264]の Nickname Profile について、 [RFC8266] の第 2.3 節で規定されているとおりに適用処理を行うべきである（SHOULD）。
PublicKeyCredentialUserEntityに継承された場合、これはユーザーアカウントの人間にとって扱いやすい識別子である。この識別子は、クレデンシャルがどのユーザーアカウントに関連付けられているかをユーザーが理解するのを助けるために、クライアントがユーザーに表示する主要な値である。

この識別子に適した値の例には、"alexm"、"+14255551234"、 "alex.mueller@example.com"、"alex.mueller@example.com (prod-env)"、または "alex.mueller@example.com (ОАО Примертех)" が含まれる。
- 依存パーティは、ユーザーにこの値を選択させてもよい（MAY）。依存パーティは、 nameの値を設定する際、またはその値をユーザーに表示する際に、PRECIS IdentifierClass [RFC8264]の UsernameCasePreserved Profile について、[RFC8265] の第 3.4.3 節で規定されているとおりに適用処理を行うべきである（SHOULD）。
- クライアントは、 nameの値をユーザーに表示する前、またはauthenticatorMakeCredential 操作のパラメーターとして含める前に、 PRECIS IdentifierClass [RFC8264]の UsernameCasePreserved Profile について、[RFC8265] の第 3.4.3 節で規定されているとおりに適用処理を行うべきである（SHOULD）。

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

name メンバーの値を保存する際、値は 64 バイト以上のサイズ制限を使用して、§ 6.4.1 文字列の切り詰めで説明されているように切り詰めてもよい（MAY）。

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 メンバーに基づいて行わなければならず（MUST）、 displayName またはname メンバーに基づいてはならない。[RFC8266]の第 6.1 節を参照すること。

ユーザーハンドルには、ユーザー名や電子メールアドレスなど、ユーザーを個人識別する情報を含めてはならない（MUST NOT）。詳細については§ 14.6.1 ユーザーハンドルの内容を参照すること。ユーザーハンドルは空であってはならない（MUST NOT）。

ユーザーハンドルは、異なるユーザーアカウント間で一定の値にするべきではない（SHOULD NOT）。これは発見不能なクレデンシャルであっても同様であり、一部の認証器は常に発見可能なクレデンシャルを作成するためである。したがって、一定のユーザーハンドルを使用すると、ユーザーはそのような認証器を依存パーティで複数のユーザーアカウントに使用できなくなる。

displayName, 型は DOMString

ユーザーアカウントの、表示のみを目的とした人間にとって扱いやすい名前。依存パーティはユーザーにこれを選択させるべきであり（SHOULD）、必要以上に選択を制限するべきではない（SHOULD NOT）。適切な、または人間にとって扱いやすい名前が利用できない場合、依存パーティはこの値を空文字列に設定するべきである（SHOULD）。

この識別子に適した値の例には、"Alex Müller"、"Alex Müller (ACME Co.)" または "田中倫" が含まれる。

依存パーティは、displayNameの値を空でない文字列に設定する際、または空でない値をユーザーに表示する際に、 PRECIS FreeformClass [RFC8264]の Nickname Profile について、 [RFC8266] の第 2.3 節で規定されているとおりに適用処理を行うべきである（SHOULD）。
クライアントは、 displayNameの値を空でない値としてユーザーに表示する前、または空でない値をauthenticatorMakeCredential操作のパラメーターとして含める前に、 PRECIS FreeformClass [RFC8264]の Nickname Profile について、 [RFC8266] の第 2.3 節で規定されているとおりに適用処理を行うべきである（SHOULD）。

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

displayName メンバーの値を保存する際、値は 64 バイト以上のサイズ制限を使用して、§ 6.4.1 文字列の切り詰めで説明されているように切り詰めてもよい（MAY）。

5.4.4. 認証器選択基準（辞書 `AuthenticatorSelectionCriteria`）

WebAuthn 依存パーティは、AuthenticatorSelectionCriteria 辞書を使用して、認証器の属性に関する要件を指定してもよい。

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

authenticatorAttachment, 型は DOMString

このメンバーが存在する場合、適格な認証器は、指定された認証器アタッチメントモダリティで接続された認証器のみに絞り込まれる（§ 6.2.1 認証器アタッチメントモダリティも参照）。このメンバーが存在しない場合、どのアタッチメントモダリティも許容される。値はAuthenticatorAttachment のメンバーであるべきだが（SHOULD）、クライアントプラットフォームは未知の値を無視し、未知の値をメンバーが存在しないかのように扱わなければならない（MUST）。

PublicKeyCredentialのauthenticatorAttachment メンバーも参照すること。これは、成功したcreate() またはget() 操作で、どの認証器アタッチメントモダリティが使用されたかを示すことができる。

residentKey, 型は DOMString

依存パーティがクライアント側で発見可能なクレデンシャルを作成することをどの程度望むかを指定する。歴史的な理由により、名称には非推奨の “resident” という用語が保持されている。値は ResidentKeyRequirement のメンバーであるべきだが（SHOULD）、クライアントプラットフォームは未知の値を無視し、未知の値をメンバーが存在しないかのように扱わなければならない（MUST）。値が指定されない場合、 requireResidentKey がtrueなら有効値はrequired、 falseまたは存在しない場合はdiscouragedとなる。

ResidentKeyRequirement に、residentKeyの値とセマンティクスの説明がある。

requireResidentKey, 型は boolean、既定値は false

このメンバーは WebAuthn レベル 1 との後方互換性のために保持されており、歴史的な理由により、その名称には発見可能なクレデンシャルに対する非推奨の “resident” という用語が保持されている。依存パーティは、residentKey がrequiredに設定されている場合に限り、これをtrueに設定するべきである（SHOULD）。

userVerification, 型は DOMString、既定値は "preferred"

このメンバーは、 create() 操作におけるユーザー検証に関する依存パーティの要件を指定する。値はUserVerificationRequirement のメンバーであるべきだが（SHOULD）、クライアントプラットフォームは未知の値を無視し、未知の値をメンバーが存在しないかのように扱わなければならない（MUST）。

UserVerificationRequirement に、userVerificationの値とセマンティクスの説明がある。

5.4.5. 認証器アタッチメント列挙（列挙型 `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) 操作には認証器アタッチメントモダリティ選択オプションはない。クライアントとユーザーは、 allowCredentials オプションを条件として、その時点で利用可能かつ便利なクレデンシャルを使用する。

5.4.6. 常駐キー要件列挙（列挙型 `ResidentKeyRequirement`）

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

注: ResidentKeyRequirement 列挙型は意図的に参照されていない。§ 2.1.1 DOMString 型としての列挙を参照すること。

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

discouraged

依存パーティは、サーバー側クレデンシャルの作成を優先するが、クライアント側で発見可能なクレデンシャルも受け入れる。クライアントと認証器は、可能であればサーバー側クレデンシャルを作成するべきである（SHOULD）。

注: 依存パーティは、作成されるクレデンシャルがサーバー側クレデンシャルであることを要求できず、クレデンシャルプロパティ拡張はrk プロパティの値を返さない場合がある。このため、クレデンシャルがサーバー側クレデンシャルであるかどうかを把握できず、したがって同じユーザーハンドルで 2 つ目のクレデンシャルを作成すると最初のものが追い出されるかどうかも把握できない場合がある。

preferred

依存パーティは、クライアント側で発見可能なクレデンシャルの作成を強く優先するが、サーバー側クレデンシャルも受け入れる。クライアントと認証器は、可能であれば発見可能なクレデンシャルを作成するべきである（SHOULD）。たとえば、クライアントは、発見可能なクレデンシャルを作成するために必要な場合、ユーザー検証の設定をユーザーに案内するべきである（SHOULD）。これはuserVerificationの設定より優先される。

required

依存パーティは、クライアント側で発見可能なクレデンシャルを要求する。クライアントは、クライアント側で発見可能なクレデンシャルを作成できない場合、エラーを返さなければならない（MUST）。

注: 依存パーティは、クレデンシャルプロパティ拡張の常駐キークレデンシャルプロパティを使用して、認証器がクライアント側で発見可能なクレデンシャルを作成したかどうかに関する情報を得ることができる。これは、 options.authenticatorSelection.residentKey にdiscouraged またはpreferred の値を使用する場合に有用である。なぜなら、その場合、認証器は、クライアント側で発見可能なクレデンシャルまたはサーバー側クレデンシャルのいずれかを作成する可能性があるためである。

5.4.7. アテステーション伝達設定列挙（列挙型 `AttestationConveyancePreference`）

WebAuthn 依存パーティは、クレデンシャル生成中のアテステーション伝達に関する選好を指定するためにAttestationConveyancePreference を使用してもよい。

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

注: AttestationConveyancePreference 列挙型は意図的に参照されていない。§ 2.1.1 DOMString 型としての列挙を参照すること。

none

依存パーティは、認証器のアテステーションに関心がない。たとえば、識別情報を依存パーティへ中継するためのユーザーの同意を得る必要性を回避できる可能性があるため、またはアテステーション CAや匿名化 CAへのラウンドトリップを省くためである。認証器が自己アテステーションではないアテステーションステートメントを生成した場合、クライアントはそれを None アテステーションステートメントに置き換える。

これが既定値であり、未知の値はこの値の動作にフォールバックする。

indirect

依存パーティは、検証可能なアテステーションステートメントを受け取りたいが、そのようなアテステーションステートメントをどのように取得するかはクライアントに決定させる。クライアントは、ユーザーのプライバシーを保護するため、または異種混在エコシステムにおけるアテステーション検証で依存パーティを支援するため、認証器が生成したアテステーションステートメントを匿名化 CAが生成したものに置き換えてもよい（MAY）。

注: この場合、依存パーティが検証可能なアテステーションステートメントを取得できる保証はない。たとえば、認証器が自己アテステーションを使用し、クライアントがアテステーションステートメントを変更せずそのまま渡す場合である。

direct

依存パーティは、認証器が生成したままのアテステーションステートメントを受け取りたい。

enterprise

依存パーティは、認証器を一意に識別する情報を含む可能性のあるアテステーションステートメントである、エンタープライズアテステーションを受け取りたい。これは、組織が登録を特定の認証器に結び付けたい企業内の管理された配備を対象としている。ユーザーエージェントは、要求されたRP IDについてユーザーエージェントまたは認証器の設定が許可していない限り、このようなアテステーションを提供してはならない（MUST NOT）。

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

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

PublicKeyCredentialRequestOptions 辞書は、アサーションを生成するために必要なデータをget() に提供する。そのchallenge メンバーは存在しなければならず（MUST）、その他のメンバーは任意（OPTIONAL）である。

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

challenge, 型は BufferSource

このメンバーは、認証器が認証アサーションを生成する際に、他のデータとともに署名するチャレンジを指定する。§ 13.5.3 暗号学的チャレンジのセキュリティ上の考慮事項を参照すること。

timeout, 型は unsigned long

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

rpId, 型は DOMString

この任意（OPTIONAL）のメンバーは、依存パーティが主張するRP IDを指定する。クライアントは、依存パーティのオリジンが、このRP IDのスコープと一致することを検証しなければならない（MUST）。認証器は、このRP IDが認証セレモニーで使用されるクレデンシャルのrpIdと完全に等しいことを検証しなければならない（MUST）。

指定されていない場合、その値は CredentialsContainer オブジェクトの関連設定オブジェクトのオリジンの有効ドメインとなる。

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

この任意（OPTIONAL）のメンバーは、この認証セレモニーに適格な認証器をクライアントが見つけるために使用される。これは次の 2 つの方法で使用できる。

認証するユーザーアカウントがすでに識別されている場合（たとえば、ユーザーがユーザー名を入力した場合）、依存パーティは、このメンバーを使用して、ユーザーアカウント内のクレデンシャルレコードのクレデンシャル記述子を列挙するべきである（SHOULD）。通常、これにはユーザーアカウント内のすべてのクレデンシャルレコードを含めるべきである（SHOULD）。

項目は、可能な限りtransports を指定するべきである（SHOULD）。これにより、クライアントは、その状況に応じたユーザーエクスペリエンスを最適化しやすくなる。また、ユーザー検証を要求する際、依存パーティが一覧をフィルタリングする必要はないことにも注意すること — userVerification がrequiredに設定されている場合、クライアントは適格でないクレデンシャルを自動的に無視する。

§ 14.6.3 クレデンシャル ID を介したプライバシー漏えいのプライバシー上の考慮事項も参照すること。
認証するユーザーアカウントがまだ識別されていない場合、依存パーティは、このメンバーを空のままにするか、指定しなくてもよい（MAY）。この場合、この認証セレモニーでは発見可能なクレデンシャルのみが使用され、結果として得られるAuthenticatorAssertionResponseの userHandle によってユーザーアカウントを識別してもよい（MAY）。利用可能な認証器が、依存パーティにスコープ設定された複数の発見可能なクレデンシャルを含む場合、クレデンシャルは、ユーザーが選択できるようクライアントプラットフォームまたは認証器によって表示される（手順 7、 § 6.3.3 authenticatorGetAssertion 操作を参照）。

空でない場合、列挙されたクレデンシャルのいずれも使用できなければ、クライアントはエラーを返さなければならない（MUST）。

この一覧は優先度の高い順に並べられる。一覧の最初の項目が最も優先されるクレデンシャルであり、最後の項目が最も優先度の低いクレデンシャルである。

userVerification, 型は DOMString、既定値は "preferred"

この任意（OPTIONAL）のメンバーは、 get() 操作におけるユーザー検証に関する依存パーティの要件を指定する。値はUserVerificationRequirement のメンバーであるべきだが（SHOULD）、クライアントプラットフォームは未知の値を無視し、未知の値をメンバーが存在しないかのように扱わなければならない（MUST）。適格な認証器は、この要件を満たす能力を持つものだけに絞り込まれる。

UserVerificationRequirement に、userVerificationの値とセマンティクスの説明がある。

hints, 型は sequence<DOMString>、既定値は []

この任意（OPTIONAL）のメンバーには、ユーザーエージェントがユーザーと対話する際のガイドとなる、 PublicKeyCredentialHint の 0 個以上の要素が含まれる。要素はその列挙型から取得されるにもかかわらず、型がDOMStringであることに注意すること。§ 2.1.1 DOMString 型としての列挙を参照すること。

extensions, 型は AuthenticationExtensionsClientInputs

依存パーティは、この任意（OPTIONAL）のメンバーを使用して、クライアントおよび認証器による追加処理を要求するクライアント拡張入力を提供してもよい（MAY）。

拡張フレームワークは§ 9 WebAuthn 拡張で定義される。一部の拡張は§ 10 定義済み拡張で定義されている。登録済みのWebAuthn 拡張の最新一覧については、 [RFC8809]によって確立された IANA "WebAuthn Extension Identifiers" レジストリ[IANA-WebAuthn-Registries]を参照すること。

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 は、AbortSignal が中止済みになったら、直ちに Promise を拒否しなければならないと規定している。 [[Create]](origin, options, sameOriginWithAncestors) および[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) メソッドの複雑な継承および並列化構造を考慮し、2 つの API のアルゴリズムは、中止済みプロパティを 3 箇所で確認することでこの要件を満たす。 [[Create]](origin, options, sameOriginWithAncestors) の場合、中止済みプロパティは、まず Credential Management 1 § 2.5.4 クレデンシャルの作成で[[Create]](origin, options, sameOriginWithAncestors)を呼び出す直前に、次に§ 5.1.3 新しいクレデンシャルを作成する - PublicKeyCredential の [[Create]](origin, options, sameOriginWithAncestors) 内部メソッドで認証器セッションが開始する直前に、そして最後に認証器セッション中に確認される。[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) についても同様である。

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;
    DOMString                    topOrigin;
};

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

enum TokenBindingStatus { "present", "supported" };

type, 型は DOMString

このメンバーは、新しいクレデンシャルを作成する場合には文字列 "webauthn.create" を、既存のクレデンシャルからアサーションを取得する場合には "webauthn.get" を含む。このメンバーの目的は、特定の種類の署名混同攻撃（攻撃者が正当な署名を別の正当な署名と置き換える攻撃）を防ぐことである。

challenge, 型は DOMString

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

origin, 型は DOMString

このメンバーには、クライアントによって認証器へ提供された要求元の完全修飾オリジンが、[RFC6454]で定義された構文で含まれる。

crossOrigin, 型は boolean

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

topOrigin, 型は DOMString

この任意（OPTIONAL）のメンバーには、要求元の完全修飾トップレベルオリジンが、 [RFC6454]で定義された構文で含まれる。これは、呼び出しがその祖先と同一オリジンではないコンテキストから行われた場合、すなわちcrossOrigin がtrueの場合にのみ設定される。

[予約済み] tokenBinding

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

注: Token Bindingは WebAuthn のレベル 1 およびレベル 2 には存在したが、レベル 3 では使用されないことが想定されている。tokenBindingフィールドは、別の目的で再利用されないよう予約されている。

status, 型は DOMString

このメンバーはTokenBindingStatus のメンバーであるべきだが（SHOULD）、クライアントプラットフォームは未知の値を無視し、未知の値をtokenBindingのメンバーが存在しないかのように扱わなければならない（MUST）。既知の場合、このメンバーは次のいずれかである。

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

注: TokenBindingStatus 列挙型は意図的に参照されていない。§ 2.1.1 DOMString 型としての列挙を参照すること。

id, 型は DOMString

status がpresentの場合、このメンバーは存在しなければならず（MUST）、依存パーティとの通信時に使用されたToken Binding IDのbase64url エンコーディングでなければならない（MUST）。

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

CollectedClientData 構造体は、クライアントが次の値を計算するために使用する。

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

5.8.1.1. シリアル化

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

シリアル化アルゴリズムは、最初は空である部分結果に連続するバイト文字列を追加し、完全な結果が得られるまで繰り返す。

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に追加する。
topOrigin が存在する場合:
1. 0x2c22746f704f726967696e223a (,"topOrigin":) をresultに追加する。
2. CCDToString(topOrigin) をresultに追加する。
CollectedClientData の一時的なコピーを作成し、フィールドtype、 challenge、 origin、 crossOrigin （存在する場合）、およびtopOrigin （存在する場合）を削除する。
一時的なコピーにフィールドが残っていない場合:
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. 利用可能な場合、ユーザーエージェントへ要求を発行した、期待されるtopOrigin を含む任意の文字列topOrigin。
6. topOriginが定義されており、topOrigin 属性がclientDataJSONに存在しない場合に限り検証を失敗させるなら true となる、 Boolean 値requireTopOrigin。
  
  これは、requireTopOriginがfalseである場合に限り、検証アルゴリズムが Web Authentication レベル 2 [webauthn-2-20210408]のJSON 互換シリアル化アルゴリズムと後方互換であることを意味する。
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に追加する。
topOriginが定義されている場合:
1. 0x74727565 (true) をexpectedに追加する。
2. requireTopOriginが true であるか、 0x2c22746f704f726967696e223a (,"topOrigin":) が、 expectedの長さと等しいオフセットから始まるclientDataJSONの部分文字列のプレフィックスである場合:
  1. 0x2c22746f704f726967696e223a (,"topOrigin":) を expectedに追加する。
  2. CCDToString(topOrigin) を expectedに追加する。
それ以外の場合、すなわちtopOriginが定義されていない場合:
1. 0x66616c7365 (false) をexpectedに追加する。
expectedがclientDataJSONのプレフィックスでない場合、検証は失敗する。
clientDataJSONがexpectedより少なくとも 1 バイト長くない場合、検証は失敗する。
expectedの長さと等しいオフセットにあるclientDataJSONのバイトが:

0x7d である

検証は成功する。

0x2c である

検証は成功する。

それ以外

検証は失敗する。

5.8.1.3. 将来の発展

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

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

5.8.2. クレデンシャル型列挙（列挙型 `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() では、そのクレデンシャルに現在クライアントが到達できるか、およびどのように到達できるかを判定するために使用される。

クレデンシャルレコードのクレデンシャル記述子は、そのクレデンシャルレコードのプロパティの一部であり、 create() およびget()によって返される PublicKeyCredential オブジェクトの一部のフィールドを反映する。

type, 型は DOMString

このメンバーには、呼び出し元が参照している公開鍵クレデンシャルの型が含まれる。値はPublicKeyCredentialType のメンバーであるべきだが（SHOULD）、クライアントプラットフォームは、未知のtypeを持つすべてのPublicKeyCredentialDescriptor を無視しなければならない（MUST）。ただし、未知のtypeのためにすべての要素が無視された場合、空のallowCredentials は意味的に異なるため、エラーにならなければならない（MUST）。

これは、識別された公開鍵クレデンシャルソースを表すクレデンシャルレコードのtype項目の値に設定するべきである（SHOULD）。これはPublicKeyCredentialの type フィールドを反映する。

id, 型は BufferSource

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

これは、識別された公開鍵クレデンシャルソースを表すクレデンシャルレコードのid項目の値に設定するべきである（SHOULD）。これはPublicKeyCredentialの rawId フィールドを反映する。

transports, 型は sequence<DOMString>

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

これは、識別された公開鍵クレデンシャルソースを表すクレデンシャルレコードのtransports項目の値に設定するべきである（SHOULD）。これは、create() 操作によって作成されたPublicKeyCredential 構造体の response.getTransports() メソッドを反映する。

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

enum AuthenticatorTransport {
    "usb",
    "nfc",
    "ble",
    "smart-card",
    "hybrid",
    "internal"
};

注: AuthenticatorTransport 列挙型は意図的に参照されていない。§ 2.1.1 DOMString 型としての列挙を参照すること。

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

usb: 対応する認証器に着脱可能な USB 経由で接続できることを示す。
nfc: 対応する認証器に近距離無線通信（NFC）経由で接続できることを示す。
ble: 対応する認証器に Bluetooth Smart （Bluetooth Low Energy / BLE）経由で接続できることを示す。
smart-card: 対応する認証器に、接点を持つ ISO/IEC 7816 スマートカード経由で接続できることを示す。
hybrid: 対応する認証器に、（多くの場合は別個の）データトランスポートと近接性メカニズムの組み合わせを使用して接続できることを示す。これは、たとえばスマートフォンを使用してデスクトップコンピューターで認証することをサポートする。
internal: 対応する認証器にクライアントデバイス固有のトランスポートを使用して接続すること、すなわちプラットフォーム認証器であることを示す。これらの認証器はクライアントデバイスから取り外すことができない。

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

typedef long COSEAlgorithmIdentifier;

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

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

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

これらの制限は、[RFC9053]の第 2.1 節の推奨事項に沿っている。

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

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

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

WebAuthn 依存パーティは、一部の操作ではユーザー検証を要求し、他の操作では要求しない場合があり、この型を使用してその要件を表現できる。

注: UserVerificationRequirement 列挙型は意図的に参照されていない。§ 2.1.1 DOMString 型としての列挙を参照すること。

required: 依存パーティは、操作にユーザー検証を要求し、応答でUV フラグが設定されていない場合、セレモニー全体を失敗させる。クライアントは、ユーザー検証を実行できない場合、エラーを返さなければならない（MUST）。
preferred: 依存パーティは、可能であれば操作にユーザー検証を行うことを望むが、応答でUV フラグが設定されていなくても操作を失敗させない。
discouraged: 依存パーティは、操作中にユーザー検証を使用することを望まない（たとえば、ユーザー対話フローへの中断を最小限に抑えるため）。

5.8.7. クライアント機能列挙（列挙型 `ClientCapability`）

enum ClientCapability {
    "conditionalCreate",
    "conditionalGet",
    "hybridTransport",
    "passkeyPlatformAuthenticator",
    "userVerifyingPlatformAuthenticator",
    "relatedOrigins",
    "signalAllAcceptedCredentials",
    "signalCurrentUserDetails",
    "signalUnknownCredential"
};

この列挙型は、WebAuthn 依存パーティがユーザーに特定のワークフローおよびエクスペリエンスを提供するために評価できる、限定された一連のクライアント機能を定義する。

依存パーティは、 PublicKeyCredentialの getClientCapabilities() メソッドを使用して、利用可能な機能の説明を取得できる。

注: ClientCapability 列挙型は意図的に参照されていない。§ 2.1.1 DOMString 型としての列挙を参照すること。

conditionalCreate

WebAuthn クライアントが登録セレモニーでconditional 仲介を実行できる。

詳細については、§ 5.1.3 新しいクレデンシャルを作成する - PublicKeyCredential の [[Create]](origin, options, sameOriginWithAncestors) 内部メソッドを参照すること。

conditionalGet

WebAuthn クライアントが認証セレモニーでconditional 仲介を実行できる。

この機能は、isConditionalMediationAvailable() がtrueで解決されることと同等である。

詳細については、§ 5.1.4 既存のクレデンシャルを使用してアサーションを作成するを参照すること。

hybridTransport

WebAuthn クライアントがhybrid トランスポートの使用をサポートする。

passkeyPlatformAuthenticator

WebAuthn クライアントが、ローカルおよび/またはhybrid トランスポート経由でパスキープラットフォーム認証器の使用をサポートする。

userVerifyingPlatformAuthenticator

WebAuthn クライアントがユーザー検証対応プラットフォーム認証器の使用をサポートする。

relatedOrigins

WebAuthn クライアントが関連オリジン要求をサポートする。

signalAllAcceptedCredentials

WebAuthn クライアントがsignalAllAcceptedCredentials()をサポートする。

signalCurrentUserDetails,

WebAuthn クライアントがsignalCurrentUserDetails()をサポートする。

signalUnknownCredential

WebAuthn クライアントがsignalUnknownCredential()をサポートする。

5.8.8. ユーザーエージェントヒント列挙（列挙型 `PublicKeyCredentialHint`）

enum PublicKeyCredentialHint {
    "security-key",
    "client-device",
    "hybrid",
};

注: PublicKeyCredentialHint 列挙型は意図的に参照されていない。§ 2.1.1 DOMString 型としての列挙を参照すること。

WebAuthn 依存パーティは、この列挙型を使用して、要求をどのように完了するのが最善かについてのヒントをユーザーエージェントに伝えてもよい。これらのヒントは要件ではなく、ユーザーエージェントを拘束しないが、依存パーティが要求について持つコンテキスト情報を利用して、最善のエクスペリエンスを提供するようユーザーエージェントを導く場合がある。ヒントは優先度の高い順に提供されるため、 2 つのヒントが矛盾する場合は最初のものが優先される。ヒントは重複する場合もある。より具体的なヒントが定義されている場合でも、依存パーティは、その具体的なヒントを認識しない可能性があるユーザーエージェントのために、より一般的なヒントも送信したい場合がある。この場合、最も具体的なヒントを、より一般的なものより前に送信するべきである。同じヒントが複数回現れる場合、2 回目以降は無視される。

ヒントは、クレデンシャルのtransports およびauthenticatorAttachment に含まれる情報と矛盾してもよい（MAY）。その場合、ヒントが優先される。（発見可能なクレデンシャルを使用する場合、transports 値は提供されず、そのような要求の一部の側面を表現する唯一の手段がヒントになることに注意すること。）

security-key

依存パーティが、ユーザーは物理的なセキュリティキーでこの要求を満たすと考えていることを示す。たとえば、企業の依存パーティは、従業員にセキュリティキーを発行しており、登録および認証にはそれらの認証器のみを受け入れる場合、このヒントを設定してもよい。

古いユーザーエージェントとの互換性のため、このヒントをPublicKeyCredentialCreationOptionsで使用する場合、 authenticatorAttachment をcross-platformに設定するべきである（SHOULD）。

client-device

依存パーティが、ユーザーはクライアントデバイスに接続されたプラットフォーム認証器でこの要求を満たすと考えていることを示す。

古いユーザーエージェントとの互換性のため、このヒントをPublicKeyCredentialCreationOptionsで使用する場合、 authenticatorAttachment をplatformに設定するべきである（SHOULD）。

hybrid

依存パーティが、ユーザーはスマートフォンなどの汎用認証器でこの要求を満たすと考えていることを示す。たとえば、消費者向けの依存パーティは、専用のセキュリティキーを所有する顧客はごく一部であると考える場合がある。このオプションは、ローカルのプラットフォーム認証器を UI で優先的に提示するべきではないことも意味する。

5.9. Permissions Policy との統合

この仕様は 3 つのポリシー制御機能 [Permissions-Policy]を定義する。

2 つの機能は、機能識別子トークン "publickey-credentials-create" および "publickey-credentials-get" によって識別される。それらの既定の許可リストはいずれも 'self' である。

3 番目の機能は、機能識別子トークン "publickey-credentials-remote-client-data-json" によって識別される。その既定の許可リストは 'none' であり、既定ですべてのオリジンに対して無効であることを意味する。この機能は、名前 "publickey-credentials-remote-client-data-json"で識別される強力な機能（[Permissions]）でもあり、既定の許可状態は"denied"である。

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

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

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

Web Authentication APIは、クロスオリジンの iframeでは既定で無効である。この既定のポリシーを上書きし、クロスオリジンの iframe がWeb Authentication APIの [[Create]](origin, options, sameOriginWithAncestors) および[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) メソッドを呼び出すことを許可されていることを示すには、 iframe 要素に allow 属性を指定し、それぞれ publickey-credentials-create または publickey-credentials-get 機能識別子トークンを allow 属性の値に含める。

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

WebAuthn クライアントおよびクライアントプラットフォームは、追加のプライバシー上の考慮事項について§ 14.5.5 WebAuthn クレデンシャルのクロスオリジンでの使用を参照するべきである。

既定では、Web Authentication は、RP IDがオリジンの有効ドメインと等しいか、そのオリジンの有効ドメインの登録可能ドメインサフィックスであることを要求する。

これは、複数の国別ドメインが使用される大規模な環境（例: example.com と example.co.uk と example.sg）、代替ドメインまたはブランドドメインが必要な環境（例: myexampletravel.com と examplecruises.com）、および/またはモバイルアプリをサポートするために Platform as a Service プロバイダーが使用される環境で、配備を困難にする可能性がある。

WebAuthn 依存パーティは、限定された一連の関連オリジン間でクレデンシャルを作成および使用できるようWebAuthn クライアントに許可することを選択できる。このような依存パーティは、関連オリジンからのすべてのセレモニーで使用する共通のRP IDを選択しなければならない（MUST）。

RP IDのwebauthn well-known URL [RFC8615]に JSON 文書をホストしなければならず（MUST）、 HTTPS を使用して配信しなければならない（MUST）。JSON 文書は次のように返されなければならない（MUST）。

コンテンツタイプはapplication/jsonでなければならない（MUST）。
トップレベル JSON オブジェクトにはoriginsという名前のキーを含めなければならず（MUST）、その値は Web オリジンを含む 1 個以上の文字列の配列でなければならない（MUST）。

たとえば、RP ID がexample.comの場合:

{
    "origins": [
        "https://example.co.uk",
        "https://example.de",
        "https://example.sg",
        "https://example.net",
        "https://exampledelivery.com",
        "https://exampledelivery.co.uk",
        "https://exampledelivery.de",
        "https://exampledelivery.sg",
        "https://myexamplerewards.com",
        "https://examplecars.com"
    ]
}

この機能をサポートするWebAuthn クライアントは、少なくとも 5 個の登録可能オリジンラベルをサポートしなければならない（MUST）。クライアントポリシーは、悪用を防ぐために上限を定義するべきである（SHOULD）。

WebAuthn クライアントによるこの well-known エンドポイントへの要求は、クレデンシャルなし、リファラーなしで行い、 https:スキームを使用しなければならない（MUST）。リダイレクトに従う場合、WebAuthn クライアントは、すべてのリダイレクトにもhttps:スキームの使用を明示的に要求しなければならない（MUST）。

この機能をサポートするWebAuthn クライアントは、 getClientCapabilities()への応答にrelatedOrigins を含めるべきである（SHOULD）。

5.11.1. 関連オリジンの検証

引数callerOriginおよびrpIdRequestedが与えられた関連オリジン検証手順は、次のとおりである。

maxLabelsを、クライアントポリシーによって許可される登録可能オリジンラベルの最大数とする。
RP ID rpIdRequestedのwebauthn well-known URL [RFC8615] （すなわちhttps://rpIdRequested/.well-known/webauthn）を、クレデンシャルなし、リファラーなしで、https:スキームを使用して取得する。
1. 取得が失敗した場合、応答のコンテンツタイプが application/jsonでない場合、または（リダイレクトに従った後の）ステータスコードが 200 でない場合、"SecurityError" DOMExceptionをスローする。
2. リソースの本文が有効な JSON オブジェクトでない場合、"SecurityError" DOMExceptionをスローする。
3. JSON オブジェクトのoriginsプロパティの値が存在しないか、文字列の配列でない場合、"SecurityError" DOMExceptionをスローする。
labelsSeenを新しい空の集合とする。
originsの各originItemについてそれぞれ:
1. urlを、originItemを入力としてURL パーサーを実行した結果とする。失敗した場合、続行する。
2. domainをurlの有効ドメインとする。それが null の場合、続行する。
3. labelを domainの登録可能オリジンラベルとする。
4. labelが空または null の場合、続行する。
5. labelsSeenのサイズがmaxLabels以上であり、 labelsSeenがlabelを含まない場合、続行する。
6. callerOriginとurlが同一オリジンである場合、trueを返す。
7. labelsSeenのサイズが maxLabels未満の場合、labelをlabelsSeenに追加する。
falseを返す。

6. WebAuthn 認証器モデル

Web Authentication APIは、WebAuthn 認証器について、特定の抽象的な機能モデルを前提としている。この節では、その認証器モデルについて説明する。

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

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

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

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

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

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

さらに、各認証器には Authenticator Attestation Globally Unique Identifier、すなわち AAGUID がある。これは、認証器の型（たとえば製造元やモデル）を示す 128 ビットの識別子である。AAGUID は、その製造元によって製造された実質的に同一のすべての認証器で同一となり、他のすべての型の認証器の AAGUID とは（高い確率で）異なるよう、その製造元によって選択されなければならない（MUST）。ある型の認証器の AAGUID は、これを確実にするためランダムに生成するべきである（SHOULD）。依存パーティは、他の情報源からの情報を使用して、認証レベルや鍵保護の強度など、認証器の特定の特性を推測するために AAGUID を使用してもよい（MAY）。依存パーティは、アテステーションを要求および検証せずに、認証器の製造元を識別しようとするために AAGUID を使用してもよい（MAY）が、アテステーションなしでは 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 ハッシュ。
flags	1	フラグ（ビット 0 が最下位ビット）: ビット 0: ユーザー存在（UP）の結果。 `1` はユーザーが存在することを意味する。 `0` はユーザーが存在しないことを意味する。ビット 1: 将来の使用のために予約（`RFU1`）。ビット 2: ユーザー検証済み（UV）の結果。 `1` はユーザーが検証済みであることを意味する。 `0` はユーザーが検証済みではないことを意味する。ビット 3: バックアップ適格性（BE）。 `1` は公開鍵クレデンシャルソースがバックアップ可能であることを意味する。 `0` は公開鍵クレデンシャルソースがバックアップ可能ではないことを意味する。ビット 4: バックアップ状態（BS）。 `1` は公開鍵クレデンシャルソースが現在バックアップ済みであることを意味する。 `0` は公開鍵クレデンシャルソースが現在バックアップ済みではないことを意味する。ビット 5: 将来の使用のために予約（`RFU2`）。ビット 6: アテステーション済みクレデンシャルデータを含む（AT）。認証器がアテステーション済みクレデンシャルデータを追加したかどうかを示す。ビット 7: 拡張データを含む（ED）。認証器データに拡張があるかどうかを示す。
signCount	4	署名カウンター。32 ビット符号なしビッグエンディアン整数。
attestedCredentialData	可変（存在する場合）	アテステーション済みクレデンシャルデータ（存在する場合）。詳細については§ 6.5.1 アテステーション済みクレデンシャルデータを参照すること。その長さは、アテステーション対象のクレデンシャル IDおよびクレデンシャル公開鍵の長さに依存する。
extensions	可変（存在する場合）	拡張によって定義された認証器データ。これは、キーとして拡張識別子を、値として認証器拡張出力を持つCBOR [RFC8949] マップである。詳細については§ 9 WebAuthn 拡張を参照すること。

認証器データのレイアウト。名前列の名称はこの文書内での参照用にすぎず、実際の認証器データの表現には存在しない。

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

認証器は、認証器データ構造を生成するために次の手順を実行する:

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

注: 認証器がユーザー存在テストとユーザー検証の両方を実行した場合、それらが単一の認可ジェスチャーに組み合わされている可能性があっても、認証器はUP フラグとUV フラグの両方を設定する。
クレデンシャルがマルチデバイスクレデンシャルである場合に限り、BE フラグを設定しなければならない（SHALL）。この値は、§ 6.1.3 クレデンシャルのバックアップ状態で定義される登録セレモニーの後に変更してはならない（MUST NOT）。
クレデンシャルがマルチデバイスクレデンシャルであり、かつ現在バックアップ済みである場合に限り、BS フラグを設定しなければならない（SHALL）。

クレデンシャルのバックアップ状態が不確かであるか、認証器がバックアップ済みクレデンシャルに問題があると疑う場合、 BS フラグを設定するべきではない（SHOULD NOT）。
アテステーション署名について、認証器はAT フラグを設定し、 attestedCredentialDataを含めなければならない（MUST）。アサーション署名については、AT フラグを設定してはならず（MUST NOT）、 attestedCredentialData を含めてはならない（MUST NOT）。
認証器が拡張データを含めない場合、ED フラグをゼロに設定しなければならず（MUST）、拡張データを含める場合は 1 に設定しなければならない（MUST）。

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

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

可変長であるアテステーション済みクレデンシャルデータの長さを決定するには、先行する credentialIdの長さを基に credentialPublicKeyの開始位置を決定し、続いて credentialPublicKeyの長さを決定する必要がある（第 7 節、[RFC9052]も参照）。

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

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

署名カウンターを実装しない認証器は、認証器データ内の signCount を常にゼロのままにする。

依存パーティは、直近のauthenticatorGetAssertion操作の署名カウンターを保存する。（または、あるクレデンシャルでauthenticatorGetAssertionが一度も実行されていない場合は、authenticatorMakeCredential操作のカウンター。）後続の authenticatorGetAssertion操作では、依存パーティは保存された署名カウンター値と、アサーションの認証器データで返された新しい signCount 値を比較する。どちらかがゼロでなく、かつ新しい signCount 値が保存された値以下である場合、複製された認証器が存在する可能性、認証器が誤動作している可能性、または依存パーティが認証器で生成された順序とは異なる順序でアサーションを受信および処理している競合状態が存在する可能性がある。

署名カウンターの不一致を検出しても、現在の操作が複製された認証器によって実行されたのか、元の認証器によって実行されたのかは示されない。依存パーティは、それぞれの状況、すなわちリスク許容度や、値が増加しないことに許容可能な理由を生じさせる可能性がある運用上の要因に応じて、この状況に適切に対処するべきである。

認証器:

クレデンシャルごとの署名カウンターを実装するべきである（SHOULD）。これにより、署名カウンター値が依存パーティ間で共有され、ユーザーを関連付けるためのハンドルとして使用される可能性を防ぐ。認証器は、グローバルな署名カウンター、すなわち認証器単位のカウンターを実装してもよい（MAY）が、これはユーザーのプライバシーにより配慮しない。
署名カウンター値が誤って減少しないようにするべきである（SHOULD）（たとえば、ハードウェア障害によって）。

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

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

これは、FIDO U2F 認証応答メッセージ内の署名対象データの先頭 37 バイトが有効な認証器データ構造を構成し、残りの 32 バイトがシリアル化されたクライアントデータのハッシュであるためである。この認証器データ構造では、 rpIdHash は FIDO U2F のアプリケーションパラメーターであり、 フラグは UP以外は常にゼロであり、 attestedCredentialData および extensions は決して存在しない。したがって、FIDO U2F 認証署名は、authenticatorGetAssertion 操作によって生成される他のアサーション署名と同じ手順で検証できる。

6.1.3. クレデンシャルのバックアップ状態

クレデンシャルのバックアップ適格性および現在のバックアップ状態は、表で定義されているように、認証器データ内のBEおよびBS フラグによって伝達される。

BE フラグの値は、authenticatorMakeCredential操作中に設定され、変更してはならない（MUST NOT）。

BS フラグの値は、公開鍵クレデンシャルソースの現在の状態に基づいて時間の経過とともに変化する場合がある。以下の表は、有効な組み合わせとその意味を定義する。

BE	BS	説明
`0`	`0`	クレデンシャルはシングルデバイスクレデンシャルである。
`0`	`1`	この組み合わせは許可されない。
`1`	`0`	クレデンシャルはマルチデバイスクレデンシャルであり、現在バックアップ済みではない。
`1`	`1`	クレデンシャルはマルチデバイスクレデンシャルであり、現在バックアップ済みである。

BEおよびBS フラグの組み合わせ

依存パーティは、将来の評価のため、これらのフラグの最新値をユーザーアカウントとともに保存することが推奨される（RECOMMENDED）。

以下は、依存パーティがこれらのフラグを使用する方法の非網羅的な一覧である。

追加の認証器を要求する:

BE フラグが 0に設定されている場合、クレデンシャルはシングルデバイスクレデンシャルであり、生成元の認証器はクレデンシャルのバックアップを決して許可しない。

シングルデバイスクレデンシャルは、単一デバイスの紛失に対する耐性がない。依存パーティは、各ユーザーアカウントに追加の認証器が登録されていること、および/またはアカウント復旧プロセスが用意されていることを確保するべきである（SHOULD）。たとえば、ローミング認証器や、マルチデバイスクレデンシャルに対応した認証器など、追加の認証器を設定するようユーザーに促すことができる。
ユーザーをパスワード不要のアカウントへアップグレードする:

BS フラグが 0から1へ変化した場合、認証器は、クレデンシャルがバックアップ済みであり、単一デバイスの紛失から保護されていることを通知している。

依存パーティは、アカウントのセキュリティをアップグレードし、パスワードを削除するようユーザーに促すことを選択してもよい（MAY）。
状態変化後に追加の要素を追加する:

BS フラグが 1から0へ変化した場合、認証器は、クレデンシャルがもはやバックアップ済みではなく、単一デバイスの紛失からも保護されなくなったことを通知している。これは、バックアップサービスの無効化などのユーザー操作、またはバックアップサービスの問題などのエラーによって生じる可能性がある。

この遷移が発生した場合、依存パーティは、他の認証要素を検証するプロセスへユーザーを案内するべきである（SHOULD）。ユーザーがアカウントに別のクレデンシャルを持っていない場合、アカウントへのアクセスを失わないよう、追加のクレデンシャルを追加するよう案内するべきである（SHOULD）。たとえば、ユーザーに追加の認証器、たとえばローミング認証器や、マルチデバイスクレデンシャルに対応した認証器を設定するよう促すことができる。

6.2. 認証器の分類

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

たとえば:

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

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

認証器がローミング認証器かプラットフォーム認証器か、または場合によってはその両方か — すなわち認証器アタッチメントモダリティ。ローミング認証器は、クライアントと通信するための 1 つ以上のトランスポートをサポートできる。
認証器がユーザー検証に対応しているかどうか — 認証要素能力。
認証器が発見可能なクレデンシャルに対応しているかどうか — クレデンシャル保存モダリティ。

これらの特性は独立しており、理論上は任意の方法で組み合わせることができるが、表では、特に重要ないくつかの認証器型を列挙し命名している。

認証器型	認証器アタッチメントモダリティ	クレデンシャル保存モダリティ	認証要素能力
第 2 要素プラットフォーム認証器	プラットフォーム	いずれか	単一要素対応
ユーザー検証対応プラットフォーム認証器	プラットフォーム	いずれか	多要素対応
第 2 要素ローミング認証器	クロスプラットフォーム	サーバー側保存	単一要素対応
パスキーローミング認証器	クロスプラットフォーム	クライアント側保存	多要素対応
パスキープラットフォーム認証器	プラットフォーム（`transport` = `internal`）またはクロスプラットフォーム（`transport` = `hybrid`）	クライアント側保存	多要素対応

いくつかの認証器型の名称の定義。

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

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

ユーザー検証対応プラットフォーム認証器クラスは、パスキープラットフォーム認証器クラスによってほぼ廃止されているが、この定義は引き続きisUserVerifyingPlatformAuthenticatorAvailable メソッドで使用される。

表で名称が付けられていない組み合わせには、あまり特徴的でないユースケースがある。

発見可能なクレデンシャルに対応しているが多要素対応ではないローミング認証器は、ユーザー名なしの単一要素認証に使用できる。この場合、ユーザーはユーザーハンドルによって自動的に識別され、クレデンシャル秘密鍵の所持が唯一の認証要素として使用される。これは一部の状況では有用であるが、ユーザーは認証器の盗難に対して特に脆弱になる。
多要素対応であるが発見可能なクレデンシャルに対応していないローミング認証器は、多要素認証に使用できるが、まずユーザーを識別する必要があり、個人識別情報が漏えいするリスクがある。§ 14.6.3 クレデンシャル ID を介したプライバシー漏えいを参照すること。

以下の各小節では、認証器アタッチメントモダリティ、クレデンシャル保存モダリティ、および認証要素能力の各側面をさらに詳しく定義する。

6.2.1. 認証器アタッチメントモダリティ

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

プラットフォーム認証器は、クライアントデバイス固有のトランスポートによって接続され、この接続をプラットフォームアタッチメントと呼ぶ。通常はクライアントデバイスから取り外すことはできない。プラットフォーム認証器にバインドされた公開鍵クレデンシャルをプラットフォームクレデンシャルと呼ぶ。
ローミング認証器は、クロスプラットフォームトランスポートによって接続され、この接続をクロスプラットフォームアタッチメントと呼ぶ。このクラスの認証器はクライアントデバイスから取り外すことができ、その間を「移動」できる。ローミング認証器にバインドされた公開鍵クレデンシャルをローミングクレデンシャルと呼ぶ。

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

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

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

6.2.2. クレデンシャル保存モダリティ

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

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

これにより、暗号化された公開鍵クレデンシャルソースが認証器ではなく依存パーティによって保存されるため、認証器は無制限のクレデンシャル保存容量を持つことができるが、この方法で保存されたクレデンシャルは、認証器が使用できるようになる前に、依存パーティから取得しなければならない。

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

認証器がクライアント側で発見可能な公開鍵クレデンシャルソースをサポートする場合、その認証器はクライアント側クレデンシャル保存モダリティを持つ。クライアント側クレデンシャル保存モダリティを持つ認証器は、発見可能なクレデンシャルに対応しているとも呼ばれる。
認証器がクライアント側クレデンシャル保存モダリティを持たない場合、すなわち公開鍵クレデンシャルソースをクレデンシャル ID内の暗号文として保存することのみをサポートする場合、その認証器はサーバー側クレデンシャル保存モダリティを持つ。

発見可能なクレデンシャルに対応した認証器は、両方の保存方式をサポートしてもよい（MAY）ことに注意すること。この場合、認証器は、 residentKey およびrequireResidentKey オプションの制約を受けるものの、 create()で、異なるクレデンシャルに異なる保存方式を任意に使用してもよい（MAY）。

6.2.3. 認証要素能力

認証セレモニー中にアイデンティティを証明するために使用できる認証要素には、大きく 3 つのクラスがある。所持しているもの、知っているもの、および本人固有のものである。それぞれの例には、物理キー、パスワード、指紋がある。

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

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

6.3. 認証器操作

WebAuthn クライアントは、認証器の操作を呼び出すために、その認証器へ接続しなければならない（MUST）。この接続により認証器セッションが定義される。認証器はセッション間の分離を維持しなければならない。これは、任意の時点で 1 つのセッションのみが存在することを許可するか、より複雑なセッション管理を提供することで実現できる。

クライアントは、認証器セッション内で次の操作を呼び出せる。

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

認証器 authenticator内でクレデンシャル IDcredentialIdを検索した結果は、次のアルゴリズムの結果である。

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

6.3.2. authenticatorMakeCredential 操作

この操作を呼び出す前に、クライアントは認証器セッションで進行中の他のすべての操作を中止するため、 authenticatorCancel操作を呼び出さなければならない（MUST）。

この操作は次の入力パラメーターを取る。

hash: クライアントによって提供されるシリアル化されたクライアントデータのハッシュ。
rpEntity: 依存パーティの PublicKeyCredentialRpEntity。
userEntity: 依存パーティによって与えられたユーザーハンドルを含む、ユーザーアカウントのPublicKeyCredentialUserEntity。
requireResidentKey: クライアントによって決定される Boolean 値である、クレデンシャル作成のための有効な常駐キー要件。
requireUserPresence: 定数 Boolean 値true、または options.mediation がconditional に設定され、ユーザーエージェントが以前にユーザーから同意を得ている場合はFALSE。
requireUserVerification: クライアントによって決定される Boolean 値である、クレデンシャル作成のための有効なユーザー検証要件。
credTypesAndPubKeyAlgs: 依存パーティによって要求された、 PublicKeyCredentialType と公開鍵アルゴリズム（COSEAlgorithmIdentifier）のペアのシーケンス。このシーケンスは、最も優先されるものから最も優先されないものの順に並ぶ。認証器は、可能な限り最も優先されるクレデンシャルを作成するよう最善を尽くす。
excludeCredentialDescriptorList: 依存パーティによって提供される任意（OPTIONAL）のPublicKeyCredentialDescriptor オブジェクトの一覧であり、これらのいずれかが認証器に既知である場合、新しいクレデンシャルを作成するべきではない（SHOULD NOT）という意図で提供される。 excludeCredentialDescriptorListには、既知のクレデンシャルの一覧が含まれる。
enterpriseAttestationPossible: 個別に識別可能なアテステーションを認証器が返してもよい（MAY）ことを示す Boolean 値。
attestationFormats: アテステーションステートメント形式に関する依存パーティの選好を、最も優先されるものから最も優先されないものの順に表す文字列のシーケンス。認証器がアテステーションを返す場合、サポートする形式のうち最も優先される形式を使用するよう最善を尽くす。
extensions: 存在する場合、依存パーティによって要求された拡張に基づきクライアントによって作成された、拡張識別子から対応する認証器拡張入力へのCBOR マップ。

この操作が呼び出されたとき、認証器は次の手順を実行しなければならない（MUST）。

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

requireUserPresenceがtrueの場合、認可ジェスチャーにはユーザー存在テストを含めなければならない（MUST）。

ユーザーが同意しないか、ユーザー検証が失敗した場合、 "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を含むアテステーション済みクレデンシャルデータのバイト配列とする。
attestationFormatを、enterpriseAttestationPossibleを考慮したうえで、 attestationFormats内の最初にサポートされるアテステーションステートメント形式識別子とする。 attestationFormatsにサポートされる値がない場合、 attestationFormatを、この認証器が最も優先するアテステーションステートメント形式識別子とする。
authenticatorDataを、§ 6.1 認証器データで規定されたバイト配列とし、 attestedCredentialDataを attestedCredentialData として、存在する場合はprocessedExtensionsを extensionsとして含める。
§ 6.5.4 アテステーションオブジェクトの生成で規定された手順、アテステーションステートメント形式 attestationFormat、およびauthenticatorDataとhashの値を使用し、 enterpriseAttestationPossibleの値を考慮して、新しいクレデンシャルのアテステーションオブジェクトを作成する。アテステーションの詳細については§ 6.5 アテステーションを参照すること。

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

6.3.3. authenticatorGetAssertion 操作

この操作は次の入力パラメーターを取る。

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

このメソッドが呼び出されたとき、認証器は次の手順を実行しなければならない（MUST）。

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

requireUserPresenceがtrueの場合、認可ジェスチャーにはユーザー存在テストを含めなければならない（MUST）。

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

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

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

6.3.4. authenticatorCancel 操作

この操作は入力パラメーターを取らず、結果も返さない。

この操作が認証器セッション内でクライアントによって呼び出されると、その認証器セッションで現在進行中のauthenticatorMakeCredentialまたはauthenticatorGetAssertion 操作が終了する。認証器は、キャンセルされた操作の認可に関連するユーザー入力を要求したり受け付けたりすることを停止する。クライアントは、キャンセルされた操作に対する認証器からのそれ以降の応答を無視する。

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

6.3.5. silentCredentialDiscovery 操作

これは、conditional ユーザー仲介を可能にするため、認証器がサポートしてもよい（MAY）任意（OPTIONAL）の操作である。

次の入力パラメーターを取る。

rpId: クライアントによって決定された、呼び出し元のRP ID。

この操作が呼び出されたとき、認証器は次の手順を実行しなければならない（MUST）。

collectedDiscoverableCredentialMetadataを、次の項目を持つDiscoverableCredentialMetadata構造体を項目とする新しいリストとする。

type

PublicKeyCredentialType。

id

クレデンシャル ID。

rpId

依存パーティ識別子。

userHandle

ユーザーハンドル。

otherUI

認証器が UI に情報を提供するために使用するその他の情報。
authenticatorのクレデンシャルマップの各公開鍵クレデンシャルソースcredSourceについてそれぞれ:
1. credSourceがクライアント側で発見可能なクレデンシャルでない場合、続行する。
2. credSource.rpIdがrpIdでない場合、続行する。
3. discoveredCredentialMetadataを、credSourceのtype、id、 rpId、userHandleおよび otherUIのコピーを項目として持つ新しいDiscoverableCredentialMetadata 構造体とする。
4. discoveredCredentialMetadataを collectedDiscoverableCredentialMetadataに追加する。
collectedDiscoverableCredentialMetadataを返す。

6.4. 文字列の処理

認証器は、依存パーティによって選択された任意の文字列、たとえばPublicKeyCredentialUserEntity内のname およびdisplayName を保存する必要がある場合がある。この節では、人間に提示される可能性がある任意の文字列を処理することによる実務上の影響について説明する。

6.4.1. 文字列の切り詰め

API 内の各任意文字列には、認証器で利用可能なリソースが制限されている可能性に対する何らかの配慮がある。選択した配慮方法が文字列の切り詰めである場合、文字列値を破損しないよう注意する必要がある。

たとえば、Unicode コードポイントだけに基づいて切り詰めると、書記素クラスタが切り詰められる可能性がある。これにより、書記素クラスタが完全に削除される代わりに別のグリフとして描画され、文字列の意味が変わる可能性がある。たとえば、図は、 UTF-8 でエンコードされた 65 バイト長の文字列の末尾を示している。 64 バイトに切り詰める場合、サイズ制限を満たすために最後の 0x88 バイトがまず削除される。その結果 UTF-8 コードポイントが不完全になるため、そのコードポイントの残りも削除しなければならない。さらに、その結果書記素クラスタが不完全になるため、そのクラスタの残りも削除するべきである。

これらの問題を処理する責任は主にクライアントにあり、認証器に文字エンコーディングや Unicode 文字プロパティの理解という負担を課さないようにする。以下の各小節では、クライアントと認証器がそれぞれ文字列を切り詰める方法についての要件を定義する。

6.4.1.1. クライアントによる文字列の切り詰め

WebAuthn クライアントが文字列を切り詰める場合、依存パーティから観測可能な切り詰め動作は、次の要件を満たさなければならない（MUST）。

指定されたサポート最小長以上のサイズ制限を選択する。 UTF-8 文字エンコーディングにおけるバイト長がその制限を満たすよう、文字列を切り詰めてもよい（MAY）。この切り詰めは UTF-8 コードポイント境界を尊重しなければならず（MUST）、書記素クラスタ境界[UAX29]を尊重するべきである（SHOULD）。切り詰め後の値は選択したサイズ制限より短くてもよい（MAY）が、サイズ制限を満たし、かつ書記素クラスタ境界で終わる最長のプレフィックス部分文字列より短くてはならない（MUST NOT）。

認証器がこれらの要件を満たす場合、クライアントは認証器に切り詰めを実行させてもよい（MAY）。そうでない場合、クライアントは文字列値を認証器へ中継する前に切り詰めを実行しなければならない（MUST）。

上記に加えて、バイト境界だけで切り詰めると既知の問題が生じるため、ユーザーエージェントは注意するべきである。認証器が[FIDO-CTAP]を使用している場合、値は CBOR 文字列として型付けされ、したがって有効な UTF-8 である必要があるため、認証器からの将来のメッセージに無効な CBOR が含まれる可能性がある。したがって、認証器を扱う際、ユーザーエージェントは次を行うべきである（SHOULD）。

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

6.4.1.2. 認証器による文字列の切り詰め

WebAuthn 認証器は制約のある環境で実装される場合があるため、認証器に対する要件はクライアントに対するものより緩和されている。

WebAuthn 認証器が文字列を切り詰める場合、切り詰め動作は次の要件を満たさなければならない（MUST）。

指定されたサポート最小長以上のサイズ制限を選択する。 UTF-8 文字エンコーディングにおけるバイト長がその制限を満たすよう、文字列を切り詰めてもよい（MAY）。この切り詰めは UTF-8 コードポイント境界を尊重するべきであり（SHOULD）、書記素クラスタ境界[UAX29]を尊重してもよい（MAY）。切り詰め後の値は選択したサイズ制限より短くてもよい（MAY）が、サイズ制限を満たし、かつ書記素クラスタ境界で終わる最長のプレフィックス部分文字列より短くてはならない（MUST NOT）。

6.4.2. 言語と方向のエンコーディング

コンテキスト内で正しく表示するためには、文字列の言語と基本方向が必要になる場合がある。この API の文字列は、固定機能の認証器に書き込まれ、後に読み戻されて別のプラットフォームで表示される必要がある場合がある。

専用の言語および方向メタデータフィールドをサポートしない既存の固定機能認証器との互換性のため、 Web Authentication レベル 2 には、そのようなメタデータを文字列自体に埋め込み、一体として転送されることを保証するための規定が含まれていた。このエンコーディングは推奨されない（NOT RECOMMENDED）。クライアントおよび認証器は、新しい値におけるそのようなエンコーディングを無視してもよい（MAY）。クライアントおよび認証器は、 Web Authentication レベル 2 §6.4.2. 言語と方向のエンコーディングで説明されているように、既存の文字列にエンコードされた言語および方向メタデータを検出して処理してもよい（MAY）。

代わりに、Web Authentication APIの将来のバージョンでは、専用の言語および方向メタデータフィールドが提供される可能性がある。

6.5. アテステーション

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

認証器が自己アテステーションまたはアテステーションなしを使用する場合、依存パーティが信頼判断の根拠とできる出所情報は提供されない。この場合、認証器は、その動作について依存パーティに何の保証も提供しない。

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

注: この図はpackedアテステーションステートメント形式のみを示している。さらにいくつかのアテステーションステートメント形式が§ 8 定義済みアテステーションステートメント形式で定義されている。

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

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

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

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

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

アテステーション型およびアテステーションステートメント形式は認証器によって選択される。依存パーティは、 attestation およびattestationFormats パラメーターを設定することで、自身の選好を通知することしかできない。

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

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

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

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

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

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

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

[RFC9052]の第 7 節では、すべての COSE_Key でエンコードされた鍵に対する一般的な枠組みを定義している。特定のアルゴリズム用の特定の鍵型は、[RFC9053]および以下で示すその他の仕様で定義されている。

以下は、EC2 形式の COSE_Key でエンコードされた楕円曲線公開鍵（[RFC9053]の第 7.1 節を参照）の例であり、 P-256 曲線上で、ES256 署名アルゴリズム（SHA-256 を使用する ECDSA、[RFC9053]の第 2.1 節を参照）とともに使用する。

{
  1:   2,  ; kty: EC2 鍵型
  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

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

{
  1:   3,  ; kty: RSA 鍵型
  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 鍵型
  3:-257,  ; alg: RS256
 -1:   n,  ; n:   RSA モジュラス n、長さ 256 バイトのバイト文字列
           ;      例、16 進数（簡潔さのため中間バイトを省略）: DB5F651550...6DC6548ACC3
 -2:   e   ; e:   RSA 公開指数 e、長さ 3 バイトのバイト文字列
           ;      例、16 進数: 010001
}

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

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

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

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

6.5.3. アテステーション型

WebAuthn は、アテステーションステートメントのセマンティクスと、その基礎となる信頼モデルを定義する、いくつかのアテステーション型をサポートする。

注: この仕様は、認証器によって使用されるアテステーション型を明示的に表現するデータ構造を定義しない。アテステーションステートメントの検証を行う依存パーティ、すなわち navigator.credentials.create() を呼び出す際に、none 以外のアテステーション伝達を選択し、受信したアテステーションステートメントを検証する場合、使用されたアテステーション型を検証の一部として決定する。§ 8 定義済みアテステーションステートメント形式の「検証手順」の各小節を参照すること。§ 14.4.1 アテステーションのプライバシーも参照すること。この節で定義されるアテステーション型のうち、Self およびNone以外では、依存パーティによる検証の後、§ 7.1 新しいクレデンシャルの登録の手順 24 に従って、信頼パスを受け入れ可能なルート証明書と照合する。これらのアテステーション型を区別することが主に有用になるのは、依存パーティのポリシーの下でアテステーションが受け入れ可能かどうかを判断する手段としてである。

基本アテステーション（Basic）

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

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

自己アテステーション（Self）

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

アテステーション CA（AttCA）

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

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

匿名化 CA（AnonCA）

この場合、認証器は、匿名化 CAを使用する。匿名化 CA は、クレデンシャルごとにアテステーション証明書を動的に生成し、依存パーティへ提示されるアテステーションステートメントが、追跡目的などに使用できるような一意に識別可能な情報を提供しないようにする。

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

アテステーションステートメントなし（None）

この場合、アテステーション情報は利用できない。§ 8.7 None アテステーションステートメント形式も参照すること。

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

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

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

認証器は次を行わなければならない（MUST）。

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

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

attObj = {
    authData: bytes,

    ; $$attStmtType の各選択肢は fmt 値と attStmt 構造を定義する
    $$attStmtType
} .within attStmtTemplate

attStmtTemplate = {
    authData: bytes,
    fmt: text,
    attStmt: (
      { * tstr => any } ; マップは各具体的な attStmtType によって埋められる
      //
      [ * any ]         ; attStmt は配列でもよい
    )
}

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

COSEAlgorithmIdentifier -7 (ES256) およびその他の ECDSA ベースのアルゴリズムでは、 sig値は、[RFC3279] の第 2.2.3 節で定義されている ASN.1 DER Ecdsa-Sig-Value としてエンコードされなければならない（MUST）。

例:
注: エンコーディング長は INTEGER の大きさと曲線サイズによって異なる。
30 43                                ; SEQUENCE（67 バイト）
    02 21                            ; INTEGER（33 バイト）
    | 00 89 90 95 04 e1 4f 1e 29 db a8 15 8f a7 c3 87
    | e8 88 ff be 07 d8 24 bb 21 43 20 55 06 ab 15 9c
    | 3e
    02 1e                            ; INTEGER（30 バイト）
    | 56 55 4f b5 81 9b 12 84 5e 85 be 2f 78 37 1c f3
    | cb 95 e3 87 f4 51 cb 36 2b 94 78 d1 83 d2

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

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

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

COSEAlgorithmIdentifier -257 (RS256) では、sigには SHA-256 をハッシュ関数として使用して[RFC8017]の第 8.2.1 節で定義される RSASSA-PKCS1-v1_5 署名方式を使用して生成された署名を含めなければならない（MUST）。署名は ASN.1 でラップされない。
COSEAlgorithmIdentifier -37 (PS256) では、sigには SHA-256 をハッシュ関数として使用して[RFC8017]の第 8.1.1 節で定義される RSASSA-PSS 署名方式を使用して生成された署名を含めなければならない（MUST）。署名は ASN.1 でラップされない。

7. WebAuthn 依存パーティの操作

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

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

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

登録セレモニーを実行するため、依存パーティは次のように進めなければならない（MUST）。

optionsを、セレモニーに対する依存パーティの要件に合わせて設定された新しいCredentialCreationOptions 構造とする。 pkOptionsを options.publicKey とする。
navigator.credentials.create() を呼び出し、optionsを引数として渡す。 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 の値が、 pkOptions.challenge の base64url エンコーディングと等しいことを検証する。
C.origin の値が依存パーティが期待するオリジンであることを検証する。ガイダンスについては§ 13.5.9 クレデンシャルのオリジンの検証を参照すること。
C.crossOrigin が存在し、trueに設定されている場合、このクレデンシャルが、その祖先と同一オリジンではない iframe 内で作成されたことを依存パーティが期待していることを検証する。
C.topOrigin が存在する場合:
1. このクレデンシャルが、その祖先と同一オリジンではない iframe 内で作成されたことを依存パーティが期待していることを検証する。
2. C.topOrigin の値が、依存パーティがその内部にサブフレーム化されると期待しているページのオリジンと一致することを検証する。ガイダンスについては§ 13.5.9 クレデンシャルのオリジンの検証を参照すること。
hashを、 response.clientDataJSON に対して SHA-256 を使用してハッシュを計算した結果とする。
AuthenticatorAttestationResponse 構造のattestationObject フィールドに対して CBOR デコードを実行し、アテステーションステートメント形式fmt、認証器データ authData、およびアテステーションステートメントattStmtを取得する。
authData内の rpIdHash が、依存パーティが期待するRP IDの SHA-256 ハッシュであることを検証する。
options.mediation がconditionalに設定されていない場合、authData内の flags のUPビットが設定されていることを検証する。
依存パーティがこの登録にユーザー検証を要求する場合、 authData内の flags のUVビットが設定されていることを検証する。
authData内の flags のBEビットが設定されていない場合、BSビットも設定されていないことを検証する。
依存パーティが、ユーザーエクスペリエンスのフローおよび/またはポリシーの判断にクレデンシャルのバックアップ適格性を使用する場合、authData内の flags のBEビットを評価する。
依存パーティが、ユーザーエクスペリエンスのフローおよび/またはポリシーの判断にクレデンシャルのバックアップ状態を使用する場合、authData内の flags のBS ビットを評価する。
authData内のクレデンシャル公開鍵の "alg" パラメーターが、 pkOptions.pubKeyCredParams 内の項目のいずれかのalg 属性と一致することを検証する。
fmtを、サポートされる WebAuthn Attestation Statement Format Identifier 値の集合と USASCII で大文字小文字を区別して照合し、アテステーションステートメント形式を決定する。登録済み WebAuthn Attestation Statement Format Identifier 値の最新一覧は、 [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 つを提供する。
手順 22の検証手順の出力を使用して、次のようにアテステーションの信頼性を評価する。
- アテステーションなしが提供された場合、 Noneアテステーションが依存パーティのポリシーの下で受け入れ可能であることを検証する。
- 自己アテステーションが使用された場合、自己アテステーションが依存パーティのポリシーの下で受け入れ可能であることを検証する。
- それ以外の場合、検証手順からアテステーション信頼パスとして返された X.509 証明書を使用して、アテステーション公開鍵が受け入れ可能なルート証明書まで正しくチェーンするか、またはそれ自体が受け入れ可能な証明書であることを検証する（すなわち、それと手順 23で取得したルート証明書は同じであってもよい）。
アテステーションステートメントが信頼できると判断されない場合、依存パーティは登録セレモニーを失敗させるべきである（SHOULD）。

注: ただし、ポリシーで許可されている場合、依存パーティは、クレデンシャル IDおよびクレデンシャル公開鍵を登録しつつ、クレデンシャルを自己アテステーションを持つものとして扱ってもよい（MAY）（§ 6.5.3 アテステーション型を参照）。そうする場合、依存パーティは、公開鍵クレデンシャルが特定の認証器モデルによって生成されたことを示す暗号学的証明は存在しないと表明することになる。より詳しい議論については[FIDOSecRef]および[UAFProtocol]を参照すること。
credentialId が 1023 バイト以下であることを検証する。これより大きいクレデンシャル ID の場合、依存パーティはこの登録セレモニーを失敗させるべきである（SHOULD）。
credentialId がまだどのユーザーにも登録されていないことを検証する。 credentialId がすでに既知である場合、依存パーティはこの登録セレモニーを失敗させるべきである（SHOULD）。

注: 依存パーティが重複するクレデンシャル IDを拒否する理由は次のとおりである。クレデンシャル IDには十分なエントロピーが含まれるため、偶然の重複は非常に起こりにくい。ただし、自己アテステーション以外のアテステーション型は、登録時にクレデンシャル秘密鍵の所持を明示的に証明する自己署名を含まない。したがって、あるサイトについてユーザーのクレデンシャル IDおよびクレデンシャル公開鍵を何らかの方法で取得した攻撃者は、そのサイトで被害者のクレデンシャルを自身のものとして登録しようとする可能性がある。依存パーティがこの新しい登録を受け入れ、被害者の既存のクレデンシャル登録を置き換え、かつクレデンシャルが発見可能である場合、被害者は次回の試行時に攻撃者のアカウントへサインインするよう強制される可能性がある。その状態で被害者がサイトに保存したデータは、攻撃者から利用可能になる。
credentialRecordを、次の内容を持つ新しいクレデンシャルレコードとする。

type

credential.type。

id

credential.id または credential.rawIdのうち、依存パーティが優先する形式。

publicKey

authData内のクレデンシャル公開鍵。

signCount

authData.signCount。

uvInitialized

authData内のflagsのUVフラグの値。

transports

response.getTransports() から返された値。

backupEligible

authData内のflagsのBEフラグの値。

backupState

authData内のflagsのBSフラグの値。

新しいクレデンシャルレコードには、次の任意（OPTIONAL）の内容を含めてもよい（MAY）。

attestationObject

response.attestationObject。

attestationClientDataJSON

response.clientDataJSON。

rpId

pkOptions.rp.id。

依存パーティは、必要に応じて追加の項目を含めてもよい（MAY）。非規範的な例として、依存パーティは、アカウント設定を操作する際に、どのクレデンシャルがどの認証器にバインドされているかをユーザーが思い出しやすくするため、クレデンシャルに「ニックネーム」を設定できるようにしてもよい。
clientExtensionResults内のクライアント拡張出力と、 authData内の extensions 内の認証器拡張出力を、依存パーティの必要に応じて処理する。各拡張に応じて、処理手順が具体的に規定される場合もあれば、拡張出力をどう処理するかが依存パーティに委ねられる場合もある。依存パーティは、任意またはすべての拡張出力を無視してもよい（MAY）。
クライアントは追加の認証器拡張またはクライアント拡張を設定してもよく（MAY）、その結果、pkOptions.extensions で依存パーティが要求していない値が、認証器拡張出力またはクライアント拡張出力に現れる場合がある。依存パーティは、そのような状況を、未要求の拡張を無視するか、アテステーションを拒否するかにかかわらず、処理できるようにしておかなければならない（MUST）。依存パーティは、ローカルポリシーと使用中の拡張に基づいてこの判断を行うことができる。

すべての拡張はクライアントと認証器の両方にとって任意（OPTIONAL）であるため、依存パーティは、要求した拡張のいずれも、または一部が処理されなかった場合にも対応できるようにしておかなければならない（MUST）。
上記のすべての手順が成功した場合、 credentialRecordを pkOptions.user で示されたユーザーアカウントに保存し、必要に応じて登録セレモニーを続行する。それ以外の場合、登録セレモニーを失敗させる。

この場合に依存パーティが登録セレモニーを失敗させない場合、依存パーティは、公開鍵クレデンシャルが特定の認証器モデルによって生成されたことを示す暗号学的証明は存在しないことを受け入れている。依存パーティは、そのクレデンシャルをアテステーションなしのものと同等と見なしてもよい（MAY）（§ 6.5.3 アテステーション型を参照）。より詳しい議論については[FIDOSecRef]および[UAFProtocol]を参照すること。

アテステーションオブジェクトの検証には、依存パーティが、上記の手順 23で受け入れ可能な信頼アンカーを決定するための信頼できる方法を持っている必要がある。また、証明書を使用している場合、依存パーティは、中間 CA 証明書の証明書状態情報にアクセスできなければならない（MUST）。クライアントがアテステーション情報内で証明書チェーンを提供しなかった場合、依存パーティはアテステーション証明書チェーンを構築できなければならない（MUST）。

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

認証セレモニーを実行するため、依存パーティは次のように進めなければならない（MUST）。

optionsを、セレモニーに対する依存パーティの要件に合わせて設定された新しいCredentialRequestOptions 構造とする。 pkOptionsを options.publicKey とする。
navigator.credentials.get() を呼び出し、optionsを引数として渡す。 credentialを、正常に解決された Promise の結果とする。 Promise が拒否された場合、ユーザーに表示されるエラーとともにセレモニーを中止するか、拒否された Promise で利用可能なコンテキストから判断できる範囲でユーザーエクスペリエンスを案内する。さまざまなエラーコンテキストと、それに至る状況については、§ 6.3.3 authenticatorGetAssertion 操作を参照すること。
responseを credential.response とする。 responseがAuthenticatorAssertionResponseのインスタンスでない場合、ユーザーに表示されるエラーとともにセレモニーを中止する。
clientExtensionResultsを、 credential.getClientExtensionResults() を呼び出した結果とする。
pkOptions.allowCredentials が空でない場合、 credential.id が pkOptions.allowCredentials に列挙された公開鍵クレデンシャルのいずれかを識別することを検証する。
認証されるユーザーを識別し、credentialRecordをクレデンシャルのクレデンシャルレコードとする。

認証セレモニーの開始前に、たとえばユーザー名や cookie を介してユーザーが識別されていた場合、

識別されたユーザーアカウントに、 idが credential.rawId と等しいクレデンシャルレコードが含まれることを検証する。 credentialRecordをそのクレデンシャルレコードとする。 response.userHandle が存在する場合、それがユーザーアカウントのユーザーハンドルと等しいことを検証する。

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

response.userHandle が存在することを検証する。 response.userHandle によって識別されるユーザーアカウントに、 idが credential.rawId と等しいクレデンシャルレコードが含まれることを検証する。 credentialRecordをそのクレデンシャルレコードとする。
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 の値が、 pkOptions.challenge の base64url エンコーディングと等しいことを検証する。
C.origin の値が、依存パーティが期待するオリジンであることを検証する。ガイダンスについては§ 13.5.9 クレデンシャルのオリジンの検証を参照すること。
C.crossOrigin が存在し、trueに設定されている場合、このクレデンシャルが、その祖先と同一オリジンではない iframe 内で使用されることを依存パーティが期待していることを検証する。
C.topOrigin が存在する場合:
1. このクレデンシャルが、その祖先と同一オリジンではない iframe 内で使用されることを依存パーティが期待していることを検証する。
2. C.topOrigin の値が、依存パーティがその内部にサブフレーム化されると期待しているページのオリジンと一致することを検証する。ガイダンスについては§ 13.5.9 クレデンシャルのオリジンの検証を参照すること。
authData内の rpIdHash が、依存パーティが期待するRP IDの SHA-256 ハッシュであることを検証する。
注: appid拡張を使用する場合、この手順には特別なロジックが必要となる。詳細については § 10.1.1 FIDO AppID 拡張 (appid)を参照すること。
authData内の flags のUPビットが設定されていることを検証する。
このアサーションにユーザー検証が必要かどうかを決定する。ユーザー検証は、 pkOptions.userVerification がrequiredに設定されている場合に限り、要求するべきである（SHOULD）。

ユーザー検証が必要であると決定された場合、 authData内の flags のUVビットが設定されていることを検証する。それ以外の場合、UV フラグの値を無視する。
authData内の flags のBEビットが設定されていない場合、BSビットも設定されていないことを検証する。
クレデンシャルのバックアップ状態が依存パーティのビジネスロジックまたはポリシーの一部として使用される場合、 currentBeおよびcurrentBsを、それぞれ authData内の flags のBEおよびBSビットの値とする。 currentBeおよびcurrentBsを credentialRecord.backupEligible および credentialRecord.backupState と比較する。
1. credentialRecord.backupEligible が設定されている場合、currentBeが設定されていることを検証する。
2. credentialRecord.backupEligible が設定されていない場合、currentBeが設定されていないことを検証する。
3. 存在する場合、依存パーティのポリシーを適用する。
注: 依存パーティが BS フラグ値を処理する方法の例については、§ 6.1.3 クレデンシャルのバックアップ状態を参照すること。
hashを、cDataに対して SHA-256 を使用してハッシュを計算した結果とする。
credentialRecord.publicKey を使用して、sigがauthDataとhashをバイナリ連結したものに対する有効な署名であることを検証する。

注: この検証手順は FIDO U2F 認証器によって生成された署名と互換性がある。§ 6.1.2 FIDO U2F 署名形式との互換性を参照すること。
authData.signCount がゼロでないか、 credentialRecord.signCount がゼロでない場合、次のサブステップを実行する。
- authData.signCount が
  credentialRecord.signCount より大きい:
  署名カウンターは有効である。
  credentialRecord.signCount 以下:
  これは認証器が複製されている可能性を示すシグナルではあるが、証明ではない。たとえば、次のことを意味する可能性がある。
  - クレデンシャル秘密鍵のコピーが 2 つ以上存在し、並行して使用されている可能性がある。
  - 認証器が誤動作している。
  - 依存パーティが、認証器で生成された順序とは異なる順序でアサーション応答を処理する競合状態が存在する。
  依存パーティは、自身の運用特性を評価し、この情報をリスクスコアリングに組み込むべきである。この場合に依存パーティが下記の credentialRecord.signCount を更新するかどうか、または認証セレモニーを失敗させるかどうかは、依存パーティ固有である。
  
  署名カウンターに関する考慮事項の詳細については、§ 6.1.1 署名カウンターに関する考慮事項を参照すること。
clientExtensionResults内のクライアント拡張出力と、 authData内の extensions 内の認証器拡張出力を、依存パーティの必要に応じて処理する。各拡張に応じて、処理手順が具体的に規定される場合もあれば、拡張出力をどう処理するかが依存パーティに委ねられる場合もある。依存パーティは、任意またはすべての拡張出力を無視してもよい（MAY）。
クライアントは追加の認証器拡張またはクライアント拡張を設定してもよく（MAY）、その結果、pkOptions.extensions で依存パーティが要求していない値が、認証器拡張出力またはクライアント拡張出力に現れる場合がある。依存パーティは、そのような状況を、未要求の拡張を無視するか、アサーションを拒否するかにかかわらず、処理できるようにしておかなければならない（MUST）。依存パーティは、ローカルポリシーと使用中の拡張に基づいてこの判断を行うことができる。

すべての拡張はクライアントと認証器の両方にとって任意（OPTIONAL）であるため、依存パーティは、要求した拡張のいずれも、または一部が処理されなかった場合にも対応できるようにしておかなければならない（MUST）。
credentialRecordを新しい状態値で更新する。
1. credentialRecord.signCount を authData.signCount の値に更新する。
2. credentialRecord.backupState をcurrentBsの値に更新する。
3. credentialRecord.uvInitialized がfalseの場合、 authData内のflagsのUVビットの値に更新する。この変更には、WebAuthn のユーザー検証と同等の追加の認証要素による認可を要求するべきである（SHOULD）。認可されない場合、この手順をスキップする。
依存パーティが、これらの WebAuthn 認証セレモニーの手順を超える追加のセキュリティチェックを実行する場合、上記の状態更新は、それらの追加チェックが正常に完了した後まで延期するべきである（SHOULD）。
上記のすべての手順が成功した場合、必要に応じて認証セレモニーを続行する。それ以外の場合、認証セレモニーを失敗させる。

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

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

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

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

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

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

注: これは、ドメイン名に基づくアテステーションステートメント形式識別子が LDH ラベル[RFC5890]のみを組み込むよう制限されることを意味する。

実装は、WebAuthn アテステーションステートメント形式識別子を大文字小文字を区別して照合しなければならない（MUST）。

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

以下の節では、現在定義および登録されているアテステーションステートメント形式とその識別子のセットを示す。登録済みアテステーションステートメント形式識別子の最新一覧は、 [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は配列の最初の要素でなければならない（MUST）。
attestnCert: X.509 形式でエンコードされたアテステーション証明書。

署名手順

このアテステーションステートメント形式の署名手順は、アサーション署名を生成する手順と類似している。

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

検証手順

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

attStmtが上記で定義された構文に準拠する有効な CBOR であることを検証し、 CBOR デコードを実行して、含まれるフィールドを抽出する。
x5cが存在する場合:
- attestnCert内のアテステーション公開鍵とalgで指定されたアルゴリズムを使用して、 sigが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 のアルゴリズムと一致することを検証する。
- algを使用するクレデンシャル公開鍵によって、 sigがauthenticatorDataとclientDataHashの連結に対する有効な署名であることを検証する。
- 成功した場合、アテステーション型 Selfおよび空のアテステーション信頼パスを表す実装固有の値を返す。

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

アテステーション証明書には、次のフィールド/拡張がなければならない（MUST）。

バージョンは 3 に設定しなければならない（MUST）（これは値 2 の ASN.1 INTEGER で示される）。
Subject フィールドは次のように設定しなければならない（MUST）。

Subject-C

認証器ベンダーが設立された国を指定する ISO 3166 コード (PrintableString)

Subject-O

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

Subject-OU

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

Subject-CN

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

依存パーティは、アテステーションルート証明書が複数の認証器モデルで使用されているかどうかを知らない場合があるため、依存パーティは拡張が存在するかどうかを確認し、存在する場合は、それがアテステーションオブジェクトで提示されたものと同じ AAGUID を含むことを検証することが推奨される。

X.509 拡張は、値の DER エンコーディングを OCTET STRING にエンコードすることに注意すること。したがって、AAGUID は有効であるために2 つの OCTET STRING でラップされなければならない（MUST）。
Basic Constraints 拡張は、CA コンポーネントをfalseに設定しなければならない（MUST）。

さらに、エントリid-ad-ocspを持つ Authority Information Access (AIA) 拡張および CRL Distribution Point 拡張 [RFC5280] は、いずれも任意（OPTIONAL）である。多くのアテステーション証明書の状態は認証器メタデータサービスを通じて利用できるためである。たとえば、FIDO Metadata Service [FIDOMetadataService]を参照すること。

特定の認証器モデルのファームウェアは、拡張 OID 1.3.6.1.4.1.45724.1.1.5 （id-fido-gen-ce-fw-version）を使用して区別してもよい（MAY）。存在する場合、この属性は、新しいファームウェアリリースバージョンごとに増加する非負の値を持つ INTEGER を含む。この拡張を critical としてマークしてはならない（MUST NOT）。

たとえば、次は上記の拡張 OID と必須フィールドを含むアテステーション証明書である。

上記の属性は、この証明書内で次のように構造化されている。

30 21                                    -- SEQUENCE
  06 0B 2B 06 01 04 01 82 E5 1C 01 01 04 -- OID 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 cd8c395c-26ed-eede-653b-00797d03ca3c
      65 3B 00 79 7D 03 CA 3C 

30 12                                    -- SEQUENCE
  06 0B 2B 06 01 04 01 82 E5 1C 01 01 05 -- OID 1.3.6.1.4.1.45724.1.1.5
  04 03                                  -- OCTET STRING
    02 01                                -- INTEGER
      2A                                 -- ファームウェアバージョン: 42

8.2.2. エンタープライズ Packed アテステーションステートメントの証明書要件

拡張 OID 1.3.6.1.4.1.45724.1.1.2（id-fido-gen-ce-sernum）は、エンタープライズ用途の packed アテステーションに追加で存在してもよい（MAY）。存在する場合、この拡張は、特定の AAGUID に対してデバイスごとに一意なオクテット文字列値を示さなければならない（MUST）。この値は工場出荷時リセットを通じて一定でなければならない（MUST）が、デバイスに関連付けられた他のシリアル番号またはその他のハードウェア識別子とは異なっていてもよい（MAY）。この拡張を critical としてマークしてはならず（MUST NOT）、対応する値は OCTET STRING としてエンコードされる。この拡張は、非エンタープライズアテステーションには存在してはならない（MUST NOT）。

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: アテステーションに使用された AIK 証明書。X.509 エンコーディング。
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フィールドをクレデンシャル公開鍵の公開領域（TPMT_PUBLIC 構造）に、certInfoフィールド（TPMS_ATTEST 構造）を同名の出力パラメーターに、 sigフィールドを上記手順から得た署名に設定する。

注: pubAreaを TPM2_ReadPublic コマンドを使用して TPM から読み取る場合、そのコマンドは TPM2B_PUBLIC 構造を返す。TPM2B_PUBLIC は 2 バイトの長さと、それに続く TPMT_PUBLIC 構造である。pubAreaに格納する前に、この 2 バイトの長さを削除しなければならない。

検証手順

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

attStmtが上記で定義された構文に準拠する有効な CBOR であることを検証し、CBOR デコードを実行して、含まれるフィールドを抽出する。

pubAreaのparametersおよびuniqueフィールドによって指定される公開鍵が、 authenticatorData内の attestedCredentialData 内の credentialPublicKey と同一であることを検証する。

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

certInfoの完全性を検証する。

x5cが存在することを検証する。
aikCertが§ 8.3.1 TPM アテステーションステートメントの証明書要件を満たすことを検証する。
aikCertに OID 1.3.6.1.4.1.45724.1.1.4 （id-fido-gen-ce-aaguid）の拡張が含まれる場合、この拡張の値がauthenticatorData内の aaguid と一致することを検証する。
aikCert内のアテステーション公開鍵とalgで指定されたアルゴリズムを使用して、sigがcertInfoに対する有効な署名であることを検証する。

certInfoが有効であることを検証する。注: certInfoは TPMS_ATTEST 構造である。

magicがTPM_GENERATED_VALUEに設定されていることを検証する。
typeがTPM_ST_ATTEST_CERTIFYに設定されていることを検証する。
extraDataが、"alg" で使用されるハッシュアルゴリズムを使用したattToBeSignedのハッシュに設定されていることを検証する。
attestedに、[TPMv2-Part2]の第 10.12.3 節で規定されるTPMS_CERTIFY_INFO構造が含まれ、そのnameフィールドが、pubArea内の nameAlg を使用して[TPMv2-Part1]の第 16 節で規定される手順により計算された、pubAreaに対する有効な Name を含むことを検証する。

注: TPM は常に、 pubArea内の nameAlg と同じ nameAlg をnameに持つ TPMS_CERTIFY_INFO 構造を返す。

注: 「Standard Attestation Structure」[TPMv2-Part1] の第 31.2 節にある残りのフィールド、すなわちqualifiedSigner、clockInfoおよび firmwareVersionは無視される。使用されるaikCert鍵の特性に応じて、これらのフィールドは難読化される場合がある。有効な場合、これらをリスクエンジンへの入力として使用してもよい（MAY）。
成功した場合、アテステーション型 AttCAおよびアテステーション信頼パスx5cを表す実装固有の値を返す。

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

TPM アテステーション証明書には、次のフィールド/拡張がなければならない（MUST）。

バージョンは 3 に設定しなければならない（MUST）。
Subject フィールドは空に設定しなければならない（MUST）。
Subject Alternative Name 拡張は、[TPMv2-EK-Profile]の第 3.2.9 節で定義されるように設定しなければならない（MUST）。

注: [TPMv2-EK-Profile]の以前のバージョンでは、 EK 証明書内に TPM シリアル番号を含む HardwareModuleName と呼ばれる任意属性を含めることが許可されていた。 HardwareModuleName をアテステーション証明書の Subject Alternative Name に含めるべきではない（SHOULD NOT）。
Extended Key Usage 拡張には OID 2.23.133.8.3 （"joint-iso-itu-t(2) internationalorganizations(23) 133 tcg-kp(8) tcg-kp-AIKCertificate(3)"）を含めなければならない（MUST）。
Basic Constraints 拡張は CA コンポーネントをfalseに設定しなければならない（MUST）。
エントリid-ad-ocspを持つ Authority Information Access (AIA) 拡張および CRL Distribution Point 拡張[RFC5280] は、いずれも任意（OPTIONAL）である。多くのアテステーション証明書の状態はメタデータサービスを通じて利用できるためである。たとえば、FIDO Metadata Service [FIDOMetadataService]を参照すること。

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

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

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

android-key

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

Basic

構文

Android key アテステーションステートメントは、DER でエンコードされた一連の X.509 証明書である Android アテステーションステートメントのみで構成される。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 デコードを実行して、含まれるフィールドを抽出する。
x5c内の最初の証明書の公開鍵とalgで指定されたアルゴリズムを使用して、 sigがauthenticatorDataとclientDataHashの連結に対する有効な署名であることを検証する。
x5c内の最初の証明書の公開鍵が、 authenticatorData内の attestedCredentialData 内の credentialPublicKey と一致することを検証する。
アテステーション証明書の拡張データ内のattestationChallengeフィールドが clientDataHashと同一であることを検証する。
アテステーション証明書の拡張データから適切な認可リストを使用して、次を検証する。
- AuthorizationList.allApplicationsフィールドが、どちらの認可リスト（softwareEnforcedまたはteeEnforced）にも存在しないこと。 PublicKeyCredential はRP IDにスコープ設定されなければならない（MUST）ためである。
- 以下について、依存パーティが信頼された実行環境からの鍵のみを受け入れたい場合は 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 でエンコードしたもの。この値は JWS [RFC7515]オブジェクト（ SafetyNet オンラインドキュメントを参照）であり、 Compact Serialization 形式である。

署名手順

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: アテステーション署名。この署名は、クライアントが認証器から受信した（生の）U2F 登録応答メッセージ[FIDO-U2F-Message-Formats] に対して計算されている。

署名手順

アテステーション対象クレデンシャルのクレデンシャル公開鍵がアルゴリズム -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 曲線上の楕円曲線（EC）公開鍵でない場合、このアルゴリズムを終了し、適切なエラーを返す。
authenticatorDataから主張されたrpIdHashを抽出し、 authenticatorData.attestedCredentialDataから、主張された credentialIdおよびcredentialPublicKeyを抽出する。
COSE_KEY 形式のcredentialPublicKey（[RFC9052]の第 7 節を参照）を 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）の連結とする（[FIDO-U2F-Message-Formats]の第 4.3 節を参照）。
[SEC1]の第 4.1.4 節に従い、第 2 手順で使用されたハッシュ関数として SHA-256 を使用して、verificationDataおよび certificate public keyを使ってsigを検証する。
任意で、x5cを調べ、外部から提供された知識を参照して、 attStmtがBasicまたは AttCAアテステーションを伝達するかどうかを決定する。
成功した場合、アテステーション型 Basic、AttCAまたは不確実、およびアテステーション信頼パスx5cを表す実装固有の値を返す。

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

None アテステーションステートメント形式は、WebAuthn 依存パーティがアテステーション情報を受け取りたくないことを示した場合に、認証器が提供するアテステーションステートメントを置き換えるために使用される。§ 5.4.7 アテステーション伝達設定列挙（列挙型 AttestationConveyancePreference）を参照すること。

認証器がアテステーションをサポートしない場合、認証器はこの形式のアテステーションステートメントを直接生成してもよい（MAY）。

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

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を表す実装固有の値を返す。

8.9. 複合アテステーションステートメント形式

"compound" アテステーションステートメント形式は、単一のセレモニーで複数の自己完結したアテステーションステートメントを渡すために使用される。

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

compound

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

任意。§ 6.5.3 アテステーション型を参照すること。

構文

複合アテステーションステートメントの構文は次のように定義される。

$$attStmtType //= (
                      fmt: "compound",
                      attStmt: [2* nonCompoundAttStmt]
                  )

nonCompoundAttStmt = { $$attStmtType } .within { fmt: text .ne "compound", * any => any }

署名手順

該当なし

検証手順

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

attStmtの各subStmtについてそれぞれ、アテステーションステートメント形式識別子subStmt.fmtに対応する検証手順を、検証手順の入力 subStmt、authenticatorDataおよびclientDataHashを使用して評価する。

1 つ以上のsubStmtで検証が失敗した場合、依存パーティのポリシーに基づいて適切な結果を決定する。
依存パーティのポリシーによって決定される十分な数の attStmtの項目が正常に検証された場合、成功した検証手順の出力の任意の組み合わせを表す実装固有の値を返す。

9. WebAuthn 拡張

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

すべての拡張はクライアント拡張であり、これはその拡張がクライアントとの通信およびクライアントによる処理を伴うことを意味する。クライアント拡張は次の手順およびデータを定義する。

登録拡張のためのnavigator.credentials.create() 拡張要求パラメーターおよび応答値。
認証拡張のためのnavigator.credentials.get() 拡張要求パラメーターおよび応答値。
登録拡張および認証拡張のためのクライアント拡張処理。

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

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

登録拡張のためのauthenticatorMakeCredential拡張要求パラメーターおよび応答値。
認証拡張のためのauthenticatorGetAssertion拡張要求パラメーターおよび応答値。
登録拡張および認証拡張のための認証器拡張処理。

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

すべてのWebAuthn 拡張は、クライアントと認証器の両方にとって任意（OPTIONAL）である。したがって、依存パーティが要求した拡張は、クライアントブラウザーまたは OS によって無視され、認証器へまったく渡されない場合もあり、認証器によって無視される場合もある（MAY）。拡張を無視することは WebAuthn API 処理では決して失敗とは見なされないため、依存パーティが API 呼び出しに拡張を含める場合、それらの拡張の一部または全部が無視される場合に対応できるようにしておかなければならない（MUST）。

すべてのWebAuthn 拡張は、クライアントまたは認証器がそれらをサポートしなくても、ユーザーのセキュリティまたはプライバシーを危険にさらさないよう定義されなければならない（MUST）。たとえば、拡張がクライアント処理を必要とする場合、JSON から CBOR へクライアント拡張入力を単純にトランスコードするだけの素朴なパススルーでは、意味的に無効な認証器拡張入力値が生成され、その結果、認証器によって拡張が無視されることを保証するよう定義できる。すべての拡張は任意（OPTIONAL）であるため、これによって API 操作が機能的に失敗することはない。

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

9.1. 拡張識別子

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

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

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

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

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

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

9.2. 拡張の定義

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

クライアントによって処理されるすべてのクライアント拡張は、 WebAuthn 依存パーティが、その拡張がクライアントによって処理されたことを認識できるよう、クライアント拡張出力値を返さなければならない（MUST）。同様に、認証器処理を必要とするすべての拡張は、依存パーティが、その拡張が認証器によって処理されたことを認識できるよう、認証器拡張出力を返さなければならない（MUST）。拡張がその他の結果値を必要としない場合、その拡張は、理解され処理されたことを示すためtrueに設定された JSON Boolean のクライアント拡張出力結果を返すよう定義するべきである（SHOULD）。同様に、その他の結果値を必要としない認証器拡張は値を返さなければならず（MUST）、理解され処理されたことを示すため trueに設定された CBOR Boolean の認証器拡張出力結果を返すべきである（SHOULD）。

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"
            }
        }
    }
});

拡張の定義では、そのクライアント拡張入力の有効な値を規定しなければならない（MUST）。クライアントは、無効なクライアント拡張入力を持つ拡張を無視するべきである（SHOULD）。拡張が依存パーティからのパラメーターを必要としない場合、その拡張は Boolean クライアント引数を取り、依存パーティによって拡張が要求されたことを示すためtrueに設定するものとして定義するべきである（SHOULD）。

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

次の例では、識別子webauthnExample_foobarを持つ拡張が、認証器拡張入力として符号なし整数を取り、認証器拡張出力として少なくとも 1 つのバイト文字列からなる配列を返すことを定義している。

$$extensionInput //= (
  webauthnExample_foobar: uint
)
$$extensionOutput //= (
  webauthnExample_foobar: [+ bytes]
)

一部の認証器は Bluetooth Low-Energy や NFC などの低帯域幅リンクを介して通信するため、拡張は可能な限り小さい認証器引数を定義することを目指すべきである（SHOULD）。

9.4. クライアント拡張処理

拡張は、クレデンシャルの作成またはアサーションの生成中に、クライアントに追加の処理要件を定義してもよい（MAY）。拡張のクライアント拡張入力は、このクライアント処理への入力として使用される。サポートされる各クライアント拡張について、クライアントはclientExtensions マップに、拡張識別子をキー、拡張のクライアント拡張入力を値とするエントリを追加する。

同様に、クライアント拡張出力は、 getClientExtensionResults() の結果において、拡張識別子をキー、各拡張のクライアント拡張出力値を値とする辞書として表現される。クライアント拡張入力と同様に、クライアント拡張出力は JSON でエンコード可能な値である。無視された拡張について値を返してはならない（MUST NOT）。

認証器処理を必要とする拡張は、クライアント拡張入力からCBOR 認証器拡張入力を決定するプロセス、および CBOR 認証器拡張出力と、使用する場合は未署名拡張出力から、クライアント拡張出力を決定するプロセスを定義しなければならない（MUST）。

9.5. 認証器拡張処理

処理される各認証器拡張のCBOR 認証器拡張入力値は、authenticatorMakeCredentialおよびauthenticatorGetAssertion 操作のextensions パラメーターに含まれる。extensionsパラメーターは CBORマップであり、各キーは拡張識別子、対応する値はその拡張の認証器拡張入力である。

同様に、拡張出力は認証器データのextensions部分に表現される。認証器データの extensions部分は CBOR マップであり、各キーは拡張識別子、対応する値はその拡張の認証器拡張出力である。

未署名拡張出力は、認証器データとは独立して表現され、認証器から、同じ拡張識別子をキーとする別のマップとして返される。このマップには、未署名出力を使用する認証器拡張のエントリだけが含まれる。未署名出力は、拡張が認証器データに対する署名を出力する場合（そうしなければ署名が自身に対して署名する必要があり、それは不可能である）や、一部の拡張出力を依存パーティへ送信するべきでない場合に有用である。

注: [FIDO-CTAP]では、未署名拡張出力は、authenticatorMakeCredentialおよびauthenticatorGetAssertionの両方から、 unsignedExtensionOutputsという名前のトップレベルフィールド内の CBOR マップとして返される。

サポートされる各拡張について、その拡張の認証器拡張処理規則を使用して、認証器拡張入力および必要に応じてその他の入力から、認証器拡張出力と、使用する場合は未署名拡張出力を作成する。無視された拡張について値を返してはならない（MUST NOT）。

10. 定義済み拡張

この節およびその各小節では、[RFC8809]によって確立された IANA "WebAuthn Extension Identifiers" レジストリ[IANA-WebAuthn-Registries]に登録される追加の拡張群を定義する。これらは、広範な相互運用性を対象とするユーザーエージェントによって実装されてもよい（MAY）。

10.1. クライアント拡張

この節では、クライアント拡張のみである拡張を定義する。

10.1.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 の両方を混在させてもよい（MAY）。この拡張を介してappid を指定しても、ユーザーがrpIdで指定されたRP IDにスコープ設定された WebAuthn 登録済みクレデンシャルを使用することを妨げない。
アサーションを検証する際、 rpIdHash はRP IDではなくAppIDのハッシュであってもよい（MAY）ことを想定する。

この拡張では 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を指定する単一の DOMString。

partial dictionary AuthenticationExtensionsClientInputs {
  DOMString appid;
};
partial dictionary AuthenticationExtensionsClientInputsJSON {
  DOMString appid;
};

クライアント拡張処理

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

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

クライアント拡張出力

outputの値を返す。true の場合、AppIDが使用されたため、アサーションを検証する際、依存パーティは rpIdHash がRP IDではなくAppIDのハッシュであることを想定しなければならない（MUST）。

partial dictionary AuthenticationExtensionsClientOutputs {
  boolean appid;
};
partial dictionary AuthenticationExtensionsClientOutputsJSON {
  boolean appid;
};

認証器拡張入力

なし。

認証器拡張処理

なし。

認証器拡張出力

なし。

10.1.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を指定する単一の DOMString。

partial dictionary AuthenticationExtensionsClientInputs {
  DOMString appidExclude;
};
partial dictionary AuthenticationExtensionsClientInputsJSON {
  DOMString appidExclude;
};

クライアント拡張処理

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

RP ID を確立する直後に次の手順を実行する。
1. facetIdを、呼び出し元のオリジンを FIDO アルゴリズム呼び出し元アプリケーションの FacetID を決定するへ渡した結果とする。
2. appIdを拡張入力appidExcludeの値とする。
3. facetIdおよびappIdを FIDO アルゴリズム呼び出し元の FacetID が AppID に対して認可されているかを決定するへ渡す。後者のアルゴリズムが appIdを拒否した場合、 "SecurityError" DOMException を返し、新しいクレデンシャルを作成するアルゴリズムとこれらの手順を終了する。
  
  注: 実際には、いくつかの実装は呼び出し元の FacetID が AppID に対して認可されているかを決定するアルゴリズムの第 4 手順以降を実装していない。代わりに、第 3 手順では host の比較を緩和し、同一サイト上の host を受け入れる。
4. それ以外の場合、通常の処理を続行する。
authenticatorMakeCredential を呼び出す直前に次の手順を実行する。
1. authenticatorが U2F プロトコル[FIDO-U2F-Message-Formats]をサポートする場合、 excludeCredentialDescriptorList内の各クレデンシャル記述子 Cについてそれぞれ:
  1. Cがauthenticator上で U2F を使用して作成されたかどうかを、「5 つの部分」を次の値に設定した U2F_AUTHENTICATEメッセージをauthenticatorへ送信して確認する。
    
    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;
};
partial dictionary AuthenticationExtensionsClientOutputsJSON {
  boolean appidExclude;
};

認証器拡張入力

なし。

認証器拡張処理

なし。

認証器拡張出力

なし。

10.1.3. クレデンシャルプロパティ拡張（credProps）

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

現時点では 1 つのクレデンシャルプロパティ、すなわちクライアント側で発見可能なクレデンシャルプロパティが定義されている。

拡張識別子

credProps

操作の適用対象

登録

クライアント拡張入力

この拡張が依存パーティによって要求されたことを示す Boolean 値true。

partial dictionary AuthenticationExtensionsClientInputs {
    boolean credProps;
};
partial dictionary AuthenticationExtensionsClientInputsJSON {
    boolean credProps;
};

クライアント拡張処理

rk を、authenticatorMakeCredentialの呼び出しで使用された requireResidentKeyパラメーターの値に設定する。

クライアント拡張出力

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

dictionary CredentialPropertiesOutput {
    boolean rk;
};

partial dictionary AuthenticationExtensionsClientOutputs {
    CredentialPropertiesOutput credProps;
};
partial dictionary AuthenticationExtensionsClientOutputsJSON {
    CredentialPropertiesOutput credProps;
};

rk, 型は boolean

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

注: 一部の認証器は、クライアントプラットフォームから要求されていなくても発見可能なクレデンシャルを作成する。このため、クライアントプラットフォームは、rk プロパティをfalseに設定できるという確証がないため、省略せざるを得ない場合がある。依存パーティは、credProps拡張がサポートされている場合、クライアントプラットフォームはrk プロパティを設定するよう努めると想定するべきである。したがってrk が存在しない場合、作成されたクレデンシャルは非発見可能クレデンシャルである可能性が最も高いことを示す。

認証器拡張入力

なし。

認証器拡張処理

なし。

認証器拡張出力

なし。

10.1.4. 疑似乱数関数拡張

このクライアント登録拡張および認証拡張により、依存パーティは、クレデンシャルに関連付けられた疑似乱数関数（PRF）の出力を評価できる。この拡張によって提供される PRF は、任意の長さのBufferSourceから 32 バイトのBufferSourceへの写像である。

動機付けとなる例として、PRF 出力をユーザーデータの暗号化に使用する対称鍵として使用できる。このような暗号化データは、関連付けられたクレデンシャルからアサーションを取得できなければアクセスできない。以下の規定を使用して、単一のアサーション操作で 2 つの入力について PRF を評価することで、新しいランダム入力を選び、新しい出力の下で再暗号化することにより、アサーション時に暗号化鍵を定期的にローテーションできる。評価入力が予測不能であれば、ユーザー検証を満たすことができ、認証器へ時間制限付きでアクセスできる攻撃者であっても、正しい PRF 入力を知らなければ暗号化鍵を知ることはできない。

この拡張は[FIDO-CTAP]のhmac-secret拡張を基礎としてモデル化されているが、他の手段で実装することもできる。これは別個のクライアント拡張である。これはhmac-secretでは入力および出力を、ユーザーエージェントのみが実行できる方法で暗号化する必要があり、また WebAuthn による使用と基盤プラットフォームによる使用を分離するためである。この分離は、任意の入力について PRF が評価されるのを防ぐため、提供された PRF 入力をコンテキスト文字列とともにハッシュすることで実現される。

hmac-secret拡張はクレデンシャルごとに 2 つの PRF を提供する。1 つはユーザー検証が実行される要求に使用され、もう 1 つはその他すべての要求に使用される。この拡張はクレデンシャルごとに 1 つの PRF のみを公開し、 hmac-secret上に実装する場合、その PRF はユーザー検証が実行される場合に使用されるものでなければならない（MUST）。必要な場合、これはUserVerificationRequirement を上書きする。

この拡張は[FIDO-CTAP]を使用しない認証器に対して実装してもよい（MAY）。そのようなクライアントと認証器間のインターフェース、および認証器による PRF の構築は、抽象的にのみ規定される。

注: hmac-secret上に実装すると、それ以外の場合には存在しない認証器拡張出力が生成される。これらの出力は暗号化されており、依存パーティは使用できないが、認証器データは署名されているため、クライアントによって削除することもできない。

拡張識別子

prf

操作の適用対象

登録および認証

クライアント拡張入力

dictionary AuthenticationExtensionsPRFValues {
    required BufferSource first;
    BufferSource second;
};
dictionary AuthenticationExtensionsPRFValuesJSON {
    required Base64URLString first;
    Base64URLString second;
};

dictionary AuthenticationExtensionsPRFInputs {
    AuthenticationExtensionsPRFValues eval;
    record<DOMString, AuthenticationExtensionsPRFValues> evalByCredential;
};
dictionary AuthenticationExtensionsPRFInputsJSON {
    AuthenticationExtensionsPRFValuesJSON eval;
    record<DOMString, AuthenticationExtensionsPRFValuesJSON> evalByCredential;
};

partial dictionary AuthenticationExtensionsClientInputs {
    AuthenticationExtensionsPRFInputs prf;
};
partial dictionary AuthenticationExtensionsClientInputsJSON {
    AuthenticationExtensionsPRFInputsJSON prf;
};

eval, 型は AuthenticationExtensionsPRFValues: PRF を評価するための 1 つまたは 2 つの入力。すべての認証器がクレデンシャル作成中の PRF 評価をサポートするとは限らないため、出力が提供される場合も提供されない場合もある。提供されない場合、出力を取得するにはアサーションが必要となる。
evalByCredential, 型は record<DOMString, AuthenticationExtensionsPRFValues>: base64url でエンコードされたクレデンシャル IDから、そのクレデンシャルについて評価する PRF 入力へのレコード。allowCredentials が空でないアサーション中にのみ適用される。

クライアント拡張処理（登録）

evalByCredential が存在する場合、名前が「NotSupportedError」であるDOMException を返す。
eval が存在する場合:
- salt1を SHA-256(UTF8Encode("WebAuthn PRF") || 0x00 || eval.first) の値とする。
- eval.second が存在する場合、 salt2を SHA-256(UTF8Encode("WebAuthn PRF") || 0x00 || eval.second) の値とする。
認証器が CTAP2 hmac-secret拡張[FIDO-CTAP]をサポートする場合:
1. 認証器拡張入力内でhmac-secretをtrueに設定する。
2. salt1が定義されており、[FIDO-CTAP]の将来の拡張によって作成時の PRF 評価が許可される場合、 salt1および定義されている場合はsalt2の値を使用して hmac-secret入力を適切に設定する。
3. enabled を認証器拡張出力内のhmac-secretの値に設定する。存在しない場合、enabled をfalseに設定する。
4. results を、存在する場合、復号された PRF 結果に設定する。
認証器が CTAP2 hmac-secret拡張[FIDO-CTAP]をサポートしないが、以下で定義される抽象的な認証器処理と互換性のある別の実装をサポートする場合:
1. enabled をtrueに設定する。
2. salt1が定義されている場合、未規定の仕組みを使用して salt1および、定義されている場合はsalt2を、その順序で PRF 入力として認証器へ伝達する。
3. 未規定の仕組みを使用して認証器から PRF 出力を受信する。存在する場合、 results を評価結果に設定する。

クライアント拡張処理（認証）

evalByCredential が空でない一方、allowCredentials が空の場合、名前が「NotSupportedError」であるDOMException を返す。
evalByCredential 内のいずれかのキーが空文字列であるか、有効なbase64url エンコーディングでないか、またはbase64url デコード後にallowCredentials のいずれかの要素のid と等しくない場合、名前が「SyntaxError」であるDOMException を返す。
prf 拡張出力を空の辞書として初期化する。
evを null とし、適用可能な PRF 入力を検索する。
1. evalByCredential が存在し、返されるクレデンシャル IDのbase64url エンコーディングをキーとするエントリを含む場合、 evをそのエントリの値とする。
2. evが null で、eval が存在する場合、evをevalの値とする。
evが null でない場合:
1. salt1を SHA-256(UTF8Encode("WebAuthn PRF") || 0x00 || ev.first) の値とする。
2. ev.second が存在する場合、salt2を SHA-256(UTF8Encode("WebAuthn PRF") || 0x00 || ev.second) の値とする。
3. 認証器が CTAP2 hmac-secret拡張[FIDO-CTAP]をサポートする場合:
  1. salt1および設定されている場合はsalt2を、その処理で同名のパラメーターとして使用して、認証器へ hmac-secret拡張を送信する。
  2. 拡張結果を復号し、存在する場合、results を PRF 結果に設定する。
4. 認証器が CTAP2 hmac-secret拡張[FIDO-CTAP]をサポートしないが、以下で定義される抽象的な認証器処理と互換性のある別の実装をサポートする場合:
  1. 未規定の仕組みを使用してsalt1および、定義されている場合は salt2を、その順序で PRF 入力として認証器へ伝達する。
  2. 未規定の仕組みを使用して、認証器から PRF 出力をAuthenticationExtensionsPRFValues 値resultsとして受信する。 results をresultsに設定する。

認証器拡張入力 / 出力

この拡張は、認証器の実装を抽象化し、 [FIDO-CTAP]のhmac-secret 拡張、またはクライアントと認証器の通信のための未規定のインターフェースのいずれかを使用する。したがって、次の要件を除き、入力および出力用の CBOR インターフェースを規定しない。

認証器拡張出力に平文の PRF 出力を含めてはならない（MUST NOT）。

注: これは認証器データが署名されているためであり、 PublicKeyCredential を依存パーティサーバーへ送信する必要がある場合、認証器拡張出力を省略することはできない。これは、PRF 出力を使用して暗号化鍵を導出するなど、PRF 出力をクライアント側だけに秘匿する必要があるユースケースにとって重要である。

認証器拡張処理

[FIDO-CTAP]のhmac-secret 拡張をサポートする認証器は、その拡張で定義される認証器処理を実装する。

[FIDO-CTAP]のhmac-secret 拡張をサポートしない認証器は、代わりに次の抽象手順を実装してもよい（MAY）。

PRFを、現在のクレデンシャルに関連付けられた疑似乱数関数とする。未初期化の場合は関連付けを初期化する。

PRFを、出力が正確に 32 バイト長であり、少なくとも 2²⁵⁶ 個のそのような関数から一様ランダムに選択された疑似乱数関数とする。 PRFの選択はユーザー検証の状態から独立していなければならない（MUST）。選択されたPRFは、この拡張の実装以外の目的に使用するべきではない（SHOULD NOT）。 PRFを現在のクレデンシャルに、そのクレデンシャルの存続期間中関連付ける。
未規定の仕組みを使用して、PRF 入力salt1および任意で salt2をクライアントからその順序で受信する。何も受信しない場合、salt1およびsalt2を未定義とする。
salt1が定義されている場合:
1. resultsを、与えられた入力におけるPRFの評価を含むAuthenticationExtensionsPRFValues 構造とする。
  - results.first をPRF(salt1)に設定する。
  - salt2が定義されている場合、 results.second をPRF(salt2)に設定する。
2. 未規定の仕組みを使用して、resultsを PRF 出力としてクライアントへ伝達する。

クライアント拡張出力

dictionary AuthenticationExtensionsPRFOutputs {
    boolean enabled;
    AuthenticationExtensionsPRFValues results;
};
dictionary AuthenticationExtensionsPRFOutputsJSON {
    boolean enabled;
    AuthenticationExtensionsPRFValuesJSON results;
};

partial dictionary AuthenticationExtensionsClientOutputs {
    AuthenticationExtensionsPRFOutputs prf;
};
partial dictionary AuthenticationExtensionsClientOutputsJSON {
    AuthenticationExtensionsPRFOutputsJSON prf;
};

enabled, 型は boolean

作成されたクレデンシャルで PRF を使用できる場合に限りtrue。これは登録中にのみ報告され、認証の場合には存在しない。

results, 型は AuthenticationExtensionsPRFValues

eval またはevalByCredentialで与えられた入力について PRF を評価した結果。登録中には出力を利用できない場合がある。evalの注記を参照すること。

一部のユースケース、たとえば PRF 出力を使用してクライアント側でのみ使用する暗号化鍵を導出する場合、PublicKeyCredential をリモートサーバーへ送信する場合には、このresults 出力を省略する必要がある場合がある。たとえば§ 7 WebAuthn 依存パーティの操作の手順を実行する場合である。特に、 PublicKeyCredential.toJSON() によって返されるRegistrationResponseJSON およびAuthenticationResponseJSON は、このresults 出力が存在する場合、それを含むことに注意すること。

10.1.5. 大容量 blob ストレージ拡張（largeBlob）

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

注: 依存パーティは、不透明なデータが容量制限のあるデバイスへ書き込まれる際に圧縮されると想定できるため、自身で圧縮する必要はない。

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

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

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

注: クロスプラットフォームトランスポートプロトコルとして[FIDO-CTAP]を使用するローミング認証器は、このLarge Blob 拡張を発見可能なクレデンシャルについてのみサポートし、 authenticatorSelection.residentKey がpreferred またはrequiredに設定されていない限り、エラーを返す場合がある。ただし、[FIDO-CTAP]を使用しない認証器は、この拡張を発見可能なクレデンシャルに限定するとは限らない。

拡張識別子

largeBlob

操作の適用対象

登録および認証

クライアント拡張入力

partial dictionary AuthenticationExtensionsClientInputs {
    AuthenticationExtensionsLargeBlobInputs largeBlob;
};
partial dictionary AuthenticationExtensionsClientInputsJSON {
    AuthenticationExtensionsLargeBlobInputsJSON largeBlob;
};

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

dictionary AuthenticationExtensionsLargeBlobInputs {
    DOMString support;
    boolean read;
    BufferSource write;
};
dictionary AuthenticationExtensionsLargeBlobInputsJSON {
    DOMString support;
    boolean read;
    Base64URLString 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]](origin, options, sameOriginWithAncestors)の手順 12での拡張処理中に発生する。満足できる認証器が利用可能にならなければ、AuthenticationExtensionsLargeBlobOutputs は破棄される。
2. 候補認証器が利用可能になった場合（[[Create]](origin, options, sameOriginWithAncestors)の手順 22）、 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]](origin, options, sameOriginWithAncestors)内で）、アサートされたクレデンシャルに関連付けられた largeBlob データの読み取りを試みる。
3. 成功した場合、blob を結果に設定する。
  
  注: 読み取りが成功しなかった場合、largeBlob はAuthenticationExtensionsClientOutputs に存在するが、blob メンバーは存在しない。
write が存在する場合:
1. allowCredentials が正確に 1 つの要素を含まない場合:
  1. 名前が「NotSupportedError」であるDOMException を返す。
2. アサーション操作が成功した場合、write の内容を、示されたクレデンシャルに関連付けて認証器に保存することを試みる。
3. 成功した場合はwritten をtrueに設定し、それ以外の場合はfalseに設定する。

クライアント拡張出力

partial dictionary AuthenticationExtensionsClientOutputs {
    AuthenticationExtensionsLargeBlobOutputs largeBlob;
};
partial dictionary AuthenticationExtensionsClientOutputsJSON {
    AuthenticationExtensionsLargeBlobOutputsJSON largeBlob;
};

dictionary AuthenticationExtensionsLargeBlobOutputs {
    boolean supported;
    ArrayBuffer blob;
    boolean written;
};
dictionary AuthenticationExtensionsLargeBlobOutputsJSON {
    boolean supported;
    Base64URLString blob;
    boolean written;
};

supported, 型は boolean: 作成されたクレデンシャルが large blob の保存をサポートする場合に限りtrue。登録出力にのみ存在する。
blob, 型は ArrayBuffer: rawIdで識別されるクレデンシャルに関連付けられていた不透明なバイト文字列。read がtrueであった場合にのみ有効。
written, 型は boolean: write の内容が、指定されたクレデンシャルに関連付けて認証器上に正常に保存されたことを示す Boolean。

認証器拡張処理

この拡張は、ユーザーエージェントに、認証器上へ large blob を保存するか、認証器から取得させる。したがって、依存パーティ向けの直接的な認証器操作は規定しない。

10.1.6. リモートクライアントデータ JSON 拡張（remoteClientDataJSON）

リモートデスクトップ Web クライアントにより、ユーザーはローカルのクライアント（Web）アプリケーションからリモートホストの（ネイティブ）デスクトップ環境を操作できる。

この登録拡張および認証拡張により、ユーザーはリモートデスクトップ Web クライアント内で、リモートホスト上で実行されるブラウザー内の Web サイトまたはアプリへサインインするために、ローカルのクライアントプラットフォームに接続された WebAuthn 認証器を使用できる。

これにより、Web ベースのリモートデスクトップ Web クライアントは、リモートの WebAuthn 要求をローカルで実行できる。ここでリモートデスクトップ Web クライアントは、リモートマシン上に存在する RP の代理として WebAuthn 要求を呼び出し、リモートマシン内の呼び出し元 RP とは異なるオリジンを持つ。

この拡張は強力な機能であり、使用前にオリジンごとの明示的な許可を必要とする。ユーザーエージェントは、要求時にこの許可をユーザーへ求めるべきではない（SHOULD NOT）。代わりに、付与はデバイス管理ポリシー（たとえば、特定のリモートデスクトップ Web クライアントのオリジンを列挙する管理対象ブラウザープロファイル、管理対象ブラウザーインスタンス、または管理対象デバイス）または WebAuthn クライアント設定での明示的なオリジンごとのユーザーオプトインを通じて管理される。この許可はオリジンごとに設定しなければならず（MUST）、すべてのオリジンを許可する機能を提供してはならない（MUST NOT）。

許可

この拡張は、どちらも"publickey-credentials-remote-client-data-json"という名前で識別される強力な機能（[Permissions]）およびポリシー制御機能（[Permissions-Policy]）を定義する。このポリシー制御機能の既定の許可リストは'none'である。この機能の既定の許可状態は "denied"であり、拡張は既定では利用できず、明示的に有効化しなければならないことを意味する。追加の側面は定義されないため、許可記述子型は既定でPermissionDescriptorとなる。

リモートデスクトップ Web クライアントは、ユーザーエージェントが現在のオリジンについてこの拡張を許可するよう設定されているかどうかを Permissions API を介して確認してもよい。

const status = await navigator.permissions.query({
    name: "publickey-credentials-remote-client-data-json"
});
if (status.state === "granted") {
    // クライアントは remoteClientDataJSON 拡張を許可するよう設定されている。リモートデスクトップフローを続行する。
}

拡張識別子

remoteClientDataJSON

操作の適用対象

登録および認証

クライアント拡張入力

partial dictionary AuthenticationExtensionsClientInputs {
    DOMString remoteClientDataJSON;
};
partial dictionary AuthenticationExtensionsClientInputsJSON {
    DOMString remoteClientDataJSON;
};

クライアント拡張処理（登録）

新しいクレデンシャルを作成する際、この拡張はそのアルゴリズム内のラベル付きポイントに次の手順を挿入する。

RP ID を確立するを次の手順で置き換える。
1. "publickey-credentials-remote-client-data-json"および現在の設定オブジェクトについて現在の許可状態を取得する結果が "granted"でない場合。
  1. "NotAllowedError" DOMExceptionをスローする。
2. pkOptions.rp.id が存在しない場合
  1. "NotAllowedError" DOMExceptionをスローする。
3. collectedClientDataを、remoteClientDataJSONを与えてJSON 文字列を Infra 値へ解析する結果とする。
  1. 上記の解析手順が失敗した場合、"EncodingError" DOMExceptionをスローする。
4. remoteOriginをcollectedClientDataの"origin"キーの値とする。
5. pkOptions.rp.id がremoteOriginの登録可能ドメインサフィックスであるか、または等しいかどうかの確認をスキップする。
  
  注: これは、ローカルクライアントがすべてのRP ID関連のオリジンチェックをリモートクライアントへ委譲することを意味する。
collectedClientData を構築する手順をスキップする。
1. collectedClientDataは、RP ID を確立する際に、与えられたremoteClientDataJSONから解析済みである。
2. ユーザーエージェントは、collectedClientDataの内容を追加、削除、変更してはならない（MUST NOT）。そうするとリモートマシンが計算した clientDataJSONが無効になり、依存パーティで署名不一致が生じるためである。
クライアントデータをシリアル化する手順では、代わりにclientDataJSONをremoteClientDataJSONに設定する。
1. ユーザーエージェントは、ここでclientDataJSONを構築するために remoteClientDataJSONの内容を追加、削除、変更してはならない（MUST NOT）。そうするとリモートマシンが計算したclientDataJSONが無効になり、依存パーティで署名不一致が生じるためである。

クライアント拡張処理（認証）

認証アサーションを生成する際、この拡張はそのアルゴリズム内のラベル付きポイントに次の手順を挿入する。

RP ID を確立するを次の手順で置き換える。
1. "publickey-credentials-remote-client-data-json"および現在の設定オブジェクトについて現在の許可状態を取得する結果が "granted"でない場合。
  1. "NotAllowedError" DOMExceptionをスローする。
2. pkOptions.rp.id が存在しない場合
  1. "NotAllowedError" DOMExceptionをスローする。
3. collectedClientDataを、remoteClientDataJSONを与えてJSON 文字列を Infra 値へ解析する結果とする。
  1. 上記の解析手順が失敗した場合、"EncodingError" DOMExceptionをスローする。
4. remoteOriginをcollectedClientDataの"origin"キーの値とする。
5. pkOptions.rp.id がremoteOriginの登録可能ドメインサフィックスであるか、または等しいかどうかの確認をスキップする。
  
  注: これは、ローカルクライアントがすべてのRP ID関連のオリジンチェックをリモートクライアントへ委譲することを意味する。
collectedClientData を構築する手順をスキップする。
1. collectedClientDataは、RP ID を確立する際に、与えられたremoteClientDataJSONから解析済みである。
2. ユーザーエージェントは、collectedClientDataの内容を追加、削除、変更してはならない（MUST NOT）。そうするとリモートマシンが計算した clientDataJSONが無効になり、依存パーティで署名不一致が生じるためである。
クライアントデータをシリアル化する手順では、代わりにclientDataJSONをremoteClientDataJSONに設定する。
1. ユーザーエージェントは、ここでclientDataJSONを構築するために remoteClientDataJSONの内容を追加、削除、変更してはならない（MUST NOT）。そうするとリモートマシンが計算したclientDataJSONが無効になり、依存パーティで署名不一致が生じるためである。

認証器拡張入力

なし

認証器拡張処理

なし

認証器拡張出力

なし

クライアント拡張出力

拡張が処理されたことを依存パーティに示すため、値trueを返す。

partial dictionary AuthenticationExtensionsClientOutputs {
  boolean remoteClientDataJSON;
};
partial dictionary AuthenticationExtensionsClientOutputsJSON {
  boolean remoteClientDataJSON;
};

10.2. 認証器拡張

この節では、クライアント拡張と認証器拡張の両方である拡張を定義する。

この節は現在空である。

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

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

11.1. WebAuthn WebDriver 拡張機能

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

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

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

valueがbooleanでない場合、WebDriver エラーを、 WebDriver エラーコード無効な引数とともに返す。
それ以外の場合、deserializedをvalueに設定する。

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

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

11.1.1. 認証器拡張機能

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

機能	キー	値の型	説明
疑似乱数関数拡張のサポート	`"webauthn:extension:prf"`	boolean	エンドポイントノードの WebAuthn WebDriver 実装が prf拡張をサポートするかどうかを示す。
Large Blob ストレージ拡張のサポート	`"webauthn:extension:largeBlob"`	boolean	エンドポイントノードの WebAuthn WebDriver 実装が largeBlob 拡張をサポートするかどうかを示す。
credBlob 拡張のサポート	`"webauthn:extension:credBlob"`	boolean	エンドポイントノードの WebAuthn WebDriver 実装が、 [FIDO-CTAP]で定義される`credBlob`拡張をサポートするかどうかを示す。

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

valueがbooleanでない場合、WebDriver エラーを、 WebDriver エラーコード無効な引数とともに返す。
それ以外の場合、deserializedをvalueに設定する。

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

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

定義済み認証器拡張を実装するユーザーエージェントは、対応する認証器拡張機能を実装するべきである（SHOULD）。

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配列に存在するすべての認証器拡張をサポートしなければならない（MUST）。 extensions配列に存在しない認証器拡張をサポートしてはならない（MUST NOT）。

defaultBackupEligibility

新たに作成される公開鍵クレデンシャルソースについて、バックアップ適格性クレデンシャルプロパティの既定状態を決定する。この値は、この仮想認証器でauthenticatorMakeCredential 操作を実行する際、BE 認証器データフラグに反映されなければならない（MUST）。

defaultBackupState

新たに作成される公開鍵クレデンシャルソースについて、バックアップ状態クレデンシャルプロパティの既定状態を決定する。この値は、この仮想認証器でauthenticatorMakeCredential 操作を実行する際、BS 認証器データフラグに反映されなければならない（MUST）。

11.3. 仮想認証器の追加

仮想認証器の追加 WebDriver 拡張コマンドは、ソフトウェアの仮想認証器を作成する。次のように定義される。

HTTP メソッド	URI テンプレート
POST	`/session/{session id}/webauthn/authenticator`

認証器設定は、parametersとしてリモートエンド手順へ渡される JSON オブジェクトである。次の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	拡張識別子を含む配列	空の配列
`defaultBackupEligibility`	boolean	`true`, `false`	`false`
`defaultBackupState`	boolean	`true`, `false`	`false`

リモートエンド手順は次のとおりである。

parametersが JSON オブジェクトでない場合、WebDriver エラーを、WebDriver エラーコード無効な引数とともに返す。

注: parametersは認証器設定オブジェクトである。
authenticatorを新しい仮想認証器とする。
parameters内の列挙可能な各自身のプロパティについて:
1. keyをプロパティの名前とする。
2. valueを、parametersからkeyという名前のプロパティを取得した結果とする。
3. 認証器設定にkeyと一致するkeyがない場合、 WebDriver エラーを、 WebDriver エラーコード無効な引数とともに返す。
4. valueがそのkeyの有効な値のいずれでもない場合、 WebDriver エラーを、WebDriver エラーコード無効な引数とともに返す。
5. authenticator上でkeyというプロパティを設定し、値をvalueとする。
認証器設定内で既定値が定義されている各プロパティについて:
1. keyがauthenticatorの定義済みプロパティでない場合、authenticator上で keyというプロパティを設定し、 defaultを値とする。
認証器設定内の各プロパティについて:
1. keyがauthenticatorの定義済みプロパティでない場合、 WebDriver エラーを、WebDriver エラーコード無効な引数とともに返す。
authenticator.extensions内の各extensionについて:
1. extensionがエンドポイントノードの WebAuthn WebDriver 実装によってサポートされる拡張識別子でない場合、 WebDriver エラーを、WebDriver エラーコードサポートされていない操作とともに返す。
有効で一意なauthenticatorIdを生成する。
authenticator上でauthenticatorIdというプロパティを設定し、 authenticatorIdを値とする。
authenticatorを仮想認証器データベースに保存する。
データauthenticatorIdとともに成功を返す。

11.4. 仮想認証器の削除

仮想認証器の削除 WebDriver 拡張コマンドは、以前に作成された仮想認証器を削除する。次のように定義される。

HTTP メソッド	URI テンプレート
DELETE	`/session/{session id}/webauthn/authenticator/{authenticatorId}`

リモートエンド手順は次のとおりである。

authenticatorIdが仮想認証器データベースに保存されたどの仮想認証器とも一致しない場合、 WebDriver エラーを、WebDriver エラーコード無効な引数とともに返す。
authenticatorIdで識別される仮想認証器を仮想認証器データベースから削除する。
成功を返す。

11.5. クレデンシャルの追加

クレデンシャルの追加 WebDriver 拡張コマンドは、公開鍵クレデンシャルソースを既存の仮想認証器に注入する。次のように定義される。

HTTP メソッド	URI テンプレート
POST	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credential`

クレデンシャルパラメーターは、parametersとしてリモートエンド手順に渡される JSON オブジェクトである。次のkeyとvalueのペアを含む。

キー	説明	値の型
`credentialId`	クレデンシャル IDをBase64url エンコーディングを使用してエンコードしたもの。	string
`isResidentCredential`	`true`に設定されている場合、クライアント側で発見可能なクレデンシャルが作成される。`false`に設定されている場合、代わりにサーバー側クレデンシャルが作成される。	boolean
`rpId`	クレデンシャルがスコープ設定される依存パーティ ID。	string
`privateKey`	[RFC5958]に従って単一の秘密鍵を含む非対称鍵パッケージであり、Base64url エンコーディングを使用してエンコードされる。	string
`userHandle`	クレデンシャルに関連付けられたuserHandleを Base64url エンコーディングを使用してエンコードしたもの。このプロパティは定義されていない場合がある。	string
`signCount`	このプロパティは必須である。`0`から`4294967295`までの範囲（両端を含む）の 32 ビット符号なし整数値、または`null`でなければならない。 `signCount`が符号なし整数値の場合、署名カウンターがクレデンシャルに関連付けられ、 authenticatorGetAssertion操作中に増加する。 `signCount`が`null`の場合、署名カウンターはクレデンシャルに関連付けられない。	number または null
`largeBlob`	クレデンシャルごとの大きな blobであり、公開鍵クレデンシャルソースに関連付けられ、Base64url エンコーディングを使用してエンコードされる。このプロパティは定義されていない場合がある。	string
`backupEligibility`	公開鍵クレデンシャルソースについてシミュレートされるバックアップ適格性。設定されていない場合、値は仮想認証器の `defaultBackupEligibility`プロパティを既定値とする。シミュレートされるバックアップ適格性は、この公開鍵クレデンシャルソースで authenticatorGetAssertion操作を実行する際、 BE 認証器データフラグに反映されなければならない（MUST）。	boolean
`backupState`	公開鍵クレデンシャルソースについてシミュレートされるバックアップ状態。設定されていない場合、値は仮想認証器の `defaultBackupState`プロパティを既定値とする。シミュレートされるバックアップ状態は、この公開鍵クレデンシャルソースで authenticatorGetAssertion操作を実行する際、 BS 認証器データフラグに反映されなければならない（MUST）。	boolean
`userName`	クレデンシャルに関連付けられた`user`の `name`。設定されていない場合、値は空文字列を既定値とする。	string
`userDisplayName`	クレデンシャルに関連付けられた`user`の `displayName`。設定されていない場合、値は空文字列を既定値とする。	string

リモートエンド手順は次のとおりである。

parametersが JSON オブジェクトでない場合、 WebDriver エラーを、WebDriver エラーコード無効な引数とともに返す。

注: parametersはクレデンシャルパラメーターオブジェクトである。
credentialIdを、parametersのcredentialIdプロパティに対するBase64url エンコーディングのデコード結果とする。
credentialIdが失敗の場合、WebDriver エラーを WebDriver エラーコード無効な引数とともに返す。
isResidentCredentialをparametersのisResidentCredential プロパティとする。
isResidentCredentialが定義されていない場合、WebDriver エラーを WebDriver エラーコード無効な引数とともに返す。
rpIdをparametersのrpIdプロパティとする。
rpIdが有効なRP IDでない場合、WebDriver エラーをWebDriver エラーコード無効な引数とともに返す。
privateKeyを、parametersのprivateKeyプロパティに対するBase64url エンコーディングのデコード結果とする。
privateKeyが失敗の場合、WebDriver エラーを WebDriver エラーコード無効な引数とともに返す。
privateKeyが、[RFC5958]に従う、P-256 曲線上の単一の ECDSA 秘密鍵を含む有効にエンコードされた非対称鍵パッケージでない場合、WebDriver エラーを WebDriver エラーコード無効な引数とともに返す。
parametersのuserHandleプロパティが定義されている場合:
1. userHandleを、parametersのuserHandleプロパティに対するBase64url エンコーディングのデコード結果とする。
2. userHandleが失敗の場合、WebDriver エラーをWebDriver エラーコード無効な引数とともに返す。
それ以外の場合:
1. isResidentCredentialがtrueの場合、WebDriver エラーをWebDriver エラーコード無効な引数とともに返す。
2. userHandleをnullとする。
authenticatorIdが仮想認証器データベースに保存されたどの仮想認証器とも一致しない場合、WebDriver エラーをWebDriver エラーコード無効な引数とともに返す。
authenticatorをauthenticatorIdに一致する仮想認証器とする。
isResidentCredentialがtrueで、authenticatorの hasResidentKeyプロパティがfalseの場合、 WebDriver エラーをWebDriver エラーコード無効な引数とともに返す。
authenticatorがlargeBlob拡張をサポートし、parametersの largeBlob機能が定義されている場合:
1. largeBlobを、parametersのlargeBlobプロパティに対するBase64url エンコーディングのデコード結果とする。
2. largeBlobが失敗の場合、WebDriver エラーをWebDriver エラーコード無効な引数とともに返す。
それ以外の場合:
1. largeBlobをnullとする。
backupEligibilityをparametersのbackupEligibilityプロパティとする。
backupEligibilityが定義されていない場合、backupEligibilityを authenticatorのdefaultBackupEligibilityの値に設定する。
backupStateをparametersのbackupStateプロパティとする。
backupStateが定義されていない場合、backupStateを authenticatorのdefaultBackupStateの値に設定する。
userNameをparametersのuserNameプロパティとする。
userNameが定義されていない場合、userNameを空文字列に設定する。
userDisplayNameをparametersのuserDisplayNameプロパティとする。
userDisplayNameが定義されていない場合、userDisplayNameを空文字列に設定する。
credentialを、isResidentCredentialがtrueの場合は新しいクライアント側で発見可能な公開鍵クレデンシャルソース、それ以外の場合は次の項目を持つサーバー側公開鍵クレデンシャルソースとする。

type

public-key

id

credentialId

privateKey

privateKey

rpId

rpId

userHandle

userHandle

otherUI

userNameおよびuserDisplayNameから構築する。
credentialのバックアップ適格性クレデンシャルプロパティを backupEligibilityに設定する。
credentialのバックアップ状態クレデンシャルプロパティを backupStateに設定する。
signCountをparametersのsignCountプロパティとする。
signCountが定義されていない場合、WebDriver エラーを WebDriver エラーコード無効な引数とともに返す。
signCountが0から4294967295までの範囲（両端を含む）の 32 ビット符号なし整数値に設定されている場合、署名カウンターcounterを credentialに関連付け、その初期値をsignCountと等しくする。
それ以外で、signCountがnullの場合、署名カウンターを credentialに関連付けない。
それ以外の場合、WebDriver エラーをWebDriver エラーコード無効な引数とともに返す。
largeBlobがnullでない場合、credentialに関連付けられたクレデンシャルごとの大きな blobをlargeBlobに設定する。
credentialおよびcounterをauthenticatorのデータベースに保存する。
成功を返す。

11.6. クレデンシャルの取得

クレデンシャルの取得 WebDriver 拡張コマンドは、仮想認証器に保存されたすべての公開鍵クレデンシャルソースについて 1 つのクレデンシャルパラメーターオブジェクトを返す。それらがクレデンシャルの追加またはnavigator.credentials.create()のどちらを使用して保存されたかは問わない。次のように定義される。

HTTP メソッド	URI テンプレート
GET	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credentials`

リモートエンド手順は次のとおりである。

authenticatorIdが仮想認証器データベースに保存されたどの仮想認証器とも一致しない場合、 WebDriver エラーをWebDriver エラーコード無効な引数とともに返す。
credentialsArrayを空の配列とする。
authenticatorIdで識別される認証器によって管理される各公開鍵クレデンシャルソース credentialについて、対応するクレデンシャルパラメーターオブジェクトを構築し、 credentialsArrayに追加する。
credentialsArrayを含むデータとともに成功を返す。

11.7. クレデンシャルの削除

クレデンシャルの削除 WebDriver 拡張コマンドは、仮想認証器に保存された公開鍵クレデンシャルソースを削除する。次のように定義される。

HTTP メソッド	URI テンプレート
DELETE	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credentials/{credentialId}`

リモートエンド手順は次のとおりである。

authenticatorIdが仮想認証器データベースに保存されたどの仮想認証器とも一致しない場合、 WebDriver エラーをWebDriver エラーコード無効な引数とともに返す。
authenticatorをauthenticatorIdで識別される仮想認証器とする。
credentialIdがauthenticatorによって管理されるどの公開鍵クレデンシャルソースとも一致しない場合、WebDriver エラーを WebDriver エラーコード無効な引数とともに返す。
authenticatorによって管理され、credentialIdで識別される公開鍵クレデンシャルソースを削除する。
成功を返す。

11.8. すべてのクレデンシャルの削除

すべてのクレデンシャルの削除 WebDriver 拡張コマンドは、仮想認証器に保存されたすべての公開鍵クレデンシャルソースを削除する。次のように定義される。

HTTP メソッド	URI テンプレート
DELETE	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credentials`

リモートエンド手順は次のとおりである。

authenticatorIdが仮想認証器データベースに保存されたどの仮想認証器とも一致しない場合、 WebDriver エラーをWebDriver エラーコード無効な引数とともに返す。
authenticatorIdで識別される仮想認証器によって管理されるすべての公開鍵クレデンシャルソースを削除する。
成功を返す。

11.9. ユーザー検証済みの設定

ユーザー検証済みの設定拡張コマンドは、仮想認証器のisUserVerifiedプロパティを設定する。次のように定義される。

HTTP メソッド	URI テンプレート
POST	`/session/{session id}/webauthn/authenticator/{authenticatorId}/uv`

ユーザー検証済み設定パラメーターは、parametersとしてリモートエンド手順へ渡される JSON オブジェクトである。次のkeyとvalueのペアを含む。

キー	説明	値の型
`isUserVerified`	仮想認証器上で実行されるユーザー検証の結果を決定する。`true`に設定されている場合、ユーザー検証は常に成功する。`false`に設定されている場合、失敗する。	boolean

リモートエンド手順は次のとおりである。

parametersが JSON オブジェクトでない場合、 WebDriver エラーをWebDriver エラーコード無効な引数とともに返す。

注: parametersはユーザー検証済み設定パラメーターオブジェクトである。
authenticatorIdが仮想認証器データベースに保存されたどの仮想認証器とも一致しない場合、 WebDriver エラーをWebDriver エラーコード無効な引数とともに返す。
isUserVerifiedがparametersの定義済みプロパティでない場合、WebDriver エラーをWebDriver エラーコード無効な引数とともに返す。
authenticatorをauthenticatorIdで識別される仮想認証器とする。
authenticatorのisUserVerifiedプロパティをparametersの isUserVerifiedプロパティに設定する。
成功を返す。

11.10. クレデンシャルプロパティの設定

クレデンシャルプロパティの設定拡張コマンドにより、仮想認証器の公開鍵クレデンシャルソースの複数のクレデンシャルプロパティを設定できる。次のように定義される。

HTTP メソッド	URI テンプレート
POST	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credentials/{credentialId}/props`

クレデンシャルプロパティ設定パラメーターは、parametersとしてリモートエンド手順へ渡される JSON オブジェクトである。次のkeyとvalueのペアを含む。

キー	説明	値の型
`backupEligibility`	バックアップ適格性クレデンシャルプロパティ。	boolean
`backupState`	バックアップ状態クレデンシャルプロパティ。	boolean
`signCount`	このプロパティは任意である。定義される場合、`0`から`4294967295`までの範囲（両端を含む）の 32 ビット符号なし整数値、または`null`であるべきである。`signCount`が符号なし整数値の場合、クレデンシャルは `signCount`に設定された署名カウンターで更新される。 `signCount`が`null`の場合、クレデンシャルに関連付けられている既存の署名カウンターはすべて削除される。	number または null

リモートエンド手順は次のとおりである。

parametersが JSON オブジェクトでない場合、 WebDriver エラーをWebDriver エラーコード無効な引数とともに返す。

注: parametersはクレデンシャルプロパティ設定パラメーターオブジェクトである。
authenticatorIdが仮想認証器データベースに保存されたどの仮想認証器とも一致しない場合、 WebDriver エラーをWebDriver エラーコード無効な引数とともに返す。
credentialを、credentialIdに一致し、authenticatorによって管理される公開鍵クレデンシャルソースとする。
credentialが空の場合、WebDriver エラーを WebDriver エラーコード無効な引数とともに返す。
backupEligibilityをparametersのbackupEligibilityプロパティとする。
backupEligibilityが定義されている場合、credentialのバックアップ適格性クレデンシャルプロパティを backupEligibilityの値に設定する。

注: 通常、backupEligibility プロパティは公開鍵クレデンシャルソースに対して永続的である。クレデンシャルプロパティの設定では、テストおよびデバッグ目的でこれを変更できる。
backupStateをparametersのbackupStateプロパティとする。
backupStateが定義されている場合、credentialのバックアップ状態クレデンシャルプロパティを backupStateの値に設定する。
signCountをparametersのsignCountプロパティとする。
signCountが定義されている場合:
1. signCountが0から 4294967295までの範囲（両端を含む）の 32 ビット符号なし整数値に設定されている場合、 credentialの既存の署名カウンターを signCountの値に設定する。credentialに署名カウンターがない場合、 1 つをcredentialに関連付け、signCountの値に設定する。
2. それ以外で、signCountがnullの場合、credentialに設定された署名カウンターをすべて削除する。
3. それ以外の場合、WebDriver エラーをWebDriver エラーコード無効な引数とともに返す。
成功を返す。

12. IANA に関する考慮事項

12.1. WebAuthn アテステーションステートメント形式識別子登録の更新

この節では、[RFC8809]によって確立された IANA "WebAuthn Attestation Statement Format Identifiers" レジストリ[IANA-WebAuthn-Registries]において、 [WebAuthn-1]で当初登録された、 § 8 定義済みアテステーションステートメント形式で定義される以下のアテステーションステートメント形式を、この仕様を参照するよう更新する。

WebAuthn アテステーションステートメント形式識別子: packed
説明: "packed" アテステーションステートメント形式は、アテステーション用に WebAuthn 向けに最適化された形式である。非常にコンパクトでありながら拡張可能なエンコーディング方法を使用する。この形式は、リソースが制限された認証器（たとえばセキュアエレメント）でも実装できる。
仕様文書: この仕様の§ 8.2 Packed アテステーションステートメント形式
WebAuthn アテステーションステートメント形式識別子: tpm
説明: TPM アテステーションステートメント形式は、packed アテステーションステートメント形式と同じ形式でアテステーションステートメントを返すが、rawData および signature フィールドの計算方法は異なる。
仕様文書: この仕様の§ 8.3 TPM アテステーションステートメント形式
WebAuthn アテステーションステートメント形式識別子: android-key
説明: バージョン "N" 以降のプラットフォーム認証器は、この独自の「ハードウェアアテステーション」ステートメントを提供してもよい。
仕様文書: この仕様の§ 8.4 Android Key アテステーションステートメント形式
WebAuthn アテステーションステートメント形式識別子: android-safetynet
説明: Android ベースのプラットフォーム認証器は、Android SafetyNet API に基づくアテステーションステートメントを生成してもよい（MAY）。
仕様文書: この仕様の§ 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 定義済み拡張で定義される以下の拡張識別子値を、[RFC8809]によって確立された IANA "WebAuthn Extension Identifiers" レジストリ[IANA-WebAuthn-Registries]において、[WebAuthn-1]で当初登録されたものから、この仕様を参照するよう更新する。

WebAuthn 拡張識別子: appid
説明: この認証拡張により、従来の FIDO JavaScript API を使用して以前にクレデンシャルを登録したWebAuthn 依存パーティは、アサーションを要求できる。
仕様文書: この仕様の§ 10.1.1 FIDO AppID 拡張 (appid)

12.4. WebAuthn 拡張識別子の登録

この節では、§ 10 定義済み拡張で新たに定義された以下の拡張識別子値を、[RFC8809]によって確立された IANA "WebAuthn Extension Identifiers" レジストリ[IANA-WebAuthn-Registries]に登録する。

WebAuthn 拡張識別子: appidExclude
説明: この登録拡張により、WebAuthn 依存パーティは、従来の FIDO U2F JavaScript API [FIDOU2FJavaScriptAPI]で作成された指定クレデンシャルを含む認証器を除外できる。
仕様文書: この仕様の§ 10.1.2 FIDO AppID 除外拡張 (appidExclude)
WebAuthn 拡張識別子: credProps
説明: このクライアント登録拡張により、新たに作成されたクレデンシャルのプロパティを、クライアントが決定したとおりに、呼び出し元のWebAuthn 依存パーティのWeb アプリケーションへ報告できる。
仕様文書: この仕様の§ 10.1.3 クレデンシャルプロパティ拡張 (credProps)
WebAuthn 拡張識別子: largeBlob
説明: このクライアント登録拡張および認証拡張により、依存パーティはクレデンシャルに関連付けられた不透明なデータを保存できる。
仕様文書: この仕様の§ 10.1.5 Large blob ストレージ拡張 (largeBlob)

12.5. Well-Known URI の登録

この節では、次の well-known URI を IANA "Well-Known URIs" レジストリ[IANA-Well-Known-URIs]に登録する。

URI サフィックス: webauthn
参照: この仕様の§ 5.11.1 関連オリジンの検証
ステータス: permanent
変更管理者: W3C Web Authentication Working Group (public-webauthn@w3.org)
関連情報: （なし）

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 を介してのみ通信できる場合、これらのトランスポートの限られた通信範囲により、悪意ある主体が認証器とやり取りするには、その範囲内に物理的に存在しなければならないことが保証される。リモートから呼び出せる認証器については、必ずしもそうとは限らない。認証器がユーザー存在を検証していても、ユーザーはリモートから開始された悪意ある要求を認可するよう騙される可能性がある。

クライアントと認証器が直接通信することで、クライアントはクレデンシャルのスコープ制限を適用できる。対照的に、クライアントと認証器の間の通信が第三者によって仲介される場合、クライアントは、その第三者がスコープ制限を適用し、認証器へのアクセスを制御すると信頼しなければならない。いずれかに失敗すると、悪意ある依存パーティが他の依存パーティに対して有効な認証アサーションを受信したり、悪意あるユーザーが他のユーザーの認証アサーションへアクセスできるようになる可能性がある。

認証器がクライアントの物理的に近くにある必要がないソリューション、またはクライアントと認証器が直接通信しないソリューションを設計する場合、設計者は、これがスコープ制限の適用、および認証器の所持しているものという認証要素としての強度にどのように影響するかを考慮するべきである（SHOULD）。

13.3. 認証器に関するセキュリティ上の考慮事項

13.3.1. アテステーション証明書階層

アテステーション証明書には 3 階層（すなわち、アテステーションルート、アテステーション発行 CA、アテステーション証明書）が推奨される（RECOMMENDED）。また、各WebAuthn 認証器のデバイスライン（すなわちモデル）ごとに、特定の認証器モデルのバージョンに関する問題を切り分けやすくするため、個別の発行 CA を使用することも推奨される（RECOMMENDED）。

アテステーションルート証明書が単一のWebAuthn 認証器デバイスライン（すなわち AAGUID）専用でない場合、AAGUID は認証器データと照合して検証できるよう、アテステーション証明書自体に指定するべきである（SHOULD）。

13.3.2. アテステーション証明書およびアテステーション証明書 CA の侵害

アテステーション証明書の発行に使用される中間 CA またはルート CA が侵害された場合でも、WebAuthn 認証器のアテステーション鍵ペアは安全なままだが、その証明書はもはや信頼できない。自身の認証器モデルのアテステーション公開鍵を記録しているWebAuthn 認証器製造元は、新しい中間 CA または新しいルート CA から、これらの鍵のための新しいアテステーション証明書を発行できる。ルート CA が変更された場合、WebAuthn 依存パーティは信頼するルート証明書を適切に更新しなければならない（MUST）。

WebAuthn 認証器のアテステーション証明書は、その秘密鍵が侵害された場合、発行 CA によって失効させなければならない（MUST）。WebAuthn 認証器の製造元は、漏えいがファームウェアの欠陥によるものであった場合、ファームウェア更新を配布し、新しいアテステーション秘密鍵および証明書を、すでに製造済みのWebAuthn 認証器へ注入する必要がある場合がある。（これが行われるプロセスは、この仕様の範囲外である。）WebAuthn 認証器製造元がこの能力を持たない場合、依存パーティが影響を受けたWebAuthn 認証器から今後のアテステーションステートメントを信頼することは不可能になる可能性がある。

§ 13.5.5 失効したアテステーション証明書にある、依存パーティに関する関連するセキュリティ上の考慮事項も参照すること。

13.4. クライアントに関するセキュリティ上の考慮事項

13.4.1. remoteClientDataJSON 拡張

remoteClientDataJSON拡張により、リモートデスクトップ Web クライアントは、リモートの依存パーティの代理として Web Authentication API要求をプロキシできる。これはWeb Authentication APIの信頼モデルを次の点で根本的に変更する。

オリジンの置換: ユーザーエージェントは、現在の実行コンテキストから導出する代わりに、呼び出し元のリモートデスクトップ Web クライアントによって提供されるorigin を受け入れる。したがって、この許可を付与するユーザーエージェントは、呼び出し元がリモートの依存パーティのオリジンを正確かつ誠実に提供すると信頼しなければならない（MUST）。
RP ID の検証: RP IDの検証はリモートクライアントへ委譲される。リモートクライアントは、関連オリジンおよびプラットフォーム固有のアプリ配布モデルを考慮してオリジンを検証するために必要なすべてのコンテキストを持つためである。したがって、この許可を付与するユーザーエージェントは、リモートクライアントがすべてのオリジンチェックに照らしてRP IDを正確かつ誠実に検証したと信頼しなければならない（MUST）。
オリジンごとの設定機構が必要: この拡張の許可はオリジンごとであるため、ユーザーエージェントは、ユーザーエージェントポリシー（たとえば UA 設定やエンタープライズポリシー）を介したオリジンごとの設定機構のみを提供しなければならない（MUST）。

この拡張を許可するユーザーエージェントは、リモートデスクトップ経由でプロキシされた WebAuthn 操作が進行中である場合、ユーザーの認証器がリモートでホストされたアプリケーションの代理として使用されていることをユーザーが理解できるよう、明確に伝えるべきである（SHOULD）。

13.5. 依存パーティに関するセキュリティ上の考慮事項

13.5.1. WebAuthn 依存パーティに対するセキュリティ上の利点

この仕様がWebAuthn 依存パーティに提供する主な利点には、次が含まれる。

広範に互換性があり、使いやすい多要素認証を使用して、ユーザーとアカウントを保護できる。
依存パーティは、ユーザーへ認証器ハードウェアを支給する必要がない。代わりに、各ユーザーは任意の適合認証器を独自に入手し、同じ認証器を任意の数の依存パーティで使用できる。依存パーティは、認証器から返されるアテステーションステートメントを調べることで、認証器のセキュリティプロパティに対する要件を任意で適用できる。
認証セレモニーは中間者攻撃に耐性がある。登録セレモニーについては、以下の§ 13.5.4 アテステーションの制限を参照すること。
依存パーティは、ほとんどまたはまったくコード変更することなく、複数種類のユーザー検証、たとえば PIN、生体認証、および/または将来の方法を自動的にサポートでき、各ユーザーが認証器の選択を通じて、使用したいものを決定できる。
依存パーティは、上記の利点を得るために追加の秘密情報を保存する必要がない。

適合性の節で述べたように、依存パーティは、上記のすべてのセキュリティ上の利点を得るため、§ 7 WebAuthn 依存パーティの操作で説明されたとおりに動作しなければならない（MUST）。ただし、これからわずかに逸脱する注目すべきユースケースの 1 つを、以下の§ 13.5.4 アテステーションの制限で説明する。

13.5.2. 埋め込み利用における可視性の考慮事項

§ 5.10 iframe 要素内での Web Authentication の使用で説明されているように、埋め込みコンテキスト、たとえば iframe内で WebAuthn を単純に使用すると、ユーザーがUI 偽装攻撃（"クリックジャッキング"とも呼ばれる）に対して脆弱になる可能性がある。これは、攻撃者が自身の UI を依存パーティの意図した UI の上に重ね、ユーザーを騙して依存パーティで意図しない操作を実行させようとするものである。たとえば、これらの手法を使用すると、攻撃者はユーザーを騙して商品を購入させたり、送金させたりできる可能性がある。

WebAuthn 固有の UI は通常クライアントプラットフォームによって処理されるため、UI 偽装に対して脆弱ではないが、 WebAuthn を使用する埋め込みコンテンツを持つ依存パーティにとって、そのコンテンツの UI がユーザーから見えることを確保することは重要である可能性が高い。そのための新たな手段の 1 つとして、実験的なIntersection Observer v2の isVisible属性の状態を監視する方法がある。たとえば、埋め込みコンテキストで実行される依存パーティのスクリプトは、 isVisbleがfalseに設定されていることを検出した場合、先回りして自身をポップアップウィンドウに読み込み、コンテンツの遮蔽を回避できる。

13.5.3. 暗号学的チャレンジ

暗号プロトコルとして、Web Authentication はリプレイ攻撃を回避するため、ランダム化されたチャレンジに依存する。したがって、PublicKeyCredentialCreationOptions.challenge とPublicKeyCredentialRequestOptions.challenge の両方の値は、依存パーティが信頼する環境（たとえばサーバー側）でランダムに生成しなければならず（MUST）、クライアントの応答で返されたchallenge 値は生成されたものと一致しなければならない（MUST）。これはクライアントの動作に依存しない方法で行うべきであり（SHOULD）、たとえば依存パーティは、操作が完了するまでチャレンジを一時的に保存するべきである（SHOULD）。不一致を許容すると、プロトコルのセキュリティが損なわれる。

チャレンジは、 WebAuthn セレモニーのタイムアウトに推奨される範囲と既定値の上限と同程度の期間、有効であるべきである（SHOULD）。

リプレイ攻撃を防ぐため、チャレンジには推測を実行不可能にするのに十分なエントロピーが含まれていなければならない（MUST）。したがってチャレンジは、少なくとも 16 バイト長であるべきである（SHOULD）。

13.5.4. アテステーションの制限

この節は規範的ではない。

新しいクレデンシャルを登録する際、アテステーションステートメントが存在する場合、それによってWebAuthn 依存パーティは、さまざまな認証器の品質について保証を導出できる場合がある。たとえば、認証器のモデルや、クレデンシャル秘密鍵をどのように保存し保護するかなどである。ただし、アテステーションステートメントだけでは、依存パーティがアテステーションオブジェクトがユーザーの意図した認証器によって生成され、中間者攻撃者によって生成されたものではないことを検証する手段を提供しない点に注意することが重要である。たとえば、そのような攻撃者は依存パーティのスクリプトへ注入された悪意あるコードを使用できる。したがって依存パーティは、アテステーションオブジェクトを中間者攻撃から保護するため、TLS および関連技術などの他の手段に依存しなければならない。

登録セレモニーが安全に完了し、認証器がクレデンシャル秘密鍵の機密性を維持するという前提の下では、その公開鍵クレデンシャルを使用する後続の認証セレモニーは、中間者攻撃による改ざんに耐性がある。

上記の議論はすべてのアテステーション型に当てはまる。すべての場合において、中間者攻撃者が、登録されるクレデンシャル公開鍵およびアテステーションステートメントを含むPublicKeyCredential オブジェクトを置き換え、その後、同じ依存パーティにスコープ設定され、同じ攻撃者を通過する将来の認証アサーションを改ざんすることが可能である。

このような攻撃は検出できる可能性がある。依存パーティはユーザーのものではなく攻撃者のクレデンシャル公開鍵を登録しているため、攻撃者はその依存パーティとの後続のすべての認証セレモニーを改ざんしなければならない。攻撃を受けずに行われたセレモニーは失敗し、攻撃が露見する可能性がある。

自己アテステーションおよびNone以外のアテステーション型は、このような攻撃の難易度を高める可能性がある。依存パーティが、たとえばモデル名称などの認証器情報をユーザーへ表示できる可能性があるためである。したがって攻撃者は、ユーザーの認証器と同じモデルの真正な認証器を使用する必要がある場合があり、またはユーザーは依存パーティがユーザーの予想とは異なる認証器モデルを報告していることに気付く可能性がある。

注: 上記で説明した中間者攻撃のすべての変種は、従来のパスワード認証に対する中間者攻撃よりも、攻撃者にとって実行が困難である。

13.5.5. 失効したアテステーション証明書

失効した中間アテステーション CA 証明書が原因でアテステーション証明書の検証に失敗し、かつ依存パーティのポリシーがこのような状況で登録/認証要求を拒否することを要求する場合、依存パーティは、 CA の侵害日より後に、同じ中間 CA までチェーンするアテステーション証明書を使用して登録された公開鍵クレデンシャルも登録解除する（または「自己アテステーション」と同等の信頼レベルを付与する）ことが推奨される（RECOMMENDED）。したがって、依存パーティは、そのような証明書の失効後に登録が行われた場合に関連する公開鍵クレデンシャルを登録解除するため、登録時に中間アテステーション CA 証明書を記憶することが推奨される（RECOMMENDED）。

§ 13.3.2 アテステーション証明書およびアテステーション証明書 CA の侵害にある、認証器に関する関連するセキュリティ上の考慮事項も参照すること。

13.5.6. クレデンシャルの喪失と鍵の可搬性

この仕様は、クレデンシャル秘密鍵をバックアップするプロトコルや、認証器間で共有するプロトコルを定義しない。一般に、クレデンシャル秘密鍵は、それを作成した認証器から決して外に出ないことが想定される。したがって、認証器を失うことは一般に、失われた認証器にバインドされたすべてのクレデンシャルを失うことを意味する。ユーザーが依存パーティに登録したクレデンシャルを 1 つしか持っていない場合、アカウントからロックアウトされる可能性がある。秘密鍵をバックアップまたは共有する代わりに、Web Authentication API は同じユーザーについて複数のクレデンシャルを登録できる。たとえば、ユーザーはよく使用するクライアントデバイスにプラットフォームクレデンシャルを登録し、バックアップ用途および新しい、または使用頻度の低いクライアントデバイスで使用するために、1 つ以上のローミングクレデンシャルを登録できる。

依存パーティは、ユーザーが同じユーザーアカウントに複数のクレデンシャルを登録することを許可し、推奨するべきである（SHOULD）。依存パーティは、これらの異なるクレデンシャルが異なる認証器にバインドされるようにするため、 excludeCredentials および user.id オプションを利用するべきである（SHOULD）。

13.5.7. 保護されていないアカウントの検出

この節は規範的ではない。

このセキュリティ上の考慮事項は、最初の認証手順として、空でないallowCredentials 引数を持つ認証セレモニーをサポートする依存パーティに適用される。たとえば、最初の認証手順としてサーバー側クレデンシャルによる認証を使用する場合である。

この場合、allowCredentials 引数は、どのユーザーアカウントに WebAuthn クレデンシャルが登録されており、どれに登録されていないかという情報を漏えいする危険があり、これはアカウント保護強度のシグナルになり得る。たとえば、攻撃者がユーザー名だけを提供して認証セレモニーを開始でき、依存パーティが一部のユーザーアカウントには空でないallowCredentialsを返し、他のユーザーアカウントには失敗またはパスワードチャレンジを返すとする。すると攻撃者は、後者のユーザーアカウントは認証成功のために WebAuthn アサーションを必要としない可能性が高いと結論付け、より弱い可能性が高いそれらのアカウントへ攻撃を集中できる。

この問題は§ 14.6.2 ユーザー名列挙および§ 14.6.3 クレデンシャル ID を介したプライバシー漏えいで説明される問題と類似しており、同様の方法で軽減できる。

13.5.8. コードインジェクション攻撃

依存パーティの公開鍵クレデンシャルのスコープ内のオリジンで実行される悪意あるコードは、WebAuthn が提供し得るあらゆるセキュリティ保証を無効にする可能性がある。 WebAuthn クライアントはセキュアコンテキストでのみ WebAuthn API を公開する。これは最も基本的な攻撃を軽減するが、依存パーティによる追加の予防措置と組み合わせるべきである（SHOULD）。

コードインジェクションは複数の方法で発生し得る。この節では、起こりそうなシナリオをいくつか指摘し、適切な軽減策を提案しようとするが、網羅的な一覧ではない。

悪意あるコードは、依存パーティが含めた第三者スクリプトによって、意図的に、またはその第三者のセキュリティ脆弱性によって注入される可能性がある。

したがって、依存パーティは、自身のオリジンのうち、自身のクレデンシャルのスコープ内にあるものに含める第三者スクリプトの量を制限するべきである（SHOULD）。

依存パーティは、 Content Security Policy [CSP2]、および/またはその時点で利用可能なその他の適切な技術を使用して、自身のオリジンで実行できるスクリプトを制限するべきである（SHOULD）。
悪意あるコードは、クレデンシャルのスコープ規則により、RP IDのサブドメインでホストされる可能性がある。たとえば、usercontent.example.orgでホストされるユーザー投稿コードは、 RP IDexample.orgにスコープ設定された任意のクレデンシャルを使用できる。依存パーティがアサーションを検証する際にサブドメインのorigin を許可する場合、悪意あるユーザーはこれを利用して中間者攻撃を実行し、有効な認証アサーションを取得して、攻撃の被害者になりすますことができる。

したがって、依存パーティは既定では、アサーションを検証する際にサブドメインのorigin を許可するべきではない（SHOULD NOT）。依存パーティがサブドメインのoriginを許可する必要がある場合、依存パーティは、自身の公開鍵クレデンシャルのスコープ内にあるオリジンの許可されたどのサブドメインでも、信頼できないコードを提供してはならない（MUST NOT）。

13.5.9. クレデンシャルのオリジンの検証

クレデンシャルを登録する際、およびアサーションを検証する際、依存パーティはクライアントデータのorigin メンバーを検証しなければならない（MUST）。

依存パーティは、 originの予期しない値を受け入れてはならない（MUST NOT）。そうすると、悪意ある Web サイトが有効なクレデンシャルを取得できる可能性があるためである。 WebAuthn クレデンシャルのスコープにより、登録先のRP ID外のドメインでの使用は防止されるが、依存パーティによるオリジン検証は、欠陥のある認証器がクレデンシャルのスコープを適用できない場合に備える追加の保護層として機能する。潜在的に悪意あるサブドメインについての議論は、§ 13.5.8 コードインジェクション攻撃も参照すること。

検証は、完全な文字列照合または依存パーティが必要とするその他の方法で行ってもよい（MAY）。たとえば:

https://example.orgでのみ提供される Web アプリケーションは、 origin がhttps://example.orgと正確に等しいことを要求するべきである（SHOULD）。

これは最も単純なケースであり、originは文字列https://にRP IDが続くものになると想定される。
少数のドメインで提供される Web アプリケーションは、 origin が、たとえば["https://example.org", "https://login.example.org"]という許可済みオリジン一覧のいずれかの要素と正確に等しいことを要求してもよい。
関連オリジン要求を利用する Web アプリケーションも、 origin が許可済みオリジン一覧のいずれかの要素と正確に等しいことを要求してもよい。たとえば、 ["https://example.co.uk", "https://example.de", "https://myexamplerewards.com"]という一覧である。この一覧は通常、RP IDの well-known URI に列挙されるオリジンと一致する。 § 5.11 関連オリジンをまたいだ Web Authentication の使用を参照すること。
頻繁に変化する多数のドメインで提供される Web アプリケーションは、 origin を構造的に解析し、URL スキームがhttpsであり、 authority がRP IDと等しいか、その任意のサブドメインであることを要求してもよい。たとえば、 example.orgまたはexample.orgの任意のサブドメイン）。

注: § 13.5.8 コードインジェクション攻撃にある、RP IDの任意のサブドメインを許可するリスクについての議論を参照すること。
ネイティブアプリケーションを伴う Web アプリケーションは、 origin がネイティブアプリケーションのオペレーティングシステム依存の識別子であることを許可してもよい。たとえば、このような依存パーティは、 origin が一覧 ["https://example.org", "example-os:appid:204ffa1a5af110ac483f131a1bef8a841a7adb0d8d135908bbd964ed05d2653b"]のいずれかの要素と正確に等しいことを要求してもよい。

クライアントデータのtopOrigin メンバーを検証する際にも、同様の考慮事項が適用される。 topOrigin が存在する場合、依存パーティは、その値が予期されたものであることを検証しなければならない（MUST）。この検証は、完全な文字列照合または依存パーティが必要とするその他の方法で行ってもよい（MAY）。たとえば:

クロスオリジンの iframe に埋め込まれることを望まない Web アプリケーションは、topOrigin がoriginと正確に等しいことを要求してもよい。
少数のドメイン上のクロスオリジン iframe に埋め込まれることを望む Web アプリケーションは、 topOrigin が許可済みオリジン一覧のいずれかの要素と正確に等しいことを要求してもよい。たとえば、 ["https://example-partner1.org", "https://login.partner2-example.org"]という一覧である。
多数のドメイン上のクロスオリジン iframe に埋め込まれることを望む Web アプリケーションは、 topOriginの任意の値を許可するか、特定のセレモニーについて、与えられたtopOrigin 値が許可されるかどうかを決定する動的な手順を使用してもよい。

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およびクレデンシャル公開鍵が同一ユーザーに属するものとして相関不能であることを保証する。したがって、悪意ある一組の依存パーティは、意図的に再利用されたユーザー名や電子メールアドレスなどの追加情報なしに、システム間でユーザーを相関させることはできない。
認証器は、自身のアテステーション証明書が、単一の認証器または少数の認証器を識別できるほど一意ではないことを保証する。これについては§ 14.4.1 アテステーションのプライバシーでさらに詳しく説明する。したがって、悪意ある一組の依存パーティは、個々の認証器を追跡してシステム間でユーザーを相関できない。

さらに、クライアント側で発見可能な公開鍵クレデンシャルソースには、任意で依存パーティによって指定されたユーザーハンドルを含めることができる。その場合、クレデンシャルを使用してユーザーを識別すると同時に認証できる。これは、プライバシーを重視する依存パーティが従来のユーザー名なしでユーザーアカウントの作成を許可できることを意味し、依存パーティ間の非相関性をさらに向上させる。

14.3. 認証器ローカルの生体認識

生体認証器は生体認識を認証器内部で実行する。ただし、プラットフォーム認証器の場合、実装によっては生体データがクライアントにも可視である可能性がある。生体データは WebAuthn 依存パーティには開示されず、公開鍵クレデンシャルの作成および登録、またはそれを使用した認証を認可するユーザー検証を行うためにローカルでのみ使用される。したがって、悪意ある依存パーティは生体データを介してユーザーの個人的なアイデンティティを特定できず、依存パーティでセキュリティ侵害が発生しても、攻撃者が他の依存パーティへのログインを偽造するために使用できる生体データが漏えいすることはない。

依存パーティが生体認識を要求する場合、これは生体認証器がユーザー検証を実行することでローカルに処理され、その後、署名済みアサーション応答内のUV フラグを設定して結果を通知する。生体データ自体を依存パーティに開示することはない。

14.4. 認証器に関するプライバシー上の考慮事項

14.4.1. アテステーションのプライバシー

アテステーション証明書およびアテステーション鍵ペアは、ユーザーを追跡したり、同一ユーザーの複数のオンラインアイデンティティを相互に関連付けたりするために使用される可能性がある。これは、以下を含むいくつかの方法で軽減できる。

WebAuthn 認証器の製造元は、同一バッチ内の認証器が同じアテステーション証明書を共有するバッチ単位で認証器を出荷することを選択してもよい（これは基本アテステーションまたはバッチアテステーションと呼ばれる）。これによりユーザーを匿名化できるが、秘密鍵が侵害された場合に特定のアテステーション証明書を失効できないというリスクがある。したがって認証器製造元は、有意な匿名化を提供できるほどそのようなバッチを十分大きくする一方、アテステーション秘密鍵が侵害された場合に影響を受けるユーザー数を制限するため、バッチサイズを可能な限り小さくするべきである（SHOULD）。

[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. 認証器に保存される個人識別情報のプライバシー

認証器は、この仕様で定義されるもの以外の追加情報をクライアントへ提供してもよい（MAY）。たとえば、認証セレモニーにどのクレデンシャルを使用するかをユーザーが選択できるリッチ UI をクライアントが提供できるようにする場合などである。認証器がそのようにする場合、正常なユーザー検証が実行されるまでは個人識別情報を公開するべきではない（SHOULD NOT）。認証器が複数のユーザーを同時に登録した状態でユーザー検証をサポートする場合、認証器は、現在検証済みのユーザー以外の個人識別情報を公開するべきではない（SHOULD NOT）。したがって、認証器がユーザー検証を行えない場合、個人識別情報を保存するべきではない（SHOULD NOT）。

この議論の目的上、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にクレデンシャルを列挙していることを意味する。

指定されたクレデンシャルが利用できない。
指定されたクレデンシャルは利用できるが、ユーザーはそれを使用することに同意しない。

上記のケースを区別できる場合、悪意ある依存パーティが利用可能なクレデンシャルを調べることでユーザーを識別できる情報が漏えいする。たとえば、クライアントが指定されたクレデンシャルを含む認証器を発見した後にのみ、認証セレモニーをキャンセルまたは続行するための指示やコントロールを表示する場合、このような情報漏えいが発生する可能性がある。この場合、依存パーティがこのクライアントの動作を認識していれば、依存パーティは、セレモニーがタイムアウトではなくユーザーによってキャンセルされたことを検出でき、その結果、allowCredentials パラメーターに列挙されたクレデンシャルの少なくとも 1 つがユーザーに利用可能であると結論付けることができる。

この懸念は、指定されたクレデンシャルが利用可能かどうかに関係なく、ユーザーがいつでも認証セレモニーをキャンセルできるコントロールを表示することで対処できる。

14.5.3. オペレーティングシステムアカウント間のプライバシー

プラットフォーム認証器がマルチユーザーオペレーティングシステムを備えるクライアントデバイスに含まれる場合、プラットフォーム認証器およびクライアントデバイスは、任意のプラットフォームクレデンシャルの存在がそのプラットフォームクレデンシャルを作成したオペレーティングシステムユーザーだけに公開されるよう協調するべきである（SHOULD）。

14.5.4. クライアント機能の開示

getClientCapabilities メソッドは、WebAuthn 依存パーティが、クライアントおよび/またはユーザーで成功する可能性の高い登録および認証体験を構築するのを支援する。

WebAuthn クライアントがある機能をサポートする、またはサポートしないことはフィンガープリンティングのリスクをもたらす可能性がある。このリスクを低減するため、クライアントは false の値を返すよりも、返されるレコードからキーを省略することを優先するべきである（SHOULD）。キーを省略すること（§ 5.1.7 クライアント機能の可用性 - PublicKeyCredential の getClientCapabilities() メソッドで説明される）は、機能がサポートされていないことを明示的に確認するよりもフィンガープリンティング面を小さくする。クライアント実装は、クライアントポリシーおよび/またはユーザーの同意に基づいて機能の開示を制限してもよい（MAY）。

14.5.5. WebAuthn クレデンシャルのクロスオリジン利用

WebAuthn の登録または認証セレモニーが、関連オリジン要求を利用する場合やクロスオリジン iframe内から呼び出される場合など、クロスオリジンコンテキストで実行されると、誰が公開鍵クレデンシャルへのアクセスまたは作成を要求しているのかについてユーザーが混乱するリスクがある。

関連オリジン要求のように、呼び出し元のオリジンとRP IDが異なるシナリオでは、 WebAuthn クライアントおよびクライアントプラットフォームは、クレデンシャルおよび認証器の選択インターフェースで以下の両方を表示し、ユーザーに明確なコンテキストを提供するべきである（SHOULD）。

呼び出し元のオリジン: navigator.credentialsを呼び出している完全にアクティブな文書のオリジン
依存パーティ ID: クレデンシャルが当初作成された、または作成されるRP ID

たとえば、RP IDが exampleA.comで、呼び出し元オリジンがhttps://otherExampleB.comの場合、 WebAuthn クライアントおよび/またはクライアントプラットフォームは、ユーザーに次のように表示できる。「exampleA.com 用のパスキーを使って otherExampleB.com にサインインしますか？」

WebAuthn がiframe内で呼び出されるシナリオでは、 WebAuthn クライアントおよび/またはクライアントプラットフォームは、 iframe が埋め込まれているページのトップレベルオリジンについて、警告および追加のコンテキストをクレデンシャルおよび認証器の選択インターフェースでユーザーへ提供することも保証するべきである（SHOULD）。これは呼び出し元のオリジンと異なる場合がある。セレモニーが成功すると、トップレベルオリジンと呼び出し元のオリジンの両方が、それぞれのサイト間でユーザーのアイデンティティを相関できる。

たとえば、RP IDが examplepay.com、呼び出し元オリジンがhttps://examplepay.com、トップレベルオリジンが https://example.comの場合、 WebAuthn クライアントおよび/またはクライアントプラットフォームはユーザーに次のように表示できる。「パスキーを使って examplepay.com にサインインしますか？ example.com は、あなたが examplepay.com にサインインしていることを認識します。」

14.6. 依存パーティに関するプライバシー上の考慮事項

14.6.1. ユーザーハンドルの内容

ユーザーハンドルは § 14.4.2 認証器に保存される個人識別情報のプライバシーでは個人識別情報とは見なされず、認証器はユーザー検証を先に実行せずにユーザーハンドルを公開してもよいため（MAY）、依存パーティは、電子メールアドレスやユーザー名などの個人識別情報をユーザーハンドルに含めてはならない（MUST NOT）。これには個人識別情報のハッシュ値も含まれる。ただし、ハッシュ関数がソルト付きであり、ソルト値が依存パーティだけに秘匿されている場合を除く。ハッシュ化だけでは推測可能な入力値の探索を防げないためである。ユーザーハンドルを 64 ランダムバイトとし、この値をユーザーアカウントに保存することが推奨される（RECOMMENDED）。

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.5.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を返す方式を使用してプライバシー漏えいを軽減できる。

クレデンシャル IDが認識されなかったことを通知する場合、 WebAuthn 依存パーティは、未認証の呼び出し元へクレデンシャル IDを公開することを避けるため、 signalAllAcceptedCredentials(options) メソッドではなく signalUnknownCredential(options) メソッドを使用するべきである（SHOULD）。

15. アクセシビリティに関する考慮事項

ユーザー検証対応の認証器は、ローミングであれプラットフォームであれ、ユーザーに複数のユーザー検証方法を提供するべきである。たとえば、指紋検知と PIN 入力の両方である。これにより、選択したユーザー検証手段が何らかの理由で機能しない場合に、別の手段へフォールバックできる。ローミング認証器の場合、認証器とプラットフォームが連携して、PIN 入力などのユーザー検証方法を提供する場合があることに注意すること[FIDO-CTAP]。

依存パーティは、登録時に、ユーザーが将来の認可ジェスチャーを正しく完了できるよう支援する手段を提供するべきである（SHOULD）。これには、認証器に名前を付ける、デバイスに関連付ける画像を選択する、または自由形式のテキストによる指示（たとえば自分自身へのリマインダー）を入力することなどが含まれ得る。

15.1. セレモニータイムアウトの推奨範囲

タイミングに依存するセレモニー、たとえば登録セレモニー（timeoutを参照）、または認証セレモニー（timeoutを参照）は、 [WCAG21]のガイドライン 2.2 十分な時間に従うべきである。クライアントプラットフォームが、依存パーティから提供されたタイムアウトが後者の[WCAG21]ガイドラインに適切に従っていないと判断した場合、クライアントプラットフォームはそれに応じてタイムアウトを調整してもよい（MAY）。

WebAuthn セレモニーのタイムアウトに推奨される範囲と既定値は次のとおりである。

推奨範囲: 300000 ミリ秒から 600000 ミリ秒。
推奨される既定値: 300000 ミリ秒（5 分）。

16. テストベクトル

この節は規範的ではない。

この節では、実装を検証するために使用できる値の例を列挙する。

例は、同じクレデンシャルで実行される登録および認証セレモニーの対として疑似コードで示され、バイト文字列リテラルおよびコメントには CDDL [RFC8610] 表記を使用する。例は網羅的ではなく、WebAuthn 拡張を含まない。

例は、いくつかの中間値を含む、入力から出力への流れとして構成される。登録の例では依存パーティがchallenge 入力を定義し、クライアントがclientDataJSON 出力を生成し、認証器がattestationObject 出力を生成する。認証の例では依存パーティがchallenge 入力を定義し、クライアントがclientDataJSON 出力を生成し、認証器が authenticatorData およびsignature 出力を生成する。暗号学的に無関係なその他の入力および出力は含まれない。

認証器の実装者は、同様の構造を持つ attestationObject、 authenticatorData およびsignature 出力を生成することを確認できる。クライアントの実装者は、同様の構造を持つclientDataJSON 出力を生成することを確認できる。依存パーティの実装者は、同じchallenge 入力が与えられたとき、登録出力を正常に検証できること、および同じchallenge 入力、ならびに関連する登録例のクレデンシャル公開鍵およびクレデンシャル IDが与えられたとき、認証出力を正常に検証できることを確認できる。

すべての例ではRP ID example.org、origin https://example.org、および該当する場合はtopOrigin https://example.comを使用する。特に記載がない限り、例にはアテステーションなしが含まれる。 clientDataJSON、attestationObject、アテステーション証明書などの複合オブジェクトには、疑似コードで明示的に記載されていない、通常は定数である追加データが含まれる場合があることに注意すること。

すべてのランダム値は、CDDL で'WebAuthn test vectors'、または同等にh'576562417574686e207465737420766563746f7273'と表記される基本入力鍵素材から HKDF-SHA-256 [RFC5869]を使用して決定論的に生成される。 ECDSA 署名は決定論的 nonce [RFC6979]を使用する。例の RSA 鍵は、p ≥ 1024 となる最小の 2 つのメルセンヌ素数 2^p - 1 から構築される。

次の点に注意すること。

例には再現性のためクレデンシャル秘密鍵およびアテステーション秘密鍵が含まれているが、通常これらはクライアントまたは依存パーティと共有されない。
各例では異なるAAGUIDを使用するが、通常、 AAGUIDは特定の認証器について一定である。

注: CTAP2 [FIDO-CTAP]を実装する認証器は、この仕様で定義されるものとは異なるキーを使用してアテステーションオブジェクトを返す。これらの例はWebAuthn 依存パーティが期待するアテステーションオブジェクト形式を反映しているため、 CTAP2 から出力されたアテステーションオブジェクトは、これらの例とビット単位で同一にするためにキーを変換する必要がある。

16.1. アテステーション信頼ルート証明書

アテステーションを含むすべての例では、以下のattestation_ca_certとして示すアテステーション信頼ルート証明書を使用し、X.509 DER [RFC5280]でエンコードする。

attestation_ca_key = h'7809337f05740a96a78eedf9e9280499dcc8f2aa129616049ec1dccfe103eb2a'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='Attestation CA', L=32)
attestation_ca_serial_number = h'ed7f905d8bd0b414d1784913170a90b6'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='Attestation CA', L=16)
attestation_ca_cert = h'30820207308201ada003020102021100ed7f905d8bd0b414d1784913170a90b6300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a3062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d030107034200043269300e5ff7b699015f70cf80a8763bf705bc2e2af0c1b39cff718b7c35880ca30f319078d91b03389a006fdfc8a1dcd84edfa07d30aa13474a248a0dab5baaa3423040300f0603551d130101ff040530030101ff300e0603551d0f0101ff040403020106301d0603551d0e0416041445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d04030203480030450220483063b6bb08dcc83da33a02c11d2f42203176893554d138c614a36908724cc8022100f5ef2c912d4500b3e2f5b591d0622491e9f220dfd1f9734ec484bb7e90887663'

16.2. アテステーションなしの ES256 クレデンシャル

登録:

challenge = h'00c30fb78531c464d2b6771dab8d7b603c01162f2fa486bea70f283ae556e130'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='none.ES256', L=32)

credential_private_key = h'6e68e7a58484a3264f66b77f5d6dc5bc36a47085b615c9727ab334e8c369c2ee'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='none.ES256', L=32)
client_data_gen_flags = h'f9'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='none.ES256', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
extraData_random = h'06441e0e375c4c1ad70620302532c4e5' = b64'BkQeDjdcTBrXBiAwJTLE5Q'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='none.ES256', L=16)
aaguid = h'8446ccb9ab1db374750b2367ff6f3a1f'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='none.ES256', L=16)
credential_id = h'f91f391db4c9b2fde0ea70189cba3fb63f579ba6122b33ad94ff3ec330084be4'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='none.ES256', L=32)
; auth_data_UV_BE_BS は認証器データフラグの UV、BE、BS ビットを決定するが、BS は BE が設定されている場合にのみ設定される
auth_data_UV_BE_BS = h'ba'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='none.ES256', L=1)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a22414d4d507434557878475453746e63647134313759447742466938767049612d7077386f4f755657345441222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a20426b5165446a646354427258426941774a544c453551227d'
attestationObject = h'a363666d74646e6f6e656761747453746d74a068617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b559000000008446ccb9ab1db374750b2367ff6f3a1f0020f91f391db4c9b2fde0ea70189cba3fb63f579ba6122b33ad94ff3ec330084be4a5010203262001215820afefa16f97ca9b2d23eb86ccb64098d20db90856062eb249c33a9b672f26df61225820930a56b87a2fca66334b03458abf879717c12cc68ed73290af2e2664796b9220'

認証:

challenge = h'39c0e7521417ba54d43e8dc95174f423dee9bf3cd804ff6d65c857c9abf4d408'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='none.ES256', L=32)

client_data_gen_flags = h'4a'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='none.ES256', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
; auth_data_UV_BS は認証器データフラグの UV および BS ビットを設定するが、BS は登録時に BE が設定されていた場合にのみ設定される
auth_data_UV_BS = h'38'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='none.ES256', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b51900000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a224f63446e55685158756c5455506f334a5558543049393770767a7a59425039745a63685879617630314167222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'3046022100f50a4e2e4409249c4a853ba361282f09841df4dd4547a13a87780218deffcd380221008480ac0f0b93538174f575bf11a1dd5d78c6e486013f937295ea13653e331e87'

16.3. 自己アテステーション付き ES256 クレデンシャル

登録:

challenge = h'7869c2b772d4b58eba9378cf8f29e26cf935aa77df0da89fa99c0bdc0a76f7e5'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='packed-self.ES256', L=32)

credential_private_key = h'b4bbfa5d68e1693b6ef5a19a0e60ef7ee2cbcac81f7fec7006ac3a21e0c5116a'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='packed-self.ES256', L=32)
client_data_gen_flags = h'db'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='packed-self.ES256', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
extraData_random = h'53d8535ef284d944643276ffd3160756' = b64'U9hTXvKE2URkMnb_0xYHVg'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='packed-self.ES256', L=16)
aaguid = h'df850e09db6afbdfab51697791506cfc'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='packed-self.ES256', L=16)
credential_id = h'455ef34e2043a87db3d4afeb39bbcb6cc32df9347c789a865ecdca129cbef58c'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='packed-self.ES256', L=32)
; auth_data_UV_BE_BS は認証器データフラグの UV、BE、BS ビットを決定するが、BS は BE が設定されている場合にのみ設定される
auth_data_UV_BE_BS = h'fd'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='packed-self.ES256', L=1)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a2265476e4374334c55745936366b336a506a796e6962506b31716e666644616966715a774c33417032392d55222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a205539685458764b453255526b4d6e625f307859485667227d'
attestationObject = h'a363666d74667061636b65646761747453746d74a263616c672663736967584630440220067a20754ab925005dbf378097c92120031581c73228d1fb4f5b881bcd7da98302207fc7b147558c7c0eba3af18bd9d121fa3d3a26d17fe3f220272178f473b6006d68617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b55d00000000df850e09db6afbdfab51697791506cfc0020455ef34e2043a87db3d4afeb39bbcb6cc32df9347c789a865ecdca129cbef58ca5010203262001215820eb151c8176b225cc651559fecf07af450fd85802046656b34c18f6cf193843c5225820927b8aa427a2be1b8834d233a2d34f61f13bfd44119c325d5896e183fee484f2'

認証:

challenge = h'4478a10b1352348dd160c1353b0d469b5db19eb91c27f7dfa6fed39fe26af20b'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='packed-self.ES256', L=32)

client_data_gen_flags = h'1f'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='packed-self.ES256', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
extraData_random = h'8136f9debcfa121496a265c6ce2982d5' = b64'gTb53rz6EhSWomXGzimC1Q'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='packed-self.ES256', L=16)
; auth_data_UV_BS は認証器データフラグの UV および BS ビットを設定するが、BS は登録時に BE が設定されていた場合にのみ設定される
auth_data_UV_BS = h'a1'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='packed-self.ES256', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50900000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a225248696843784e534e493352594d45314f7731476d3132786e726b634a5f6666707637546e2d4a71386773222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a206754623533727a36456853576f6d58477a696d433151227d'
signature = h'304402203310b9431903c401f1be2bdc8d23a4007682dbbddcf846994947b7f465daf84002204e94dd00047b316061b3b99772b7efd95994a83ef584b3b6b825ea3550251b66'

16.4. clientDataJSON に "crossOrigin": true を含む ES256 クレデンシャル

登録:

challenge = h'3be5aacd03537142472340ab5969f240f1d87716e20b6807ac230655fa4b3b49'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='none.ES256.crossOrigin', L=32)

credential_private_key = h'96c940e769bd9f1237c119f144fa61a4d56af0b3289685ae2bef7fb89620623d'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='none.ES256.crossOrigin', L=32)
client_data_gen_flags = h'71'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='none.ES256.crossOrigin', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
extraData_random = h'cd9aae12d0d1f435aaa56e6d0564c5ba' = b64'zZquEtDR9DWqpW5tBWTFug'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='none.ES256.crossOrigin', L=16)
aaguid = h'883f4f6014f19c09d87aa38123be48d0'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='none.ES256.crossOrigin', L=16)
credential_id = h'6e1050c0d2ca2f07c755cb2c66a74c64fa43065c18f938354d9915db2bd5ce57'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='none.ES256.crossOrigin', L=32)
; auth_data_UV_BE_BS は認証器データフラグの UV、BE、BS ビットを決定するが、BS は BE が設定されている場合にのみ設定される
auth_data_UV_BE_BS = h'27'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='none.ES256.crossOrigin', L=1)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a224f2d57717a514e5463554a484930437257576e7951504859647862694332674872434d475666704c4f306b222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a747275652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a207a5a7175457444523944577170573574425754467567227d'
attestationObject = h'a363666d74646e6f6e656761747453746d74a068617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b54500000000883f4f6014f19c09d87aa38123be48d000206e1050c0d2ca2f07c755cb2c66a74c64fa43065c18f938354d9915db2bd5ce57a501020326200121582022200a473f90b11078851550d03b4e44a2279f8c4eca27b3153dedfe03e4e97d225820cbd0be95e746ad6f5a8191be11756e4c0420e72f65b466d39bc56b8b123a9c6e'

認証:

challenge = h'876aa517ba83fdee65fcffdbca4c84eeae5d54f8041a1fc85c991e5bbb273137'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='none.ES256.crossOrigin', L=32)

client_data_gen_flags = h'57'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='none.ES256.crossOrigin', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
extraData_random = h'f76a5c4d50f401bcbeab876d9a3e9e7e' = b64'92pcTVD0Aby-q4dtmj6efg'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='none.ES256.crossOrigin', L=16)
; auth_data_UV_BS は認証器データフラグの UV および BS ビットを設定するが、BS は登録時に BE が設定されていた場合にのみ設定される
auth_data_UV_BS = h'0c'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='none.ES256.crossOrigin', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50500000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a226832716c463771445f65356c5f505f62796b7945377135645650674547685f49584a6b655737736e4d5463222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a747275652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a2039327063545644304162792d713464746d6a36656667227d'
signature = h'3046022100eb12fcf23b12764c0f122e22371fab92e283879fd798f38ee1841c951b6e40e7022100c76237ff9db77b3c56f30837cda6a09acfa2e915544e609c0733b1184036d1cf'

16.5. clientDataJSON に "topOrigin" を含む ES256 クレデンシャル

登録:

challenge = h'4e1f4c6198699e33c14f192153f49d7e0e8e3577d5ac416c5f3adc92a41f27e5'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='none.ES256.topOrigin', L=32)

credential_private_key = h'a2d6de40ab974b80d8c1ef78c6d4300097754f7e016afe7f8ea0ad9798b0d420'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='none.ES256.topOrigin', L=32)
client_data_gen_flags = h'54'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='none.ES256.topOrigin', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
aaguid = h'97586fd09799a76401c200455099ef2a'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='none.ES256.topOrigin', L=16)
credential_id = h'b8ad59b996047ab18e2ceb57206c362da57458793481f4a8ebf101c7ca7cc0f1'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='none.ES256.topOrigin', L=32)
; auth_data_UV_BE_BS は認証器データフラグの UV、BE、BS ビットを決定するが、BS は BE が設定されている場合にのみ設定される
auth_data_UV_BE_BS = h'a0'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='none.ES256.topOrigin', L=1)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a225468394d595a68706e6a504254786b68555f53646667364f4e58665672454673587a72636b7151664a2d55222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a747275652c22746f704f726967696e223a2268747470733a2f2f6578616d706c652e636f6d227d'
attestationObject = h'a363666d74646e6f6e656761747453746d74a068617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b5410000000097586fd09799a76401c200455099ef2a0020b8ad59b996047ab18e2ceb57206c362da57458793481f4a8ebf101c7ca7cc0f1a5010203262001215820a1c47c1d82da4ebe82cd72207102b380670701993bc35398ae2e5726427fe01d22582086c1080d82987028c7f54ecb1b01185de243b359294a0ed210cd47480f0adc88'

認証:

challenge = h'd54a5c8ca4b62a8e3bb321e3b2bc73856f85a10150db2939ac195739eb1ea066'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='none.ES256.topOrigin', L=32)

client_data_gen_flags = h'77'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='none.ES256.topOrigin', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
extraData_random = h'52216824c5514070c0156162e2fc54a5' = b64'UiFoJMVRQHDAFWFi4vxUpQ'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='none.ES256.topOrigin', L=16)
; auth_data_UV_BS は認証器データフラグの UV および BS ビットを設定するが、BS は登録時に BE が設定されていた場合にのみ設定される
auth_data_UV_BS = h'9f'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='none.ES256.topOrigin', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50500000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a22315570636a4b53324b6f34377379486a7372787a68572d466f51465132796b3572426c584f6573656f4759222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a747275652c22746f704f726967696e223a2268747470733a2f2f6578616d706c652e636f6d222c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a205569466f4a4d56525148444146574669347678557051227d'
signature = h'3045022100b5a70c81780d5fcc9a4f2ae9caae99058f8accaf58b91fb59329646c28ac6ffc022012e101c165db3c8e9957f0c54dd6ca9b56bc3bd2f280bd2faa6c1d02c6e5c171'

16.6. 非常に長いクレデンシャル ID を持つ ES256 クレデンシャル

登録:

challenge = h'1113c7265ccf5e65124282fa1d7819a7a14cb8539aa4cdbec7487e5f35d8ec6c'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='none.ES256.long-credential-id', L=32)

credential_private_key = h'6fd2149bb5f1597fe549b138794bde61893b2dc32ca316de65f04808dac211dc'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='none.ES256.long-credential-id', L=32)
client_data_gen_flags = h'90'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='none.ES256.long-credential-id', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
aaguid = h'8f3360c2cd1b0ac14ffe0795c5d2638e'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='none.ES256.long-credential-id', L=16)
credential_id = h'3a761a4e1674ad6c4305869435c0eee9c286172c229bb91b48b4ada140c0863417031305cce5b4a27a88d7fe728a5f5a627de771b4b40e77f187980c124f9fe832d7136010436a056cce716680587d23187cf1fc2c62ae86fc3e508ee9617ffc74fbc10488ec16ec5e9096328669a898709b655e549738c666c1ae6281dc3b5f733c251d3eefb76ee70a3805ca91bcc18e49c8dc7f63ebcb486ba8c3d6ab52b88ff72c6a5bb47c32f3ee8683a3ddc8abf60870448ec8a21b5bdcb183c7dead870255575a6df96eb1b6a2a1019780cba9e4887b17ff1164bbbcc10eb0d86ed75984cd3fa3419103024507dfd9ce8f92c56af7914cb0bb50b87ba82a312bb7dcd93028dbdcd6adb266979667158335171e3682d37755701edbf9d872846a291d49e57ef09da1ec637f5052ed2aa7407f7e61827468e94b461844f4c67be5fa9c6055a566f8fdfc29d4bf78a9ff275f552cc68ba543fa3962eea36fd1ea8453764577d021d0a181efc1f6100ab2e4110039e21ee16970bda7432b6134492155afc126295b3a2eccd12c66a68e340969e995e3e8c9c476e395cfc21203414110779474f1c9797406637dbe414f132519d3bf0ce4f01734ef0e1a12c3ad604ff15d766b1624db6a5a7ccbff7bc35c9908df94aba277e0af48f04ff3d16381c47e5a37ed3988a67a3b1ecaa926336b33391fff04128f869991c9fabd905b6fe3ceef5f8b630ec1c5d2636d5b1961ad5ca5004170f6f5e482792aad989b0287fe91e5c479403397152f1fa56aa79b156eb47e6c8ea3eb175c34cfb38ad8e772874639b1023d4d01395c94e55831671cc022aa6fa1e02a02c2e4abc776f6960e51f83b71a8c0f207b6a347573977812c9aa5480b0011aa739bd4b76c18c000cc4757cceccb920f007c40c00e37e5ab21476cd9f6054a8fffb55a108f5c706e2cea2049d81fd321ff47d2a5761b0800955ab1d4f4889f55a84e2601c684f17a4ade7453ea49591d0b59c8d9a765052f62219cf6ef4a5dd9539f0617d6ebbebce7c000455475d18449e25c49ef9a1e3efe18c09082ebe2058d7c347defaa92f0664553b805c7d76bbfce5f330aca220ac90a789380fc479ea0d8793205813cca590a912f699ad52f991a1bc0a503c3ec4b2a696719e3c26591a87127f7305cc7e72f4c8e39355ebb06a5b1042990f38710ee7aa612ee4374bb82e878585a70a96c2a6b47f101a4ff154be4fd76a3167577a5cc54d9167c154c69ac35485e44cc898b719e1be3cc9c0fb5624b8f8a0dae10947a41bf848b6c1bb33d1006ec077d7e286e3f2a7b4843716390119449fe2721e81a5ed2333d331c7120765da58fadae73c19d9a8c4509cf8ac1e9d98b799a5274509069739b5823f3fb496663820033426988eefca53e580e0f9e0dfe0992fc2e53a97e053639f98577058f995bdbd41cefdb'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='none.ES256.long-credential-id', L=1023)
; auth_data_UV_BE_BS は認証器データフラグの UV、BE、BS ビットを決定するが、BS は BE が設定されている場合にのみ設定される
auth_data_UV_BE_BS = h'69'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='none.ES256.long-credential-id', L=1)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a22455250484a6c7a50586d5553516f4c364858675a7036464d75464f61704d322d7830682d587a5859374777222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
attestationObject = h'a363666d74646e6f6e656761747453746d74a0686175746844617461590483bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b549000000008f3360c2cd1b0ac14ffe0795c5d2638e03ff3a761a4e1674ad6c4305869435c0eee9c286172c229bb91b48b4ada140c0863417031305cce5b4a27a88d7fe728a5f5a627de771b4b40e77f187980c124f9fe832d7136010436a056cce716680587d23187cf1fc2c62ae86fc3e508ee9617ffc74fbc10488ec16ec5e9096328669a898709b655e549738c666c1ae6281dc3b5f733c251d3eefb76ee70a3805ca91bcc18e49c8dc7f63ebcb486ba8c3d6ab52b88ff72c6a5bb47c32f3ee8683a3ddc8abf60870448ec8a21b5bdcb183c7dead870255575a6df96eb1b6a2a1019780cba9e4887b17ff1164bbbcc10eb0d86ed75984cd3fa3419103024507dfd9ce8f92c56af7914cb0bb50b87ba82a312bb7dcd93028dbdcd6adb266979667158335171e3682d37755701edbf9d872846a291d49e57ef09da1ec637f5052ed2aa7407f7e61827468e94b461844f4c67be5fa9c6055a566f8fdfc29d4bf78a9ff275f552cc68ba543fa3962eea36fd1ea8453764577d021d0a181efc1f6100ab2e4110039e21ee16970bda7432b6134492155afc126295b3a2eccd12c66a68e340969e995e3e8c9c476e395cfc21203414110779474f1c9797406637dbe414f132519d3bf0ce4f01734ef0e1a12c3ad604ff15d766b1624db6a5a7ccbff7bc35c9908df94aba277e0af48f04ff3d16381c47e5a37ed3988a67a3b1ecaa926336b33391fff04128f869991c9fabd905b6fe3ceef5f8b630ec1c5d2636d5b1961ad5ca5004170f6f5e482792aad989b0287fe91e5c479403397152f1fa56aa79b156eb47e6c8ea3eb175c34cfb38ad8e772874639b1023d4d01395c94e55831671cc022aa6fa1e02a02c2e4abc776f6960e51f83b71a8c0f207b6a347573977812c9aa5480b0011aa739bd4b76c18c000cc4757cceccb920f007c40c00e37e5ab21476cd9f6054a8fffb55a108f5c706e2cea2049d81fd321ff47d2a5761b0800955ab1d4f4889f55a84e2601c684f17a4ade7453ea49591d0b59c8d9a765052f62219cf6ef4a5dd9539f0617d6ebbebce7c000455475d18449e25c49ef9a1e3efe18c09082ebe2058d7c347defaa92f0664553b805c7d76bbfce5f330aca220ac90a789380fc479ea0d8793205813cca590a912f699ad52f991a1bc0a503c3ec4b2a696719e3c26591a87127f7305cc7e72f4c8e39355ebb06a5b1042990f38710ee7aa612ee4374bb82e878585a70a96c2a6b47f101a4ff154be4fd76a3167577a5cc54d9167c154c69ac35485e44cc898b719e1be3cc9c0fb5624b8f8a0dae10947a41bf848b6c1bb33d1006ec077d7e286e3f2a7b4843716390119449fe2721e81a5ed2333d331c7120765da58fadae73c19d9a8c4509cf8ac1e9d98b799a5274509069739b5823f3fb496663820033426988eefca53e580e0f9e0dfe0992fc2e53a97e053639f98577058f995bdbd41cefdba50102032620012158203b8176b7504489cc593046d7988abb7905a742de6ac2cdc748a873c663e90cb12258201436d5edc9a75f23999eef9d5950a5c2455514ee1014084720f841a06b828a11'

認証:

challenge = h'ef1deba56dce48f674a447ccf63b9599258ce87648e5c396f2ef0ca1da460e3b'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='none.ES256.long-credential-id', L=32)

client_data_gen_flags = h'80'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='none.ES256.long-credential-id', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
; auth_data_UV_BS は認証器データフラグの UV および BS ビットを設定するが、BS は登録時に BE が設定されていた場合にのみ設定される
auth_data_UV_BS = h'e5'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='none.ES256.long-credential-id', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50d00000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a22377833727057334f53505a307045664d396a75566d53574d36485a4935634f573875384d6f647047446a73222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'304502203ecef83fb12a0cae7841055f9f87103a99fd14b424194bbf06c4623d3ee6e3fd022100d2ace346db262b1374a6b70faa51f518a42ddca13a4125ce6f5052a75bac9fb6'

16.7. ES256 クレデンシャルを使用する Packed アテステーション

登録:

challenge = h'c1184a5fddf8045e13dc47f54b61f5a656b666b59018f16d870e9256e9952012'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='packed.ES256', L=32)

credential_private_key = h'36ed7bea2357cefa8c4ec7e134f3312d2e6ca3058519d0bcb4c1424272010432'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='packed.ES256', L=32)
client_data_gen_flags = h'8d'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='packed.ES256', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
extraData_random = h'f5af1b3588ca0a05ab05753e7c29756a' = b64'9a8bNYjKCgWrBXU-fCl1ag'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='packed.ES256', L=16)
aaguid = h'876ca4f52071c3e9b25509ef2cdf7ed6'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='packed.ES256', L=16)
credential_id = h'c9a6f5b3462d02873fea0c56862234f99f081728084e511bb7760201a89054a5'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='packed.ES256', L=32)
; auth_data_UV_BE_BS は認証器データフラグの UV、BE、BS ビットを決定するが、BS は BE が設定されている場合にのみ設定される
auth_data_UV_BE_BS = h'4f'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='packed.ES256', L=1)
attestation_private_key = h'ec2804b222552b4b277d1f58f8c4343c0b0b0db5474eb55365c89d66a2bc96be'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='packed.ES256', L=32)
attestation_cert_serial_number = h'88c220f83c8ef1feafe94deae45faad0'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='packed.ES256', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a227752684b58393334424634543345663153324831706c61325a725751475046746877365356756d56494249222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a20396138624e596a4b436757724258552d66436c316167227d'
attestationObject = h'a363666d74667061636b65646761747453746d74a363616c6726637369675847304502203f19ec4b229f46ab8c45eff29b904ff10c0390dc40bf1216f04a78f4ceba3425022100fe7041a32759aff05a0f9f26c70a999c7a284451ba89234a1d3483c25e21925b637835638159022530820221308201c8a00302010202110088c220f83c8ef1feafe94deae45faad0300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d03010703420004a91ba4389409dd38a428141940ca8feb1ac0d7b4350558104a3777a49322f3798440f378b3398ab2d3bb7bf91322c92eb23556f59ad0a836fec4c7663b0e4dc3a360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e04160414a589ba72d060842ab11f74fb246bdedab16f9b9b301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d040302034700304402201726b9d85ecd8a5ed51163722ca3a20886fd9b242a0aa0453d442116075defd502207ef471e530ac87961a88a7f0d0c17b091ffc6b9238d30f79f635b417be5910e768617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b54d00000000876ca4f52071c3e9b25509ef2cdf7ed60020c9a6f5b3462d02873fea0c56862234f99f081728084e511bb7760201a89054a5a50102032620012158201cf27f25da591208a4239c2e324f104f585525479a29edeedd830f48e77aeae522582059e4b7da6c0106e206ce390c93ab98a15a5ec3887e57f0cc2bece803b920c423'

認証:

challenge = h'b1106fa46a57bef1781511c0557dc898a03413d5f0f17d244630c194c7e1adb5'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='packed.ES256', L=32)

client_data_gen_flags = h'75'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='packed.ES256', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
extraData_random = h'019330c8cc486c3f3eba0b85369eabf1' = b64'AZMwyMxIbD8-uguFNp6r8Q'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0b', info='packed.ES256', L=16)
; auth_data_UV_BS は認証器データフラグの UV および BS ビットを設定するが、BS は登録時に BE が設定されていた場合にのみ設定される
auth_data_UV_BS = h'46'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0c', info='packed.ES256', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50d00000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a2273524276704770587676463446524841565833496d4b4130453958773858306b526a44426c4d6668726255222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a20415a4d77794d78496244382d756775464e7036723851227d'
signature = h'30450220694969d3ee928de6f02ef23a9c644d7d779916451734a94b432542f498a1ebe90221008b0819c824218a97152cd099c55bfb1477b29d900a49a64018314f9bfccda163'

16.8. ES384 クレデンシャルを使用する Packed アテステーション

登録:

challenge = h'567b030b3e186bc1d169dd45b79f9e0d86f1fd63474da3eade5bdb8db379a0c3'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='packed.ES384', L=32)

credential_private_key = h'271e37d309c558c0f35222b37abba7500377d68e179e4c74b0cb558551b2e5276b47b90a317ca8ebbe1a12c93c2d5dd9'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='packed.ES384', L=48)
client_data_gen_flags = h'32'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='packed.ES384', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
aaguid = h'e950dcda3bdae1d087cda380a897848b'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='packed.ES384', L=16)
credential_id = h'953ae2dd9f28b1a1d5802c83e1f65833bb9769a08de82d812bc27c13fc6f06a9'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='packed.ES384', L=32)
; auth_data_UV_BE_BS は認証器データフラグの UV、BE、BS ビットを決定するが、BS は BE が設定されている場合にのみ設定される
auth_data_UV_BE_BS = h'db'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='packed.ES384', L=1)
attestation_private_key = h'8d979fbb6e49c4eeb5925a2bca0fcdb023d3fb90bcadce8391da9da4ed2aee9a'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='packed.ES384', L=32)
attestation_cert_serial_number = h'3d0a5588bb87ebb1d4cee4a1807c1b7c'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='packed.ES384', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a22566e7344437a3459613848526164314674352d65445962785f574e4854615071336c76626a624e356f4d4d222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
attestationObject = h'a363666d74667061636b65646761747453746d74a363616c67266373696758473045022100c56ecc970b7843833e0f461fde26233f61eb395161d481558c08b9c6ed61675b022029f5e05033705cd0f9b0a07e149468ec308a4f84906409efdceb1da20a7518d6637835638159022530820221308201c7a00302010202103d0a5588bb87ebb1d4cee4a1807c1b7c300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d0301070342000417e5cc91d676d370e36aa7de40c25aacb45a3845f13d2932088ece2270b9b431241c219c22d0c256c9438ade00f2c05e62f8ef906b9b997ae9f3c460c2db66f5a360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e04160414c7c8dd95382a2230e4c0dd3664338fa908169a9c301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d0403020348003045022054068cc9ae038937b7c468c307edb9c6927ffdeb6a20070c483eb40330f99f10022100cf41953919c3c04693d6b1f42a613753f204e70e85fc6e9b17036170b83596e068617574684461746158c5bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b55900000000e950dcda3bdae1d087cda380a897848b0020953ae2dd9f28b1a1d5802c83e1f65833bb9769a08de82d812bc27c13fc6f06a9a5010203382220022158304866bd8b01da789e9eb806e5eab05ae5a638542296ab057a2f1bbce9b58f8a08b9171390b58a37ac7fffc2c5f45857da2258302a0b024c7f4b72072a1f96bd30a7261aae9571dd39870eb29e55c0941c6b08e89629a1ea1216aa64ce57c2807bf3901a'

認証:

challenge = h'ff41c3d25dbd8966fb61e28ef5e47041e137ed268520412d76202ba0ad2d1453'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='packed.ES384', L=32)

client_data_gen_flags = h'0c'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='packed.ES384', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
; auth_data_UV_BS は認証器データフラグの UV および BS ビットを設定するが、BS は登録時に BE が設定されていた場合にのみ設定される
auth_data_UV_BS = h'af'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='packed.ES384', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50d00000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a225f304844306c32396957623759654b4f39655277516545333753614649454574646941726f4b307446464d222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'3065023100e4efbb46745ed00e67c4d51ab2bacab2af62ffa8b7c5fecec6d7d9bf2582275034a713a3dd731685eee81adfaf6aa63f0230161655353f07e018a3c2539f8de7c8c4cf88d4c32d2be29fe4e76fa096ecc9458bbfe0895d57129ab324130e6f0692db'

16.9. ES512 クレデンシャルを使用する Packed アテステーション

登録:

challenge = h'4ee220cd92b07e11451cb4c201c5755bd879848e492a9b12d79135c62764dc2fd28ead4808cafe5ad1de8fa9e08d4a8eeafea4dfb333877b02bc503f475d3b0c1394a7683baaf4f2477829f7b8cf750948985558748c073068396fcfdcd3f245bf2038e6bb38d7532768aad13be8c118f727722e7426139041e9caca503884c5'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='packed.ES512', L=128)

credential_private_key = h'f11120594f6a4944ac3ba59adbbc5b85016895b649f4cc949a610f4b48be47b318850bacb105f747647bba8852b6b8e52a0b3679f1bbbdfe18c99409bcb644fa45'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='packed.ES512', L=65)
client_data_gen_flags = h'6d'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='packed.ES512', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
extraData_random = h'a37a958ce2f6b535a6e06c64cc8fd082' = b64'o3qVjOL2tTWm4GxkzI_Qgg'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='packed.ES512', L=16)
aaguid = h'39d8ce6a3cf61025775083a738e5c254'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='packed.ES512', L=16)
credential_id = h'd17d5af7e3f37c56622a67c8462c9e1c6336dfccb8b61d359dc47378dba58ce4'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='packed.ES512', L=32)
; auth_data_UV_BE_BS は認証器データフラグの UV、BE、BS ビットを決定するが、BS は BE が設定されている場合にのみ設定される
auth_data_UV_BE_BS = h'cf'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='packed.ES512', L=1)
attestation_private_key = h'ffbc89d5f75994f52dc5e7538ee269402d26995d40c16fb713473e34fca98be4'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='packed.ES512', L=32)
attestation_cert_serial_number = h'8a128b7ebe52b993835779e6d9b81355'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='packed.ES512', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a22547549677a5a4b7766684646484c544341635631573968356849354a4b707353313545317869646b33435f536a713149434d722d577448656a366e676a55714f3676366b33374d7a683373437646415f5231303744424f5570326737717654795233677039376a5064516c496d465659644977484d47673562385f63305f4a46767941343572733431314d6e614b72524f2d6a424750636e636935304a684f5151656e4b796c4134684d55222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a206f3371566a4f4c327454576d3447786b7a495f516767227d'
attestationObject = h'a363666d74667061636b65646761747453746d74a363616c67266373696758473045022100ce158f6c04aa5c14c0dd3e1103cf93664896fb5c337a66dbd7dba31546ff0d41022071cbcd0d3b8e218a6d05374e0ef8031329d25059002ac1603d02d5fd8a0a29cb637835638159022730820223308201c8a0030201020211008a128b7ebe52b993835779e6d9b81355300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d03010703420004940b68885291536e2f7c60c05acfb252e7eebcf4304425dd93ab7b1962f20492bf18dc0f12862599e81fb764ac92151f9a78fcbb35d7a26c8c52949b18133c06a360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e041604143ffad863abcd3dc5717b8a252189f41af97e7f31301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d0403020349003046022100832c8b64c4f0188bd32e1bec63e13301cdc03165d3ef840d1f3dabb9a5719f83022100add57a9d5bedec98f29222dfc97ea795d055ee13a02a153d02be9ce00aedeb9168617574684461746158e9bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b54d0000000039d8ce6a3cf61025775083a738e5c2540020d17d5af7e3f37c56622a67c8462c9e1c6336dfccb8b61d359dc47378dba58ce4a5010203382320032158420083240a2c3ad21a3dc0a6daa3d8bc05a46d7cd9825ba010ae2a22686c2d6d663d7d5f678987fb1e767542e63dc197ae915e25f8ee284651af29066910a2cc083f50225842017337df47ab5cce5d716ef8caffa97a3012689b1f326ea6c43a1ba9596c72f71f0122390143552b42be772b4c35ffb961220c743b486a601ea4cb6d5412f5b078d3'

認証:

challenge = h'08d3190c6dcb3d4f0cb659a0333bf5ea124ddf36a0cd33d5204b0d7a22a8cc26f2e4f169d200285c77b3fb22e0f1c7f49a87d4be2d25e92d797808ddaaa9b5715efd3a6ada9339d3052a687dbc5d2f8c871b0451e0691f57ad138541b7b72e7aa8933729ec1c664bf2e4dedae1616d08ecefa80a2a53b103663ce5a881048829'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='packed.ES512', L=128)

client_data_gen_flags = h'ac'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='packed.ES512', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
; auth_data_UV_BS は認証器データフラグの UV および BS ビットを設定するが、BS は登録時に BE が設定されていた場合にのみ設定される
auth_data_UV_BS = h'52'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0b', info='packed.ES512', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b51900000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a22434e4d5a4447334c5055384d746c6d674d7a763136684a4e337a61677a5450564945734e65694b6f7a436279355046703067416f5848657a2d794c67386366306d6f66557669306c3653313565416a6471716d31635637394f6d72616b7a6e544253706f666278644c3479484777525234476b66563630546855473374793536714a4d334b6577635a6b7679354e376134574674434f7a7671416f71553745445a6a7a6c7149454569436b222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'3081870242009bda02fe384e77bcb9fb42b07c395b7a53ec9d9616dd0308ab8495c2141c8364c7d16e212a4a4fb8e3987ff6c99eafd64d8484fd28c3fc7968f658a9033d1bb1b802416383e9f3ee20c691b66620299fef36bea2df4d39c92b2ead92f58e7b79ab0d9864d2ebf3b0dcc66ea13234492ccee6e9d421db43c959bcb94c162dc9494136c9f6'

16.10. RS256 クレデンシャルを使用する Packed アテステーション

登録:

challenge = h'bea8f0770009bd57f2c0df6fea9f743a27e4b61bbe923c862c7aad7a9fc8e4a6'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='packed.RS256', L=32)

; p >= 1024 となる最小の 2 つのメルセンヌ素数 2^p - 1
private_key_p = 2^1279 - 1 = h'7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff'
private_key_q = 2^2203 - 1 = h'07ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff'
client_data_gen_flags = h'1c'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='packed.RS256', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
aaguid = h'428f8878298b9862a36ad8c7527bfef2'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='packed.RS256', L=16)
credential_id = h'992a18acc83f67533600c1138a4b4c4bd236de13629cf025ed17cb00b00b74df'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='packed.RS256', L=32)
; auth_data_UV_BE_BS は認証器データフラグの UV、BE、BS ビットを決定するが、BS は BE が設定されている場合にのみ設定される
auth_data_UV_BE_BS = h'7e'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='packed.RS256', L=1)
attestation_private_key = h'08a1322d5aa5b5b40cd67c2cc30b038e7921d7888c84c342d50d79f0c5fc3464'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='packed.RS256', L=32)
attestation_cert_serial_number = h'1f6fb7a5ece81b45896b983a995da5f3'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='packed.RS256', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a2276716a776477414a76566679774e3976367039304f69666b7468752d6b6a79474c48717465705f49354b59222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
attestationObject = h'a363666d74667061636b65646761747453746d74a363616c672663736967584730450221008b8c5c6ea8c142c032e0be69e1353d44461c5c9109941cdda951b976eb95b6b302204d52f406c19e254b3ff9589bd18070fb055ac8db12fdd0a6734bea9d7168e900637835638159022630820222308201c7a00302010202101f6fb7a5ece81b45896b983a995da5f3300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d03010703420004b7b36b7542a11120b443c794d0c99fdc25a06b76586413d81e086163ef6fe147a557afc34e2861d9057d6d465d4705a0310550bdeeb5f35ee35b9425ab859981a360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e04160414fb37b647bccfb9e54d989eaaacc1633868703fb3301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d0403020349003046022100b86bc129d92afca7d9869a39f70f139a305b4073a39eb654d81424bed5757d91022100cf9f7c60cab7c4a7d3e7f0020f281a93d4fd0a9f95121b989f56932a68885fba68617574684461746159021bbfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b55d00000000428f8878298b9862a36ad8c7527bfef20020992a18acc83f67533600c1138a4b4c4bd236de13629cf025ed17cb00b00b74dfa4010303390100205901b403fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000012143010001'

認証:

challenge = h'295f59f5fa8fe62c5aca9e27626c78c8da376ae6d8cd2dd29aebad601e1bc4c5'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='packed.RS256', L=32)

client_data_gen_flags = h'0e'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='packed.RS256', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
; auth_data_UV_BS は認証器データフラグの UV および BS ビットを設定するが、BS は登録時に BE が設定されていた場合にのみ設定される
auth_data_UV_BS = h'ba'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='packed.RS256', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b51900000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a224b56395a39667150356978617970346e596d7834794e6f33617562597a5333536d75757459423462784d55222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'01063d52d7c39b4d432fc7063c5d93e582bdcb16889cd71f888d67d880ea730a428498d3bc8e1ee11f2b1ecbe6c292b118c55ffaaddefa8cad0a54dd137c51f1eec673f1bb6c4d1789d6826a222b22d0f585fc901fdc933212e579d199b89d672aa44891333e6a1355536025e82b25590256c3538229b55737083b2f6b9377e49e2472f11952f79fdd0da180b5ffd901b4049a8f081bb40711bef76c62aed943571f2d0575304cb549d68d8892f95086a30f93716aee818f8dc06e96c0d5e0ed4cfa9fd8773d90464b68cf140f7986666ff9c9e3302acd0535d60d769f465e2ab57ef8aabc89fccfef7ba32a64154a8b3d26be2298f470b8cc5377dbe3dfd4b0b45f8f01e63bde6cfc76b62771f9b70aa27cf40152cad93aa5acd784fd4b90f676e2ea828d0bf2400aebbaae4153e5838f537f88b6228346782a93a899be66ec77de45b3efcf311da6321c92e6b0cd11bfe653bf3e98cee8e341f02d67dbb6f9c98d9e8178090cfb5b70fbc6d541599ac794ae2f1d4de1286ec8de8c2daf7b1d15c8438e90d924df5c19045220a4c8438c1b979bbe016cf3d0eeec23c3999d4882cc645b776de930756612cdc6dd398160ff02a6'

16.11. Ed25519 クレデンシャルを使用する Packed アテステーション

登録:

challenge = h'a8abf9dabdc6b0df63466b39bda9e8a34a34e185337a59f1c579990676d3b3bd'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='packed.EdDSA', L=32)

private_key = h'971f38c0f73aaf0c5a614eb5e26430ae1ea0ed13e4f425d96e9662349340b0b3'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='packed.EdDSA', L=32)
client_data_gen_flags = h'bd'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='packed.EdDSA', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
extraData_random = h'07f0d3e60ed90fffbd3932d85f922f11' = b64'B_DT5g7ZD_-9OTLYX5IvEQ'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='packed.EdDSA', L=16)
aaguid = h'd5aa33581e8ca478e20fe713f5d32ff2'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='packed.EdDSA', L=16)
credential_id = h'ce9f840ed96599580cd140fbc7bb3230633f50f61041aff73308ae71caa8a2bd'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='packed.EdDSA', L=32)
; auth_data_UV_BE_BS は認証器データフラグの UV、BE、BS ビットを決定するが、BS は BE が設定されている場合にのみ設定される
auth_data_UV_BE_BS = h'32'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='packed.EdDSA', L=1)
attestation_private_key = h'fbe7f950684f23afd045072a8b287ad29528707c662672850ac69733ffe0db85'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='packed.EdDSA', L=32)
attestation_cert_serial_number = h'b2cfc9ea33c8643b0e1a760463eaf164'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='packed.EdDSA', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a22714b763532723347734e396a526d733576616e6f6f306f303459557a656c6e7878586d5a426e6254733730222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a20425f44543567375a445f2d394f544c59583549764551227d'
attestationObject = h'a363666d74667061636b65646761747453746d74a363616c67266373696758483046022100d83f60bd80269537583218858aefb03ac57d45fa06e42feaae332d187f62da9f022100a02bd3cb6f7e1d283c93bad1f3f4b5a4c0494463da7fdbf256949116754d1f17637835638159022730820223308201c8a003020102021100b2cfc9ea33c8643b0e1a760463eaf164300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d03010703420004dd2b7a564b73b8c0b81c4c62e521925c4d1198ec9f583dbf1eebe364b65cd9c29a9bdf346aaa81fb6b9507e5249a52fdaf8e39e26b0b7dc45992a7e233b70f70a360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e041604140ae27546bc7eccb1b4b597bd354f0c0b1f1f8f8e301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d0403020349003046022100a0d434ecb5fc3bfd7da5f41904517ad2836249f561bd834ba7a438a8ab7a4ce8022100fac845bb7a02513b58e9f319654dbe49b0f02b95835bac568c71f8a18cdde9ab6861757468446174615881bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b54100000000d5aa33581e8ca478e20fe713f5d32ff20020ce9f840ed96599580cd140fbc7bb3230633f50f61041aff73308ae71caa8a2bda401010327200621582044e06ddd331c36a8dc667bab52bcae63486c916aa5e339e6acebaa84934bf832'

認証:

challenge = h'895957e01c633a698348a2d8a31a54b7db27e8c1c43b2080d79ae2190267bfd2'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='packed.EdDSA', L=32)

client_data_gen_flags = h'8c'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='packed.EdDSA', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
; auth_data_UV_BS は認証器データフラグの UV および BS ビットを設定するが、BS は登録時に BE が設定されていた場合にのみ設定される
auth_data_UV_BS = h'ab'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0b', info='packed.EdDSA', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50100000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a2269566c583442786a4f6d6d44534b4c596f7870557439736e364d48454f7943413135726947514a6e763949222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'f5c59c7e46c34f6f8cc197101ddf9934fa2595f68eb1913a637e8419eb9ba4cfdfc48f85393bc0d40b011f0d6fecb097d6607525713223a0dc0d453993dae00b'

16.12. Ed448 クレデンシャルを使用する Packed アテステーション

登録:

challenge = h'2578d0801b5a005b5451e540121788cb01949e187b91db13f58755403efbf337'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='packed.Ed448', L=32)

private_key = h'ed479eecf63bd89e3898434798bb3c417bfc8284f6f011958bc0e78edbf6a2a640c0e358b1b1452a1f3782c400dabb4134192dee3031869a45'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='packed.Ed448', L=57)
client_data_gen_flags = h'e3'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='packed.Ed448', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
extraData_random = h'050a80de27875521cc4c3316c06da42b' = b64'BQqA3ieHVSHMTDMWwG2kKw'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='packed.Ed448', L=16)
aaguid = h'41c913aeda925fe02273322e34c2ae67'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='packed.Ed448', L=16)
credential_id = h'224fcde324e6b075ede55098a24b9ddce5f5a7c71d23703efd528a38f8a5f33c'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='packed.Ed448', L=32)
; auth_data_UV_BE_BS は認証器データフラグの UV、BE、BS ビットを決定するが、BS は BE が設定されている場合にのみ設定される
auth_data_UV_BE_BS = h'3b'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='packed.Ed448', L=1)
attestation_private_key = h'd90faf5cc3f7853456b09124dd870250347f9c9ff66dba363aecd9194c665715'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='packed.Ed448', L=32)
attestation_cert_serial_number = h'cff4228697d6e5ac47480b2390677f05'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='packed.Ed448', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a224a586a5167427461414674555565564145686549797747556e6868376b6473543959645651443737387a63222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a2042517141336965485653484d54444d577747326b4b77227d'
attestationObject = h'a363666d74667061636b65646761747453746d74a363616c67266373696758473045022100c5430b6b53f6b8fd1e5fa46ae7ebb8f9e9ae0d10ebc748e876e2d979b39b1382022008c5cda8af174f2d3c050d5d14eec0721031364cb12924a06633d4924c6bcad3637835638159022730820223308201c8a003020102021100cff4228697d6e5ac47480b2390677f05300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d03010703420004b85aaf790c824037cfe9fc56ab8d7ce6fbfaff2e3fe7c8d745734c3c6e3c6ce880d505ccdb1e2c3738680e6f49f475e4d8d0b6c29060e6e0d7a6392fb69094cea360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e04160414fa8f81c2dcc0e194ae5034c7e79dcf6d9d8593e2301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d0403020349003046022100e761f54215ad92f27c2c14b9eea3e39e8c22429e833ecba5be918987aa72e0e6022100d5a714df479c238586b7d9e6684ea84991087038b0fef6a29b57b66b74df05fd686175746844617461589bbfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b5590000000041c913aeda925fe02273322e34c2ae670020224fcde324e6b075ede55098a24b9ddce5f5a7c71d23703efd528a38f8a5f33ca4010103383420072158398051ef4f94670b5abf17da2e9558ba6eba94eb8704363915b4d666de287ad329de9f1f075211aba602dc6e7a5e52b15a8ee1c984a9f8887380'

認証:

challenge = h'1a942f401d8d8e36fe888c35c22b718217802fc6685bf139c47b311408128693'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='packed.Ed448', L=32)

client_data_gen_flags = h'2d'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='packed.Ed448', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
extraData_random = h'5ca1e381b5e009e01760db2eb632316f' = b64'XKHjgbXgCeAXYNsutjIxbw'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0b', info='packed.Ed448', L=16)
; auth_data_UV_BS は認証器データフラグの UV および BS ビットを設定するが、BS は登録時に BE が設定されていた場合にのみ設定される
auth_data_UV_BS = h'fc'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0c', info='packed.Ed448', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b51d00000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a22477051765142324e6a6a622d6949773177697478676865414c385a6f575f4535784873784641675368704d222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a20584b486a6762586743654158594e7375746a49786277227d'
signature = h'071db921430e13ca1a607eedb96cbd30fd63946a06e731217cad6fd82ba3b930d482308a2c101752a2518cff70918d4a20f29bd2eda4f45a80bba6c4ad85b10fb721b1849725b7dbef315d5fb101c6dab890b06d94a8b52a74b5848f68e6152af24867b7555d2b22b8955cbff5c87de73b00'

16.13. ES256 クレデンシャルを使用する TPM アテステーション

登録:

challenge = h'cfc82cdf1ceee876120aa88f0364f0910193460cfb97a317b2fe090694f9a299'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='tpm.ES256', L=32)

credential_private_key = h'80c60805e564f6d33e7abdff9d32e3db09a6219fe378a268d23107191b18e39f'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='tpm.ES256', L=32)
client_data_gen_flags = h'84'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='tpm.ES256', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
aaguid = h'4b92a377fc5f6107c4c85c190adbfd99'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='tpm.ES256', L=16)
credential_id = h'ec27bec7521c894bbb821105ea3724c90e770cf1fa354157ef18d0f18f78bea9'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='tpm.ES256', L=32)
; auth_data_UV_BE_BS は認証器データフラグの UV、BE、BS ビットを決定するが、BS は BE が設定されている場合にのみ設定される
auth_data_UV_BE_BS = h'af'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='tpm.ES256', L=1)
attestation_private_key = h'6210f09e0ce7593e851a880a4bdde2d2192afeac46104abce1a890a5a71cf0c6'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='tpm.ES256', L=32)
attestation_cert_serial_number = h'311fc42da0ab10c43a9b1bf3a75e34e2'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='tpm.ES256', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a227a38677333787a753648595343716950413254776b51475452677a376c364d587376344a427054356f706b222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
attestationObject = h'a363666d746374706d6761747453746d74a663616c67266373696758463044022066e5826a652091030fd444e33c3eca2bc6dc548cf3045013addb38aa6457a21002203f3a5c95c9e707d0e555041bcc8698ee4ebc04e26cc8bae459705471789851766376657263322e30637835638159023a30820236308201dca0030201020210311fc42da0ab10c43a9b1bf3a75e34e2300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a30003059301306072a8648ce3d020106082a8648ce3d03010703420004c54e3f109094f60d7699b7db5d838569ffd1f3e1c9e897cd9eb40063f9402e3e9937e936cf1fcd5eb743ff443c97ab2edcd7c8e0e6cf6cfd413b8ab19fffa769a381d33081d0300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e041604145f546cb6973d4981e80fcdc7463859f5879680e4301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e30100603551d250409300706056781050803305e0603551d110101ff04543052a450304e314c3014060567810502010c0b69643a30303030303030303014060567810502030c0b69643a3030303030303030301e060567810502020c15576562417574686e207465737420766563746f7273300a06082a8648ce3d0403020348003045022063c9a2797b8066f1db34dd609f1ab6695607e7a98e9ff8090a68853c9a9fc949022100a55831a39f5b8a2aa9a68837829cabf43fea2a5cea4859ae851cac78e6ac3e97677075624172656158560023000b0004000000000010001000030010002041202698c9d9753fb4bb3f27cd09fe6b8afdb76438ee2ae54d7c9dade10d864b0020d8735115cdb330a63ea1d6e43d5000f4bd56f99bce83ee1d73301fc270116d076863657274496e666f5869ff544347801700000020277d0e05579dd013215a62273f7f3a3e7e191ead2654a3036d75a5a3ee37a6b0000000000000000011111111222222223300000000000000000022000b9c42d8aad5939331b9af3711af179f17123178098c9a7d0ca89fcd1fc800f3c7000068617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b54d000000004b92a377fc5f6107c4c85c190adbfd990020ec27bec7521c894bbb821105ea3724c90e770cf1fa354157ef18d0f18f78bea9a501020326200121582041202698c9d9753fb4bb3f27cd09fe6b8afdb76438ee2ae54d7c9dade10d864b225820d8735115cdb330a63ea1d6e43d5000f4bd56f99bce83ee1d73301fc270116d07'

認証:

challenge = h'00093b66c21d5b5e89f7a07082118907ea3e502d343b314b8c5a54d62db202fb'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='tpm.ES256', L=32)

client_data_gen_flags = h'86'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='tpm.ES256', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
; auth_data_UV_BS は認証器データフラグの UV および BS ビットを設定するが、BS は登録時に BE が設定されていた場合にのみ設定される
auth_data_UV_BS = h'87'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='tpm.ES256', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50d00000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a2241416b375a7349645731364a393642776768474a422d6f2d554330304f7a464c6a46705531693279417673222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'3045022060dc76b1607ec716c6e5eba8d056695ed6bc47b2e3d7a729c34e759e3ab66aa0022100d010a9e8fddcb64c439dfdca628ddb33cf245d567d157d9f66f942601bed9b38'

16.14. ES256 クレデンシャルを使用する Android Key アテステーション

登録:

challenge = h'3de1f0b7365dccde3ff0cbf25e26ffa7baff87ef106c80fc865dc402d9960050'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='android-key.ES256', L=32)

credential_private_key = h'd4328d911acb0ebcc42aad29b29ffb55d5bc31d8af7ca9a16703d56c21abc7b4'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='android-key.ES256', L=32)
client_data_gen_flags = h'73'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='android-key.ES256', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
extraData_random = h'555d5c42e476a8b33f6a63dfa07ccbd2' = b64'VV1cQuR2qLM_amPfoHzL0g'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='android-key.ES256', L=16)
aaguid = h'ade9705e1ce7085b899a540d02199bf8'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='android-key.ES256', L=16)
credential_id = h'0a4729519788b6ed8a2d772b494e186244d8c798c052960dbc8c10c915176795'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='android-key.ES256', L=32)
; auth_data_UV_BE_BS は認証器データフラグの UV、BE、BS ビットを決定するが、BS は BE が設定されている場合にのみ設定される
auth_data_UV_BE_BS = h'1e'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='android-key.ES256', L=1)
attestation_cert_serial_number = h'1ff91f76b63f44812f998b250b0286bf'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='android-key.ES256', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a2250654877747a5a647a4e345f384d76795869625f7037725f682d385162494438686c334541746d57414641222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a205656316351755232714c4d5f616d50666f487a4c3067227d'
attestationObject = h'a363666d746b616e64726f69642d6b65796761747453746d74a363616c67266373696758483046022100e95512982aa3f216cff2e87c8ec57057b8529f674eaabeccaa27fd03d8779f19022100afb6bf459da4a826f00d01fc6b60712ff31dc4eb331619c8f874bb17e4314e94637835638159027c308202783082021ea00302010202101ff91f76b63f44812f998b250b0286bf300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d0301070342000499169657036d089a2a9821a7d0063d341f1a4613389359636efab5f3cbf1accfdd91c55543176ea99b644406dd1dd63774b6af65ac759e06ff40b1c8ab02df6ba381b63081b3300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e041604141ac81e50641e8d1339ab9f7eb25f0cd5aac054b0301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e3053060a2b06010401d679020111044530430202012c0a01000201000a01000420b435028d7b6a8f83bb461d41c19b053a9d3cdb30351a4f374cd4cde8dbefb60604003000300ea1053103020102bf853e03020100300a06082a8648ce3d040302034800304502201354f9149996f6e1830852da629b86d37c10da0ffe17471c67d48765ed83f63b02210086db5746944cecdfce071d9e041072ceac3d1c504382f205676e9a1f02d7632568617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b55d00000000ade9705e1ce7085b899a540d02199bf800200a4729519788b6ed8a2d772b494e186244d8c798c052960dbc8c10c915176795a501020326200121582099169657036d089a2a9821a7d0063d341f1a4613389359636efab5f3cbf1accf225820dd91c55543176ea99b644406dd1dd63774b6af65ac759e06ff40b1c8ab02df6b'

認証:

challenge = h'e4ee05ca9dbced74116540f24ed9adc62aae8507560522844ffa7eea14f7af86'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='android-key.ES256', L=32)

client_data_gen_flags = h'43'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='android-key.ES256', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
extraData_random = h'ab127107eff182bc3230beb5f1dad29c' = b64'qxJxB-_xgrwyML618drSnA'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='android-key.ES256', L=16)
; auth_data_UV_BS は認証器データフラグの UV および BS ビットを設定するが、BS は登録時に BE が設定されていた場合にのみ設定される
auth_data_UV_BS = h'4a'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0b', info='android-key.ES256', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50900000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a22354f344679703238375851525a55447954746d74786971756851645742534b45545f702d36685433723459222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a2071784a78422d5f78677277794d4c3631386472536e41227d'
signature = h'3045022100a2b5e37da43ceb63566f6e2817c6cbef261073d0cadfd213ff6229bd33ddea6c02203d77eb3202fc92b9b5bb843ef082c7766f8c7f23194c92708ff2f3d1de765a8f'

16.15. ES256 クレデンシャルを使用する Apple 匿名アテステーション

登録:

challenge = h'f7f688213852007775009cf8c096fda89d60b9a9fb5a50dd81dd9898af5a0609'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='apple.ES256', L=32)

credential_private_key = h'de987bd9d43eeb44728ce0b14df11209dff931fb56b5b1948de4c0da1144ded0'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='apple.ES256', L=32)
client_data_gen_flags = h'5f'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='apple.ES256', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
extraData_random = h'4e32cf9e939a5d052b14d71b1f6b5364' = b64'TjLPnpOaXQUrFNcbH2tTZA'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='apple.ES256', L=16)
aaguid = h'748210a20076616a733b2114336fc384'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='apple.ES256', L=16)
credential_id = h'9c4a5886af9283d9be3e9ec55978dedfdce2e3b365cab193ae850c16238fafb8'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='apple.ES256', L=32)
; auth_data_UV_BE_BS は認証器データフラグの UV、BE、BS ビットを決定するが、BS は BE が設定されている場合にのみ設定される
auth_data_UV_BE_BS = h'2a'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='apple.ES256', L=1)
attestation_cert_serial_number = h'394275613d5310b81a29ce90f48b61c1'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='apple.ES256', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a22395f61494954685341486431414a7a34774a6239714a316775616e37576c4464676432596d4b396142676b222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a20546a4c506e704f6158515572464e6362483274545a41227d'
attestationObject = h'a363666d74656170706c656761747453746d74a1637835638159025c30820258308201fea0030201020210394275613d5310b81a29ce90f48b61c1300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d030107034200048a3d5b1b4c543a706bf6e4b00afedb3c930b690dd286934fe2911f779cc7761af728e1aa3b0ff66692192daa776b83ddf8e3340d2d9a0eabdfc324eb3e2f136ca38196308193300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e0416041412f1ce6c0ae39b403bfc9200317bc183a4e4d766301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e303306092a864886f76364080204263024a1220420d7a86e7233fb843eb0eeb407d8b76ff7e4f82d218cf5dbb461d752073f5cb29a300a06082a8648ce3d0403020348003045022070f5c2ede3000e9dae358d412b26a4acbf18f4cdeb80f5b13fcd564d090c39ec022100f672e2c3dbe117c9b1490b3c660abf5dcd74398187082dacb58b6744de4aca6068617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b54900000000748210a20076616a733b2114336fc38400209c4a5886af9283d9be3e9ec55978dedfdce2e3b365cab193ae850c16238fafb8a50102032620012158208a3d5b1b4c543a706bf6e4b00afedb3c930b690dd286934fe2911f779cc7761a225820f728e1aa3b0ff66692192daa776b83ddf8e3340d2d9a0eabdfc324eb3e2f136c'

認証:

challenge = h'd3eb2964641e26fed023403a72dde093b19c4ba9008c3f9dd83fcfd347a66d05'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='apple.ES256', L=32)

client_data_gen_flags = h'c2'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='apple.ES256', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
; auth_data_UV_BS は認証器データフラグの UV および BS ビットを設定するが、BS は登録時に BE が設定されていた場合にのみ設定される
auth_data_UV_BS = h'e2'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='apple.ES256', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50900000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a22302d73705a4751654a76375149304136637433676b37476353366b416a442d6432445f503030656d625155222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'3046022100ee35db795ce28044e1f8231d68b3d79a9882f7415aa35c1b5ac74d24251073c8022100dcc65691650a412d0ceef843710c09827acf26c7845bddac07eec95863e7fc4c'

16.16. ES256 クレデンシャルを使用する FIDO U2F アテステーション

登録:

challenge = h'e074372990b9caa507a227dfc67b003780c45325380d1a90c20f81ed7d080c06'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='fido-u2f.ES256', L=32)

credential_private_key = h'51bd002938fa10b83683ac2a2032d0a7338c7f65a90228cfd1f61b81ec7288d0'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='fido-u2f.ES256', L=32)
client_data_gen_flags = h'00'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='fido-u2f.ES256', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
aaguid = h'afb3c2efc054df425013d5c88e79c3c1'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='fido-u2f.ES256', L=16)
credential_id = h'a4ba6e2d2cfec43648d7d25c5ed5659bc18f2b781538527ebd492de03256bdf4'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='fido-u2f.ES256', L=32)
attestation_private_key = h'66fda477a2a99d14c5edd7c1041a297ba5f3375108b1d032b79429f42349ce33'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='fido-u2f.ES256', L=32)
attestation_cert_serial_number = h'04f66dc6542ea7719dea416d325a2401'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='fido-u2f.ES256', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a22344851334b5a4335797155486f696666786e73414e344445557955344452715177672d4237583049444159222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
attestationObject = h'a363666d74686669646f2d7532666761747453746d74a26373696758473045022100f41887a20063bb26867cb9751978accea5b81791a68f4f4dd6ea1fb6a5c086c302204e5e00aa3895777e6608f1f375f95450045da3da57a0e4fd451df35a31d2d98a637835638159022530820221308201c7a003020102021004f66dc6542ea7719dea416d325a2401300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d0301070342000456fffa7093dede46aefeefb6e520c7ccc78967636e2f92582ba71455f64e93932dff3be4e0d4ef68e3e3b73aa087e26a0a0a30b02dc2aa2309db4c3a2fc936dea360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e04160414420822eb1908b5cd3911017fbcad4641c05e05a3301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d040302034800304502200d0b777f0a0b181ad2830275acc3150fd6092430bcd034fd77beb7bdf8c2d546022100d4864edd95daa3927080855df199f1717299b24a5eecefbd017455a9b934d8f668617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b54100000000afb3c2efc054df425013d5c88e79c3c10020a4ba6e2d2cfec43648d7d25c5ed5659bc18f2b781538527ebd492de03256bdf4a5010203262001215820b0d62de6b30f86f0bac7a9016951391c2e31849e2e64661cbd2b13cd7d5508ad225820503b0bda2a357a9a4b34475a28e65b660b4898a9e3e9bbf0820d43494297edd0'

認証:

challenge = h'f90c612981d84f599438de1a500f76926e92cc84bef8e02c6e23553f00485435'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='fido-u2f.ES256', L=32)

client_data_gen_flags = h'2c'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='fido-u2f.ES256', L=1)
; client_data_gen_flags のビット 0x01 が 1 の場合に限り extraData が clientDataJSON に追加される
; auth_data_UV_BS は認証器データフラグの UV および BS ビットを設定するが、BS は登録時に BE が設定されていた場合にのみ設定される
auth_data_UV_BS = h'd1'   ; 導出方法: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='fido-u2f.ES256', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50100000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a222d5178684b59485954316d554f4e3461554139326b6d36537a49532d2d4f417362694e5650774249564455222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'304402206172459958fea907b7292b92f555034bfd884895f287a76200c1ba287239137002204727b166147e26a21bbc2921d192ebfed569b79438538e5c128b5e28e6926dd7'

16.17. WebAuthn 拡張のテストベクトル

この節では、WebAuthn 拡張の値の例を列挙する。

16.17.1. 疑似乱数関数拡張

この節では、疑似乱数関数（prf）拡張の値の例を列挙する。

prf拡張は CTAP2 hmac-secret拡張[FIDO-CTAP]と統合されるため、例は 2 つの節に分けられる。 WebAuthn クライアントおよびWebAuthn 依存パーティに関連する、 WebAuthn prf 拡張の入力および出力の例と、 WebAuthn クライアントおよびWebAuthn 認証器に関連する、 WebAuthn prf 拡張と CTAP2 hmac-secret拡張の間のマッピング例である。

16.17.1.1. Web Authentication API

次の例は、WebAuthn クライアントによるprf拡張の実装、およびWebAuthn 依存パーティによるその利用をテストするために使用できる。例は網羅的ではない。

enabled 出力は登録セレモニー中には常に存在し、認証セレモニー中には決して存在しない。

// 拡張入力の例:
{ prf: {} }

// navigator.credentials.create() からのクライアント拡張出力の例:
{ prf: { enabled: true } }
{ prf: { enabled: false } }

// navigator.credentials.get() からのクライアント拡張出力の例:
{ prf: {} }

results 出力は、eval またはevalByCredential 入力が存在する場合、登録セレモニーまたは認証セレモニー中に存在する場合がある。

// 拡張入力の例:
{ prf: { eval: { first: new Uint8Array([1, 2, 3, 4]) } } }

// navigator.credentials.create() からのクライアント拡張出力の例:
{ prf: { enabled: true } }
{ prf: { enabled: false } }
{ prf: { enabled: true, results: { first: ArrayBuffer } } }

// navigator.credentials.get() からのクライアント拡張出力の例:
{ prf: {} }
{ prf: { results: { first: ArrayBuffer } } }

results.second 出力は、results 出力が存在し、かつ選択された PRF 入力に second 入力が存在していた場合に限り存在する。

// 拡張入力の例:
{
  prf: {
    eval: {
      first: new Uint8Array([1, 2, 3, 4]),
      second: new Uint8Array([5, 6, 7, 8]),
    },
    evalByCredential: {
      "e02eZ9lPp0UdkF4vGRO4-NxlhWBkL1FCmsmb1tTfRyE": {
        first: new Uint8Array([9, 10, 11, 12]),
      }
    }
  }
}

// クレデンシャル "e02eZ9lP..." が使用された場合の navigator.credentials.get() からのクライアント拡張出力の例:
{ prf: { results: { first: ArrayBuffer } } }

// 別のクレデンシャルが使用された場合の navigator.credentials.get() からのクライアント拡張出力の例:
{ prf: {} }
{ prf: { results: { first: ArrayBuffer, second: ArrayBuffer } } }

first およびsecond 出力は任意のBufferSource 型であってよい。等しいfirst およびsecond 入力は、等しいfirst およびsecond 出力を生成する。

// 拡張入力の例:
{
  prf: {
    evalByCredential: {
      "e02eZ9lPp0UdkF4vGRO4-NxlhWBkL1FCmsmb1tTfRyE": {
        first: new Uint8Array([9, 10, 11, 12]),
        second: new Uint8Array([9, 10, 11, 12])
      }
    }
  }
}

// navigator.credentials.get() からのクライアント拡張出力の例:
{
  prf: {
    results: {
      first: new Uint8Array([0xc4, 0x17, 0x2e, 0x98, 0x2e, 0x90, 0x97, 0xc3, 0x9a, 0x6c, 0x0c, 0xb7, 0x20, 0xcb, 0x37, 0x5b, 0x92, 0xe3, 0xfc, 0xad, 0x15, 0x4a, 0x63, 0xe4, 0x3a, 0x93, 0xf1, 0x09, 0x6b, 0x1e, 0x19, 0x73]),
      second: new Uint32Array([0x982e17c4, 0xc397902e, 0xb70c6c9a, 0x5b37cb20, 0xadfce392, 0xe4634a15, 0x09f1933a, 0x73191e6b]),
    }
  }
}

この節で使用する疑似ランダム値は次のように生成された。

"e02eZ9lPp0UdkF4vGRO4-NxlhWBkL1FCmsmb1tTfRyE" = Base64Url(SHA-256(UTF-8("WebAuthn PRF test vectors") || 0x00))
h'c4172e982e9097c39a6c0cb720cb375b92e3fcad154a63e43a93f1096b1e1973' = SHA-256(UTF-8("WebAuthn PRF test vectors") || 0x01)

16.17.1.2. CTAP2 `hmac-secret` 拡張

次の例は、WebAuthn クライアントが prf拡張から[FIDO-CTAP]のhmac-secret拡張を使用する方法の実装をテストするために使用できる。例は CDDL [RFC8610] 表記で示される。例は網羅的ではない。

以下の共有定義は、以降のすべての例で使用される。

; 与えられた入力パラメーター:
platform_key_agreement_private_key = 0x0971bc7fb1be48270adcd3d9a5fc15d5fb0f335b3071ff36a54c007fa6c76514
authenticator_key_agreement_public_key = {
    1: 2,
    3: -25,
    -1: 1,
    -2: h'a30522c2de402b561965c3cf949a1cab020c6f6ea36fcf7e911ac1a0f1515300',
    -3: h'9961a929abdb2f42e6566771887d41484d889e735e3248518a53112d2b915f00',
}
authenticator_cred_random = h'437e065e723a98b2f08f39d8baf7c53ecb3c363c5e5104bdaaf5d5ca2e028154'

first およびsecond 入力は、例の中でそれぞれprf_eval_firstおよびprf_eval_secondへマッピングされる。例のprf_results_firstおよびprf_results_secondの値は、それぞれ results.first および results.second 出力へマッピングされる。

PIN プロトコル 2 を使用する単一入力の場合:

; 依存パーティからの入力:
prf_eval_first = h'576562417574686e20505246207465737420766563746f727302'

; クライアントが計算:
shared_secret = h'0c63083de8170101d38bcf8bd72309568ddb4550867e23404b35d85712f7c20d8bc911ee23c06034cbc14290b9669bec07739053c5a416e313ef905c79955876'
salt1 = h'527413ebb48293772df30f031c5ac4650c7de14bf9498671ae163447b6a772b3'
salt_enc = h'23dde5e3462daf36559b85c4ac5f9656aa9bfd81c1dc2bf8533c8b9f3882854786b4f500e25b4e3d81f7fc7c74236229'

; 認証器が計算:
output1 = h'3c33e07d202c3b029cc21f1722767021bf27d595933b3d2b6a1b9d5dddc77fae'
output_enc = h'3bfaa48f7952330d63e35ff8cd5bca48d2a12823828915749287256ab146272f9fb437bf65691243c3f504bd7ea6d5e6'

; クライアントが復号:
prf_results_first = h'3c33e07d202c3b029cc21f1722767021bf27d595933b3d2b6a1b9d5dddc77fae'

PIN プロトコル 2 を使用する 2 入力の場合:

; 依存パーティからの入力:
prf_eval_first = h'576562417574686e20505246207465737420766563746f727302'
prf_eval_second = h'576562417574686e20505246207465737420766563746f727303'

; クライアントが計算:
shared_secret = h'0c63083de8170101d38bcf8bd72309568ddb4550867e23404b35d85712f7c20d8bc911ee23c06034cbc14290b9669bec07739053c5a416e313ef905c79955876'
salt1 = h'527413ebb48293772df30f031c5ac4650c7de14bf9498671ae163447b6a772b3'
salt2 = h'd68ac03329a10ee5e0ec834492bb9a96a0e547baf563bf78ccbe8789b22e776b'
salt_enc = h'd9f4236403e0fe843a8e4e5be764d120904c198ad6e77b089876a3391961f183b0008b4ca66b91cd72aa35b6151ff981f6e5649f3c040e6615ad7dd8ae96ef23b229a5c97c3f0dcd8605eee166ce163a'

; 認証器が計算:
output1 = h'3c33e07d202c3b029cc21f1722767021bf27d595933b3d2b6a1b9d5dddc77fae'
output2 = h'a62a8773b19cda90d7ed4ef72a80a804320dbd3997e2f663805ad1fd3293d50b'
output_enc = h'90ee52f739043bc17b3488a74306d7801debb5b61f18662c648a25b5b5678ede482cdaff99a537a44f064fcb10ce6e04dfd27619dc96a0daff8507e499296b1eecf0981f7c8518b277a7a3018f5ec6fb'

; クライアントが復号:
prf_results_first = h'3c33e07d202c3b029cc21f1722767021bf27d595933b3d2b6a1b9d5dddc77fae'
prf_results_second = h'a62a8773b19cda90d7ed4ef72a80a804320dbd3997e2f663805ad1fd3293d50b'

PIN プロトコル 1 を使用する単一入力の場合:

; 依存パーティからの入力:
prf_eval_first = h'576562417574686e20505246207465737420766563746f727302'

; クライアントが計算:
shared_secret = h'23e5ed7157c25892b77732fb9c8a107e3518800db2af4142f9f4adfacb771d39'
salt1 = h'527413ebb48293772df30f031c5ac4650c7de14bf9498671ae163447b6a772b3'
salt_enc = h'ab8c878bb05d04700f077ed91845ec9c503c925cb12b327ddbeb4243c397f913'

; 認証器が計算:
output1 = h'3c33e07d202c3b029cc21f1722767021bf27d595933b3d2b6a1b9d5dddc77fae'
output_enc = h'15d4e4f3f04109b492b575c1b38c28585b6719cf8d61304215108d939f37ccfb'

; クライアントが復号:
prf_results_first = h'3c33e07d202c3b029cc21f1722767021bf27d595933b3d2b6a1b9d5dddc77fae'

この節で使用する入力および疑似ランダム値は次のように生成された。

seed = UTF-8("WebAuthn PRF test vectors")
prf_eval_first = seed || 0x02
prf_eval_second = seed || 0x03
platform_key_agreement_private_key = SHA-256(seed || 0x04)
authenticator_key_agreement_public_key = P256-Public-Key(sk) ここでsk = SHA-256(seed || 0x05)
authenticator_cred_random = SHA-256(seed || 0x06)
PIN プロトコル 2 を使用する単一入力salt_enc内のiv: 切り詰めたSHA-256(seed || 0x07)
PIN プロトコル 2 を使用する 2 入力salt_enc内のiv: 切り詰めたSHA-256(seed || 0x08)
PIN プロトコル 2 を使用する単一入力output_enc内のiv: 切り詰めたSHA-256(seed || 0x09)
PIN プロトコル 2 を使用する 2 入力output_enc内のiv: 切り詰めたSHA-256(seed || 0x0a)

17. 謝辞

この仕様のレビューおよび貢献を行った以下の方々に感謝する。 Yuriy Ackermann, James Barclay, Richard Barnes, Dominic Battré, Julien Cayzac, Domenic Denicola, Rahul Ghosh, Brad Hill, Nidhi Jaju, Jing Jin, Wally Jones, Ian Kilpatrick, Axel Nennker, Zack Newman, Yoshikazu Nojima, Kimberly Paulhamus, Adam Powers, Yaron Sheffer, Anne van Kesteren, Johan Verrept, および Boris Zbarsky。

全体的な登録および認証フロー図（図 1および図 2）を作成した Adam Powers に感謝する。

Web Authentication Working Groupの共同議長として貢献した Anthony Nadalin, John Fontana, および Richard Barnes に感謝する。

また、W3C Team Contacts として貢献した Simone Onofri, Philippe Le Hégaret, Wendy Seltzer, Samuel Weiler, および Harry Halpin にも感謝する。

18. 改訂履歴

この節は規範的ではない。

この節では、この仕様に長期にわたって加えられた重要な変更を要約する。

18.1. Web Authentication レベル 3 [webauthn-3-20260825]以降の変更

18.1.1. 実質的な変更

Web Authentication APIおよびその動作方法に、以下の変更が加えられた。

変更:

prf拡張の認証器拡張出力に平文の PRF 出力を含めないことを必須とした。
Virtual Authenticator のクレデンシャルの追加およびクレデンシャルプロパティの設定コマンドを、署名カウンターの作成、更新、削除機能を含む、明示的なsignCount処理で拡張した。

新機能:

リモートデスクトップ WebAuthn 操作向けに、remoteClientDataJSON登録および認証拡張を追加した。これには、既定で拒否される強力な機能、ポリシー制御機能であり、その既定の許可リストが 'none'であるもの、およびクライアント向けのセキュリティ上の考慮事項を含む。§ 10.1.6 リモートクライアントデータ JSON 拡張 (remoteClientDataJSON)、§ 5.9 Permissions Policy 統合、§ 13.4.1 remoteClientDataJSON 拡張。

18.1.2. 編集上の変更

文書の明瞭性、可読性、ナビゲーション性、および同様の側面を改善するため、以下の変更が加えられた。

クレデンシャル作成および認証アルゴリズムでremoteClientDataJSON拡張が使用するクライアントデータ構築およびシリアル化手順に、明示的なアンカーを追加した。
ユーザー検証済みの設定 Virtual Authenticator コマンド向けに、 JSON ユーザー検証済み設定パラメーターオブジェクトを定義した。

18.2. Web Authentication レベル 2 [webauthn-2-20210408]以降の変更

18.2.1. 実質的な変更

Web Authentication APIおよびその動作方法に、以下の変更が加えられた。

変更:

タイムアウトの指針を更新した: § 15.1 セレモニータイムアウトの推奨範囲
uvm拡張は含まれなくなった。代わりに L2 [webauthn-2-20210408]を参照すること。
アテステーション済みクレデンシャルデータ内のaaguidは、attestation 設定がnoneの場合でもゼロ化されなくなった。 § 5.1.3 新しいクレデンシャルの作成 - PublicKeyCredential の [[Create]](origin, options, sameOriginWithAncestors) 内部メソッド
ESP256 (-9)、ESP384 (-51)、ESP512 (-52) の公開鍵に非圧縮形式を使用する要件を追加した: § 5.8.5 暗号アルゴリズム識別子 (typedef COSEAlgorithmIdentifier)
§ 5.6 AbortSignal による操作の中止における、文書がフォーカスを失った場合に中止するという推奨を削除した。

非推奨:

登録パラメーター publicKey.rp.name: § 5.4.1 公開鍵エンティティの説明 (dictionary PublicKeyCredentialEntity)
§ 8.5 Android SafetyNet アテステーションステートメント形式
tokenBindingは [RESERVED] に変更された。
フィールド内の言語および方向メタデータは推奨されなくなった。
pubKeyCredParamsで COSEAlgorithmIdentifier 値 -9、-51、-52、-19 を使用しないという推奨を追加した。

新機能:

新しい JSON（デ）シリアル化メソッド:
クロスオリジン iframe 内での create 操作:
- § 5.1.3 新しいクレデンシャルの作成 - PublicKeyCredential の [[Create]](origin, options, sameOriginWithAncestors) 内部メソッド
- § 5.10 iframe 要素内での Web Authentication の使用
create の条件付き mediation: § 5.1.3 新しいクレデンシャルの作成 - PublicKeyCredential の [[Create]](origin, options, sameOriginWithAncestors) 内部メソッド
get の条件付き mediation: § 5.1.4 既存のクレデンシャルを使用してアサーションを作成する
§ 5.1.7 クライアント機能の可用性 - PublicKeyCredential の getClientCapabilities() メソッド
- § 14.5.4 クライアント機能の開示
§ 5.8.4 認証器トランスポート列挙 (enum AuthenticatorTransport)に新しい enum 値hybridを追加した。
§ 5.1.10 クレデンシャルの変更を認証器へ通知する - PublicKeyCredential の signal メソッド
新しいクライアントデータ属性 topOrigin: § 5.8.1 WebAuthn 署名で使用されるクライアントデータ (dictionary CollectedClientData)
§ 5.8.8 ユーザーエージェントヒント列挙 (enum PublicKeyCredentialHint)
§ 5.11 関連オリジンをまたいだ Web Authentication の使用
認証器データフラグBEおよびBSを割り当てた。
§ 8.9 複合アテステーションステートメント形式
§ 10.1.4 疑似乱数関数拡張 (prf)
登録パラメーター publicKey.attestationFormats: § 5.4 クレデンシャル作成のオプション (dictionary PublicKeyCredentialCreationOptions)

18.2.2. 編集上の変更

文書の明瞭性、可読性、ナビゲーション性、および同様の側面を改善するため、以下の変更が加えられた。

§ 1.2 ユースケースを、展開状況の進展を反映するよう更新した。
クレデンシャルレコード概念を導入し、依存パーティが保存する必要のあるデータと、それが登録および認証セレモニーの間でどのように関連するかを形式化した。
エラー条件を明確化した。
- § 5.1.3.1 Create 要求の例外
- § 5.1.4.3 Get 要求の例外
§ 6.4 文字列の処理を、責任の分担を明確にするため、 § 6.4.1.1 クライアントによる文字列の切り詰めおよび§ 6.4.1.2 認証器による文字列の切り詰めという小節に分割した。
§ 16 テストベクトルを追加した。
規範的な文言を「注」ブロックの外へ移動した。
Web Authentication: 公開鍵クレデンシャルへアクセスするための API - レベル 3 § sctn-isUserVerifyingPlatformAuthenticatorAvailable およびWeb Authentication: 公開鍵クレデンシャルへアクセスするための API - レベル 3 § sctn-getClientCapabilitiesにある Permissions Policy に関する古い注記を削除した。
Web Authentication: 公開鍵クレデンシャルへアクセスするための API - レベル 3 § sctn-sample-registrationのサンプルコードにアルゴリズム -8 (EdDSA) を追加した。

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

概要

この文書のステータス

1. はじめに

1.1. 仕様ロードマップ

1.2. ユースケース

1.2.1. マルチデバイスクレデンシャルを使用する消費者

1.2.1.1. 登録

1.2.1.2. 認証

1.2.2. シングルデバイスクレデンシャルを使用する従業員

1.2.2.1. 登録

1.2.2.2. 認証

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

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.3.1. 作成要求の例外

5.1.4. 既存のクレデンシャルを使用してアサーションを作成する

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

5.1.4.2. 認証器へのクレデンシャル 要求の発行

5.1.4.3. 取得要求の例外

5.1.5. 既存のクレデンシャルを保存する - PublicKeyCredential の [[Store]](credential, sameOriginWithAncestors) 内部メソッド

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

5.1.7. クライアント機能の利用可能性 - PublicKeyCredential の getClientCapabilities() メソッド

5.1.8. 登録セレモニーのオプションを逆シリアル化する - PublicKeyCredential の parseCreationOptionsFromJSON() メソッド

5.1.9. 認証セレモニーのオプションを逆シリアル化する - PublicKeyCredential の parseRequestOptionsFromJSON() メソッド

5.1.10. クレデンシャルの変更を認証器に通知する - PublicKeyCredential のシグナルメソッド

5.1.10.1. 非同期 RP ID 検証 アルゴリズム

5.1.10.2. signalUnknownCredential(options)

5.1.10.3. signalAllAcceptedCredentials(options)

5.1.10.4. signalCurrentUserDetails(options)

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. 認証器アタッチメント列挙（列挙型 AuthenticatorAttachment）

5.4.6. 常駐キー要件列挙（列挙型 ResidentKeyRequirement）

5.4.7. アテステーション伝達設定列挙（列挙型 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. クレデンシャル型列挙（列挙型 PublicKeyCredentialType）

5.8.3. クレデンシャル記述子（辞書 PublicKeyCredentialDescriptor）

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

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

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

5.8.7. クライアント機能列挙（列挙型 ClientCapability）

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

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.1. PublicKeyCredential の `[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)` 内部メソッド

5.1.4.2. 認証器へのクレデンシャル要求の発行

5.1.5. 既存のクレデンシャルを保存する - PublicKeyCredential の `[[Store]](credential, sameOriginWithAncestors)` 内部メソッド

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

5.1.7. クライアント機能の利用可能性 - PublicKeyCredential の `getClientCapabilities()` メソッド

5.1.8. 登録セレモニーのオプションを逆シリアル化する - PublicKeyCredential の `parseCreationOptionsFromJSON()` メソッド

5.1.9. 認証セレモニーのオプションを逆シリアル化する - PublicKeyCredential の `parseRequestOptionsFromJSON()` メソッド

5.1.10.1. 非同期 RP ID 検証アルゴリズム

5.1.10.2. `signalUnknownCredential(options)`

5.1.10.3. `signalAllAcceptedCredentials(options)`

5.1.10.4. `signalCurrentUserDetails(options)`

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. 認証器アタッチメント列挙（列挙型 `AuthenticatorAttachment`）

5.4.6. 常駐キー要件列挙（列挙型 `ResidentKeyRequirement`）

5.4.7. アテステーション伝達設定列挙（列挙型 `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. クレデンシャル型列挙（列挙型 `PublicKeyCredentialType`）

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

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

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

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

5.8.7. クライアント機能列挙（列挙型 `ClientCapability`）

5.8.8. ユーザーエージェントヒント列挙（列挙型 `PublicKeyCredentialHint`）

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 アテステーション、およびアサーション署名の署名形式

9.5. 認証器拡張処理

11.1.1. 認証器拡張機能