Early UX notes on browser integration for federated login (especially IDP discovery)

Google's user experience reason on federated login has been focused on developing a solution that works without requiring any additional software on the user's computer. However, assuming the industry does identify such a solution, and it becomes widely deployed, then there is the potential for browser extensions to help simplify the user experience even further. Of course, it takes a long time for new software/browser-extensions to become widely deployed, and they generally take even longer to become available on mobile devices, thus this is primarily a long term optimization.

Note: A related topic is the PDS proposal to add an IDP discovery mechanism to all browsers without requiring any client-side extensions

A key feature that the browser could provide is to give a hint to an RP about the likely IDPs for the current user of that browser. In most cases, the domain name of the IDP would be enough of a hint for the RP. However, if federated login is widely deployed, there is a high chance that users will have more then one IDP, with at least one for personal activity and one for their job. Currently the major desktop browsers support two features that are close to what is needed; (1) password autofill & (2) language preferences.

General Design

The Password Autofill feature enables a browser to detect when a user is logging into a site with a password. Browsers then prompt the user with the option to save the username/password for that site and automatically enter it in the future. What is likely needed is a way for a website login page to identify that it is an OpenID/SAML IDP AFTER the user has logged in to that site. The Browser can then ask the user not just whether to save the username/password for that site, but whether to also add it to their list of preferred IDPs (similar to the list of preferred languages). Other RP websites with a login page can then specify that they support OpenID or SAML IDPs, and the browser can, with the users permission, send the list of preferred IDPs to that site.

The RP site can review that list of IDPs to determine whether it supports any of them, and if so it can modify its login box to show a list of suggested IDPs to the user, along with the option to use the site's regular login box if the user does not want to use one of the listed IDPs. For example, the site might detect a single RP it trusts, such as aol.com, and modify their login box to say something simple such as "Login with your @aol.com account" which would take the user to the AOL IDP, and a smaller option underneath that says "Or use a different account" which would display the same login box that the RP uses when the IDP hint is unavailable.

Discovery

The key functionality lacking is technical standards for how the browser can detect an IDP or RP website beyond basic things like looking for fields with certain names. However the hope is that the XRD work will provide most of the underlying infrastructure needed to provide a standardized discovery mechanism. Hopefully that mechanism will work for multiple federated login technologies (SAML, OpenID, InfoCard) as well as define a mechanism for IDPs/RPs to indicate which of those protocols they support.

Primary Modes of Operation

The design described above is not new, but one of the problems is that different users, IDPs, and RPs have varying requirements on usage.

End users have different levels of sophistication, and privacy concerns. A very small % of users will be sophisticated enough to understand the problem we are trying to solve. A subset of those users will also be concerned about the privacy impacts of sending their IDP information to the RP, especially if that IDP information is a unique identifier (like a blog URL), or the domain of an IDP with few users (like a vanity domain for their family), or an IDP for a domain they don't want broadcasted (like a stealth-mode startup). However 80% of users will not understand anything about federated login (especially when they are only first encountering it), and will have minimal privacy concerns. So we need to optimize the UI for mainstream users while providing some additional controls for advanced users, and try to help users make good default decisions about privacy. This leads to some suggested requirements:

- The standard UI should allow RP/IDPs to provide as much guidance as possible, and have as little browser specific UI as possible

- The default privacy should probably be to send a user's IDP automatically, as long as the IDP is identified by shared domain name, and not a unique URL

- There should be an option for advanced users to change the default privacy settings

For IDPs, one of the key issues is whether the browser handles all of the UI interaction for adding an IDP to the user's preferred list, or does the IDP provide some/all of the UI. Many IDPs will not care, and thus the browser can handle the UI. However, more major IDPs will want to optimize the user experience (especially if they think first time users will be confused by the default browser prompts, which is likely). For example, they will probably need a way to invisibly detect that their IDP is not in the user's current preferred list in the browser, and if so they can use server-side logic to decide whether/how to display an option to the user to add it. Only if the user confirms their interest in adding it will the IDP want to initiate the browser UI needed to enable the browser to confirm the user's desire to add that IDP to their list. The IDP (especially an enterprise) may also want to promote the option for the user's IDP to be broadcasted automatically to all the sites they visit, and in that case it needs a way to ask the browser to show a special UI to confirm the user is okay with that type of broadcast. This leads to some suggested requirements:

- The browser should allow the IDP to invisibly detect whether they are already in the browser's list of preferred IDPs, but in a secure way that does not allow one IDP to check if the browser contains any other IDPs

- The browser should support a well defined mechanism to display a UI to confirm the addition of the IDP

- That confirmation mechanism should support an option for the IDP to request that this UI also get the user's permission to automatically broadcast that IDP in the future

- That confirmation mechanism might need to let the IDP indicate the likely "persona type" of the IDP, and the main types would probably be personal, business, or unspecified

RPs will also vary in their requirements for control over the UI. Many RPs will not care, but they may also not publish the necessary discovery information for this browser IDP hint to work. Other RPs will be fine publicizing the discovery information, and will let the browser decide what UI to use to control what IDP information is sent to the RP, including just pre-filling a field on the page with a default value. However most major RPs will be very unhappy if the browser automatically displays additional UI that might distract users who are visiting their site. Those RPs will want to be able to invisibly detect what IDPs a user is willing to have their browser send. They can then use that information to customize their UI, such as to promote the ability to login using one of those IDPs.

- Allow RPs to indicate whether they want to block the browser from auto-displaying any UI

- Provide a way for RPs to request a user's list of IDPs invisibly (but let the user pre-define what that list is), as well as a flag to indicate if the user has other IDPs that were not sent

- Allow RPs to request that the browser get the user's permission to send other IDPs (and if the user does, the browser should have an option that is turned-on by default which will cause that IDP information to be sent to this site invisibly in the future)

- Allow RPs to publicize a whitelist of IDPs they support so the browser can send only the subset of IDPs that overlap with that list

Special Cases

While that may be the key functionality needed, we expect to identify other work that is required to support special cases. For example:

• • The administrators of web cafes and Internet kiosks would likely want to disable this feature, just as they (hopefully) disable the browser prompting to save username/passwords

  • Many vendors provide browner Toolbar extensions that detect whether the user is logged into the vendor who provided that Toolbar, and then confige the browser based on preferences stored in that vendor's server. Those Toolbar vendors will probably want the ability to modify the "preferred IDP" list.

  • Some enterprises may modify their outbound web proxies to insert this IDP hint information when they proxy a user's HTTP request, thereby avoiding the need to update the user's browser software. Similarly, some ISP/mobile proxies may be able to automatically identify the user who is making a request through the proxy, and also include their list of IDPs.

  • Some websites should be able to identify themselves as both IDPs and RPs (such as major consumer websites such as Google and MS Live that provide E-mail services, but also allow users to login with an E-mail provided by another company).

Eric Sachs

Product Manager, Google Security