On Thu, May 9, 2024 at 2:05 PM Brock Allen <brockal...@gmail.com> wrote:
> > In your example acme.com is an RP to all the federated IdPs > > Umm, maybe indirectly. But in what I was trying to express, acme.ca is > the RP to login.acme.com, and login.acme.com is the RP to wonka.com. > acme.ca knows nothing about wonka.com. Maybe you're saying the same thing? > > > and gathering the identifier to determine the IdP is out of scope of > federation protocols. > > Yes, that's clear. > > But the original point I was trying to get at was that with FedCM, there's > now UX that seems to be handled by the browser. I'm simply asking that > FedCM allows us to break out of that so something custom can be built to > continue to allow the scenario I describe. Perhaps the pop-up window > workflow that Tim showed/described is the way to achieve that. > For reference, here is the proposed extension that Tim was referring to in the talk: https://github.com/fedidcg/FedCM/issues/555 > > -Brock > > On 5/9/2024 1:08:13 PM, Dick Hardt <dick.ha...@gmail.com> wrote: > Yes, IdP chaining is common. > > In your example acme.com is an RP to all the federated IdPs — and > gathering the identifier to determine the IdP is out of scope of federation > protocols. > > On Thu, May 9, 2024 at 9:54 AM Brock Allen <brockal...@gmail.com> wrote: > >> Could be, but if the IdP the RP uses is itself a gateway to other IdPs >> then this might not work (especially if they're all cross-site). >> >> I have a real world use case as an example for a customer (let's call >> them "Acme"). They have many RPs, one of which might be at acme.ca. >> Since they have so many RPs, they have designed a central IdP for all of >> Acme and that resides at login.acme.com (notice cross-site). Employees >> and business partners login via the central Acme IdP, but the business >> partners' credentials are held at the business partner IdP, thus those >> users are federating. >> >> Now a user from business partner "Wonka" needs to use the RP at acme.ca. >> To login they are redirected to login.acme.com. During this process at >> login.acme.com, the user is prompted in some way to determine that they >> are a Wonka employee and really need to use wonka.com as the ultimate >> IdP. They then are redirected to Wonka to actually enter credentials and >> login. The trust relationship is that RP trusts Acme IdP, which in turn >> trusts Wonka IdP (all three of which are cross site). >> >> Oh and also... at some point the user needs to logout :) >> >> So perhaps a more complicated example than most, but this is exactly what >> many organizations are doing today with OAuth and OIDC. >> >> Again, hope this makes sense. >> >> >> -Brock >> >> On 5/9/2024 12:36:28 PM, Dick Hardt <dick.ha...@gmail.com> wrote: >> Would that identifier first flow not just be part of the app? The app >> gets the identifier and then knows which IdP (if any) to redirect the user >> to. >> >> On Thu, May 9, 2024 at 9:06 AM Brock Allen <brockal...@gmail.com> wrote: >> >>> Often a user needs to be presented with a prompt collecting some data to >>> identity the upstream IdP (e.g. email, or something else). This is very >>> common with B2B relationships. This is in lieu of showing a long list of >>> the IdP (NASCAR) buttons because perhaps you, as a business, don't want to >>> show off all the business partners you integrate with for SSO. >>> >>> Hope that makes sense. >>> >>> -Brock >>> >>> On 5/9/2024 12:04:13 PM, Dick Hardt <dick.ha...@gmail.com> wrote: >>> 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
