On Thu, May 9, 2024 at 8:03 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. > I think this is the key insight. I often use the analogy of Bezo's Infinite Shelf <https://www.youtube.com/shorts/g9BIXfQ62fc>: to turn a finite container (a physical store bookshelf in Bezo's case, pixels and screen sizes in the NASCAR's flag case) and to fundamentally make that infinite (Search over a large inventory in Bezo's case, browser state in FedCM's). By that, I mean that, when a RP calls FedCM with multiple IdPs, the IdPs that the user is not logged in to are **not** shown (prominently), so they don't occupy space in the NASCAR flag. That means that an IdP that doesn't have as many users (the torso and long tail of top selling niche books, in the infinite shelf analogy) has shelf space that it didn't before, because it doesn't take space on the top shelf. So, I do hope that FedCM can lead to a NASCAR flag that is much more diverse (in terms of the cardinality of IdPs) and personalized than the one we have today. I'm also generally excited about how much the IdP Registration API <https://github.com/fedidcg/FedCM/issues/240#issuecomment-2065607797> can substantially change the economics of the NASCAR flag. It is still an immature extension that we are still learning about, but I think it has some potential too (maybe it is analogous to self-published books, in the Amazon analogy -- but that analogy probably already went too far by then :)). > > 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
