認証情報管理レベル1

1. はじめに

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

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

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

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

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

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

1.1. ユースケース

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

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

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

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

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

2. コアAPI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   1. navigableをnavigableの親にする。

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

7. trueを返す。

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

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

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

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

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

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

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

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

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

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

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

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

2.2. Credentialインターフェース

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

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モード欄にはデフォルト値がありません。指定されない場合、[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) メソッドは、ユーザーエージェントの挙動を指定するために CredentialMediationRequirement のみを考慮しなければなりません。

注: これにより呼び出し元は、ユーザー仲介が発生する場合に、利用可能な異なる形態のユーザー仲介を区別できます。 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が完全にアクティブでなければ、"InvalidStateError" DOMException でrejectされるプロミスを返す。

5. もし options.signal が中断済みなら、その abort reasonでrejectされるプロミスを返す。

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

7. もしinterfacesが 空 なら、"NotSupportedError" DOMException でrejectされるプロミスを返す。

8. 各 interface について：

   1. もし options.mediation が conditional かつ interface が conditional のユーザー仲介 をサポートしないなら、"TypeError" DOMException でrejectされるプロミスを返す。

   2. もし options.uiMode が immediate かつ interface が immediate のユーザー仲介 をサポートしないなら、"TypeError" DOMException でrejectされるプロミスを返す。

   3. もし settings の アクティブ資格情報タイプ が interface の [[type]] を含んでいる場合、"NotAllowedError" DOMException でrejectされるプロミスを返す。

   4. set append操作でinterfaceの[[type]] をsettingsのアクティブ資格情報タイプに追加する。

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

10. sameOriginWithAncestors を、settings が祖先と同一オリジンの場合はtrue、そうでなければfalseとする。

11. options の関連資格情報インターフェースオブジェクトごとに：

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

    2. permission が null なら継続。

    3. document が 未使用許可されていない permission なら、"NotAllowedError" DOMException でrejectされるプロミスを返す。

12. p を 新しいプロミスとする。

13. 次の手順を並列で実行：

    1. credentials を、認証ストアから資格情報を収集した結果（origin、options、sameOriginWithAncestorsを渡す）とする。

    2. もし credentials が 例外なら、reject 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" であれば、 resolve p に null を指定し、以降の手順をスキップ。

    5. result を ユーザーに資格情報の選択を促す操作（optionsと credentialsを渡す）の結果とする。

    6. もしresultがインターフェースオブジェクトであれば：

       1. resultをresultの[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 実行結果（origin、options、sameOriginWithAncestorsを渡す）に置き換える。

          それが例外を投げた場合：

          1. 投げられた例外をeとする。

          2. タスクキューへglobalのDOM操作タスクソース で下記サブステップを実行：

             1. reject p に e を指定。

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

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

    8. もし result が Credential なら、resolve p に result を指定。

    9. もし result が null かつ、options.mediation が conditional でないなら、resolve p に result を指定。

       注: options.mediation が conditional で資格情報nullが発見された場合、プロミスpはresolveされません。

14. プロミス解決時に:

    1. 各 interface について：

       1. remove 操作で interface の [[type]] を settings の アクティブ資格情報タイプから除外。

15. 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 で rejectされるプロミスを返す。

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

5. p を 新しいプロミス とする。

6. もし settings の アクティブ資格情報タイプ が credential の [[type]] を 含んでいる場合、 "NotAllowedError" DOMException で rejectされるプロミスを返す。

7. set append 操作で、credential の [[type]] を settings の アクティブ資格情報タイプ に追加する。

8. 以下の手順を 並列で実行：

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

      それが例外を投げた場合：

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

      2. タスクキュー で global の DOM操作タスクソース に基づき、次のサブステップを実行：

         1. reject p に e を指定する。

      そうでなければ resolve p に undefined を指定する。

9. プロミス成立時：

   1. remove 操作で 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が完全にアクティブでなければ、 "InvalidStateError" DOMException でrejectされるプロミスを返す。

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

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

8. 下記いずれかが成り立てば、NotSupportedErrorでrejectされたプロミスを返す：

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

   2. interfacesの要素数が1より大きい。

      注: 将来的にこの制約を緩和して、ユーザーエージェントが複数の資格情報タイプからユーザーに選ばせ「サインアップ」用途を支援することもありえる。現時点では辞書は単一項目に制限されている。

9. interfacesの各interfaceについて：

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

   2. permissionがnullなら続行。

   3. もしdocumentが未allowed to use permissionならば、 "NotAllowedError" DOMException でrejectされたプロミスを返す。

10. options.signal が中断済みであれば、その abort reasonでrejectされたプロミスを返す。

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

12. もしsettingsのアクティブ資格情報タイプがtypeを含んでいれば、 "NotAllowedError" DOMException でrejectされたプロミスを返す。

13. set append操作でtypeをsettingsの アクティブ資格情報タイプに追加する。

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

15. p を新しいプロミスとする。

16. 次の手順を並列で実行：

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

       それが例外を投げた場合：

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

       2. タスクキューでglobalのDOM操作タスクソース上で 次のサブステップを実行：

          1. reject p に e を指定。

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

    2. もしrがCredential または null であれば、resolve p に r を渡して手順終了。

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

    4. タスクキューでglobalのDOM操作タスクソース上で以下のサブステップを実行：

       1. resolve p に、プロミス呼び出しで r を global に与えて実行した結果を渡す。

17. プロミス成立時に：

    1. remove操作でtypeをsettingsの アクティブ資格情報タイプから除外。

18. p を返す。

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

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

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

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

3. pを新しいプロミスとする。

4. 以下の手順を並列で実行：

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

   2. resolve 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();
    }
  });

注: ユーザーエージェントが表示する認証情報選択UIでは、 現オリジン用に保存されていない認証情報もユーザーが選べる場合があります。 例えば 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/ で利用可能にすることは、 開発者に安全な通信への移行を促す観点で許容されますが、その逆は危険です。

2. ユーザーエージェントは認証情報の実質的なスコープを決定するためにPublic Suffix List [PSL]を使ってもよい（MAY）。 すなわち認証情報の[[origin]] の登録可能ドメインと、 get() を呼び出したオリジンで比較できます。 たとえば https://admin.example.com/ や https://example.com/ で保存した認証情報は、 https://www.example.com/ から get() を呼び出した際にもユーザーに提示でき、逆も可能です。

3. 認証情報のオリジンが呼び出し元のオリジンと正確に一致しない場合、 ユーザー仲介 なしでその認証情報を get() 応答として返してはなりません（MUST NOT）。 つまり、 https://example.com の Credential が直接 https://www.example.com へ返されることはありませんが、 認証情報選択UI経由でユーザーに提示することは可能です。

6.2. クレデンシャル漏洩

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

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

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

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

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

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

6.3. 安全でないサイト

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

6.4. オリジン混同

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

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

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

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

6.5. サインアウト

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

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

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

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

7.1. タイミング攻撃

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

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

7.2. 選択UIの漏洩

ユーザーエージェントの認証情報選択UIがオリジン提供の画像（例えば Credential がサイトのファビコンを表示する場合など）を表示する場合、 これら画像のリクエストは、選択UIの表示と直接結び付けてはなりません（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自体の再設計なしにサポートできる拡張性を持つことを期待しています。

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