Digital ID 101

The key difference is cryptographic proof. A PDF or a photo of an ID can be easily photoshopped. A VC, however, is sealed with a digital signature from the Issuer. This signature mathematically guarantees three things: who issued it, to whom it was issued, and that the data has not been altered by a single pixel or byte since it was created.

SSI is an identity model where the individual is the ultimate owner and controller of their personal data. Instead of your data sitting in a central database owned by Facebook, a bank, or the government, your data lives securely on your own device. You decide exactly who gets to see it, when, and for how long.

DIDs are globally unique strings of letters and numbers (like a URL) that identify a person, organization, or thing. Unlike a domain name (which requires ICANN) or an email address (which requires Google or Microsoft), a DID is generated mathematically by the user's software. It is anchored to a decentralized network (like a blockchain), meaning no single company or government can delete or control your identifier.

In this ecosystem, a Digital Wallet is a secure software application (usually on a smartphone). It does not hold money. Instead, it securely stores your private cryptographic keys, your DIDs, and your Verifiable Credentials. It also acts as the interface you use to accept new credentials and approve requests to share them.

A social media bio is self-asserted - you can type that you are a Harvard graduate and an astronaut, but there is no proof. A Verifiable Credential is third-party verified - it is issued by an authoritative source (like Harvard University itself) using cryptographic signatures, making the claim mathematically provable.

• Federated Identity (e.g., "Sign in with Google" or Okta): You use a central middleman to verify you. The middleman knows exactly which websites you are logging into, creating a privacy issue known as the "phone-home" problem.
• Decentralized Identity: There is no middleman. You present your proof directly to the website (the Verifier). The Issuer who gave you the credential has no idea where or when you are using it.

Portability relies heavily on open standards and interoperability. Because VCs are built on universal W3C standards rather than proprietary tech, a credential issued by a university in Japan can be stored in a digital wallet built by a startup in Germany, and instantly verified by an employer in Canada.

The W3C defines a VC as a standardized data format (usually JSON or JSON-LD) containing three specific compartments:

• Metadata: Information about the credential itself (Issuer ID, date of issuance, expiration date).
• Claims: The actual data being asserted (e.g., Name: John Doe, Degree: B.S. Computer Science).
• Proofs: The cryptographic signatures that bind the claims to the Issuer and the Holder.

When a system looks up a DID, it gets a DID Document - a simple file containing the Public Keys of the DID owner and Service Endpoints (secure routing addresses). This allows anyone to verify a signature made by that DID or send them a secure, encrypted message.

In traditional systems, you often hand over your entire ID just to prove you are over 21. Digital credentials use Selective Disclosure to ensure data minimization. Granular consent means the user's wallet will explicitly ask: "The bouncer only needs proof you are over 21. Do you consent to share just this one specific fact?"

• Issuer: Creates the credential, signs it cryptographically, and gives it to the Holder.
• Holder (User): Stores the credential in their digital wallet. When a service asks for proof, the Holder decides whether to share it.
• Verifier: Requests the proof from the Holder. Upon receiving it, checks the cryptographic signature against the Verifiable Data Registry to ensure it is authentic.

First, the Issuer verifies the real-world identity of the subject. Then, the Issuer formats the data into a standardized credential (like a JSON file), generates a cryptographic hash of that data, and encrypts the hash using their Private Key. This creates the digital signature. Finally, they transmit the signed credential securely to the Holder's wallet.

The Verifier looks up the Issuer's DID on the Verifiable Data Registry to find the Issuer's Public Key. By applying the Public Key to the credential's digital signature, the Verifier can mathematically prove that the credential was created by that specific Issuer and hasn't been tampered with - all without making a phone call or API ping to the Issuer.

The Registry acts as the decentralized "phonebook" and anchor of trust. It does not store user data or credentials. Instead, it stores public identifiers (DID Documents containing Public Keys), public schemas (data formats), and revocation registries - allowing Verifiers to independently look up the cryptographic keys needed to verify credentials.

An "Edge Agent" is software running on the user's smartphone (their digital wallet). It stores credentials locally in the device's secure storage, manages the user's private keys (often using the phone's Secure Enclave), and provides the user interface where the Holder reviews and approves requests to present their data to Verifiers.

• Direct Presentation: The Holder sends the credential directly from their own edge device (smartphone) to the Verifier over a secure connection.
• Proxied Presentation: The Holder delegates the task to a representative service (like an enterprise server or a cloud wallet) to present the credential on their behalf.

Cloud Agents run on remote servers rather than local devices. They offer high availability (always online) and easier account recovery if a user loses their phone. They manage the keys and routing on behalf of the user, though this requires the user to trust the cloud provider (a semi-custodial or custodial model).

If the registry goes down, Verifiers cannot look up new Issuers' Public Keys or check the absolute latest revocation status. However, if a Verifier has previously cached the Issuer's DID Document (Public Key), they can still cryptographically verify the credential perfectly offline. The core math doesn't rely on real-time internet access to function.

DIDComm uses the public/private keys associated with the actors' DIDs to create mutually authenticated, end-to-end encrypted communication channels. When a Holder and a Verifier connect via DIDComm, they can exchange credentials knowing absolutely no one - not even the network provider - can intercept or read the data in transit.

A Presentation Request is a machine-readable message sent by the Verifier to the Holder's wallet. Using protocols like Presentation Exchange, the request specifies exactly what the Verifier needs - for example: "I need a credential issued by the Department of Motor Vehicles, and I only need the 'over_18' attribute to be true." The wallet reads this and prompts the user for consent to share exactly that.

Currently, employers hire third-party background check companies that spend weeks calling university registrars to confirm a candidate's degree. With Verifiable Credentials, the candidate simply presents a digital diploma from their wallet. The employer's software mathematically verifies the university's signature in milliseconds, instantly eliminating diploma mills and fraud while drastically speeding up the hiring timeline.

KYC traditionally requires users to repeatedly scan physical passports and utility bills for every new bank they join. With digital credentials, a trusted entity (like a government or a heavily regulated anchor bank) issues a "Verified Person" credential. The user presents this to any new financial institution for instant, mathematically proven compliance data - without that institution needing to store vulnerable honeypots of raw passport images.

While W3C VCs were heavily designed for web-based interactions, mDLs (governed by ISO 18013-5) were specifically designed for in-person, offline scenarios like a traffic stop or TSA checkpoint. They rely on direct device-to-device communication (using NFC, Bluetooth, or QR codes) so a police officer's device can securely request and verify your license data even if neither of you has cell service.

The widespread rollout of SMART Health Cards for COVID-19 vaccinations proved this model globally. Using digital credentials, a hospital can issue a verifiable prescription, allergy list, or test result directly to a patient's wallet. The patient can then travel to a completely different hospital network in another country and securely prove their medical history without requiring complex, expensive backend integrations between the two hospital IT systems.

This is often called a "Digital Product Passport." Instead of just people, physical goods (like a batch of fair-trade coffee beans or a luxury handbag) are assigned a DID. As the product moves from farm to factory to shipping container, inspectors issue credentials verifying its status at each step. A consumer or customs agent can scan the final product and cryptographically verify its entire journey and ethical origin without trusting a single centralized database.

Enter "Bring Your Own Identity" (BYOI). When hired, an employee receives a digital "Employee Badge" credential in their wallet. Instead of creating and memorizing 20 different passwords for Slack, VPNs, HR portals, and physical door readers, the employee uses their credential to instantly authenticate across all systems. If they leave the company, IT simply revokes the single credential, instantly cutting off access everywhere.

Initiatives like the Known Traveler Digital Identity (KTDI) aim to replace the friction of physical passport control. A traveler can package their digital passport, visa, and flight ticket into a presentation and share it securely with the destination country's customs agency before they even board the plane. Customs pre-verifies the cryptographics, allowing the traveler to walk through seamless biometric corridors upon arrival.

Machines need identities too. A smart energy meter, for example, can be assigned a digital wallet and a DID at the factory, containing a credential that proves it was built by a certified manufacturer. Before the central power grid allows that meter to connect, it challenges the meter to present its credential - instantly thwarting hackers trying to connect counterfeit, malicious devices to the network.

• Benefits: Using Zero-Knowledge Proofs, a citizen could cryptographically prove they are registered to vote and that they cast exactly one ballot, without revealing who they voted for, making the election both highly secure and perfectly verifiable.
• Risks: Remote digital voting introduces the risk of coercion (a bad actor demanding a voter choose a certain way) and malware (a compromised smartphone altering the vote locally before it is sent).

Right now, your reputation and assets are locked within specific games - your World of Warcraft achievements mean nothing in Fortnite. With decentralized identity, a player could earn a Verifiable Credential representing a rare digital item, an e-sports ranking, or a verified age check. They carry this credential in their personal wallet and can plug it into entirely unaffiliated virtual worlds, making digital achievements truly portable.

When an Issuer creates a credential, they run the data through a mathematical algorithm to create a hash (a unique digital fingerprint). The Issuer encrypts this hash using their Private Key, creating a digital signature. When the Verifier receives the credential, they use the Issuer's Public Key to decrypt the hash, then re-hash the received data. If the two hashes match exactly, it mathematically proves that not a single character of the data was altered in transit.

Selective Disclosure is a privacy feature powered by advanced cryptography (like BBS+ signatures). It allows a Holder to take a credential that contains 10 pieces of data and only reveal 1 piece to a Verifier. Crucially, the Verifier can still mathematically verify that the Issuer signed the entire original document, without ever seeing the other 9 hidden fields.

ZKPs allow you to prove that a specific statement is true without revealing the data that makes it true. For example, if a bouncer needs to know you are over 18, a ZKP allows your wallet to mathematically prove to the bouncer's system that your date of birth is greater than the required threshold, yielding a True or False result - without the Verifier ever learning your actual birth date.

If you use the exact same DID to log into your bank, your healthcare provider, and a retail store, those companies could collude to track your activity across the web - this is "linkability." Pairwise DIDs solve this: your wallet automatically creates a brand-new, unique DID for every single relationship. The bank sees DID "A", the store sees DID "B", making cross-profile correlation impossible.

Issuers cannot publish a public list of names whose credentials have been revoked, as that violates privacy. Instead, systems use privacy-preserving mechanisms like Status Lists or Cryptographic Accumulators - complex mathematical lists of anonymous, randomized numbers representing credentials. A Verifier can check if a credential's anonymous number is on the "revoked" list without learning anything about who owns the credential.

The Secure Enclave is a dedicated, physically isolated chip inside a smartphone. When your digital wallet generates your private cryptographic keys, they are created inside this chip and physically cannot be extracted or copied by the operating system or other apps. When your wallet needs to sign a credential presentation, the data is sent into the enclave, signed, and sent back out.

Blockchains are immutable - data written to them can never be deleted. If you put PII on a blockchain, it is permanently exposed, fundamentally violating privacy laws like the GDPR's "Right to be Forgotten." Verifiable Credentials avoid this by storing all PII entirely off-chain in your local digital wallet. Only the public, non-identifying cryptographic keys (DIDs) are anchored to the blockchain.

Think of an accumulator as a mathematical "bucket" into which an Issuer can add values (representing active credentials). A Verifier can run a calculation to prove whether a specific value is currently inside the bucket. If an Issuer revokes a credential, they simply recalculate the bucket's total value without that credential. The Verifier checks the new bucket value, sees the credential is no longer included, and knows it is revoked - all without anyone seeing the bucket's contents.

Because the private keys are locked inside the device's hardware Secure Enclave, a hacker cannot simply copy the wallet files and paste them onto a new phone. The copied wallet would lack the private keys necessary to prove ownership of the credentials or sign any presentation requests, rendering the copied data useless.

Through Biometric Binding, credentials are locked so that the hardware Secure Enclave will absolutely refuse to sign a presentation proof unless it receives a fresh, successful biometric authentication (like FaceID or fingerprint scan) from the authorized owner at the exact moment of the transaction. This ensures you can't simply hand your phone to a friend to use your digital ID.

A well-implemented mobile ID discloses less than a physical card. 18013-5 builds privacy into the protocol through five mechanisms, though some depend on how issuers and wallets implement them.

Only approved elements are sent. A bouncer checking age needs age_over_21 and portrait, not the name, address or document number. A car rental desk needs the name, driving privileges and expiry date, not the home address.

Instead of a birth date, the issuer can pre-compute boolean elements such as age_over_18 and age_over_21. Each one is separately salted and hashed, so disclosing age_over_21 = true reveals nothing about the exact age. Issuers choose which thresholds to include based on local law: 16, 18, 19, 21 and 65 are common.

For every requested element, the reader must declare whether it intends to store the value after the transaction - the IntentToRetain flag. The wallet shows this to the holder. A reader that only displays data for a visual check should set the flag to false.

Offline device retrieval means the issuer is not contacted during the transaction. The issuing authority therefore cannot build a log of where, when or to whom a citizen showed their ID.

If the same MSO, device key and salts were reused everywhere, colluding verifiers could recognise the same credential across transactions by comparing signatures or digests.

Good practice is for issuers to provision batches of short-lived MSOs, each with fresh salts and its own device key, and for wallets to use a different one per presentation. Ephemeral session keys and the DeviceMac option further reduce linkability. Unlinkability is therefore an implementation choice that issuers should specify explicitly.

Cryptography can mathematically prove who signed a credential, but it cannot prove if that person is trustworthy. A Trust Framework is the "legal and business layer" - a set of rules, policies, and legal agreements that dictate, for example, which universities are officially accredited to issue degrees, or which banks are liable if a KYC credential is fake. Without these legal rules, Verifiers wouldn't know which cryptographic signatures to actually trust.

eIDAS 2.0 is a massive legislative shift that requires every EU Member State to offer a standardized European Digital Identity (EUDI) Wallet to its citizens. It allows citizens to prove their identity and share electronic documents across all of Europe, and legally mandates that large online platforms (like Big Tech companies) and public services must accept it as a valid form of login and verification.

The main challenge is fragmentation. Europe leans heavily toward OpenID protocols (OIDC4VC), North America often experiments with W3C standards (DIDs and JSON-LD), and the mobile driver's license space relies on ISO standards (mDL). For true global interoperability, a wallet needs to be able to "speak" all these different technical languages, and international laws must be aligned so a digital credential issued in Tokyo holds legal weight in Toronto.

They are practically designed for it. The GDPR requires Data Minimization (sharing only what is necessary) and the Right to be Forgotten (the ability to delete your data). Because Verifiable Credentials use Selective Disclosure and store personal data locally on the user's device rather than permanently on an immutable blockchain, users have absolute control over their data.

The Digital Divide is the risk of excluding the elderly, the unhoused, or those in developing nations without access to expensive smartphones or reliable internet. Solutions being actively developed include:

• Hardware Smart Cards which hold keys and act like a physical wallet.
• Delegated Guardianship where a trusted family member or social worker manages credentials on someone's behalf.
• Verifiable Paper - printing a cryptographically signed QR code on physical paper.

If a hospital needs to verify 10,000 digital nurse licenses a day, humans cannot manually read legal contracts to check if the issuing medical boards are legitimate. Machine-readable governance translates Trust Frameworks into code (via Trust Registries). A Verifier's software can instantly ping an API to ask, "Is the Issuer's DID currently on the government's authorized list?" and get an automated Yes/No, processing trust at the speed of the internet.

They are the architects ensuring we don't end up with "walled gardens." If Apple, Google, and Microsoft all built proprietary digital IDs that couldn't talk to each other, the system would fail. The W3C, OpenID Foundation, and ISO create the open, royalty-free blueprints ensuring that a wallet built by a startup uses the exact same cryptographic data structures as a wallet built by a trillion-dollar tech giant.

Generally, liability is distributed based on the Trust Framework:

• Issuers are liable if they issue a credential based on fraudulent background checks.
• Wallet Providers are liable if their software has vulnerabilities that allow a hacker to steal the user's private keys.
• Verifiers are liable if they request too much data or fail to secure the data after the user presents it to them.

It represents a shift from "platform-centric" to "user-centric" data. Currently, companies spend billions verifying documents, managing passwords, and dealing with data breaches. By creating a missing "Trust Layer" for the internet, digital credentials will drastically lower the cost of doing business, eliminate entire categories of fraud, and allow individuals to monetize or strictly protect their own data, fundamentally changing the power dynamics of the web.

There are over 100 different ways to anchor a DID. The Universal Resolver acts as a standardized API gateway. A Verifier sends any DID to the Resolver, and the Resolver acts like a router, forwarding the request to the specific protocol driver required to fetch and return that DID's public keys - without the Verifier needing to support the custom code for all 100+ DID methods.

While many DIDs rely on blockchains, did:web allows an organization to anchor its identity directly to its existing web domain (e.g., did:web:university.edu). It leverages the traditional DNS and TLS certificates for security. This makes it incredibly easy for enterprises to adopt, manage, and prove their authoritative identity without needing to interact with or pay transaction fees on a blockchain network.

KERI is a highly advanced identity protocol that completely removes the dependency on a centralized blockchain. Instead of publishing cryptographic keys to a shared ledger, KERI uses "ambient verifiability." The history of a user's key creation and key rotations is maintained in a cryptographic log. Users prove their identity by passing these cryptographically signed "receipts" directly to one another peer-to-peer.

Standard JWTs are universally used in web development but lack privacy - if you share the token, you share all the data inside it. SD-JWT adds Selective Disclosure to these traditional tokens. It is gaining massive adoption (especially in the EU's eIDAS 2.0 framework) because it allows developers to build highly privacy-preserving credentials without having to learn entirely new, complex data structures like JSON-LD.

OID4VCI is a standard developed by the OpenID Foundation that defines a secure API for an Issuer to send a digital credential to a Holder's wallet. It is widely adopted because it is built on top of the heavily utilized OAuth 2.0 protocol, allowing organizations to plug verifiable credential issuance directly into the identity systems they already use (like Keycloak or Okta), drastically lowering the barrier to entry for developers.

Defined within the OID4VCI specification, the Pre-Authorized Code Flow is used when an Issuer already knows who the user is and wants to push a credential to them with minimal friction. The Issuer generates a unique PIN or QR code and sends it to the user. When the user opens this link with their wallet, the wallet uses the pre-authorized code to instantly download the credential - bypassing the need for the user to create a new login account with the Issuer.

Before an Issuer mints a digital credential, they must verify the person in the real world. OIDC4IDA is a protocol extension that transmits the context of how a user was verified (e.g., "Verified via physical passport scan at a bank branch with high assurance"). This contextual data is embedded directly into the credential, allowing the final Verifier to judge whether the Issuer's initial background check was rigorous enough for their needs.

During standard OAuth issuance, if a hacker intercepts the user's access token, they could theoretically download the credential themselves. DPoP prevents this by legally "binding" the token to the private key held inside the user's digital wallet. When the wallet requests the credential, the Issuer's server mathematically verifies that the request was signed by the exact same private key that the token was issued to, instantly stopping token-replay attacks.

DIDComm (Decentralized Identifier Communication) provides a secure, private communication channel between any two entities using DIDs. Unlike standard web traffic which relies on central certificate authorities (SSL/TLS), DIDComm uses the public/private keys inherently tied to the users' DIDs to create end-to-end encrypted messaging. It is transport-agnostic, meaning it can run over HTTP, WebSockets, or even offline over Bluetooth.

Traditionally, connecting a digital wallet to a website required scanning a QR code. The W3C Digital Credentials API is a browser-level protocol that integrates digital wallets directly into the web browser's architecture. When a website requests a credential, the browser natively prompts the user to select their wallet (similar to how Apple Pay works), creating a seamless, phishing-resistant user experience.

Before the browser-native W3C Digital Credentials API existed, CHAPI was developed as a browser polyfill protocol. It allowed websites to broadcast a request for a credential, and allowed users to register their preferred web-based wallet to "catch" and respond to those requests. It served as the vital pioneering protocol that proved wallet-to-browser interoperability was possible.

OID4VP allows a Verifier to securely request and receive a verifiable credential from a Holder's wallet. The Verifier sends an Authorization Request to the wallet. The wallet authenticates the user, generates a presentation containing the requested credentials, and posts it back to the Verifier's secure endpoint - all without relying on a centralized identity provider.

In traditional OpenID Connect, Google or Microsoft acts as the OpenID Provider (OP) that authenticates you. SIOPv2 flips this model: your personal digital wallet becomes the OpenID Provider. When a website asks for authentication, the request goes straight to your wallet. You authenticate locally on your device, and your wallet securely passes the login token to the website, cutting out the middleman.

In standard OAuth, a Verifier uses simple "scopes" (like scope=email) to ask for data. RAR allows the Verifier to send a highly detailed, machine-readable JSON object during the authorization flow, specifying exact credential types, required cryptographic algorithms, and specific Trust Frameworks the credential must adhere to.

Presentation Exchange provides a standard JSON-based language for Verifiers to write "Presentation Definitions." Instead of just asking for a "driver's license," PE allows a Verifier to programmatically request: "I need a credential issued by the California DMV, I only want the 'over_21' attribute, and it must be signed using an active ES256 cryptographic key."

WACI is the connective tissue between the Presentation Exchange (PE) data format and the DIDComm messaging protocol. While PE defines what data the Verifier wants, WACI-DIDComm defines the exact sequence of encrypted messages - the "handshake" - used to securely request, negotiate, and deliver that data between the Verifier and the wallet.

ISO 18013-5 is designed for in-person scenarios without internet access (like a traffic stop). The standard specifies that device-to-device data transfer between the phone and the reader must happen via secure, localized protocols: NFC (Near Field Communication), Bluetooth Low Energy (BLE), or WiFi Aware.

While ISO 18013-5 handles offline, proximity-based presentations, ISO/IEC 18013-7 defines the protocols for presenting an mDL over the internet (remote presentation). It profiles existing web standards to allow a user to securely present their mobile driver's license to a website - for example, to buy age-restricted goods online.