Getting started (applicant)
Start by clicking the name of one of the offered claims (grey boxes within red ones) within Undeclared Attestations. Click "start" and provide the data requested (e.g. fill the form, follow the QR link or log in with an identity provider) (in the demo, shouldn't every QR be accompanied by the corresponding text content?). Upon successful completion, this will result in an addition to Presented Claims. Once these are approved by the Registration Authority (RA), they will be moved to Approved Claims and a corresponding Received Attestation will be produced. To see details or retract (remove?) / start (recreate?) a claim, click on the claim or attestation title. To return, click on "home". More at https://wiki.geant.org/display/gn43wp5/CommTrust+demonstrator+usage#CommTrustdemonstratorusage-Gettingstarted(applicant).
Getting started (RA)
The RA (registration authority) is responsible for approving claims that have been presented by applicants.
Start by clicking the name of one of the Unapproved Claims (yellow boxes), tick if the applicant is present in person, and click "approve" to confirm the claim (not "assertion"!). To disapprove, click on the title of one of the green claims that you approved (Claims Approved by ...) and click on"disapprove". Do we also need Other Approvals? More at https://wiki.geant.org/display/gn43wp5/CommTrust+demonstrator+usage#CommTrustdemonstratorusage-Gettingstarted(RA).
Glossary
... for developers is provided here
Step by step example
Available claims and attestations, as well as their names, sources and contacts, depend on the configuration of the system. Here provided is a walkthrough for an example that was set up in line with Remote vetting of the guest participant for access to a high Level of Assurance (LoA) project scenario:
Bob, an external researcher on the new Climate balance restoration project requires access to the restricted Massive Climate Archives Service (MCAS) to complete his thesis. The policy of this service is to demand strong identity vetting and multi-factor authentication, but also to check whether the users are genuine academic researchers.
Bob logs into the vetting portal with his guest identity student1/student1 and selects a token (from those he has and which he wishes to use), uses his token and is directed to a site giving him instructions on how to
He proves his identity using his passport by clicking at Undeclared Attestations > ID document > ReadID and following on-screen instructions (do we need a link to the ReadID app ib stores along with the QR?) Yes, for the case when Bob does not have the app on his phone we should. We should include a link. Following the instructions, he scans the presented QR code and downloads an application onto his mobile device (in the event he already has the application, from a previous session (say) he can skip the downloading step). He opens the application and is instructed to use it to scan his passport (PassportProof) perhaps here we could align the name of the claim in the demo app with the component use case name - so ReadID becomes PassportProof and receives confirmation that ‘vetting is in process’.
Bob also provides his ORCID ID ORCIDProof and confirms his name and email with a login to ORCID, which also confirms the possession of his ORCID credentials.
Later that day Alice, who is the vetting portal credential manager (RA), receives a notification that a new applicant request is pending. She opens the admin portal https://ra.incubator.geant.org/ with her staff1/staff1 credentials and searches for the applicant.
She makes contact with Bob and, using Bob’s mobile device camera and the picture from Unapproved Claims > ReadID (NO PHOTO YET!!!), verifies that the picture from his identity document does correspond with the living Bob (FaceMatch), This is the 'liveness' claim, so we could call it FaceMatch checks if the document is valid, and confirms the claim by clicking on "approve". Since access to stored climate documents is subject to very strict checks (to prevent rogue history revisionists) she checks Bob’s ORCID ID (ORCIDProof) via the ORCID API (AttribRelease) integrated into the admin portal using Unapproved Claims > ReadID by following the link to the ORCID page on Bob (we also need a new tab link such as https://orcid.org/0000-0002-5614-3516) We could do this or we could just say this is something the RA does by other means - does not have to be integrated into the application. confirms that he has a convincing academic record in the field, in line with the MCAS Admittance Policy, by clicking on "approve". by asking Bob to produce a reference from an esteemed colleague (ProvideRef) and verifying that this colleague is indeed on the list of validated reference providers (CheckRef) (if Bob had not been able to do this Alice would follow normal procedure and request such a reference (RequestRef)) Perhaps as we do not have this functionality, it could change in this example to be a self-asserted attestation that is approved by the RA. Or TOTP here? and attests that Bob’s data is correct within the admin portal (SetAttribMediatore t) and that he meets admittance criteria. again we will need to describe this as a workflow that could be done but is not a part of the demo - unless it can be added in a short time.
By this confirmation, Alice, satisfied, has created an "MCAS member" attestation (we can bind this attestation to ORCID approval). binds Bob’s identity to the token (MFABinding) and sends an email to Bob with a QR code that invites him to activate his selected token. Bob opens the email, clicks on the activation code and receives a message informing him that the token is activated. again I'm not sure we have this final step although we have a TOTP token to use.
The IdP used by the MCAS portal can confirm Bob's identity and that he is entitled to access the MCAS by invoking the JSON API https://app.incubator.geant.org/rest.php?id=<USER ID>, e.g. https://app.incubator.geant.org/rest.php?id=1.