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, 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?). 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) and receives confirmation that ‘vetting is in process’.

Bob also provides his ORCID ID 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 (we do not say how ) 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, in fact, correspond with the living Bob (FaceMatch), checks if the document is valid, and confirm 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) 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)) and attests that Bob’s data is correct within the admin portal (SetAttribMediator) and that he meets admittance criteria.

By this confirmation, Alice, thus 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.

The IdP used by the MCAS portal can confirm Bob's identity and that he is entitled to access the MCAC API by invoking (JSON query with <USER ID> placeholder)