chore: update fedcm links (#650)

* chore: update fedcm links * update more links * Update explorations/alternatives_considered.md Co-authored-by: Sam Goto <[email protected]> * Update explorations/cookies.md Co-authored-by: Sam Goto <[email protected]> * Update cookies.md --------- Co-authored-by: Sam Goto <[email protected]>
w3c-fedid · Sep 16, 2024 · ab072de · ab072de
1 parent f4e2a98
commit ab072de
Show file tree

Hide file tree

Showing 9 changed files with 21 additions and 21 deletions.
diff --git a/README.md b/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

diff --git a/explorations/README.md b/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).
 

diff --git a/explorations/alternatives_considered.md b/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
 

diff --git a/explorations/cookies.md b/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:
 

diff --git a/explorations/directed_identifiers.md b/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.
 

diff --git a/explorations/glossary.md b/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

diff --git a/explorations/navigations.md b/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.

diff --git a/explorations/proposal.md b/explorations/proposal.md
@@ -127,7 +127,7 @@ Notably, for cases where the IDP controls the deployment of the JavaScript runni
 ```javascript
 // This is just a possible starting point, largely TBD.
 //
-// Note, this historical, see https://fedidcg.github.io/FedCM for the current API.
+// Note, this historical, see https://w3c-fedid.github.io/FedCM for the current API.
 //
 let {idToken} = await navigator.credentials.get({
   provider: 'https://accounts.example.com',
@@ -151,7 +151,7 @@ In this formulation, the triggering of the API works similarly as before, but th
 ```javascript
 // This is just a possible starting point, largely TBD.
 //
-// Note, this historical, see https://fedidcg.github.io/FedCM for the current API.
+// Note, this historical, see https://w3c-fedid.github.io/FedCM for the current API.
 //
 let {idToken} = await navigator.credentials.get({
   provider: 'https://accounts.example.com',

diff --git a/privacy_questionnaire.md b/privacy_questionnaire.md
@@ -107,8 +107,8 @@ resulting from browsing in incognito mode should be cleared once the user ends t
 
 ### 15. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
 
-Security section is work in progress: https://fedidcg.github.io/FedCM/#security Privacy is discussed
-more in depth: https://fedidcg.github.io/FedCM/#privacy 
+Security section is work in progress: https://w3c-fedid.github.io/FedCM/#security Privacy is discussed
+more in depth: https://w3c-fedid.github.io/FedCM#privacy 
 
 ### 16. Do features in your specification enable origins to downgrade default security protections?