The Embedded Discovery Service (EDS) provides a consistent user experience for the discovery part of Single Sign On (SSO).

In order to initiate SSO, the user has to select where (with which Identity Provider - IdP) they wish to be authorized. Many mechanisms have been used to solve this problem for instance:

• Typing in an associated URI.
• Hard-wiring in one or a few IdPs.
• Centralized discovery.

This last has been commonly used with Shibboleth SPs and in other situations where there is a a large number of IdPs. It consists of redirecting the user to a central location (the Centralized Discovery Service) where they are presented with a choice of all potential IdPs. This has usability issues:

• The user may be presented with, and then select, an IdP that the SP has no relationship with. The user may then log in successfully to the IdP, but still fail to get access to the SP. This leads to confusion.
• The Centralized Discovery Service will almost certainly have a different 'look and feel' from either the SP or the IdP. In usability testing this has been shown to be a massive barrier to progressing the logging-in process.
• There is no provision to allow favored IdPs to be presented.

EDS consists of JavaScript files that are be used to create a discovery service within an existing webpage. This can then be

• Branded so that the user can seamlessly move from SP to Discovery to the IdP
• Restricted to only show those IdPs with which the SP has a relationship
• Configured to preferentially present favored IdPs

The EDS is designed to be branded. Nonetheless SPs running the same EDS will present the same look and feel for discovery. This reduces confusion when a user encounters discovery.

Example deployment

The screenshots shown below are from a branded deployment. Firstly the default layout with no previously visited sites:

After the user has selected some IdPs:

During the selection process: