You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 73 Next »


Next WG call: Monday, December 12

Agenda and Notes: Monday, October 31

The World Clock Meeting Planner - Details

NOTE: US is still on Daylight Savings Time for one more week, so time differences are skewed

  

LocationLocal timeTime zoneUTC offset
Madison (USA - Wisconsin)Monday, October 31, 2016 at 9:00:00 AMCDTUTC-5 hours
London (United Kingdom - England)Monday, October 31, 2016 at 2:00:00 PMGMTUTC
Amsterdam (Netherlands)Monday, October 31, 2016 at 3:00:00 PMCETUTC+1 hour
Corresponding UTC (GMT)Monday, October 31, 2016 at 14:00:00  

 

Agenda, Live Scribing and Meeting Notes: http://bit.ly/iolrNotes 

Agenda, Monday, Oct. 31

  • List Research SPs that might be in need of Un-Affiliated IdPs

          - See email thread, "Re: Other SPs for unaffiliated IdPs"

  • Review sustainability strategies

          - See email thread, "Re: Funding an unaffiliated IdPs

  • Participation in SIRTFI (federated incident handling agreements) as an item on the Un-Affiliated IdP checklist
  • Consider addressing the orphaned user problem by leveraging ORCID iDs
  • Update Self-assessment form for self-declaring Un-Affiliated IdPs
  • Respond to Request from REFEDs Assurance WG

          - Pål: Mark IoLR IdPs with some type of metadata tag. Is that something you have thought of?

 

 

  • Work Items


Internationalize the Requirements for R&S Un-Affiliated IdPs



Define Acceptable Bases of Trust

  • Self-assertion? Reputation-based? Tagging by fed. operator?

 

Mitigate “Single (IdP) Point of Failure” for Users

  • The most difficult challenge: "What if my un-affiliated IdP of choice goes out of business? What happens to all my existing access paths?"
  • Overview

This is the wiki space for the IdPs of Last Resort (IoLR) Working Group.  To participate in this group, please subscribe to the mailing list.

Service Providers (SPs) often f­ind that the population they want to serve includes individuals who are not represented by campus-based or other institutional Identity Providers (IdPs). In other cases, the individual's organizational IdP can not (or will not) release attributes necessary for the operation of the SP. The two most commonly encountered accommodations for users in this situation both suffer from serious inadequacies. First, SPs can opt to issue credentials and run an authentication service for those users lacking an adequate federated solution. The drawback is that this forces the SP owners to take on the unwelcome role of issuers and managers of user credentials. It is not their core mission and it can easily become a substantial support burden.  The second fallback is to accept external IdPs such as Google. This gets the SP owners out of the credential management business, but brings other issues. To take Google as an example, Google’s IdP-like service comes with several caveats: Their business model is premised on monetizing user and usage data; As a non-SAML solution, they don’t support the Enhanced Client or Proxy (ECP) Profile, a critical requirements for some key research services; They also reserve the right to throttle usage if it gets above what they consider an acceptable level of use.

A different approach is clearly needed. Ideally, individuals lacking a suitable IdP could be invited to register with a participating IdP that offered no-cost, easy self-registration processes. This REFEDS Working Group is charged with specifying how such a service should be structured and establishing processes for reviewing and approving IdPs that seek to be designated as "Un-Affiliated IdPs", or informally, "IdPs of Last Resort" that meet the Service Providers' requirements. For some additional background, see the 2015 Final Report of the InCommon Technical Advisory Working Group, IdPoLR.

  • Terms

The following terms apply to all REFEDS Working Groups:

  • When a working group is agreed, REFEDS Participants will be asked if they wish to participate. Working Groups tend to be small, so consensus can be achieved quickly between participants.
  • A chair for the group is chosen from the REFEDS Participants.
  • TERENA provides facilities for the working group, including meeting support, wiki space, mailing lists and, where appropriate, funding.
  • An appropriate output from the group is produced. Currently, this is typically a draft white paper or a wiki page.
  • When the Working Group is in agreement, the chair shares the outputs with the wider REFEDS community with an open period for discussion and comment. This is typically a period of 4 weeks, but may be longer if appropriate.
  • After this period of time, the REFEDS Steering Committee signs off on the work item. Work is either written up as a formal white paper, left on the wiki but promoted as finished work or occasionally submitted as an Internet Draft.
  • Convener

Keith Hazelton, UW-Madison and Internet2

  • Calls

  • Mondays, June 27 and bi-weekly thereafter
  • 9 am US Central, 3 pm UTC, 4 pm CET (except during Daylight Savings Time mis-match between US & Europe)


  • No labels