Meri Pehchaan 2.0 · a concept for India's National Single Sign-On
Sign in once, with the same button on every service. See exactly what each one reads. Let someone act for you without giving them your code. Take it all back in one tap.
Demo: your own number and the code 123456 · or the seeded citizen 9876543210. Nothing here touches a live government system.
One citizen, three services and a helper. Every frame is a live screen from this build — press one to go there.
1 · One door. A mobile number, a DigiLocker, e-Pramaan or Jan Parichay id — the hub works out which.
2 · What it will read. Each field named, your own value under it, the optional ones unticked, until a date you can shorten.
3 · The next service already knows you. Income Tax, no second code, your identity fields already filled.
4 · One more proof, in place. A bank needs Pratyaksh; the screen says so and offers the passkey right there.
5 · Someone acts for you. A helper asks for one permission; you approve it on your phone by matching a number. They never see your code.
6 · Who has access, on your home. Every service, every helper, a Revoke on each row.Prototype journey comparison — measured on this build, not a national statistic
The scenario: Labour → Income Tax → Bharat Trust Bank → a helper files one form. The "before" is counted from the 1.0 sign-in each portal carries; the "after" is read from this hub's own ledger after running the scenario. The method, line by line.
Every screen names the level a service needs. The names are the three classical ways of knowing — what is told, what is inferred, what is seen directly — and one word for acting on someone's behalf. A citizen climbs them by proving more, never by scoring points.
| Level | Means | Proven by | Enough for |
|---|---|---|---|
| शब्द Shabda | "word" — what you tell us | a one-time code to your number | viewing status, tracking an application, a social app |
| अनुमान Anumaan | "inference" — what records confirm | a record from its issuer, such as a PAN, matched to you | filing, applying, registering — most government services |
| प्रत्यक्ष Pratyaksh | "direct" — seen for yourself | a device you hold: a passkey, or the authenticator matching a number | cancelling, withdrawing, money in motion, signing, a bank |
| अधिकृत Adhikrit | "authorised" — acting for someone | Pratyaksh, plus a grant the citizen approved on their own phone | a helper filing one form for you, for a set time, revocable |
A service asks for the level its action needs, never for the highest; when it needs more, the consent screen offers the proof in place.
The consent screen names each field a service will read and what it will never receive. A private app gets a pairwise identifier and an over-18 answer — never a date of birth, never an Aadhaar number. A bank gets more, and the screen says why.
A family member, a service-centre operator or a professional asks for one permission. You approve it on your own phone by matching a number. They sign in as themselves; the department records "helper, for citizen, under grant"; you can end it in one tap.
The hub answers who signed in, what was consented and what was delegated. Departments keep their own records and sessions, and are told when a session ends. Identity is separated from activity by construction.
Three tiers with names a person can say — Shabda, Anumaan, Pratyaksh — and a step up in place when a service needs more. The same button on 8 services, in 12 languages, on the government's own component library.
These four and twelve more, each with its reason and the screen that proves it, are collected under About this demonstration.
Five mock departments run the same sign-in. Start on any of them; the next one already knows you. Today none of the real portals behind them offers the national sign-on — the rails switch shows which are proposed.
UPI let every app move money on one rail. This is the rail for trust: verified once, relied on everywhere, with each sector allowed to ask only for what it needs.
Next in line, as designed: GST · Parivahan · UMANG · state scheme portals. High-burst services such as railway booking keep their own login and add the button only for account recovery.
This table is read from the hub itself (/api/about), not typed: 17 capabilities, each with the published primitive it stands on, its status in this build, and what production would need. Mocked here, and labelled in the interface: OTP delivery; DigiLocker document issuance; myScheme; Bhashini; e-District certificates.
| Capability | Published primitive | Status | What production needs |
|---|---|---|---|
| Federated sign-in across relying parties | Meri Pehchaan NSSO with OpenID Connect and PKCE S256 | Working in this prototype | Production NSSO client onboarding, certified redirects and managed signing keys. |
| Itemised, signed consent receipt | API Setu consent artefact | Working in this prototype | Production data-consumer registration, policy review and live revocation postbacks. |
| Progressive tiers with step-up in place | Meri Pehchaan NSSO assurance carried in OIDC acr and amr | Working in this prototype | Certified identity-proofing and authenticator binding for each production assurance tier. |
| Delegation grant with an acting-for identity | OAuth 2.0 Token Exchange with an act claim | Working in this prototype | Production representative registries, department policy and auditable approval delivery. |
| Citizen revocation of consent, grants and sessions | RFC 7009 token revocation and RFC 7662 token introspection | Working in this prototype | Reliable production postbacks and department-side enforcement of revoked authority. |
| Back-channel logout across participating services | OpenID Connect Back-Channel Logout | Working in this prototype | Registered department logout endpoints with retries, monitoring and key rotation. |
| One-time linking to an existing department account | Meri Pehchaan NSSO account linking | Working in this prototype | Department account-match adapters and production fraud controls. |
| DigiLocker issued-document proof | DigiLocker Partner API v2.0 and Requester spec v2.3 | Working in this prototype | DigiLocker partner approval, issuer access and production document URIs. |
| Scheme search and identity-backed eligibility filters | myScheme collection | Working in this prototype | API Setu consumer registration, subscription and production myScheme access. |
| Passkey assurance for a newly created account (demo-light) | WebAuthn passkeys | Working in this prototype | A production WebAuthn ceremony, attestation policy and recoverable credential store. |
| Second-phone authenticator TOTP | RFC 6238 TOTP | Working in this prototype | Hardware-backed secret storage, recovery policy and production device risk controls. |
| Private relying parties receive pairwise IDs and age_over | OIDC pairwise subject identifiers and selective claims | Working in this prototype | Sector classification, client policy audit and protected production pairwise salt. |
| Regulated relying party with KYC step-up | OIDC claims policy at mp:pratyaksh | Working in this prototype | Regulator-approved KYC policy, authoritative sources and relying-party certification. |
| Twelve-language page translation | ULCA pipeline for Bhashini | Published rail, no production access | A department Bhashini key and a production pipeline/config plus pipeline/compute integration. |
| Passwordless self sign-up | Meri Pehchaan NSSO registration | Working in this prototype | Production mobile ownership proof, duplicate-account resolution and recovery controls. |
| Replay-safe relying-party callbacks | OIDC authorization code flow with one-time state and PKCE | Working in this prototype | Shared production state storage, bounded retention and monitored callback failures. |
| Repeatable hub and identity-provider failure states | Meri Pehchaan integration sandbox fault injection | Working in this prototype | An isolated non-production environment and synthetic test identities only. |
"Working" means exercised by a verification script in this repository. "Published rail" means the primitive exists and is documented and this prototype holds no production access. "Proposed" is future state. The data, the limits, and how it was built.
Built with OpenAI. The problem was chosen in ChatGPT from the research on where the friction sits — between services, not inside any one portal. OpenAI Codex wrote the entire backend: 126 endpoints, an OpenID Connect issuer with PKCE, discovery and JWKS, consent receipts in the published artefact shape, delegation grants, the sandbox faults — in logged tasks, each with its own verification script (15 of them). Claude Code did design, documentation and the front end, which the rules require to be disclosed. The interface is the government's own component library, unchanged; every rail is a published one.
India's National Single Sign-On: one set of credentials that opens many government services. Today it brings together three sign-on platforms — Jan Parichay, e-Pramaan and DigiLocker. This concept, Meri Pehchaan 2.0, makes that one identity visible as one button, one consent screen and one place to see who has access.
Because being verified once and then again for every service is the everyday friction of Indian public life — the maker’s company registration, his father’s scheme applications, his wife’s verifications. Meri Pehchaan 2.0 is the rail that lets every service rely on one verification, with the citizen deciding what each one receives. It looks like a government site on purpose: looking familiar is the anti-phishing mechanism. The full reasons, in the maker’s words, are on the vision page.
No. Any of your existing identifiers — mobile number, DigiLocker, e-Pramaan or Jan Parichay username — opens the same door. In this demonstration any 10-digit number works and the one-time code is always 123456.
In the demonstration: the Labour Services portal, Income Tax e-Filing and the Public Grievance portal, all mock departments. Sign in once and the next portal recognises you without another code.
Only the service you consented to, only the fields you allowed, only until the date you saw on the consent screen. Who has access lists every consent and every helper, and you can withdraw any of them there.
India built one rail for moving money, and "Pay by UPI" became a habit. This concept asks whether one rail for proving who you are — beginning with government services, on the identity programme India already has — could become as familiar. That is the long-term direction, labelled as such; the prototype above is what exists.
Build What Moves India · the Top 10
Each one takes a single moment in a citizen's life and makes it simpler. Go and try them.
A note to Varun Mayya and the team
Thank you for putting this question in front of independent builders. Meri Pehchaan 2.0 was a genuine attempt to push a trust rail for the country — verified once, relied on everywhere, with the citizen deciding what each service sees. If it is useful, I would be grateful if it reached the right people in government. Reach me here. — Sambit Swarup