On Thu, Apr 9, 2026 at 2:42 PM Will Bartlett <wibartle= [email protected]> wrote:
> ZjQcmQRYFpfptBannerEnd > > 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 > <https://urldefense.com/v3/__https://app-example.login.idp.example/fedcm.config__;!!Bt8RZUm9aw!5rqaYDydXovOt3CL6litYbPnJ9AJr4sUeENnwXQQiD57bwFZa_dxX1mkW_AAzKpyE-OmpeQUL7baPSBwTlOLXjXEmv0$> > or > https://login.idp.example/app.example/fedcm.config > <https://urldefense.com/v3/__https://login.idp.example/app.example/fedcm.config__;!!Bt8RZUm9aw!5rqaYDydXovOt3CL6litYbPnJ9AJr4sUeENnwXQQiD57bwFZa_dxX1mkW_AAzKpyE-OmpeQUL7baPSBwTlOLJgNaa78$> > as > its config, pointing to accounts and login endpoints in the same domain > subdomain or subpath, and thereby identify app.example before consent. > Thanks, that's actually very different from the attack I imagined. (I thought we were discussing $USERINFO.login.idp.example). I'm concerned that restricting IDPs to registrable domains may not present a substantial countermeasure against this attack. For ~$10/year, any colluding RP and IDP can simply register a unique domain name to bypass this restriction. They would lose access to the IDP's cookies, but users could still presumably log in using their usual username+password (etc), allowing the histories to be joined. My recommendation: * Remove the registrable-domain restriction. * Limit requests to fully origin-scoped cookies. * Advise user agents to collect anonymized statistics on RP-IDP pairs and place a warning label on any IDP that is confusingly named or not offered by a wide range of RPs. > 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 > <https://urldefense.com/v3/__https://w3c-fedid.github.io/FedCM/*manifest-fingerprinting__;Iw!!Bt8RZUm9aw!5rqaYDydXovOt3CL6litYbPnJ9AJr4sUeENnwXQQiD57bwFZa_dxX1mkW_AAzKpyE-OmpeQUL7baPSBwTlOLhq61jkY$> > AFAICT that doesn't mention subdomains. > > 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 > Each new DNS record type that must resolve represents a much greater reliability impairment than a second HTTP origin. --Ben >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
