The invisible UI is kinda weird

[dolda2000]

I don't technically know if this belongs to the specification or to Chromium's specific implementation, but I figure Chromium's implementation is shaping the spec as it is developed. Please tell me off if I'm mistaken.

To the point, FedCM currently doesn't display a UI at all if the user-agent doesn't find any currently logged in accounts to authenticate with. I find this kinda weird. Here are a couple of use-cases that I imagine are realistic where I find that this is less than optimal:

• Imagine an RP that only uses FedCM for logins with no other mechanisms. This is realistic, surely? I'd expect such an RP to want to have a "sign in" button somewhere without too much surrounding fluff. If the user-agent doesn't find any logged in accounts, said button would appear to just do nothing.
• In my concrete case, I'd like to offer users with existing accounts a way to associate a federated account with them for future logins. As such, I'd like to have some sort of button to do this, which would invoke FedCM, but again without any currently logged-in IdP accounts, said button would appear to be faulty, and I don't see that there's a whole lot that I could do to mitigate this, since it's impossible to distinguish between different failure modes (which I assume is intentional for privacy reasons).
• Again for my specific case, I do have a dedicated login page, where I'd like to offer FedCM login as an alternative to "native" logins. I would like to do this by invoking FedCM at page load time. However, if the user isn't logged into an IdP, they wouldn't even know that FedCM is being offered as an alternative and thus wouldn't know to log in on an IdP unless I instructed them to do that in text somewhere (and assuming that a user would read said test, a pretty big assumption).

Are these reasonable objections, or am I misunderstanding something?

[cbiesinger]

For the case of a button click, please see the proposal in w3c-fedid/active-mode#2 which adds a "button" mode, which avoids the invisible UI for a logged-out user; there will be an origin trial for this feature in Chrome 126

For your third issue -- you want to trigger a fedcm dialog onload that lets a user log in to your IDP?

[dolda2000]

"button" mode

That's nice, and sounds like it would fix those issues.

For your third issue -- you want to trigger a fedcm dialog onload that lets a user log in to your IDP?

That was my idea, at least. Is that not how it's intended to be used? I was thinking of it similarly to conditional WebAuthn mediation -- give the user the option and let them choose as they wish. If this is not how FedCM is intended to be used, then what is the intention?

[cbiesinger]

We have not had a request previously to show a fedcm dialog without user interaction for logged-out users. It's an interesting request, my initial thought is that I'm a little worried about user annoyance.

[dolda2000]

What would the alternative even be? If FedCM is not triggered by a button, or by page-load, what would it then be triggered by?

my initial thought is that I'm a little worried about user annoyance

I mean, if I could have my wishlist, I'd want the FedCM UI to be part of the same username autofill list that WebAuthn uses for conditional mediation. :)

[cbiesinger]

Sorry, what I meant was, our current thinking around use cases is:

• onload for users who are already logged in to the IDP, or
• on button click for either case

We have been discussing things like the webauthn-like conditional UI, or other variations, but they are not near implementation yet

[samuelgoto]

I mean, if I could have my wishlist, I'd want the FedCM UI to be part of the same username autofill list that WebAuthn uses for conditional mediation. :)

That's perfectly plausible, and something that I think we'll get to eventually. Here is how we were envisioning early on how FedCM would connect to auto-fill.

[dolda2000]

onload for users who are already logged in to the IDP

Right, but does that differ from what I was talking about? That is, that there's a potential problem in that the user might not be aware that there's the option of logging into an IdP and trying again.

That's perfectly plausible, and something that I think we'll get to eventually.

That sonds very promising!

[cbiesinger]

Because this issue is talking about multiple things I have filed w3c-fedid/active-mode#4 to track the specific request to let users log in from a widget that gets shown onload.

I believe the remaining issues here will be addressed by the button mode that I have linked previously. Please feel free to discuss the onload request further in that issue, or reopen this issue if I have missed something. Closing for now.