Release 2.0 : Analysis, Code Review and Design discussions

[Sreejit-K]

What is the feature request for?

Registry Core

What problem/inconvenience (if any) will this feature solve?

It is inconvenient for me to do .... If we add this feature, it would make it easier to do ....

Describe the feature clearly.

Add a new feature that does ....

[manukalia29]

Go through the existing ULP flows for verification and Holder apps and make plan on making them generic - [x

• [ ] Holder
• [x] Verification

[Sreejit-K]

https://beehyv0-my.sharepoint.com/:w:/g/personal/sreejith_k_beehyv_com/Eeb8usUSmn9DmP_10mPvfBMBSszVlP5EI_GevQ5v3RL_Bg?e=1ZZgc9

[srprasanna]

@Sreejit-K can you add the document here itself.

[Sreejit-K]

Holder-App:

Features that we already have:

• User login SSOs: The user can login using multiple options listed.

• User Registration: The user can register themselves on the portal by providing personal information.
• Proof Of identity (optional): The user can prove identity by sharing a recognised id (like Aadhar).
• Proof Of Association (optional): The user can prove the association with an organisation.

• View Credentials: The holder can view the credentials issued to them.
• Raise Grievance: The holder can undertake 2 functionalities here:
• Raise request for issuance of a credential: They can raise a request for a credential with the issuer
• Request updates in the existing credential: Raise a request for an update in the info entered.
• View Profile: The issuer can view personally identifiable information entered by them in this section.
• Discover Opportunities: The holder can view opportunities listed and apply for them

Note: 3,4,5,7 should be removed to make it more generic to sunbird-rc.

Interaction with BFF services:

The UI interacts with the below services of bff -

• Credentials service
• Schema service
• Learner service
• Issuer service
• Sbrc service
• Grievence service
• Claim-Attest service

Changes needed:

Create and Issuance API – which mainly has these functionalities

• Check if the user already exists (we will use email, name & mobile Number as Ownership attributes)
• If user already exit fetch his fetch his existing DID. Else create one
• Create a keycloak user for the same.
• Use this DID as the credential Subject ID while creation of the credentials
• The req body is same as we use for creating a credential using the credential service.

• Change the Schema from Learner to User and make corresponding changes in the ULP-BFF
• Add OwnerhipAttributes in the Schema – so that user can login through keycloak – default
• In Current flow, username is basically the mobile number of the User
• Mock the Aadhaar/ digi-locker /meri-pehchan verification functionality (ssoLogin) in ULP BFF
• Opportunities tab should be removed.
• Add API to fetch Credentials based on different credentials-schems.

Observations : We can add the claims and Attestation flow when we plan a dedicated issuance portal. Need changes in the claims and attestation flows. The Grievence, Claim-Attest service are using the sunbird RC v1.0.0 to store the claim status and the grievance status by defining corresponding schemas.

Current Claims/ grievance Flow: The Learner raises a claim or a grievance ---> this will be stored in the Claim Attest, Grievance table respectively and this data is fetched in the Issuance portal by the instructor, and he takes the appropriate action based on the school_id which is common to both Learner and the Instructor.

• If he accepts the claim --> a new VC is issued to the Learner and linked to his did
• If he Accepts the Grievance --> the details will be updated along with the VC.

We need to replace this with the RC claim-attestation flow of Sunbird-RC. Or make it optional based on the use case Raise Grievance, add and view documents from dig locker tabs should be pluggable and not mandatory tabs on the home page Learner service of bff is used for the user/holder login - (we need to think of changing the schema name or use the same name)

Note: The learner service basically uses the Learner schema defined in the RC to store the corresponding DID, SSO details and other status updates. - these are stored in the registry.

---

Verification- UI :

Features that we already have:

• Scan’s the QR code.

• The credential opens as a PDF Doc.

Current Verification Flow:

• On Scan, the UI fetches the credential DID
• If scanning fails ---> ‘Invalid QR code try again’ message is displayed on the UI
• Then it hits the ‘/v1/credentials/verify/${id}’ endpoint of the BFF repo
• Error while verifying ---- > ‘Credential not verified’ message is displayed on the UI
• If there is a Success response from the verify API
• Checks for the expiry

• If yes ---> ‘Credential Expired’ message is displayed on the UI
• Else ---> “Credential Verified” message is displayed on the UI

• On Successful verification it tries to fetch the credential as a PDF using ‘/v1/credentials/render’ endpoint of BFF repo

Interaction with BFF services:

The UI interacts with the below services of bff -

• Credentials service
• Schema service (a.k.a credential-schema service)
• Sbrc service (to fetch keycloak client token with a default password ‘test@1234)

Changes needed:

In BFF:

The ‘/v1/credentials/render’ endpoint has a token-based authentication layer before generating the pdf and sending it back. We must remove this dependency on the sbrc service. So that we can access the Credential as a PDF directly

In UI :

• The revocation status is not handled in the UI so we must make changes to include that.
• Few Errors handling is missing - like while failing to fetch the PDF, or the template etc must add those
• Token based dependency changes in the UI.
• Verification- UI is almost generic we just need to tweak a few things on how to display the data
• Do we need to display the data as a JSON? (open question)

Observations

To generate a credential ---> we need Template ID
But template ID is linked to the schema ID Though the Schema Id is mapped to the credential ---> we are unable to fetch it though the endpoints that we have right now

Create a new get API which fetches the credntial-schema linked to the credentials (Not available rn) Or figure out why the “credential_schema” feild is not reflecting while fetching the data by credentialId.