UI customizations #287
Comments
I think this sort of text does speak to a need that FedCM's UI model doesn't fit today - that of an entity that provides authorization to a resource, without necessarily sharing an exact identity with the resource's owner. For example, bundled newspaper subscriptions. It is fairly common for one to be able to sign up for a bundle at Today on browsers that still allow 3p cookies the above happens 'invisibly' to the user, but in the future it will require explicit user interaction, and FedCM seems like a good structure for that - but the current UI (and the spec!) assumes 'sign-in' as the only intent. |
|
We have thought about this! Our API should be easily extensible to support other UI formats. One caveat is that it would be hard for the browser to enforce that the information sharing is limited to what is being implied by the UI. |
Yes, this is a very important caveat to note! Although an IDP may only provide authorization for an RP, nothing technically would prevent them from sharing more than that (e.g., full identification of the user). So any different UI treatment would have to not mislead the user there. That said, this area is difficult in general for the user to know what is being shared. If I click 'Sign in as Stephen' (current FedCM), do I know that |
|
An IDP should not be able to choose how the UI is displayed, that should be up to the user agent. Allowing IDP to control UI will lead to inconsistent user experience. Instead an IDP can provide what features it supports so that a user agent can use that information to provide a UI to accommodate those things, but do so in a consistent manner. |
@matthewp - What features did you have in mind? |
Well, there's a question as to who should be providing (which part of?) the experience -- the IDP or the user agent? The browser should be providing core primitives to enable IDPs / service providers to do their job better (and to distinguish them from trackers / ad networks). However, I disagree that it should be trying to control the entire experience without providing any service provider "escape hatches". I think that approach actually makes it much harder to innovate and provide better UIs over time for users. Browser development moves more slowly (relative to general Web development) and often lacks domain-specific knowledge and experience for any number of use cases. Multiple issues in this repo have already spoken to the difficulties around getting sufficient user consent, providing clarity to users over what is being shared (or isn't), expressing authorization vs. authentication vs. identity credentials, and so on. I think this suggests that the space is too open for us to think that all (or most) use cases and requirements will be solved in a satisfying way with merely a simple UI in the user agent. The last thing we need is another AppCache-style feature. We need more powerful solutions; the browser just needs to enable them in a safe way for users. Furthermore, we should not be centralizing innovation in the space to a handful of browser vendors. Browsers should instead provide a strong foundation of security and privacy primitives that can be assembled by Web developers to create consistent user experiences -- as users interact with the service providers of their choice. The service providers know best how to surface information to their users ... and if they don't, users should be able to vote with their feet and choose a different provider. In other words, FedCM should be supporting the extensible Web paradigm by providing the primitives necessary to enable Web developers to do their jobs in a decentralized ecosystem. It should not take over the entire UX to the exclusion of service providers. |
By features I meant the parts of the UI that you pointed out in the initial post. Such as the IDP icon, a user name, etc. A user agent might decide to only display icons for known trusted providers, for example, and provide a different sort of UI for the others. They might decide that if there are 3 providers and only 1 of them has the user's name, to not display the name for any of them, to make the UI more consistent. |
|
@dlongley I couldn't disagree more. My experience browsing the web is that most websites do not have the user's best interest in mind so handing them the ability to control UI outside of the browser frame would be a massive mistake. The login popup should be owned by the user agent, entirely. There's actually nothing UX focused about having multiple identity providers. If this spec was purely UX focused then the browser would use its own identity backend and present the user with an option to login or not. That it's federated to allow multiple providers is a compromise to use existing infrastructure and gain buy-in; it's not a UX focused decision. |
But whether or not "most websites" have the user's best interest in mind is not relevant nor is it what I claimed. We're not talking about "most websites", we're talking about service providers (e.g., IDPs). These are sites that users intentionally visit, sign up with, and continually use -- to provide them with login services and the like. If an IDP does not have the user's best interests in mind, users should be able to switch IDPs. Of course, this is difficult today because there's no browser-based mediation of IDP / service provider choices. This means it is entirely up to relying parties to decide for users which IDPs / service providers they can use, which is a huge problem for user choice. It inevitably centralizes the service provider market to companies with large user bases -- which they often acquire through practices that don't support user privacy. This allows large IDPs, today, to ignore the user's best interests -- instead collecting and selling their personal data. But FedCM can help solve that problem, too (see: w3c-fedid/idp-registration#2). We should be aiming for the future we want that's best for users on the Web. If we trade a world of IDPs that spy on people and monetize their personal information for a world where 3-4 browser companies (some of which are also large IDPs too) control innovation for authz / authn / identity credentials on the Web, we will have just recreated the problem for user choice. The best outcome for users is that their choices matter and are influential over which service providers are successful... because they offer the best experiences in an open, decentralized marketplace. Centralized controls like forcing RPs to pick service providers for users or forcing all innovation into a slow and constrained browser pipeline are mistakes that harm users. |
One clarifying point here -- I'm not suggesting that we let websites control the UI in a way that would confuse users as to whether the user agent or the website were rendering the content. I'm suggesting that the user agent provide an appropriate window for service providers to render their own UI and interact with an appropriate API, i.e., similar to the payment handler spec. |
|
@dlongley A "relying party" is just a website. Since a website can control what IDPs are eligible, giving an IDP the ability to style the popup is the same as giving every website the ability to style the popup. Innovation in styling a popup is not what we need at this stage of the process. What we need at this stage is the very basics; the ability for a user to login to a website with a consistent experience so it's not an exercise in frustration and "did I use this password or that other one on this website". And we also need the login experience to be simple for websites as well. The FedCM spec doesn't currently provide that, and that's something that should be tackled way before popup styling. See the Gemini spec as an example of how that can be done well. |
|
I'm not against solving problems in a piecemeal fashion, prioritizing those that are seen as the most immediately damaging to users. However, the design and architecture must consider the problem space as a whole -- and not further entrench bad UX (e.g., lack of user choice) on the Web.
There are any number of ways that this can be interpreted to be incorrect -- too many to chase down. Instead, consider the design I'm advocating for:
The longer it takes for step 4 to be implemented (instead users only have a very limited browser UI for simple login cases), the longer the status quo of poor user choice on the Web is preserved. FedCM will not have helped solve the user choice problem on the Web until it implements step 4 (or something that achieves the same goal). Taking away IDP UI freedom in the short term can also be additionally harmful to users. Right now IDPs can show whatever UIs they want -- but they have to build everything on top of primitives that are also used by ad trackers / other sites that we agree do not have the user's best interests in mind. If FedCM is successful in making it so that users are taken through a limited browser-only UI ... and then browser vendors consider the problem solved and remove the primitives required to provide a better IDP UI, users will pay that price with lost functionality and further consolidation of the service and credential provider market to those companies that control platforms and browsers. |
|
I think that design is overcomplicated. You should not have to visit website B when trying to login to website A. The flow should be:
We really need to look at competitor UX flows and not try to design this to be like how you currently login to websites. How you currently login to websites is bad; it's not a guide. |
|
Here's how you login to a site on the gemini protocol:
The left panel is browser UI. You have a list of identities (in their case they are client certificates). On a site that requires a certificate you select an identity to use. The browser will then send that certificate with requests in the future. That's it; that's all you have to do. |
|
The above solution appears (to me) to be a rehash of the WebID+TLS work from over a decade ago: https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html Browser vendors have long rejected using TLS client certificates to solve the problem we're discussing now for a variety of reasons. I understand that you may be suggesting that we only consider the above UI (not the underlying technical details for how to get there) -- but I believe that the proposed UI depends upon a number of assumptions that are problematic here. First, I think it will be hard to achieve the UI you proposed when the goal here is to build on top of existing federated / decentralized identity style solutions. It may be possible to get to something close to the above once a user has already made a number of choices on a particular website. For example, if the browser "remembers" choices for faster selection again by the user. However, this seems, to me, to be about adding optimizations to the flow I described rather than a starting point. Implementing those "optimizations" may also break abstractions in ways that end up being harmful to users. In other words, the primitives aren't quite right. This is a danger of focusing only on top-down design. But maybe you disagree with that goal, so... Second, I think the UI you proposed (if seen as a starting point) relies on the idea that websites will do their own identity and / or credential management for their users or that "login" is all that matters. It's clear that many (most?) websites don't want to do this -- they want to delegate it. They also sometimes don't even want to choose who to delegate it to (which is a reason why they just pick the largest providers to get the largest user base). This includes websites that already accept (or may want to accept) third-party verifiable credentials (aka claims) about users -- where the issuer of the credentials matters, not the manager. This is another sign that the design needs to put this choice back into the hands of users -- not build another thing that every website needs to manage... which sends the ecosystem system backwards, IMO. Third, user identity and credential management is a large space. The proposed UI seems to push this either onto websites (as just mentioned) or entirely to the browser -- where it would be run by just a few companies (platform / browser vendors), reducing or eliminating competition. This clearly harms users. So the UI that is built here should be the simplest possible ... but not simpler :). In other words, it's possible to build a really simple UI that doesn't meet all the requirements. We need to enable users to pick good stewards for their credentials / PII -- and enable those stewards to innovate at the edges so that the UX and feature set continues to improve and change with the ecosystem. IMO, the UI must meet these requirements. |
|
@dlongley I'm only proposing that we:
That is to say, I only care about UX and DX. I don't care about underlying technology. I don't care about goals that are counter to good UX and good DX.
I'd love to hear why you think that is the case. The UI I am proposing would send a header to the server that includes a unique identifier for the user, that the website can use as a key in their database. They would not have to do "credential management" or any of that stuff. The website would literally not have to do anything, the browser and identity providers would do all of the work.
Strong disagree. Having users go through a dozen dialogs for no reason harms users. Having website do all of the same steps to achieve login as they do today harms users. |
Sorry I may be confused, but isn't this the exact definition of federated login? Website B gets to Federate their login flow to website A? |
No, the definition doesn't need to include showing website B UI. It can be done entirely from browser UI (the popup) without leaving website A in any way. |
If you're just using an existing SSO session, sure. But an actual active authentication is not possible via browser chrome. |
If this is true then it's something to be fixed, not something to double-down on. You do not have to load a website to login to your Android or iOS device. We should not accept UX worse than competitors. |
|
You're comparing unlocking a local credential store with a device-specific PIN or biometric, to third party federation on the web. Not really something you can compare. Browser chrome should not replace an IdP's sign in experience, and in most cases, it cannot. |
Can we compare a native app like Twitter to a native app like Safari or Chrome or Brave? I just logged into Twitter without a web page popping up. Can you explain to me why that native app can do it but a browser cannot? We're just talking about some HTTP requests here. To be clear, I am not against federated login. I am against doubling-down on federated login and making UX worse than status quo (per the mock-ups I was shown). Our goal should be getting to as close-as-possible UX that native platforms provide. The priority for a login API for the web should be:
It seems that some people here disagree and place Federation as the most important priority. I disagree, strongly. |
|
If you use Twitter, with a local twitter account, yes you're correct. But that is not third party federation. Signing into Twitter app with a third party IdP often pops open a browser and takes you to the IdP, which is required if you're using strong authentication. |
|
So then a browser should be able to provide the same login flow when users are using the browser's 1st party IDP, as 99% of users will be doing. |
|
Apologies, but I might need a picture or sequence diagram here. I don't see how the browser could be expected to provide the same login flow as with a first-party scenario when the credentials and attributes are held by a third party, especially when the browser doesn't have any idea who that third party might be. When a student in the University of California system goes to a journal's website, they are usually given an option to authenticate with their home institution's credentials. And this gets tricky because they may actually have more than one home institution (happens a lot in the Bay area). Only the journal (SP) knows what IdPs they have relationships with (usually hundreds if not thousands of IdPs), and only the IdPs know if the user is entitled to access that subscription. And the user knows that if they can't get access with their credentials from one school, they can always try with a different account at another school. |
Not sure what this means. If you log into Twitter, with a Twitter account, there is no federated identity flow. The browser is not involved outside of (optional) password autofill or WebAuthn. |
I mean that Google, Apple, Firefox, all own their own identity services. They can provide a simplified UX flow when a user chooses to say, login via Google Login when using Chrome. They can, like Twitter does in its native app, skip the federated flow. |
They do when the user is using the browser provider's own login flow, which is what will happen 99% of the time. Aside from that, the scenario you laid out seems completely plausible. Perhaps not with the current spec, and that's fine. But certainly it's possible for a browser to make HTTP requests to an IDP, and it's possible for an IDP to respond to those HTTP requests and choose to trust the browser with information. And then it's possible for the browser to then relay that information back to another website. Whether that fits with the model or whether it should happen is a different matter, but if you take a step back there's nothing implausible about a browser acting as an intermediator between 2 web servers. |
Sure, but you're making an implicit tradeoff here which @dlongley has been calling into question. If the browser determines that only password based authentication flows are necessary, but not 2FA (unlikely but bear with me for the sake of the argument) and programs their UI that way (using the C++ logic necessary to implement browser UI) then all IDPs have to conform with this authentication logic implemented by the browser. The browser logic and IDP logic become inherently tied together. Now lets say that the IDPs for enterprise A, EDU B, and Social Provider C all want to enable support for 2FA. Unfortunately, they cannot do this alone now because the IDP needs to coordinate with browser vendors, via a new standard, to update the data that's passed in these HTTP requests and to update the browser UI so that all IDPs can support 2FA. This is because without the browser UI being able to enable this flow none of the IDPs could support 2FA because they require changes from the browsers. This coordination takes a lot of time which slows the pace of innovation. As, @samuelgoto pointed out very early on with this work when hosting a session at IIW on this spec (I'm paraphrasing a bit here since it's been awhile) "There's far more web developers than browser developers so it's better to leave things to web developers where possible rather than cause a larger maintenance burden on browser developers." While the path you're suggesting @matthewp is possible, it goes against this principle in a way that would increase complexity and coordination by browser vendors. This complexity wouldn't fall on browser developers though if the solution did something like creating a secure frame that IDPs can use to challenge the user and innovate as they wish while also creating a browser API for the RPs to call in order to pass credentials between the IDP and the RP (once the IDP has registered) via the browser. While this does increase the complexity on IDPs, it greatly relieves the pressure on browser developers which is what's typically preferred when considering these tradeoffs. Additionally, this tradeoff means that IDPs can innovate in ways that they choose in order to compete for users and RP trust via offering different claims that are passed in the tokens they're willing to provide as well as different authentication mechanisms they'll use to challenge the user. All while not requiring any changes at the browser layer if things get implemented this way. |
|
I had a conversation with Samuel and got a very different impression of what he prioritizes. I would not be opposed to some level of customization as so long as it comes way down the line after initial UX and DX is nailed down. What I'm afraid of happening is an explosion of requirements that makes it impossible to provide a native-competitive UX. If we nail the basics of UX and DX today then we can feel better about providing customizations for the 0.1% of users who might use a provider that has them. |
These are solved with the RP context API. #470 We currently support the cases listed in the Sign In With Google docs but please reach out to us if you would like to add more.
These could probably be done through the button mode API. I will be closing this bug for now but opened a new one over at w3c-fedid/active-mode#1 to track the latter cases. |
FedCM UI currently displays:
In order to support more use cases, it may be useful to add some API parameters that choose among a list of possible UI strings and/or layouts.
For example, perusing Sign In With Google docs suggests a couple more variations on the strings:
Are there other user journeys where different strings or UI layouts would be helpful? For example:
It would be great to hear from RPs and IDPs about what kind of call-to-action strings or UI layouts/fields they may like to see in FedCM.
The text was updated successfully, but these errors were encountered: