Credential Management Level 1

1. Introduction

This section is not normative.

Signing into websites is more difficult than it should be. The user agent is in a unique position to improve the experience in a number of ways, and most modern user agents have recognized this by providing some measure of credential management natively in the browser. For example, users can save usernames and passwords for websites; those credentials are later autofilled into sign-in forms, albeit with varying degrees of success.

The autocomplete attribute offers a declarative mechanism by which websites can work with user agents to improve the latter’s ability to detect and fill sign-in forms by marking specific fields as "username" or "password", and user agents implement a wide variety of detection heuristics to work with websites which haven’t taken the time to provide this detail in markup.

While this combination of heuristic and declarative detection works relatively well, the status quo leaves some large gaps where detection is problematic. Sites with uncommon sign-in mechanisms (submitting credentials via XMLHttpRequest [XMLHTTPREQUEST], for instance) are difficult to reliably detect, as is the increasingly common case in which users wish to authenticate themselves using a federated identity provider. Allowing websites to more directly interact with the user agent’s credential manager would allow the credential manager to be more accurate on the one hand, and to assist users with federated sign-in on the other.

These use cases are explored in more detail in § 1.1 Use Cases and in Credential Management: Use Cases and Requirements; this specification attempts to address many of the requirements that document outlines by defining a Credential Manager API which a website can use to request credentials for a user, and to ask the user agent to persist credentials when a user signs in successfully.

Note: The API defined here is intentionally small and simple: it does not intend to provide authentication in and of itself, but is limited to providing an interface to the existing credential managers implemented by existing user agents. That functionality is valuable right now, without significant effort on the part of either vendors or authors. There’s certainly quite a bit more which could be done, of course. See § 9 Future Work for some thoughts we’ve punted for now, but which could be explored in future iterations of this API.

1.1. Use Cases

Modern user agents generally offer users the capability to save passwords when signing into a website, and likewise offer the capability to fill those passwords into sign-in forms fully- or semi-automatically when users return to a website. From the perspective of a website, this behavior is completely invisible: the website doesn’t know that passwords have been stored, and it isn’t notified that passwords have been filled. This is both good and bad. On the one hand, a user agent’s password manager works regardless of whether or not a site cooperates, which is excellent for users. On the other, the password managers' behaviors are a fragile and proprietary hodgepodge of heuristics meant to detect and fill sign-in forms, password change forms, etc.

A few problems with the status quo stand out as being particularly noteworthy:

• User agents have an incredibly difficult time helping users with federated identity providers. While detecting a username/password form submission is fairly straightforward, detecting sign-in via a third-party is quite difficult to reliably do well. It would be nice if a website could help the user agent understand the intent behind the redirects associated with a typical federated sign-in action.

• Likewise, user agents struggle to detect more esoteric sign-in mechanisms than simple username/password forms. Authors increasingly asynchronously sign users in via XMLHttpRequest or similar mechanisms in order to improve the experience and take more control over the presentation. This is good for users, but tough for user agents to integrate into their password managers. It would be nice if a website could help the user agent make sense of the sign-in mechanism they choose to use.

• Finally, changing passwords is less well-supported than it could be if the website explicitly informed the user agent that credentials had changed.

2. Core API

From a developer’s perspective, a credential is an object which allows a developer to make an authentication decision for a particular action. This section defines a generic and extensible Credential interface which serves as a base class for credentials defined in this and other documents, along with a set of APIs hanging off of navigator.credentials.* which enable developers to obtain them.

Various credential types are each represented to JavaScript as an interface which inherits, either directly or indirectly, from the Credential interface. This document defines two such interfaces, PasswordCredential and FederatedCredential. Other specifications, for example [WEBAUTHN], define other credential types.

A credential is effective for a particular origin if it is accepted as authentication on that origin. Even if a credential is effective at a particular point in time, the UA can’t assume that the same credential will be effective at any future time, for a couple reasons:

1. A password credential may stop being effective if the account holder changes their password.

2. A credential made from a token received over SMS is likely to only be effective for a single use.

Single-use credentials are generated by a credential source, which could be a private key, access to a federated account, the ability to receive SMS messages at a particular phone number, or something else. Credential sources are not exposed to Javascript or explicitly represented in this specification. To unify the model, we consider a password to be a credential source on its own, which is simply copied to create password credentials.

Even though the UA can’t assume that an effective credential will still be effective if used a second time, or that a credential source that has generated an effective credential will be able to generate a second effective credential in the future, the second is more likely than the first. By recording (with store()) which credentials have been effective in the past, the UA has a better chance of offering effective credential sources to the user in the future.

2.1. Infrastructure

User agents MUST internally provide a credential store, which is a vendor-specific, opaque storage mechanism to record which credentials have been effective. It offers the following capabilities for credential access and persistence:

1. Store a credential for later retrieval. This accepts a credential, and inserts it into the credential store.

2. Retrieve a list of credentials. This accepts an arbitrary filter, and returns a set of credentials that match the filter.

3. Modify a credential. This accepts a credential, and overwrites the state of an existing credential in the credential store.

Additionally, the credential store should maintain a prevent silent access flag for origins (which is set to true unless otherwise specified). An origin requires user mediation if its flag is set to true.

Note: The importance of user mediation is discussed in more detail in § 5 User Mediation.

Note: The credential store is an internal implementation detail of a user agent’s implementation of the API specified in this document, and is not exposed to the web directly. More capabilities may be specified by other documents in support of specific credential types.

This document depends on the Infra Standard for a number of foundational concepts used in its algorithms and prose [INFRA].

Each environment settings object has an associated active credential types, a set which is initially empty.

2.1.1. Infrastructure Algorithms

2.1.1.1. Same-Origin with its Ancestors

An environment settings object (settings) is same-origin with its ancestors if the following algorithm returns true:

1. If settings’s relevant global object has no associated Document, return false.

2. Let document be settings’ relevant global object's associated Document.

3. If document has no browsing context, return false.

4. Let origin be settings’ origin.

5. Let navigable be document’s node navigable.

6. While navigable has a non-null parent:

   1. Set navigable to navigable’s parent.

   2. If navigable’s active document's origin is not same origin with origin, return false.

7. Return true.

2.1.2. Credential Type Registry

This registry maps credential types (i.e., [[type]] values) to various values associated with a given credential type. For example: the Options Member Identifier (formally, a dictionary member identifier) used in CredentialCreationOptions and CredentialRequestOptions (i.e., "options dictionaries") by their specifications.

Note: This registry is used by the relevant credential interface objects algorithm.

2.1.2.1. Registration Entry Requirements and Update Process

• Each credential type must be unique amongst the set of credential types.

• Each registry entry must state the dictionary member identifier (known as the Options Member Identifier in the registry) used in the credential specification’s extentions of CredentialCreationOptions and CredentialRequestOptions.

• Each registry entry must state the Appropriate Interface Object identifier for the credential type.

• Each registry entry must state the Get Permissions Policy permission used when executing Request a Credential for a credential type, or null if no permissions policy is specified.

• Each registry entry must state the Create Permissions Policy permission used when executing Create a Credential for a credential type, or null if no permissions policy is specified.

• Each registry entry must include a link that references a publicly available specification defining the credential type and the dictionary member identifier.

• Each registry entry’s specification must include the requestor’s contact information.

An update to this registry is an addition, change or deletion of a credential type's registry entry. Any person can request an update to this registry by pull requests to the webappsec-credential-management repository. The Web Applications Security Working Group will place it on an upcoming meeting agenda and notify the requestor. Consideration and disposition of the request is by consensus of the W3C Web Applications Security Working Group. The Chair will then notify the requestor of the outcome and update the registry accordingly.

2.2. The Credential Interface

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

Talk to Tobie/Dominic about the interface object bits, here and in § 2.5.1 Request a Credential, etc. I’m not sure I’ve gotten the terminology right. interface prototype object, maybe?

Some Credential objects are origin bound: these contain an internal slot named [[origin]], which stores the origin for which the Credential may be effective.

2.2.1. Credential Internal Methods

The Credential interface object features several internal methods facilitating retrieval and storage of Credential objects, with default "no-op" implementations as specified in this section, below.

Unless otherwise specified, each interface object created for interfaces which inherit from Credential MUST provide implementations for at least one of these internal methods, overriding Credential's default implementations, as appropriate for the credential type. E.g., § 3.2 The PasswordCredential Interface, § 4.1 The FederatedCredential Interface, and [WEBAUTHN].

2.2.1.1. [[CollectFromCredentialStore]] internal method

Credential's default implementation of [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors):

1. Return an empty set.

2.2.1.2. [[DiscoverFromExternalSource]] internal method

Credential's default implementation of [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors):

1. Return null.

2.2.1.3. [[Store]] internal method

Credential's default implementation of [[Store]](credential, sameOriginWithAncestors):

1. Throw a NotSupportedError.

2.2.1.4. [[Create]] internal method

• creates a Credential, or

• does not create a credential and returns null, or

• throws an error if creation fails due to exceptional situations (for example, incorrect options could produce a TypeError).

When creating a Credential, it will return an algorithm that takes a global object and returns an interface object inheriting from Credential. This algorithm MUST be invoked from a task.

Note: This algorithm’s steps are defined on a per-credential type basis.

Credential's default implementation of [[Create]](origin, options, sameOriginWithAncestors):

1. Return null.

2.2.2. CredentialUserData Mixin

Some Credential objects contain data which aims to give users a human-readable disambiguation mechanism in the credential chooser by providing a friendly name and icon:

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

2.3. navigator.credentials

Developers retrieve Credentials and interact with the user agent’s credential store via methods exposed on the CredentialsContainer interface, which hangs off the Navigator object as navigator.credentials.

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

The credentials attribute MUST return the CredentialsContainer associated with the active document's browsing context.

Note: As discussed in § 6.3 Insecure Sites, the credential management API is exposed only in Secure Contexts.

[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. The CredentialRequestOptions Dictionary

In order to retrieve a Credential via get(), the caller specifies a few parameters in a CredentialRequestOptions object.

Note: The CredentialRequestOptions dictionary is an extension point. If and when new types of credentials are introduced that require options, their dictionary types will be added to the dictionary so they can be passed into the request. See § 8.2 Extension Points.

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

2.3.2. Mediation Requirements

When making a request via get(options) or create(options), developers can set a case-by-case requirement for user mediation by choosing the appropriate CredentialMediationRequirement enum value.

Note: The § 5 User Mediation section gives more detail on the concept in general, and its implications on how the user agent deals with individual requests for a given origin).

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

2.3.2.1. Examples

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. The CredentialCreationOptions Dictionary

In order to create a Credential via create(), the caller specifies a few parameters in a CredentialCreationOptions object.

Note: The CredentialCreationOptions dictionary is an extension point. If and when new types of credentials are introduced, they will add to the dictionary so they can be passed into the creation method. See § 8.2 Extension Points, and the extensions introduced in this document: § 3.2 The PasswordCredential Interface and § 4.1 The FederatedCredential Interface.

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

2.5. Algorithms

2.5.1. Request a Credential

The Request a Credential algorithm accepts a CredentialRequestOptions (options), and returns a Promise that resolves with a Credential if one can be unambigiously obtained, or with null if not.

1. Let settings be the current settings object.

2. Assert: settings is a secure context.

3. Let document be settings’s relevant global object's associated Document.

4. If document is not fully active, then return a promise rejected with an "InvalidStateError" DOMException.

5. If options.signal is aborted, then return a promise rejected with options.signal’s abort reason.

6. Let interfaces be options’s relevant credential interface objects.

7. If interfaces is empty, then returna promise rejected with a "NotSupportedError" DOMException.

8. For each interface of interfaces:

   1. If options.mediation is conditional and interface does not support conditional user mediation, return a promise rejected with a "TypeError" DOMException.

   2. If settings’ active credential types contains interface’s [[type]], return a promise rejected with a "NotAllowedError" DOMException.

   3. Append interface’s [[type]] to settings’ active credential types.

9. Let origin be settings’ origin.

10. Let sameOriginWithAncestors be true if settings is same-origin with its ancestors, and false otherwise.

11. For each interface in options’ relevant credential interface objects:

    1. Let permission be the interface’s [[type]] Get Permissions Policy.

    2. If permission is null, continue.

    3. If document is not allowed to use permission, return a promise rejected with a "NotAllowedError" DOMException.

12. Let p be a new promise.

13. Run the following steps in parallel:

    1. Let credentials be the result of collecting Credentials from the credential store, given origin, options, and sameOriginWithAncestors.

    2. If credentials is an exception, reject p with credentials.

    3. If all of the following statements are true, resolve p with credentials[0] and skip the remaining steps:

       1. credentials’ size is 1

       2. origin does not require user mediation

       3. options is matchable a priori.

       4. options.mediation is not "required".

       5. options.mediation is not "conditional".

       This might be the wrong model. It would be nice to support a site that wished to accept either username/passwords or webauthn-style credentials without forcing a chooser for those users who use the former, and who wish to remain signed in.

    4. If options’ mediation is "silent", resolve p with null, and skip the remaining steps.

    5. Let result be the result of asking the user to choose a Credential, given options and credentials.

    6. If result is an interface object:

       1. Set result to the result of executing result’s [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors), given origin, options, and sameOriginWithAncestors.

          If that threw an exception:

          1. Let e be the thrown exception.

          2. Queue a task on global’s DOM manipulation task source to run the following substeps:

             1. Reject p with e.

          3. Terminate these substeps.

    7. Assert: result is null, or a Credential.

    8. If result is a Credential, resolve p with result.

    9. If result is null and options.mediation is not conditional, resolve p with result.

       Note: if options.mediation is conditional and a null credential is discovered, promise p is not resolved.

14. React to p:

    1. For each interface in interfaces:

       1. Remove interface’s [[type]] from settings’ active credential types.

15. Return p.

2.5.2. Collect Credentials from the credential store

Given an origin (origin), a CredentialRequestOptions (options), and a boolean which is true if and only if the calling context is same-origin with its ancestors (sameOriginWithAncestors), the user agent may collect Credentials from the credential store, returning a set of Credential objects stored by the user agent locally that match options’ filter. If no such Credential objects are known, the returned set will be empty:

1. Let possible matches be an empty set.

2. For each interface in options’ relevant credential interface objects:

   1. Let r be the result of executing interface’s [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) internal method on origin, options, and sameOriginWithAncestors. If that threw an exception, rethrow that exception.

   2. Assert: r is a list of interface objects.

   3. For each c in r:

      1. Append c to possible matches.

3. Return possible matches.

2.5.3. Store a Credential

The Store a Credential algorithm accepts a Credential (credential), and returns a Promise which resolves once the object is persisted to the credential store.

1. Let settings be the current settings object.

2. Assert: settings is a secure context.

3. If settings’s relevant global object's associated Document is not fully active, then return a promise rejected with an "InvalidStateError" DOMException.

4. Let sameOriginWithAncestors be true if the current settings object is same-origin with its ancestors, and false otherwise.

5. Let p be a new promise.

6. If settings’ active credential types contains credential’s [[type]], return a promise rejected with a "NotAllowedError" DOMException.

7. Append credential’s [[type]] to settings’ active credential types.

8. Run the following steps in parallel:

   1. Execute credential’s interface object's [[Store]](credential, sameOriginWithAncestors) internal method on credential and sameOriginWithAncestors.

      If that threw an exception:

      1. Let e be the thrown exception.

      2. Queue a task on global’s DOM manipulation task source to run the following substeps:

         1. Reject p with e.

      Otherwise, resolve p with undefined.

9. React to p:

   1. Remove credential’s [[type]] from settings’ active credential types.

10. Return p.

2.5.4. Create a Credential

The Create a Credential algorithm accepts a CredentialCreationOptions (options), and returns a Promise which resolves with a Credential if one can be created using the options provided, or null if no Credential can be created. In exceptional circumstances, the Promise may reject with an appropriate exception:

1. Let settings be the current settings object.

2. Assert: settings is a secure context.

3. Let global be settings’ global object.

4. Let document be the relevant global object's associated Document.

5. If document is not fully active, then return a promise rejected with an "InvalidStateError" DOMException.

6. Let sameOriginWithAncestors be true if the current settings object is same-origin with its ancestors, and false otherwise.

7. Let interfaces be the set of options’ relevant credential interface objects.

8. Return a promise rejected with NotSupportedError if any of the following statements are true:

   1. global does not have an associated Document.

   2. interfaces’ size is greater than 1.

      Note: It may be reasonable at some point in the future to loosen this restriction, and allow the user agent to help the user choose among one of many potential credential types in order to support a "sign-up" use case. For the moment, though, we’re punting on that by restricting the dictionary to a single entry.

9. For each interface in interfaces:

   1. Let permission be the interface’s [[type]] Create Permissions Policy.

   2. If permission is null, continue.

   3. If document is not allowed to use permission, return a promise rejected with a "NotAllowedError" DOMException.

10. If options.signal is aborted, then return a promise rejected with options.signal’s abort reason.

11. Let type be interfaces[0]'s [[type]].

12. If settings’ active credential types contains type, return a promise rejected with a "NotAllowedError" DOMException.

13. Append type to settings’ active credential types.

14. Let origin be settings’s origin.

15. Let p be a new promise.

16. Run the following steps in parallel:

    1. Let r be the result of executing interfaces[0]'s [[Create]](origin, options, sameOriginWithAncestors) internal method on origin, options, and sameOriginWithAncestors.

       If that threw an exception:

       1. Let e be the thrown exception.

       2. Queue a task on global’s DOM manipulation task source to run the following substeps:

          1. Reject p with e.

       3. Terminate these substeps.

    2. If r is a Credential or null, resolve p with r, and terminate these substeps.

    3. Assert: r is an algorithm (as defined in § 2.2.1.4 [[Create]] internal method).

    4. Queue a task on global’s DOM manipulation task source to run the following substeps:

       1. Resolve p with the result of promise-calling r given global.

17. React to p:

    1. Remove type from settings’ active credential types.

18. Return p.

2.5.5. Prevent Silent Access

The Prevent Silent Access algorithm accepts an environment settings object (settings), and returns a Promise which resolves once the prevent silent access flag is persisted to the credential store.

1. Let origin be settings’ origin.

2. If settings’s relevant global object's associated Document is not fully active, then return a promise rejected with an "InvalidStateError" DOMException.

3. Let p be a new promise.

4. Run the following seps in parallel:

   1. Set origin’s prevent silent access flag in the credential store.

   2. Resolve p with undefined.

5. Return p.

3. Password Credentials

For good or for ill, many websites rely on username/password pairs as an authentication mechanism. The PasswordCredential interface is a credential meant to enable this use case, storing both a username and password, as well as metadata that can help a user choose the right account from within a credential chooser.

3.1. Examples

3.1.1. Password-based Sign-in

navigator.credentials
  .get({ 'password': true })
  .then(credential => {
    if (!credential) {
      // The user either doesn’t have credentials for this site, or
      // refused to share them. Insert some code here to fall back to
      // a basic login form.
      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'  // Send cookies.
      };
      fetch('https://example.com/loginEndpoint', opt)
        .then(function (response) {
          if (/* |response| indicates a successful login */) {
            // Record that the credential was effective. See note below.
            navigator.credentials.store(credential);
            // Notify the user that sign-in succeeded! Do amazing, signed-in things!
            // Maybe navigate to a landing page via location.href =
            // '/signed-in-experience'?
          } else {
            // Insert some code here to fall back to a basic login form.
          }
        });
    }
  });

navigator.credentials
  .get({ 'password': true })
  .then(credential => {
    if (!credential) {
      return; // as above...
    }
    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();
    }
  });

Note: The credential chooser presented by the user agent could allow the user to choose credentials that aren’t actually stored for the current origin. For instance, it might offer up credentials from https://m.example.com when signing into https://www.example.com (as described in § 6.1 Cross-domain credential access), or it might allow a user to create a new credential on the fly. Developers can deal gracefully with this uncertainty by calling store() every time credentials are successfully used, even right after credentials have been retrieved from get(): if the credentials aren’t yet stored for the origin, the user will be given the opportunity to do so. If they are stored, the user won’t be prompted.

3.1.2. Post-sign-in Confirmation

To ensure that users are offered to store new credentials after a successful sign-in, they can to be passed to store().

<form action="https://example.com/login" method="POST" id="theForm">
  <label for="username">Username</label>
  <input type="text" id="username" name="username" autocomplete="username">
  <label for="password">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();

      // Construct a new PasswordCredential from the HTMLFormElement
      // that fired the "submit" event: this will suck up the values of the fields
      // labeled with "username" and "current-password" autocomplete
      // attributes:
      var c = new PasswordCredential(e.target);

      // Fetch the form’s action URL, passing that new credential object in
      // as a FormData object. If the response indicates success, tell the user agent
      // so it can ask the user to store the password for future use:
      var opt = {
        method: 'POST',
        body: new FormData(e.target),
        credentials: 'include'  // Send cookies.
      };
      fetch(e.target.action, opt).then(r => {
        if (/* |r| is a "successful" Response */)
          navigator.credentials.store(c);
      });
    }
});

3.1.3. Change Password

This same storage mechanism can be reused for "password change" with no modifications: if the user changes their credentials, the website can notify the user agent that they’ve successfully signed in with new credentials. The user agent can then update the credentials it stores:

<form action="https://example.com/changePassword" method="POST" id="theForm">
  <input type="hidden" name="username" autocomplete="username" value="user">
  <label for="password">New 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();

    // Construct a new PasswordCredential from the HTMLFormElement
    // that fired the "submit" event: this will suck up the values of the fields
    // labeled with "username" and "new-password" autocomplete
    // attributes:
    var c = new PasswordCredential(e.target);

    // Fetch the form’s action URL, passing that new credential object in
    // as a FormData object. If the response indicates success, tell the user agent
    // so it can ask the user to store the password for future use:
    var opt = {
      method: 'POST',
      body: new FormData(e.target),
      credentials: 'include'  // Send cookies.
    };
    fetch(e.target.action, opt).then(r => {
      if (/* |r| is a "successful" Response */)
        navigator.credentials.store(c);
    });
  }
});

3.2. The PasswordCredential Interface

[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 objects can be created via navigator.credentials.create() either explicitly by passing in a PasswordCredentialData dictionary, or based on the contents of an HTMLFormElement's submittable elements.

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

typedef (PasswordCredentialData or HTMLFormElement) PasswordCredentialInit;

partial dictionary CredentialCreationOptions {
  PasswordCredentialInit password;
};

PasswordCredential objects are origin bound.

PasswordCredential's interface object inherits Credential's implementation of [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors), and defines its own implementation of [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors), [[Create]](origin, options, sameOriginWithAncestors), and [[Store]](credential, sameOriginWithAncestors).

3.3. Algorithms

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

[[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) is called with an origin (origin), a CredentialRequestOptions (options), and a boolean which is true if and only if the calling context is same-origin with its ancestors (sameOriginWithAncestors). The algorithm returns a set of Credential objects from the credential store. If no matching Credential objects are available, the returned set will be empty.

The algorithm will throw a NotAllowedError if sameOriginWithAncestors is not true.

1. Assert: options["password"] exists.

2. If sameOriginWithAncestors is false, throw a "NotAllowedError" DOMException.

   Note: This restriction aims to address the concern raised in § 6.4 Origin Confusion.

3. Return the empty set if options["password"] is not true.

4. Return the result of retrieving credentials from the credential store that match the following filter:

   1. The credential is a PasswordCredential

   2. The credential’s [[origin]] is the same origin as origin.

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

[[Create]](origin, options, sameOriginWithAncestors) is called with an origin (origin), a CredentialCreationOptions (options), and a boolean which is true if and only if the calling context is same-origin with its ancestors (sameOriginWithAncestors). The algorithm returns a PasswordCredential if one can be created, null otherwise. The CredentialCreationOptions dictionary must have a password member which holds either an HTMLFormElement or a PasswordCredentialData. If that member’s value cannot be used to create a PasswordCredential, this algorithm will throw a TypeError exception.

1. Assert: options["password"] exists, and sameOriginWithAncestors is unused.

2. If options["password"] is an HTMLFormElement, return the result of executing Create a PasswordCredential from an HTMLFormElement given options["password"] and origin. Rethrow any exceptions.

3. If options["password"] is a PasswordCredentialData, return the result of executing Create a PasswordCredential from PasswordCredentialData given options["password"]. Rethrow any exceptions.

4. Throw a TypeError exception.

3.3.3. PasswordCredential’s [[Store]](credential, sameOriginWithAncestors)

[[Store]](credential, sameOriginWithAncestors) is called with a PasswordCredential (credential), and a boolean which is true if and only if the calling context is same-origin with its ancestors (sameOriginWithAncestors). The algorithm returns undefined once credential is persisted to the credential store.

The algorithm will return a NotAllowedError if sameOriginWithAncestors is not true.

1. Throw a "NotAllowedError" DOMException without altering the user agent’s credential store if sameOriginWithAncestors is false.

   Note: This restriction aims to address the concern raised in § 6.4 Origin Confusion.

2. If the user agent’s credential store contains a PasswordCredential (stored) whose id attribute is credential’s id and whose [[origin]] slot is the same origin as credential’s [[origin]], then:

   1. If the user grants permission to update credentials (as discussed when defining user mediation), then:

      1. Set stored’s password to credential’s password.

      2. Set stored’s name to credential’s name.

      3. Set stored’s iconURL to credential’s iconURL.

   Otherwise, if the user grants permission to store credentials (as discussed when defining user mediation, then:

   1. Store a PasswordCredential in the credential store with the following properties:

      id

      credential’s id

      name,

      credential’s name

      iconURL

      credential’s iconURL

      [[origin]]

      credential’s [[origin]]

      password

      credential’s password

3.3.4. Create a PasswordCredential from an HTMLFormElement

To Create a PasswordCredential from an HTMLFormElement, given an HTMLFormElement (form) and an origin (origin), run these steps.

Note: § 3.1.2 Post-sign-in Confirmation and § 3.1.3 Change Password provide examples of the intended usage.

1. Let data be a new PasswordCredentialData dictionary.

2. Set data’s origin member’s value to origin’s value.

3. Let formData be the result of executing the FormData constructor on form.

4. Let elements be a list of all the submittable elements whose form owner is form, in tree order.

5. Let newPasswordObserved be false.

6. For each field in elements, run the following steps:

   1. If field does not have an autocomplete attribute, then skip to the next field.

   2. Let name be the value of field’s name attribute.

   3. If formData’s has() method returns false when executed on name, then skip to the next field.

   4. If field’s autocomplete attribute’s value contains one or more autofill detail tokens (tokens), then:

      1. For each token in tokens:

         1. If token is an ASCII case-insensitive match for one of the following strings, run the associated steps:

            "new-password"

            Set data’s password member’s value to the result of executing formData’s get() method on name, and newPasswordObserved to true.

            "current-password"

            If newPasswordObserved is false, set data’s password member’s value to the result of executing formData’s