On Thu, May 9, 2024 at 9:07 AM Tom Jones <[email protected]> wrote:
> Has anyone considered what information the RP verifier should supply for > FedCM to function well on the behalf of both the verifier and the user? > Can you expand on this a bit more? Selective disclosure came to mind to us (e.g. an RP selectively asking for specific attributes), but maybe you have something else in mind? > > thx ..Tom (mobile) > > On Thu, May 9, 2024, 8:06 AM Dick Hardt <[email protected]> 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= >> [email protected]> 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= >>> [email protected]> wrote: >>> >>>> >>>> >>>> On Wed, May 8, 2024 at 3:50 PM Neil Madden <[email protected]> >>>> wrote: >>>> >>>>> On 8 May 2024, at 22:01, Joseph Heenan <[email protected]> wrote: >>>>> >>>>> >>>>> On 8 May 2024, at 21:43, Sam Goto <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>> On Wed, May 8, 2024 at 1:34 PM Joseph Heenan <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Neil >>>>>> >>>>>> >>>>>> On 8 May 2024, at 18:45, Neil Madden <[email protected]> wrote: >>>>>> >>>>>> >>>>>> On 8 May 2024, at 17:52, Sam Goto <[email protected]> wrote: >>>>>> >>>>>> On Wed, May 8, 2024 at 7:23 AM Neil Madden <[email protected]> >>>>>> 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 -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> >>> _______________________________________________ >>> OAuth mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> _______________________________________________ >> OAuth mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
