...
Later that day Alice, who is the vetting portal credential manager (RARA), receives a notification that (we do not say how 
)Yes, that is a detail we do not need to cover 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 mobile device camera and the picture from from Unapproved Claims > ReadID (NO PHOTO YET!!!), verifies that the picture from his identity document does , in fact, 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 could do this or we could just say this is something the RA does 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 o 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, 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. 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 MCAC API 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.