> On 8 May 2024, at 21:43, Sam Goto <g...@google.com> wrote: > > > > On Wed, May 8, 2024 at 1:34 PM Joseph Heenan <jos...@authlete.com > <mailto:jos...@authlete.com>> wrote: >> Hi Neil >> >> >>> On 8 May 2024, at 18:45, Neil Madden <neil.e.mad...@gmail.com >>> <mailto:neil.e.mad...@gmail.com>> wrote: >>> >>> >>>> On 8 May 2024, at 17:52, Sam Goto <g...@google.com >>>> <mailto:g...@google.com>> wrote: >>>> >>>> On Wed, May 8, 2024 at 7:23 AM Neil Madden <neil.e.mad...@gmail.com >>>> <mailto:neil.e.mad...@gmail.com>> wrote: >>> >>>> >>>>> 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. >> >> Sam’s response here is fair, but also note that as far as I understand it >> you can still use the authorization code flow or encrypted id tokens with >> the FedCM API > > That's correct: the browser doesn't open the response from the IdP to the RP, > so it can, for example, be encrypted. > > I was assuming that Neil was referring to the fact that the > id_assertion_endpoint (which contains the user's IdP's PII accounts > <https://fedidcg.github.io/FedCM/#dictdef-identityprovideraccount>) become, > suddenly, transparent to the browser.
Oh yes, that’s true - but (I think) the data from the id_assertion_endpoint at least isn’t exposed to javascript and isn’t vulnerable to XSS? Joseph
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
