Dear @cbiesinger , @yi-gy, @npm1,

We appreciate your detailed feedback on the proposal. To clarify and address our concerns, we would like to ask the following:

• Attack Surface: The current proposal might increase the potential attack surface and questioned what triggered its recent reconsideration (especially in malicious RP and social engineering attack vectors). You mentioned a few potential attack scenarios in the Privacy and Security section. Could you elaborate on specific attack vectors you foresee when RP is malicious, and what safeguards could be implemented to minimise the risk of malicious developers?

  • Example attack (Phishing Scenario): an evil site could exploit the specification to deceive users if the iframe URL is not shown. Consider the following:

    • An evil site (kitten.com) could feature a button for authentication on google.com. However, when the user clicks it, the site loads gogle.com (a domain owned by the evil site).
    • Following this spec, the user will see kitten.com displayed above the iframe, maintaining trust in the authentication process without suspicion.
    • It doesn't matter whether the IdP is benign or malicious, or whether the authentication succeeds or fails, because gogle.com is already in the permission list of kitten.com, and the user has been presented with kitten.com on the iframe.

  • If the iframe had displayed all three URLs (gogle.com,kitten.com,idp.com), the user could have noticed the discrepancy.

• Incognito Mode Behaviour: I am interested to know about the behaviour of the specification in incognito mode and potential information leakage. Could you clarify how the specification should handle private browsing modes to ensure user privacy and security?

We value your input and look forward to your further insights to refine the proposal and address these critical issues effectively.

Was that written by AI? I have a hard time following it.

We appreciate your detailed feedback on the proposal

We were hoping for your feedback on the proposal

questioned what triggered its recent reconsideration

I have no idea what this means

Example attack (Phishing Scenario): an evil site could exploit the specification to deceive users if the iframe URL is not shown. Consider the following:

This proposal allows showing the iframe URL

An evil site (kitten.com) could feature a button for authentication on google.com. However, when the user clicks it, the site loads gogle.com (a domain owned by the evil site).

I can't follow this. Can you describe in more detail what the iframe origin is in this attack?

Are you suggesting that kitten.com embeds an iframe from gogle.com, and a dialog saying "Sign in to gogle.com with google.com. kitten.com embeds content from gogle.com" is a phishing risk (?)

Or alternatively, you are concerned about "Sign in to kitten.com with google.com" showing up (the status quo without the proposal) even though that token will get sent to gogle.com? But this attack requires kitten.com to cooperate with gogle.com, in which case it can skip the entire iframe and just ask the user to sign in to the toplevel frame directly.

It doesn't matter whether the IdP is benign or malicious, or whether the authentication succeeds or fails, because gogle.com is already in the permission list of kitten.com, and the user has been presented with kitten.com on the iframe.

Sorry, why does it not matter if the authentication fails? What is the bad thing that will happen?

If the iframe had displayed all three URLs (gogle.com,kitten.com,idp.com), the user could have noticed the discrepancy.

I assume you mean the fedcm dialog when you say "iframe". This proposal allows showing the iframe. I still don't follow the attack vector that requires the toplevel to conspire with the iframe because in that case the toplevel can skip the iframe entirely.

Incognito Mode Behaviour

That seems entirely unrelated to the specific change, but in general, FedCM will only use the cookies that were set in incognito mode. That is, FedCM does work in incognito, but only if the user signed in to the IDP within incognito mode.

Dear @cbiesinger ,

Thanks for the response. Let me clarify my comments better:

1. The spec you submitted as explainer (which is in fact a comment in an issue) was written almost 3 years ago. Can you please point me to any meeting note/discussion that triggered this reconsideration so I can have better insight?

2. As this is UI spec, I am not concerned about other potential attack scenarios at this stage of review, but I think all three URLs should be shown in the fedcm dialogue and replacing/removing any can be exploited if the RP is malicious. I am not trying to prove my proposed attack scenario is serious or not. I am asking if it is possible.

If kittens.com (top origin) conspires with gogle.com(as an iframe origin), then replacing the gogle.com signs in with idp.com with kitten.com signs in with idp.com will make a potential URL scam possible (of course if the top frame is a matched client to the RP iframe). If all three are shown at all times, at least the user can have a chance to recognise any potential attack.

So now, I ask my question again (regardless of being serious or not): Is the above scenario possible? If yes, then replacing the gogle.com with kitten.com does not really help the user make an informed decision (despite making the user less confused).

3. Thanks for the clarification on the incognito mode ceremony.

I hope I am clear enough now.

Regards, Ehsan

@toreini I'm pretty sure that the proposed change is to show all 3 origins in some cases, where only 2 are currently shown. The "explainer" implies the opposite, but the title of this issue implies adding an origin.

@jyasskin , yes, you are right. What I am also trying to understand is whether showing 3 URLs at all times is better than only showing 3 in some cases (where RP had not specified a matched client), which is at the heart of this spec?

Dear @cbiesinger ,

Thanks for the response. Let me clarify my comments better:

1. The spec you submitted as explainer (which is in fact a comment in an issue) was written almost 3 years ago. Can you please point me to any meeting note/discussion that triggered this reconsideration so I can have better insight?

Apologies for the old explainer. I am also realizing I neglected to link to https://github.com/w3c-fedid/FedCM/issues/725 which is a more up-to-date summary.

I don't have anything public to point to, but we have heard from partners that they wanted their iframe domain to be visible in the dialog. For example, imagine a photo editor embedded inside a website, perhaps a book editor.

The photo editor may want to allow the user to sign in to their photo editor account so that they can access previously stored files. Showing only the toplevel domain would be misleading.

On the other hand, some websites (real example) trigger the fedcm dialog from a foostatic.com iframe. The dialog would show Sign in to foostatic.com with google.com and the subtitle would say foo.com embeds content from foostatic.com, which is not very meaningful to the user.

3. As this is UI spec, I am not concerned about other potential attack scenarios at this stage of review, but I think all three URLs should be shown in the fedcm dialogue and replacing/removing any can be exploited if the RP is malicious. I am not trying to prove my proposed attack scenario is serious or not. I am asking if it is possible.>

If kittens.com (top origin) conspires with gogle.com(as an iframe origin), then replacing the gogle.com signs in with idp.com with kitten.com signs in with idp.com will make a potential URL scam possible (of course if the top frame is a matched client to the RP iframe). If all three are shown at all times, at least the user can have a chance to recognise any potential attack.

So now, I ask my question again (regardless of being serious or not): Is the above scenario possible? If yes, then replacing the gogle.com with kitten.com does not really help the user make an informed decision (despite making the user less confused).

Right now we show kitten.com (and the IDP, google.com). With the proposal we may show all three domains ("Sign in to gogle.com with google.com" with a subtitle "kitten.com embeds content from gogle.com"), depending on what the IDP tells us.

Your attack relies on having a harmless-looking toplevel origin that is actually malicious. But in this situation the toplevel frame can just trigger FedCM directly.

If you are imagining a benign toplevel and an evil iframe, this relies on the toplevel allowing the iframe to use FedCM with permissions policy (and CSP). And in this case, the IDP would tell the brower to show all three origins.