Is there a way to maintain UI hint freshness without falling back to heavyweight FedCM

fedidcg / LightweightFedCM

A Work Item of the Federated Identity Community Group.

9 stars 4 forks source link

Is there a way to maintain UI hint freshness without falling back to heavyweight FedCM #40

Open bvandersloot-mozilla opened 2 months ago

bvandersloot-mozilla commented 2 months ago

Coming from the first comment on the TAG review request, this may be worth considering.

samuelgoto commented 2 months ago

Is there a way to maintain UI hint freshness without falling back to heavyweight FedCM?

I think the answer is: "yes" with a "but".

There are two solutions that I'm aware of:

The first involves Web Push. However, by the time that you involve Web Push, you have to spin up a lot of server-side infrastructure.
The second involves using expiration dates and triggering the "Sign-in to IdP" flows to refresh them. That's likely a lot more ergonomical for IdPs, at a small cost for users (with expired hints).

Just as a data point in case it helps, we heard from IdPs that they have strict freshness requirements (e.g. in the order of hours, not days).

bvandersloot-mozilla commented 1 month ago

I think the answer is: "yes" with a "but".

That's my sense as well. I think these are two interesting choices for IdPs to have. I'm curious what infrastructure requirements are like for Web Push, as I've never deployed its use to a production environment before.

bvandersloot-mozilla commented 1 month ago

From the meeting, an alternative would be to allow two new behaviors, depending on how many IDPs are present in the request.

If there is only one, then open the login page if one is provided, as if the credential doesn't exist.
If there is more than one, add an optional account chooser that relies upon an IDP-endpoint request to let the user pick a particular account.

(1) has the downside of maybe facilitating more "blinking" popups or redirects. (2) devolves to an "IDP chooser" rapidly for short-lived UI hints.

bvandersloot-mozilla commented 1 month ago

Relatedly, from #42 we are talking about adding pull requests for the token endpoint. This is akin to option 2 above.

bvandersloot-mozilla commented 1 month ago

I think (1)'s downside can be resolved by requiring sticky user activation to store a credential! I lean toward that direction, and allowing stores in workers to facilitate using the Push API. There was a comment in the meeting with the push API requiring notifications, and I think that is reasonable given the infrequency of user information updates.

samuelgoto commented 1 month ago

(1) would certainly lead to the best UX and Privacy properties, I believe. It is unclear to me whether that's too big of a lift to IdPs or not, but seems like a better place to start from.

samuelgoto commented 1 month ago

Just ran into this, and may help:

https://developer.mozilla.org/en-US/docs/Web/API/Web_Periodic_Background_Synchronization_API

cbiesinger commented 1 month ago

Just ran into this, and may help:

https://developer.mozilla.org/en-US/docs/Web/API/Web_Periodic_Background_Synchronization_API

That requires installing the app as a PWA, and exposes user activity & IP address to the IDP. (We considered that in https://github.com/w3c-fedid/FedCM/blob/main/meetings/2022/FedCM_%20Options%20for%20the%20Timing%20Attack%20Problem%202022-08-31.pdf)

wseltzer commented 1 month ago

Discussed at TPAC 2024: https://github.com/fedidcg/meetings/blob/main/2024/2024-09-24-TPAC-notes.md#lightweight