InCommon IdP of Last Resort WG List of Requirements

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.

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

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.