The direction · Proposed
UPI for trust
UPI did not give India a government payment app. It gave every bank and every app one open rail, and the citizen chose the app. Meri Pehchaan 2.0 is that rail for trust: verified once, trusted everywhere, with the citizen deciding what each service receives.
Why this, in the maker's words
I registered a company during COVID. Everything was online and it worked: the Registrar of Companies, the digital signature after a face check, the video KYC, the fee. Then the same person was verified again for GST, again for the bank, again for Udyam, again by a messaging platform's business verification. Every department's prerogative, every one fragmented. India already verifies who you are well. What it lacks is the rail that lets everyone else rely on that verification once.
What one verification unlocks
Each row names who relies on the rail, the least they need to receive, and the level of assurance it takes. The first row works in this prototype today; the rest are proposed, and the private services are fictional.
| Who relies on it | What they receive | Level | Today |
|---|---|---|---|
| Government departments | Profile claims by consent, one session across services, every application reporting to one inbox | Shabda to Pratyaksh, by action | 4 of 46 portals accept the national sign-on. Working here. |
| A social app checking age | A pairwise id and over 18: yes or no. Never a date of birth, never a name. | Anumaan | Apps collect dates of birth, identity cards or face scans on their own. Proposed: Sabha. |
| A messaging or advertising platform verifying a business | Verified business: the entity, its structure, Udyam or GSTIN attested, the person's role. No document upload. | Adhikrit | Each platform runs its own business verification. Proposed. |
| A bank opening an account | Name, address as dated, a PAN match, the phone. KYC once, at the level a regulator sets. | Pratyaksh | A video KYC per bank. Proposed. |
| Family, or a Jan Seva operator | A grant approved on the citizen's own phone, for one purpose, for a set time | Pratyaksh | OTPs are shared over the phone. Working here. |
| A future ballot | Not built and not claimed. A trust rail is the kind of thing a better voting experience would stand on. | — | Direction only. |
The rules that make it a rail, not a wrapper
A single company's login that sees every app you use is the surveillance model. These rules are what keep the rail on the citizen's side, and each one is visible in the prototype.
- A different id for every private service. No two services can join their records through the rail.
- Only what the sector may ask. A private app may ask whether you are over 18 and whether you are a verified person. It may not ask for your name, phone, address or any identity number. A bank may ask for KYC claims at the level its regulator sets.
- The consent screen says what a service will not receive as plainly as what it will.
- You decide how much your own ledger records for private sign-ins: everything, or only that a private app signed you in.
- Aadhaar never reaches the private sector. The Supreme Court settled that in 2018. The rail is federated and consent-based, which is why it can serve private services at all.
- Device trust is attestation, not a registry. Passkeys and the authenticator prove a device is genuine to the service; the hub keeps no list of devices.
- The hub does not sell anything. Its economics are UPI's: adoption, not data.
Others have walked this path
- European Union: the EU Digital Identity Wallet, which large online platforms must accept from 2026, with selective disclosure built in.
- Singapore: Singpass, relied on by banks, insurers and telecom operators as well as government.
- United States: Login.gov, one account across federal agencies.
- India: UPI for money, ONDC for commerce, the Account Aggregator for consented financial data. Trust is the missing rail.
For the officials in the room: what is built, what is pending, and where a decision is needed
Every bar below is the maker's estimate, made after building it: how much of each layer runs today on published contracts, how much waits on partner onboarding (paperwork), and how much waits on a government decision. Green is built and working in this prototype. Nothing here needs a technology that does not exist.
- 65%built and running in this prototype on published contracts
- 12%partner onboarding at the three provider portals — forms, not code
- 23%needs a government decision: publish two spec additions, name an operator, set a deadline
-
One button, one hub session across departmentsOpenID Connect to every department; the hub is a client of the three providers
check_circleBuilt 80% · handshakeOnboarding 20%
Pending: register the hub as a partner at the three provider portals (DigiLocker, Jan Parichay, e-Pramaan). Paperwork, not code.
-
Linking the three accounts to one citizenfirst sign-in at whichever provider you have; matched by verified mobile or PAN
check_circleBuilt 85% · handshakeOnboarding 15%
Pending: the providers return a stable subject and a verified mobile in their token — DigiLocker does today; Jan Parichay and e-Pramaan by agreement.
-
Passkeys in front of everythinga device-bound credential issued by the hub; the three tabs disappear after the first link
check_circleBuilt 100%
Pending: nothing external. Works on every current phone and browser.
-
A level in every token, with step-upShabda · Anumaan · Pratyaksh carried as acr and amr; a bank asks for more and gets it on the citizen's device
check_circleBuilt 90% · gavelDecision 10%
Pending: one agreed mapping from e-Pramaan's internal L0–L4 levels, so departments read one scale.
-
One ledger of who has access, with revokethe API Setu consent artefact and the consent operations, joined across providers
check_circleBuilt 85% · handshakeOnboarding 15%
Pending: subscribe to the published consent contracts; the hub's revoke reaches a department only if it exposes a logout endpoint.
-
Sign-out everywhereone sign-out ending every department session
check_circleBuilt 40% · gavelDecision 60%
Pending: none of the three providers publishes back-channel logout; the hub can only guarantee what it issued. A spec addition, already drafted on the developer page.
-
Beyond government: age, business, KYCa private app gets only 'over 18'; a bank gets KYC once at the regulator's level; Aadhaar never crosses
check_circleBuilt 70% · gavelDecision 30%
Pending: a sector policy under the data-protection rules and a regulator's word on the KYC claim set. The court settled the Aadhaar line in 2018; the rail respects it.
-
One account store, the three retiredthe migration, not a rewrite
check_circleBuilt 20% · gavelDecision 80%
Pending: a programme owned by the ministry and its three agencies. Jan Parichay's own 'link or migrate account' shows the path is already recognised.
-
Adoption by the portals citizens use4 of 46 accept the national sign-on today; none of the 21 business portals
check_circleBuilt 15% · handshakeOnboarding 25% · gavelDecision 60%
Pending: the government's own web guidelines already require single sign-on integration; enforcement through the audit that every portal already passes, and a dated deadline.
What to do, in order
- Name the operator and publish the missing half of the spec. Discovery, the signing keys, the level in every token, and back-channel logout. Every one is drafted on this prototype's developer page and costs no citizen a single change.
- Register the hub as a relying party at all three providers and turn on account linking by verified mobile. From that day, one sign-in covers every department that has the button.
- Enforce the button through the audit portals already pass, with a dated deadline. The rule exists; the deadline does not.
- Adopt the published consent contracts so "who has access" and revoke work across providers, not per provider.
- Migrate in waves, new users first, legacy last (below). Never replace a portal's login; add the door beside it.
- Write the sector policy for private relying parties: what a social app may ask (over 18, verified person), what a regulated one may ask, and that Aadhaar never crosses.
The migration, in waves
| Wave | Portals | How | What makes it happen |
|---|---|---|---|
| 0 · now | Sandbox, button kit and docs live; a first flagship portal re-pointed to the hub | native: add the button and a callback | a decision |
| 1 · within 6 months | Grievance, RTI, cybercrime, Parivahan, UMANG | the national reference adapter | enforcement through the existing audit |
| 2 · 6 to 18 months | Income Tax, EPFO, MCA21 | a vendor change request; PAN-linked accounts | a ministry order with a dated deadline |
| 3 · 18 to 30 months | GST, railway booking | a broker in front of the gateway; a sidecar for the highest-burst services | new users hub-first; legacy accounts migrate last |
| 4 | the remaining SAML-era services | an OpenID-to-SAML bridge | a sunset date for SAML |
The pattern is the one the United Kingdom's tax authority and Singapore used: the national sign-in appears beside the old login, new users start on it, and legacy accounts move last. Figures on this page are estimates from building the prototype, not government numbers.
What exists today, and what this prototype adds
Meri Pehchaan 1.0 already verifies a citizen through three providers and signs them into the services that adopted it. This prototype keeps that and adds one door, one inbox, one ledger of who has access, one identity screen that says what each credential proves, one authenticator, and the rules above. Where the infrastructure does not exist yet, the screen says Proposed, and the prototype controls on every page can show which published contract each screen speaks.
Try the working journey What is real and what is proposed The design, on ten sheets