Would you elaborate on your point Brock? I don’t follow. On Thu, May 9, 2024 at 8:54 AM Brock Allen <brockal...@gmail.com> wrote:
> This is why redirects with a custom UI are so essential. This allows other > forms of HRD without a NASCAR button list too. I hope that this will remain > possible, as it's crucial to so many business use cases. > > > -Brock > > On 5/9/2024 11:06:23 AM, Dick Hardt <dick.ha...@gmail.com> wrote: > The NASCAR problem is rooted in the RP does not know which provider(s) the > user has, so sites showed all the choices. FedCM only shows the provider(s) > the user has. > > On Thu, May 9, 2024 at 5:33 AM Warren Parad <wparad= > 40rhosys...@dmarc.ietf.org> wrote: > >> 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 >> > _______________________________________________ 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
