# | InC requirement | Refeds Restatement | Status | Notes |
---|---|---|---|---|
1 | The IdP must support the R&S entity category and be tagged as such (Note: Requirements 2, 3 and 4 are implied by the terms of R&S). | |||
2 | It must have the ability to Assign/Assert ePPNs. | |||
3 | It must have the ability to Assign/Assert ePTIDs or provide a SAML2 persistent NameID if ePPNs are re-assignable | |||
4 | It must accept SP requests for authentication contexts via the standard SAML2 Authentication Request Protocol.
| |||
5 | It must support SAML Enhanced Client or Proxy (ECP) | |||
6 | It must support user self-registration in a manner that lets the user know what, if any, further steps are required before they can authenticate to the SP they were initially trying to access. | |||
7 | User sessions at the IdP should have a reasonable default duration allowing multiple SPs to leverage the same user session when that is appropriate to the context. | |||
8 | The IdP operator must address the service longevity issue (even if for now the response is "TBD"). | |||
9 | It must support Recommended Technical Basics for IdPs (as of May 2015, with future development of the recommendations accommodated as possible, and in negotiation with InCommon). | |||
10 | It must conform to the 'Interoperable SAML 2.0 Web Browser SSO Deployment Profile' as documented at http://saml2int.org (as of May 2015, with future development of the recommendations accommodated as possible) | |||
11 | It must be certified for InCommon Bronze. | |||
12 | The IdP must have no commercial interest in the use of user data. | |||
13 | The IdP should, by design, be a service available to any R&S SP needing an IdPoLR, assuming the SP’s federation supports R&S and eduGAIN. | |||
14 | There must be no charges to the user for use of the IdPoLR service. | |||
15 | The IdPoLR service shall employ techniques to minimize system failures and ensure that any failures are not likely to result in inaccurate assertions being sent to SPs. | |||