認証情報管理レベル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 拡張で使用されるものとして記載しなければなりません。

• 各レジストリエントリは、適切なインターフェイスオブジェクトの 識別子を 認証情報タイプごとに記載しなければなりません。

• 各レジストリエントリは、取得パーミッションポリシーとなる パーミッションを Credentialのリクエストを 認証情報タイプに対して行う際に使用するものとして記載しなければなりません。 パーミッションポリシーが指定されていない場合はnullとします。

• 各レジストリエントリは、作成パーミッションポリシーとなる パーミッションを Credentialの作成を 認証情報タイプに対して行う際に使用するものとして記載しなければなりません。 パーミッションポリシーが指定されていない場合はnullとします。

• get() のリクエストでは1つのリクエストで複数タイプを問い合わせることが可能ですが、 すべての組み合わせが許可されるわけではありません。各レジストリエントリにはセットとしての 認証情報タイプ を記載し、 その同一get()リクエストで許容されるタイプ を示さなければなりません。 他と混在できない場合はemptyを記載します。 いずれの認証情報タイプもget()リクエストで自身とは混在可能です。

• 各レジストリエントリには、その認証情報タイプおよび辞書メンバーの識別子を定義する公開仕様への参照リンクが必要です。

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

このレジストリの更新は、認証情報タイプの登録エントリの追加、変更、または削除です。 どなたでもwebappsec-credential-management レポジトリへのPull Requestによって本レジストリの更新を申請できます。 Web Applications Security Working Groupは次回以降の会議アジェンダに追加し、 申請者へ通知します。 申請に対する検討と対応はW3C Web Applications Security Working Groupの合意により行われます。 議長は結果を申請者に知らせ、必要に応じてレジストリが更新されます。

2.2. Credentialインターフェース

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

TobieやDominicと、 インターフェースオブジェクトの扱いについて ここや§2.5.1 Credentialのリクエストなどで相談すること。用語の使い方が正しくないかもしれない。 インターフェースプロトタイプオブジェクトかもしれない？

一部のCredential オブジェクトはオリジンバウンドです。これらは [[origin]] という内部スロットを持ち、 そこにはこのCredential が有効となりうる オリジン を保存します。

2.2.1. Credentialの内部メソッド

Credential インターフェースオブジェクトには、内部メソッドがいくつか備わっており、 Credential オブジェクトの取得や保存を支援します。各メソッドは、本節以下に示すデフォルトの「何もしない(no-op)」実装を持ちます。

特に明記されていない限り、Credential を継承するインターフェース用に作られる各インターフェースオブジェクトは、 少なくとも下記内部メソッドのいずれか1つ以上の実装を持たなければなりません（MUST）。 必要に応じて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から継承） を返すアルゴリズムを返します。 このアルゴリズムはタスクから呼び出されなければなりません。

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

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

1. nullを返す。

2.2.2. CredentialUserDataミックスイン

一部の Credential オブジェクトには、ユーザーが認証情報選択UIで判別しやすくするための、表示用の名前やアイコン画像のデータが含まれています：

[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辞書

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

注記: CredentialRequestOptions 辞書は拡張ポイントです。 新しいタイプの認証情報がオプションを必要とし導入される場合、その辞書型がこの辞書に追加され、リクエストに渡せるようになります。 詳しくは§ 8.2 拡張ポイントを参照してください。

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

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

get(options) やcreate(options) でリクエストする際、開発者は 適切なCredentialMediationRequirement の列挙値を選んで ユーザーメディエーション 要否を個別に設定できます。

注記: § 5 ユーザーメディエーション の章にて、この概念全般やユーザーエージェントがオリジンごとのリクエストにどう応じるかの影響がより詳しく解説されています。

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

2.3.3. UIモード

get(options) でリクエストする際、開発者は 希望するユーザーメディエーションモードを 適切なCredentialUiMode の列挙値を指定して表現できます。

UI Modeフィールドには既定値はありません。値が指定されていなければ、 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)メソッドが CredentialMediationRequirement のみを考慮してユーザーエージェントの動作を決定しなければなりません。

注記: これにより呼び出し元は ユーザーメディエーション が発生する場合に異なるUI形式を区別できます。 UIの表示有無は、そのリクエストの CredentialMediationRequirement 値に依存します。 すべてのCredentialUiMode の値を、すべての CredentialMediationRequirement 値と自由に組み合わせて意味があるとは限らず、 その組み合わせの動作は、各認証情報タイプがサポートする [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) メソッドに依存することになります。

enum CredentialUiMode {
  "immediate"
};

2.3.3.1. 例

window.addEventListener('load', async () => {
  const credentials = await navigator.credentials.get({
    ...,
    mediation: 'silent'
  });
  if (credentials) {
    // Hooray! Let's sign the user in using these credentials!
  }
});

document.querySelector('#sign-in').addEventListener('click', async () => {
  const credentials = await navigator.credentials.get({
    ...,
    mediation: 'optional'
  });
  if (credentials) {
    // Hooray! Let's sign the user in using these credentials!
  }
});

document.querySelector('#important-form').addEventListener('submit', async () => {
  const credentials = await navigator.credentials.get({
    ...,
    mediation: 'required'
  });
  if (credentials) {
    // Verify that |credentials| enables access, and cancel the submission
    // if it doesn't.
  } else {
    e.preventDefault();
  }
});

document.querySelector('#switch-button').addEventListener('click', e => {
  var c = await navigator.credentials.get({
    ...,
    mediation: 'required'
  });
  if (c) {
    // Sign the user in using |c|.
  }
});

2.4. CredentialCreationOptions辞書

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

注: CredentialCreationOptions 辞書は拡張ポイントです。新しい種類の認証情報が導入された場合、その辞書型がこの辞書に追加され、作成時に渡せるようになります。 詳細は§ 8.2 拡張点および本ドキュメントで導入される拡張（ § 3.2 パスワード認証情報インターフェース・ § 4.1 フェデレーテッド認証情報インターフェース）を参照してください。

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

2.5. アルゴリズム

2.5.1. Credentialの要求

Credential のリクエストアルゴリズムは、 CredentialRequestOptions (options) を受け取り、資格情報を明確に取得できればそれで解決される Promise を返します。明確な取得ができない場合はnullで解決されます。

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

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

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

4. もしdocumentが完全にアクティブでない場合は、拒否状態のpromise "InvalidStateError" DOMException を返す。

5. options.signal の中止されている場合、 拒否状態のpromise を options.signalの 中断理由で返す。

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

7. もしinterfacesが空なら、 拒否状態のpromise "NotSupportedError" DOMException を返す。

8. 各interface1 of interfacesについて:

   1. type1をinterface1の[[type]] とする。

   2. 各interface2 of interfacesについて:

      1. type2をinterface2の[[type]] とする。

      2. もしtype1 が type2と等しい場合は続行。

      3. もしtype1の同一get()リクエストで許容されるタイプに type2が含まれていないなら、 拒否状態のpromise "NotSupportedError" DOMException を返す。

9. 各interface of interfacesについて:

   1. もしoptions.mediation が conditional であり、かつinterfaceが conditional ユーザーメディエーション に非対応なら、拒否状態のpromise TypeError を返す。

   2. もしoptions.uiMode が immediate であり、かつinterfaceが immediate ユーザーメディエーション に非対応なら、拒否状態のpromise TypeError を返す。

   3. もしsettingsの有効な認証情報タイプが interfaceの [[type]] を含んでいる場合、 拒否状態のpromise "NotAllowedError" DOMException を返す。

   4. interfaceの[[type]] をsettingsの 有効な認証情報タイプ に追加する。

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

11. sameOriginWithAncestorsを、settingsが祖先と同一オリジンなら true、そうでなければ false とする。

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

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

    2. もしpermissionがnullなら続行。

    3. もしdocumentが permissionの使用を 許可されていない場合は 拒否状態のpromise "NotAllowedError" DOMException を返す。

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

14. 次の手順を並行して実行する：

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

    2. もしcredentialsが例外であれば p をcredentialsで拒否する。

    3. 次のすべてが真ならpを credentials[0]で解決し、残りの手順をスキップする：

       1. credentialsのサイズが1

       2. originがユーザーメディエーションを必要としない

       3. optionsが事前にマッチ可能である。

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

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

       このモデルは正しくないかもしれません。たとえば、パスワード認証・webauthn型のどちらでも受け付けるが、前者だけなら選択ダイアログを省略してサインインしたい等が実現できると便利かもしれません。

    4. もしoptions’ mediation が "silent" なら、pをnullで解決して残りの手順をスキップ。

    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で拒否する。

          3. これ以降の手順を終える。

    7. アサート: resultはnullまたはCredentialである。

    8. もしresultがCredentialであれば、 pをresultで解決する。

    9. もしresultがnullで、かつoptions.mediation が conditionalで なければ、 pをresultで解決する。

       注記: options.mediation が conditional で、nullの認証情報が発見された場合、promise pは解決されません。

15. pが確定したら反応する：

    1. 各interface of interfacesについて:

       1. interfaceの[[type]] を settingsの 有効な認証情報タイプ から除去する。

16. pを返す。

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

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

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

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

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

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

   3. r の各 c について：

      1. set append 操作で c を possible matches に追加。

3. possible matches を返す。

2.5.3. Credentialの保存

Credentialを保存するアルゴリズムは Credential (credential) を受け取り、 認証情報ストアへの保存が完了した時に解決される Promise を返します。

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

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

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

4. sameOriginWithAncestorsを 現在の設定オブジェクトが 祖先と同一オリジンならtrue、 そうでなければfalseとする。

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

6. もしsettingsの有効な認証情報タイプが credentialの [[type]] を含んでいる場合、 拒否状態のpromise "NotAllowedError" DOMExceptionを返す。

7. credentialの[[type]] をsettingsの 有効な認証情報タイプ に追加する。

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

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

      この実行で例外がスローされた場合：

      1. スローされた例外をeとする。

      2. タスクをキューイング し、 globalの DOM 操作タスクソース で以下のサブステップを実行：

         1. p を e で拒否する。

      成功時は p を undefined で解決する。

9. pが確定したら反応する：

   1. credentialの [[type]] を settings の 有効な認証情報タイプ から除去する。

10. pを返す。

2.5.4. Credentialの作成

Credentialを作成するアルゴリズムは、 CredentialCreationOptions (options) を受け取り、 指定されたoptionsで作成できる場合は Promise をCredential とともにresolveし、 ひとつもCredential を作成できない場合はnullでresolveします。 例外的な状況では、 Promise は適切な例外でrejectされることがあります。

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

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

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

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

5. もし document が 完全にアクティブ でない場合、 拒否状態のPromise "InvalidStateError" DOMException を返す。

6. sameOriginWithAncestors を、 現在の設定オブジェクト が 祖先と同一オリジンなら true、 そうでなければ false とする。

7. interfaces を セット として options の 該当する認証情報インターフェースオブジェクトを得る。

8. 以下のどれかが該当する場合、拒否状態のPromise NotSupportedError を返す：

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

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

      注記: 将来的にはこの制約を緩和して、 ユーザーエージェントが複数の候補となる認証情報タイプからユーザー操作で1つを選ぶ「サインアップ」用途などをサポートできるかもしれません。 現時点では、辞書を1エントリに制限することで対応を先送りしています。

9. interfaces 内の各 interface について：

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

   2. もし permission が null なら続行。

   3. もし document が 許可されていない permission の使用、 拒否状態のPromise "NotAllowedError" DOMException を返す。

10. options.signal が 中断されているなら 拒否状態のPromise を options.signal の 中断理由 で返す。

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

12. もし settings の 有効な認証情報タイプ が type を 含んでいれば、 拒否状態のPromise "NotAllowedError" DOMExceptionを返す。

13. type を settings の 有効な認証情報タイプ に追加する。

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

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

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

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

       それが 例外なら：

       1. スローされた 例外 を e とする。

       2. タスクをキューイングし、 global の DOM操作タスクソースで以下のサブステップを実行：

          1. p を e で拒否する。

       3. これ以降のサブステップを終了する。

    2. もし r が Credential または null なら、 p を r で解決し、残りのサブステップを終了する。

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

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

       1. pを promise-calling r（引数：global）の結果で解決する。

17. pが解決されたら：

    1. type を settings の 有効な認証情報タイプ から取り除く。

18. p を返す。

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

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

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

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

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

4. 次の手順を 並行して 実行する：

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

   2. p を undefined で解決する。

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 クロスドメイン認証情報アクセス参照）、 あるいはユーザーがその場で新規認証情報を作成できる場合もあります。 このような不確定な状況にも対応できるよう、認証情報が 正しく使われたら（たとえ直前に get() で取得していた場合でも） 毎回 store() を呼びだすことを推奨します。 認証情報がオリジンにまだ保存されていない場合は保存の案内が表示され、 すでに保存されていれば案内は行われません。

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）、CredentialRequestOptions （options）、 および 祖先と同一オリジン かどうかを示すブール値（sameOriginWithAncestors）が true の場合に呼び出されます。 このアルゴリズムは認証情報ストアから Credential オブジェクトの集合を返します。一致する Credential オブジェクトがなければ返される集合は空になります。

アルゴリズムは sameOriginWithAncestors が true でない場合、NotAllowedError 例外を投げます。

1. アサート: 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）と CredentialCreationOptions （options）、および呼び出しコンテキストが祖先と同一オリジンかどうか（sameOriginWithAncestors）を示す ブール値が与えられて呼び出されます。 アルゴリズムはPasswordCredential が生成できればそれを、できなければ null を返します。CredentialCreationOptions 辞書には必ず password メンバーがあり、これにはHTMLFormElement または PasswordCredentialData が入っていなければなりません。 そのメンバーの値からPasswordCredential を生成できない場合、このアルゴリズムはTypeError 例外を投げます。

1. アサート: options["password"] が存在し、かつ sameOriginWithAncestors は未使用である。

2. もし options["password"] が HTMLFormElement なら、 options["password"] と origin を指定して HTMLFormElementから PasswordCredentialを作成する の結果を返す。例外が発生した場合はそのまま再スローする。

3. もし options["password"] が PasswordCredentialData なら、 options["password"] を指定して PasswordCredentialDataからPasswordCredentialを作成する の結果を返す。例外が発生した場合は再スローする。

4. TypeError 例外を投げる。

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

[[Store]](credential, sameOriginWithAncestors) は、 PasswordCredential (credential) および呼び出しコンテキストが 祖先と同一オリジン (sameOriginWithAncestors) かどうかを示すブール値で呼び出されます。 アルゴリズムは、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）が与えられたとき、次のアルゴリズムは PasswordCredential を get() リクエストの応答として利用可能な場合は "Matches" を、そうでなければ "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）、CredentialRequestOptions （options）、 および呼び出しコンテキストが祖先と同一オリジン (sameOriginWithAncestors)である場合だけtrueとなるブール値で呼び出されます。 このアルゴリズムは認証情報ストアから Credential オブジェクトの集合を返します。一致する Credential がなければ、返される集合は空です。

1. アサート: options["federated"] が存在する。

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

   注: この制約は§ 6.4 オリジンの混同で挙げられた懸念への対応です。

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

4. 以下のフィルタに一致する認証情報ストアからの資格情報取得 の結果を返す：

   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を通じてウェブに認証情報を公開することは、ユーザープライバシーにさまざまな影響を与える可能性があります。そのため、ユーザーエージェントは、ユーザーが何が起きているのか、また自身の認証情報が誰と共有されるのかを明示的に理解できるように、いくつかの場合においてユーザー関与を必須としなければなりません。

特定のアクションがユーザーの明示的な同意を得て行われた場合、そのアクションを ユーザー仲介（user mediated）と呼びます。同意は、たとえば認証情報選択UIを操作するなど、ユーザーが直接インターフェースを操作することで表明される場合があります。一般的に、ユーザー仲介アクションでは、何らかの UI を提示し、ユーザーに判断を求めることが含まれます。

明示的なユーザー同意なく静かに行われるアクションは「非仲介的」と言います。たとえば、ユーザーが特定のオリジンへの認証情報への持続的なアクセスをブラウザーで許可した場合などは、ユーザーへ決断を促す UI を表示することなく認証情報が提供されることがあります。

ここでは、すべての認証情報タイプに当てはまるいくつかの要件を明記しますが、実際にはユーザーエージェント側の裁量も大きく（ユーザーを支援できる特権的な立場にあるためです）、また認証情報タイプによっては本節よりさらに厳しい独自要件が課されることもあります。

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

認証情報は機微なデータであり、その保存に関してユーザーが常にコントロールできる状態でなければなりません。不注意な保存が行われた場合、例えば、特定端末のローカルプロファイルが想定外にオンライン上の一意な人格と結び付くなど、望ましくない事態が生じる可能性があります。そのような驚きのリスクを軽減するため：

1. ユーザー仲介（user mediated）なしに 認証情報を保存・更新すべきではありません（SHOULD NOT）。 例えば、ユーザーエージェントは store() を呼ぶごとに「この認証情報を保存しますか？」とダイアログを表示する対応が考えられます。

   また、ユーザーエージェントが「常にパスワードを保存する」といった持続的な同意をユーザーに提供する場合には、ユーザーの同意は推定してもよい（MAY）。 ただし、より限定的なスコープ（例:「生成されたパスワードは常に保存」「このサイトのパスワードのみ保存」など）に配慮することが望ましいです。

2. ユーザーエージェントは、認証情報が保存されたことをユーザーに通知すべきです（SHOULD）。 これはアドレスバー付近のアイコンや同様の方法で実装できます。

3. ユーザーエージェントは、ユーザーが手動で保存済み認証情報を削除できるようにする必要があります（MUST）。 例えば設定ページや、上記の通知経由の操作などで提供してもよいでしょう。

5.2. ユーザー仲介の要求

デフォルトでは、すべてのユーザー仲介 は、各オリジンごとに必須です。これは、サイレントアクセス防止フラグが認証情報ストアでtrueに設定されているためです。ユーザーは、あるオリジンに永続的な認証情報アクセス（たとえば「このサイトにサインインしたままにする」オプション）を許可することもできます。この場合、フラグはfalseとなります。この場合、そのサイトには常にサインイン済みとなり、利便性や使いやすさの観点からは望ましいものの、予期せぬ影響もあり得ます（たとえばユーザーエージェントがこのフラグの状態を複数デバイス間で同期する場合など）。

そのような「驚き」のリスクを軽減するため：

1. ユーザーエージェントは、ユーザーが特定のオリジンまたはすべてのオリジンについてユーザー仲介を要求できるようにしなければなりません（MUST）。この機能は、グローバルなトグルスイッチ（すべてのオリジンのサイレントアクセス防止フラグをfalseにオーバーライドする）や、より細かな設定（特定のオリジンや認証情報ごとの設定）などで実現できます。

2. ユーザーエージェントは、オリジンのサイレントアクセス防止フラグを falseにユーザー仲介なしで設定してはなりません（MUST NOT）。例として、認証情報選択UI （§ 5.3 認証情報選択で説明）が、ユーザーがチェックボックスを切り替えて、 仲介なしで利用可能にマークできるようにしたり、ユーザーエージェントの認証情報マネージャーの初期設定時に既定値を尋ねたりできます。

3. ユーザーエージェントは、認証情報がオリジンへ提供された際にユーザーへ通知しなければなりません（MUST）。例えばアドレスバーや他のわかりやすい場所でアイコンを表示するなど。

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

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

ユーザー仲介（user mediation）が必要なオリジンで get() が呼ばれた場合、ユーザーエージェントはユーザーに認証情報を共有する許可を尋ねなければなりません（MUST）。 この際、ユーザーにそのサイトで利用できる認証情報のリストを示し、どれをウェブサイトへ提供するか選ばせたりリクエスト自体を中止できるようにする 認証情報選択UI の形式で行うのが望ましいです（SHOULD）。

選択UIは、Webサイトが再現できるUIと明確に区別できるように実装されるべきです（SHOULD）。 たとえばユーザーエージェント独自のUIに重ねて表示するなど、偽装できない形が考えられます。

選択UIには、認証情報を要求しているオリジンの表示が必須です（MUST）。

選択UIには、そのオリジンに関連づいた Credential オブジェクトをすべて含めるべきです（SHOULD）。

ユーザーエージェントは、こうした選択UIの利便性を高める目的で、本仕様で規定された属性以外の情報を Credential オブジェクトごとに内部的に持ってよい（MAY）。例：ファビコン等によりIDプロバイダーを判別しやすくしても良い。ただし、 追加情報はWebに直接公開してはなりません（MUST NOT）。

選択UIの挙動自体はここでは規定されません。 ユーザーエージェントは、ユーザーに認証方式を理解させ、どの認証情報を提示するか案内するためのUI表現の工夫が推奨されています。 インターフェースは次のようになります：

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

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

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

認証情報は機密性の高い情報であり、ユーザーエージェントはそれをいつウェブサイトと安全に共有してよいか慎重に判断する必要があります。最も安全なのは、その認証情報が保存された正確なオリジンへの共有に限定することです。しかし、それではWebとしては制限が厳しすぎる場合もあります。たとえば example.com と admin.example.com のように機能をサブドメインで分けているサイトを考えてください。

ユーザーに煩わしさを与えず認証情報の安全も守るため、ユーザーエージェントは以下の対応を行います：

1. オリジン間で、スキームがセキュリティ上ダウングレードとなる場合には認証情報を共有してはならない（MUST NOT）。 つまり、http://example.com/ で保存された認証情報を https://example.com/ で利用できるようにするのは、 開発者に安全な通信への移行を促す観点で理にかなう場合があるが、逆（https→http）は危険である。

2. パブリックサフィックスリスト [PSL] を利用して、認証情報の有効範囲を判定するために、 その認証情報の 登録可能ドメイン （[[origin]] ）と get() を呼び出しているオリジンの登録可能ドメインを比較してもよい（MAY）。 つまり、https://admin.example.com/やhttps://example.com/ で保存された認証情報は、 https://www.example.com/ から get() を呼び出した際にユーザーへ提示してもよく、その逆も同様。

3. get() に対して、 認証情報のオリジンが呼び出し元のオリジンと完全一致しない場合は、 ユーザーメディエーションなしに、 該当の認証情報を提供してはならない（MUST NOT）。 つまり、https://example.com 用の Credential オブジェクトは https://www.example.com へ直接は返さないが、 選択ダイアログを通じてはユーザーへ提示できる。

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の表示と直接結び付けてはなりません（MUST NOT）。選択UIの利用が外部に漏れることを防ぐためです。一つの方法は、Credential を保存または更新する時に画像をバックグラウンドで取得し、 Credential の存続期間中キャッシュする方法です。

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

さらに、ユーザーエージェントがユーザーに認証情報に紐付いた名前やアイコンの変更を許可する場合、 そのデータの変更はウェブサイトには公開すべきではありません（SHOULD NOT）。 例えば、一つのオリジン用に「偽物アカウント」「本物アカウント」とユーザーが名付けた場合などを考えてください。

7.3. ローカル保存データ

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

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

9. 今後の課題

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

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

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

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

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

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