認証情報管理レベル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内の状態を更新します。

さらに、資格情報ストアは、オリジンごとにprevent silent accessフラグを 維持するべきである（特に指定されない限り、これはtrueに設定される）。 オリジンのフラグが trueに設定されている場合、そのオリジンはユーザー仲介を必要とする。

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()リクエストで許容されるタイプ を示さなければなりません。 同じ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) を受け取り、Credential を一意に取得できればそれで解決される 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. interfacesの各interface1について反復する：

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

   2. interfacesの各interface2について 反復する：

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

      2. type1がtype2と等しい場合、続行する。

      3. type1の同じ get() リクエストで許可される型がtype2を含まない場合、 次を伴って拒否された promise、"NotSupportedError" DOMExceptionを返す。

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

10. interfacesの各interfaceについて反復する：

    1. interfaceのインスタンスがオリジンに バインドされるものであり、かつoriginが 不透明なオリジンである場合、次を伴って拒否された promise、 "SecurityError" DOMExceptionを返す。

11. interfacesの各interfaceについて反復する：

    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の 末尾に追加する アクティブな資格情報型に。

12. settingsがその祖先と同一オリジンである場合はsameOriginWithAncestorsをtrueとし、そうでない場合は falseとする。

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

    1. permissionをinterfaceの[[type]]の Get Permissions Policyとする。

    2. permissionがnullである場合、続行する。

    3. documentがpermissionの使用を許可されていない場合、使用を許可されているものではなく、 次を伴って拒否された promise、"NotAllowedError" DOMExceptionを返す。

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

15. 以下の手順を並列に実行する：

    1. credentialsを、origin、 options、および sameOriginWithAncestorsを与えて、資格情報ストアから Credentialを収集する結果とする。

    2. credentialsが例外である場合、credentialsでpを拒否する。

    3. 以下のすべての文が真である場合、pを credentials[0]で解決し、 残りの手順をスキップする：

       1. credentialsのサイズが1である

       2. originがユーザー仲介を必要としない

       3. optionsがa prioriに照合可能である。

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

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

       これは 誤ったモデルかもしれない。ユーザー名／パスワードまたは WebAuthn 形式の資格情報のいずれかを受け入れたいサイトで、 前者を使用し、かつサインイン状態を維持したいユーザーに選択 UI を強制することなく、 それをサポートできれば望ましい。

    4. optionsのmediation が "silent"である場合、 pをnullで解決し、 残りの手順をスキップする。

    5. resultを、optionsおよび credentialsを与えて、ユーザーに Credentialを選択するよう求める結果とする。

    6. resultがインターフェイスオブジェクトである場合：

       1. origin、options、および sameOriginWithAncestorsを与えて、resultをresultの [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)を実行した結果に設定する。

          それが例外を送出した場合：

          1. eを送出された例外とする。

          2. 以下のサブステップを実行するため、globalのDOM 操作タスク ソース上にタスクをキューに入れる：

             1. eでpを拒否する。

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

    7. 表明：resultはnull、またはCredentialである。

    8. resultがCredentialである場合、 pをresultで解決する。

    9. resultがnullであり、かつoptions.mediation が conditionalではない場合、 pをresultで解決する。

       注：options.mediation が conditional であり、null資格情報が発見された場合、 promise pは解決されない。

16. pに反応する：

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

       1. interfaceの[[type]]をsettingsの アクティブな資格情報型から削除する。

17. 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が完全にアクティブでない場合、 "InvalidStateError" DOMExceptionを伴って拒否された promiseを返す。

4. credentialがオリジンにバインドされているものであり、かつsettingsのオリジンが不透明なオリジンである場合、"SecurityError" DOMExceptionを伴って拒否された promiseを返す。

5. 現在の設定オブジェクトがその祖先と同一オリジンである場合はsameOriginWithAncestorsをtrueとし、そうでない場合は falseとする。

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

7. settingsのアクティブな資格情報型がcredentialの [[type]]を含む場合、 "NotAllowedError" DOMExceptionを伴って拒否された promiseを返す。

8. credentialの[[type]]をsettingsの アクティブな資格情報型に追加する。

9. 以下の手順を並列に実行する：

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

      それが例外を送出した場合：

      1. eを送出された例外とする。

      2. globalのDOM 操作タスクソース上にタスクをキューに入れ、 以下のサブステップを実行する：

         1. eでpを拒否する。

      そうでない場合、pをundefinedで解決する。

10. pに反応する：

    1. credentialの[[type]]をsettingsの アクティブな資格情報型から削除する。

11. 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が完全にアクティブでない場合、 "InvalidStateError" DOMExceptionを伴って拒否された promiseを返す。

6. 現在の設定オブジェクトがその祖先と同一オリジンである場合はsameOriginWithAncestorsをtrueとし、それ以外の場合は falseとする。

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

8. 以下の文のいずれかが 真である場合、NotSupportedErrorを伴って拒否された promiseを返す：

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

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

      注：将来のある時点でこの制限を 緩和し、 「サインアップ」のユースケースをサポートするために、複数の候補となる資格情報 型の中から1つをユーザーエージェントが選択できるよう支援することは妥当かもしれない。ただし現時点では、辞書を単一のエントリに制限することで この問題への対応を先送りしている。

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

   1. permissionをinterfaceの[[type]]の 作成時の Permissions Policyとする。

   2. permissionがnullである場合、続行する。

   3. documentがpermissionの使用を許可されていない場合、 "NotAllowedError" DOMExceptionを伴って拒否された promiseを返す。

10. options.signal が中止済みである場合、 options.signalの 中止理由を伴って拒否された promiseを返す。

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

12. interfacesの各interfaceについて反復する：

    1. interfaceのインスタンスがオリジンに バインドされているものであり、かつoriginが 不透明なオリジンである場合、"SecurityError" DOMExceptionを伴って拒否された promiseを返す。

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

14. settingsのアクティブな資格情報型が typeを含む場合、 "NotAllowedError" DOMExceptionを伴って拒否された promiseを返す。

15. typeをsettingsのアクティブな資格情報型に追加する。

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

17. 以下の手順を並列に実行する：

    1. rを、origin、options、およびsameOriginWithAncestorsに対してinterfaces[0]の [[Create]](origin, options, sameOriginWithAncestors) 内部メソッドを実行した 結果とする。

       それが例外を送出した場合：

       1. eを送出された例外とする。

       2. globalのDOM 操作タスクソース上にタスクをキューに入れ、 以下のサブステップを実行する：

          1. eでpを拒否する。

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

    2. rがCredential またはnullである場合、pをrで解決し、 これらのサブステップを終了する。

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

    4. globalのDOM 操作タスクソース上にタスクをキューに入れ、 以下のサブステップを実行する：

       1. globalを与えてrをpromise 呼び出しした結果でpを解決する。

18. pに反応する：

    1. typeをsettingsのアクティブな資格情報型から削除する。

19. pを返す。

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

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

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

2. settingsの関連するグローバルオブジェクトの関連付けられた Documentが完全にアクティブでない場合、 "InvalidStateError" DOMExceptionを伴って拒否された promiseを返す。

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"イベントを発生させたHTMLFormElementから新しいPasswordCredentialを構築する：
      // これにより、"username"および"current-password"のautocomplete
      // 属性が付けられたフィールドの値が取り込まれる：
      var c = new PasswordCredential(e.target);

      // フォームのaction URLを取得し、その新しい資格情報オブジェクトを
      // FormDataオブジェクトとして渡す。レスポンスが成功を示す場合、ユーザーエージェントに通知し、
      // 今後使用するためにパスワードを保存するかどうかをユーザーに尋ねられるようにする：
      var opt = {
        method: 'POST',
        body: new FormData(e.target),
        credentials: 'include'  // Cookieを送信する。
      };
      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"イベントを発生させたHTMLFormElementから新しいPasswordCredentialを構築する：
    // これにより、"username"および"new-password"のautocomplete
    // 属性が付けられたフィールドの値が取り込まれる：
    var c = new PasswordCredential(e.target);

    // フォームのaction URLを取得し、その新しい資格情報オブジェクトを
    // FormDataオブジェクトとして渡す。レスポンスが成功を示す場合、ユーザーエージェントに通知し、
    // 今後使用するためにパスワードを保存するかどうかをユーザーに尋ねられるようにする：
    var opt = {
      method: 'POST',
      body: new FormData(e.target),
      credentials: 'include'  // Cookieを送信する。
    };
    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 オブジェクトは、 navigator.credentials.create() を介して、PasswordCredentialData 辞書を明示的に渡すか、または HTMLFormElementの 送信可能な要素の内容に基づいて作成できる。

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）、 および呼び出し元のコンテキストがその祖先と 同一オリジンである場合に限りtrueとなるブール値 （sameOriginWithAncestors）を指定して呼び出される。 このアルゴリズムは、 資格情報ストアから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）、および呼び出し元の コンテキストがその祖先と同一オリジンである場合に限りtrueとなるブール値 （sameOriginWithAncestors）を指定して呼び出される。 このアルゴリズムは、作成できる場合はPasswordCredential を返し、 それ以外の場合はnullを返す。CredentialCreationOptions 辞書は、HTMLFormElement またはPasswordCredentialDataのいずれかを保持するpasswordメンバーを 持たなければならない。 そのメンバーの値を使用して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）、および呼び出し元の コンテキストがその祖先と同一オリジンである場合に限りtrueとなるブール値 （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 （form）およびオリジン（origin）から、HTMLFormElementから PasswordCredentialを作成するには、以下の手順を実行する。

注：§ 3.1.2 サインイン後の確認および§ 3.1.3 パスワードの変更では、 意図された使用方法の例を 示している。

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

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

3. formDataを、formに対してFormData コンストラクターを 実行した結果とする。

4. elementsを、送信可能な要素のうち、そのフォーム所有者がformであるすべての要素を、ツリー 順に並べたリストとする。

5. newPasswordObservedをfalseとする。

6. elements内の各fieldについて、以下の手順を実行する：

   1. fieldが autocomplete 属性を持たない場合、次の fieldへ進む。

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

   3. formDataのhas() メソッドをnameに対して実行したときにfalseを返す場合、 次のfieldへ進む。

   4. fieldの autocomplete 属性の値に1つ以上の自動入力詳細トークン（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を、dataに対してPasswordCredentialDataから PasswordCredentialを作成するを実行した結果とする。それが例外をスローした場合、その 例外を再スローする。

8. 表明：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"] が真値でないなら、空集合を返す。

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自体の再設計なしにサポートできる拡張性を持つことを期待しています。

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