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
