> If I understand correctly, the concern here is that the RP and IDP could > collude by using high-entropy IDP subdomains (and a wildcard DNS entry), > effectively creating a covert channel between the RP and IDP. Is that > correct?
Yes, that's right. It'd be trivial for an IDP login.idp.example that stores cookies in .login.idp.example to ask that app.example use https://app-example.login.idp.example/fedcm.config or https://login.idp.example/app.example/fedcm.config as its config, pointing to accounts and login endpoints in the same domain subdomain or subpath, and thereby identify app.example before consent. > I didn't see it mentioned explicitly in the spec. It's in 7.3.1. Manifest Fingerprinting. https://w3c-fedid.github.io/FedCM/#manifest-fingerprinting > If installing a redirect is operationally challenging, the indirection can > also be encoded in the FedCM JSON response. Surely publishing a small, > stable JSON file is achievable even in very basic static site management > tools. It's not operationally challenging. It's inconsistent with high reliability architectural principles - namely, the principle of minimizing dependencies. There are three core services here - DNS, LOGIN, and APEX - each with their own virtual or physical machines, routing layers, etc. There are any number of apps APP1, APP2, APP3, etc. It'd be preferable if the successful login to APP1 only required DNS and LOGIN to be healthy, and didn't also require APEX to be healthy. If each individual service operates at 99.99% reliability, two service dependencies implies an overall reliability of 99.98% and and three service dependencies implies an overall reliability of 99.97%. If some of the individual services have lower reliability numbers (99.9% or 99%), the math becomes correspondingly worse. RFC 3439 (Some Internet Architectural Guidelines and Philosophy) discusses the downsides of unnecessary dependencies in section 2.2.2 The Coupling Principle. Thanks, Will ________________________________ From: Ben Schwartz <[email protected]> Sent: Thursday, April 9, 2026 10:10 AM To: Will Bartlett <[email protected]> Cc: [email protected] <[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<https://aka.ms/LearnAboutSenderIdentification> The spec currently requires Identity Providers to host a .well-known/web-identity file at the registrable domain (apex). This requirement is privacy driven - in order to ensure Identity Providers are unaware of Relying Parties until user consent is granted, Identity Providers must not be permitted to use per-Relying Party configuration files. If I understand correctly, the concern here is that the RP and IDP could collude by using high-entropy IDP subdomains (and a wildcard DNS entry), effectively creating a covert channel between the RP and IDP. Is that correct? I didn't see it mentioned explicitly in the spec. This closely resembles the configuration consistency requirement that we previously discussed in the Privacy Pass working group (not coincidentally, given the related goals): https://datatracker.ietf.org/doc/draft-ietf-privacypass-key-consistency/ 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<http://login.example.com/> CNAMEs to a white-label auth provider while the apex serves a marketing site, storefront, etc. As Matthew Pounsett noted, I believe an HTTP 3XX redirect is the appropriate solution to this problem. If installing a redirect is operationally challenging, the indirection can also be encoded in the FedCM JSON response. Surely publishing a small, stable JSON file is achievable even in very basic static site management tools. We're considering using DNS to let IDPs indicate where the well-known data lives. We have four candidate approaches and would appreciate guidance on which is most appropriate, or if another pattern is appropriate If HTTP redirection is not sufficient, the first DNS technology I would recommend is the SVCB/HTTPS AliasMode, which allows owners to indirect the apex domain much like a CNAME. This avoids many of the apex domain limitations of DNS. --Ben Schwartz
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
