Closed dolda2000 closed 5 months ago
For the case of a button click, please see the proposal in w3c-fedid/button-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?
"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?
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.
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. :)
Sorry, what I meant was, our current thinking around use cases is:
We have been discussing things like the webauthn-like conditional UI, or other variations, but they are not near implementation yet
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.
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!
Because this issue is talking about multiple things I have filed w3c-fedid/button-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.
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:
Are these reasonable objections, or am I misunderstanding something?