Consider adding an IDP chooser for unconnected IDPs

[bvandersloot-mozilla]

I think there is a follow up to a lot of the FedCM-releveant discussion we have had in fedidcg/LightweightFedCM#40 and fedidcg/LightweightFedCM#50, as well as a few bugs here, and I think is the best alternative direction to take on the balance.

Filing for discussion in FedCM broadly here, although I filed it against LightweightFedCM as well. I think it can only work on Lightweight if adopted here.

The idea is to only put an IDP chooser in front of the user when there are no accounts matching the current IDP-RP in the connected accounts set. This gives us a lot more freedom in shaping the API's behavior because we no longer need to maintain secrecy of the RP to the IDP. This also facilitates happy-path login, without pushing contextual integrity concerns associated with sign up. I think this represents a fair compromise that prioritizes the users' interest, but is probably gated on FedCM making the same changes, and leaves a lot of freedom for UI innovation.

Here are the particular points of flexibility this gives us in API design:

The credential request can include the RP's information (e.g. client ID, origin) so the IDP can server-side control what accounts should appear where and in what order. This...

• removes the need for browser-logic to filter by hints, instead allowing us to be a dumb pipe for the IDP-RP.
• removes the need for a well-known resource, unless we retain it for IDP-picker opt-in where it would not need to be site-level
• roll the metadata endpoint into the credential endpoint, since we no longer need to have a distinct RP-linked request before we request a credential
• reduces approved_clients to a bit
• pushes potentially high-latency IDPs behind an IDP picker, improving multi-idp UX-flows

[npm1]

The idea is to only put an IDP chooser in front of the user when there are no accounts matching the current IDP-RP in the connected accounts set.

This seems like worse UX to me.

but is probably gated on FedCM making the same changes,

Why?

and leaves a lot of freedom for UI innovation.

The FedCM spec already allows this freedom. Why must there be this constraint on browser vendors?

• removes the need for browser-logic to filter by hints, instead allowing us to be a dumb pipe for the IDP-RP.

Maybe? They would still need to be passed somehow to the request. Also, I hope you are not suggesting that clicking on a generic IDP origin should grant the IDP full access within the RP.

[bvandersloot-mozilla]

The idea is to only put an IDP chooser in front of the user when there are no accounts matching the current IDP-RP in the connected accounts set.

This seems like worse UX to me.

It seems better to me. And it gives us the benefits bulleted at the end of my post.

but is probably gated on FedCM making the same changes,

Why?

Because to take advantage of that flexibility, we would significantly change the details of the accounts network request and its security properties. This is a significant change, and if Lightweight FedCM is actually meant to be a different working mode, we would need this to align, right?

and leaves a lot of freedom for UI innovation.

The FedCM spec already allows this freedom. Why must there be this constraint on browser vendors?

This is a relatively small constraint in order to make significant improvements in the rest of the API, as I said above.

• removes the need for browser-logic to filter by hints, instead allowing us to be a dumb pipe for the IDP-RP.

Maybe? They would still need to be passed somehow to the request.

Definitely, I pointed that out here: "credential request can include the RP's information (e.g. client ID, origin)".

Also, I hope you are not suggesting that clicking on a generic IDP origin should grant the IDP full access within the RP.

Can you elaborate on what you mean by clicking on an origin and full access?

[npm1]

This seems like worse UX to me.

It seems better to me. And it gives us the benefits bulleted at the end of my post.

Maybe this is something we can ask IdPs and RPs about then.

Because to take advantage of that flexibility, we would significantly change the details of the accounts network request and its security properties. This is a significant change, and if Lightweight FedCM is actually meant to be a different working mode, we would need this to align, right?

I guess this assumes that clicking on the generic IdP picker means game over: IdP is allowed to track the user after this point, perhaps even rSA autogrant? Not sure about the details of the proposal. It does not match my intuition that clicking on a generic dialog with little context should provide this allowance.

This is a relatively small constraint in order to make significant improvements in the rest of the API, as I said above.

I think this would be a fairly big change. But perhaps I shouldn't speak for the IdPs that are currently using FedCM in Chrome.

Definitely, I pointed that out here: "credential request can include the RP's information (e.g. client ID, origin)".

Those not sufficient to know the hints. My point is that the hints would still need to be passed. They could arguably be passed in a browser-agnostic form, as some params. But in that case the login status could be incorrectly set if all of the accounts are filtered out on the IdP server side.

Also, I hope you are not suggesting that clicking on a generic IDP origin should grant the IDP full access within the RP.

Can you elaborate on what you mean by clicking on an origin and full access?

I think this sentence is what I am worried about: This gives us a lot more freedom in shaping the API's behavior because we no longer need to maintain secrecy of the RP to the IDP. I read this as saying that the IDP can have all knowledge once the user taps on the generic origin dialog. So my current understanding of the proposal is that the privacy is improved at the beginning since there are no timing attacks, but then it is weakened because the generic dialog is a much weaker signal and less understandable for the user compared to the account chooser.

[bvandersloot-mozilla]

I think there is a difference in why we think differently about this UI change: I don't care as much about what the IDP and RP think, especially when compared to what benefits the user. Both IDP and RPs are incentivized to push registrations, and I don't believe it is in the interest of the user to register accounts on every site they visit, particularly via a 3rd party service.

Another difference I sense is what makes a IdP picker or origin dialog generic or not. It seems like you are conflating a permission prompt that looks like the storage access API's prompt and a branded dialog that is specifically for linking of IDPs to the RP. The first is far more generic. I'm suggesting the second. It is also worth noting that the extremely generic prompt of the Storage Access API gives this power already and has consensus and deployment across browser engines.

[npm1]

I think there is a difference in why we think differently about this UI change: I don't care as much about what the IDP and RP think, especially when compared to what benefits the user.

Yea that's a fair point. I would argue this is also worse UX for users, but it is harder to ask users.

Another difference I sense is what makes a IdP picker or origin dialog generic or not. It seems like you are conflating a permission prompt that looks like the storage access API's prompt and a branded dialog that is specifically for linking of IDPs to the RP. The first is far more generic. I'm suggesting the second.

Yea I think this is where I am getting a bit lost. I'm not sure what you mean by 'branded dialog'. Do you mean having an RP/IdP logo? I am not sure if that would be a substantial improvement or 'far less generic'.

It is also worth noting that the extremely generic prompt of the Storage Access API gives this power already and has consensus and deployment across browser engines.

Yea but they are usually scary looking dialogs. If the idea is to give this dialog the same power (still not sure if this is the intention or not), we should make sure we do not incentivize people to use this new FedCM dialog instead of the SAA.

[bvandersloot-mozilla]

Another difference I sense is what makes a IdP picker or origin dialog generic or not. It seems like you are conflating a permission prompt that looks like the storage access API's prompt and a branded dialog that is specifically for linking of IDPs to the RP. The first is far more generic. I'm suggesting the second.

Yea I think this is where I am getting a bit lost. I'm not sure what you mean by 'branded dialog'. Do you mean having an RP/IdP logo? I am not sure if that would be a substantial improvement or 'far less generic'.

I mean having an IdP logo and user-friendly name (Google instead of https://accounts.google.com). Consider Google Account's OneTap widget where there is no account available to an equivalent storage access prompt in Firefox:


These are very different in user-friendliness to me.

It is also worth noting that the extremely generic prompt of the Storage Access API gives this power already and has consensus and deployment across browser engines.

Yea but they are usually scary looking dialogs. If the idea is to give this dialog the same power (still not sure if this is the intention or not), we should make sure we do not incentivize people to use this new FedCM dialog instead of the SAA.

I think it would be reasonable to make the SAA-trust-signal rely upon completion of a FedCM flow, not just stopping after the IdP dialog. This would leave the same incentives in place as FedCM currently has, since it already is a trust signal for SAA. Does that seem reasonable?

[samuelgoto]

Consider Google Account's OneTap widget where there is no account available to an equivalent storage access prompt in Firefox:

IIUC, this UI never happens in Chrome, just in Browsers that don't support FedCM. It performs really poorly.

I think it would be reasonable to make the SAA-trust-signal rely upon completion of a FedCM flow, not just stopping after the IdP dialog.

I'm a bit lost on this discussion ... just checking: is this a discussion that is only applicable whenmode=active and Multi-IdP?

[wseltzer]

Discussed at Jan 14 meeting minutes