Question - how does all this interact with the password manager? Can the RP ask if they have an entry in the PM first? Or is that too much of a privacy issue?
Also when calling for an app, wouldn't it matter if the app were web vs native? Which one does this thread discuss? ..tom On Tue, May 21, 2024 at 1:47 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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
