Workflow

Sequence Diagram: OpenID4VP Cross Device Flow

In this flow, Inji Verify prepares an Authorization Request and renders it as a QR Code. The End-User then uses the Wallet to scan the QR Code. The Verifiable Presentations are sent to the Inji Verify backed in a direct HTTP POST request to a URL controlled by Inji Verify. The flow uses the Response Type vp_token in conjunction with the Response Mode direct_post, both defined in this specification.

1. Inji Verify UI sends a POST request to create a new Authorization Request with

• clientId: (required) - ID of the client requesting the Verifiable Presentation.

• presentationDefinition: One of presentationDefinitionID or presentationDefinition (required) - Presentation Definition for the Verifiable Presentation.

• presentationDefinitionID: One of presentationDefinitionID or presentationDefinition (required) - Presentation Definition ID for the Verifiable Presentation requesting, which is saved in backend.

• transactionID - (optional) - A unique identifier for the current authorization request transaction.

1. Inji Verify backend creates a new Authorization Request

2. Inji Verify backend returns the newly created Authorization Request

3. Inji Verify UI generates a QR code with response

4. Inji Verify UI Starts polling for the current transaction status

5. Wallet Scans QR code

6. Wallet reads the QR code data and initiates a OpenId4VP flow on wallets end.

7. Wallet creates a VP based on the VP selected VCs and POST it to responseUri from the QR code

8. Inji Verify UI Starts polling status becomes VP_SUBMITTED

9. Inji Verify UI requests for the submitted result with its verification statuses

10. Using transactionId Inji v will fetch the data from DB and validate it using vc-verifier and return the response(11) Using transactionId Inji Verify Backed will fetch the data from DB and validate it using vc-verifier and returns the response

11. Inji Verify UI renders the response accordingly

Sequence Diagram

Understanding the workflow:

Embedded VC data in QR code:

• The user sends a scan request to the Inji verify portal.

• Inji verify portal sends a scan request to the Device camera.

• The user will be prompted to ask for Device camera permissions.

• The user grants camera permissions.

  • The user scans the QR code using the device camera, and the QR data is returned to the Inji Verify portal.

  • Inji Verify passes the QR data to the Pixel Pass SDK.

  • The Pixel Pass SDK returns the decoded data to Inji Verify.

    • Inji Verify then passes the decoded data to the Verification SDK for verification.

    • The status is returned to the Inji Verify portal from the Verification SDK.

    • Inji Verify retrieves the display properties of the credential from the issuer’s well-known configuration.

    • Finally, Inji Verify displays the credential details using the fetched display properties.

  • The pixel-pass library fails to decode the data

    • Inji verify goes back to the home screen and displays the QR code format not supported error

• The user denies the camera permissions and the Camera permissions denied screen appears on the Inji verify portal

OpenID4VP (Online Sharing)

• User Scans QR Code:

  • The user opens the Inji Verify portal and scans the QR code using the provided scanner interface in the portal.

  • The QR code contains an authorization request with the URL of the Inji Web authorize endpoint and parameters like response_type, presentation_definition, and the resource URL from Durian.

• Inji Verify Constructs Authorization Request:

  • Inji Verify appends the necessary parameters to the authorization request:

    • client_id: Identifies the verifier (Inji Verify).

    • redirect_uri: Specifies where the user should be redirected after the authorization process.

• GET Request to Inji Web Authorization Endpoint:

  • Inji Verify makes a secure GET call to the authorize endpoint of Inji Web, sending the constructed authorization request.

• Verification of Verifier (Inji Verify) by Inji Web:

  • Inji Web checks its internal configuration for trusted verifiers. It verifies the client_id sent by Inji Verify to ensure it is authorized to request access to the VC stored in Durian.

• Retrieving the VC from Inji Web:

  • Upon successful verification, Inji Web retrieves the Verifiable Credential (VC) from the Durian storage (or any specified secure VC storage).

  • Inji Web generates a vp_token containing the VC in JSON format and redirects the user back to Inji Verify with the vp_token as part of the response.

• Inji Verify Receives and Verifies VC:

  • Inji Verify receives the vp_token containing the VC.

  • It performs a thorough verification of the received VC by checking:

    • The validity of the VC against the issuer's key (issuer key verification).

    • The integrity of the credential ensures it has not been tampered with.

• Displaying the Verified Credential:

  • After successful verification, Inji Verify showcases the verified credential in the user interface.

• Completion of Verification:

  • The user is presented with the verified credential, confirming successful online sharing and validation using OpenID4VP standards.

Upload QR flow:

Embedded VC data in QR code

• The user uploads a file with a QR Code.

• Inji Verify passes the QR data to the Pixel Pass SDK.

• The Pixel Pass SDK returns the decoded data to Inji Verify.

  • Inji Verify then passes the decoded data to the Verification SDK for verification.

  • The status is returned to the Inji Verify portal from the Verification SDK.

  • Inji Verify retrieves the display properties of the credential from the issuer’s well-known configuration.

  • Finally, Inji Verify displays the credential details using the fetched display properties.

• However, if Pixel Pass fails to decode the data:

  • Inji Verify navigates back to the home screen and displays the "QR code format not supported" error.

OpenID4VP (Online Sharing)

• User Uploads QR Code:

  • The user opens the Inji Verify portal and uploads a QR code file using the upload functionality in the portal.

• QR Code Details:

  • The uploaded QR code contains an authorization request with the URL of the Inji Web authorize endpoint and parameters like response_type, presentation_definition, and the resource URL from Durian.

• Inji Verify Constructs Authorization Request:

  • Inji Verify appends the necessary parameters to the authorization request:

    • client_id: Identifies the verifier (Inji Verify).

    • redirect_uri: Specifies where the user should be redirected after the authorization process.

• GET Request to Inji Web Authorization Endpoint:

  • Inji Verify makes a secure GET call to the authorize endpoint of Inji Web, sending the constructed authorization request.

• Verification of Verifier (Inji Verify) by Inji Web:

  • Inji Web checks its internal configuration for trusted verifiers. It verifies the client_id sent by Inji Verify to ensure it is authorized to request access to the VC stored in Durian.

• Retrieving the VC from Inji Web:

  • Upon successful verification, Inji Web retrieves the Verifiable Credential (VC) from Durian storage (or any specified secure VC storage).

  • Inji Web generates a vp_token containing the VC in JSON format and redirects the user back to Inji Verify with the vp_token as part of the response.

• Inji Verify Receives and Verifies VC:

  • Inji Verify receives the vp_token containing the VC.

  • It performs a thorough verification of the received VC by checking:

    • The validity of the VC against the issuer's key (issuer key verification).

    • The integrity of the credential, ensuring it has not been tampered with.

    • The VC verification happens at Inji Verify Backend, the Verify UI sends the VC to its backend and performs the verification using vc-verfier library.
• Displaying the Verified Credential:

  • After successful verification, Inji Verify showcases the verified credential in the user interface.

• Completion of Verification:

  • The user is presented with the verified credential, confirming successful online sharing and validation using OpenID4VP standards.

Additional Features:

• The Pixel Pass library now supports decoding CBOR QR codes and can provide details of verifiable credential (VC) data.

• Inji Verify can now handle the display of expired credentials, in addition to valid and invalid credential displays, using the same verification and display processes.

Note: To understand the Inji Verify components in detail please refer to the topic Components under Technical Overview section.