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

[Will Bartlett <[e-mail]>]

Hi DNSOP,
The W3C Federated Identity CG/WG is working on FedCM (Federated Credential Management), a browser API for federated authentication. 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. 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.
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:
Option A: SVCB with embedded data — Query _web-identity.<registrable-domain> for an SVCB record whose SvcParams carry the well-known data directly (custom keys like accounts-endpoint, login-url). Eliminates the HTTP round-trip entirely. Requires IANA registration of new SvcParamKeys per RFC 9460.
Option B: SVCB for delegation — Query _web-identity.<registrable-domain> for an SVCB record; use TargetName to identify the subdomain, then fetch .well-known/web-identity from that host over HTTPS.
Option C: Fixed subdomain — No DNS lookup; always fetch from web-identity.<registrable-domain>, which the IDP points (e.g., via CNAME) to their infrastructure.
Option D: TXT record — Query _web-identity.<registrable-domain> for a TXT record containing sub=login, then fetch the well-known file from login.<registrable-domain>.
Our key questions:

  1.
Is SVCB appropriate here? We're not doing service binding in the traditional sense (ALPN negotiation, ECH, etc.) — we'd either be using TargetName purely for delegation (Option B) or embedding application-layer metadata in custom SvcParams (Option A). Is this a reasonable use of SVCB, or a misuse of the record type?
  2.
TXT vs SVCB pragmatics. TXT at an underscore-prefixed name (à la DMARC _dmarc, MTA-STS _mta-sts) is universally supported by registrars today. SVCB support is still limited. Given that a goal is broad deployability (including small organizations managing DNS through commodity registrars), does the group have a view on whether new protocols should prefer SVCB over TXT for simple delegation, or is TXT still the practical choice?
  3.
Naming convention. Is _web-identity.<domain> an appropriate underscore name? Any conflicts or conventions we should be aware of? Should we register in the Underscored and Globally Scoped DNS Node Names registry (RFC 8552)?
  4.
Embedding data in DNS vs delegation. Option A puts application data (URL paths) directly in DNS records, avoiding an HTTP fetch. Is there precedent or guidance for/against this pattern? We're aware of the 65535-byte practical limit on DNS responses, but the data here is small (two short paths).

Relevant links:

  *   Spec: https://fedidcg.github.io/FedCM/
  *   Issue: https://github.com/w3c-fedid/FedCM/issues/809
  *   PR with options: https://github.com/w3c-fedid/FedCM/pull/821

Thanks for any guidance.