Page History

In the past years, technology for validating a user's identity using a combination of a mobile phone, an identity document like a passport with NFC chip and improvements in real time facial recognition technology, have made real time, remote and trusted identity validation viable. As a result several vendors are now offering such a service, such as READ.ID and SisuID.

In the R&E community there are multiple use cases for this kind of technology. Two very dominant cases are:

• Identity vetting for research communities, typically as part of the onboarding of a user into the community. This use case [1] was brought up by CSC/Elixir and there are indications also BBMRI and Lumi EuroHPC project would benefit from such capabilities.
  The use case was also previously identified in the work in the incubator on identity vetting and 2FA token binding and led to an activity that integrated with the READ.ID service. In addition, eduTEAMS has shown interest in having this capability.
• Identity vetting for foreign students who are enrolling into a campus. This scenario was brought up by SURF, and CSC expressed interest in such a capability as well.

Other potential use cases may include the use of a passport for second factor authentication and using it as a way to do token recovery of other 2FA tokens.

Previous work in the incubator (on READ.ID) and also within CSC/Elixir (on SisuID) have shown that on the technical side implementation of such services which are offered by vendors is not too difficult for a skilled technical team. However, typically the APIs and interfaces offered by the vendors do not align well with commonly used APIs in the R&E community. Furthermore, while the vendors services provide similar capabilities highlevel, there are some differences e.g in LoA which can be established and in user experience.

This activity will investigate the a possible business case for creating and operating a neutral, pan EU identity validation broker, targeted toward EU research and education use cases. The platform should offer (one or more) standardized APIs towards consuming services (SAML/OIDC/REST), while engaging with multiple platforms offering identity validation capabilities. For vendors the platform should be an open platform. This multi vendor strategy will allow NRENs, Campuses, Research Communities and perhaps even end users to make their own choices about which vendors to engage with, while still benefiting from standardized interfaces and economies of scale.The platform and its operator should take care of integration with the vendors as well as take care of technical, legal and security considerations that come with the operation of such a platformto support identity verification and will consider a number of ways of delivering this (e.g. as an identity broker for a range of possible commercial identity verification services, as a GEANT offered service, as an information portal pointing to services etc).

• Stakeholders may have very different requirements that cannot be reconciled into one modelThe preferred model may bring unacceptable challenges to a potential operator
• A centralized solution may not be cost effective
• A centralized solution may not be sustainable