認証情報管理レベル1

1. はじめに

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

ウェブサイトへのサインインは、理想よりも難しいものです。ユーザーエージェントは、ユーザー体験を様々な方法で向上させる独自の立場にあり、ほとんどの現代的なユーザーエージェントは、ブラウザでネイティブに認証情報管理機能をある程度備えています。例えば、ユーザーはウェブサイトのユーザー名やパスワードを保存でき、後でそれらの認証情報がサインインフォームに自動入力されますが、その成功度は様々です。

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

このヒューリスティックと宣言的検出の組み合わせは比較的うまく機能しますが、現状には検出が困難な大きなギャップが残っています。例えば、一般的でないサインインの仕組み（XMLHttpRequest [XMLHTTPREQUEST]で認証情報を送信する場合など）は、確実な検出が困難です。また、ユーザーがフェデレーテッドIDプロバイダーを用いて認証したいという、近年増加しているケースも同様です。ウェブサイトがユーザーエージェントの認証情報マネージャーとより直接的にやり取りできれば、認証情報マネージャーの精度が向上し、フェデレーテッドサインインの支援も可能になります。

これらのユースケースについては、§ 1.1 ユースケースおよび認証情報管理：ユースケースと要件で詳しく説明されています。本仕様は、ウェブサイトが認証情報をユーザーのために要求したり、サインインが成功した際にユーザーエージェントへ認証情報の保存を依頼できる「Credential Manager API」を定義し、その要件の多くに対応することを目的としています。

注: ここで定義するAPIは意図的に小さくシンプルです。認証自体を提供するものではなく、既存ユーザーエージェントが実装する認証情報管理機能へのインターフェースのみに限定しています。この機能は、ベンダーや著者の大きな負担なしに今すぐ役立つものです。もちろん、今後さらに多くのことが可能です。今後の課題は§ 9 今後の課題をご覧ください。

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. インフラストラクチャ

ユーザーエージェントは、ベンダー固有かつ不透明なストレージメカニズムである認証情報ストアを内部的に必ず提供しなければなりません。これは、どの認証情報が有効だったかを記録します。以下の認証情報アクセスおよび永続化機能を備えています：

1. 認証情報の保存（後で取得可能）。認証情報を受け取り、認証情報ストアに登録します。

2. 認証情報リストの取得。任意のフィルターを受け取り、該当する認証情報セットを返します。

3. 認証情報の変更。認証情報を受け取り、既存の認証情報の状態を認証情報ストア内で上書きします。

さらに、認証情報ストアは、サイレントアクセス防止フラグをオリジンごとに管理すべきです（特に指定がない限りtrueに設定）。オリジンのフラグがtrueなら、そのオリジンはユーザー操作が必要となります。

注: ユーザー操作の重要性は§ 5 ユーザーメディエーションで詳述されています。

注: 認証情報ストアは本仕様のAPI実装におけるユーザーエージェントの内部実装詳細であり、ウェブに直接公開されません。特定の認証情報タイプをサポートするため、他の文書でさらに機能が指定される場合があります。

本仕様はアルゴリズムや記述に用いる基盤概念としてInfra現行標準に依存しています [INFRA]。

各環境設定オブジェクトは、関連付けられたアクティブ認証情報タイプ（初期状態は空の集合）を持ちます。

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. ユーザーエージェントは、特定のオリジンやすべてのオリジンに対してユーザー仲介を要求できるようユーザーに許可しなければなりません。この機能は、各オリジンのサイレントアクセス防止フラグを false にするグローバル切替や、特定オリジンや特定クレデンシャルに対する個別設定などで実現できます。

2. ユーザーエージェントは、オリジンのサイレントアクセス防止フラグをユーザー仲介なしに falseにしてはなりません。例えば、クレデンシャル選択でチェックボックスを設け、ユーザーがそのオリジンに対して仲介なしでクレデンシャルを利用できるように指定できたり、クレデンシャルマネージャーの初期設定でデフォルト設定を尋ねることもできます。

3. ユーザーエージェントは、クレデンシャルがオリジンに提供された際にユーザーに通知しなければなりません。これはアドレスバーのアイコン表示などで実現できます。

4. ユーザーがオリジンの閲覧データ（Cookie、localStorageなど）をクリアした場合、ユーザーエージェントはそのオリジンのサイレントアクセス防止フラグを true に設定しなければなりません。

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

get() の呼び出しに対し、ユーザー仲介が必要なオリジンの場合、ユーザーエージェントはクレデンシャル情報の共有についてユーザーの許可を求めなければなりません。 これは、ユーザーに利用可能なクレデンシャルの一覧を提示し、どれをウェブサイトに提供するか選択したり、リクエスト自体を中止できる クレデンシャル選択UIの形態で実装するべきです。

選択UIは、ウェブサイトが生成できるUIとは区別できるように実装されるべきです。例えば、選択UIがユーザーエージェントのUIと重なり、偽装できない方法で実装することが考えられます。

選択UIには、クレデンシャルを要求しているオリジンの表示が含まれていなければなりません。

選択UIには、要求元オリジンに関連付けられたすべてのCredentialオブジェクトが含まれているべきです。

ユーザーエージェントは、Credentialオブジェクトごとに、本書で規定されている属性以外の情報を内部的に持つことができます。例えば、ファビコンを使ってIDプロバイダーを区別するなどです。追加情報はウェブには直接公開されてはなりません。

選択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をセキュアコンテキストでない環境に公開してはなりません。ユーザーエージェントは、潜在的に信頼できないURL上でサインインフォームを自動入力する機能を持つことはありますが、そうしたサイトはクレデンシャルマネージャーと直接やりとりする信頼はできず、セキュアコンテキストで保存されたクレデンシャルへのアクセスは許可されません。

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は、ユーザーエージェントのクレデンシャルマネージャーをウェブに公開するための最低限の機能を提供し、ウェブがフェデレーテッドアイデンティティプロバイダーの利用状況をクレデンシャルマネージャーに伝えるのに役立ちます。次の論理的なステップは、[WEB-LOGIN] や、ある程度は Mozilla の BrowserID [BROWSERID] のような文書で概略されている方向性になるでしょう。

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

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

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

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