[DNSOP] Re: [EXTERNAL] Re: Advice sought: DNS record type for FedCM well-known file delegation

[Will Bartlett <[e-mail]>]

Hit send to soon... Part of the problem here is that these services often have different reliability and layering characteristics.

In reliability:

  *
DNS is foundational network architecture and has a very high reliability like 99.999.
  *
LOGIN is foundational cloud architecture has a reliability like 99.99.
  *
APEX is just some random maybe-not-very-important site and has a reliability like 99.9.

In cloud layering:

  *
DNS is one of the lowest layers
  *
LOGIN is a low layer
  *
APEX is a high layer.

Middle-layers services (e.g. the deployment infrastructure for the APEX or APP1, which requires the service operators to login) can take a dependency on lower layers of the stack, but cannot take a dependency on higher layers.

The FedCM spec today effectively requires that the HTTP server at the APEX become a low layer in the dependency stack, where today it is usually a high layer.

It's not hard to host a json file, of course. It is hard to move high layers to low layers to maintain the disaster recovery plan's invariant that all layers only depend on layers under them.

Thanks,
Will

________________________________
From: Will Bartlett <wibartle=[e-mail]>
Sent: Thursday, April 9, 2026 11:42 AM
To: Ben Schwartz <bemasc=[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [DNSOP] Re: [EXTERNAL] Re: Advice sought: DNS record type for FedCM well-known file delegation

> 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 <bemasc=[e-mail]>
Sent: Thursday, April 9, 2026 10:10 AM
To: Will Bartlett <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [EXTERNAL] Re: [DNSOP] Advice sought: DNS record type for FedCM well-known file delegation

You don't often get email from bemasc=[e-mail]. 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