Inji Verify SDK
OpenID4VPVerification Component
The below diagram illustrates the flow in which Relaying party UI is directly fetching the result from verify backend. Which is the current implementation of Inji Verify UI.
Relying Party UI initiates the process: The user interacts with the Relying Party's User Interface (UI) and triggers a verification action.
OPENID4VP UI Component communicates with Verify Backend: Upon the user's action, the Relying Party UI sends a request to Verify Backend. This request contains information needed to initiate the verification.
Verify Backend processes the request: The Verify Backend receives the request from the UI. It then processes this request. As part of the processing, the Verify Backend creates an Authorization Request.
Verify Backend sends the Authorization Request to the OPENID4VP UI Component: The generated Authorization Request is then sent back to the Relying Party UI ( OPENID4VP UI Component ).
OPENID4VP UI Component generates a QR Code: The component receives the Authorization Request and, based on its content, generates a QR code. This QR code will contain information that the user's wallet can scan. The generated QR code is then presented to the user through the Relying Party UI.
OPENID4VP UI Component Starts Status polling a QR Code: The component starts to poll for the current status of the Authorization request created.
User scans the QR Code with their Wallet: The user uses their digital wallet application to scan the QR code displayed by the Relying Party UI.
Wallet processes the QR Code and matching VC(s): The user's wallet application reads the data from the QR code and identifies the Verifiable Credential(s) (VCs) that are relevant to the verification request.
Wallet authenticates the user and submits the VP Token: The user authenticates themselves within their wallet application. Following authentication, the wallet constructs a Verifiable Presentation (VP) Token containing the necessary VCs and submits it to the Verify Backend (via a direct post to verifyService/vp-submission/direct-post).
Verify Backend sends a Status update to the OPENID4VP UI Component: Based on the validation result, the Verify Backend sends a status update to the OPENHVP UI Component. This status could indicate success (VP_SUBMITTED), ongoing processing (ACTIVE), or failure (EXPIRED).
Flow Ends and Control is passed to the Relying Party UI: The core verification flow concludes, and the Relying Party UI now has the status of the verification.
Relying Party UI passes the transaction result to the Relying Party Backend: The Relying Party UI communicates the outcome of the verification (including the verifyService/vp-result and potentially the transaction details) to its backend (Relying Party Backend).
Relying Party Backend acts based on the verification result: The Relying Party Backend receives the verification result and proceeds with the next steps in its application logic based on whether the verification was successful or not.
The below diagram illustrates the flow in which a authorization request gets expired.
OPENID4VP UI Component sends a Status update: The Verify Backend sends a Status update to the OPENID4VP UI Component. At this point, the status is something like EXPIRED or PENDING, indicating that the QR code is currently valid.
Time passes and the QR code expires: The Verify Backend sends a Status update to the OPENID4VP UI Component. At this point, the status is EXPIRED, indicating that the authorization request is currently expired valid.
OPENID4VP UI Component triggers the onQrCodeExpired callback: Upon detecting the expiration, the OPENID4VP UI Component triggers a callback function onQrCodeExpired .
The below diagram illustrates the flow in which an error occurs
An error occurs at OPENID4VP UI Component : An error occurs at OPENID4VP UI Component due to some response error, exceptions or expected errors.
OPENID4VP UI Component triggers the onError callback: Upon detecting the error, the OPENID4VP UI Component triggers a callback function onError .
There is an alternate flow available to implement if the Relaying party has a backend and the results needs to be fetched in the backend. The below diagram illustrates the flow in which Relaying party backend is directly fetching the result from verify backend.
Relying Party UI initiates the process: The user interacts with the Relying Party's User Interface (UI) and triggers a verification action.
OPENID4VP UI Component communicates with Verify Backend: Upon the user's action, the Relying Party UI sends a request to Verify Backend. This request contains information needed to initiate the verification.
Verify Backend processes the request: The Verify Backend receives the request from the UI. It then processes this request. As part of the processing, the Verify Backend creates an Authorization Request.
Verify Backend sends the Authorization Request to the OPENID4VP UI Component: The generated Authorization Request is then sent back to the Relying Party UI ( OPENID4VP UI Component ).
OPENID4VP UI Component generates a QR Code: The component receives the Authorization Request and, based on its content, generates a QR code. This QR code will contain information that the user's wallet can scan. The generated QR code is then presented to the user through the Relying Party UI.
OPENID4VP UI Component Starts Status polling a QR Code: The component starts to poll for the current status of the Authorization request created.
User scans the QR Code with their Wallet: The user uses their digital wallet application to scan the QR code displayed by the Relying Party UI.
Wallet processes the QR Code and matching VC(s): The user's wallet application reads the data from the QR code and identifies the Verifiable Credential(s) (VCs) that are relevant to the verification request.
Wallet authenticates the user and submits the VP Token: The user authenticates themselves within their wallet application. Following authentication, the wallet constructs a Verifiable Presentation (VP) Token containing the necessary VCs and submits it to the Verify Backend (via a direct post to verifyService/vp-submission/direct-post).
Verify Backend sends a Status update to the OPENID4VP UI Component: Based on the validation result, the Verify Backend sends a status update to the OPENHVP UI Component. This status could indicate success (VP_SUBMITTED), ongoing processing (ACTIVE), or failure (EXPIRED).
OPENID4VP UI Component triggers 'onProcessed' callback with the result: When the status indicates VP_SUBMITTED and the onProcessed callback is passed, the OPENID4VP UI Component triggers this callback, providing the result of the initial submission.
Relying Party UI receives the final result via the 'onProcessed' callback: The Relying Party UI receives the final verification result through the onProcessed callback, which now includes the validated claims.
Flow Ends and Control is passed to the Relying Party UI: The complete verification flow concludes, and the Relying Party UI can now use the validated claims to proceed with the application logic.
Scan/Upload Component
The below diagram illustrates the flow in which Relaying party UI is directly fetching the result from verify backend. Which is the current implementation of Inji Verify UI.
Initial Component Trigger and State (Relying Party UI):
Provider triggers component display: The Relaying Party initiates the process by initializing the QRCodeVerification component. This call includes several parameters:
triggerElement: The HTML element that triggers the component.
verifyServiceUrl: The backend service URL.
onVcReceived: A callback function for when the VC is received.
onError: A callback function for error handling.
isEnableZoom: A boolean to enable the zoom option.
isEnableUpload: A boolean to enable the upload option.
isEnableScan: A boolean to enable the scan option.
On-click trigger opens component (Relying Party UI): An onClick event on the Relying Party UI opens the component.
Handling Initial Errors (Relying Party UI):
Error returned immediately: If both isEnableScan and isEnableUpload are enabled (meaning neither scan nor upload is allowed), the component immediately returns an error.
User Interaction and QR Code Handling (User, Relying Party UI, QR Code Handler):
User chooses to upload and disable scan: The User makes a choice within the Relying Party UI to upload a QR code and disables the scan option.
Upload QR code: The Relying Party UI then handles the upload of the QR code, specifying accepted formats (PNG, JPEG, JPG, PDF).
User chooses to scan and disable upload: Alternatively, the User can choose to scan a QR code and disable the upload option.
Scan QR Code: The Relying Party UI proceeds with scanning the QR code.
QR Code Handler processes: In both upload and scan scenarios, the QR Code Handler receives the QR code data.
Decoding QR Code Data (QR Code Handler, Online VC Provider):
Decode QR data (Embedded VC): If the QR code contains an embedded Verifiable Credential (VC), the QR Code Handler decodes the QR data using the Pixelpass Library. This results in an embedded VC.
Decode QR data (Datashare URL): If the QR code contains a URL for the Online VC Provider, the QR Code Handler decodes the QR data using the Pixelpass Library to extract the Datashare URL.
Interaction with Online VC Provider and Redirection (QR Code Handler, Online VC Provider, Relying Party UI):
Redirect to Datashare URL: If an Datashare URL was obtained, the QR Code Handler redirects to this Datashare URL, passing along relevant parameters.
Validate data (Online VC Provider): The Online VC Provider validates data such as the signature.
Redirect to redirect_url: The Online VC Provider then redirects back to a redirect_url, including the vp_token and presentation_submission.
Verification (QR Code Handler, Relying Party UI, Verify Backend):
Request for VC verification result (QR Code Handler to Verify Backend): The component requests the Verifiable Credential verification result from the Verify Backend using the decoded VC (verifyServiceUrl/vc-verification).
Validate VC using VC Verifier Library (Verify Backend): The Verify Backend validates the Verifiable Credential (VC) using the internal VC Verifier Library.
Triggers onVcProcessed with the verification result (Relying Party UI): The onVcProcessed callback on the Relying Party UI is triggered with the vc and status.
The below diagram illustrates the flow in which an error occurs
Initiation of Scan/Upload UI Component (User, QR Code Handler):
Scan/Upload UI Component: The User interacts with a "Scan/Upload UI Component." This component is likely facilitated or provided by the QR Code Handler as suggested by the previous diagrams where the QR Code Handler was responsible for scanning/uploading.
Error :
Error Encountered (anywhere before successful verification): An error occurs at some point in the process before a successful verification can be achieved. This implies that the error can originate from various points:
Within the QR Code Handler (e.g., failed scan, invalid QR code format, network issues during OVP URL redirection).
Within the Relying Party UI (e.g., issues with component rendering, user input validation failures).
During communication between the Relying Party UI and QR Code Handler.
During communication between Relying Party UI and Verify Backend, or Relying Party Backend and Verify Backend.
Error Handling and Callback (QR Code Handler, Relying Party UI):
Trigger onError callback (with error details): When the error is encountered, the component or module where the error occurred is responsible for triggering an onError callback function. This callback is directed towards the Relying Party UI.
There is an alternate flow available to implement if the Relaying party has a backend and the results needs to be fetched in the backend. The below diagram illustrates the flow in which Relaying party backend is directly fetching the result from verify backend.
Initial Component Trigger and State (Relying Party UI):
Provider triggers component display: The Relaying Party initiates the process by initializing the QRCodeVerification component. This call includes several parameters:
triggerElement: The HTML element that triggers the component.
verifyServiceUrl: The backend service URL.
onVcReceived: A callback function for when the VC is received.
onError: A callback function for error handling.
isEnableZoom: A boolean to enable the zoom option.
isEnableUpload: A boolean to enable the upload option.
isEnableScan: A boolean to enable the scan option.
On-click trigger opens component (Relying Party UI): An onClick event on the Relying Party UI opens the component.
Handling Initial Errors (Relying Party UI):
Error returned immediately: If both isEnableScan and isEnableUpload are enabled (meaning neither scan nor upload is allowed), the component immediately returns an error.
User Interaction and QR Code Handling (User, Relying Party UI, QR Code Handler):
User chooses to upload and disable scan: The User makes a choice within the Relying Party UI to upload a QR code and disables the scan option.
Upload QR code: The Relying Party UI then handles the upload of the QR code, specifying accepted formats (PNG, JPEG, JPG, PDF).
User chooses to scan and disable upload: Alternatively, the User can choose to scan a QR code and disable the upload option.
Scan QR Code: The Relying Party UI proceeds with scanning the QR code.
QR Code Handler processes: In both upload and scan scenarios, the QR Code Handler receives the QR code data.
Decoding QR Code Data (QR Code Handler, Online VC Provider):
Decode QR data (Embedded VC): If the QR code contains an embedded Verifiable Credential (VC), the QR Code Handler decodes the QR data using the Pixelpass Library. This results in an embedded VC.
Decode QR data (Datashare URL): If the QR code contains a URL for the Online VC Provider, the QR Code Handler decodes the QR data using the Pixelpass Library to extract the Datashare URL.
Interaction with Online VC Provider and Redirection (QR Code Handler, Online VC Provider, Relying Party UI):
Redirect to Datashare URL: If an Datashare URL was obtained, the QR Code Handler redirects to this Datashare URL, passing along relevant parameters.
Validate data (Online VC Provider): The Online VC Provider validates data such as the signature.
Redirect to redirect_url: The Online VC Provider then redirects back to a redirect_url, including the vp_token and presentation_submission.
Verification and Submission (Relying Party UI, Verify Backend, Relying Party Backend):
Send VC (Relying Party UI to Verify Backend): The Relying Party UI sends the Verifiable Credential (VC) to the Verify Backend for verifyServiceUrl/vc-submission
Sends UUID in response (Verify Backend to Relying Party UI): The Verify Backend sends a UUID back to the Relying Party UI in response.
Trigger onVcReceived (Relying Party UI): The onVcReceived callback function on the Relying Party UI is triggered, passing the vc_status (verification result).
Flow ends and passes control to Relying Party UI: The main flow concludes, and control is passed back to the Relying Party UI.
Pass UUID to Relying Party Backend: The Relying Party UI passes the received UUID to the Relying Party Backend.
Request for VP verification result (Relying Party Backend to Verify Backend): The Relying Party Backend requests the Verifiable Presentation (VP) verification result from the Verify Backend using the UUID (verifyServiceUrl/vc-verification/{uuid}).
Validate VC using VC Verifier Library (Verify Backend): The Verify Backendvalidates the Verifiable Credential (VC) using a VC Verifier Library.
Return verification status (Verify Backend to Relying Party Backend): Finally, the Verify Backend returns the verification status (e.g., valid, invalid, expired) to the Relying Party Backend.
Last updated
Was this helpful?