On Thu, May 9, 2024 at 9:07 AM Tom Jones <thomasclinganjo...@gmail.com> 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 <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
