On 8 May 2024, at 17:52, Sam Goto <g...@google.com> wrote:
Thanks for these slides and recording. This is a fascinating proposal. I have plenty of potential thoughts and comments to digest, but I guess the most fundamental is that this spec assumes that users and IdPs will be happy for their browser to be a trusted party involved in login flows.
Yep, that is, indeed, the privacy and security threat model that we (FedCM specifically, Web Platforms API in general) use: the user agent is a trusted party.
I’m sure browser developers do of course view their own products as trustworthy, but not everyone does. Episodes like [1] do provoke some distrust. Especially in corporate environments where users are forced to use a particular user-agent (and may be subject to mitm proxies), this may not be a universally accepted threat model.
In particular, the call to the accounts endpoint assumes that the IdP is willing to provide PII about the user to the browser. That seems questionable.
Aside from a privacy/security threat model perspective (meaning, the user agent already has visibility over every network request made available to the content area)
Sure, but if I use the recommended auth code flow or encrypted ID tokens, then PII is not exposed to the browser. And it’s not just the browser itself in the current proposal, as the token is exposed to _javascript_, of course, so the usual XSS risks.
, I think that, if you look through the lenses of the design of incentives, this is indeed something that we are still gathering validation. So far, it seems to strike a good balance, but I think you are right in that this introduces an extra game theoretical position that can be questioned.
I guess a related question is whether browser vendors are intending for this to become the only game in town for cross-site authentication? If not then those with differing threat models can use other mechanisms. But if the plan is to eventually completely block all other federation protocols then it needs to work for all use cases.
This endpoint also has no CSRF protection, so risks leaking PII more generally (eg to any origin that has been CORS-allowlisted).
As far as CSRF goes, we expose a Sec-Fetch-Dest HTTP request, which is a forbidden request header (meaning that it can't be polyfilled in userland).
Ok, that is good. But it feels like something that IdPs could easily forget to enforce. In general, being one missed security header check away from a PII data leak seems not a fun place to be for an IdP.
As another general comment, I'd say that if you want this to be easy for RPs to apply to existing login flows then it needs to be something that is easy to configure/initiate via a reverse proxy. That would suggest HTTP header-based rather than a JS API in my opinion.
Yep, that sounds reasonable to me. For the most part, we think of JS APIs and HTTP request are largely isomorphic in the important parts (again, privacy/security wise), and we can expose either/both purely based on ergonomics (as you suggest), so yeah, if this makes it easier for developers, it is easy to make it happen, I think.
— Neil
|
