This should be taken as nothing more than a spur to further discussion in the appropriate forum at the appropriate time.
The Challenges
We have a vetted list of requirements that an IdP would have to meet in order to serve the need for an Open R&S Identity Provider (ORSID <== better term than IdP of Last Resort, but no cigar: find another term).
We want to define a standard process by which federations can assess candidate ORSID providers and tag the approved ORSIDs.
We want to assure the long-term stability of identifiers issued by ORSID providers.
We want to assure that a person always has the option to migrate from one ORSID provider to another.
We want to allow individuals to carry the same identifier even if they move from one ORSID provider to another.
We want to assure that ORSID services are continuously available as long as they are filling a need for the Research and Scholarship community.
The Questions, Some Answers
Q: Should people be able to enable more than one ORSID to authenticate them? Ie, beyond moving from one to another?
If the solution involves assigning people a portable identifier value that could be asserted by two different ORSID-tagged IdPs, it would be possible for people to authenticate with either IdP; If that is a problem, then it would be necessary to prevent or forbid this from happening.
In the case of two IdPs for a user, attribute values received by an SP could differ depending on the choice of IdP.
TB: Should we anticipate that more than one ORSID will come into operation in the world? I think so. If so, it is possible that some will be relied on by some VOs and others for others? Eg, perhaps for reasons of data privacy regulatory compliance, or because an ORSID is an integral part of a larger piece of infrastructure designed to enable and manage VOs (and provide attributes of relevance to those VOs). If we do not enable a researcher/collaborator to be able to use more than one ORSID, we may create an impediment to their work.
The Plan An Approach for Discussion
InCommon and the UK Access Management Federation will collaborate to define a process for evaluating and tagging candidate ORSIDs.
InCommon and the UK federation will tag at least one ORSID as soon as feasible and assure that it operates for a minimum of two years.
The InCommon and UK federations will seek to designate additional IdPs as ORSIDs with the goal of having at least two production ORSID providers in operation at any one time.
REFEDS will create a working group to feed the knowledge gained during the InCommon/UK Access Management Federation into, and to draft and finalize a REFEDS-level ORSID entity category
KeithH Note: Tom Barton suggested in an email of Oct. 19 in the thread "Re: [TAC-InC] Draft TAC Minutes - 7-October-2015" that we might be wise to get a two-federation agreement on process and have a successful trial before approaching Refeds. For further discussion.
eduGAIN will adopt the entity category and require member federations to abide by its terms
KeithH Note: That may be more responsibility than the eduGAIN organization wants to take on. For further discussion.
IAY note: eduGAIN does have a process for adopting mandatory profiles, but requires a supermajority of participating federations for such a profile to be adopted (given that refusing to comply would mean ejection from eduGAIN, this seemed a prudent constitutional approach). I'd advise not proceeding on the basis that the process could be successfully invoked for this. Having individual participant federations adopt an entity category voluntarily under REFEDS (not eduGAIN) guidance (not requirement) is more likely to be viable in the short to medium term. Long term, of course, if something is universally recognised as desirable then a different approach can be taken.