Central Discovery Service

Multiple proposals exist for browser-side extensions to help with discovering a user's identity provider. This is also known as the NASCAR problem, or federated login box problem. This document attempts to determine how much functionality of a browser-side extension can also be achieved using a shared & trusted web domain that we call the CDS. One theory is that it might be possible for nearly the exact same UI to be used by both browser-side extensions and this CDS domain. That would enable RPs to use the browser-extension if it exists, or the CDS if it is configured on this computer.

The primary value proposition of a browser-side extension is that it can store information that is global to the machine, as opposed to information which is specific to a particular web domain and thus could be stored with traditional browser cookies. The key global state that could be stored is the list of identity providers that the end-user prefers. That global state can then be used in one of two-ways. The first mode, promiscuous mode, allows that IDP list to be automatically shared with any website the user visits so those sites can optimize their login UI. The second mode, privacy-sensitive mode, allows the user to choose which IDP names in the list are shared with the website (and usually only one is shared).

Promiscuous Mode

Lets first take the promiscuous mode, and consider how a CDS domain could provide similar functionality. The user needs some way to tell the CDS the name of an IDP that can be shared in promiscuous mode. There are four possible user experiences for that flow:

    1. IDP redirects user to the CDS with a request to add a specific IDP, and the CDS shows a page asking the user to confirm that request

    2. Same as #1, but the the IDP is not on a trusted whitelist, so the CDS confirmation page shows a small caution note about the IDP. The goal of the note is to help the user detects attempts to trick them into visiting one IDP that impersonates another and tries to phish the user

    3. Same as #1, but the initial request is digitally signed to prove it came from the IDP itself, and if the IDP is on a trusted whitelist, the CDS skips the confirmation request. To be on this trusted whitelist, the IDP would need to go through a certification process to confirm it gets a reasonable level of user consent to broadcast the IDP's name via the CDS. In the case of an IDP run by an Enterprise, that consent decision could be made by the company instead of the employee.

Any RP that a user visits can make a JSON request to the CDS to get the list of the user's IDPs that are advertised in promiscuous mode. That process is invisible to the user. Note that if flow #3 above is used, then that is also invisible to the user. So that raises the question, at what point would a user first be sent to a CDS to add their IDP. There are a few possible options:

    1. When a user first creates an account at an IDP, it can send the request to the CDS

    2. When a user first logs into an IDP, and it detects that the IDP is not listed by the CDS, then it can redirect to the CDS

    3. When a user first hits the federated login IDP endpoint, and it detects that the IDP is not listed by the CDS, then it can redirect to the CDS

    4. When a user first logs into an RP, and it detects that the IDP is not listed by the CDS, then it can redirect to the CDS (though sadly the RP has little incentive to do this since it only helps other RPs)

    5. A user can go directly to the CDS, and provide the name of the IDP that it wants to add

Note that options 1-3 are also a good point for a certified IDP to get the user's consent to automatically add the IDP's name to the CDP.

Privacy Sensitive Mode

This more advanced mode would allow an IDP name to be added to a CDS, but the CDS would never share their name without getting the user's explicit consent to share that IDP name with a SPECIFIC RP. Instead, the CDS would let RPs determine that the CDS is currently storing a privacy-sensitive IDP name (or names), while the CDS would still allow any RP to invisibly get a list of IDP names that are in promiscuous mode. The user experience for adding the IDP to the CDS would be similar to the 3 listed above, however in flow #1 the CDS would not need to confirm the user's consent since it will do that in the future for every RP that asks for the an IDP on this privacy-sensitive list. If an RP makes such a request, it has to perform a redirect to the CDS. The CDS will then show a user experience with the following information/options:

    • The names of the IDPs that the user has previously shared with this site, and the date/time it was shared if it is on the privacy sensitive list

    • The names of the most recently used IDPs on other sites, and the date/time the IDP was used if it is on the privacy sensitive list

    • The list of all IDPs in the user's CDS

    • An option to manually add another IDP. If the user had never configured their CDS with an IDP, then this is the UI the user would see. In that case, the CDS could ask the user to enter their Email address or other ID that could be used to bootstrap the process of finding their IDP.

The CDS could potentially provide multiple flavors of this UI to enable RPs to experiment with the best user experience. Some of those UIs might even provide a way for the user to enter the username or E-mail address of a legacy account they have at the RP where that account does not use federated login.

Who runs the CDS?

The technical complexity of this trusted domain would be simple, but it would need to be well trusted. It would also be enforcing a whitelist of trusted IDPs. Therefore this domain would probably be run by a neutral group such as Verisign or a standard body foundation such as OIDF, Information Card Foundation, Kantara, etc.

User Experience at RP

Lets assume for a moment that both a browser-extension and CDS web-domain provide the same UI. The question that still leaves is what UI the RP should use. There are a large variety of RP use cases, but we can cover a few:

    • RPs who only support a few IDPs will probably continue to operate without these optimizations, and simply show icons for the IDPs

    • RPs who only support federated login, but for large # of IDPs, might always send the user to the CDS/browser-extension, even if the user does not have an IDP on the privacy-sensitive list, because it leverages the consistent UI of the CDS/browser-extension. The RP might optionally give the CDS/browser-extension a list of IDPs it trusts, or characteristics that the IDP must publicly state it supports

    • RPs who support legacy logins and a large number of IDPs, will probably use the list of promiscuous IDPs from the CDS/browser-extension to show their icons next to their login box as an optimization, but with a fall back to ask the user for their legacy account name/Email. The RP may still only support a subset of the IDPs (like those which are email providers) listed by the CDS in which case it would only show the icons for that subset.

    • Advanced RPs who support legacy logins and a large number of IDPs may always redirect to the CDS/browser-extension and ask that CDS/browser-extension also give the user the option to enter their legacy username/E-mail for the RP

Incremental Steps

A browser-extension is easier to use for bootstrapping this user experience because it does not require establishing a trust-model for the CDS, and it is reasonably easy for those of us at large commercial IDPs to get UX approval to show special UI when we detect the selector is installed on a computer. One the model was established for browser-extensions, we could evaluate whether to invest the work needed to build the trust model for a CDS.

Google hosts a million+ OpenID IDPs via our Google Apps for your Domain service, so we could configure them to work with the CDS/browser-extension to help with incremental testing.