On Wed, May 8, 2024 at 2:01 PM Joseph Heenan <jos...@authlete.com> wrote:
> > > 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> wrote: > >> Hi Neil >> >> >> On 8 May 2024, at 18:45, Neil Madden <neil.e.mad...@gmail.com> wrote: >> >> >> On 8 May 2024, at 17:52, Sam Goto <g...@google.com> wrote: >> >> On Wed, May 8, 2024 at 7:23 AM Neil Madden <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? > That's correct. > > Joseph > >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
