-
Notifications
You must be signed in to change notification settings - Fork 174
Inji Web OpenID4VP and Agama Integration
The Agama-Inji-Wallet project enables an OpenID Provider to accept a credential presentation from the MOSIP Inji web wallet using OpenID for Verifiable Presentations protocol (OpenID4VP). The Agama flow serves as the orchestration layer — sending REST API calls to Inji Verify, constructing OpenID4VP requests, managing transaction states, and providing feedback to the user based on verification outcomes.
| Actor | Description |
|---|---|
| User | End-user initiating credential verification. |
| Inji Web (Wallet) | User’s credential wallet responsible for holding and presenting VCs. |
| Agama Application | Janssen orchestration engine coordinating the entire verification flow. |
| Inji Verify | Verification service responsible for validating presented VCs. |
The Inji Web OpenID4VP and Agama Integration project enables the Janssen Agama orchestration engine to interoperate with Inji Web (wallet) and Inji Verify using the OpenID for Verifiable Presentations (OpenID4VP) protocol.
This integration allows a user to verify credentials stored in their Inji wallet through an orchestrated Agama flow. Agama serves as the orchestration and decision-making layer — handling REST API calls to Inji Verify, constructing OpenID4VP requests, managing transaction states, and providing feedback to the user based on verification outcomes.
This collaboration with MOSIP extends Agama’s capabilities to support verifiable credential verification workflows across real-world digital identity ecosystems.
| Actor | Description |
|---|---|
| User | End-user initiating credential verification. |
| Inji Web (Wallet) | User’s credential wallet responsible for holding and presenting VCs. |
| Agama Application | Janssen orchestration engine coordinating the entire verification flow. |
| Inji Verify | Verification service responsible for validating presented VCs. |
- User clicks “Verify with Inji” on the relying service.
-
Agama initiates an authorization request to
Inji Verify(/verifyServiceURL/vp-request). - Inji Verify processes the request and returns an authorization response.
-
Agama saves
requestIdandtransactionIdfrom the response. -
Agama constructs an OpenID4VP request (includes
nonce,state,presentation_definition,response_url). - Agama redirects the user to Inji Web with the OpenID4VP request.
- Inji Web authenticates the user (if not already logged in).
- User selects credentials and consents to share.
- Inji Web sends a VP Token response to Inji Verify, then redirects to Agama.
-
Agama checks the verification status (
/vp-request/{requestId}/status). - If status =
VP_SUBMITTED, Agama fetches the result (/vp-result/{transactionId}). - Inji Verify validates the VP using the VC Verifier library and returns the result.
- Agama displays a success or failure message to the user based on validation result.
User Story: As an Agama flow, I need to create an authorization request to the Inji Verify service to initiate the verification process.
Acceptance Criteria:
- Agama sends a
POSTrequest to/verifyServiceURL/vp-request. - The response includes
requestIdandtransactionId. - Agama stores these values in the flow context for subsequent API calls.
User Story: As an Agama flow, I must construct an OpenID4VP request using values from the authorization response and redirect the user to Inji Web.
Acceptance Criteria:
- The OpenID4VP request includes
nonce,state,presentation_definition, andresponse_url. - Redirect URL follows OpenID4VP specification.
- User successfully reaches Inji Web (wallet) via redirect.
User Story: As a user interacting through Agama, I must be redirected to Inji Web for login and credential selection.
Acceptance Criteria:
- If the user is not logged in, Inji Web prompts for authentication.
- User can view and select available credentials.
- On approval, Inji Web sends VP token to Inji Verify and redirects back to Agama.
User Story: As an Agama flow, I need to check the verification request status from Inji Verify to determine if a VP has been submitted.
Acceptance Criteria:
-
Agama performs a
GETcall to/vp-request/{requestId}/status. -
Possible statuses:
ACTIVE,VP_SUBMITTED,EXPIRED. -
Flow branches accordingly:
- ACTIVE → Wait/retry after delay
- VP_SUBMITTED → Proceed to result fetch
- EXPIRED → Terminate with error
User Story: As an Agama flow, once VP is submitted, I must fetch and validate the result from Inji Verify.
Acceptance Criteria:
- Agama calls
/vp-result/{transactionId}. - Inji Verify validates data using VC Verifier library and returns
validorinvalid. - Agama parses the response and updates flow state.
- Validation outcome logged for audit.
User Story: As a user, I should see a clear message indicating whether my credential verification succeeded or failed.
Acceptance Criteria:
- If VC is valid, Agama displays “Verification successful.”
- If VC is invalid, Agama displays “Verification failed” or appropriate error reason.
- Messages are user-friendly and localized.
User Story: As an Agama developer, I want all REST API interactions to include proper error handling, retries, and logs so issues can be easily diagnosed.
Acceptance Criteria:
- All REST API failures (timeout, 4xx, 5xx) are logged with timestamps and endpoint details.
- Flow gracefully fails with meaningful messages.
- Configurable retry mechanism for transient failures (e.g., polling status).
User Story: As an Agama flow, I must interact with the Jans Authorization Challenge (RFAC) endpoint to initiate and complete authorization securely.
Acceptance Criteria:
- RFAC request/response handled per Jans Server specification.
- Correlates with
requestIdandtransactionIdin the flow context. - Challenge results logged for traceability.