Allow IDPs to host well-known file at web-identity. subdomain - #823
Open
will-bartlett wants to merge 1 commit into
Open
Allow IDPs to host well-known file at web-identity. subdomain#823will-bartlett wants to merge 1 commit into
will-bartlett wants to merge 1 commit into
Conversation
Adds a fixed web-identity.<registrable domain> subdomain as an alternative location for the well-known file, with fallback to the existing apex domain fetch. The subdomain fetch and fallback run in parallel with the config fetch. - Add well-known subdomain discovery section - Update fetch-config-file algorithm with subdomain-first, apex-fallback - Update well-known file documentation with subdomain examples - Add Deployment Considerations section explaining motivation Addresses: w3c-fedid#809
beckysiegel
pushed a commit
to chromium/chromium
that referenced
this pull request
May 14, 2026
Implements the subdomain-first / apex-fallback discovery flow described in w3c-fedid/FedCM#823. When the kFedCmWebIdentitySubdomain feature is enabled, FetchWellKnown fetches https://web-identity.<eTLD+1>/.well-known/web-identity first and falls back to the apex URL on fetch failure, malformed JSON, non-dict result, or provider_urls length > 1. Bug: 510015140 Change-Id: Icec90acda6a036faa95b58b58f9fcc3bc912d784 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7827169 Reviewed-by: Avi Drissman <avi@chromium.org> Reviewed-by: Christian Biesinger <cbiesinger@chromium.org> Commit-Queue: suresh potti <sureshpotti@microsoft.com> Reviewed-by: Mohamed Amir Yosef <mamir@chromium.org> Cr-Commit-Position: refs/heads/main@{#1630773}
TallTed
reviewed
May 29, 2026
Comment on lines
+1161
to
+1163
| This requires no special DNS record type support beyond standard A/AAAA/CNAME records, | ||
| making it broadly deployable. However, it requires the [=IDP=] to configure the | ||
| `web-identity.` subdomain and obtain a TLS certificate for it. |
Contributor
There was a problem hiding this comment.
Suggested change
| This requires no special DNS record type support beyond standard A/AAAA/CNAME records, | |
| making it broadly deployable. However, it requires the [=IDP=] to configure the | |
| `web-identity.` subdomain and obtain a TLS certificate for it. | |
| This option is broadly deployable because it requires only standard A/AAAA/CNAME DNS | |
| records, i.e., no special DNS record types are needed. However, it requires that the | |
| [=IDP=] configures the `web-identity.` subdomain and obtains a TLS certificate for it. |
Contributor
There was a problem hiding this comment.
I do wonder whether `web-identity.` subdomain shouldn't be changed to drop the trailing ., as DNS experts will recognize that that trailing dot typically means that is the complete hostname in the record. In other words, if I set up a DNS A/AAAA/CNAME record for web-identity. within my example.com domain, it will not be delivered in response to a lookup like host web-identity.example.com. Rather, the A/AAAA/CNAME record must be for web-identity (with no trailing dot) or web-identity.example.com. (with trailing dot) to be delivered in response to that lookup.
TallTed
reviewed
May 29, 2026
Comment on lines
1371
to
1372
| NOTE: a two-tier file system is used in order to prevent the [=IDP=] from easily determining the [=RP=] | ||
| that a user is visiting by encoding the information in the config file path. This issue is solved by |
Contributor
There was a problem hiding this comment.
Suggested change
| NOTE: a two-tier file system is used in order to prevent the [=IDP=] from easily determining the [=RP=] | |
| that a user is visiting by encoding the information in the config file path. This issue is solved by | |
| NOTE: to prevent the [=IDP=] from easily determining the [=RP=] that a user is visiting by encoding | |
| the information in the config file path, a two-tier file system is used. This solves the issue by |
TallTed
reviewed
May 29, 2026
Comment on lines
+1373
to
+1379
| requiring a [=well-known file=] to be hosted at a location controlled by the [=IDP=]'s | ||
| [=host/registrable domain=] — either at the [=host/registrable domain=] itself or at the | ||
| fixed `web-identity.` subdomain (see [[#well-known-discovery]]). The config file itself can be | ||
| anywhere, but it will not be used if the user agent does not find it in the [=well-known file=]. | ||
| This allows the [=IDP=] to keep their actual config files on an arbitary path while allowing the | ||
| user agent to prevent config file path manipulation to fingerprint (for instance, by including | ||
| the RP in the path). See [[#manifest-fingerprinting]]. |
Contributor
There was a problem hiding this comment.
Suggested change
| requiring a [=well-known file=] to be hosted at a location controlled by the [=IDP=]'s | |
| [=host/registrable domain=] — either at the [=host/registrable domain=] itself or at the | |
| fixed `web-identity.` subdomain (see [[#well-known-discovery]]). The config file itself can be | |
| anywhere, but it will not be used if the user agent does not find it in the [=well-known file=]. | |
| This allows the [=IDP=] to keep their actual config files on an arbitary path while allowing the | |
| user agent to prevent config file path manipulation to fingerprint (for instance, by including | |
| the RP in the path). See [[#manifest-fingerprinting]]. | |
| requiring that [=well-known files=] be hosted at a location controlled by the [=IDP=]'s | |
| [=host/registrable domain=] — either at the [=host/registrable domain=] itself or at the | |
| fixed `web-identity.` subdomain (see [[#well-known-discovery]]). In fact, the actual config | |
| file can be anywhere, but it will not be used if the user agent does not find it in the | |
| [=well-known file=]. This allows the [=IDP=] to keep their config files on arbitrary paths | |
| while allowing the user agent to prevent config file path manipulation to fingerprint | |
| (for instance, by including the RP in the path). See [[#manifest-fingerprinting]]. |
TallTed
reviewed
May 29, 2026
| NOTE: The browser uses the [=well-known file=] to prevent [[#manifest-fingerprinting]]. | ||
|
|
||
| The [=IDP=] exposes a <dfn>well-known file</dfn> in a pre-defined location, specifically at the "web-identity" file at the [=IDPs=]'s path ".well-known". | ||
| The [=IDP=] exposes a <dfn>well-known file</dfn> in a pre-defined location, specifically at the "web-identity" file at the path ".well-known". By default, the user agent first attempts to fetch the [=well-known file=] from the fixed subdomain `web-identity.<registrable domain>` (see [[#well-known-discovery]]). If this fails, the user agent falls back to fetching from the [=IDP=]'s [=host/registrable domain=] (e.g., `idp.example`). This addresses operational challenges where the [=host/registrable domain=] is not operated by the authentication service. |
Contributor
There was a problem hiding this comment.
Manual linting, and some minor tweaks to the text and markup. Please use your preferred DIFF tool to see the changes, because GitHub fails to highlight this properly.
Suggested change
| The [=IDP=] exposes a <dfn>well-known file</dfn> in a pre-defined location, specifically at the "web-identity" file at the path ".well-known". By default, the user agent first attempts to fetch the [=well-known file=] from the fixed subdomain `web-identity.<registrable domain>` (see [[#well-known-discovery]]). If this fails, the user agent falls back to fetching from the [=IDP=]'s [=host/registrable domain=] (e.g., `idp.example`). This addresses operational challenges where the [=host/registrable domain=] is not operated by the authentication service. | |
| The [=IDP=] exposes a <dfn>well-known file</dfn> in a pre-defined location, specifically | |
| as the `web-identity` file at the path `.well-known`. By default, the user agent first | |
| attempts to fetch the [=well-known file=] from the fixed subdomain | |
| `web-identity.<registrable domain>` (see [[#well-known-discovery]]). If this fails, the | |
| user agent falls back to fetching from the [=IDP=]'s [=host/registrable domain=] (e.g., | |
| `idp.example`). This addresses operational challenges where the [=host/registrable domain=] | |
| is not operated by the authentication service. |
TallTed
reviewed
May 29, 2026
Comment on lines
+3685
to
+3686
| the [=well-known file=] at the apex creates a runtime dependency between the authentication service | ||
| and whichever service operates the apex domain. |
Contributor
There was a problem hiding this comment.
Suggested change
| the [=well-known file=] at the apex creates a runtime dependency between the authentication service | |
| and whichever service operates the apex domain. | |
| the [=well-known file=] to be at the apex creates a runtime dependency between the authentication | |
| service and whichever service operates the apex domain. |
TallTed
reviewed
May 29, 2026
|
|
||
| To address these challenges, a fixed subdomain mechanism is specified | ||
| (see [[#well-known-discovery]]). The [=IDP=] hosts the [=well-known file=] at | ||
| `web-identity.<registrable domain>` by configuring a CNAME (or A/AAAA records) for this |
Contributor
There was a problem hiding this comment.
Suggested change
| `web-identity.<registrable domain>` by configuring a CNAME (or A/AAAA records) for this | |
| `web-identity.<registrable domain>` by configuring a CNAME (or A/AAAA) record for this |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a fixed web-identity. subdomain as an alternative location for the well-known file, with fallback to the existing apex domain fetch. The subdomain fetch and fallback run in parallel with the config fetch.
Addresses: #809
Preview | Diff