Internet2 is investigating a security incident involving a compromise to a confluence server that affected https://spaces.at.internet2.edu on April 10, 2019, which was successfully mitigated on April 12, 2019. If you did not receive an email from us, it’s unlikely that any of the content you submitted to the Internet2 Spaces Wiki needs to be re-entered. We apologize for any inconvenience this may have caused. Should you have any questions or require further assistance, please email collaboration-support@internet2.edu.
Child pages
  • Draft Process for the Assignment and Verification of Un-Affiliated IdP Tags

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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

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

...