The FIM4R community met on June the 17th 2021 for the first time since their in-person meeting in Vienna 2020. Many thanks to all those who presented and joined the discussion! The objective of the workshop was to raise our collective awareness of assurance for federated identity and consider how it can be of use to mitigate risk to our Research Communities.

We kicked off with an overview of assurance and assurance profiles by Jule Ziegler (LRZ); Jule talked us through the approach to a risk assessment for determining required levels of assurance, and went into detail on the approach taken by the REFEDS assurance profile. This was followed by Alan Lewis (G√ČANT) on the latest trends in identity proofing. We heard about the difference between data-centric and document-centric proofing strategies and their use cases.

Next, Mikael Linden (CSC) talked us through two use cases for assurance within Research Communities; Elixir integrating ORCID Multifactor-Authentication (MFA) and an implementation of the REFEDS assurance profile in the Life Sciences AAI. All slides are available on the Agenda.

The remainder of the session was spent in breakout rooms where we attempted to answer questions such as:

“What degree of risk to your project or e-infrastructure is posed by an unintended person being allowed to login? Is the impact low, medium, or high, compared to other unfortunate things that might happen? Why?”

We quickly realised that such topics require much more time than 30 minutes! The diversity of our Research Communities also means that answers vary dramatically – those dealing with sensitive data accessible over web interfaces have many more immediate use cases than those with non-sensitive data. Of course, assurance is not only of importance for researchers; the level of assurance of infrastructure administrators is critical. What is less clear is how much of this administration is carried out by federated identities and could benefit from widespread adoption of assurance profiles.

One interesting remark expressed by several people was that we must trust that these expressions of assurance are accurate. Failure to trust home Identity Providers in this implies that we equally do not trust them to authenticate users, which is the foundation of federated identity. This particular point, about our willingness to accept assertions of assurance from third parties, certainly requires elaboration.

There was a resounding expression of interest in continuing the discussion and working towards a whitepaper to express the views of the FIM4R Community. We will be reaching out soon to continue work in that direction.