#1217: Question: How to reduce apex domain modifications for IDPs using FedCM
Discussions
Log in to see TAG-private discussions.
Discussed
Apr 6, 2026 (See Github)
Jeffrey: this is very interesting.
Heather: and frustrating. This has already been in the group in 2021. It seems to be a very hard problem for several organisations. The group that work on Stanford uni commented that can we put the information somewhere and then the conversation started that what would be the right approach. Microsoft proposed this comming to the ???, we basically reached the point that we are not sure what to do and we are asking for help.
Jeffrey: maybe we should offer help to Mark Nottingham to help. This is part of the web architecture.
Heather: It seemed easy problem but the university and Microsoft are pointing it as a hard problem and it is intiating discussions.
Jeffrey: the biggest risk is we give two answers and then they disagree. The best is to have an answer that make sense to developers.
Yves: if many people failed, then I am not sure how we can make it.
Heather: as I am too invested in this already, I will nto put my name.
Jeffrey: I will post to offer with that to Mark Nottingham. We will come back to this one later.
Comment by @jyasskin Apr 7, 2026 (See Github)
This might also be something the IETF HTTPAPI WG might want to weigh in on. FYI @mnot.
Comment by @mnot Apr 8, 2026 (See Github)
DNSOP is likely the right place to talk about the possibility of using a domain name.
With my well-known registry expert hat on - I've got a TODO to produce some documentation on considerations for well-known URIs. I'd be interested to hear more about why some operators find it difficult to modify a file on a HTTP server but presumably can easily change DNS.
Comment by @jyasskin Apr 10, 2026 (See Github)
@mnot Do you want the TAG's help with producing that documentation? Can you send us whatever drafts you have?
Comment by @will-bartlett Apr 10, 2026 (See Github)
DNSOP is likely the right place to talk about the possibility of using a domain name.
With my well-known registry expert hat on - I've got a TODO to produce some documentation on considerations for well-known URIs. I'd be interested to hear more about why some operators find it difficult to modify a file on a HTTP server but presumably can easily change DNS.
See my mail: https://mailarchive.ietf.org/arch/msg/dnsop/oGjGfsb-Gs6PMhLqKcQlXHpNi2E/.
It's not that modifying the apex domain http server is difficult. It's a layering problem. This image shamelessly stolen from geeksforgeeks.com. DNS lives in the infrastructure layer. Identity lives in the platform layer. The http server for the apex domain lives at the application layer, like the http server for any other application. Platform layer components shouldn't depend on application layer components.
Even putting layering aside, there's a simple "number of dependencies" argument. More dependencies means less reliability. Today's OAuth flows have two dependencies - IDP and DNS. If FedCM flows have three dependencies - IDP, DNS and APEX - that's a comparative technical disadvantage.
Discussed
Apr 20, 2026 (See Github)
Yves: Need to dig more into discussion before commenting
Discussed
May 11, 2026 (See Github)
(Skipped.)
Discussed
May 18, 2026 (See Github)
skipped
Comment by @mnot May 19, 2026 (See Github)
My .02 - the layering argument isn't terribly strong; those are abstractions for helping people understand functionality, not hard borders -- and as has often been observed, they're leaky abstractions at best. Fair point about dependencies tho.
Still if you want to do this in DNS you really need to check with the DNS community for best practice -- the TAG has little authority there (sorry not sorry).
Discussed
Jun 1, 2026 (See Github)
Ives: I have not got a chance to review it propoerly. will do that soon.
Discussed
Jun 8, 2026 (See Github)
Yves: No update.
Discussed
Jun 22, 2026 (See Github)
Heather: Mark Nottingham blogged on this recently. Don't think we've got back to the WG.
Yves: ...DNSSEC.. could be vulnerable to man-in-the-middle attacks. Concern about using well-known for service discovery. I don't think DNS is the right option.
Heather: there's no good solution but is there a least-bad solution? The group could do with our help on this.
Matthew: I've seen a couple things recently that use ".well-known/" in a way that seems not appropriate. For example, we (as in one of the task forces in APA) about not using ".well-known/" because there isn't a one-to-one correspondance between an origin and what some users would consider a "website." The well-known is too globa for that. I've seen a couple things where it look slike people are using well-known because it's well-known, but then they have to invent their own layer of structure to accommodate a more nuanced definition of "website." This seems like a common enough pattern that we might need to look at it directly.
Heather: I know service workers is having a similar problem. Microsoft in particular is interested in this.
Heather: Could add to the f2f agenda - see if we can find a better path forward.
Discussed
Jun 29, 2026 (See Github)
Yves: It's more generic, about service discovery. I said last time, using DNS for this seems clunky, and prone to spoofing. Mark Nottingham wrote an article about .well-known - need to discuss with far more people to solve it.
Heather: we did add this to the f2f agenda as we agreed there's no good way to do this. The WG is going ahead with the idea of a .well-known as they don't have better ideas. This is going to be another bespoke solution, until everyone figures out a path to service discovery.
Yves: Original question was about a 'web way' to do service discovery.
Matthew: There were a couple examples that I'm aware of about using .well-known but then needing to do something on top. One was for discoverable destinations. Helping people navigate around sites. There's also a proposal for accessibility problem reporting; if you're having a problem accessing a particular website, they could have a service set up to receive reports. Is the service a subdomain or a route? There are several more. We could collect them... The one for changing passwords: there is a W3C spec for that . IT could be struggling with the same thing. We have someone from the Adapt [sp?] task force; you could have one password for one subtree of a site but a different password for other subtrees.
Mike: Might we apply an issue label for "service discovery" so that we can begin to build a corpus of case-studies?
Heather: We had a bit of a discussion at plenary about labels and how tomake them as useful as possible, w/o having a proliferation that we can't track. Maybe instead of labels, we could have an issue that we link other things to (like the 'make progress on' issues). Anyone willing
Mathew: I agree with the idea of using an issue to track this. I guess we would put it in Design Reviews--a separate type of issue. I guess we'll see if we break TAG Bot by doing that. I guess if it's a design review, we can put the design review number, and if it's something else, we can just put a link. I will create this issue.
Discussed
Jul 6, 2026 (See Github)
Yves: So we should say there is no common approach.
Christian: We will add this to the agenda-f2f.
OpenedApr 7, 2026
The FedID Working Group and Community Group are trying to resolve a long-standing question on alternatives to .well-known on the apex domain. There is a new proposal under discussion, but the groups have stalled on the best architectural pattern for the web. While using .well-known is technically easy, but implementation-wise, it is not easy for identity providers that do not have direct control of that file.
So, the immediate question is: What is the pattern (or, is there a pattern) for an item that MUST have a cardinality of 1 on the registrable domain? FedCM requires one endpoint for user+relyingParty privacy. Today, the FedCM spec uses the apex domain, which has operational considerations (see the meeting notes from 7 April 2026 for the most recent CG/WG discussion on the matter). We are examining:
Does TAG have a preferred pattern for problems like this or have any considerations for choosing between these options?
We also have a question on the use of an underscored prefixed DNS name open with IETF DNSOPS (see https://mailarchive.ietf.org/arch/msg/dnsop/aLACo0YpxJezsvlXZipp9aL0mFs/.
The AT Protocol group is discussing a similar and related topic here
<!-- Content below this is maintained by @w3c-tag-bot -->Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1217