trustchain-oc1-orchestral
/
idhub-docker
Archived
10
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update README.md 

Reformulate section "About pilots"
This commit is contained in:
mildred 2024-01-24 12:48:19 +00:00
parent 78a79e69e9
commit e044dadfcc
1 changed files with 77 additions and 64 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
README.md
View File

@ -2,21 +2,34 @@
## About the pilots that this repository deploys ## About the pilots that this repository deploys
- xo9b: - **XO9B**:
- motivation: one idhub connects to the other using OIDC4VP flow - Motivation: The aim is to support an accreditation program for vulnerable people, exploring the value of using verifiable credentials to get services/benefits.
- components: idhub1, idhub2 - Scenario: A vulnerable family obtains a benefit (internet connection fee discount) presenting a verifiable credential to an connectivity provider entity.
- setem:
- motivation: a user from org 1 connects to org 2 to get a discount code Actors-> **XO9B**: IdHub (acting as a user wallet), **Connectivity provider entity**: Demo portal (acting as Verifier Portal). The verifier portal incorporates verification capabalities and support to establish an OIDC4VP dialog with the user wallet.
- components: idhub1, idhub2 - **Setem**:
- lafede: - Motivation: Since SETEM is a federation, members of one of the federated entities (Setem BCN) can accredit their membership to other federation members (Setem Madrid) with a verifiable credential to obtain a discount.
- motivatiion: a user gets a verifiable credential presentation from idhub, optionally could be signed also using EIDAS1
- components: idhub1 Actors-> **Setem BCN**: IdHub (acting as a user wallet), **Setem Madrid**: Demo portal (acting as Verifier Portal). The verifier portal incorporates verification capabalities and support to establish an OIDC4VP dialog with the user wallet.
- pangea: - **Lafede**:
- motivation: - Motivation: Implementation of the dual model of EIDAS1-compliant signed PDFS that embed public verifiable credentials exported as QR codes embedded in these documents. Member organisations of the Lafede federation request membership and training certificates.
- a user from org 1 connects to org 1 services
- a user from org 1 connects to org 2 services Actors-> **Lafede**: idHub
- components: idhub1, idhub2, goauthentik services, orchestra (with also nginx api rproxy), musician
- test: intended for software quality such as testing, CI/CD, etc. - **Pangea**:
- Motivation: The case of Pangea as a web/internet service provider, with member organisations that receive services. These organisations have allocated several resources units (mail accounts, blogs, etc.). Only authorised users with a specific role should be able to access the Musician (Administration Control Panel of resources).
- Scenarios:
- Scenario 1-> 'Login with Organisation A (Idp)'. The staff members of organisation A, with the appropiate role, can authenticate themselves by providing their organisation credentials (username and password) to access a service in Pangea (Musician).
Actors-> **Pangea**: Idp (goauthentik), Musician, Orchestra. **Organisation A**: Idp, IdHub
Pangea delegates authentication to the idP of organisation B using OpenID Connect. In this case, the Pangea's IdP (goauthentik) delegates the authentication to Organisation A's IdP, which get the user's role information from the Organisation A's IdHub.
- Scenario 2-> 'Present a verifiable credential'. The staff members of organisation A, with the appropiate credentials, present them to Pangea in order to access the Musician service.
Actors-> **Pangea**: Idp (goauthentik), IdHub (as verifier), Musician, Orchestra (with also nginx api rproxy). **Organisation A**: IdHub (as user wallet)
- **test**: intended for software quality such as testing, CI/CD, etc.
## Installation ## Installation