Standardising Trust
In the world of verifiable credentials, the biggest challenge isn't the cryptography—it's the interoperability. How does an issuer from one company talk to a wallet from another company and a verifier from a third?
The industry answer is OID4VC (OpenID for Verifiable Credentials).
What is OID4VC?
OID4VC is a family of specifications built on top of OpenID Connect (OIDC)—the same technology that powers "Sign in with Google." It adapts this proven infrastructure for the world of decentralised identity and verifiable credentials.
AssureLocker implements the two primary parts of the specification:
- OID4VCI (Issuance): How an institution issues a credential to a user's wallet.
- OID4VP (Presentation): How a user presents that credential to a verifier.
The three moving parts
“OID4VC” is really three coordinated pieces: a protocol to put a credential into a wallet, a protocol to get it back out under the holder’s control, and a credential format that makes selective disclosure possible in the first place.
| Protocol | Purpose | Who talks to whom |
|---|---|---|
| OID4VCI | Issue a credential into the holder’s wallet | Issuer → holder wallet |
| OID4VP | Request a credential and present it with selective disclosure | Verifier ↔ holder wallet |
| SD-JWT VC | The credential format — issuer-signed claims the holder can selectively reveal | Issued by the issuer, held by the holder, checked by the verifier |
Why OID4VC for India?
While other standards exist (like ISO 18013-5 used for mobile driving licenses), OID4VC is the superior choice for India's digital ecosystem for several reasons:
1. Web-Native Compatibility
OID4VC is built for the web. It works seamlessly in mobile browsers and native apps, making it perfect for India's mobile-first population.
Because the whole exchange rides on ordinary HTTPS redirects and QR codes, it needs no proprietary NFC or Bluetooth proximity stack on the device. The same flow runs two ways: same-device, where the browser redirects straight into the wallet, and cross-device, where a verifier shows a QR code the holder scans with a phone. That second mode is the common one at a branch or onboarding desk — the verifier is a web page on a laptop while the credential lives on a handset a few inches away. By contrast, ISO 18013-5 (the mobile driving-licence standard) is oriented to NFC/Bluetooth proximity, which assumes a very different device-and-reader estate.
2. Developer Familiarity
Since it is based on OAuth2 and OIDC, most developers already understand the core concepts. This reduces the time to integrate AssureLocker’s DigiKYC into existing banking and fintech stacks.
An OID4VCI issuer reuses the familiar OAuth 2.0 furniture — an authorization endpoint, a token endpoint, PKCE, redirect URIs — so an existing OAuth library does most of the work. The genuinely new surface is small: a credential offer, a credential endpoint, and the credential format itself. A team that has ever wired up “Sign in with Google” already holds most of the mental model it needs.
3. Global Alignment
The European Union (eIDAS 2.0) has selected OID4VC as the standard for its Digital Identity Wallets. By adopting it in India, AssureLocker ensures that our infrastructure remains interoperable with global standards.
The alignment runs deeper than the wire protocol. OID4VC sits on open building blocks rather than a vendor stack: the W3C Verifiable Credentials data model for the shape of a credential, and IETF SD-JWT VC for how it is serialised and signed. Building to those standards means a credential issued in India can, in principle, be understood by a compliant verifier abroad without a bespoke integration for every counterparty.
4. Selective Disclosure by Design
OID4VC pairs naturally with SD-JWT VC, a format that lets the holder reveal individual claims — a name and a single address line, or a plain “over 18” — while the rest of the credential stays sealed and still cryptographically verifiable. For India’s DPDP Act, that turns data minimisation from a policy promise into a property of the protocol: a verifier cannot over-collect what the holder never disclosed.
How OID4VCI Works (The Issuance Flow)
Issuance is the half that fills the wallet. Using AssureLocker DigiKYC as the issuer:
- The institution presents a credential offer— a QR code or deep link naming the credential type and where to fetch it.
- The wallet runs an OAuth 2.0 authorization (with PKCE), so the holder proves who they are before anything is issued.
- The wallet exchanges the resulting code at the token endpoint for an access token.
- The wallet calls the credential endpoint and receives a signed SD-JWT VC, which it stores locally.
From that point the credential lives on the holder’s device, not on a server they must trust to be online. Reusing it later costs nothing and need not touch the issuer again.
How OID4VP Works (The Verification Flow)
When a user wants to verify their identity at a bank using a AssureLocker DigiKYC credential:
- The Bank (Verifier) generates an OID4VP Authorization Request (usually as a QR code).
- The User's Wallet scans the QR and processes the request.
- The User consents to share the specific claims (selective disclosure).
- The Wallet sends an OID4VP Authorization Response back to the Bank.
- The Bank validates the cryptographic signature of the response against the registry.
Two details make that response trustworthy rather than merely well-formed. The request carries a nonce and an intended audience, and the wallet signs over both — so a captured response cannot be replayed at a different verifier or a later moment. And the verifier states exactly which claims it needs through a presentation_definition (DIF Presentation Exchange); the wallet returns only those, typically via response_mode=direct_post so the vp_token never rides back on a browser URL where it could leak.
Security Note: The exchange happens over a secure, encrypted channel. The verifier receives exactly what they asked for and nothing more, satisfying the data minimisation requirements of the DPDP Act.
Implementation at AssureLocker
At AssureLocker, we provide the full OID4VC stack as a service. Institutions don't need to learn the complexities of JWTs, SD-JWTs, or AnonCreds. Our APIs handle the protocol heavy lifting, allowing you to focus on your core business.
Concretely, AssureLocker runs the issuer and verifier endpoints, mints credentials as SD-JWT VCs, and drives the presentation_definition a verifier asks against. Issuer-signed artefacts are signed with post-quantum ML-DSA-65, so a credential checked years from now still holds; holder keys stay on the device. You integrate two REST surfaces — issue and verify — rather than assembling a wallet SDK, a signing library and a disclosure engine yourself.
One boundary is worth stating plainly. AssureLockeris the trust-service layer: it issues a credential, transports it under the holder’s consent, and hands the verifier a signature it can check against the registry. It does notmake the decision that sits on top — whether to open the account, approve the loan, or admit a counterparty. That judgement, and the liability for it, stays with the relying institution. AssureLocker verifies; it never lends, decides, or guarantees an outcome. See how the pieces fit together in the DigiKYC platform.
Ready to see the protocol in action? Request a technical walkthrough.