# | 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). | The IdP must support the Refeds R&S entity category and must be tagged as such. | ||
2 | It must have the ability to Assign/Assert ePPNs. | See #1 | ||
3 | It must have the ability to Assign/Assert ePTIDs or provide a SAML2 persistent NameID if ePPNs are re-assignable | If ePPNs are reassignable by the IdP, it must provide a SAML2 persistent NameID or an ePTID, preferably the former. | ||
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) | 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. | The initial registration flow should leave the registrant clear as to the next steps and avoid a user experience that ends with an inexplicable error or process termination. This applies whether the flow is SP first or registration first. | ||
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. | Drop. A basic feature of federated IdPs. | ||
8 | The IdP operator must address the service longevity issue (even if for now the response is "TBD"). | This is a matter for the community to address and is one of the reasons we encourage multiple IdPs to support the Un-Affiliated IdP requirements. | ||
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. |