Usability/UX/Accessability Research?

[blaine]

I'm curious if this work has any usability, UX, or accessibility research that supports the designs here? Are there non-goals, or handling of failure case scenarios that have been envisioned and accounted for in the designs?

[samuelgoto]

I'm curious if this work has any usability, UX, or accessibility research that supports the designs here?

FedCM is a (a) browser API used by (b) websites with supportive (c) Identity Providers, so UXR is being run independently in all of these three different orthogonal / independent audiences a, b and c (see who is using what here): websites (e.g. pinterest.com, booking.com, etc) are running their own UXR against their users, identity providers (e.g. shopify.com, substack.com, google.com, web.de, gmx.de, etc) are running their own UXR again their users and developers and browser vendors (e.g. Chrome, Edge, Atlas, Firefox, etc) are also run their UXR trying to reconcile the goals that users, developers and identity providers might have.

From a browser engineering perspective, each browser also runs their own independent UXR with their users and implement their UXD independently.

For chrome, specifically, the current area of UXD/UXR focus has been on reducing what we call "intrusion" of the passive mode call (the active call performs well with users), with different / lower volume UXDs such as URL bar pills (example) or autofill (example), in conjunction with machine learning models to make predictions of user's intent.

accessibility research

On accessibility, the biggest area of investigation is what we call "auto re-authn", which automatically signs the user back in, if the website and the idp supports it, and if the user has already signed-in before. The challenge is that the UX gets automatically submitted after a timer, which is hard to find the right threshold for a lot of users. So, this is one open area of UXD investigation with an accessibility research in mind.

Does this help?

Are there non-goals, or handling of failure case scenarios that have been envisioned and accounted for in the designs?

Can you expand a bit more on what you mean by this? By non-goals do you mean specifically UXD non goals? Or privacy/security?

[blaine]

Thanks, @samuelgoto — this is helpful context.

I’m especially interested in this because we at joinroundabout.com recently implemented a discovery-based OIDC sign-in flow, and a significant amount of the implementation complexity came from areas where OAuth/OIDC behavior is either underspecified or left too optional from the relying party’s perspective.

A concrete example is login_hint.

In the first attached video (https://github.com/user-attachments/assets/5157f7d0-e706-428c-af77-ce208790bca1), we attempt to authenticate a user who is not currently signed in to their provider, while supplying login_hint with the identity the user entered. In that case, Google presents an account chooser containing identities the user did not request, rather than either:

1. attempting authentication for the hinted identity, or
2. returning an error indicating that it cannot do so.

That behavior creates an avoidable ambiguity between the identity the relying party is trying to authenticate and the identity the provider is willing to offer interactively.

In practice, that ambiguity produces one of the worst possible authentication outcomes: not a clean failure, but an apparent success under the wrong identity. Users either click quickly and authenticate as the wrong account, or abandon the flow because the UI no longer matches their intent.

When that happens, we have to provide an explicit recovery path:

From the relying party side, that recovery path is compensating for behavior that feels too weakly constrained. If login_hint were treated as semantically binding in this scenario, the RP could reason much more reliably about the authentication attempt. At minimum, the provider behavior here seems like it should collapse to one of two outcomes:

1. authenticate the identity specified in login_hint, or
2. fail in a machine-actionable way.

By contrast, the behavior is much more coherent in the case where Google has no active signed-in user at all:

And in the normal happy path — where the user is already signed in as the identity they supplied — the flow is also coherent: they are signed in directly, with an authorization prompt only where consent is actually required.

The broader concern for me is that the most damaging usability failures in authentication are often ambiguous successes, not explicit failures. The user gets signed in, but as the wrong identity, or without a clear mental model of which identity they have used before. In terms of support burden and user confusion, those are often worse than a hard error. That seems closely related to the “auto re-authn” concern you mention.

That is also why FedCM looks promising and risky at the same time.

From an RP perspective, FedCM seems capable of reducing some of the accidental complexity around identity provider UX. But if it becomes too automatic without giving the RP a way to bind the interaction to a specific user-supplied identity, it risks preserving protocol-level success while worsening identity-state legibility for users.

That matters a lot in real deployments. Based on the usability research I’ve seen and the support calls I’ve personally had to handle, one of the most confusing states for users is: “I signed in, but not as the account I meant,” or “I don’t know which account I used last time.” Any mechanism that smooths over authentication without reducing that ambiguity is only solving part of the problem.

I also suspect many relying parties will continue to need an identifier-first flow for the foreseeable future, simply because they cannot assume universal FedCM support. In our case, I do not think we can avoid prompting for an email address — or possibly an atproto handle — as the entry point.

Relatedly, I have a strong preference for supporting one authentication UX, not multiple parallel ones. The research I’ve seen and participated in (which I unfortunately can’t share because it was from a previous employer, but involved dozens of test participants in the context of sign-in on major media websites) strongly suggested that multiple sign-in pathways were substantially worse for both user comprehension and conversion than a single, consistent route.

So, without yet knowing the intended long-term FedCM model in detail, the only deployable RP flow I can currently see is something like:

1. Site prompts the user for an identity (email address or possibly an atproto handle)
2. If FedCM is available for that identity, request FedCM credentials
3. Verify control of that identity using the returned credentials
4. Issue local credentials

Put more directly: the key requirement for us is not just that FedCM make sign-in smoother, but that it allow the RP to preserve a clear and enforceable association between the identity the user typed, the identity the browser mediates, and the identity the IdP ultimately authenticates.

If that association remains loose, then a great deal of the usability and recovery complexity stays with the relying party. I would be overjoyed if FedCM gave the ability for RPs to clearly and unambiguously specify the intended sign-in identity, and if IdP/FedCM implementations gave an unambiguous return flow – a binary success or failure result, like email "magic link" flows offer – rather than the "Success: intended user / Success: unintended user (aka failure) / Failure (abandonment) / Failure (oauth policy rejection)" that plagues many existing OIDC implementations.

The benefits of FedCM's promise to remove the surveillance part of the OIDC IdP dance, and to make it easier for legitimate identity providers to offer this functionality are both extremely exciting! Let me know if any more context would be helpful!

[samuelgoto]

I’m especially interested in this because we at joinroundabout.com

joinroundabout.com looks pretty cool!!

In the first attached video (https://github.com/user-attachments/assets/5157f7d0-e706-428c-af77-ce208790bca1), we attempt to authenticate a user who is not currently signed in to their provider, while supplying login_hint with the identity the user entered.

Just to see if I understand you correctly: you are saying here that you were expecting the Google account chooser to only show the blain+test2@newpublic.org that was entered in the input box, rather than "all of the google accounts you are signed-in to"?

Did I get this right?

If so, isn't this a bug / unsupported feature in the Google OIDC/OAuth implementation?

That is also why FedCM looks promising and risky at the same time.
From an RP perspective, FedCM seems capable of reducing some of the accidental complexity around identity provider UX. But if it becomes too automatic without giving the RP a way to bind the interaction to a specific user-supplied identity, it risks preserving protocol-level success while worsening identity-state legibility for users.

From a FedCM perspective, have you run into the loginHint parameter that the RP can pass to the browser to filter out all accounts that don't match that value?

For example:

const {token} = await navigator.credentials.get({
  identity: {
     providers: [{
       configURL: "https://accounts.google.com/gsi/fedcm.json",
       clientId: "1234",
       loginHint: "blain+test2@newpublic.org",
     }]
  }
});

Should lead to an account chooser that does not show any accounts that don't match blain+test2@newpublic.org for the email field.

Because this is happening in the browser layer, this specific aspect of the UX (the semantics of loginHint) is consistent across all IdPs.

Does that help?

I also suspect many relying parties will continue to need an identifier-first flow for the foreseeable future, simply because they cannot assume universal FedCM support.

Yeah, for sure.

We have been deliberately and proactively designing FedCM as a progressive enhancement feature where it augments an existing flow rather than replacing it: when things work (e.g. browser supports it, IdP supports it, user is logged in, etc) they work better but when they don't they work the same (degrades gracefully to the the status quo), so that it can be deployed before every browser/OS in the world supports it.

In our case, I do not think we can avoid prompting for an email address — or possibly an atproto handle — as the entry point.

I'm hoping that, in the future, this will help avoiding prompting for atproto:

https://atproto.com/blog/working-to-decentralize-fedcm

And this will avoid prompting for email addresses (and for email OTPs, fwiw):

https://github.com/WICG/email-verification-protocol

Relatedly, I have a strong preference for supporting one authentication UX, not multiple parallel ones.
So, without yet knowing the intended long-term FedCM model in detail,

Yeah, me too.

However, "one unified authentication UX" requires all of the authentication mechanisms to all live in the same layer of the stack.

Federation has been, as you know =), traditionally, built "on top of the browser" (e.g. with low level primitives like top level redirects and cookies), rather "inside the browser" (e.g. with high level identity specific primitives), so the browser is entirely unaware of your federated identities: we call this The Classification Problem. So, the browser can't construct an account chooser that unifies and reconciles your federated identities with your usernames and passwords / passkeys. Since passwords/passkeys are stored in browser/kernel land, the userland that knows about federation can't reconcile with them either.

So, long term, we hope that FedCM can help by making the browser/OS aware of your federated identities, and with that, able to reconcile them with passwords and passkeys at the browser/OS layer.

Here is one step browsers are taking to unify passwords and passkeys into a single account chooser, and we hope to unify it with federated identities at some point:

https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation

Long term, I'm hoping that web developers are singly going to use a <login> element instead.

Does that help get a better sense of the long term direction we expect of FedCM?

the only deployable RP flow I can currently see is something like:

Yeah, I think what you described is roughly what you could use today. I hope that it stands on its own: I believe this flow that you described would perform better with your users than without it. LMK if it doesn't.

I would be overjoyed if FedCM gave the ability for RPs to clearly and unambiguously specify the intended sign-in identity

Like I said above, does loginHint help?

The benefits of FedCM's promise to remove the surveillance part of the OIDC IdP dance, and to make it easier for legitimate identity providers to offer this functionality are both extremely exciting!

Sweet!

I think some of the best benefits of FedCM come from the usability / UX part, more so than the surveillance part (although, yeah, not having IdPs and RPs track you is a nice to have).

For example, https://github.com/w3c-fedid/idp-registration and https://github.com/w3c-fedid/multi-idp aren't related to surveillance and are things that intrinsically can't happen unless you have a neutral intermediator involved.

Does that help?

[blaine]

That’s great, and very helpful — thank you.

One of the biggest mistakes OAuth/OIDC made in this area, in my view, was specifying login_hint as a hint or recommendation rather than as an unambiguous request. Google’s OAuth/OIDC behavior is not really buggy relative to the spec, but it is “buggy” in the sense that it violates both user expectations and relying-party expectations. The protocol leaves too much room between “the user asked to authenticate this identity” and “the provider may offer some other identity interactively.”

The loginHint parameter in FedCM is therefore very encouraging, and I hadn’t seen it before. But given the history here, I’d strongly consider making that concept more explicit — both in naming and semantics. From my own implementation experience, I would be inclined to rename loginHint to something like authnIdentity, or another term that makes the intent unmistakable, and then require the spec to produce an unambiguous outcome.

From the relying party side, the desirable outcomes seem straightforward:

1. authenticate the requested identity, or
2. fail in a clear, machine-actionable way.

What has historically caused so much UX and implementation pain is the ambiguous middle state, where the RP asks to authenticate one identity and the user is instead offered a broader account-selection experience that can easily result in the wrong identity being used. That behavior may be spec-compliant, but it is extremely costly in practice.

I had also seen missem’s work in this space, with a lot of interest. One thing that especially caught my attention was the distinction between “request an identity from this provider” and “request this identity from this provider.” That distinction matters enormously. For all the reasons in my previous comment, my hope was that FedCM would not take control of the sign-in flow away from site developers by collapsing those two models together. Based on your comments, it sounds like it does preserve that distinction, which is very good news. 🎉

Thanks as well for the other links — they were genuinely useful context. In particular, immediate credential mode for passkeys seems like a major improvement. I don’t think I could responsibly ship passkeys without that mode, because the UX failure case is too confusing: presenting a passkey option that the user appears able to choose, but which cannot actually be fulfilled, is exactly the sort of thing that undermines trust in the sign-in flow. More broadly, that kind of edge case was part of what I had in mind when I asked, sincerely, about the usability-testing side of all this.

As for some of the other solutions discussed here, I should say that I’m actually quite happy with the solution we’ve built, modulo two big remaining gaps: dynamic registration and broad IdP support.

In particular, it’s been frustrating that Microsoft’s implementation is broken enough in practice that we can’t rely on it, and Apple’s support is effectively gated behind an RP-side contractual requirement that, for us, would only be realistically solvable by shipping an App Store app, and other major providers like Hey.com, ProtonMail, etc are all conspicuously absent in the IdP arena. Obviously having the atproto ecosystem would be a huge boon, even if we can't get email providers on-board!

Aside from those limitations, though, I’d be very happy to compare notes on our approach and how we’re thinking about adding both passkey support and multi-IdP support. With the caveat that we have a small sample size, our conversion rates are extremely high, and our error rates are close to zero. Perhaps I could share a demo / discussion of our implementation, with the hope that it might serve useful for your work on and other related bits?

The email-verification flow is also very appealing. As a side note, it’s a lovely historical echo of one of the original — perhaps the original, if my memory serves correctly — use cases for WebFinger and, indeed, .well-known. Unfortunately, the ecosystem and adoption were not there to support that model at the time. It’s nice to see progress in that direction now.