Add a destination type for FedCM

[cbiesinger]

We think it makes sense to define a destination type specific to FedCM requests (https://fedidcg.github.io/FedCM/)

This would replace the Sec-FedCM-CSRF header that is currently in the FedCM spec.

• At least two implementers are interested (and none opposed):
  • Chrome is interested (we're the ones proposing this)
  • Firefox is interested in FedCM in general and has also suggested a change along these lines (Why Sec-FedCM-CSRF and not Sec-Fetch-Mode fedidcg/FedCM#320, though that issue is kind of meandering and has morphed into general CORS discussions)
• Tests are written and can be reviewed and commented upon at:
  • I will add WPT tests once I update Chrome's implementation to use this destination
• Implementation bugs are filed:
  • Chrome: https://crbug.com/1368382
  • Firefox: n/a, fedcm impl still in progress
  • Safari: n/a, does not support fedcm
  • Deno (not for CORS changes): n/a

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[cbiesinger]

xref fedidcg/FedCM#353

[annevk]

When are implementations planning to ship this? If that's soon, will it move out of the CG soon as well?

This also requires a PR to CSP I think, to make it use connect-src.

[annevk]

The Build script discovered you need to update <td rowspan=19> to account for this new row.

[cbiesinger]

To answer the questions:

• Chrome is hoping to ship in 108, but we might slip to 109
• Not sure about Firefox's plans, maybe @bvandersloot-mozilla can advise?
• We spec'd the CSP check in https://fedidcg.github.io/FedCM/#fetch-the-internal-manifest, is that not enough?
• Thanks for pointing out the rowspan thing, now fixed

[annevk]

The way it works is that Fetch calls out to CSP (to ensure all fetches are governed by CSP). With what you have now we'd end up checking CSP twice and slightly different CSP policies at that.

[cbiesinger]

Oh OK, I will work on that. Can you elaborate on how it is a slightly different policy...?

[annevk]

Just because of the code path it goes down in CSP which doesn't currently know about this destination.

[cbiesinger]

I have sent w3c/webappsec-csp#567

Is there anything else that's blocking merging this PR?

[cbiesinger]

Tests are in web-platform-tests/wpt#36230

[bvandersloot-mozilla]

* Not sure about Firefox's plans, maybe @bvandersloot-mozilla can advise?

We are supportive and implementing FedCM. It is harder for us to be too precise at this point. Current ballpark is early next year.

[annevk]

Thanks @cbiesinger!

[smaug----]

Shouldn't this have been added to the dictionary too, or how is https://fetch.spec.whatwg.org/#dom-request-destination supposed to work?

[annevk]

It depends a bit on whether it's exposed to service workers, but if it is then yes. I filed #1500 on that.

[cbiesinger]

Thanks for pointing that out. It is not exposed to service workers but I'll let Anne handle the question of whether it should be added to the enum anyway, since they have a patch already.