Give FeedbackGovStack Home

9 Internal Workflows

This section provides a detailed view of how this Building Block will interact with other Building Blocks to support common use cases.

the If GovStack will offer global workflow management for cross-building block use cases, Identity and Verification Building Block will have its internal workflows for its own internal business flows execution.

Non-exhaustive list of examples:

  • For onboarding a new individual.

  • For managing identity changes after an event on a person's identity (name change, death, etc.).

  • For life cycle management of an individual's identity evidence (i.e. ID Cards).

  • For management of access rights to services on an individual's data.

Those workflows will be described in a later version.

9.1 Identity Verification Workflow

The below workflow details the steps involved in the relying party application enabling the end user to log in using their National ID. Once the login process is completed, Identity Building Block also allows the relying party to get verified user claims based on explicit permission from the end user.

9.1.1 Verification with user claims

The steps are:

  • The relying party wants to authenticate the user to the Identity Building Block.

  • The relying party redirects the user to the Identity Building Block UI.

  • The user will authenticate on the Identity Build block.

  • The Identity Build Block will ask the user permission to share his/her personal data.

  • The User selected the attributes he/she accepts to share.

  • A code is generated and returned by the Identity Building Block to the relying party.

  • The relying party uses the code and receives an ID token and an access token.

  • The relying party then uses the access token to receive the user information.

  • The user can pursue its application within the relying party UI.

9.1.2 Verification without user claims

If the relying party wants to verify the identity of the end user without user information, then a lean workflow can be adopted. The steps of lean flow are similar to the workflow steps in previous section. However, during /authorize API call, the scope is set to "openid". This informs the IDBB UI that no user claims will be accessed and thus IDBB UI doesn't show any consent page and these steps are skipped in the workflow.

9.2 Identity Management Workflow

The enrollment process differs from country to country and the enrollment data collection can be done in-person, or ported from existing servers. Here sample workflows are shown.

9.2.1 Enrollment Workflow (Fresh Enrollment)

These are the sample steps for fresh enrollment where the enrollment data is collected afresh:

  1. User goes to the Enrollment office.

  2. The Enrollment Client collects user demographic details and supporting documents and calls the createPacket API of the GovStack Packet Store.

  3. Enrollment Client collects user bio-metric details and calls createPacket API of GovStack Packet Store.

  4. Once all the enrollment data is available at the GovStack Packet Store, it triggers enrollment process in the GovStack Packet Processor.

  5. GovStack Packet Processor processes the data and generates a Unique Identity for the user.

  6. The user is notified of successful enrollment and receives the Unique Identity by mail.

9.2.2 Enrollment Workflow (Enrollment with existing database)

These are the steps for enrollment using existing data, in which the demographic details are collected from an existing database and biometric data is collected afresh.

  1. The user goes to the Enrollment office.

  2. The enrollment Client retrieves the user demographic details and supporting documents from an existing database and calls the createPacket API of the GovStack Packet Store.

  3. Enrollment Client collects user biometric details afresh and calls createPacket API of GovStack Packet Store.

  4. Once all the enrollment data is available at the GovStack Packet Store, it triggers the enrollment process in the GovStack Packet Processor.

  5. GovStack Packet Processor processes the data and generates a Unique Identity for the user.

  6. The user is notified of successful enrollment and receives the Unique Identity by mail.

9.3 Credential Management

9.3.1 Sharing Credentials

This sequence diagram shows the workflow for sharing credentials.

  1. The user logs into the Citizen Portal.

  2. After authentication, the user can select the format of the credentials to be shared. The format is defined by the attributes such as fully/partially masking.

  3. The user gives consent for sharing the credentials and logs a request. The Citizen Portal returns an event ID.

  4. The user logs in to the Citizen Portal after some time and checks the status of the credential-sharing request using the event ID.

  5. The credentials can be provided as a Verifiable Credential in PDF format with the issuer's signature.

9.3.2 Download Credentials

This sequence diagram shows the workflow for downloading a Unique Identity Card:

  • The user logs into the Citizen Portal.

  • After authentication, the user clicks on the Download Card.

  • The Citizen Portal calls the '/download/personalized-card' API on the IDBB.

  • IDBB returns a link for the card download.

  • The Citizen Portal shares the link with the user.

9.4 Notification Workflow

Last updated

Copyright © 2024