Allow IDPs to delegate well-known file hosting via DNS TXT record by will-bartlett · Pull Request #821 · w3c-fedid/FedCM

will-bartlett · 2026-03-25T23:19:24Z

Adds a _fedcm DNS TXT record mechanism that allows IDPs to indicate which subdomain should host the well-known file, instead of requiring it at the registrable domain (apex). This addresses operational challenges for organizations where the apex domain is operated by a different service than the authentication service.

Add 'resolve the well-known host' algorithm that queries _fedcm.
Distinguish DNS 'no record' (fallback to apex) from DNS errors (hard fail)
Extract well-known fetch into reusable 'fetch a well-known resource' algorithm
Update well-known file documentation with DNS examples
Add Deployment Considerations section explaining motivation

Addresses: #809

Preview | Diff

Adds a _fedcm DNS TXT record mechanism that allows IDPs to indicate which subdomain should host the well-known file, instead of requiring it at the registrable domain (apex). This addresses operational challenges for organizations where the apex domain is operated by a different service than the authentication service. - Add 'resolve the well-known host' algorithm that queries _fedcm.<domain> - Distinguish DNS 'no record' (fallback to apex) from DNS errors (hard fail) - Extract well-known fetch into reusable 'fetch a well-known resource' algorithm - Update well-known file documentation with DNS examples - Add Deployment Considerations section explaining motivation Addresses: w3c-fedid#809

samuelgoto

Good stuff @will-bartlett ! Clarification questions!!!

samuelgoto · 2026-03-25T23:36:45Z

I also wanted to say that I personally empathize so much with this proposal here because I cannot set a .well-known file in my personal website running in https://sgo.to, but WOULD be able to set a DNS record, so this PR would resolve a long standing issue that I have not being able to run my own FedCM IdP!!!

ThisIsMissEm · 2026-03-30T20:39:16Z

Does this reference https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/12/ by any chance?

will-bartlett · 2026-03-30T21:28:17Z

Does this reference https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/12/ by any chance?

I don't think so. There's no unique token for challenge and response, because it's all public metadata.

You did send me reading a bit though. I wonder if I should be aligning with RFC 9460 Service Binding. A _web-identity SVCB record instead of TXT. Such a record could either point to the well known file or replace the well known file. I guess it depends on whether we expect the well known file to grow. With one or two parameters (config or accounts+login), it fits in DNS, but if it were to grow to many parameters, it might not fit.

samuelgoto · 2026-03-30T21:42:10Z

A _web-identity SVCB record instead of TXT

Something that I'd be concerned about, specially in the context of decentralizing FedCM, is that if I had to guess, most DNS registrars allow their users to set TXT records but disallow setting SVCB records?

ThisIsMissEm · 2026-03-30T21:51:07Z

@will-bartlett I can't really provide any guidance here, since I'm absolutely not an expert when it comes to DNS. I would strongly recommend reaching out to the DNSOP WG mailing list: https://mailman3.ietf.org/mailman3/lists/dnsop@ietf.org/ or contact them via socials: https://datatracker.ietf.org/wg/dnsop/about/

will-bartlett · 2026-03-30T22:05:16Z

I think there's maybe three key decision points:

Do we want to do this at all, do we agree this is a problem worth solving?
Existing first, new first, or both in parallel? If both in parallel, does first response win (which permits intermittent but decreases latency), or must both either be matching or one errored?
DNS replacing well known (SVCB or TXT record contains values from well known file), DNS to find well known (SVCB or TXT record contains domain of well known file), or HTTPS to well known in fixed subdomain (i.e. web-identity.)?

I think my answers and rationale would be:

Yes, this is a problem worth solving, see prior discussion.
DNS replacing well known, for optimal performance
New first, because DNS is most lightweight and the majority of FedCM deployments don't exist yet, and existing deployments can always update to be optimal (and browser makers can always actually do them in parallel to avoid losing perf in transition). And because we don't expect more globally unique paths other than accounts and login url.

most DNS registrars allow their users to set TXT records but disallow setting SVCB records?

Hm, I'm no expert, but Copilot seems to say this is true. I don't really have a strong opinion, other than to remark that such things are self-perpetuating. Specs support TXT because registrars don't support new records and registrars don't support new records because specs support TXT.

samuelgoto · 2026-03-30T22:20:03Z

Edit: I changed some of my answers based on re-reading your comments and digesting them further.

I think my answers and rationale would be:

I think mine would be:

Yes, this is a problem worth solving, see prior discussion.
You are raising a good point on "And because we don't expect more globally unique paths other than accounts and login url." .... I can't think of anything that we would expect to be globally unique .... I think that if that was right, I'd agree with you that "DNS replacing well known, for optimal performance". But I'm thinking that the option "HTTPS to well known in fixed subdomain (i.e. web-identity.)" also gives you TLS encryption of the values (and also makes its size unbounded for free?)?
Good question on "existing first, new first or both in parallel". I think I could live with "New first" too, but that's a tough call, see notes below, to see if existing IdPs are going to be OK with that.

So yeah, I think, having thought about this for a second time, that your original answers seem like the right ones to me too.

Just a few notes:

On question number 2: I'm a bit surprised by "the majority of FedCM deployments don't exist yet" because we currently make FedCM requests for 3% of chrome page loads, which is quite a lot, but maybe you are envisioning something that will 10x that? One way to think about this too is to ask ourselves "what's the best that we can do?" and then "default to that" and work with existing IdPs to say "we'll make a performance/latency regression on your deployment at the moment, but here is how you can go and fix it". So, on question number 2, I think my head is at "what's the right thing to do?" now, and walk backwards from it.
On question number 3: I think your observation of "how many more things need to be globally unique" is a really good one. Just thinking out loud, I was actually hoping that we'd get rid of the configURL at some point and only use the .well-known files, because that makes them easier to be discovered (e.g. given a domain, you can figure out how to use it as an IdP).

will-bartlett · 2026-04-06T22:56:04Z

Ok. I've updated the PR now to have all the options and marked my preferences. All my preferences are fairly weak however, so I'm happy to align with whatever we conclude when we meet.

also gives you TLS encryption of the values

I wasn't sure how important this was, given that the values must match the values from the config file, which is received over TLS.

we currently make FedCM requests for 3% of chrome page loads, which is quite a lot

Wow! That is quite a lot! 1) Maybe I don't have my facts right. 2) I was thinking about IDPs more than RPs - I expect that huge/complex IDPs adopt FedCM sooner than small ones, but also have a greater capacity to deal with revisions.

I was actually hoping that we'd get rid of the configURL at some point and only use the .well-known files, because that makes them easier to be discovered (e.g. given a domain, you can figure out how to use it as an IdP).

I don't know how to do N=1 for Microsoft Entra. Microsoft lets tenants brand the login screen, all within the single Entra domain (login.microsoftonline.com). What the spec says right now works for us, because we can have per-customer branding in config files (/customerid/fedcm/config.json) and common endpoints in well-known files.

RFC8414 does an interesting thing with well-known, where it puts subpaths in the well known. It says that configuration files should be located at idp.example/.well-known/oauth-authorization-server/customerid/v2.0 in Microsoft's setup. FedCM could do something like this for config files - idp.example/.well-known/web-identity/customerid, i.e. switch from configUrl to configDomain + configPath, or require that configUrl's path start with .well-known/web-identity - but that doesn't really seem to solve your discovery goals, if configPath is not auto-discoverable.

hlflanagan · 2026-04-07T15:44:00Z

Discussed on the 7 April 2026 call. @hlflanagan will take the architectural question to the TAG. The WG/CG are strongly advised to review this PR and indicate their preferred option so we can resolve the .well-known question.

npm1 · 2026-04-09T15:14:52Z

+
+##### Option 1A: SVCB record with embedded data (Preferred) ##### {#option-1a}
+
+In this option, the user agent queries a DNS [[RFC9460]] SVCB record at


Exposing DNS record resolution (SVCB or TXT) directly in a web specification is a layering violation. There is no standard primitive in the WHATWG/W3C ecosystem for "resolve a DNS record." By specifying this, you are forcing the user agent to integrate a custom network-layer API into the web platform's processing model.

In practice, the user agent has already done this integration to support RFC 9460 (SVCB / HTTPS RRs). It's a layering violation only on paper, not in practice. Still, I've included option 1C in case folks think this conceptual layering violation is unsuitable.

Oh no, this is very much an in practice layering violation too, as @cbiesinger found out when implementing a similar DNS query for EVP.

Can you please share details? These sort of allusions to unspecified problems are not as helpful as details

Well that's why I tagged Christian, I don't know the details

npm1 · 2026-04-09T15:27:18Z

+
+<!-- BEGIN OPTION 2A -->
+
+##### Option 2A: Existing fetch first, new as fallback ##### {#option-2a}


Unclear if this would actually work reasonably well for IDPs that cannot modify the existing location of well-known. Eg if the current fetch would timeout for them, this would not work. It would only work if the current fetch would always quickly fail.

will-bartlett · 2026-04-09T16:14:18Z

@npm1 - the ask from the most recent notes (4/7) is for participants to express their preferences for how to solve this problem. I understand from your comments that for the first decision point, you prefer option C, as it avoids a conceptual layering violation. However, you left negative feedback about all options for the second decision point. Can you clarify your preference of the available options, or suggest a new option? Alternatively, if you'd prefer no option, i.e. if you think this problem is not worth solving, you can share that as well.

npm1 · 2026-04-09T17:09:21Z

@npm1 - the ask from the most recent notes (4/7) is for participants to express their preferences for how to solve this problem. I understand from your comments that for the first decision point, you prefer option C, as it avoids a conceptual layering violation. However, you left negative feedback about all options for the second decision point. Can you clarify your preference of the available options, or suggest a new option? Alternatively, if you'd prefer no option, i.e. if you think this problem is not worth solving, you can share that as well.

The ask, both in the call and in the comment which I'm quoting below, is to read and review the PR and express preferences. My preference would be 1C and 2A (or fetching both new and existing at the same time but giving priority to the existing, which I think is not any of the options: 2E?), but subject to this actually resolving the use cases, which is why I left a comment there on why it might not. Also, you called me out as being an editor and not reviewing in a timeline fashion, so not sure why you are not happy about my review?

Discussed on the 7 April 2026 call. @hlflanagan will take the architectural question to the TAG. The WG/CG are strongly advised to review this PR and indicate their preferred option so we can resolve the .well-known question.

will-bartlett · 2026-04-09T17:47:38Z

The ask, both in the call and in the comment which I'm quoting below, is to read and review the PR and express preferences. My preference would be 1C and 2A

Thanks for clarifying. It wasn't clear from your other comments that you preferred 2A.

Also, you called me out as being an editor and not reviewing in a timeline fashion, so not sure why you are not happy about my review?

I don't believe I called you out specifically in the WG call - that was certainly not my intention. I merely asked all participants to take a look.

I also don't think I expressed any unhappiness with your review - not sure what that it in reference to. To be clear, I appreciate you reviewing the PR. I only asked you to clarify which option you preferred for decision point 2.

will-bartlett · 2026-04-09T19:33:47Z

It occurs to me that there's perhaps another option for compatibility, 2E, which is just to have the relying party specify.

      let token = await navigator.credentials.get({
        identity: {
          providers: [{
            configURL: "https://idp.example/manifest.json",
            clientId: "123",
            privacyMode: "apex-http"
          }]
        }
      });

      let token = await navigator.credentials.get({
        identity: {
          providers: [{
            configURL: "https://idp.example/manifest.json",
            clientId: "123",
            privacyMode: "apex-dns"
          }]
        }
      });

That avoids the timeout or race condition choice, but muddles the API with an additional parameter.

Maybe 2F is to put privacyMode in manifest.json.

It adds a bit of data - the IdP can categorize RPs into one of two buckets based on which mode they use. But I'm not sure how much of a problem that really is - two buckets doesn't seem to be a big deal.

will-bartlett · 2026-04-09T20:06:17Z

A DNSOP participant (Ben Schwartz) has another suggestion (let's call it 2G) which is to specify FedCM to only send origin-scoped cookies (i.e. those with _Host) prefix. This could be on the manifest as a "privacyMode":"originScopedCookies". This would allow hosting the well-known file on the same origin rather than on the registrable domain. However, it is a whole new mode for sending cookies, which brings its own complexities.

npm1 · 2026-04-10T21:47:55Z

A DNSOP participant (Ben Schwartz) has another suggestion (let's call it 2G) which is to specify FedCM to only send origin-scoped cookies (i.e. those with _Host) prefix. This could be on the manifest as a "privacyMode":"originScopedCookies". This would allow hosting the well-known file on the same origin rather than on the registrable domain. However, it is a whole new mode for sending cookies, which brings its own complexities.

The manifest and well-known fetches are uncredentialed.

will-bartlett · 2026-04-10T21:52:49Z

A DNSOP participant (Ben Schwartz) has another suggestion (let's call it 2G) which is to specify FedCM to only send origin-scoped cookies (i.e. those with _Host) prefix. This could be on the manifest as a "privacyMode":"originScopedCookies". This would allow hosting the well-known file on the same origin rather than on the registrable domain. However, it is a whole new mode for sending cookies, which brings its own complexities.

The manifest and well-known fetches are uncredentialed.

I know. I mean that the manifest could indicate that the accountUrl and loginUrl fetches only send origin scoped cookies (cookies whose 'host-only' flag is true, in the language of 6252bis). But I'm thinking this is probably too complex. We'd have to update 6252bis to have multiple retrieval modes and then update fetch to have a new credential modes which correspond to the new retrieval modes. And I don't think we'll convince the 6525bis folks - cookies are hard enough without modes.

bemasc · 2026-04-13T21:11:42Z

Here's that message.

I don't claim to understand the whole flow here, but I doubt that new DNS records are the right answer.

Regarding origin-scoped cookies, another option would be to disable cookies entirely and keep the login state in LocalStorage (etc.), which already has the desired origin-scoping behavior.

will-bartlett · 2026-04-13T21:35:12Z

Ok. I've updated this PR substantially. It now no longer display options, but focuses exclusively on the DNS option. It also includes that the new result is preferred over the old (matching @samuelgoto 's preference) and a note that browsers can make them in parallel to preserve performance in the short term.

I will send out a second PR with the other option (HTTP to fixed subdomain). This is my preferred option at this point. The only substantial con is the layering issues with web specs depending on DNS, which seems to be mostly a theory issue rather than a practical one.

Regarding origin-scoped cookies, another option would be to disable cookies entirely and keep the login state in LocalStorage (etc.), which already has the desired origin-scoping behavior.

Needs to be credentials under fetch's definition, which basically means cookies, mtls, or basic/digest auth.

samuelgoto · 2026-04-13T21:39:13Z

I will send out a second PR with the other option (HTTP to fixed subdomain). This is my preferred option at this point.

Would that be Option (C) described here? If so, yeah, that's my preferred option too.

Option C: Fixed subdomain — No DNS lookup; always fetch from web-identity.<registrable-domain>, which the IDP points (e.g., via CNAME) to their infrastructure.

If so, should we include that in this PR rather than a second one?

will-bartlett · 2026-04-13T22:10:44Z

Here's that other PR: #823

will-bartlett · 2026-04-13T22:26:25Z

This is my preferred option at this point.

I meant "This [PR (that uses DNS)] is my preferred option" - but I'm ok with either.

hlflanagan · 2026-04-21T16:24:00Z

Discussed during 21 April 2026 meeting. WG/CG encouraged to review how WebAuthn handles this. Will continue discussion at the next call (5 May 2026).

samuelgoto reviewed Mar 25, 2026

View reviewed changes

Comment thread spec/index.bs Outdated

Comment thread spec/index.bs Outdated

Comment thread spec/index.bs Outdated

Comment thread spec/index.bs Outdated

Comment thread spec/index.bs Outdated

will-bartlett added 2 commits March 26, 2026 10:30

Address PR feedback

53407b6

Move explanatory note before algorithm steps

18cf3bf

samuelgoto reviewed Mar 30, 2026

View reviewed changes

Comment thread spec/index.bs

Comment thread spec/index.bs Outdated

samuelgoto added the agenda+ Regular CG meeting agenda items label Mar 30, 2026

PR feedback - make options

a0711e0

remove unnecssary note

1c7ad03

hlflanagan removed the agenda+ Regular CG meeting agenda items label Apr 7, 2026

npm1 requested changes Apr 9, 2026

View reviewed changes

will-bartlett added 2 commits April 13, 2026 14:25

Narrow to DNS option

6e529b5

Add transition note

6d6d42f

samuelgoto reviewed Apr 13, 2026

View reviewed changes

Comment thread spec/index.bs

samuelgoto added the agenda+ Regular CG meeting agenda items label Apr 17, 2026

will-bartlett mentioned this pull request Apr 24, 2026

Host-only cookie retrieval httpwg/http-extensions#3437

Open


		##### Option 1A: SVCB record with embedded data (Preferred) ##### {#option-1a}

		In this option, the user agent queries a DNS [[RFC9460]] SVCB record at


		<!-- BEGIN OPTION 2A -->

		##### Option 2A: Existing fetch first, new as fallback ##### {#option-2a}

Conversation

will-bartlett commented Mar 25, 2026 • edited by pr-preview Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

samuelgoto left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

samuelgoto commented Mar 25, 2026

Uh oh!

Uh oh!

Uh oh!

ThisIsMissEm commented Mar 30, 2026

Uh oh!

will-bartlett commented Mar 30, 2026

Uh oh!

samuelgoto commented Mar 30, 2026

Uh oh!

ThisIsMissEm commented Mar 30, 2026

Uh oh!

will-bartlett commented Mar 30, 2026

Uh oh!

samuelgoto commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

will-bartlett commented Apr 6, 2026

Uh oh!

hlflanagan commented Apr 7, 2026

Uh oh!

Uh oh!

npm1 Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

will-bartlett Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

npm1 Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

will-bartlett Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

npm1 Apr 10, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

npm1 Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

will-bartlett commented Apr 9, 2026

Uh oh!

npm1 commented Apr 9, 2026

Uh oh!

will-bartlett commented Apr 9, 2026

Uh oh!

will-bartlett commented Apr 9, 2026

Uh oh!

will-bartlett commented Apr 9, 2026

Uh oh!

npm1 commented Apr 10, 2026

Uh oh!

will-bartlett commented Apr 10, 2026

Uh oh!

bemasc commented Apr 13, 2026

Uh oh!

will-bartlett commented Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

samuelgoto commented Apr 13, 2026

Uh oh!

will-bartlett commented Mar 25, 2026 •

edited by pr-preview Bot

Loading

samuelgoto commented Mar 30, 2026 •

edited

Loading

will-bartlett commented Apr 13, 2026 •

edited

Loading