# | InC requirement | Refeds Restatement or Comments | 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). | That document has been superceded by the Kantara Initiative draft, "SAML V2.0 Implementation Profile for Federation Interoperability", https://kantarainitiative.github.io/SAMLprofiles/fedinterop.html. Open Question: What is the relationship between REFEDs and the Kantara Initiative? The IOLR Working Group should review the Kantara draft and offer suggested revisions. The ultimate goal should be to make compliance with this implementation profile a condition for designation as an Un-Affiliated IdP. | ||
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. |