Hi Inji team,
Thank you for the earlier detailed response. Based on your guidance, we have started implementing the Inji Interoperability Playground and have explored the existing Inji components and their APIs to understand how we can integrate them instead of rebuilding their functionality.
I wanted to clarify a few things where we are still stuck.
1. Inji Certify → Wallet issuance flow
We explored the Inji Certify repository and its Docker setup, issuer metadata, credential configurations, and pre-authorized issuance APIs. We manually tested the flow involving /v1/certify/pre-authorized-data, /credential-offer-data/{offer_id}, and /oauth/token, and also investigated the credential request, c_nonce, proof JWT, and credential issuance requirements.
We also explored the Inji Mobile Wallet’s inji-vci-client implementation to understand how it processes a credential offer, obtains a token, creates the proof, and requests the credential.
However, in the Inji Web repository, we found that the frontend issuance flow uses issuer selection and OAuth authorization code through Mimoto. We could not find a frontend entry point for directly accepting an externally generated credential_offer or credential_offer_uri.
-
Is there an existing supported way to pass a credential offer generated by our Playground to Inji Web and initiate issuance?
-
If not, should we use the existing Inji Web authorization-code flow for the Web Wallet and use generated credential-offer QR codes for compatible mobile wallets when demonstrating pre-authorized issuance?
2. Inji Web Wallet → Inji Verify presentation flow
We explored the Inji Verify repository and its POST /v1/verify/vp-request API, request-object generation, response URI, and direct_post submission flow. We also inspected the Inji Web and Mimoto repositories to understand how the Web Wallet handles an incoming /authorize request, performs verifier trust checks, retrieves available credentials, lets the user select credentials, and submits the selection to Mimoto.
In our Playground backend, we have already created the initial component registry, adapters, and orchestration APIs, and have implemented the logic to create a Verify presentation request and construct the OpenID4VP authorization URI.
However, we have not yet confirmed the complete integration from the Playground-generated request through the actual wallet presentation to the final result from Inji Verify.
-
Is there a recommended reference implementation or configuration for launching Inji Web with a presentation request generated by a separately running Playground?
-
What verifier identity and trust configuration should we use when connecting our local Inji Verify instance to Inji Web/Mimoto?
-
Are there any specific requirements for the request URL, response URL, client ID, or DID-based versus non-DID client identification that we should follow?
3. Getting the actual verification result
We found that creating a presentation request and receiving a wallet submission are separate from completing verification. We do not want our Playground to report PASS merely because a request was created, a wallet submitted a presentation, or an endpoint returned HTTP 200.
We have been investigating the Verify APIs and source code to identify how the final result is exposed, but we have not yet established the correct mechanism for our external orchestrator.
Which API or mechanism should the Playground use to retrieve the authoritative verification result and correlate it with the original presentation request or transaction? Is there an existing callback, result endpoint, or reference implementation that we should follow?
4. Local setup versus Collab environment
We have also inspected the Docker configurations and environment properties. Our local Certify, Verify, and Inji Web/Mimoto setups have different service URLs, and the Inji Web configuration we inspected references Collab mock issuer and verifier services. We also noticed that some URLs use Docker-internal hostnames or localhost, which may not be reachable from a separate wallet device.
For the initial end-to-end baseline, would you recommend using the existing Collab services or connecting our locally running components? Are there any recommended configuration changes or deployment guidelines for making the wallet, issuer, and verifier communicate correctly across these environments?
Our goal is to complete a real Inji Certify → Inji Wallet → Inji Verify flow first, with the actual protocol exchanges, errors, and final verification outcome visible in the Playground. Once this baseline works, we can expand to representative external issuer, wallet, and verifier combinations as suggested.
We have explored the individual repositories and several API flows, but the main difficulty now is connecting the existing components into one reliable end-to-end flow and obtaining the authoritative result.
Any guidance on the specific integration points above, or pointers to a working example, would be very helpful.
Thank you!