> > 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 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]
