If the user logs in using their username and password, that's consent for disclosure, so that's ok.
FedCM envisions that some sites would allow any IDP. Consider if adult-content.example allowed any IDP. The FedCM privacy stance is that it's ok for all of Bob's IDPs to receive an anonymous (cookie-less) request to https://login.idp.example/adult-content-fedcm-manifest.config, but that it'd be a problem for all of Bob's IDPs to receive an authenticated (cookie-full) request to https://login.idp.example/adult-content-accounts/, because then the IDP would learn that Bob specifically . The well known file ensures that adult-content.example and business-content.example use the same endpoint (https://login.idp.example/accounts) for authenticated (cookie-fuill) requests, because it requires that each cookie only have a single set of authenticated endpoints for FedCM. > Limit requests to fully origin-scoped cookies This is an interesting idea, and not one I've considered before. IIUC, you're effectively saying that we can specify FedCM to only send __Host / __Host-Http- prefixed cookies. If so specified, FedCM can retrieve the well known file from the same origin as the manifest, not from the registrable domain, which makes my apex problems go away. I will bring this to the WG and see what they think. At first glance, this also seems like a new concept - I don't know of any spec which says to send only origin-scoped cookies rather than all cookies - but it's worth considering for sure. Thanks, Will ________________________________ From: Ben Schwartz <[email protected]> Sent: Thursday, April 9, 2026 12:34 PM To: Will Bartlett <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [EXTERNAL] Re: [DNSOP] Advice sought: DNS record type for FedCM well-known file delegation On Thu, Apr 9, 2026 at 2:42 PM Will Bartlett <[email protected]<mailto:[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]
