Consider a domain which is reorganizing its endpoints. It wants to move the accounts endpoint from /accounts to /auth/fedcm/v1.0/accounts. Today, such a move effectively requires a maintenance window.
The core problem is keeping two files (config file and well known file) in sync. A web service might consist of 100 virtual machines, each of which has its own copy of each file. It takes a (small) time window to update all the files. Because a user browser hits a random service virtual machine, it can hit an updated virtual machine for one file and an un-updated virtual machine for the other file. Additionally, even if all 100 machines could update simultaneously, the browser cannot make HTTP requests simultaneously - if the file is update at 12:00:00.00000, it's possible that the config request arrives at 11:59.59.99865 and the well known request arrives at 12:00:00.12345. Caching can exacerbate the issue. While the FedCM specification doesn't specify caching precisely, presumably browsers will cache both files for some duration. If a relying party invokes fedcm with standard_config.json at 11:50 and then invokes fedcm with darkmode_config.json at 12:10, it's possible that the browser will reuse the well known file it retrieved at 11:50 instead of retrieving it again at 12:10.
For a typical maintenance, the identity provider must:
- Schedule maintenance.
- In preparation of maintenance, reducing the caching lifetimes on all relevant endpoints to small values
- Go offline at the beginning of maintenance
- Update the well known file to point to the new accounts endpoint
- Update the manifest files to point at the new accounts endpoint
- Go back online.
- Increase caching lifetimes on relevant endpoints back to long values
- Declare maintenance complete.
Modern cloud services prefer to avoid such maintenance windows and prefer be continuously available. They also want to follow safe deployment practices. Rather than going from 0% to 100% in a single maintenance window, they desire to go from 0% to 5%, and then 10%, and then 20%, etc.
One option to achieve this might be permit identity providers to make login_url and accounts_endpoint optional in the config file. The current algorithm for fetching the config file (2.5.2) checks the consistency of well known and config files in step 21, when skipWellKnown is set to false. We could:
- Update step 15 to only set accounts_url and login_url when config.login_url and config.accounts_endpoint are non-null.
- Insert a step between 17 and 18: if config.login_url or config.accounts_endpoint is missing, set skipWellKnown to false.
- Insert steps between 19 and 20: if config.login_url is null, set config.login_url to wellKnown.loginUrl. if config.accounts_endpoint is null, set config.accounts_endpoint to wellKnown.accounts_endpoint.
This change would permit the login_url and accounts_endpoint to be specified in one file (config when skipWellKnown == false, wellKnown when skipWellKnown == true). With the endpoints only specified in one file, there is no longer a possibility of two files being out of sync, enabling cloud providers to change endpoints using standard safe deployment practices.
Consider a domain which is reorganizing its endpoints. It wants to move the accounts endpoint from
/accountsto/auth/fedcm/v1.0/accounts. Today, such a move effectively requires a maintenance window.The core problem is keeping two files (config file and well known file) in sync. A web service might consist of 100 virtual machines, each of which has its own copy of each file. It takes a (small) time window to update all the files. Because a user browser hits a random service virtual machine, it can hit an updated virtual machine for one file and an un-updated virtual machine for the other file. Additionally, even if all 100 machines could update simultaneously, the browser cannot make HTTP requests simultaneously - if the file is update at 12:00:00.00000, it's possible that the config request arrives at 11:59.59.99865 and the well known request arrives at 12:00:00.12345. Caching can exacerbate the issue. While the FedCM specification doesn't specify caching precisely, presumably browsers will cache both files for some duration. If a relying party invokes fedcm with standard_config.json at 11:50 and then invokes fedcm with darkmode_config.json at 12:10, it's possible that the browser will reuse the well known file it retrieved at 11:50 instead of retrieving it again at 12:10.
For a typical maintenance, the identity provider must:
Modern cloud services prefer to avoid such maintenance windows and prefer be continuously available. They also want to follow safe deployment practices. Rather than going from 0% to 100% in a single maintenance window, they desire to go from 0% to 5%, and then 10%, and then 20%, etc.
One option to achieve this might be permit identity providers to make login_url and accounts_endpoint optional in the config file. The current algorithm for fetching the config file (2.5.2) checks the consistency of well known and config files in step 21, when skipWellKnown is set to false. We could:
This change would permit the login_url and accounts_endpoint to be specified in one file (config when skipWellKnown == false, wellKnown when skipWellKnown == true). With the endpoints only specified in one file, there is no longer a possibility of two files being out of sync, enabling cloud providers to change endpoints using standard safe deployment practices.