Login with Inji (WLA) — Real IDA vs Mock IDA Requirements

[Rutvik]

Problem Summary

We’ve successfully implemented the credential download pipeline (eSignet 1.8.0 → Certify → Inji wallet), but “Login with Inji” (WLA) QR-code authentication is blocked by infrastructure we don’t have deployed. Before investing in a full IDA deployment, we need to clarify whether a mock IDA would suffice or if a real production IDA is required.

---

What’s Working

• eSignet v1.8.0 deployed (OAuth/OpenID provider)
• Keycloak configured with eSignet as identity provider
• Inji wallet successfully downloads mock mDL credentials from Certify
• Wallet ↔ Server authentication (token validation, credential issuance)

---

What’s Broken

“Login with Inji” (QR-based authentication) fails at activation step.

Flow We’re Trying to Achieve

1. eSignet generates QR code
2. Inji wallet scans QR
3. Wallet activates credential for online login
   ↓ THIS STEP FAILS
4. Credential bound to device
5. User can use credential to login via Keycloak

Root Cause: Missing IDA Service

Per official docs:

1. Inji Docs

   • Credentials must be “activated for online login” before QR login works
   • Activation is user-initiated in the wallet

2. eSignet Docs ( Wallet Authenticator | Signet )

   • Credential activation requires calling Identity Data Authority (IDA) KYC-exchange APIs
   • eSignet acts as a proxy to IDA services
   • Currently only ldp_vc format is supported for credential holder integration (https://docs.esignet.io/integration/wallet/credential-holder)

3. Reality Check

   • eSignet’s actual API surface does NOT include /kyc-exchange/* endpoints
   • These must be delegated to an external IDA service

---

What We’ve Tried

Attempt 1: Mock Identity System (Failed)

• Used MOSIP’s mock identity system from certify-service-with-plugins
• Issue: Built for eSignet’s mock credential flow, not IDA KYC-exchange protocol
• Result: Incompatible protocols — can’t stand in for IDA

Attempt 2: Certify’s Built-in IDA Plugin (Blocked)

• Found unused MOSIP IDA identity-issuance plugin in Certify image
• Requires: Real IDA service backend
• Missing: KYC API implementation, identity data store
• Result: Dead end without IDA

---

Current Architecture

┌─────────────┐
│  Keycloak   │
└──────┬──────┘
       │ (SSO via eSignet)
       ↓
┌──────────────────┐
│    eSignet       │ ← Credential holder integration
│  (v1.8.0)        │   (needs IDA to call KYC APIs)
└──────┬───────────┘
       │
       ├─→ Certify (credential issuance) ✅
       │
       ├─→ Mock Identity System ✅
       │
       └─→ IDA (KYC-exchange APIs) ❌ NOT DEPLOYED

---

The Question: Real vs Mock IDA

Option 1: Deploy Real MOSIP IDA

What it is: Full Identity Data Authority component from MOSIP stack

• Standalone service with proper identity data store
• Implements KYC-exchange protocol
• Handles identity verification, data masking, compliance
• Production-grade with audit logs

Scope:

• Requires separate Docker deployment (~2-3 services: IDA, DB, KYC processor)
• Needs real identity data seeding
• Configuration for credential scoping & data release policies
• Integration testing with eSignet

Questions:

• Is this overkill for a proof-of-concept?
• Do we need production IDA compliance for demo purposes?

Option 2: Mock IDA (If One Exists)

What it would need:

• Implement /kyc-exchange/request and /kyc-exchange/response endpoints
• Accept wallet’s KYC request with:
  • Credential ID
  • Identity attributes to release
  • Proof of possession
• Return verified identity data
• No real identity database — just mock responses

Advantages:

• Minimal footprint (single container)
• Can bootstrap it quickly
• Sufficient for WLA demo/testing

Questions for Community:

1. Does MOSIP provide a mock IDA anywhere?
2. Has anyone built a minimal mock IDA for eSignet testing?
3. Are there example KYC-exchange request/response payloads in the docs?

Option 3: Bypass IDA (Partial Workaround)

Idea: Can we use a credential format that doesn’t require IDA activation?

• Current attempt: mDL (vc+sd-jwt) — requires IDA
• Possible alternative: ldp_vc format — per eSignet docs, “supported for credential holder”
• Question: Does ldp_vc skip the IDA-binding step, or just use a different serialization?

---

What We Need to Know

For the Community:

1. Has anyone implemented “Login with Inji” without a real IDA?

   • If yes, how did you mock it?
   • What credential format did you use?

2. KYC-Exchange Protocol:

   • Official spec/examples?
   • Request/response payload format?
   • Authentication mechanism between eSignet ↔ IDA?

3. eSignet Credential Holder Integration:

   • Why is only ldp_vc supported?
   • Does ldp_vc avoid the IDA binding step?
   • Can mDL be used with a different activation flow?

4. MOSIP Component Status:

   • Is there a standalone mock IDA in MOSIP examples?
   • Any reference implementations for minimal KYC services?

5. Real-World Deployments:

   • For production eSignet+Inji, is a real IDA always required?
   • What’s the typical deployment (cloud, on-prem)?

---

Before we commit: We want community input on whether a mock IDA is viable for our use case or if we should jump to real IDA deployment.