...
The topic on Federated User Experience includes a discussion on the "boarding" of IdPs by an SP. There are two general approaches that influence how critical this error condition can be to address. One model is to rely on a user- or administrator-initiated workflow that proves an IdP is capable of releasing the necessary information before offering general users the choice to use it. The other is to offer a large set of unproven choices and handle errors afterward. Obviously, the latter approach makes effective error handling absolutely essential to provide a usable service, while the former seeks to minimize errors, and thus make handling them, well, less essential. It is important to understand that no approach will eliminate this kind of error. Whether due to privacy controls or simple technical glitches, there can always be insufficient information available.
Handling this situation well is dependent upon having enough information to lead the user to a resolution of the problem (or a determination that the IdP in question simply won't allow itself to be used for the SP in question). Simply telling the user that some list of attributes has to be supplied is not going to help, particular particularly if that list is overly technical in nature (e.g., a user will not in general know what an "EPPN" is). Even if the IdP organization has a process for dealing with attribute release, most users are not going to know anything about it. Rather, a contact at the IdP will often need to manage this process and deal with technical matters on behalf of the affected user(s).
...
It's also important for SPs to provide sufficient information, such as a link to technical documentation via the <mdui:InformationURL> element|SPUIElements], a user interface element in SP metadata, so that users (and even IdP staff) understand the nature of the requested service. A list of requested attributes should also be included in SP metadata.
...