#1217: Question: How to reduce apex domain modifications for IDPs using FedCM

Visit on Github

Opened Apr 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:

  1. using an underscored prefixed DNS name (_web-identity.<domain>) or
  2. using a non-underscored prefixed DNS name through HTTP (web-identity.<domain>).

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

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