Overview

FedCM ("A privacy preserving federated identity Web API" - quote from GitHub) is several browser vendors go at ensuring users can still use buttons for "Sign in with <third party IdP vendor>..." even as the privacy preserving practices around third party cookies etc. are rolled out - privacy practises that would inevitably break the current login pattern. This baseline will enable us to continue offering our R&E community federated access as long as we take part in its development, and adapt our community's critical software stacks.

This new approach to protect end-user privacy that browsers are proposing appears to have a significant impact on R&E federation access practices. If you have software, have your developers reviewed https://fedidcg.github.io/FedCM/? Are they aware of a hackathon planned in Feb to test R&E tools and provide the W3C with feedback? Have you considered business continuity effects for your systems, especially if your suppliers do not address the new browser controls?

Meetings

Our meetings are currently weekly on Thursdays: Meetings 

If you have joined the W3C community group, their meetings are weekly on Mondays, with occasional time changes for Asia Pacific participation: Calendar

Deliverables

• Create a TL;DR, a recorded presentation (Geant), and include an initial resource center and find maintainers of the resource center. - Albert Wu Albert Wu Leif Johansson 
• A cadence of communications activities around FedCM in particular and browser changes in general focused on federation communities eg eduGAIN, CACTI/Internet2, etc. 
• Recommendations for how software developers /software stacks and federation operators implement and respond to Fed CM. – Leif J
• Common communication language for larger scale motivation of resources. - Chris P

Events

• IIW April 18-20
• TNC lightning talks
• TNC's REFEDS meeting: short report
• TechEx Sept. 18-22 in Minneapolis, Minn. : proposal
• 
  
• IIW October

Terms

The following terms apply to all REFEDS Working Groups:

1. 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.
2. A chair for the group is chosen from the REFEDS Participants.
3. GÉANT provides facilities for the working group, including meeting support, wiki space, mailing lists and, where appropriate, funding.
4. An appropriate output from the group is produced. Currently, this is typically a draft white paper or a wiki page.
5. 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.
6. 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.