An aim of OpenID Connect is to solve the problem of death by a thousand passwords by allowing the user to select their identity provider including ones that the relying party has never heard of through Dynamic Registration. A problem of allowing the user to select their identity provider is that the authentication challenge page needs to show all the registered identity providers.
This means that this page becomes like the NASCAR problem. The NASCAR problem describes the jumble of branding icons on websites, e.g. 3rd party sign-in/login options or sharing buttons. It is dubbed the NASCAR problem because of these clusters of 3rd party icons/brands on websites resembles the collages of sponsorship decals covering NASCAR racing cars. It’s a problem because such clusters of icons/brands cause both visual noise and people to be confused, overwhelmed or unlikely to remember individual icons, especially as the clusters seem to grow with the introduction of new 3rd party identity/profile/social sites and services.
When using O
penID Connect, it’s likely that the client will both have buttons for popular servers as well as a text field for user entry of an email address or URL. (OpenID Connect does not directly solve the “NASCAR” problem).
How therefore to solve the NASCAR problem in OpenID Connect?
The client will need to either limit the number of registered authorisation servers supported by their service or provide a mechanism for selecting from a larger list of identity providers. Furthermore if the OpenID Connect Dynamic Registration capability is enabled a form field for the authorisation server’s URL needs to be provided as a last option below the existing identity providers.
Limiting the number of supported identity providers maybe easier for commercial sites. In a public sector / government scenario there may be legal reasons why the number of authorisation servers cannot be constrained. As a future example it may become necessary for a government service provider to support all retail banks operating in that country acting as authorisation servers (e.g. PAYM in the UK) and all the mobile network operators acting in that country (e.g. MobileConnect). In this example there may be more that 50 different authorisation providers and the user may have an existing registration with multiple identity providers. It is here that presentation of identity provider is important and mere alphabetic listing maybe insufficient.
API Crazy 