Executive Summary
TBD
Problem Statement: Why is Such a Service Needed?
Research Service Providers (SPs) often find that the population they want to serve includes individuals who are not represented by campus-based or other institutional Identity Providers (IdPs), or whose organizational IdP refuses to release attributes necessary for the operation of the SP. Ideally in those cases such individuals could be directed to register with a participating IdP that offered no-cost, easy registration processes. However, none of the existing IdPs meet all the requirements of the research community. What is needed is an IdP of Last Resort specifically addressing this service gap.
The “IdP of Last Resort” is, as the name suggests, only intended as a last resort and is not intended to take the place of an organizational IdP. Having an IdP run by an organization with which the user is affiliated, and which meets the user’s needs in interacting with SPs, is clearly the desirable state for all users.
It is our implicit recommendation that InCommon continue to make it very plain to its participants that, if they are not doing so already, they should endeavor to run an IdP for its user community which is managed in such a way as to meet their needs. E.g., if organizational policy is preventing the IdP from releasing attributes required by SPs that the user needs to access, then the policy should be revisited in that light, and/or a clear and flexible exception process implemented. Users should use their organizational IdP unless:
the organization doesn't have an IdP
the organization’s IdP doesn't release required attributes to the SP
the SP requires ECP but the organization’s IdP doesn't support ECP
the SP requires MFA but the organization’s IdP doesn't support MFA
Requirements
- Support for user self-registration
- User registration incorporated into sign-in flow, so new user is not stranded at IdP
- User registers once for sign-in to multiple Research and Scholarship (R&S)-tagged SPs (i.e., user identity is not SP-specific)
- Once user has authenticated at the IdP, user is not prompted for password again when visiting other SPs during the same browser session, unless required by the SP
- IdP must support the R&S entity category and be tagged as such
- Ability to Assign/Assert ePPN; values must not be reassigned
- Ability to Assign/Assert ePTIDs
- Must address the service longevity issue (even if for now the response is "TBD")
- Support for SAML Enhanced Client or Proxy (ECP)
- Support for Multiple AuthN Contexts for MFA and Assurance
- This is for their InCommon Bronze, as well as Silver and MFA, if supported.
- Support for Recommended Technical Basics for IdPs
- ? Conforms to the 'Interoperable SAML 2.0 Web Browser SSO Deployment
Profile' as documented at http://saml2int.org ? - Self-assertion of InCommon Bronze compliance
- No commercial interest in the use of user data
- IdP must be available globally to any R&S tagged SP
- NOTE: This can only be achieved at the federation level, not unilaterally by an IdP
- Available to users throughout the world (perhaps with invitation from "approved" projects)
The following criteria are highly desirable, but not required.
- Publishes aggregate usage statistics to give feedback to campus IT on use by their constituency (i.e., motivate campus to participate in R&S so the campus users don't need the IdPoLR anymore)
- Support for user consent
- Support for Silver credentials and authN (to be combined with local identity vetting to achieve Silver LoA
- Low/no cost to SPs for use
- No cost for users
- Accepts non-ASCII characters (e.g. uses UTF-8 as the default encoding) in user-entered data
- Support for some form of multi-factor authentication
Risks and Their Mitigation
Multiple competing IdPs offer service
- Build in a requirement to onboard users from an existing but sunsetting service; notify SPs of the change so no UX bumps at switch.
Loss of incentive for institutions to support R&S
Potential users will be unaware of the option to use IdPoLR; Research SPs will be motivated to market the option to their users
If InCommon launches a trial service, users & SPs could be orphaned
If InCommon waits until we have the perfect service, the Research SPs will have found other solutions
Recommendations
Short and Long Term Recommendations
Our primary recommendation is that InCommon take steps to help make available a production IdPoLR service. An IdP meeting all these requirements is unlikely to appear through spontaneous generation. On the other hand, InCommon does not necessarily need to operate the IdP in question, it may be enough for InCommon to identify and support the launch of an independent operator.
Our recommendations include a near-term plan to get an IdPoLR service into production as quickly as possible and a longer-term plan to create a level playing field for any potential provider to offer a comparable or better service. The urgency comes from the research service providers who have a critical unmet need to enable all of their potential users to access there research sites and tools. The long-term value of fostering multiple IdPs that meet this requirement is to mitigate the risk that failure of a single IdP will mean that the required service goes away.
(Identity proofing and other aspects of LoA not requirements of initial service offering)
Having a clear set of requirements is one important prerequisite to creating a level playing field on which multiple IdPoLRs can play. Another is some form of identity federation-based vetting and tagging of candidate IdPoLR services. Both of these prerequisites could be met by leveraging emerging practices in the entity category space. The REFEDS Research and Scholarship Entity Category specification (https://refeds.org/category/research-and-scholarship/) provides a concrete example of this approach in action. Again by having short and long term plans, an initial IdPoLR service could be made operational prior to committing to define an entity category (and registration processes) for candidate IdPoLRs.
Near Term and Possible Longer Term Candidate Services
UnitedId.org: Near term possibility
Embedded IdP in InCommon MFA IdP Proxy: Longer term possibility
Globus Nexus: Longer term possibility
Steps Entailed if Recommendation is Accepted
If InCommon endorses the primary recommendation, the next steps would include the following: