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 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.

<Enter here>Based on the specified flow, tools to support and implement the flow need to be identified.

The following output 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: to deliver

#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#

#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

• 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