Hi John, Thanks for your reply. I think you must have misunderstood the problem description. This problem does not relate to poorly configured web servers whatsoever. Let me try to re-explain, and you can ask a clarifying question if it is still not clear. You can also read the problem description in the github issues that I linked in the initial mail.
The core of the issue is that FedCM desires to mandate that implementations provide a single authoritative document for a "registrable domain" (also sometimes called an "eTLD+1"). This "single authoritative document" requirement comes from privacy considerations related to tracking. In particular, registrable domain is the appropriate scope because registrable domain is the scope used by HTTP cookies. See the privacy considerations section of the FedCM spec for more information. Today, the FedCM spec says that to locate the single authoritative document for an origin like idp.foo.example, the browser should query https://foo.example/.well-known/web-identity - note particularly - foo.example, not idp.foo.example. Foo Inc. uses a CNAME to point idp.foo.example to its identity service in (as you say) an ordinary virtual host transaction. However, Foo Inc. cannot use a CNAME to point foo.example to the same identity service for multiple reasons. First, foo.example isn't the identity service - it's a marketing or storefront page. Second, DNS does not support CNAME for foo.example, because foo.example is an apex domain. I'm seeking guidance on how to: 1. Move the authoritative document off of the apex. 2. Maintain FedCM's "single authoritative document" structure. Effectively I've come up with three solutions: 1. Put the authoritative document in DNS itself in an underscore prefixed DNS name (_web-identity.foo.example). The authoritative document contains only two HTTP paths, so it could fit in a DNS result. 2. Use DNS to indicate which subdomain contains the authoritative document using an underscore prefixed DNS name (_web-identity.foo.example), then retrieve the authoritative document from that subdomain with HTTP 3. Simply say that the authoritative document always lives in a fixed subdomain (https://web-identity.foo.example/.well-known/web-identity) I'm interested in feedback on which of these solutions might be recommended and in any details about the correct ways to implement these solutions. PS: your mail server is misconfigured and your emails are being routed to spam. The DKIM signature on your mail was invalid. Mails from other DNSOP participants and participants of other IETF WGs do not show this problem, so the problem appears to be specific to either your email domain or mailbox. Thanks, Will ________________________________ From: John Levine <[email protected]> Sent: Tuesday, April 7, 2026 12:08 PM To: [email protected] <[email protected]> Cc: Will Bartlett <[email protected]> Subject: [EXTERNAL] Re: [DNSOP] Advice sought: DNS record type for FedCM well-known file delegation [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] It appears that Will Bartlett <[email protected]> said: >configuration files. In other words, each registrable domain must have a >single configuration file. Hosting a file at the apex is operationally >problematic >when the apex is operated by a different service than the authentication >service � a common setup where login.example.com CNAMEs to a white-label auth >provider while the apex serves a marketing site, storefront, etc. If I may push back a little, this sounds like a problem of poorly configured web servers, not something that dnsop needs to solve. If you use a CNAME to point a domain at a web server, that's an ordinary virtual host transaction and it can (and generally does) return contents appropriate to that domain. I understand that it may be a challenge to get some providers to implement this setup, but if they don't think it's worth the effort to provide it to people who are presumably their paying customers, why it it worth the effort for anyone else? R's, John
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
