認証情報管理レベル1

1. はじめに

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

ウェブサイトへのサインインは、本来よりも難しくなっています。ユーザーエージェントは体験を様々な面で改善できる特別な立場にあり、ほとんどの最新のユーザーエージェントはブラウザにネイティブな形で何らかのcredential managementを提供することでこれを認識しています。たとえば、ユーザーはウェブサイトのユーザー名やパスワードを保存でき、それらの 資格情報 は後にサインインフォームへ自動入力されますが、成功度合いは様々です。

属性 autocomplete は宣言的な仕組みを提供し、ウェブサイトが特定のフィールドを "username" や "password" としてマークすることで、ユーザーエージェントがサインインフォームを検出して入力する能力を向上させるために連携できます。ユーザーエージェントは、マークアップでこの詳細を提供していないサイトに対して動作するために、さまざまな検出ヒューリスティックを実装しています。

このヒューリスティックと宣言的検出の組み合わせは比較的よく機能しますが、検出が問題になる大きなギャップが残っています。一般的でないサインイン方式（例えば、資格情報をXMLHttpRequest経由で送信するケース）のサイトは確実に検出するのが難しく、ユーザーがフェデレーションIDプロバイダを使って認証したいというケースが増えていることも同様です。ウェブサイトがユーザーエージェントの 資格情報マネージャ とより直接的にやり取りできるようにすれば、一方で資格情報マネージャの精度を高め、他方でフェデレーテッドサインインを利用するユーザーを支援できるようになります。

これらのユースケースは § 1.1 Use Cases および Credential Management: Use Cases and Requirements により詳しく説明されています；この仕様書は、ウェブサイトがユーザーの 資格情報 を要求し、ユーザーが正常にサインインした際にユーザーエージェントへ資格情報の永続化を依頼できる Credential Manager API を定義することで、その文書が列挙する多くの要件に対応しようと試みています。

Note: ここで定義する API は意図的に小さく単純です：それ自体で認証を提供することを目的とせず、既存のユーザーエージェントによって実装されている 資格情報マネージャ へのインターフェイスを提供することに限定しています。この機能は、ベンダーや著者の双方に大きな労力を要求することなく、今すぐに価値があります。もちろんさらに多くのことが可能ですが、ここではいくつかの考えを § 9 Future Work に残しており、将来の API の反復で検討される可能性があります。

1.1. ユースケース

現代のユーザーエージェントは、ウェブサイトへのサインイン時にパスワードを保存できる機能や、ユーザーが再訪した際にサインインフォームへ自動または半自動でパスワードを入力する機能を備えています。ウェブサイト側から見ると、この動作は完全に不可視です：パスワードが保存されたことも、フォームに入力されたこともサイトは知りません。これは良い面も悪い面もあります。一方では、ユーザーエージェントのパスワードマネージャーはサイトの協力がなくても機能し、ユーザーにとって有益です。もう一方では、パスワードマネージャーの動作は、サインインフォームやパスワード変更フォームの検出などを目的とした脆弱で独自のヒューリスティックの寄せ集めになっています。

現状の課題として、特に以下の点が挙げられます：

• ユーザーエージェントはフェデレーテッドIDプロバイダーによるユーザー支援が非常に困難です。ユーザー名／パスワードフォームの検出は比較的容易ですが、サードパーティによるサインインの検出は確実に行うのが難しいです。ウェブサイトが典型的なフェデレーテッドサインインのリダイレクトの意図をユーザーエージェントに伝えられれば理想的です。

• 同様に、ユーザーエージェントは単純なユーザー名／パスワードフォーム以外の特殊なサインイン手法の検出に苦労しています。著者はXMLHttpRequest などを使って非同期的にサインイン処理を行うことが増えています。これはユーザーにとって良い体験ですが、ユーザーエージェントのパスワードマネージャーへの統合は困難です。ウェブサイトが独自のサインイン方式についてユーザーエージェントに伝えられれば理想的です。

• 最後に、パスワード変更は、ウェブサイトが明示的に認証情報の変更をユーザーエージェントに通知すれば、より良いサポートが可能です。

2. コアAPI

開発者視点では、認証情報とは、特定の操作に対して認証判断を行うためのオブジェクトです。本セクションでは、Credential インターフェースをベースクラスとして定義します。これは本仕様や他の仕様書で定義される認証情報の基盤となり、navigator.credentials.* にぶら下がるAPI群から取得できます。

各種認証情報タイプは、それぞれJavaScript上で、継承によって、直接的または間接的にCredential インターフェースを基盤としています。本仕様書では、PasswordCredential とFederatedCredential の2つを定義しています。その他、例えば[WEBAUTHN]では他の認証情報タイプが定義されています。

認証情報が特定のオリジンに有効であるとは、そのオリジンで認証として受理されることを指します。認証情報がある時点で有効であっても、UAは同じ認証情報が将来的にも有効だと仮定できない理由がいくつかあります：

1. パスワード認証情報は、アカウント保有者がパスワードを変更した場合、有効でなくなる可能性があります。

2. SMSで受け取ったトークンで作成された認証情報は、1回限りの利用のみ有効な場合が多いです。

使い捨て認証情報は、認証情報ソースによって生成されます。これは秘密鍵、フェデレーテッドアカウントへのアクセス、特定の電話番号でSMS受信できる能力などであり、JavaScriptで直接扱うことはできず、本仕様でも明示的に表現されません。モデルを統一するため、パスワード自体も認証情報ソースと見なし、これをコピーしてパスワード認証情報を作成します。

UAは、有効な認証情報が再度有効であるとは限らない、あるいは有効な認証情報を生成した認証情報ソースが将来も有効な認証情報を生成できるとは限らないものの、後者の方が可能性として高いです。過去に有効だった認証情報をstore() で記録すれば、UAは今後ユーザーに提示する際、より有効な認証情報ソースを提供できる可能性が高まります。

2.1. インフラストラクチャ

A credential manager は、保存、整理、管理し、資格情報の選択を可能にする アプリケーション、ハードウェア機器、またはサービスです。資格情報マネージャの例としては、 デジタルウォレット、パスワードマネージャ、およびpasskeyマネージャが含まれます。

ユーザーエージェントは内部的にcredential storeを提供しなければなりません（MUST）。これは、どのcredentialsがeffectiveであったかを記録する、 ベンダー固有の不透明な格納機構です。これは、credentialへのアクセスと永続化に対して次の機能を提供します：

1. Store a credential — 後で取得できるようにcredentialを保存します。これは credential storeに挿入します。

2. Retrieve a list of credentials — 任意のフィルタを受け取り、フィルタに一致するcredentialsの集合を返します。

3. Modify a credential — credentialを受け取り、既存のcredentialの状態を上書きして credential store内の状態を更新します。

さらに、credential storeは、オリジンごとにprevent silent access flagを維持するべきです（特に指定がない限りtrueに設定されます）。 そのフラグがtrueに設定されている場合、そのオリジンはrequires user mediationとなります。

Note: ユーザー媒介の重要性については、§ 5 User Mediationでより詳しく議論されています。

Note: credential storeは、 ユーザーエージェントが本書で指定したAPIを実装する際の内部実装の詳細であり、ウェブに対して直接公開されるものではありません。 特定のcredentialタイプをサポートするために、 他の文書でより多くの機能が指定される場合があります。

本書は、そのアルゴリズムと本文で使用される多くの基礎概念について Infra Standard に依存しています [INFRA]。

各environment settings objectには、関連付けられたアクティブな資格情報タイプがあり、これは初期状態では空の集合です。

2.1.1. インフラストラクチャアルゴリズム

2.1.1.1. 祖先も同一オリジンであること

環境設定オブジェクト（settings）が祖先も同一オリジンであるかどうかは、以下のアルゴリズムがtrueを返す場合です：

1. settingsの関連グローバルオブジェクトに関連付けられたDocumentがなければ、 falseを返す。

2. documentをsettingsの関連グローバルオブジェクトの関連付けられたDocumentとする。

3. documentにブラウジングコンテキストがなければ、falseを返す。

4. originをsettingsのオリジンとする。

5. navigableをdocumentのノードナビゲーブルとする。

6. navigableが非nullの親を持つ間：

   1. navigableをnavigableの親にする。

   2. navigableのアクティブドキュメントのオリジンがoriginと同一オリジンでなければ、 falseを返す。

7. trueを返す。

2.1.2. 認証情報タイプレジストリ

このレジストリは認証情報タイプ（例：[[type]]値）を、指定された認証情報タイプに関連する様々な値へマッピングします。例えば、オプションメンバー識別子（正式には辞書メンバーの識別子）は、CredentialCreationOptionsやCredentialRequestOptions（すなわち「オプション辞書」）で仕様ごとに使われます。

注: このレジストリは関連する認証情報インターフェースオブジェクトアルゴリズムで利用されます。

2.1.2.1. 登録エントリ要件および更新プロセス

• 各認証情報タイプは、認証情報タイプ集合内で一意でなければなりません。

• 各レジストリエントリは、認証情報仕様のCredentialCreationOptions およびCredentialRequestOptionsで拡張される辞書メンバーの識別子（レジストリではオプションメンバー識別子と呼ばれる）を明記しなければなりません。

• 各レジストリエントリは、適切なインターフェースオブジェクトの識別子を明記しなければなりません。

• 各レジストリエントリは、取得パーミッションポリシーのパーミッション（認証情報の要求実行時に使用）か、パーミッションポリシーが指定されていなければnullを明記しなければなりません。

• 各レジストリエントリは、作成パーミッションポリシーのパーミッション（認証情報の作成実行時に使用）か、パーミッションポリシーが指定されていなければnullを明記しなければなりません。

• 各レジストリエントリは、認証情報タイプと辞書メンバーの識別子を定義する公開仕様へのリンクを必ず含めなければなりません。

• 各レジストリエントリの仕様には申請者の連絡先情報を含めなければなりません。

このレジストリの更新は、認証情報タイプのレジストリエントリの追加・変更・削除です。誰でもwebappsec-credential-managementリポジトリへのプルリクエストで更新を申請できます。 Webアプリケーションセキュリティ作業部会が次回会議の議題に載せ申請者に通知します。 審議と決定はW3C Webアプリケーションセキュリティ作業部会の合意によります。 議長が申請者に結果を通知し、レジストリを更新します。

2.2. Credentialインターフェース

[Exposed=Window, SecureContext]
interface Credential {
  readonly attribute USVString id;
  readonly attribute DOMString type;
  static Promise<boolean> isConditionalMediationAvailable();
  static Promise<undefined> willRequestConditionalCreation();
};

TobieやDominicとインターフェースオブジェクトについて相談してください。ここや§ 2.5.1 認証情報の要求など、用語が正しいか不明です。インターフェースプロトタイプオブジェクトかもしれません？

一部のCredential オブジェクトはオリジンに束縛される型です。これらは[[origin]]という内部スロットを持ち、オリジンを格納します。これは当該Credentialが有効となり得るオリジンです。

2.2.1. Credentialの内部メソッド

Credential のインターフェースオブジェクトは、認証情報オブジェクトの取得・保存を補助するいくつかの内部メソッドを備えています。これらのデフォルトは本節で示す「no-op」です。

特に指定がない限り、Credentialを継承するインターフェースごとに作成されるインターフェースオブジェクトは、少なくとも1つの内部メソッドの実装を提供し、該当する認証情報タイプに合わせてCredentialのデフォルト実装をオーバーライドしなければなりません。例：§ 3.2 PasswordCredentialインターフェース、§ 4.1 FederatedCredentialインターフェース、[WEBAUTHN]。

2.2.1.1. [[CollectFromCredentialStore]]内部メソッド

Credentialの [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors)のデフォルト実装：

1. 空集合を返す。

2.2.1.2. [[DiscoverFromExternalSource]]内部メソッド

Credentialの [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)のデフォルト実装：

1. nullを返す。

2.2.1.3. [[Store]]内部メソッド

Credentialの [[Store]](credential, sameOriginWithAncestors)のデフォルト実装：

1. NotSupportedErrorを投げる。

2.2.1.4. [[Create]]内部メソッド

• Credentialを作成する、または

• 認証情報を作成せずnullを返す、または

• 例外的状況でエラーを投げる（例：オプションが不正ならTypeError）。

認証情報を作成する場合は、グローバルオブジェクトを受け取り、Credentialを継承するインターフェースオブジェクトを返すアルゴリズムを返します。このアルゴリズムはタスクから呼び出されなければなりません。

注: このアルゴリズムの手順は各認証情報タイプごとに定義されます。

Credentialの [[Create]](origin, options, sameOriginWithAncestors)のデフォルト実装：

1. nullを返す。

2.2.2. CredentialUserDataミックスイン

一部のCredentialオブジェクトは、認証情報選択画面でユーザーに分かりやすい名称やアイコンを表示するためのデータを持ちます：

[SecureContext]
interface mixin CredentialUserData {
  readonly attribute USVString name;
  readonly attribute USVString iconURL;
};

2.3. navigator.credentials

開発者はCredentialを取得し、ユーザーエージェントの認証情報ストアとやり取りするために、CredentialsContainerインターフェースのメソッドを利用します。これはNavigatorオブジェクトのnavigator.credentialsとして提供されます。

partial interface Navigator {
  [SecureContext, SameObject] readonly attribute CredentialsContainer credentials;
};

credentials属性は、アクティブドキュメントのブラウジングコンテキストに関連付けられたCredentialsContainerを必ず返さなければなりません。

注: § 6.3 安全でないサイトで述べている通り、認証情報管理APIはセキュアコンテキストでのみ公開されます。

[Exposed=Window, SecureContext]
interface CredentialsContainer {
  Promise<Credential?> get(optional CredentialRequestOptions options = {});
  Promise<undefined> store(Credential credential);
  Promise<Credential?> create(optional CredentialCreationOptions options = {});
  Promise<undefined> preventSilentAccess();
};

dictionary CredentialData {
  required USVString id;
};

2.3.1. CredentialRequestOptions辞書

get()でCredentialを取得するには、 呼び出し側がCredentialRequestOptionsオブジェクトでいくつかのパラメーターを指定します。

注: CredentialRequestOptions辞書は拡張ポイントです。新しい認証情報タイプで追加オプションが必要になった場合、その辞書型を拡張してリクエストに渡すことができます。§ 8.2 拡張ポイント参照。

dictionary CredentialRequestOptions {
  CredentialMediationRequirement mediation = "optional";
  AbortSignal signal;
};

2.3.2. メディエーション要件

get(options) やcreate(options) のリクエスト時、開発者はCredentialMediationRequirement列挙型の値を選択することで、個別にユーザー操作の要件を設定できます。

注: § 5 ユーザーメディエーションで、この概念の詳細や、ユーザーエージェントが特定のオリジンに対する個々のリクエストをどのように扱うかについて説明しています。

enum CredentialMediationRequirement {
  "silent",
  "optional",
  "conditional",
  "required"
};

2.3.2.1. 例

window.addEventListener('load', async () => {
  const credentials = await navigator.credentials.get({
    ...,
    mediation: 'silent'
  });
  if (credentials) {
    // 認証情報でユーザーをサインイン！
  }
});

document.querySelector('#sign-in').addEventListener('click', async () => {
  const credentials = await navigator.credentials.get({
    ...,
    mediation: 'optional'
  });
  if (credentials) {
    // 認証情報でユーザーをサインイン！
  }
});

document.querySelector('#important-form').addEventListener('submit', async () => {
  const credentials = await navigator.credentials.get({
    ...,
    mediation: 'required'
  });
  if (credentials) {
    // |credentials|でアクセス可能か確認し、不正なら送信をキャンセル
  } else {
    e.preventDefault();
  }
});

document.querySelector('#switch-button').addEventListener('click', e => {
  var c = await navigator.credentials.get({
    ...,
    mediation: 'required'
  });
  if (c) {
    // |c|でユーザーをサインイン
  }
});

2.4. CredentialCreationOptions辞書

create()でCredentialを作成するには、 呼び出し側がCredentialCreationOptionsオブジェクトでいくつかのパラメーターを指定します。

注: CredentialCreationOptions辞書は拡張ポイントです。新しい認証情報タイプが導入される際には、この辞書に追加され、作成メソッドに渡せます。§ 8.2 拡張ポイント、本仕様で導入されている拡張（§ 3.2 PasswordCredentialインターフェース、§ 4.1 FederatedCredentialインターフェース）も参照してください。

dictionary CredentialCreationOptions {
  CredentialMediationRequirement mediation = "optional";
  AbortSignal signal;
};

2.5. アルゴリズム

2.5.1. Credentialの要求

Credentialの要求アルゴリズムはCredentialRequestOptions（options）を受け取り、一意に取得できる場合はCredentialでresolve、そうでなければnullでresolveするPromiseを返します。

1. settingsを現在の設定オブジェクトとする。

2. Assert: settingsはセキュアコンテキストである。

3. documentをsettingsの関連グローバルオブジェクトの関連付けられたDocumentとする。

4. documentが完全にアクティブでなければ、"InvalidStateError" DOMExceptionでpromiseをrejectして返す。

5. options.signal が中断済みなら、 options.signalの中断理由でpromiseをrejectして返す。

6. interfacesをoptionsの関連する認証情報インターフェースオブジェクトとする。

7. interfacesが空なら、 "NotSupportedError" DOMExceptionでpromiseをrejectして返す。

8. interfacesの各interfaceについて:

   1. options.mediation がconditionalで、 interfaceがconditionalなユーザー操作をサポートしないなら、"TypeError" DOMExceptionでpromiseをrejectして返す。

   2. settingsのアクティブ認証情報タイプがinterfaceの[[type]]を含んでいれば、 "NotAllowedError" DOMExceptionでpromiseをrejectして返す。

   3. settingsのアクティブ認証情報タイプにinterfaceの[[type]]を追加する。

9. originをsettingsのoriginとする。

10. sameOriginWithAncestorsを、settingsが祖先も同一オリジンならtrue、それ以外はfalseとする。

11. optionsの関連する認証情報インターフェースオブジェクトの各interfaceについて:

    1. permissionをinterfaceの[[type]]の取得パーミッションポリシーとする。

    2. permissionがnullなら、次へ。

    3. documentがpermissionの利用許可がないなら、"NotAllowedError" DOMExceptionでpromiseをrejectして返す。

12. pを新しいpromiseとする。

13. 以下の手順を並行して実行:

    1. credentialsを認証情報ストアからCredentialを収集（origin、options、sameOriginWithAncestors）の結果とする。

    2. credentialsが例外なら、pをrejectして返す。

    3. 以下すべてがtrueなら、pをcredentials[0]でresolveし、残り手順をスキップ:

       1. credentialsのサイズが1

       2. originがユーザー操作不要

       3. optionsが事前に一致可能

       4. options.mediation が "required"でない

       5. options.mediation が "conditional"でない

       このモデルは誤っているかもしれません。WebAuthn型認証情報でも、ユーザー名／パスワードを使うユーザーには選択画面を表示しないままサインインできるようにしたい。

    4. options.mediation が "silent"なら、pをnullでresolveし、残り手順をスキップ。

    5. resultをユーザーにCredential選択を依頼（options、credentials）の結果とする。

    6. resultがインターフェースオブジェクトなら:

       1. resultを、resultの[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)（origin、options、sameOriginWithAncestors）の結果にする。

          例外が発生した場合:

          1. 発生した例外をeとする。

          2. globalのDOM操作タスクソースでタスクをキューし、以下を実行：

             1. pをeでrejectする。

          3. 以降の手順を終了。

    7. Assert: resultはnullまたはCredential。

    8. resultがCredentialなら、pをresultでresolveする。

    9. resultがnullかつoptions.mediation がconditionalでない場合、pをresultでresolveする。

       注: options.mediation がconditionalであり、nullな認証情報が発見された場合、promise pはresolveされません。

14. pがsettleしたら反応:

    1. interfacesの各interfaceについて：

       1. interfaceの[[type]]をsettingsのアクティブ認証情報タイプから削除する。

15. pを返す。

2.5.2. 認証情報ストアからCredentialを収集

origin（origin）、 CredentialRequestOptions （options）、および呼び出しコンテキストが祖先も同一オリジン（sameOriginWithAncestors）の場合のみtrueとなるboolean値が与えられたとき、ユーザーエージェントは認証情報ストアからCredentialを収集できる。 これは、ユーザーエージェントがローカルに保存しているoptionsのフィルターに一致するCredentialオブジェクトの集合を返す。該当するCredentialオブジェクトがなければ、空集合を返す：

1. possible matchesを空集合とする。

2. optionsの関連する認証情報インターフェースオブジェクトの各interfaceについて：

   1. rをinterfaceの[[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) 内部メソッド（引数はorigin、options、sameOriginWithAncestors）の実行結果とする。例外が発生した場合は、その例外を再スローする。

   2. Assert: rはインターフェースオブジェクトのリストである。

   3. rの各cについて：

      1. possible matchesにcを追加する。

3. possible matchesを返す。

2.5.3. Credentialの保存

Credentialの保存アルゴリズムは Credential （credential）を受け取り、オブジェクトが認証情報ストアに永続化されるとresolveする Promise を返す。

1. settingsを現在の設定オブジェクトとする。

2. Assert: settingsはセキュアコンテキストである。

3. settingsの関連グローバルオブジェクトの関連付けられたDocumentが完全にアクティブでなければ、 "InvalidStateError" DOMExceptionでpromiseをrejectして返す。

4. 現在の設定オブジェクトが祖先も同一オリジンならtrue、それ以外はfalseとしたsameOriginWithAncestorsを定める。

5. pを新しいpromiseとする。

6. settingsのアクティブ認証情報タイプがcredentialの[[type]]を含んでいれば、 "NotAllowedError" DOMExceptionでpromiseをrejectして返す。

7. settingsのアクティブ認証情報タイプにcredentialの[[type]]を追加する。

8. 以下の手順を並行して実行：

   1. credentialのインターフェースオブジェクトの[[Store]](credential, sameOriginWithAncestors) 内部メソッド（引数はcredential、sameOriginWithAncestors）を実行する。

      例外が発生した場合：

      1. 発生した例外をeとする。

      2. globalのDOM操作タスクソースでタスクをキューし、以下を実行：

         1. pをeでrejectする。

      例外が発生しない場合は、pをundefinedでresolveする。

9. pがsettleしたら反応：

   1. credentialの[[type]]をsettingsのアクティブ認証情報タイプから削除する。

10. pを返す。

2.5.4. Credentialの作成

Credentialの作成アルゴリズムは CredentialCreationOptions (options)を受け取り、指定されたオプションで作成できる場合はCredentialでresolveし、作成できない場合はnullでresolveする Promise を返します。例外的な状況では、Promiseは適切な例外でrejectされる場合があります。

1. settingsを現在の設定オブジェクトとする。

2. Assert: settingsはセキュアコンテキストである。

3. globalをsettingsのグローバルオブジェクトとする。

4. documentを関連グローバルオブジェクトの関連付けられたDocumentとする。

5. documentが完全にアクティブでなければ、"InvalidStateError" DOMExceptionでpromiseをrejectして返す。

6. 現在の設定オブジェクトが祖先も同一オリジンならtrue、それ以外はfalseとしたsameOriginWithAncestorsを定める。

7. interfacesをoptionsの関連する認証情報インターフェースオブジェクトの集合とする。

8. 次のいずれかがtrueならNotSupportedErrorでpromiseをrejectして返す：

   1. globalに関連付けられたDocumentがない。

   2. interfacesのサイズが1より大きい。

      注: 今後この制限を緩和し、ユーザーエージェントが複数の認証情報タイプから選択できる「サインアップ」ユースケースをサポートする可能性はありますが、現時点では辞書は1エントリに制限されています。

9. interfacesの各interfaceについて：

   1. permissionをinterfaceの[[type]]の作成パーミッションポリシーとする。

   2. permissionがnullなら次へ。

   3. documentがpermissionの利用許可がない場合、"NotAllowedError" DOMExceptionでpromiseをrejectして返す。

10. options.signal が中断済みなら、 options.signalの中断理由でpromiseをrejectして返す。

11. typeをinterfaces[0]の[[type]]とする。

12. settingsのアクティブ認証情報タイプがtypeを含んでいれば、 "NotAllowedError" DOMExceptionでpromiseをrejectして返す。

13. settingsのアクティブ認証情報タイプにtypeを追加する。

14. originをsettingsのoriginとする。

15. pを新しいpromiseとする。

16. 以下の手順を並行して実行：

    1. rをinterfaces[0]の[[Create]](origin, options, sameOriginWithAncestors)内部メソッド（引数はorigin、options、sameOriginWithAncestors）の実行結果とする。

       例外が発生した場合：

       1. 発生した例外をeとする。

       2. globalのDOM操作タスクソースでタスクをキューし、以下を実行：

          1. pをeでrejectする。

       3. 以降の手順を終了。

    2. rがCredentialまたはnullなら、pをrでresolveし、以降の手順を終了。

    3. Assert: rは（§ 2.2.1.4 [[Create]]内部メソッドで定義される）アルゴリズムである。

    4. globalのDOM操作タスクソースでタスクをキューし、以下を実行：

       1. pをglobalでpromise-callingしたrの結果でresolveする。

17. pがsettleしたら反応：

    1. settingsのアクティブ認証情報タイプからtypeを削除する。

18. pを返す。

2.5.5. サイレントアクセスの防止

サイレントアクセスの防止アルゴリズムは環境設定オブジェクト（settings）を受け取り、認証情報ストアにサイレントアクセス防止フラグが永続化されるとresolveするPromiseを返します。

1. originをsettingsのoriginとする。

2. settingsの関連グローバルオブジェクトの関連付けられたDocumentが完全にアクティブでなければ、 "InvalidStateError" DOMExceptionでpromiseをrejectして返す。

3. pを新しいpromiseとする。

4. 以下の手順を並行して実行：

   1. originのサイレントアクセス防止フラグを認証情報ストアに設定する。

   2. pをundefinedでresolveする。

5. pを返す。

3. パスワード認証情報

良いか悪いかは別として、多くのウェブサイトは認証手段としてユーザー名／パスワードの組み合わせに依存しています。 PasswordCredential インターフェースは、このユースケースを実現するための認証情報であり、ユーザー名とパスワード両方を保存し、 認証情報選択画面でユーザーが正しいアカウントを選びやすくするメタデータも保持します。

3.1. 例

3.1.1. パスワードによるサインイン

navigator.credentials
  .get({ 'password': true })
  .then(credential => {
    if (!credential) {
      // ユーザーがこのサイト用の認証情報を持っていない、または
      // 共有を拒否した場合。ここで通常のログインフォームへのフォールバック処理を実装。
      return;
    }
    if (credential.type == 'password') {
      var form = new FormData();
      form.append('username_field', credential.id);
      form.append('password_field', credential.password);
      var opt = {
        method: 'POST',
        body: form,
        credentials: 'include'  // クッキー送信
      };
      fetch('https://example.com/loginEndpoint', opt)
        .then(function (response) {
          if (/* |response| がログイン成功を示す場合 */) {
            // 認証情報が有効だったことを記録（下記注参照）
            navigator.credentials.store(credential);
            // サインイン成功を通知して、サインイン後の処理を実行！
            // location.href = '/signed-in-experience' なども可能
          } else {
            // 通常のログインフォームへのフォールバック処理
          }
        });
    }
  });

navigator.credentials
  .get({ 'password': true })
  .then(credential => {
    if (!credential) {
      return; // 上記と同様...
    }
    if (credential.type === 'password') {
      document.querySelector('input[name=username_field]').value =
        credential.id;
      document.querySelector('input[name=password_field]').value =
        credential.password;
      document.getElementById('myform').submit();
    }
  });

注: ユーザーエージェントが提示する認証情報選択画面では、現在のオリジンに保存されていない認証情報も選択できる場合があります。例えば、https://m.example.comの認証情報が https://www.example.comで利用可能として表示されることがあります（§ 6.1 クロスドメイン認証情報アクセス参照）。 または、ユーザーが新しい認証情報を即時作成できる場合もあります。開発者は、store()を認証情報が利用されるたび（get()直後でも）呼ぶことで、未保存なら保存の機会が提示され、すでに保存済みならユーザーへのプロンプトも表示されません。

3.1.2. サインイン後の確認

サインイン成功後に新しい認証情報の保存をユーザーに提案するには、その認証情報をstore() に渡します。

<form action="https://example.com/login" method="POST" id="theForm">
  <label for="username">ユーザー名</label>
  <input type="text" id="username" name="username" autocomplete="username">
  <label for="password">パスワード</label>
  <input type="password" id="password" name="password" autocomplete="current-password">
  <input type="submit">
</form>

document.querySelector('#theForm').addEventListener('submit', e => {
    if (window.PasswordCredential) {
      e.preventDefault();

      // "submit"イベント発火元のPasswordCredentialを
      // HTMLFormElementから生成
      // "username"や"current-password"のautocomplete属性値を吸い上げる
      var c = new PasswordCredential(e.target);

      // フォームのaction URLに新しい認証情報オブジェクト(FormData)を送信。成功ならユーザーエージェントに通知してパスワード保存を提案：
      var opt = {
        method: 'POST',
        body: new FormData(e.target),
        credentials: 'include'  // クッキー送信
      };
      fetch(e.target.action, opt).then(r => {
        if (/* |r| が"成功した" Response */)
          navigator.credentials.store(c);
      });
    }
});

3.1.3. パスワード変更

この保存機構は「パスワード変更」にもそのまま利用できます。ユーザーが認証情報を変更した場合、ウェブサイトは新しい認証情報でサインイン成功を通知できます。ユーザーエージェントは保存済み認証情報を更新します：

<form action="https://example.com/changePassword" method="POST" id="theForm">
  <input type="hidden" name="username" autocomplete="username" value="user">
  <label for="password">新しいパスワード</label>
  <input type="password" id="password" name="password" autocomplete="new-password">
  <input type="submit">
</form>

document.querySelector('#theForm').addEventListener('submit', e => {
  if (window.PasswordCredential) {
    e.preventDefault();

    // "submit"イベント発火元のPasswordCredentialを
    // HTMLFormElementから生成
    // "username"や"new-password"のautocomplete属性値を吸い上げる
    var c = new PasswordCredential(e.target);

    // フォームのaction URLに新しい認証情報オブジェクト(FormData)を送信。成功ならユーザーエージェントに通知してパスワード保存を提案：
    var opt = {
      method: 'POST',
      body: new FormData(e.target),
      credentials: 'include'  // クッキー送信
    };
    fetch(e.target.action, opt).then(r => {
      if (/* |r| が"成功した" Response */)
        navigator.credentials.store(c);
    });
  }
});

3.2. PasswordCredentialインターフェース

[Exposed=Window,
 SecureContext]
interface PasswordCredential : Credential {
  constructor(HTMLFormElement form);
  constructor(PasswordCredentialData data);
  readonly attribute USVString password;
};
PasswordCredential includes CredentialUserData;

partial dictionary CredentialRequestOptions {
  boolean password = false;
};

PasswordCredential オブジェクトはPasswordCredentialData 辞書を明示的に渡すか、HTMLFormElementの 送信可能要素の内容に基づいて navigator.credentials.create() で作成できます。

dictionary PasswordCredentialData : CredentialData {
  USVString name;
  USVString iconURL;
  required USVString origin;
  required USVString password;
};

typedef (PasswordCredentialData or HTMLFormElement) PasswordCredentialInit;

partial dictionary CredentialCreationOptions {
  PasswordCredentialInit password;
};

PasswordCredential オブジェクトはオリジンに束縛されます。

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

3.3. アルゴリズム

3.3.1. PasswordCredentialの [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors)

[[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) は、origin（origin）、CredentialRequestOptions (options)、 および呼び出しコンテキストが祖先も同一オリジン (sameOriginWithAncestors)の場合のみtrueとなるboolean値を受け取ります。 このアルゴリズムは認証情報ストアからCredentialオブジェクトの集合を返します。一致するCredentialがなければ空集合を返します。

sameOriginWithAncestorsがtrueでない場合、NotAllowedErrorを投げます。

1. Assert: options["password"] 存在する。

2. sameOriginWithAncestorsがfalseなら、"NotAllowedError" DOMExceptionを投げる。

   注: この制限は§ 6.4 オリジン混同の懸念に対応しています。

3. options["password"] がtrueでなければ空集合を返す。

4. 資格情報ストアから 次のフィルターに一致する資格情報を取得した結果を返します：

   1. 資格情報がPasswordCredentialであること

   2. 資格情報の[[origin]] がoriginと同一オリジンであること。

3.3.2. PasswordCredentialの [[Create]](origin, options, sameOriginWithAncestors)

[[Create]](origin, options, sameOriginWithAncestors) は、origin（origin）、CredentialCreationOptions (options)、および呼び出しコンテキストが祖先も同一オリジン（sameOriginWithAncestors）の場合のみtrueとなるboolean値を受け取ります。 このアルゴリズムは、作成できる場合はPasswordCredentialを、そうでなければnullを返します。CredentialCreationOptions 辞書は必ずpasswordメンバーを持ち、その値はHTMLFormElement またはPasswordCredentialData でなければなりません。 その値からPasswordCredentialを作成できない場合、このアルゴリズムはTypeError 例外を投げます。

1. Assert: options["password"] 存在する、かつsameOriginWithAncestorsは未使用。

2. options["password"] がHTMLFormElementなら、 HTMLFormElementから PasswordCredentialを作成（options["password"]、origin）の結果を返す。 例外は再スローすること。

3. options["password"] がPasswordCredentialDataなら、 PasswordCredentialDataから PasswordCredentialを作成（options["password"]）の結果を返す。 例外は再スローすること。

4. TypeError 例外を投げる。

3.3.3. PasswordCredentialの[[Store]](credential, sameOriginWithAncestors)

[[Store]](credential, sameOriginWithAncestors) は PasswordCredential (credential)と、呼び出しコンテキストが祖先も同一オリジンの場合のみtrueとなるboolean値を受け取ります。アルゴリズムはcredentialが認証情報ストアに永続化されるとundefinedを返します。

sameOriginWithAncestorsがtrueでない場合、NotAllowedErrorを返します。

1. sameOriginWithAncestorsがfalseの場合、"NotAllowedError" DOMException を投げ、ユーザーエージェントの認証情報ストアは変更しない。

   注: この制限は§ 6.4 オリジン混同の懸念に対応しています。

2. ユーザーエージェントの認証情報ストアに、PasswordCredential (stored) があり、そのid 属性がcredentialのidで、 [[origin]] スロットがcredentialの[[origin]]と同一オリジンなら：

   1. ユーザーが認証情報の更新を許可した場合（ユーザー操作定義時参照）、

      1. storedのpassword を credentialのpasswordに設定する。

      2. storedのname を credentialのnameに設定する。

      3. storedのiconURL を credentialのiconURLに設定する。

   それ以外の場合、ユーザーが認証情報保存を許可した場合（ユーザー操作定義時参照）：

   1. 以下のプロパティを持つPasswordCredentialを認証情報ストアに保存する：

      id

      credentialのid

      name

      credentialのname

      iconURL

      credentialのiconURL

      [[origin]]

      credentialの[[origin]]

      password

      credentialのpassword

3.3.4. HTMLFormElementからPasswordCredentialを作成

HTMLFormElementから PasswordCredentialを作成するには、HTMLFormElement （form）とオリジン（origin）を受け取り、以下の手順を実行します。

注: § 3.1.2 サインイン後の確認と§ 3.1.3 パスワード変更が主な利用例です。

1. dataを新しいPasswordCredentialData辞書とする。

2. dataのoriginメンバー値をorigin値に設定する。

3. formDataをFormDataコンストラクターでformから生成する。

4. elements を、送信可能な要素のうち、form owner が form であるものを 木構造順で並べたリストとする。

5. newPasswordObservedをfalseとする。

6. elementsの各fieldについて以下を実行：

   1. fieldがautocomplete属性を持たない場合は以降をスキップ。

   2. nameをfieldのname属性値とする。

   3. formDataのhas()をnameに対して実行し、結果がfalseなら以降をスキップ。

   4. fieldのautocomplete値に1つ以上のautofill詳細トークン（tokens）が含まれている場合：

      1. tokensの各tokenについて：

         1. tokenが以下のいずれか文字列（ASCII大文字小文字無視）と一致する場合は該当手順を実行：

            "new-password"

            dataのpassword メンバー値をformDataのget()でname取得結果に設定し、newPasswordObservedをtrueにする。

            "current-password"

            newPasswordObservedがfalseなら、dataのpasswordメンバー値をformDataのget()でname取得結果に設定。

            注: newPasswordObservedがfalseか判定することでnew-passwordフィールドがcurrent-passwordより優先されます。

            "photo"

            dataのiconURLメンバー値をformDataのget()でname取得結果に設定。

            "name"

            "nickname"

            dataのnameメンバー値をformDataのget()でname取得結果に設定。

            "username"

            dataのidメンバー値をformDataのget()でname取得結果に設定。

7. cをPasswordCredentialDataからPasswordCredentialを作成（data）の結果とする。例外発生時は再スロー。

8. Assert: cはPasswordCredentialである。

9. cを返す。

3.3.5. PasswordCredentialDataからPasswordCredentialを作成

PasswordCredentialDataから PasswordCredentialを作成するには、PasswordCredentialData （data）を受け取り、以下の手順を実行します。

1. cを新しいPasswordCredentialオブジェクトとする。

2. 以下いずれかが空文字列なら、TypeError 例外を投げる：

   • dataのid値

   • dataのorigin値

   • dataのpassword値

3. cの各プロパティを以下のように設定：

   password

   dataのpassword値

   id

   dataのid値

   iconURL

   dataのiconURL値

   name

   dataのname値

   [[origin]]

   dataのorigin値

4. cを返す。

3.3.6. CredentialRequestOptionsによるPasswordCredential一致判定

CredentialRequestOptions (options)が与えられたとき、以下のアルゴリズムはMatches（PasswordCredentialがget()リクエスト応答として利用可能）またはDoes Not Match（そうでない場合）を返します。

1. optionsにpasswordメンバーがあり、値がtrueならMatchesを返す。

2. Does Not Matchを返す。

4. フェデレーテッドクレデンシャル

4.1. FederatedCredential インターフェース

[Exposed=Window,
 SecureContext]
interface FederatedCredential : Credential {
  constructor(FederatedCredentialInit data);
  readonly attribute USVString provider;
  readonly attribute DOMString? protocol;
};
FederatedCredential includes CredentialUserData;

dictionary FederatedCredentialRequestOptions {
  sequence<USVString> providers;
  sequence<DOMString> protocols;
};

partial dictionary CredentialRequestOptions {
  FederatedCredentialRequestOptions federated;
};

FederatedCredential オブジェクトは FederatedCredentialInit 辞書を navigator.credentials.create() に渡すことで作成できます。

dictionary FederatedCredentialInit : CredentialData {
  USVString name;
  USVString iconURL;
  required USVString origin;
  required USVString provider;
  DOMString protocol;
};

partial dictionary CredentialCreationOptions {
  FederatedCredentialInit federated;
};

FederatedCredential オブジェクトは オリジンに紐付けられています。

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

注記: 将来的にユーザーエージェントがユーザーのために認証トークンを取得できるようになった場合、 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) の実装を追加することで実現できます。

4.1.1. プロバイダーの識別

すべてのサイトは、特定のフェデレーテッドアイデンティティプロバイダーを参照する際に同じ識別子を使用するべきです。例えば Facebook Login は "Facebook" や "Facebook Login" や "FB" や "FBL" や "Facebook.com" などと呼ばず、誰もが利用できる正規の識別子を持つべきです。識別が一貫していれば、ユーザーエージェントが役立つことが可能になります。

一貫性のため、本書で定義されたAPIに渡されるフェデレーション（例: FederatedCredentialRequestOptions の providers 配列や FederatedCredential の provider プロパティ）は、プロバイダーがサインインに使用する origin のASCIIシリアライゼーション で識別されなければなりません。 つまり、Facebookは https://www.facebook.com、Googleは https://accounts.google.com で表されます。

この origin のシリアライゼーションには、末尾の U+002F SOLIDUS ("/") は含まれませんが、ユーザーエージェントはそれを黙って受け入れるべきです: https://accounts.google.com/ は明らかに https://accounts.google.com と同じ意味です。

4.2. アルゴリズム

4.2.1. FederatedCredential の [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors)

[[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) は origin（origin）、CredentialRequestOptions （options）、および呼び出し元コンテキストが 祖先と同一オリジン である場合に限り true となるブール値（sameOriginWithAncestors）を受け取ります。 このアルゴリズムは credential store から Credential オブジェクトの集合を返します。該当する Credential オブジェクトが存在しない場合、返却される集合は空になります。

1. Assert: options["federated"] 存在する。

2. もし sameOriginWithAncestors が false なら、"NotAllowedError" DOMException を投げる。

   注記: この制限は § 6.4 オリジン混同 で提起された懸念に対応するためのものです。

3. もし options["federated"] が true でなければ、空集合を返す。

4. credential store からクレデンシャルのリストを取得する の結果を、以下のフィルターに一致するもののみ返す:

   1. クレデンシャルが FederatedCredential であること

   2. クレデンシャルの [[origin]] が origin と 同一オリジンであること。

   3. もし options["federated"]["providers"] 存在する場合、その値がクレデンシャルの provider を 含むこと。

   4. もし options["federated"]["protocols"] 存在する場合、その値がクレデンシャルの protocol を 含むこと。

4.2.2. FederatedCredential の [[Create]](origin, options, sameOriginWithAncestors)

[[Create]](origin, options, sameOriginWithAncestors) は origin（origin）、CredentialCreationOptions （options）、および呼び出し元コンテキストが 祖先と同一オリジンの場合のみ true となるブール値（sameOriginWithAncestors）を受け取ります。 このアルゴリズムは FederatedCredential が作成できればそれを返し、できなければ null を返します。また、例外的な場合は 例外 を投げます:

1. Assert: options["federated"] 存在すること、および sameOriginWithAncestors は未使用であること。

2. options["federated"] の origin メンバーの値を origin の値に設定する。

3. FederatedCredentialInit から FederatedCredential を作成する を options["federated"] に対して実行した結果を返す。 それが 例外 を投げた場合は、その例外を再スローする。

4.2.3. FederatedCredential の [[Store]](credential, sameOriginWithAncestors)

[[Store]](credential, sameOriginWithAncestors) は FederatedCredential （credential）、および呼び出し元コンテキストが 祖先と同一オリジン の場合のみ true となるブール値（sameOriginWithAncestors）を受け取ります。 このアルゴリズムは credential を credential store に保存したら undefined を返します。

もし sameOriginWithAncestors が true でなければ、NotAllowedError を返します。

1. "NotAllowedError" DOMException を投げ、ユーザーエージェントの credential store を変更しない。 sameOriginWithAncestors が false の場合。

   注記: この制限は § 6.4 オリジン混同 で提起された懸念に対応するためのものです。

2. もしユーザーエージェントの credential store に FederatedCredential が存在し、その id 属性が credential の id であり、 [[origin]] スロットが credential の [[origin]] とprovider が credential の provider である場合は、返す。

3. ユーザーがクレデンシャルの保存を許可した場合（ユーザー操作を定義するときに議論）、FederatedCredential を credential store に以下のプロパティで保存する:

   id

   credential の id

   name,

   credential の name

   iconURL

   credential の iconURL

   [[origin]]

   credential の [[origin]]

   provider

   credential の provider

   protocol

   credential の protocol

4.2.4. FederatedCredentialInit から FederatedCredential を作成する

FederatedCredentialInit から FederatedCredential を作成する ためには、FederatedCredentialInit (init) を受け取り、次の手順を実行します。

1. c を新しい FederatedCredential オブジェクトとする。

2. 以下のいずれかが空文字列の場合、TypeError 例外 を投げる:

   • init.id の値

   • init.provider の値

3. c のプロパティを以下のように設定する:

   id

   init.id の値

   provider

   init.provider の値

   iconURL

   init.iconURL の値

   name

   init.name の値

   [[origin]]

   init.origin の値。

4. c を返す。

5. ユーザー仲介

APIを通じてウェブにクレデンシャル情報を公開することは、ユーザーのプライバシーに関してさまざまな影響を及ぼす可能性があります。したがって、ユーザーエージェントはユーザーが何が起こっているか、誰と自分のクレデンシャルが共有されるのかを明確に理解できるように、いくつかの場合においてユーザーを関与させなければなりません。

あるアクションがユーザーの明示的な同意を得た後に行われる場合、それを ユーザー仲介 と呼びます。同意は、クレデンシャル選択インターフェースとの直接的な操作によって示される場合があります。一般的に、ユーザー仲介アクションは、ユーザーに何らかのUIを提示し、意思決定を求めることが含まれます。

アクションがユーザーの明示的な同意なしに静かに行われる場合、それは非仲介型です。例えば、ユーザーが特定のオリジンに永続的なクレデンシャルアクセスを許可するようブラウザを設定した場合、ユーザーに意思決定を求めるUIを表示せずにクレデンシャルが提供されることがあります。

ここでは、すべてのクレデンシャルタイプに共通するいくつかの要件を示しますが、ユーザーエージェント側の裁量に委ねられている部分も多くあります（ユーザーを支援できる特権的な立場にあるため）。また、特定のクレデンシャルタイプには、ここで一般的に記載されている要件を超える独自の要件がある場合もあります。

5.1. クレデンシャルの保存と更新

クレデンシャル情報は機微なデータであり、ユーザーがその情報の保存を常に管理できる必要があります。意図しないクレデンシャルの保存は、特定のデバイス上のローカルプロファイルとオンライン上の特定の人物が予期せず紐付けられる可能性があります。このような驚きのリスクを軽減するために：

1. クレデンシャル情報はユーザー仲介なしに保存や更新すべきではありません。例えば、ユーザーエージェントは store() の呼び出しごとに「このクレデンシャルを保存しますか？」というダイアログを表示できます。

   ユーザーの同意は、ユーザーエージェントが「常にパスワードを保存する」などの永続的な同意オプションを提供する場合に推測されることもあります（ただし、より範囲の狭い「常に生成されたパスワードのみ保存する」や「このサイトのパスワードのみ保存する」といった選択肢が望ましいでしょう）。

2. ユーザーエージェントはクレデンシャルが保存されたとき、ユーザーに通知すべきです。これはアドレスバーのアイコン表示などで実現できます。

3. ユーザーエージェントはユーザーが保存済みクレデンシャルを手動で削除できるようにしなければなりません。この機能は設定ページや上記の通知とのインタラクションなどで実装できます。

5.2. ユーザー仲介の要求

デフォルトでは、すべてのユーザー仲介がオリジンに対して要求されます。これは対応するサイレントアクセス防止フラグがクレデンシャルストア内で true に設定されているためです。ユーザーはオリジンへのクレデンシャルへの永続的なアクセスを許可することもでき（例えば「このサイトに常にログインした状態にする」オプションなど）、このフラグが false になります。この場合、ユーザーは常にそのサイトにログインした状態になりますが、利便性の観点では望ましいものの、場合によっては驚きの結果を招くこともあります（例えば、ユーザーエージェントがこのフラグの状態を複数のデバイス間で同期する場合など）。

驚きのリスクを軽減するために：

1. ユーザーエージェントは、特定のオリジンまたはすべてのオリジンに対してユーザー媒介を要求できるよう、ユーザーに許可しなければなりません（MUST）。この機能は、各オリジンのprevent silent access flagをfalseに上書きするグローバルなトグルや、特定のオリジン（あるいは特定のオリジンにおける特定の資格情報）に対するより細やかな設定として実装される場合があります。

2. ユーザーエージェントは、オリジンのprevent silent access flagをユーザー媒介なしにfalseに設定してはなりません（MUST NOT）。たとえば、credential chooser（§ 5.3 Credential Selectionで説明）には、ユーザーがチェックボックスを切り替えて当該オリジンで媒介なしで利用可能にできる資格情報をマークできるようにしたり、ユーザーエージェントが資格情報マネージャのオンボーディングプロセスでデフォルト設定をユーザーに尋ねることも考えられます。

3. ユーザーエージェントは、資格情報がオリジンに提供されたとき、ユーザーに通知しなければなりません（MUST）。これはアドレスバーのアイコンや、同様の場所で通知する形でも構いません。

4. ユーザーがあるオリジンの閲覧データ（Cookie、localStorage など）を消去した場合、ユーザーエージェントはそのオリジンのprevent silent access flagをtrueに設定しなければなりません（MUST）。

5.3. クレデンシャルの選択

オリジンでget()が呼び出され、そのオリジンがユーザー媒介を要求する場合、ユーザーエージェントは資格情報を共有する許可をユーザーに求めなければなりません（MUST）。これは、サイトで利用可能な資格情報のリストをユーザーに提示し、どれをウェブサイトに提供するかを選択させたり、リクエストを完全に中止させたりできる資格情報選択UI（credential chooser）の形で提供するべきです（SHOULD）。

選択UIのユーザーインターフェースは、ウェブサイトが生成可能なUIと区別できるように実装されるべきです（SHOULD）。例えば、選択UIがユーザーエージェントのUIと何らかの偽装不能な形で重なって表示されてもよいでしょう。

選択UIのユーザーインターフェースには、資格情報を要求しているオリジンの表示が必ず含まれていなければなりません（MUST）。

選択UIのユーザーインターフェースには、資格情報を要求したオリジンに関連付けられている全てのCredentialオブジェクトが含まれているべきです（SHOULD）。

ユーザーエージェントは、このような選択UIの利便性を高めるために、本書で指定されている属性以外の情報を各Credentialオブジェクトに内部的に関連付けてもかまいません（MAY）。例えば、ファビコンなどを使ってIDプロバイダの判別を支援するなどが考えられます。追加情報はウェブに直接公開されてはなりません（MUST NOT）。

選択UIの挙動はここでは定義されていません：ユーザーエージェントは、ユーザーに認証オプションについて教育し、提示する資格情報を選択するプロセスをガイドするUIの工夫を推奨されます。それを踏まえ、選択UIのインターフェースは以下の通りです：

6. セキュリティに関する考慮事項

以下の各節は、セキュリティおよびプライバシーに関するガイドラインを示しています。個々のクレデンシャルタイプは、これらのガイドラインより厳格または緩和されたバージョンを適用することがあります。

6.1. クロスドメインでのクレデンシャルアクセス

クレデンシャルは機微な情報であり、ユーザーエージェントはそれをウェブサイトと安全に共有できるタイミングについて慎重である必要があります。最も安全な選択肢は、クレデンシャルの共有を保存した正確なオリジンに限定することです。しかし、それはウェブにとって制約が厳しすぎる場合があります。たとえば、example.comとadmin.example.comのように機能をサブドメインに分割するサイトを考えてみてください。

ユーザーへの煩わしさとセキュリティのバランスを取るため、ユーザーエージェントは以下のようにします：

1. スキーム要素がセキュリティを低下させるオリジン間でクレデンシャルを共有してはなりません。つまり、http://example.com/で保存したクレデンシャルをhttps://example.com/で利用できるようにするのは（開発者の安全な通信への移行を促すため）許容されますが、その逆は危険です。

2. ユーザーエージェントはPublic Suffix List [PSL]を使用して、クレデンシャルの有効範囲を決定してもよいです。これはクレデンシャルの登録可能ドメインと[[origin]]、およびget()が呼ばれるオリジンの比較によって判断します。つまり、https://admin.example.com/やhttps://example.com/で保存されたクレデンシャルは、https://www.example.com/からget()が呼ばれた際に提示されてもよく、逆も同様です。

3. クレデンシャルのオリジンが呼び出し元オリジンと完全一致しない場合、get()への応答でクレデンシャルを直接提示してはなりません。必ずユーザー仲介を伴う必要があります。つまり、Credentialオブジェクトはhttps://example.comから直接https://www.example.comに返されることはなく、選択UIを経由してユーザーに提示する必要があります。

6.2. クレデンシャル漏洩

開発者は、クロスサイトスクリプティング攻撃がユーザーのアカウントへの永続的なアクセスに変わるリスクを軽減するために、データ送信先を制限する適切なContent Security Policy [CSP]を設定するなど、いくつかの対策を講じることが強く推奨されます。特に、開発者は次のディレクティブがページのポリシーに明示的または暗黙的に設定されていることを確認すべきです：

• script-src および object-src は、どちらもページ上でのスクリプト実行を制限し、クロスサイトスクリプティング攻撃がそもそも成功しにくくなります。もしサイトが form 要素を利用している場合は、form-action ディレクティブも設定すべきです。

• connect-src は、fetch() がデータを送信できるオリジンを制限します（これにより、資格情報がevil.comなどに流出するリスクを低減します）。

• child-src は、ページ内に埋め込むことができるネストされた閲覧コンテキストを制限し、悪意のあるpostMessage()ターゲットの注入をより困難にします。[HTML]

もちろん、開発者は入力と出力の適切なエスケープ処理や、Subresource Integrity [SRI]など、他の防御策も検討すべきです。

特定のクレデンシャルタイプを定義する際には、クレデンシャルデータの送信方法にも十分な配慮を行うべきです。例えば、同一オリジンのエンドポイントのみ送信を許可する伝送方式を定義するのが妥当かもしれません。

6.3. 安全でないサイト

ユーザーエージェントは、ここで定義されているAPIをセキュアコンテキストではない環境に公開してはなりません（MUST NOT）。ユーザーエージェントは、ユーザーの資格情報を保存し、サインインフォームに自動入力するオートフィル機能を非・信頼できるURL上で実装する場合がありますが、そうしたサイトは資格情報マネージャと直接やり取りすることは信頼できず、また、それらのサイトがセキュアコンテキストで保存された資格情報へアクセスすることはできません（MUST NOT）。

6.4. オリジン混同

フレーム化されたページが現行標準で定義されたAPIにアクセスできる場合、ユーザーがトップレベル閲覧コンテキスト以外のオリジンに対してクレデンシャルへのアクセス権を誤って与えてしまう可能性があります。トップレベル閲覧コンテキストこそが、ユーザーが理解できる唯一のセキュリティオリジンです。

本書では、ユーザーエージェントがUI設計に十分配慮すれば、いくつかのクレデンシャルタイプはそうしたコンテキストにも安全に公開可能と考え、Credential Management APIをそれらのコンテキストにも公開しています。

しかしながら、特定のクレデンシャルタイプはリスクなしでこうしたコンテキストに公開するのが困難です。これらのタイプは、[[Create]](origin, options, sameOriginWithAncestors)、 [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors)、 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)、 [[Store]](credential, sameOriginWithAncestors) の各メソッドにおいて適切に制限されています。

例えば、PasswordCredentialの [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) メソッドは、Workerや非トップレベル閲覧コンテキストから呼ばれた場合、即座に空集合を返します。

6.5. サインアウト

ユーザーが§5.2 ユーザー仲介の要求で述べたように、ウェブサイトへの自動サインインを選択している場合、ユーザーエージェントは要求に応じてオリジンにクレデンシャルを提供します。ウェブサイトは、CredentialsContainerの preventSilentAccess() メソッドを呼び出すことで、この動作を抑制できます。これにより特定のオリジンで自動サインインを停止できます。

ユーザーエージェントはウェブサイトが適切に振る舞うことに依存しています。不注意または悪意のあるウェブサイトがこのメソッドを呼ばなければ、ユーザーエージェントはユーザーの意図に反してクレデンシャルを提供し続けることになります。これは、サイトがユーザーが「サインアウト」をクリックしてもクレデンシャルを消去しない現状よりも若干悪化します。なぜなら、ユーザーエージェントが認証に加担することになるからです。

ユーザーはこの動作を制御できなければなりません。§5.2 ユーザー仲介の要求で述べた通り、オリジンのCookieを消去すると、そのオリジンのサイレントアクセス防止フラグも クレデンシャルストア内でtrueにリセットされます。加えて、ユーザーエージェントは特定オリジンの自動サインインを無効化できるUI（例えばクレデンシャルが提供された通知に連動したUIなど）も提供すべきです。

7. プライバシーに関する考慮事項

7.1. タイミング攻撃

ユーザーがあるオリジンに対してクレデンシャルを持っていない場合、get() の呼び出しは非常に素早く解決されます。悪意のあるウェブサイトは、クレデンシャルを持っていないユーザーと、クレデンシャルは持っているが共有しないユーザーとを区別することができます。

ユーザーエージェントはクレデンシャル要求にレート制限を設けるべきです。短時間に何度もクレデンシャルを要求するページはほぼ確実に悪質です。

7.2. 選択UIの漏洩

ユーザーエージェントのクレデンシャル選択UIがオリジンから提供された画像（例えばCredential がサイトのファビコンを表示する場合）を表示する場合、これらの画像のリクエストは選択UIの生成に直接紐付けてはなりません。選択UIの利用状況が漏れるのを防ぐためです。ひとつの方法は、クレデンシャルの保存や更新時に画像をバックグラウンドで取得し、クレデンシャルの有効期間中キャッシュしておくことです。

これらの画像はcredentials modeを"omit"、 service-workers modeを"none"、 clientをnull、 initiatorを空文字列、 destinationを"subresource"に設定して取得しなければなりません。

さらに、ユーザーエージェントがクレデンシャルに関連付けられた名前やアイコンをユーザーが変更できる場合、その変更内容はウェブサイトに公開されるべきではありません（例えば、ユーザーが同じオリジンの2つのクレデンシャルに「偽のアカウント」と「本物のアカウント」と名付けた場合など）。

7.3. ローカル保存データ

このAPIは、オリジンに対し、ユーザープロファイルとともにデータを永続的に保存する機能を提供します。 多くのユーザーエージェントはクレデンシャルデータを「閲覧データ」（Cookieなど）とは区別して扱うため、ユーザーがCookieを消去してオリジンの痕跡がすべて消えたと思っても、クレデンシャルが残っていて驚く可能性があります。

ユーザーエージェントは、オリジンごとにクレデンシャルデータが保存されていることをユーザーに明示するUIを提供し、不要になったデータを容易に削除できるようにすべきです。

9. 今後の課題

この節は規範的ではありません。

ここで定義されたAPIは、ユーザーエージェントの資格情報マネージャをウェブに公開するための最低限の機能のみを提供し、ウェブがこれらの資格情報マネージャにフェデレーションIDプロバイダの利用状況を理解させることを可能にします。次の論理的なステップは、[WEB-LOGIN]のような文書（および、ある程度はMozillaのBrowserID [BROWSERID]）で示された方向性に沿ったものになるでしょう。

ユーザーエージェントは、ユーザー・アイデンティティプロバイダー・ウェブサイト間の関係を効果的に仲介できる唯一の立場にあります。ユーザーエージェントが一般的な認証フローに伴うリスクや混乱を軽減できれば、ユーザーは現在よりもはるかに良い状況になるでしょう。

この情報を公開する自然な方法としては、FederatedCredential インターフェースを認証トークンなどのプロパティで拡張したり、プロバイダーがサポートする認証タイプを宣言するプロパティを持つマニフェスト形式を追加することが考えられます。

ここで説明したAPIは、ユーザー操作を必要とするユースケースや、クレデンシャルを要求したウェブサイト以外のサイトとのやり取りを含むユースケースにも対応できるよう十分に拡張可能となるよう設計されています。Promiseベースのシステムは、複数の閲覧コンテキスト間（例：idp.com での仲介活動によって rp.com にPromiseが返される場合）や、将来デバイス・ユーザーエージェント間（例：[WEBAUTHN]）での非同期フローをAPI自体の再設計なしにサポートできる拡張性を持つことを期待しています。

少しずつ前進していきます。