Page History

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).

It must have the ability to Assign/Assert ePPNs.

 It must have the ability to Assign/Assert ePTIDs

or provide a SAML2 persistent NameID if ePPNs are re-assignable

 It must accept SP requests for authentication contexts

via the standard SAML2 Authentication Request Protocol.

• This is for InCommon Bronze, as well as Silver and MFA, if supported.

"The IdP must accept authentication requests that include one or more requested authentication contexts and that may include a comparison method for evaluating the requested context classes or statements. If a comparison method is absent or "exact" and the IdP cannot satisfy the requested authentication context it must indicate no authentication context in its reply."

 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.

 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.

The IdP operator must address the service longevity issue

 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.

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)

It must be certified for InCommon Bronze.

The IdP must have no commercial interest in the use of user data.

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.

There must be no charges to the user for use of the IdPoLR service.

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.