Needing RP's identity to be able to provide account list

[mitar]

I am working on a IDP called Charon which aims to improve privacy of users by being a trusted intermediary between their private data and applications. The idea is simple: it creates unique identities for each app (also called directed/pairwise) for all users which interact with the app. Moreover, user can maintain different profiles (sets of personal information, including proxied e-mail addresses) for each of those apps. From the perspective of an app, each of those profiles is a separate user. From the perspective of an user, those profiles are different accounts the user might have for the app.

Current FedCM spec seems to prevent such trusted IDP to do its work because when asking for the list of accounts for the app it does not really provide app's (RP's) client ID. I think there should be some way to opt-in into this behavior, maybe through configuration, so that user might want to decide if they trust IDP more or less.

As a side note, I think current approach the spec outlines is a bit sad to me in the sense that generally users trust IDPs (already with their personal data, etc.) and while the goal of the spec is to enable IDPs to do their work it imposes limitations on IDPs because the spec also tries to protect against tracking. And those limitations also then prevent additional privacy improvements IDPs might try to achieve for users. I think better approach would be to simply directly address the classification problem and simply provide a better way for the UA or user (or company administrator) to determine if something is an IDP or a tracker. I wrote more about this here. But maybe there is a way to make it work with the current spec. I just feel that it will be a never ending list of use cases FedCM will have to support and expand.

[cbiesinger]

It's not clear to me that you need the RP identity for the account list endpoint for this use case -- the email address from the account list is not shared with the RP. As long as you return the directed identifier in the token endpoint (which does get the RP's identity), you should be OK, right?

[mitar]

Sure, I could always have only one account (on the IDP side) per user. But then I would not be able to use FedCM feature to allow the user to easily switch between accounts available to the user from the RP's side, directly from the browser. So how and when would then user be able to pick which account/profile they want to send to the RP?

[yi-gu]

We are introducing domainHint in the API. If it's OK for you to expose all accounts to the browser, it can filter out the ones that don't belong to the RP and only show to users the ones that are related. Would that work?

[mitar]

@yi-gu: Very interesting, thank you for pointing that out. It looked at first as it could address the use case I raised here, but it seems:

• domainHint is optionally provided by the RP? In my case it would make sense only if that list of accounts is limited by UA by RP's origin/domain or something similar, mandatory.
• This does not allow the user to create a new profile to be used for RP. My IDP enables the user to create new profiles/accounts as necessary, it allows even anonymous/ephemeral profiles/accounts. (There is then the other side of this coin which is abuse handling, which is also done by IDP, of course.)

Maybe there could be some way for user or IDP to ask to redirect to IDP to do the full OIDC flow? So FedCM could be used for common case where RP primarily wants to re-authenticate the user. But user could always break out and request to be taken to IDP to get more features?

The issue is that user might not know why they would do that, they might not be familiar with those extra features available by IDP (in my case, creating extra profiles, using anonymous/ephemeral profiles, enabling e-mail proxying).

[npm1]

Help us understand, what is your motivation for wanting to use FedCM? Does your IDP use iframes to show content to the user, or to silently refresh tokens? Do you have screenshots of sample UI of your current product?

[mitar]

My main motivation as I am working on my IDP is that I want to mitigate issues with 3rd party cookies blocking. So I was looking at alternatives out there and find FedCM as a proposed alternative. And now I am trying to see how it could integrate.

My main worry about 3rd party cookies is that it seems the industry is going in the direction of blocking cookies even if you use full-page redirects because of bounce tracking. So I worry less about iframes but more about simply user having to sign-in into IDP every time user is redirected to it because cookies get blocked by the browser.

Charon is still in development but hopefully in a month or two I could share a demo.

[yi-gu]

Would a user have a Charon account that's RP agnostic? If so, when the FedCM API is used, we can display that account on the account UI. Upon user selecting that account, the browser will send a request to the id assertion endpoint with both the user credential and RP information. With a new API that we are working on [1], IdP can return a url instead of a token in the response. The browser will then open the url in a pop-up window and IdP could do follow-up confirmation/authentication with the specific RP in that Charon controlled pop-up window. Once a user grants permission via that window, the IdP can notify the browser with the token and the browser will resolve the promise with that token.

[1] https://drive.google.com/file/d/13yaivjaJXQpWUyHtWWWUV-u-ViHIannD/view?usp=sharing

p.s. if you are interested in the motivation of this API, you could find more details [here].(#477)

[mitar]

With a new API that we are working on

Nice, I like the idea of followup options for permissions, etc. But I am not sure if it will work for this case. The account user has on Charon is without any identification, it is just authentication (possibly just keypass) so there is little to show to the user. Maybe something generic like "Your Charon account" could be used as display name. But it is still strange UX for user to have to confirm first this account and then go to a followup page to select real account. But yea, it could work, but in my mind is primarily a workaround.

Personally, I think #58 is a better solution: an opt-in for users to select which IdPs they trust (or not).

The browser will then open the url in a pop-up window

BTW, a pop-up window is a nightmare on mobile.