Merge branch 'main' into userinfo-sorted

.gitignore

@@ -1,3 +1,5 @@
 spec/index.html
 spec/fedcm.idl
+spec/login-status.html
+spec/login-status.idl
 .DS_Store

.pr-preview.json

@@ -4,4 +4,5 @@
     "params": {
         "force": 1
     }
+
 }

README.md

@@ -4,7 +4,7 @@ This is the repository for the W3C's FedID CG Federated Credentials Management A
 
 Explainer: [explainer.md](explainer.md)
 
-Work-in-progress specification: <https://fedidcg.github.io/FedCM/>
+Work-in-progress specification: <https://w3c-fedid.github.io/FedCM/>
 
 ## Introduction
 
@@ -21,7 +21,7 @@ the removal of third-party cookies on federated login. Historically this has
 relied on third-party cookies or navigational redirects in order to function
 as they were the primitives provided by the web.
 
-The [explainer](explainer.md) and [spec](https://fedidcg.github.io/FedCM)
+The [explainer](explainer.md) and [spec](https://w3c-fedid.github.io/FedCM)
 provide a potential API and the rational behind how that API was designed.
 
 ## Contributing
@@ -44,9 +44,9 @@ There are several ways to contribute to the Federated Credential Management API.
  * If you're an Identity Provider, there are two sides of the implementation that
    will be needed and any feedback on either side is appreciated.
 
-   1. The [Identity Provider API](https://fedidcg.github.io/FedCM/#idp-api) describes
+   1. The [Identity Provider API](https://w3c-fedid.github.io/FedCM/#idp-api) describes
       the manifest and API needed server side.
-   2. The [Browser API](https://fedidcg.github.io/FedCM/#browser-api) describes the JavaScript
+   2. The [Browser API](https://w3c-fedid.github.io/FedCM/#browser-api) describes the JavaScript
       interface to FedCM which will need to be utilized.
 
  * If you're a Relying Party (i.e. website) and would like to test the changes out
@@ -55,7 +55,7 @@ There are several ways to contribute to the Federated Credential Management API.
    JavaScript. (Until an IDP provides first party JavaScript to work with FedCM
    this integration will be tricker). You can also review the demo provided by the
    HOWTO and take a look at the
-   [Relying Party API](https://fedidcg.github.io/FedCM/#rp-api) to see what is needed
+   [Relying Party API](https://w3c-fedid.github.io/FedCM/#rp) to see what is needed
    on the RP side.
 
 ## Code of Conduct

explorations/HOWTO-chrome.md

@@ -333,3 +333,169 @@ IdP fails by either returning some network error or saying that the disconnectio
 was unsuccessful, or if the `account_id` is nowhere to be found, the browser will
 remove from local storage all of the federated accounts associated with the (RP,
 IDP).
+
+### Button Flow
+The button flow differs from the widget flow in several ways. The most significant
+difference is that the button flow requires a user gesture such as clicking on a
+sign-in button. This means that a user must be able to successfully sign in with a
+federated account using this flow. In contrast, the widget flow is an optimized
+flow that can reduce sign-in friction. This means that if the widget flow is
+unavailable, a user can still click a "Sign in with IdP" button to continue. See
+illustrative [mocks here](https://docs.google.com/presentation/d/1iURrPakaHgBfQ6mAefKijjxToiTTgBSPz1rtaV0od98/edit?usp=sharing).
+
+#### Button Mode API
+To use the Button Mode API:
+* Enable the experimental feature `FedCmButtonMode` in `chrome://flags`.
+* Make sure to invoke the API behind [transient user activation](https://html.spec.whatwg.org/multipage/interaction.html#transient-activation).
+* Invoke the API with the `mode` parameter like so:
+  ```js
+    return await navigator.credentials.get({
+        identity: {
+          providers: [{
+            configURL: "https://idp.example/config.json",
+            clientId: "123",
+            nonce: nonce
+          }],
+          mode: "button"
+        }
+    });
+  ```
+
+The browser will send a new parameter to the IdP representing the request type by including
+`mode=button` in the request sent to the ID assersion endpoint:
+```
+POST /fedcm_assertion_endpoint HTTP/1.1
+Host: idp.example
+Origin: https://rp.example/
+Content-Type: application/x-www-form-urlencoded
+Cookie: 0x23223
+Sec-Fetch-Dest: webidentity
+
+account_id=123&client_id=client1234&nonce=Ct60bD&disclosure_text_shown=true&is_auto_selected=false
+&mode=button
+```
+Note that we currently only include the new parameter in the button flow. Other flow
+types such as "widget" (name TBD) will be added when Chrome ships this feature.
+
+#### Use Other Account API
+This API allows users to use other accounts in the account chooser when, for example, IdPs
+support multiple accounts or replacing the existing account.
+
+To use the Use Other Account API:
+* Enable the experimental feature `FedCmUseOtherAccount` in `chrome://flags`.
+* IdP specifies the following in the FedCM config file:
+```
+{
+  "accounts_endpoint" : ...,
+  "modes: {
+    "button": {
+      "supports_use_other_account": true|false,
+    }
+  }
+}
+```
+
+### Continuation API
+This API lets the IdP request that the authorization flow should continue
+in a popup window that is controlled by the IdP. This can be used to request
+additional permission, to ask a user to confirm their account details, or
+for a variety of other use cases.
+
+To use this feature:
+* Enable the experimental feature `FedCmAuthz` in chrome://flags
+* Return a "continue_on" field with a URL instead of a token
+  from the ID assertion endpoint. For example:
+  ```js
+  {
+    "continue_on": "https://idp.example/finish_login?account_id=123"
+  }
+  ```
+* When the authorization flow finishes, call `IdentityProvider.resolve` to close the
+  popup and provide the token that will be passed to the RP:
+  ```js
+    IdentityProvider.resolve("this is the token");
+  ```
+* If the account ID has changed (for example, if the popup provided a "Switch
+  User" function), you can specify it in a second parameter:
+  ```js
+    IdentityProvider.resolve("this is the token", {accountId: "123"});
+  ```
+* If the user cancels the login flow, call `IdentityProvider.close` to close
+  the popup and reject the promise that was returned from `navigator.credentials.get`:
+  ```js
+    IdentityProvider.close();
+  ```
+
+### Parameters API
+This feature lets RPs specify additional key/value pairs that will get sent
+to the ID assertion endpoint.
+
+To use this feature:
+* Enable the experimental feature `FedCmAuthz` in chrome://flags
+* Add a `params` field to the `navigator.credentials.get` call:
+  ```js
+    navigator.credentials.get({
+        identity: {
+          providers: [{
+            configURL: "https://idp.example/config.json",
+            clientId: "123",
+            nonce: nonce,
+            params: {
+              "key": "value",
+              "anything_goes": "yes",
+              "really": "yes",
+              "scopes": "calendar.readonly",
+              "dpop": "something",
+              "moar": "sure",
+            }
+          }],
+        }
+    });
+  ```
+* These key/value pairs will be sent as-is in the ID assertion request:
+  `account_id=123&key=value&anything_goes=yes&really=yes&scopes=calendar.readonly&dpop=something&moar=sure&...`
+  
+
+### Multiple configURLs
+This feature lets you have multiple different config files under the same
+eTLD+1 as long as they all have the same accounts_endpoint. This can be
+useful to specify different branding or different ID assertion endpoints.
+
+To use this feature:
+* Enable the experimental feature `FedCmAuthz` in chrome://flags
+* Add the login_url and accounts_endpoint to the .well-known/web-identity
+  file:
+  ```js
+  {
+    "provider_urls": [
+      // keep this unchanged
+    ],
+    "accounts_endpoint": "https://fedcm.idp.example/accounts",
+    "login_url": "https://fedcm.idp.example/login.html"
+  }
+  ```
+
+### Account labels
+The account labels API lets IdPs give a list of labels to an account and
+lets different config files specify a filter for those labels.
+
+To use the API:
+* Enable the experimental feature `FedCmAuthz` in chrome://flags
+* Add a `labels` field to accounts in the account endpoint:
+  ```js
+  {
+    "name": "John Smith",
+    //...
+    "labels": ["label1"]
+  }
+  ```
+* Add the desired label to the config file:
+  ```js
+  {
+    "accounts_endpoint": "...",
+    // ...
+    "accounts": {
+      "include": "label1"
+    }
+  }
+  ```

explorations/README.md

@@ -13,7 +13,7 @@ active exploration into the problem space, potential end states, and possible
 solutions. These all serve the purpose of providing context, understanding and
 a shared idea of where we _could_ go. For a more specific document on what can
 be done right now, please see the
-[Federated Credential Management API](https://fedidcg.github.io/FedCM) proposal.
+[Federated Credential Management API](https://w3c-fedid.github.io/FedCM) proposal.
 
 This exploration has been broken into several sections.
 
@@ -22,7 +22,7 @@ This exploration has been broken into several sections.
    * What are some [related problems](related_problems.md)?
    * What has been tried [previously](prior.md)?
 1. Description of where we [should](proposal.md) be and accompanying
-   [FedCM API](https://fedidcg.github.io/FedCM) proposal.
+   [FedCM API](https://w3c-fedid.github.io/FedCM) proposal.
    * What [alternatives](alternatives_considered.md) have been explored?
 1. Potential [roadmap](roadmap.md) to the [proposal](proposal.md).
 

explorations/alternatives_considered.md

@@ -1,6 +1,6 @@
 # Alternatives Considered
 
-Now that we have a deep understanding of (a) the [problem](README.md) and (b) the [motivations](https://fedidcg.github.io/FedCM/#privacy-threat-model) and [topology](activation.md) of the parties involved, lets look at some **why not**s.
+Now that we have a deep understanding of (a) the [problem](README.md) and (b) the [motivations](https://w3c-fedid.github.io/FedCM/#privacy) and [topology](activation.md) of the parties involved, lets look at some **why not**s.
 
 ## The Status Quo
 

explorations/cookies.md

@@ -1,6 +1,6 @@
 # Cookies
 
-This is a **proposal** for a high level API to support identity federation under this [threat model](https://fedidcg.github.io/FedCM/#privacy-threat-model).
+This is a **proposal** for a high level API to support identity federation under this [threat model](https://w3c-fedid.github.io/FedCM/#privacy).
 
 It is widely known that browsers are either **already** blocking third party cookies or are planning to.
 
@@ -18,7 +18,7 @@ This is a proposal to preserve these operations in the absence of third party co
 
 Cross-site communication is used throughout the entire lifecycle of the user signing in to a RP with an IDP, beginning at signing-up a new user all the way through managing the sessions (e.g. signing in, signing out or renewing refresh tokens).
 
-From a [privacy threat model](https://fedidcg.github.io/FedCM/#privacy-threat-model) perspective, the design of this proposal is anchored on the observation that the most critical moment is when the identities between the RP and the IDP are joined for the very first time, namely when the user creates a new account in the RP using the identifiers from the IDP or when a user signs-in to an RP with an IDP for the first time in the browser: once the identities are joined, any arbitrary/uncontrolled cross-side communication can happen (with or without the browser's permission, e.g. via backchannel or cookie-less requests).
+From a [privacy threat model](https://w3c-fedid.github.io/FedCM/#privacy) perspective, the design of this proposal is anchored on the observation that the most critical moment is when the identities between the RP and the IDP are joined for the very first time, namely when the user creates a new account in the RP using the identifiers from the IDP or when a user signs-in to an RP with an IDP for the first time in the browser: once the identities are joined, any arbitrary/uncontrolled cross-side communication can happen (with or without the browser's permission, e.g. via backchannel or cookie-less requests).
 
 In this proposal, the browser:
 

explorations/debug-network-requests-chrome.md

@@ -0,0 +1,31 @@
+While the Chrome team is trying to integrate FedCM into devtools, we suggest developers to use the following tools to debug network requests.
+
+1. Open chrome://net-export from the URL bar. Select “Include raw bytes” and
+click “Start Logging to Disk”. Select a location to save the logs when prompted.
+<p align="center">
+     <img width="467" src="https://github.com/fedidcg/FedCM/blob/main/explorations/static/net-export/net-export-entry.png"/>
+</p>
+2. Open the page that calls the FedCM API. e.g. https://webid-fcm.glitch.me
+<p align="center">
+     <img width="467" src="https://github.com/fedidcg/FedCM/blob/main/explorations/static/net-export/fedcm-1.png"/>
+</p>
+3. Go through the FedCM flow to debug all network requests
+<p align="center">
+     <img width="467" src="https://github.com/fedidcg/FedCM/blob/main/explorations/static/net-export/fedcm-2.png"/>
+</p>
+4. Stop the logging on chrome://net-export
+<p align="center">
+     <img width="467" src="https://github.com/fedidcg/FedCM/blob/main/explorations/static/net-export/net-export-stop.png"/>
+</p>
+5. Load the logs into https://netlog-viewer.appspot.com/
+<p align="center">
+     <img width="467" src="https://github.com/fedidcg/FedCM/blob/main/explorations/static/net-export/netlog-viewer-entry.png"/>
+</p>
+6. Under `Events` from the left, filter the logs with `type:URL_REQUEST`
+<p align="center">
+     <img width="467" src="https://github.com/fedidcg/FedCM/blob/main/explorations/static/net-export/netlog-viewer-example.png"/>
+</p>
+7. The network requests that were sent to different endpoints can be viewed
+individually. They also include the response that the browser has received. If
+raw bytes are selected from step 1, the detailed response such as name, token
+string etc. will show up on the right.

explorations/directed_identifiers.md

@@ -21,7 +21,7 @@
 # Directed identifiers
 This document explores the ideas of [directed identifiers](glossary.md#directed-identifier) and [verifiably directed identifiers](glossary.md#verifiably-directed-identifier) in FedCM.
 
-Directed identifiers are included in the FedCM proposal as an attempt to mitigate [Relying Party tracking](README.md#the-rp-tracking-problem) of users by means of [identifier correlation](https://fedidcg.github.io/FedCM/#attack-scenarios-by-rp-cross-site-correlation). As traditional tracking mechanisms have become less accessible, a fallback method for following user activity across the web has been for web sites with account systems to correlate personal identifiers associated with each account. For example, all sites that require users to use email addresses as login identifiers can collude to uniquely identify a given user across all of those sites, and profile that user's full activity across them.
+Directed identifiers are included in the FedCM proposal as an attempt to mitigate [Relying Party tracking](README.md#the-rp-tracking-problem) of users by means of [identifier correlation](https://w3c-fedid.github.io/FedCM#attack-scenarios-by-rp-cross-site-correlation). As traditional tracking mechanisms have become less accessible, a fallback method for following user activity across the web has been for web sites with account systems to correlate personal identifiers associated with each account. For example, all sites that require users to use email addresses as login identifiers can collude to uniquely identify a given user across all of those sites, and profile that user's full activity across them.
 
 Conceptually, a directed identifer is a limited-scope identifier that has a one-way mapping from a user identifier that is known to an Identity Provider. The original identifier cannot practically be derived from the directed identifier by anyone other than the IdP or possibly the user.
 

explorations/glossary.md

@@ -86,7 +86,7 @@ References: [OIDC terminology](https://openid.net/specs/openid-connect-core-1_0.
 ### IDP tracking
 * _A privacy threat in which an [Identity Provider](#identity-provider-idp) is able to surveil or correlate user activity across the web._
 
-References: [FedCM Threat Model](https://fedidcg.github.io/FedCM/#attack-scenarios-by-idp)
+References: [FedCM Threat Model](https://w3c-fedid.github.io/FedCM/#idp-intrusion)
 
 
 ### Relying Party (RP)
@@ -106,7 +106,7 @@ References: [OIDC terminology](https://openid.net/specs/openid-connect-core-1_0.
 ### RP tracking
 * _A privacy threat in which a [Relying Party](#relying-party-rp) is able to surveil or correlate user activity across the web._
 
-References: [FedCM Threat Model](https://fedidcg.github.io/FedCM/#attack-scenarios-by-rp)
+References: [FedCM Threat Model](https://w3c-fedid.github.io/FedCM/#rp-fingerprinting)
 
 
 ### Standard claims

explorations/navigations.md

@@ -1,10 +1,10 @@
 # Navigations
 
-This is an **early exploration** of the design alternatives to address [bounce tracking](README.md#stage-2-bounce-tracking) under [this threat model](https://fedidcg.github.io/FedCM/#privacy-threat-model).
+This is an **early exploration** of the design alternatives to address [bounce tracking](README.md#stage-2-bounce-tracking) under [this threat model](https://w3cping.github.io/privacy-threat-model/).
 
 This section goes over the **what** and the **how**. It presuposes that you have read and started from:
 
-- The **why**: the [problem statement](problem.md) and the [motivations](https://fedidcg.github.io/FedCM/#privacy-threat-model) and the [topology](activation.md) of the parties involved.
+- The **why**: the [problem statement](problem.md) and the [motivations](https://w3cping.github.io/privacy-threat-model/) and the [topology](activation.md) of the parties involved.
 - The **why not**: the [alternatives considered](alternatives_considered.md) (e.g. the [prior art](prior.md), the [status quo](alternatives_considered.md#the-status-quo) and the [requestStorageAccess API](alternatives_considered.md#the-request-storage-access-api)).
 
 We'll then go over the [high-level overview](#high-level-design) and a breakdown into two smaller problems:
@@ -39,7 +39,7 @@ We'll go over each of these separately next.
 
 The consumer API is the Web Platform privacy-oriented API that relying parties call to request information from a specific identity provider, to be used in replacement of the current redirect/popup affordances that are currently used.
 
-From the perspective of [The Privacy Threat Model](https://fedidcg.github.io/FedCM/#privacy-threat-model), there are two notably distinct uses of federation:
+From the perspective of [The Privacy Threat Model](https://w3cping.github.io/privacy-threat-model/), there are two notably distinct uses of federation:
 
 * [signing-in](glossary.md#federated-sign-in) and
 * [authorization](glossary.md#authorization)
@@ -128,7 +128,7 @@ Now that we looked at the surface area introduced for relying parties, lets turn
 
 The purpose of the Provider API is to fulfill the invocation of [The Consumer API](#the-Consumer-api) by coordinating with the identity provider.
 
-From the perspective of [The Privacy Threat Model](https://fedidcg.github.io/FedCM/#privacy-threat-model), the Provider API has a much wider set of choices and trade-offs:
+From the perspective of [The Privacy Threat Model](https://w3cping.github.io/privacy-threat-model/), the Provider API has a much wider set of choices and trade-offs:
 
 1. Because of the [classification problem](README.md#the-classification-problem), we want to prevent a tracker from abusing this API by impersonating an IDP to track users.
 1. Because of the [RP tracking problem](README.md#the-rp-tracking-problem), we want to promote directed identifiers as much as we can.