IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Wallets & verifiable credentials — portable customer identity
Maya has typed her name, birthdate and address into 41 signup forms. Every one of those services now keeps its own copy of her. This lesson shows a model that flips it: identity lives in Maya's own wallet. Your goal: explain issuer, holder and verifier, and what a wallet changes.
- An issuer signs a fact. Maya holds it in a wallet. A verifier checks it.
- The verifier checks the issuer's signature, then keeps nothing.
- Selective disclosure shows one fact, not the whole document.
- A status list revokes credentials without tracking who checked them.
- Plan for wallet loss, issuer trust and years of classic signup.
Today: everyone keeps a copy of Maya
This track assumed that you collect and store the customer. Signup collects her email, profiling the rest, and when the law needs proof she uploads her ID again for another eKYC check. The result is dozens of copies of one person, each going stale and one breach away from trouble.
The credential triangle
The W3C Verifiable Credentials model has three roles.
- An issuer knows a fact and signs it into a credential. For example, a government signs your age.
- The holder is Maya. She keeps the credential in a wallet app on her phone.
- A verifier is your service. It checks the issuer's signature with the issuer's published keys (see keys & signatures).
The verifier trusts the issuer's keys, not a phone call, so the issuer need not learn where Maya shows her credential. Your service never stores what it checked: verify, admit, discard.
Selective disclosure
A paper ID is all or nothing: to prove she is over 18, Maya shows her birthdate and address too. With formats such as SD-JWT, each claim is sealed into the signature on its own. Maya reveals only the claims a verifier asks for, such as a signed "over 18: yes". The signature still checks out. This is selective disclosure.
At a concert, Maya's wallet shows "over 18: yes", with no name and no birthdate. At a hotel it shows her legal name. At the campus store it shows "student: yes". Each door gets the minimum.
Revocation that respects privacy
A credential can outlive the fact it carries: a student graduates. The issuer needs a kill switch. The standard answer is a status list. The issuer publishes one long string of bits. Each credential owns one fixed position. To revoke, the issuer flips that bit. A verifier downloads the list and reads one position. Everyone fetches the same long list, so the issuer does not learn whose credential was checked.
What this changes for CIAM
Signup can verify instead of collect. A request to present replaces a form and an upload. One regulated issuer does the identity proofing once, and everyone accepts it. Age checks need no birthdate database.
India has a close cousin: DigiLocker, a government app run by MeitY. Issuers such as a transport office or an exam board put signed documents there, and Maya shares them with her consent. Indian rules treat an issued document there as equal to the original paper. The picture is the same: the issuer is the source of truth, and Maya carries and shares.
This is leaving the lab: the EU's eIDAS 2.0 law requires each member state to offer its citizens a wallet by around the end of 2026, and some countries may be late.
Plan for three things. First, verifiers wait for wallets and wallets wait for verifiers, so run credentials next to classic signup for years. Second, a credential is only as good as its issuer: check who signed it, not just that someone did. Third, losing the wallet is the new account recovery. The keys live on Maya's phone, and phones get lost, so backup and re-issuing need account recovery.
Go deeper: Standards and dates (as of October 2026)
- W3C Verifiable Credentials Data Model 2.0 became a W3C Recommendation on 15 May 2025. The Bitstring Status List v1.0 (the status list above) became a Recommendation on 15 May 2025 too.
- SD-JWT is RFC 9901, "Selective Disclosure for JSON Web Tokens", a Proposed Standard from 2025.
- OpenID for Verifiable Credential Issuance 1.0 (how a wallet gets a credential): Final, September 2025. OpenID for Verifiable Presentations 1.0 (how a wallet shows one): Final, July 2025.
- Another credential format is mdoc, from ISO/IEC 18013-5 (2021), used for mobile driver's licenses. The EU wallet design supports mdoc and SD-JWT credentials.
- eIDAS 2.0 is Regulation (EU) 2024/1183. Each member state must offer at least one wallet within 24 months after the Commission's implementing acts took effect. Those acts date from late 2024, so the date is about the end of 2026. Regulated services such as banks must accept the wallet about a year later. Press reports in mid-2026 say several countries are behind. Check the official EU text.
- DigiLocker is run by MeitY. Rule 9A of the Information Technology (Preservation and Retention of Information by Intermediaries providing Digital Locker Facilities) Rules, 2016 (added in 2017) treats a document issued there as equal to the original physical document. Not every department issues documents there yet. It is not the W3C technology: a requester fetches the shared document through a link.
Sources: w3.org/TR/vc-data-model-2.0, w3.org/TR/vc-bitstring-status-list, digilocker.gov.in, rfc-editor.org/rfc/rfc9901, openid.net/specs.
🧪 Interactive lab — enable JavaScript to play with this one.
Selective disclosure is data minimization with cryptography behind it. Rank what apps over-ask for today with Consent Check. Check the device-bound key hygiene that wallets depend on with Passkey Check.