The term "boarding" has come into common use to describe a process by which an SP determines that a particular IdP that it finds acceptable is also "set up" for successful use by its users. The reason this is traditionally a problem is that most non-consumer IdPs are not equipped to prompt users to approve the release of Attributes to an SP. Instead, they rely on administrative control over release of information based on contractual agreements and the like, usually brokered by staff who operate the IdP service.
Consent is never likely to be universally deployed, but if it were widely in use, SPs that required fairly simple and well-defined information might be able to assume the the majority of potential IdPs will work correctly and simply handle the others as exception cases. But as long as the majority of potential IdPs are likely to fail, assuming they can be offered to users as choices during IdP Discovery will create a poor user experience.
The most common way this manifests is when SPs avoid implementing an IdP Discovery process by pointing to a "master" list of IdPs, often based on an entire federation. This gives the SP, the IdPs, and the federation a black eye. Thus, the boarding process.
- Implications for IdP Discovery
- User-facing list
- Administrative list
- Describing/expressing requirements for User Identification and Attributes
- Directing "unboarded" users
- Handling errors