Peter: they asked us to reopen this.. and have asked some questions

Amy: I don't think I have any insight for these questions

Peter: Let's review and look next week

Amy: they've asked for our opinion but it's been 4 months so we could just ask if they've made progress

Peter: they're asking for a lot more detailed knowledge..

Amy: [posts request for more info]

Amy: they say they have not made much progress... re-reading their brainstorm... seems like 5 might be least bad from a ux perspective... but is maybe excessive tracking?

Peter: not sure if I have an opinion... none seem great

Amy: I had a reaction to the one that suggests buttons might move around just as you're about to click on something. Definitely not that.

Peter: dynamic updates don't necessarily require layout shifts if the designer does it right. But not not sure if they'd have enough information to know how many placeholders and where. Or add the new ones at the bottom.. but screws up other content

Amy: if it's waiting for some it could display a loader in a correctly sized gap..

Peter: if you know how many you're waiting for.. because you've made the get calls. Why is this UI in the webpage? FedCM login UI should be in the browser itself?

Amy: excellent point

Peter: would be a departure from everything they've designed so far. Doesn't it make sense to be part of the browser chrome?

Amy: I guess had assumed they were making it part of the browser and didn't really click that's not what they're doing

Peter: I think that's not what they're doing... they did talk about using iframes. This is coming from trying to replicate existing behavious which was all done in the content. Always felt the browser should play a stronger role in session management, indicating whether you're logged in or not, regardless of whether it's fedcm. Browsers do a horrible job of UX for basic auth and certificate auth. Be nice to see..

Amy: agree. You can already sign into chrome with google... it's not new.

Peter: hoped this would go the direction of persona. The whole notion of browser managed login status and session management is beyond fedcm, but would love to see a unified ux for that that fedcm could just plug into, and take it out of the content entirely. Login button triggers the browser ux. Allows dynamic updates that don't cause layout shifts in the content. Doesn't necsssarily solve all of the timing and perf issues.

We discussed this in our call today. It seems like a good solution from a UX perspective would be if the IDPs are loaded dynamically, but without causing layout shifts in the content of the webpage (we all hate when a button we were about to click on is suddenly displaced from under our pointer). Have you thought about making this part of the browser chrome, rather than the site? Essentially moving the rendering responsibilities from the RP to the user agent.

User agents have historically had horrible UX with basic auth and certificate auth, it would be good for users if the UA could play a more active, and consitent, role in managing logged in state and UX for all forms of authentication. This implies creating other APIs beyond FedCM to handle other forms of authentication, but they could have a uniform UX. Do you think this is a direction you could see FedCM going in, in the future?

[Talked about several issues probably explained in the explainer]

Tess: Explainer has gone missing—it 404s.

Review on pause until Amy gets back.

Peter: the response that this is the direciton they're going makes me happy - but I wish they would spend the effort on the solution that doesn't require the hacks...

explainer here: https://github.com/fedidcg/FedCM/issues/319#issuecomment-1270753874

Peter: are they thinking this will be useful in the next 3 months?