I think I'm still missing something, and I'm sure it was discussed somewhere and I just didn't see it. How will this help avoid the NASCAR problem, for sites when a user *signs up* or when the user *signs in on a new browser?*
On Thu, May 9, 2024 at 1:07 AM Sam Goto <goto=40google....@dmarc.ietf.org> wrote: > > > On Wed, May 8, 2024 at 3:50 PM Neil Madden <neil.e.mad...@gmail.com> > wrote: > >> On 8 May 2024, at 22:01, 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 depends on whether the IdP correctly enforces the presence of the >> sec-fetch-dest header. If it doesn’t then yes, it would be vulnerable. >> Presumably it’s also vulnerable on older/niche browsers that don’t block >> sec-* headers: caniuse.com reckons > 8% of users globally are using >> browsers that don’t understand any sec-fetch-* headers. I’m not sure when >> sec-* was added to the forbidden list. >> >> I guess, flipping this around, we might ask what is the legitimate >> purpose for which browsers need to access the user’s name, email address >> (both requires) and other identifying information? I’d have thought an >> identifier (possibly randomised) and some user-supplied account nickname >> would be sufficient. >> > > That's easier to answer: the browser needs name/email/picture to construct an > account chooser > <https://docs.google.com/presentation/d/1iURrPakaHgBfQ6mAefKijjxToiTTgBSPz1rtaV0od98/edit#slide=id.p>, > which is the UX that tested best with users by a far margin. > > Static/unpersonalized permission prompts - example > <https://www.cookiestatus.com/images/content/storage-access-api.jpg> in > Safari, example > <https://developers.google.com/static/privacy-sandbox/assets/images/storage-access-api-permission-prompt.png> > in Chrome - perform extremely poorly (in comparison to account choosers), > although have other benefits too (namely ergonomics and extensibility), so > Chrome (and others) expose that too in the form of the Storage Access API > <https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API>. > > >> >> — Neil >> >> _______________________________________________ > 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
