Web Authentication

Last updated 5 months ago

Web Authentication: An API for accessing Public Key Credentials Level 1 和訳例(作業中)

はじめに

本和訳は個人で作成・公開している、あくまで例であり、意訳や間違いが含まれておりますことをご了承ください。

コメントや誤り指摘等は、Twitter @sami_mkw_ までいただけますと幸いですm(_ _)m

Web Authentication

W3C Candidate Recommendation, 20 March 2018

要旨(Abstract)

本仕様では,ユーザを強力に認証することを目的とした,Webアプリケーションによる強力・実績あり・範囲が限定されている公開鍵ベースのクレデンシャルを作成・使用可能なAPIを定義している.概念的には,それぞれが対象のRPに限定されている1つ以上の公開鍵クレデンシャルが,Webアプリケーションと連携してユーザエージェントによって作られ,認証器に保存される。ユーザエージェントは,ユーザのプライバシを保護するために公開鍵へのアクセスを仲介する.認証器は,ユーザの同意なしに操作が行われないようにする責任を負う.認証器はRPにそのプロパティの暗号証明をアテステーション経由で提供する.本仕様では,署名とアテステーションの機能を含め,WebAuthn準拠の認証器の機能モデルについても説明している.

Status of this document

1Introduction

1.1. ユースケース

以下のユースケースシナリオでは,2つの非常に異なるタイプの認証器の使用方法とシナリオの概要を示す.サンプルコードと追加のシナリオは,12 サンプルシナリオの後半に記載している.

1.1.1. 登録

  • 携帯電話で:

    • ユーザはブラウザでexample.comにアクセスし,いつもの方法(パスワードなどの従来の方法)を使用して既存のアカウントにサインインするか,新しいアカウントを作成する.

    • 携帯電話に「このデバイスをexample.comに登録しますか?」というメッセージが表示される.

    • ユーザが同意する.

    • 携帯電話は,事前に設定された認可行為(PIN,生態認証など)を求めるプロンプトを表示し,ユーザはこれを提供する.

    • ウェブサイトに「登録が完了しました」というメッセージが表示される.

1.1.2. 認証

  • ノートPCまたはデスクトップPCで:

    • ユーザがブラウザでexample.comにアクセスすると,「携帯電話でログイン」オプションが表示される.

    • ユーザがこのオプションを選択すると,ブラウザに「携帯電話で操作を完了してください」というメッセージが表示される.

  • 自分の携帯電話で:

    • 「example.comにサインインする」という個別のプロンプトまたは通知が表示される.

    • ユーザはこのプロンプト/通知を選択する.

    • ユーザに,example.comのIDのリストが表示される(例:「Aliceとしてログイン/ Bobとしてログイン」).

    • ユーザはIDを選択し,認可行為(PIN,生体認証など)を求められ,これを提供する.

  • ノートPC/デスクトップに戻る:

    • Webページには,選択したユーザでログインしていることが示され,ログインしたページに移動する.

1.1.3. その他の使用例と構成

その他さまざまなユースケースおよび構成も可能(以下に挙げるものに限定されない).

  • ユーザはノートPCでexample.comにアクセスし,自分の携帯電話にクレデンシャルを作成して登録する.

  • ユーザは,USBまたはUSB+NFC/BLE接続オプションを備えた「フォブ」などの独立したローミング認証器を取得,ノートPCや携帯電話のブラウザでexample.comにアクセスし,フォブのクレデンシャルを作成して登録する.

  • RPは,支払や他の金融取引などの単一の取引を承認するため,ユーザに認可行為を促す.

2. コンフォーマンス

この仕様は,3つの準拠クラスを定義する.これらのクラスはそれぞれ,準拠メンバが,他クラスの非準拠メンバまたは不適合メンバに対して安全であるように指定されている.

2.1. ユーザエージェント

ユーザエージェントが準拠しているとみなされるためには,5Web認証API に記載されたとおりに動作しなければならない(MUST).準拠しているユーザエージェントは,最終的な結果が本仕様のアルゴリズムによって得られる結果と見分けがつかない限り,記載されているアルゴリズムを任意の方法で実装してもよい(MAY).

準拠しているユーザエージェントは,"Web IDL" の仕様で説明されているように,この仕様のIDLフラグメントに準拠した実装でなければならない(MUST).[WebIDL-1]

2.2. 認証器

認証器は,6. WebAuthn認証器モデル によって定義された操作を提供しなければならず(MUST),それらの操作は記載されている通りに動作しなければならない(MUST).これは,準拠しているユーザエージェントによって使用できるようになるための機能およびセキュリティ要件の集合である.

1.1. ユースケースで説明したように,認証器は,ユーザエージェントの基礎となるオペレーティングシステム,または外部ハードウェア,またはその両方の組み合わせで実装することができる.

2.2.1. FIDO U2Fとの下位互換性

8.6. FIDO U2Fアテステーションステートメントフォーマットのみをサポートする認証器にはユーザーハンドルを格納するメカニズムがないため,userHandleは常にnullが返される.

2.3. RP(Relying Parties)

RPは,本仕様書によって提供されるセキュリティを享受するため,7. RP業務 に記述されている通りに動作しなければならない(MUST).

2.4. すべての準拠クラス

上記準拠クラスのメンバが実行するすべてのCBORエンコーディングは,CTAP2に基づくCBORエンコーディング形式でなければならない(MUST).上記の準拠クラスのすべてのデコーダは、CTAP2に基づくCBORエンコーディング形式で適切にエンコードされていないCBORを拒否しなければならず(SHOULD),重複したマップキーでメッセージを拒否しなければならない(SHOULD).

3Dependencies

4. 用語

  • アサーション(Assertion)

    • 認証アサーションを参照

  • アテステーション(Attestation)

    • 一般にアテステーションは,証明,確認,または認証を行うためのステートメントである.WebAuthnのコンテキストでは,認証器ととそれが発行するデータの出所を証明するためにアテステーションが採用されている.例えば,クレデンシャルID,クレデンシャル鍵ペア,署名カウンタなどである.アテステーションは,登録中にアテステーションオブジェクト内に伝達される.6.3. アテステーションおよび図3を参照.クライアントプラットフォームが,アテステーションオブジェクトのアテステーションステートメントをどのように証明するか,AAGUID部分をRPに伝えるかどうかについては,アテステーション伝達によって表される.

  • アテステーション証明書 (Attestation Certificate)

    • 認証器が製造と機能を証明するためにアテステーションキーペアのX.509証明書が使用される.登録時に認証器は,アテステーション秘密鍵を使用し,RP固有の公開鍵クレデンシャル(および追加データ)に署名する.生成した公開鍵はauthenticatorMakeCredentialオペレーションを介して返される.RPは,アテステーション証明書で伝達されたアテステーション公開鍵を使用してアテステーション署名を検証する.セルフアテステーションの場合,認証器には個別のアテステーションキーペアもアテステーション証明書もない.詳細についてはセルフアテステーションを参照のこと.

  • 認証 (Authentication)

    • ユーザおよびデバイス(少なくとも1つの認証器を含む)が協同し,事前に登録された(登録を参照)公開鍵クレデンシャルと関連する秘密鍵クレデンシャルをユーザが制御することを,RPに暗号的に証明する儀.これにはユーザ実在確認またはユーザ検証が含まれる.

  • 認証アサーション (Authentication Assertion)

    • authenticatorGetAssertionのオペレーション結果として認証器から返された,暗号署名された認証アサーションレスポンスオブジェクト.

  • 認証器(Authenticator)

    • WebAuthn Clientが(i)公開鍵証明書を生成してそれをRPに登録し,(ii)潜在的にユーザを検証することで認証し,次にWebAuthnクライアントと連携しているRPが提示するチャレンジやその他のデータを認証アサーションの形式で暗号化署名して返信する.

  • 認可行為 (Authorization Gesture)

    • 認可行為は,登録・認証の儀の一部として、認証器を用いてユーザが行う物理的な対話である.そのような認可行為を行うことによって,ユーザは儀を進めるために同意する(認可する).使用した認証器が可能ならユーザ検証を伴うことがある(MAY),またはユーザ実在確認の簡単なテストを行う(MAY).

  • 生体認証 (Biometric Recognition)

    • 生物学的および行動的特徴に基づく個の自動認証[ISOBiometricVocabulary].

  • 生体認証器 (Biometric Authenticator)

    • 生体認証認識が実装されている認証器.

  • 儀式 (Ceremony)

    • 儀式の概念[Ceremony]は,人間がコンピュータのそばにあり,ユーザインタフェースや人と人とのコミュニケーション,およびデータを運ぶ物理的オブジェクトの転送を含む通信リンクを持つ,ネットワークプロトコルの概念の拡張である.

      プロトコルの帯域外であるものは,儀式の帯域内である.本仕様書においては,登録と認証は儀式であり,認可行為はそれらの構成要素である.

  • クライアント (Client)

    • WebAuthnクライアント,準拠ユーザエージェントを参照.

  • クライアント側 (Client-Side)

    • 一般的に,ユーザのプラットフォームデバイス,ユーザエージェント,認証器,およびそれらをすべてに関連する組合せを指す.

  • クライアント側組込み秘密鍵クレデンシャル (Client-side-resident Credential Private Key)

    • クライアント側組込み秘密鍵クレデンシャルは,クライアントプラットフォーム上,または認証器自体(例えば分離第一因子ーミング認証器の場合など)に格納される.このようなクライアント側秘密鍵クレデンシャルのストレージは,認証器がRP IDのみが与えられた秘密鍵クレデンシャルをユーザの操作を伴いながら選別することができる(例えば、RP IDに関連付けられたクレデンシャルの選択リストをユーザに提供することによって).

      定義上,秘密鍵は常に認証器によって排他的に制御される.クライアント側組込み秘密鍵クレデンシャルの場合,認証器はラップされた鍵材料のストレージをクライアントプラットフォームにオフロードする可能性があるが,クライアントプラットフォームはキーストレージをリモートエンティティ(例えばRPサーバ)にオフロードすることは起こり得ない.

  • 準拠ユーザエージェント (Conforming User Agent)

    • 基盤となるプラットフォームと連携して,本仕様に記載されているWeb認証APIとアルゴリズムを実装し,認証器とRP間の通信を処理するユーザエージェント.

  • クレデンシャルID(Credential ID)

    • 公開鍵クレデンシャルのソースとその認証アサーションを識別する,確率的にユニークなバイトシーケンス.

    • クレデンシャルIDは,認証器によって次の2つの形式で生成される:

      • 少なくとも100ビットのエントロピーを含む16バイト,あるいは

      • クレデンシャルIDがなくても公開鍵クレデンシャルのソースは暗号化されているため,それを管理している認証器のみが復号化できる.これにより,RPに必要な状態を格納させることによって,認証器がほとんどステートレスになることを可能にする.

        注:[FIDO-UAF-AUTHNR-CMDS]には,"セキュリティガイドライン" に基づく暗号化技術に関するガイダンスが含まれている.

    • RPが,これら2つのクレデンシャルIDの形式を区別する必要はない.

  • 公開鍵クレデンシャル(Credential Public Key)

    • 認証器によって生成され,登録時にRPに返されたRP固有のクレデンシャル鍵ペアの公開鍵部分(公開鍵証明書も参照のこと).クレデンシャル鍵ペアの秘密鍵部分はクレデンシャル秘密鍵と呼ばれる.セルフアテステーションの場合,クレデンシャル鍵ペアはアテステーションの鍵ペアとしても使用される.詳細はセルフアテステーションを参照のこと.

  • 人の嗜好性(Human Palatability)

    • 人が好む識別子は,ランダムに生成された一連のビット列である識別子[EduPersonObjectClassSpec]とは対照的に,典型的な人であるユーザが記憶して再現可能であることが意図されている.

  • 公開鍵クレデンシャルのソース(Public Key Credential Source)

    • 認証アサーションを生成するために認証器によって使用されるクレデンシャルソース([CREDENTIAL-MANAGEMENT-1]).公開鍵クレデンシャルのソースは,次の項目を含む形で構成されている.

      • タイプ(type)

        • 値はPublicKeyCredentialTypeであり,デフォルトはpublic-keyである.

      • id

        • クレデンシャルID.

      • 秘密鍵(privateKey)

        • 秘密鍵クレデンシャル.

      • RP ID(rpId)

        • 関連付けられている公開鍵クレデンシャルのソースを識別するためのRPの識別子.

      • ユーザハンドル(userHandle)

        • 公開鍵クレデンシャルのソースが生成されたときに関連付けられたユーザハンドル.null可能.

      • その他のUI(otherUI)

        • UIに通知するために認証器によって使用されるオプションの情報.例えば,ユーザのdisplayNameを含めることができる.

    • authenticatorMakeCredentialオペレーションは,管理認証器に紐付けられた公開鍵クレデンシャルのソースを生成し,その秘密鍵に関連付けられた公開鍵クレデンシャルを返却する.RPは,この公開鍵クレデンシャルを使用して,この公開鍵クレデンシャルのソースによって生成された認証アサーションを検証することができる.

  • 公開鍵クレデンシャル(Public Key Credential)

    • 一般的にクレデンシャルは,あるエンティティが別のエンティティに認証してもらうために,前者が後者に提示するデータである[RFC4949].公開鍵クレデンシャルという用語は次のうちのいずれかを指す:公開鍵クレデンシャルのソース,公開鍵クレデンシャルのソースに対応する可能性があると証明された公開鍵クレデンシャル,認証アサーション.どれであるかは一般的に文脈によって決定される.

      注:これは[RFC4949]の意図的な違反である.英語では,"クレデンシャル" は,a) ステートメントを証明するために提示されるものと,b) 複数回使用されることを意図したものとの両方である. 公開鍵システムにおいて,片方のデータで両方の基準を安全に達成することは不可能である.[RFC4949]は,複数回使用できるものとしてクレデンシャルを定義することを選択し(公開鍵),本仕様では "クレデンシャル" に英語の柔軟性が与えられる.本仕様では,[RFC4949]クレデンシャルに関連するデータを特定するために,より具体的な用語を使用している:

      • "認証情報(Authentication information)"(秘密鍵を含む可能性あり)

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

      • "署名値"

        • 認証アサーション

      • [RFC4949] "クレデンシャル"

        • 公開鍵クレデンシャルまたはアテステーションオブジェクト

    • 登録時に,認証器は非対称鍵ペアを生成し,その秘密鍵部分およびRPからの情報を公開鍵クレデンシャルのソースに格納する.公開鍵部分はRPに返却され,RPはそれを現在のユーザのアカウントと紐付けて保管する.その後は,RP IDによって識別されるそのRPのみが,get()メソッドを介して認証の儀式で公開鍵クレデンシャルを使用することができる.RPは,格納された公開鍵クレデンシャルのコピーを使用して,結果の認証アサーションを検証する.

  • レート制限(Rate Limiting)

    • 一定時間内に連続して失敗した認証試行の回数を制限することにより,認証器がブルートフォース攻撃に対する制御を実装するプロセス(スロットルとも呼ばれる).限界に達すると,認証器は連続した試行ごとに指数関数的に増加する遅延を課すか,現在の認証方式を無効にして異なる認証方式を提供する必要がある(利用可能なものがあれば).レート制限は,多くの場合,ユーザ検証の一部として実装される.

  • 登録 (Registration)

    • ユーザ,RP,ユーザのデバイス(少なくとも1つの認証器を含む)が共同して公開鍵クレデンシャルを生成し,RPにおけるユーザアカウントに関連付ける一連の儀式.これには、ユーザの実在確認またはユーザ検証が使用される.

  • RP(Relying Party)

    • WebアプリケーションがWeb認証APIを使用してユーザを登録および認証するエンティティ.登録と認証をそれぞれ参照のこと.

      注:RPという用語は,他のコンテキスト(X.509やOAuthなど)でも使用されるが,あるコンテキストでRPとして機能するエンティティが,他のコンテキストでも必ずしもRPということではない.

  • RP ID(Relying Party Identifier)

    • 登録や認証を実行しているRPを識別する有効なドメイン文字列.公開鍵クレデンシャルは,登録された同じエンティティ(RP IDで識別される)との認証にのみ使用できる.デフォルトでは,WebAuthn操作のRP IDは,呼出し元の有効なドメインに設定される.呼出し元仕様のRP ID値が登録可能なドメイン接尾辞であるか,呼出し元の有効なドメインと等しい場合,デフォルト値は呼出し元によって上書きされる可能性がある(MAY).5.1.3. 新しいクレデンシャルの生成 - 公開鍵クレデンシャルの[[Create]](origin,options,sameOriginWithAncestors)メソッドと 5.1.4. アサーションを生成する既存のクレデンシャルの使用 - 公開鍵クレデンシャルの[[Get]](option)メソッドを参照のこと.

      注:公開鍵クレデンシャルの有効範囲は,RPであり,以下の制限と緩和がある:

      • スキームは常にhttps(制限)

      • ホストは,RPの有効ドメインと同等であってもよいし,RPの有効ドメインの登録可能なドメイン接尾辞と同等であってもよい(利用可能な緩和)

      • そのホスト上のすべての(TCP)ポート(緩和)

      これは,包括的に展開されたクレデンシャル(例えば,クッキー[RFC6265])のふるまいを適合させるために行われる.document.domainの設定者が提供するものと同じ "same-origin" の制限が緩和されていることに注意する.

  • ユーザ実在確認(Test of User Presence)

    • ユーザの実在確認は,認可行為と技術プロセスの単純な形式である.ユーザは(通常は)単に認証器に触れ,対話して(他の様式も存在する可能性はある), 真理値の結果を生成する.このユーザ実在確認は,ユーザ検証は構成しないことに注意する.定義上,ユーザの実在確認は生体認証を行うことができず,パスワードやPINなどの共有秘密の提示も伴わないためである.

  • ユーザ同意 (User Consent)

    • ユーザ同意とは,求められている内容にユーザが同意すること,つまり,プロンプトの内容を読み理解することを意味する.認可行為はユーザ同意を示すためにしばしば採用される儀式である.

  • ユーザハンドル(User Handle)

    • ユーザーハンドルはRPによって指定される,そのRPにおけるユーザアカウントの一意の識別子である. ユーザハンドルは最大64バイトのサイズを持つバイトシーケンス.

    • ユーザハンドルは,ユーザに表示されることを意図したものではなく,クレデンシャルの数を制御するためにRPによって使用される.認証器は,同じユーザハンドル配下にある特定のRPに対して複数のクレデンシャルを所有することはない.

  • ユーザ検証(User Verification)

    • 認証器がauthenticatorMakeCredentialオペレーションとauthenticatorGetAssertionオペレーションの呼出しをローカルで認可する技術プロセス.ユーザの検証は,様々な認可行為様式を通じて推進される(MAY).例えば,PINコード,パスワード,生態認証(指紋の提示)など[ISOBiometricVocabulary].その目的は,個々のユーザーを区別できるようにすることである.authenticatorMakeCredentialオペレーションとauthenticatorGetAssertionオペレーションの呼出しは,認証器によって管理される鍵の使用を意味することに注意すること.セキュリティのため,ユーザの検証と秘密鍵クレデンシャルの使用は,認証器を定義する単一の論理セキュリティ境界内で行われなければならないことに注意すること.

  • 実在ユーザ/UP(User Present/UP)

    • ユーザ実在確認が正常に完了すると,ユーザは"実在する"と扱われる.

  • 検証済ユーザ/UV(User Verified/UV)

    • ユーザ検証プロセスが正常に完了すると,ユーザは"検証済み"と扱われる.

  • WebAuthnクライアント(WebAuthn Client)

    • ここでは単にクライアントとも呼ばれる.準拠ユーザエージェントも参照のこと.WebAuthnクライアントは,ユーザエージェントに一般に実装された中間的なエンティティである(全体的にまたは部分的に).概念的には,Web認証APIの基礎となり、[[Create]](起点,オプション,sameOriginWithAncestors)および[[DiscoverFromExternalSource]](起点,オプション,sameOriginWithAncestors)の内部メソッドの実装を体現している.これは,基礎となる認証器操作の入力をマーシャリングすることと,後者の操作の結果をWeb認証APIの呼び出し元に返却することの両方を担当する.

5. API Web認証API

本章では,公開鍵クレデンシャルを生成および使用するためのAPIを規定している.基本的な考え方は,クレデンシャルはユーザに属し,クライアント(ブラウザと基礎となるOSプラットフォームで構成されている)を介してRPが対話する認証器によって管理されることである.スクリプトは,RPによる将来の使用のために新しいクレデンシャルを生成するようブラウザに要求することができる(ユーザの同意を得て).スクリプトは,既存のクレデンシャルを使用して認証操作を実行するためのユーザ同意を要求することもできる.このような操作はすべて認証器で実行され,ユーザの代わりにブラウザおよび/またはプラットフォームによって仲介される.どの時点でも,スクリプトはクレデンシャル自体にアクセスできない.オブジェクトの形式でクレデンシャルに関する情報を取得するだけである.

上記のスクリプトインタフェースに加えて,認証器は管理のためのユーザインタフェースを実装する(または実装するクライアントソフトウェアを提供する)(MAY).このようなインタフェースは,例えば,認証器をクリーンな状態にリセットしたり,認証器の現在の状態を検査したりするために使用することができる(MAY).言い換えれば,そのようなインタフェースは,履歴や保存されたパスワード,クッキーなどのユーザ状態を管理するためにブラウザによって提供されるユーザインタフェースに似ている.クレデンシャルの削除などの認証器管理アクションは,そのようなユーザインタフェースの責任とみなされ,スクリプトに公開されたAPIから意図的に削除される.

このAPIのセキュリティプロパティは,クライアントと認証器が連携して提供する.クレデンシャルを保持して管理する認証器は,すべてのオペレーションが特定の生成元にスコープされており,生成元をその応答に組み込むことによって,異なる生成元に対して再生することはできない.特に,6.2. 認証器オペレーション で定義されているように,リクエストの完全な生成元は,新しいクレデンシャルが生成されたときに生成されたアテステーションオブジェクトだけでなくWebAuthnクレデンシャルによって生成されたすべてのアサーションに含まれ,署名されている.

さらに,ユーザのプライバシを維持し,悪意のあるRPが他のRPに属する公開鍵クレデンシャルの存在を探知するのを防ぐため,各クレデンシャルはRP識別子(RP ID)にも関連付けられる.このRP IDは,すべての操作のためにクライアントによって認証器に提供され,認証器はRPによって作成されたクレデンシャルが同じRP IDによって要求された操作でのみ使用されることを保証する.このような方法でRP IDから発信元を分離することにより,単一のRPが複数の発信元を維持する場合にもAPIを使用することが可能となる.

クライアントは,各操作におけるRPの発信元とRP IDを認証器に提供することによって,これらのセキュリティ対策を容易にする.これはWebAuthnセキュリティモデルの不可欠な部分であるため,ユーザエージェントはセキュリティ保護されたコンテキストで呼出された場合にのみこのAPIを公開する.

Web認証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;
AuthenticationExtensionsClientOutputs getClientExtensionResults();
};
  • id

    • この属性はCredentialから継承されるが,PublicKeyCredentialCredentialのgetterをオーバーライドし,オブジェクトの[[identifier]]内部スロットに含まれるデータのbase64urlエンコーディングを返す.

  • rawId

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

  • AuthenticatorResponseタイプのresponse,読み取り専用

    • この属性には,公開鍵クレデンシャルを生成するか,認証アサーションを生成するためのクライアントからのリクエストに対する認証器のレスポンスが含まれる.PublicKeyCredentialcreate()に応答して生成された場合,この属性の値はAuthenticatorAttestationResponseになる.そうでない場合,PublicKeyCredentialget()に対する応答として生成され,この属性の値はAuthenticatorAssertionResponseになる.

  • getClientExtensionResults()

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

  • [[type]]

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

      注:これは,Credentialから継承されたtype属性のgetterを介して反映される.

  • zz

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. Create a new credential - PublicKeyCredential’s [[Create]](origin, options, sameOriginWithAncestors) method

5.1.4Use an existing credential to make an assertion - PublicKeyCredential’s [[Get]](options) method

5.1.4.1PublicKeyCredential’s [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) method

5.1.5Store an existing credential - PublicKeyCredential’s [[Store]](credential, sameOriginWithAncestors) method

5.1.6Preventing silent access to an existing credential - PublicKeyCredential’s [[preventSilentAccess]](credential, sameOriginWithAncestors) method

5.1.7Availability of User-Verifying Platform Authenticator - PublicKeyCredential’s isUserVerifyingPlatformAuthenticatorAvailable() method

5.2Authenticator Responses (interface AuthenticatorResponse)

5.2.1Information about Public Key Credential (interface AuthenticatorAttestationResponse)

5.2.2Web Authentication Assertion (interface AuthenticatorAssertionResponse)

5.3Parameters for Credential Generation (dictionary PublicKeyCredentialParameters)

5.4Options for Credential Creation (dictionary PublicKeyCredentialCreationOptions)

5.4.1Public Key Entity Description (dictionary PublicKeyCredentialEntity)

5.4.2RP Parameters for Credential Generation (dictionary PublicKeyCredentialRpEntity)

5.4.3User Account Parameters for Credential Generation (dictionary PublicKeyCredentialUserEntity)

5.4.4Authenticator Selection Criteria (dictionary AuthenticatorSelectionCriteria)

5.4.5Authenticator Attachment enumeration (enum AuthenticatorAttachment)

5.4.6Attestation Conveyance Preference enumeration (enum AttestationConveyancePreference)

5.5Options for Assertion Generation (dictionary PublicKeyCredentialRequestOptions)

5.6Abort operations with AbortSignal

5.7Authentication Extensions Client Inputs (typedef AuthenticationExtensionsClientInputs)

5.8Authentication Extensions Client Outputs (typedef AuthenticationExtensionsClientOutputs)

5.9Authentication Extensions Authenticator Inputs (typedef AuthenticationExtensionsAuthenticatorInputs)

5.10Supporting Data Structures

5.10.1Client data used in WebAuthn signatures (dictionary CollectedClientData)

5.10.2Credential Type enumeration (enum PublicKeyCredentialType)

5.10.3Credential Descriptor (dictionary PublicKeyCredentialDescriptor)

5.10.4Authenticator Transport enumeration (enum AuthenticatorTransport)

5.10.5Cryptographic Algorithm Identifier (typedef COSEAlgorithmIdentifier)

5.10.6User Verification Requirement enumeration (enum UserVerificationRequirement)

6WebAuthn Authenticator Model

6.1Authenticator data

6.1.1Signature Counter Considerations

6.2Authenticator operations

6.2.1Lookup Credential Source by Credential ID algorithm

6.2.2The authenticatorMakeCredential operation

6.2.3 The authenticatorGetAssertion operation

6.2.4The authenticatorCancel operation

6.3Attestation

6.3.1Attested credential data

6.3.1.1Examples of credentialPublicKey Values encoded in COSE_Key format

6.3.2Attestation Statement Formats

6.3.3Attestation Types

6.3.4Generating an Attestation Object

6.3.5Signature Formats for Packed Attestation, FIDO U2F Attestation, and Assertion Signatures

7Relying Party Operations

7.1Registering a new credential

7.2Verifying an authentication assertion

8Defined Attestation Statement Formats

8.1Attestation Statement Format Identifiers

8.2Packed Attestation Statement Format

8.2.1Packed attestation statement certificate requirements

8.3TPM Attestation Statement Format

8.3.1TPM attestation statement certificate requirements

8.4Android Key Attestation Statement Format

8.5Android SafetyNet Attestation Statement Format

8.6FIDO U2F Attestation Statement Format

8.7None Attestation Statement Format

9WebAuthn Extensions

9.1Extension Identifiers

9.2Defining extensions

9.3Extending request parameters

9.4Client extension processing

9.5Authenticator extension processing

10Defined Extensions

10.1FIDO AppID Extension (appid)

10.2Simple Transaction Authorization Extension (txAuthSimple)

10.3Generic Transaction Authorization Extension (txAuthGeneric)

10.4Authenticator Selection Extension (authnSel)

10.5Supported Extensions Extension (exts)

10.6User Verification Index Extension (uvi)

10.7Location Extension (loc)

10.8User Verification Method Extension (uvm)

10.9Biometric Authenticator Performance Bounds Extension (biometricPerfBounds)

11IANA Considerations

11.1WebAuthn Attestation Statement Format Identifier Registrations

11.2WebAuthn Extension Identifier Registrations

11.3COSE Algorithm Registrations

12Sample scenarios

12.1Registration

12.2Registration Specifically with User Verifying Platform Authenticator

12.3Authentication

12.4Aborting Authentication Operations

12.5Decommissioning

13Security Considerations

13.1Cryptographic Challenges

13.2Attestation Security Considerations

13.2.1Attestation Certificate Hierarchy

13.2.2Attestation Certificate and Attestation Certificate CA Compromise

13.3credentialId Unsigned

13.4Browser Permissions Framework and Extensions

14Privacy Considerations

14.1Attestation Privacy

14.2Registration Ceremony Privacy

14.3Authentication Ceremony Privacy

15Acknowledgements

Contents