This Wiki is available to view but still under maintenance. PLEASE DO NOT EDIT THE WIKI UNTIL FURTHER NOTICE. We are attempting to restore missing edits which took place between Monday 8 and Thursday 11 April 2019, therefore the site is likely to be taken off line at any time. Updated 20:43 CEST 16 April 2019.

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Update details for next meeting


LocationLocal timeTime zoneUTC offset
San Francisco (USA - California)9:00 AMPDTUTC-7
Madison (USA - Wisconsin)11:00 AMCDTUTC-5
London (United Kingdom - England)17:00 PMGMTUTC

Next Meeting


Topic: IoLR WG 
Time: Feb 4, 2019 5:00 PM London 

Join Zoom Meeting 

One tap mobilemobile 
+16465588656442030512874,,187642106# US (New York)739733064# United Kingdom 
+16699006833442036950088,,187642106# US (San Jose)739733064# United Kingdom 

Dial by your locationlocation 
        +44 203 051 2874 United Kingdom 
        +44 203 695 0088 United Kingdom 
        +1 646 558 8656 US  US (New York) 
          +1 669 900 6833 US  US (San Jose) 
Meeting ID: 187 642 106739 733 064 
Find your local number:

Join by SIP

Join by H.323 (US West) (US East) (China) (India) (EMEA) (Australia) (Hong Kong) (Brazil) (Canada)
Meeting ID: 187 642 106

Join by Skype for Business

- - - - - - - - - - - - - - - - - - - - - - - - - -   


- Notes of previous meeting(s) 
- Discussion/editing of proposed actions at 
- Use of Github for data and reports? 
- Use of Slack? 
- AOB 

Agenda, Live Scribing and Meeting Notes: 


Current Work Items

  • 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

  • Consider addressing the orphaned user problem by leveraging ORCID iDs

  • Update Self-assessment form for self-declaring Un-Affiliated IdPs


Older 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?"


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.


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.