Prove, don’t Approve: VCs and Passkeys for Sign‑in

Voice phishing vs MFA: why “Approve” isn’t enough

Recent vishing (voice‑phishing) shows a simple reality: if authentication relies on reading a code or tapping “✅ Approve”, a persuasive caller can talk people into it.

🕵️‍♂️ How the scam works

• 📞 Attacker pretends to be IT support.
• 🌐 Steers the user to a convincing look‑alike login page.
• 🔐 Coaxes them to share a one‑time code (OTP) or approve a push.
• ⚡ The attacker uses that in real time to sign in while the user believes they’re being helped.

🧾 Why authenticating with Verifiable Credentials stops vishing

• 🚫 No codes to steal. With Verifiable Credentials (VCs) – vLEI or an mDL-style credential – authentication uses device‑held cryptographic keys, not passwords or OTPs. There’s nothing to read out over the phone.
• 🔗 Proofs go only to the real site. Wallets send an origin‑checked cryptographic presentation to the legitimate site, not a phishing copy.
• 🧠 Biometric‑unlocked, device‑bound. Proofs are produced on the user’s device and typically require FaceID/TouchID, reducing “push fatigue” and approval tricks.
• 🔑 No password resets to exploit. The helpdesk verifies cryptographic proofs, not secrets, so vishing callers have nothing to “reset”.
• 🛡️ Reduces helpdesk risk. The helpdesk’s role shifts to verifying cryptographic proofs (via the official channel), not resetting secrets.
• 🔒 Stronger end-to-end flow. Standards like PKCE prevent intercepted authorisation codes from being redeemed by attackers.

🧾Passkeys (FIDO2/WebAuthn)

• 🧷 Also phishing‑resistant. Keys are bound to the website’s origin, so look‑alike pages can’t complete the challenge.
• ⚡ Great UX for login. Fast, familiar and device/biometric‑based; ideal for signing in to your own site or workforce SSO.

Use passkeys when your goal is:

• Streamlined, phishing‑resistant login to your own site/app or workforce SSO.
• You don’t need to know anything about the user beyond “this is the account owner.”

Use VCs when your goal is:

• B2B/B2G trust: “Is this person authorised to act for this company in this role?” → vLEI OOR/ECR fits perfectly.
• Attribute/age/permit checks with selective disclosure (mDL‑style).
• Cross‑ecosystem reuse: the same credential works with many verifiers, not just one website.

Quick decision helper

• Need only “log the user in” to your site? Start with passkeys.
• Need to prove organisational identity/role or share only specific attributes, across partners? Use VCs (OID4VP) – and consider vLEI for governed roles.
• Have both needs? Combine: passkey to unlock the wallet, VC to prove who/what the user is.

🛠️ How to adopt

@TradeVeris bridges to your existing Single Sign On (SSO) – Okta/Auth0/Entra – so you can add VC / vLEI sign‑in without re‑writing apps. This follows the widely used brokered OIDC pattern: authentication is delegated to a wallet/VC check first; only then is the SSO session established.

Bottom line

Vishing feeds on shareable secrets. VCs and passkeys replace them with origin‑checked cryptographic proofs a phone call can’t spoof. When you also need portable, governed assurance across organisations, VCs (incl. vLEI) are the right tool.