Security policy

What this prototype does to protect a sign-in, what a real deployment must add before it may host citizens, and how to tell us about a weakness.

Independent concept prototype. Every citizen, identifier and document here is synthetic; no live government system is called. This page is written in the form a government website's security policy takes, so the gaps are visible rather than hidden.

What is in place on this site

Every page and API is served over HTTPS with HTTP Strict Transport Security, a content-security policy that allows only this site and the design-system CDN, no framing, no MIME sniffing, and a strict referrer policy.
Sign-in uses the authorisation-code flow with PKCE (S256 only), an exact redirect match, single-use codes, and signed RS256 tokens. Only the public half of the signing key is ever served. Access tokens live for an hour; refresh tokens rotate; revocation and introspection are real.
Session cookies are HttpOnly, Secure and SameSite. The hub session ends after five minutes of inactivity with a sixty-second warning, and "Sign out everywhere" ends every department session too.
One-time codes are single-use and time-boxed; five failures lock the request for thirty minutes and the screen shows attempts remaining. A one-time code is never the only factor for a sensitive action: cancelling a claim or granting access needs the authenticator, by number matching.
No password exists anywhere in the system. No biometric is stored, transmitted or compared. Identifiers are shown masked (••••4321); the demo Aadhaar-shaped strings are masked-only and the demo PANs fail their own check digit on purpose.
Every authentication, consent, grant and application event is written to an audit log the citizen can read on the activity page. Each consent is a signed receipt in the API Setu consent-artefact shape, and withdrawal is one tap on Who has access.
Delegation never shares a credential: a bounded, revocable grant is exchanged for a token that names the person acting, expires with the grant and counts its uses.
If the hub is unreachable, a department keeps its own session and shows its own sign-in; the hub is on the path at sign-in and never on every request.
There is no CAPTCHA by design. The guidelines that ask for one also require an alternative for every kind of sensory perception; rate limits and lockout do the same job without excluding anyone.

What a real deployment must add before hosting citizens

A security audit and "safe to host" certificate from an auditor empanelled by CERT-In or STQC, renewed every year or whenever the code changes. The content-hash stamps on this site's assets are the artefacts such an audit records.
Hosting on a Government Community Cloud empanelled by MeitY, inside India, with a disaster-recovery site, a yearly drill, and 180 days of logs kept in Indian jurisdiction with clocks synchronised to NIC or NPL time.
Any Aadhaar number held by an identity provider in an Aadhaar Data Vault behind a reference key, with keys in a FIPS 140-2 Level 3 hardware security module. The hub itself holds tokens, never the number.
The incident clocks, with a named point of contact: six hours to CERT-In, twenty-four hours to DigiLocker, seventy-two hours to the Data Protection Board and to UIDAI where an Aadhaar transaction is involved, and notice to every affected citizen without delay.
A security operations centre, a Data Protection Officer in India, a grievance officer, and the duties of a Significant Data Fiduciary: a yearly impact assessment and audit.
Registration as a Consent Manager under the Digital Personal Data Protection Rules once that provision is in force, keeping consent records for seven years.

Contingency

The design assumes the hub will sometimes be down. Departments cache the hub's discovery document and keys, keep their own sessions, and fall back to their own sign-in with a visible notice. The authenticator works without signal. A real deployment adds the recovery-time and recovery-point targets of its business-continuity plan here.

Report a vulnerability

Tell us through the repository, and tell CERT-In: its Responsible Vulnerability Disclosure and Coordination Policy is India's official channel, at cert-in.org.in and vdisclose@cert-in.org.in. A machine-readable copy of this section is at /.well-known/security.txt.

Contact

Questions about this policy, or about the demonstration: see the Contact us page for the team and the repository.