Make every Inji credential prove itself

Inji Certify already produces signed verifiable credentials, and Inji Verify already checks those signatures. That proves the data is intact and came from the holder of a given key. It says nothing about whether the issuer behind that key is a real, accredited authority, or whether the verifier (relying party) requesting Asha's ID is one she should trust. That gap is where fraud and over-collection live: a perfectly valid signature from an issuer nobody vetted, or an over-asking verifier with no right to the data.

Verana closes it by putting the answer on-chain. Every participant, issuer, verifier and ecosystem, is a Decentralized Identifier registered in an Ecosystem, and given an explicit Participant entry for one credential type. At any step, anyone can ask the Verana Trust Resolver "is this party actually trusted, and authorized for this exact credential?" and get a fail-closed answer in one call. These are the four ideas the rest of the story uses.

The MOSIP Pilot Authority anchors everything. It defines what a Resident ID is, and it accredits exactly who may issue and verify it. This is the precise structure a MOSIP engineer would query, each box a real participant with its role and DID, each edge one party having granted the next. The three services resolve live, so the picture proves itself.

Now let's build that up, one move at a time, and after each move the page asks the real resolver to prove it. Green means the link holds. At the very end you'll see the same trust as one flow.

First there is the MOSIP Pilot Authority. It registers on the Verana network, creates a Ecosystem (#167), and owns the schema and the governance framework. It sits at the root of the participant tree as the ECOSYSTEM node. Every credential in this ecosystem, including Asha's, chains back to it.

The real condition: the anchor doesn't get to declare itself trusted. It must resolve as a TRUSTED Verifiable Service, and that holds only because it carries two verified credentials from Verana's own credential service, an Organization credential and a Service credential, presented from its DID document. The resolver's Q1 (resolve) walks that and returns trustStatus: TRUSTED. Ask it yourself:

Before Asha can be issued anything, the ecosystem publishes what a Foundational Resident ID is: the exact claims it carries, recorded on-chain as a credential schema. Every credential issued here must conform to it, and its credentialSchema field points back to it. That pointer is what lets a verifier, later, confirm two things at once: that Asha's credential is the right kind, and that it was issued under the right registry.

One detail that matters for the whole demo: this schema is in ECOSYSTEM issuer onboarding mode, which means an issuer cannot simply self-register, it must be explicitly accredited by the root. (An OPEN schema would let anyone issue, which is exactly the trust gap we are closing.) Here is the live schema, loaded straight from the chain:

Now a real MOSIP Inji Certify deployment joins as the issuer that will mint Asha's ID, the ISSUER node in the tree. But running Inji Certify is not enough to be believed. A verifier needs two separate things to be true, and the resolver checks both in one go:

• Q1It is a trusted Verifiable Service. Inji Certify was made verifiable by adding a service credential to its DID document, a holder-signed Verifiable Presentation that chains back to the anchor. Open the DID document on the card below to see the added credential and the service identity, this is the "add a service credential" step made concrete.
• Q2It holds an issuer participant entry. The ecosystem granted it an on-chain accreditation to act as issuer for this exact schema, the edge from ECOSYSTEM to ISSUER in the tree. Without it, even a trusted service resolves as "trusted, but not accredited for this credential", fail closed.

Green here means both are true at once: trustStatus: TRUSTED and authorized: true. That is precisely what "accredited issuer" means, and it is the thing a bare signature can never tell you.

With Inji Certify trusted and accredited, it issues Asha a real Foundational Resident ID over OID4VCI. The credential is signed, carries her claims (name, date of birth, identifier), and embeds the credentialSchema pointer from Move 2, so any verifier can check both the signature and the accreditation behind it. The moment it lands in her wallet, Asha becomes the HOLDER leaf of the tree. Pick a resident and issue one:

Or hold it in the real wallet, on your phone

The same credential, in the native MOSIP Inji Wallet on Android. Install it, sign in as a seeded resident, and the Foundational Resident ID downloads from our Certify, the identical Verana-trust-backed flow, on a real device.

scan to install on Android

Download the Android APK

1. Install the APK, allow "install from unknown sources"
2. Open Inji Wallet, set a passcode
3. Add Credential, Foundational Resident ID
4. UIN 7841223190, OTP 111111

A credential is only half the story. When someone asks Asha to present her ID, she should be able to ask back: who are you, and are you even allowed to request this? So the verifier (Inji Verify) is checked too. It needs its own verifier participant entry on the schema, the ECOSYSTEM to VERIFIER edge in the tree, which the resolver answers as Q3. An unknown or over-asking verifier resolves as untrusted, and the wallet defaults to blocking it before any attribute leaves Asha's device.

Nothing here re-implements Inji. Inji Verify runs the real verification; a thin Verana add-on then shows the accreditation verdict on top. Upload one of these sample QRs on the live Inji Verify UI and watch the verdict change with the real conditions:

Accredited issuer

Untrusted issuer

Not accredited here

Invalid signature

Every card above used this exact query. Here you can drive it: pick a party and the page asks the live Verana Trust Resolver in your browser, including a self-signed issuer that should fail. A valid signature is authenticity; this is legitimacy.

The participant tree is not just a diagram, it is enforced and economically backed. Accreditation can be delegated through grantor branches, metered with fees and deposits, and revoked, with slashing behind the guarantees. You can watch the whole ecosystem on the Verana network visualizer or open it in the Ecosystem explorer.

The same chain of trust you just built, end to end: the anchor defines the credential, accredits the issuer and verifier, the issuer hands Asha her Resident ID, and any verifier checks it all the way back to the root. Each ✓ is the resolver answering live.