Participants
...
| Panel |
|---|
| title | Contact data | | Proposers |
|---|
|
|
| Panel |
|---|
Please provide contact details for | | participants involved in this activity
|
|
| Panel |
|---|
| title | Contact data of Parties involved | Stakeholders |
|---|
|
| Name | Organisation | Role |
|---|
| Laura Paglione on behalf of ORCID | ORCID |
Please provide names and contact details for additional (external) organisations involved in this Incubator project
|
Activity Overview
| Panel |
|---|
|
Many research collaborations as well as campus services need a solution to deal with guest identity, as in many cases not all users are members of the academic Identity Federations. As a result several federation operators as well as research collaborations operate IdPs or proxies to allow users to authenticate trough external identity providers like social ones. THis This has lead to serious reinventing of the the wheel. The need for guest identities burdens the SPs with the integration costs and along the way may force guest users to use specific IdPs as implemented by the SP, which they may not want or may not be able to use, only because the SP decided only to implement a few of these solutions. In the GN4-2 project a first pilot was run as part of the eduTEAMS activity to investigate if a centralized service could be offered to resolve these issues. This resulted in solution named IDhub that uses SaToSa product. The aim of eduTEAMS service this solution was to resolve these issues by providing a solution that is technically alike any other IdP in edUGAIN eduGAIN so the integration cost is reduced to zero, and offers offer multiple IdPs so the guest users may choose what they want/can to use. This pilot aims to bring ORCID into the IDhub solution, with formal support from ORCID(SaToSa) solution. It also investigates the (technical) improvements needed to better scale the IDhub solution and will begin a dialog with the service activities to make the pilot move towards a full service offering under the GEANT umbrella.IDhub. At the same time it will investigate the requirements to be able to offer such a service with formal support from ORCID. |
| Panel |
|---|
|
Please describe the goals of pilot, including activities, participants, the community(ies) that require a solution. Describe when the pilot is done and how to measure the success of it, in a SMART way. <Enter here> |
...
- Implement the ORCID member API into IDhub (SaToSa)
- Identify requirements and issues that would prevent GEANT from operating this as a service
|
Activity Details
| Panel |
|---|
|
| Technically this is an application of SATOSA SaToSa where the south side is a SAML IdP exposed to GEANT or other SAML federations the north side is ORCID API, which is based on OAuth. |
| Panel |
|---|
|
| Business case: It is assumed this service can be maintained at low cost and enhances the appeal of eduTEAMS and eduGAIN, and at the same time it creates a good relationship with ORCID. |
...
| Panel |
|---|
| title | Data protection & Privacy |
|---|
|
| We are going to accept users and their personal data Users personal data will be processed when the data will be handled from ORCID into the SAML side, therefore we have to have a data protection policy about how this data is handled needs to be defined. |
| Panel |
|---|
| title | Sustainability | Definition of Done (DoD) |
|---|
|
The project is finished when: - ORCID API can be used for authentication in the IDhub (SaToSa)
- requirements and issues have been identified that would prevent GEANT project form offering such an IdP into eduGAIN
|
| Panel |
|---|
|
| The intent is to initially offer this as part of eduTEAMS |
Activity Results
| Panel |
|---|
|
See documents provided belowThis is a low-cost operation that is planned to be maintained as an eduTEAMS application.
|
Meetings
...
Documents
ORCID IdP as a Last Resource Business Case Analysis
