This activity constitutes to be the follow-up activity of the topic Second Factor Authentication - Distributed Vetting (see: https://wiki.geant.org/x/zLAuBw) of the previous Incubator cycle. It investigates analogously to the preceding cycle how identity vetting and token registration can be scaled for second-factor authentication scenarios where participants are distributed over EU and beyond and thus takes into account the report which was delivered as part of the first Incubator cycle.

As part of this activity a specific flow - based on a community-based approach - will be investigated. It takes into account the concept of the Web of Trust which is also used in (Open)PGP to establish a binding between a key and its owner. While this mechanism typically does not work well in broad user groups, it is very well suited to distribute trust between small groups where a pre-existing trust fabric is already in place, as we typically have in research communities. What seems to be missing is a means to make this trust network auditable and transparent. In order to make the trust network transparent, this activity seeks to identify/develop tools to support this flow.

• Workflow specification based on a community-based approach (i.e. either in text format and/or graphical visualization such as BPMN flow(s))
• Report on identification of tools (e.g. REMS: https://confluence.csc.fi/display/REMS) to support the flow
• Example implementation of at least 1 such a workflow
• Demonstration at the relevant venue
• Describe how the vetted identity may be used in common authN and AuthZ systems like eduTEAMS
• It was noted the proposed work aligns well with recommendations made by the InCommon XYZ. We should discuss.

#Please describe the goals of Activity, including what needs to be delivered, participants, the community(ies) that require a solution. Describe when the Activity is done and how to measure the success of it, in a SMART way. - delete this line after using the template#

Based on the specified flow, tools to support and implement the flow need to be identified.

The following outputs of the previous Incubator cycle will be taken into account:

• Wiki page: https://wiki.geant.org/x/zLAuBw
• Report of the previous Incubator cycle

#Please describe the technical details for the Activity. - delete this line after using the template#

#What is the business case for the Activity? Who would be beneficiaries of the results of the Activity and what would potential business case look like if applicable? - delete this line after using the template#

<Enter here>

#Are there risks that influence either the implementation of the activity or its outcomes? - delete this line after using the template#

<Enter here>

• Keep the community-based approach in this iteration as simple and user-friendly as possible in order to avoid complexity which might lead to incomplete work
• Solution might not fulfil 100% of the use cases

#How do data protection and privacy impact the Activity? Think about e.g. handling of personal data of users - delete this line after using the template#

<Enter here>Personal data which is processed during the act of identity vetting must be reduced to a minimum and transmitted/stored by using cryptographical means.

#Please describe here the set of criteria that the product must meet in order to be considered finished. - delete this line after using the template#

<Enter here>

• Intended to be used in the scope of research communities
• Engagement with eduTEAMS task and Stepup solution

#How are the results of the Activity intended to be used? If this requires further engagement, can you describe how you intent to sustain it? - delete this line after using the template#

• Integration with readID
• Documentation produced
• Demonstrator (publicly available) integrating with readID, ORCID, google
  • RA management web interface: https://ra.incubator.geant.org/index.php
  • Applicant web interface: https://app.incubator.geant.org/
  • The following internal test IdP accounts can be used to access the web interfaces: https://github.com/OpenConext/OpenConext-DIY/blob/master/group_vars/logins.json All user interfaces hide actual attributes harvested from real IdP's like google and orcid. staff1 has access to the RA part of the application.
  • Code available via Github: https://github.com/mrvanes/commtrust