Page History

...

InCommon has chosen to introduce service categories in a conservative way, by focusing narrowly on services purposed for research and scholarship, in order to make implementation as straightforward as possible, and limit the range of concerns to be as specific as possible. Other service categories may be defined in the future for other purposes.

Requirements

...

and Recommended Practices

R&S

...

Service Providers must comply with the following requirements:

• The service enhances the research and scholarship activities of some subset of the InCommon community.The service requests a subset of R&S Category Attributes and requests only those attributes it absolutely needs. (See below.)
• The service does not require out-of-band negotiation and/or contracts with IdPs.
• The service conforms to a subset of the Recommended Practices published by InCommon, as specified for the R&S Category in the following listmeets the following technical requirements:
  • The SP is a production SAML deployment.
  • The SP supports SAML V2.0 Web Browser SSO.
  • The SP refreshes and verifies metadata at least daily.
  • The SP's metadata has been submitted to InCommon and published in a human-readable format on the InCommon public web site.
  • The SP refreshes and verifies metadata at least daily.
  • The SP provides an mdui:DisplayName, in metadata (one of the numerous User Interface Elements).
  • The SP supports SAML V2.0 Web Browser SSO by including an md:AssertionConsumerService endpoint in metadata.  Provision of all user interface elements is highly recommended that supports the SAML V2.0 HTTP-POST binding.
  • The SP provides appropriate contacts in the metadata.  In addition to the Technical and Administrative contacts that are required of all SPs, a Security contact must also be providedin metadata.
  • The SP provides requested attributes in metadata.
  • The SP intelligently handles errors involving the release of requested attributes.

R&S Service Providers must resolve issues of non-compliance within a reasonable period of time from when they become aware of the issue.   Failure to do so may result in revocation of their membership in the R&S category.

In addition to the above requirements, R&S Service Providers are encouraged to consider the following guidelines and Recommended Practices:

• The service should not require out-of-band negotiation with IdPs.
• The service should request a subset of R&S Category Attributes, and furthermore should request only those attributes it absolutely needs. (See the next section for details.)
• The SP should fully support SAML V2.0 Web Browser SSO (see the SP Endpoints in Metadata 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 (once that option becomes available).
• The SP should strive to provide a good, overall user experience. In particular, the SP should intelligently handle errors involving the release of requested attributes.

Requirements for the R&S Category

R&S Category Attributes

InCommon IdPs are strongly encouraged to release the following attributes to R&S category SPs:

...