The Incommon Federation wiki has moved.

Please visit the new InCommon Federation Library wiki for updated content. Remember to update your bookmarks.

Click in the link above if you are not automatically redirected in 15 seconds.



You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 45 Next »

Deployment Considerations for the R&S Category

It is important that the deployment of all InCommon services facilitate initial on-boarding processes to avoid operational and technical impediments to adoption, as described in Recommended Practices for InCommon Participants.

More specifically, R&S services generally have a broad user community, often including people who do not have a close relationship with the Service Provider, or whose IdP operators do not have a close relationship with the Service Provider. For this reason, R&S Service Providers are encouraged to consider the following guidelines:

  • The R&S category is most useful to those services that do not require out-of-band negotiation with IdPs.
  • The service should request a subset of R&S Category Attributes, and furthermore, the service should request only those attributes it absolutely needs. (See the section on R&S Category Attributes for details.)
  • The SP should fully support SAML V2.0 Web Browser SSO (see the SP Endpoints wiki page).
  • The SP should provide a complete set of User Interface Elements in metadata. In particular, a Privacy Statement and a Logo are highly recommended.
  • In addition to the technical and administrative Contacts in Metadata required of all SPs, a security contact should also be provided.
  • The SP should strive to provide a good, overall federated user experience. In particular, the SP should intelligently handle errors involving the release of attributes.

Federated Error Handling

Although R&S is specifically designed to facilitate attribute release, errors are expected and therefore service providers are strongly encouraged to support Federated Error Handling. A centralized Error Handling Service is provided for this purpose.

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels