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. > - this is likely one of the things we need to talk about as we discuss how > OAuth2 & OpenID Connect are profiled to work with the new API. > > Joseph > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
