What a Verifiable Credential Attests To: The W3C Model in Plain Terms

Every operator who carries a wallet already understands the shape of a credential. The driving licence is a tamper-resistant card whose authorship — the issuing authority, with its lithography, holograms and machine-readable zone — is what makes the credential believable to a third party. The bank card is a signed object whose validity any merchant can check without phoning the bank. The passport is a government-issued identifier whose verifier — the border officer — reads what the issuer signed and decides whether the holder is the same person the credential describes. Compliance teams already know the analogue framework. What changes when the same shape is rebuilt as software is what the verifier learns at presentation time, what the issuer continues to retain after issuance, and how the architecture defends itself across hundreds of integrating platforms.

That is the question the W3C Verifiable Credentials Data Model exists to answer. The specification has matured past the standards-body stage; this week, two regulators and one direct competitor pushed it into immediate operating focus. Sumsub launched a Cross-Chain Identity (CCID) credential with Chainlink on 5 May 2026, framed as a "reusable, privacy-preserving credential containing verified claims like 'Age > 18'" (3). FinCEN re-issued its consolidated Customer Due Diligence FAQs in early May 2026, codifying a direction-of-travel that rewards previously-verified facts over fresh evidence re-collections (4). FATF's Singapore mutual evaluation, issued 6 May 2026, rated even one of the world's most coordinated regimes only moderately effective on ultimate beneficial ownership outcomes (6). For practitioners reading this, the question stops being what is a verifiable credential and starts being what does the credential actually attest to, and what does the verifier learn when it is presented. This article walks the W3C three-party model in plain terms, maps it onto the live competitive landscape, and closes on what a Zero-Knowledge KYC attestation contains in production. We use the abbreviation VC (and VCs for the plural) interchangeably with the full form "verifiable credential(s)" hereafter, following the W3C convention.

A verifiable credential is not a digital document

The driving licence in the wallet — what the analogue object actually does

Pull a driving licence out of a physical wallet and three things happen at once. The card identifies the holder by name, photo and date of birth. It carries a set of claims the issuer has asserted — the licence class, the validity period, the country of issuance. It is constructed so any third party — a hire-car desk, a border officer — can satisfy themselves it is authentic without phoning the issuing authority. The lithography, holograms, printed micro-text, machine-readable zone: every element is a signature property the issuer baked into the object so the verifier can check the credential without re-running the underlying verification.

Physical credentials work this way at scale because the cost of forging the issuer's signed properties is high, and because the verifier knows what to look for. The same logic underlies the passport, the national identity card, the professional credentials a doctor or lawyer hangs on a wall, the membership cards, the bank cards. Different categories of credentials, but the same architecture: an issuer asserts claims about a subject; the subject holds the credential; a verifier checks the credential's signed properties. Three parties, three roles, one mechanism.

The W3C VCDM 2.0 definition — a tamper-evident credential whose authorship can be cryptographically verified

The W3C Verifiable Credentials Data Model 2.0, issued as a W3C Recommendation on 15 May 2025 (https://www.w3.org/TR/vc-data-model-2.0/), defines the digital equivalent in a single sentence. "A verifiable credential is a tamper-evident credential whose authorship can be cryptographically verified" (1). Three properties carry the entire model: the credential is tamper evident (any modification to the claims after the issuer signed them is detectable; a tampered version never passes the cryptographic check); the credential's authorship can be cryptographically verified (the verifier can satisfy themselves the issuer they trust signed it, without phoning the issuer); and the credential carries claims (statements about the subject the issuer has asserted are true at issuance time). The credential created by the issuer carries those three properties from issuance through every subsequent presentation.

The W3C verifiable credentials data model formalises the analogue intuition into a digital data model. Where the driving licence's hologram is the physical signature property, the VC's cryptographic proof — typically a digital signature applied by the issuer using their private key — is the digital signed property. Where the licence's printed details are read from a card, the VC's claims are expressed in a structured format, typically JSON. Where the border officer checks a card visually, a verifier checks a credential by running a cryptographic check against the issuer's public key. The verifiable credential is what the wallet contains; the verifiable credentials data model specification at https://www.w3.org/TR/vc-data-model-2.0/ defines the shape of what the wallet holds.

How a verifiable credential differs from physical credentials in everyday use

The driver's licence example makes the contrast concrete. A government-issued physical driver's licence carries claims printed onto a plastic card — the holder's name, photo, date of birth, licence class, expiry date — and the issuer's authorship is proven by lithography, holograms, micro-text and the machine-readable zone the issuer baked into the card. A verifier can satisfy themselves the card is valid without phoning the issuing authority. The same set of claims, rebuilt as a verifiable credential, lives in the holder's digital wallet as a structured JSON object signed by the issuing authority's cryptographic keys. The issuer signs the credential with a private key; the verifier checks the signed credential against the issuer's public key. The credential is cryptographically secure in a way the physical card is not — and it is tamper-proof in a stronger sense than the physical equivalent, because any modification to the signed claims after issuance breaks the digital signatures the verifier checks. A tampered credential never passes the cryptographic check.

Why the digital version is harder to tamper with comes down to the cryptographic keys. The private key is what proves the credential is not tampered with — only the issuer holds that key. If anyone modifies a single claim in the VC after the issuer signed it, the cryptographic check fails. With a physical credential, the verifier looks for hologram tampering, printed-claim alteration, embossing irregularities; the visual check is good but not perfect. With the digital equivalent, the cryptographic check is mathematical — either the digital signatures verify against the issuer's public key, or they do not. Government-issued physical credentials rely on the verifier's training to spot tampered records and tampered embossing; the verifiable-credential version delegates that work to public-key cryptography. A digital credential is also verifiable cryptographically without contacting the issuer, and is presentable as the holder chooses with selective disclosure built in — a physical driver's licence shows everything to anyone who looks at it, while a VC of the same content shows only the claims the holder has chosen to share.

Why the digital version is not a PDF of the analogue version

A common starting confusion treats the digital credential as a scan of the analogue one. It is not. A PDF of a passport is a copy of a record; a verifiable credential is a signed claim about the subject the record describes. What the verifier learns when a PDF is presented is the record itself — every field, every photograph, every personal detail printed on it. What the verifier learns when a VC is presented is the subset of claims the holder chose to disclose, cryptographically verified against the issuer's signed proof, with no underlying record anywhere in the exchange. A PDF leaks; a verifiable credential discloses.

This is what the digital credentials category labels — verifiable digital credentials, mobile driver's licences, the NIST framing of subscriber-controlled wallets (11) — all converge on. The digital wallet is not a folder of scanned records. It is a holder of cryptographically signed credentials whose presentation surface is controlled by the subject, expressed in a standard format, and verifiable against the issuer's public key without any record re-transfer. The analogue object solved one half of the problem (the issuer's signed property the verifier can check); the digital data model solves the other half (the holder's control over what the verifier sees). Verifiable credentials are not PDFs of paper credentials; they are the structural answer to the question paper credentials never quite solved.

The three-party model: issuer, holder, verifier

The issuer: who signs the claim

In the W3C verifiable credentials data model, the issuer plays a single, well-defined role users and verifiers can rely on. The W3C VCDM 2.0 specification puts it precisely: the issuer is "a role an entity can perform by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder" (1). Three verbs: asserts, creates, transmits. The issuer asserts claims it has authority to assert (a university asserts a degree was awarded; a government agency asserts an identity document is valid; an identity provider asserts an identity has been verified). The issuer creates the credential — combining the claims with the issuer's identifier, the issuance date, and the proof object carrying the cryptographic signature. Once created and signed, the credential cannot be modified without breaking the proof. The issuer transmits the credential to the holder, typically into the holder's digital wallet via an issuance protocol; once issued, the credential lives on the holder's device.

Different issuers sign different types of credentials. A university issues degree credentials to students; a government agency issues identity credentials; an employer issues employment credentials to employees; a healthcare institution issues professional credentials for doctors. The credential subject is identified inside the credential, often via a decentralized identifier. The issuer's authority to assert the claim makes the credential trustworthy and lets verifiers verify the claim without phoning the issuer. Trust rests on the verifier's ability to verify the signed credential, not on prior knowledge of the underlying users. Each credential the issuer signs is a verifiable credential that carries its own trust path: the issuer signs the credential, the holder receives it, the verifier checks it. Credentials created by recognised issuers — universities, government agencies, employers, healthcare institutions — flow into the holder's wallet across many use cases. Trust between the three parties is what the verifiable credentials specification standardises.

The issuance leg of the model is where protocols come in. OpenID for Verifiable Credential Issuance (OpenID4VCI) is the standards-body specification that defines how an issuer signs and a wallet stores. The OpenID Foundation's final specification "defines an API and corresponding OAuth-based authorization mechanisms for issuance of Verifiable Credentials" (12). Adoption is past the experiment stage: more than 30 jurisdictions have selected and are deploying OpenID4VCI to support digital identity credential issuance to digital identity wallets (12). An issuer-side implementation does not invent the credentials offer flow; the flow follows a published specification that interoperates across wallets.

How an issuer signs and a wallet stores — the issuance leg in plain terms

The issuance leg has a precise shape and a defined sequence of steps. The W3C VC framework, the OpenID4VCI protocol, and the JSON-LD format all describe each step. When the issuer signs a credential, the resulting object is a JSON-LD document carrying the credential subject's claims, the issuer's identifier, an issuance date, an expiration date, and a proof object. Every verifiable credential begins with a @context field that points to the W3C namespace URI https://www.w3.org/2018/credentials/v1 (or the v2 successor at https://www.w3.org/ns/credentials/v2). The context URL declares which version of the verifiable credentials data model the credential follows. The credential's id property is typically a URL or URI that uniquely identifies the credential within the issuer's system. The credential subject's identifier is often a decentralized identifier — a did: string — which the verifiable credential model uses to point to the holder without binding the credential to any centralised registry.

Decentralized identifiers (DIDs) are how the credential subject is referenced. A DID is a URI that resolves to a DID document containing the subject's public key and any service endpoints. The W3C verifiable credentials specification uses DIDs because the credential subject identifier needs to outlast any single issuer or integrating platform, and because the holder needs to demonstrate control of the subject identifier independently of the issuer that signed the credential. OpenID Connect, the federation protocol most web developers already know, is the lineage OpenID4VCI builds on; the issuance protocol layers verifiable-credential issuance semantics on top of the OAuth-based authorisation flows OpenID Connect already standardised. Information passes between issuer, holder and verifier as structured JSON objects whose interpretation the W3C standard defines.

The credential metadata — issuance date, issuer identifier, expiration, credential type — is included alongside the claims as structured JSON. The proof object carries the digital signature, the proof purpose (typically proofPurpose: assertionMethod), the verification method URL pointing to the issuer's public key, and the proof value as a string. Once the issuer has signed the credential, it is transmitted to the holder's wallet via the OpenID4VCI credentials offer flow — the holder's wallet receives the offer, authenticates to the issuer's endpoint, and pulls the signed credential into local storage. The steps — issuer signs, transmits, wallet receives, wallet stores — are the same regardless of which jurisdiction's wallet implements them. The verifiable credential framework and its protocol layer settle the issuance question for web developers building issuer applications: the credential is a structured JSON object, the namespace URI declares the context, the proof object carries the signed value, and the wallet stores the resulting credential securely on the holder's device. The pattern works across many use cases — VCs issued for identity attestations, education, employment, professional certificates and government credentials all use the same JSON-LD shape, the same proof object format, and the same OpenID4VCI issuance protocol to reach the user's wallet.

The holder: where the credential lives between issuance and presentation

The holder is the second role in the model. The holder receives the credential from the issuer, stores it securely in a digital wallet, and decides what to share with which verifier. Individuals holding verifiable credentials are the parties making disclosure decisions; users hold credentials and present them when integrating platforms request them. NIST's Special Publication 800-63-4, finalised July 2025, "enhances FALs by requiring cryptographic binding in federated transactions and formally integrating user-controlled wallets and verifiable credentials" into the federation model and uses the term "subscriber-controlled wallets" to describe what the holder operates (11). The holder's wallet is where the credential lives between issuance and presentation, and where the holder decides what the verifier sees.

The wallet's design matters because it determines who actually controls the credential. A digital wallet living on the holder's device, encrypted and accessible only via the subscriber's authentication, gives the holder custody. A wallet living on a vendor's centralised server gives the vendor custody. The W3C verifiable credentials framework is agnostic about deployment topology, but the framework's privacy property holds only when the holder genuinely controls what the wallet discloses. EUDI Wallet ARF v2.7.2 makes the subscriber-controlled wallet a regulator-mandated property — the wallet must give the holder selective-disclosure control over what the verifier learns (10).

What the holder presents at request time is not the credential itself, but a verifiable presentation constructed from one or more credentials. The W3C VC Overview (https://www.w3.org/TR/vc-overview/), issued 24 September 2025, describes the flow plainly: "An issuer issues a Verifiable Credential to a holder" who then "presents one or more of its Verifiable Credentials to a verifier" who subsequently "verifies the authenticity of the presented Verifiable Presentation" (2). The presentation is a wrapper the holder constructs at presentation time; it carries only the claims the holder chooses to expose, and it carries them with the issuer's original cryptographic signature still attached. The verifier learns what the holder discloses; the holder retains everything else.

The verifier: what the integrating platform actually receives

The verifier is the third role, and the one most relevant to regulated firms. The verifier is the integrating platform — the system that needs to verify something about the subject before granting access, completing onboarding, or releasing a service. What the verifier receives at presentation time is a verifiable presentation: a structured object containing the claims the holder chose to disclose, the issuer's identifier, and a cryptographic proof the verifier can check against the issuer's public key.

The verifier checks the credential's cryptographic signature in real time against the issuer's public key — a property of the W3C VC verification protocol, not a property of the issuer's screening cadence. The check follows three steps: step one, the verifier confirms the credential was issued by the issuer the verifier trusts; step two, the verifier confirms the claims have not been modified since issuance; step three, the verifier confirms the holder controls the credential subject identifier. If all three steps pass, the verifier has a cryptographically secure basis to act on the disclosed assertions.

What the verifier does not receive is the underlying record, the underlying personal data, or any claim the holder chose not to disclose. This is the architectural property that distinguishes the W3C verifiable credentials framework from a record-transfer architecture. In a traditional verification flow, the verifier receives the record; in a VC flow, the verifier receives a verifiable presentation containing only the claims the holder selectively disclosed. The credential itself remains in the wallet.

This is the framework we built Verifyo around. We act as the issuer — the party that ran the verification and signed the attestation. The user's digital wallet acts as the holder. The integrating platform acts as the verifier, querying the credential's status without ever receiving the underlying records. The three-party separation is not a marketing wrapper; it is the architecture, and the operational privacy property is a direct consequence of the separation holding under production conditions.

Verifiable presentations and selective disclosure

What the verifier learns versus what the issuer holds

The verifiable presentation is the unit the W3C verifiable credentials framework exposes to the verifier. A verifiable presentation can carry one or many VCs and can expose claims at varying levels of detail. The W3C VC Overview describes the presentation as the artefact the holder constructs and the verifier verifies the authenticity of (2). The verifier learns precisely what the verifiable presentation discloses — and nothing more.

Compare this to what the issuer continues to retain. The issuer needed the underlying personal data and personal information at the moment of issuance — to run the verification, to make the assertions the credential carries, and to satisfy any statutory record-retention obligation. Whether the issuer continues to retain that data after issuance is an architectural choice the issuer makes, not a property of the W3C framework itself. Two issuers running the same verifiable credentials pattern can carry materially different residual data footprints. The verifier does not see the difference at presentation time — only that the credential's cryptographic signature has not been tampered with since issuance — but the difference is exactly what determines whether the architecture's privacy property holds.

Selective disclosure in plain language

Selective disclosure — sometimes called minimum disclosure — is the W3C mechanism that lets a holder expose only the claims a verifier needs, while keeping everything else in the credential private. The eIDAS 2.0 framework codifies the property in regulator-binding terms: the European Digital Identity Wallet allows EU residents "to prove a specific personal attribute, such as age, without revealing their full identity or other personal details" (9). The regulator names the property and mandates its presence; the W3C specification provides the technical mechanism that implements it.

In plain language, selective disclosure means the holder can prove a specific claim is true without revealing the underlying data the claim was derived from. The holder proves they are over 18 without revealing the date of birth. The holder proves they passed sanctions screening without revealing their full identity. The holder proves they hold a valid government-issued identity credential without revealing the underlying document image. The cryptographic proof the issuer signed is what the verifier checks; the underlying data remains in the credential, exposed only to the extent the holder chose to disclose.

The university degree example shows the property at work outside regulated-firm use cases. An example university issues a verifiable credential carrying a bachelor's degree to a graduating student. The student receives the credential the issuer created into their digital wallet — a JSON-LD object signed by the university's private key, carrying the claims that the student was awarded the degree, the date of conferral, the field of study, the GPA, and the transcript reference. When the student applies for a job, the prospective employer asks the student to prove they hold a bachelor's degree from a recognised institution. The student's wallet constructs a verifiable presentation that exposes only the boolean — "holds a bachelor's degree from example university" — without revealing the GPA, the specific date of graduation, the transcript or the underlying education attributes. The employer's verifier checks the cryptographic signature against the university's public key and learns the boolean is true. Different employers asking for different attributes — qualifications for an accreditation board, certificates for a licensing body, education attestations for a recruitment platform — receive different verifiable presentations from the same underlying VC, each one carrying only the objects the verifier needs.

The architectural property is the same one regulated firms use to verify identities. Students sharing degree claims, employers verifying qualifications, professionals presenting employment credentials, individuals proving identities — every case is the holder constructing a verifiable presentation that exposes a specific subset of attributes from one or more VCs, with the issuer's cryptographic signature still attached. Selective disclosure is enabling the holder to share only what the use case needs; the credential itself stays whole in the wallet, ready for the next presentation. Users share verifiable credentials with verifiers many times across the credential's lifetime. Universities issuing diplomas, employers verifying employment, regulated firms running customer due diligence — the W3C mechanism applies identically across cases, even though the types of credentials being shared differ widely.

Different presentation formats expose different levels of granularity. A presentation can disclose every claim in the credential, only the specific attributes a verifier requested (selective disclosure), or use zero knowledge proofs to prove a claim is true without revealing the underlying value (proving age over 18 without disclosing the date of birth at all). The verifier and holder agree on the level of disclosure required for the use case.

The boolean as the minimum-disclosure surface

For regulated-firm verification, the minimum-disclosure surface is typically a boolean. The verifier asks "is this user verified?" and receives kyc_status: verified. The verifier asks "is this user over 18?" and receives age_over_18: true. Each boolean is independently verifiable against the issuer's signed proof; each is a strict subset of the underlying personal information the issuer used to derive the claim.

This is the worked example for Verifyo. When an integrating platform queries a Verifyo-verified wallet, the public attestation it receives carries exactly the following set of claims:

{
  "zk_kyc_token": "ZKYC_<token>",
  "identity": "identity-<pseudonym>@id.verifyo.com",
  "kyc_level": 1,
  "kyc_status": "verified",
  "document_country": "<ISO-2 country code>",
  "residence_country": "<ISO-2 country code> | null",
  "age_over_18": true,
  "age_over_21": true,
  "aml": {
    "sanctioned": false,
    "barred": false,
    "criminal": false,
    "pep": false,
    "military": false,
    "adverse_media": false
  }
}
Plain Text
Copy

The verifier learns the boolean. The verifier does not learn the underlying record, the date of birth, the underlying screening evidence, or the user's name. The document_country is exposed as an ISO-2 code so an integrating platform can satisfy a regulator's country-of-issuance requirement, but the underlying record itself is not transmitted. The residence_country is exposed in the attestation but is self-declared, not verified — the honest scope footprint. Six AML booleans cover sanctions, barred-persons, criminal record, PEP, military-personnel and adverse-media screening. Together, the attestation set is the worked example of what a verifiable presentation looks like when the W3C selective-disclosure mechanism is applied to regulated-firm use cases.

The architecture is interoperable with the W3C verifiable credentials data model and with the broader EUDI Wallet ARF and EBSI reference implementations that use this W3C standard "to ensure interoperability and wide adoption" (8). What changes from one issuer to another is not the credential format; it is what the issuer retains after the credential is signed.

Reusable KYC as a verifiable credential

Where regulated-firm attestations slot into the W3C framework

Regulated-firm attestations created by an identity provider slot into the W3C three-party framework cleanly. The issuer is the identity provider that ran the verification — the party with the regulatory permissions, the underlying record-handling capability, and the authority to assert the claims. The holder is the natural person whose identity was verified — the credential subject, identified inside the credential by an identifier the issuer assigned (often a decentralized identifier, often a wallet-bound pseudonym). The verifier is the integrating platform — the regulated business that needs to know the user's verification status before completing onboarding, releasing a transaction, or granting access to a service.

The re-presentation property follows from the framework. Once the issuer has signed the credential, the holder can present it to many verifiers without re-running the underlying verification. A user who completes verification once can prove the resulting status — kyc_status: verified, age_over_18: true, the AML screening booleans — to every integrating platform that recognises the issuer's signed credential. The integrating platform does its own check (cryptographic verification of the issuer's signed proof, evaluation of the booleans against its own risk policy), but the platform does not need to re-collect submissions the user has already shown to a recognised issuer. Verified once at the issuer, the credential created at that point is recognised by every integrating platform that trusts the issuer's signed credential. This is what re-presentation means in practice.

For practitioners building verifiable-credential-shaped verification, the operational case has been made: see reusable KYC operates at scale for why repeated submission re-collection at every integrating platform is incompatible with how onboarding actually scales. The W3C verifiable credentials framework is the structural answer; treat verification as infrastructure rather than a one-off check, as Finextra's control-plane framing put it.

How a wallet stores and the holder shares a reusable credential — the day-to-day mechanics

The day-to-day mechanics are how the W3C verifiable credentials framework translates into something users actually interact with. Once an issuer has signed and transmitted a credential, it is stored securely in the holder's digital wallet — typically a wallet application installed on the user's phone or device. The credential is stored in encrypted local storage; access requires the user's authentication (biometric or PIN); the wallet manages the keys that bind the credential to the device. Wallet providers compete on the security guarantees they offer around storage, authentication and key recovery, but the underlying pattern is consistent across every W3C-compliant wallet: the credential stays on the holder's device, and the wallet decides when and how it is presented.

When an integrating platform requests the credential at account creation or sign-in, the request reaches the holder's wallet over a defined channel — typically a QR code displayed on the integrating platform's screen, a deep-link the user clicks, or a wallet-to-wallet message. Three steps describe what the wallet does next: step one, the wallet receives the request and parses what claims the verifier is asking for; step two, the wallet presents the holder with a consent screen showing exactly what is about to be shared; step three, the wallet constructs the verifiable presentation, signs it with the holder's key, and sends it back to the verifier. The verifier receives the presentation, runs the cryptographic check, and grants access if the assertions satisfy its risk policy.

The pattern works across many platforms and individuals. The same credential is stored once and presented many times — at one platform's account creation, at another platform's sign-in, at a third platform's transaction-approval flow. Users hold the credential between presentations and decide each time what to share. Streamline onboarding flows compose around this pattern: the integrating platform asks for the claims it needs; the wallet returns the presentation; the platform verifies and proceeds. Reducing friction at every onboarding touchpoint is what verifiable credentials achieve operationally — users do the verification once, receive the credential into their wallet, and then send presentations to every integrating platform from the same underlying account. The architecture is what the W3C verifiable credentials specification mandates; Verifyo's role in the pattern is described elsewhere as the issuer.

The attestation set as a minimum-disclosure credential

Verifyo's Level 1 attestation set is a worked example of a minimum-disclosure verifiable credential applied to natural-person identity verification. The credential carries identity-document validity (the issuer asserts a valid government-issued document was checked), age claims (age_over_18, age_over_21 as separate booleans, derived from the verified document), document country (as an ISO-2 code), and the AML screening booleans. Each claim is a strict subset of the personal information the issuer used at verification time. The verifier reading the attestation learns the booleans needed to act; the underlying personal data does not move. What changes between issuers is the data footprint each one keeps after the credential is created and signed.

This is the natural example we built Verifyo around. We act as the issuer of a Zero-Knowledge KYC attestation — the party that ran the verification and signed the verifiable credential. The user's wallet acts as the holder. The integrating platform acts as the verifier, querying the attestation's status and receiving the booleans the use case requires. The credential is presented across every platform that recognises Verifyo as an issuer; the user verifies once, and the VC is presented selectively each time an integrating platform needs to confirm verification status. The check the verifier runs is cryptographic; the underlying record the verifier never sees stays out of the integrating platform's data store. Trust between the issuer, the holder and each verifier is what the W3C verifiable credentials framework standardises.

The W3C VC framework supports many credential categories — address, education, professional credentials, business — that the EUDI Wallet ARF and EBSI demonstrate. Verifyo's Level 1 attestation set covers natural-person identity claims today; address verification, KYB, and EDD-tier attestations are on the regulatory CDD spectrum but not part of Verifyo's current attestation set. The W3C verifiable credentials specification is broad; our attestation set is what is live in production today.

Why reusable beats redundant — the operational case for verifiable credentials

The operational case for verifiable credentials is the case against redundant submission re-collection. In a record-transfer architecture, users verifying with one platform must verify again with the next. Ten platforms means ten record collections, ten copies held by ten integrating platforms, ten data stores subject to whatever breach surface and retention obligation each integrating platform operates under. The friction is operational; the breach surface is structural. Re-presentable verifiable credentials remove both at once — users verify once, the VC is reused across every integrating platform, the underlying record never moves to the integrating platforms. Each presentation lets the verifier verify the cryptographic proof against the issuer's public key. Trust shifts from "the integrating platform trusts what users uploaded" to "the integrating platform trusts the issuer that signed the credential and verifies the cryptographic proof". The information the verifier learns is precisely what the credential discloses; the information the verifier never learns is everything else.

VCs also reduce onboarding errors (the same verified data, presented via a cryptographically signed credential, is harder to mis-key), reduce the cost of fraud detection at the integrating-platform side (the verifier's check is a cryptographic verification, not a record forensics exercise), and create a defensible audit trail: every presentation is cryptographically signed against the issuer's signed proof, so the regulator can trace what the integrating platform actually checked and what the holder disclosed. Trust between the issuer, the holder, and the verifier is established through cryptography rather than through repeated record custody by every integrating platform in the ecosystem.

What changes operationally is the shape of the verification process. The verification still happens; the regulator's CDD obligations still apply to the integrating platform; the audit trail is still required. What changes is where the verification happens (once at the issuer, not many times at each integrating platform) and what the integrating platform inherits afterwards (a verifiable presentation, not a copy of the record). The W3C verifiable credentials framework lets regulated firms treat the verification check as a verification problem, not a data problem — see the verification-versus-data framing for the underlying argument about why this distinction is the precondition for everything else.

What the Sumsub × Chainlink CCID launch actually attests to

The CCID launch in plain terms — what it issues, what it presents

On 5 May 2026, Sumsub and Chainlink launched Cross-Chain Identity (CCID) — a verifiable credential carrying a Sumsub-verified status across multiple EVM blockchain networks. The launch signals that a major traditional verification vendor is investing in the blockchain credential ecosystem users can trust at presentation time. The launch announcement describes the architecture verbatim: "Once a user completes Sumsub's KYC flow and proves wallet ownership by signing a message, Chainlink ACE issues a CCID — a reusable, privacy-preserving credential containing verified claims like 'Age > 18.' No raw personal data ever touches the chain" (3). Every clause carries operational meaning, and each one maps to a step in the issuance and presentation flow.

The user completes Sumsub's verification flow — where the underlying record is collected, the verification is run, and the issuer establishes the basis for the claims that will live in the credential. The user proves wallet ownership by signing a message — binding the credential subject to a wallet address, so the holder of the wallet is cryptographically the same party whose identity was verified. Chainlink ACE issues a CCID. Once the credential was created and issued, it is privacy-preserving and re-presentable, and carries assertions like 'Age > 18' presentable on multiple blockchain networks across the EVM ecosystem. No raw personal data ever touches the chain — the CCID does not carry the underlying record, the date of birth, or any personal information. The artefact users present at request time is the boolean.

In W3C terms, the CCID is a verifiable credential. The issuer is Chainlink ACE; the holder is the user's wallet; the verifier is any integrating smart contract or platform recognising the CCID. The presentation surface the verifier sees is the claim — the boolean — exactly as the W3C minimum-disclosure mechanism describes. Sumsub's launch is a public endorsement by a traditional verification vendor of the reusable, privacy-preserving credential pattern VCs are designed to support. The same blockchain credential is intended to flow across multiple integrating platforms running different services — fraud-prevention applications, age-attestation applications, identification applications, attestation-of-membership use cases — each of which is a different verifier consuming the same underlying credential. The architecture's serviceability across so many different applications is what makes the re-presentation property valuable; the use case the architecture serves determines what the credential needs to attest to.

The diagnostic question: what the W3C framework lets us frame precisely

The diagnostic question is not whether the CCID is privacy-preserving in presentation. The architecture the announcement describes is genuinely minimum-disclosure at the blockchain layer — no raw personal data published to the network, the verifier learns the boolean. The diagnostic question is what the issuer continues to retain after the credential is signed. The Sumsub verification flow producing the verified claims still ran as Sumsub's verification has always run — collection of the underlying identity record, document verification, retention under Sumsub's retention policy.

The W3C three-party separation tells us where to look: the verifier-side surface is the credential presentation; the issuer-side surface is what stays behind after the credential is signed. Two issuers can produce identical-looking verifiable presentations to the verifier — the same boolean, the same cryptographic signature, the same blockchain reference — and carry materially different residual data footprints. The verifier does not see the difference at presentation time — only that the credential's cryptographic signature has not been tampered with since issuance. The architecture's overall privacy property depends on the difference holding.

The question matters because the data the issuer retains is the data subject to whatever breach surface and retention obligation the issuer operates under. A credential that does not move on the blockchain still moved off it at issuance time; the underlying record the issuer collected is still data the issuer holds. If the issuer's data store is compromised, the underlying record is compromised — even though the issued credential never carried it. The on-chain privacy property and the off-chain residual footprint are two different things. The W3C verifiable credentials framework lets us name them separately and ask the right question of any vendor claiming a reusable, privacy-preserving credential.

Why the issuer-side data footprint determines whether the architecture delivers the privacy property

In production, the issuer-side data footprint determines whether the architecture actually delivers the privacy property. A verifiable credentials flow whose verifier-side surface is a boolean but whose issuer-side store is a centralised record warehouse delivers half the privacy promise — minimum-disclosure at presentation, full-disclosure at issuance. A flow whose issuer-side store is also minimised delivers the full promise. The W3C standard does not enforce one or the other; the issuer's architectural choice determines what happens to the underlying record.

This is the question the W3C verifiable credentials framework lets us frame precisely, and it is the question we built Verifyo to answer differently. Verifyo's attestation is, by design, a minimum-disclosure credential whose verifier-facing surface is reduced to the booleans above. The issuer-side approach we take means the underlying record does not need to live in a centralised store after the attestation is signed. The Zero-Knowledge KYC architecture is the issuer-side answer to the question the W3C three-party separation forces. See traditional KYC vs Zero-Knowledge KYC for the architectural contrast in detail; see the data-honeypot framing for the underlying argument about why issuer-side minimisation is the part of the privacy promise that holds at scale.

Sumsub offers KYB, address verification, and an enhanced-tier (EDD) product that Verifyo does not. The architectural distinction this article isolates sits at the issuer-side data footprint, not at the comparative scope of services. Both architectures issue what the W3C framework would call a verifiable credential; the operational difference is what the issuer retains after the credential is signed. The CCID launch is a public endorsement by a traditional verification vendor of the reusable, privacy-preserving credential pattern, and the diagnostic question it raises is the question every buyer evaluating a reusable-verification vendor should be asking.

The regulatory direction-of-travel: FinCEN, FATF, eIDAS 2.0, EUDI Wallet

The US direction-of-travel: FinCEN's exceptive relief and the consolidated CDD FAQs

The W3C verifiable credentials specification is regulator-aligned, not regulator-defying — and the US direction-of-travel is the proof. FinCEN's exceptive relief order FIN-2026-R001, issued 13 February 2026, narrows the BOI re-verification trigger to identification and verification "when a covered financial institution has knowledge of facts that would reasonably call into question the reliability of beneficial ownership information previously obtained; and as needed based on a covered financial institution's risk-based procedures for conducting ongoing customer due diligence" (5). The order codifies what regulated firms have argued for years — re-running the same verification at every account opening is not the regulator's intent when the underlying facts have been previously obtained. The categories of organisations the rule covers — financial institutions, banks, money services businesses, credit unions and the broader set of covered entities listed under the BSA — are the same organisations the W3C verifiable credentials data model is designed to interoperate with.

FinCEN's consolidated Customer Due Diligence FAQs, re-issued in early May 2026, align the FAQ guidance with the exceptive relief direction. "The purpose of re-issuing the FAQs is to consolidate the three sets of FAQs into one document and update certain FAQs to align with the exceptive relief order FinCEN issued on February 13, 2026" (4). The legal direction-of-travel is fewer redundant evidence re-collections, more reliance on previously-verified facts — the operational pattern the W3C three-party framework was designed to support. See the FinCEN CDD direction-of-travel for the per-vendor view of how the exceptive relief reshapes buyer-side verification choices in 2026.

The EU reference implementation: EBSI, eIDAS 2.0, EUDI Wallet ARF

The European Union does not just permit the W3C verifiable credentials data model; it has built reference implementations on it. The European Commission's EBSI Verifiable Credentials documentation states the alignment plainly: "EBSI's Verifiable Credentials profile uses this W3C standard to ensure interoperability and wide adoption" (8). EBSI is not a vendor service; it is the EU's regulator-adjacent reference implementation of a verifiable-credentials infrastructure at the framework level, specifying W3C VCs as the credential format member states use.

The statutory backing comes from eIDAS 2.0. Regulation (EU) 2024/1183, issued in the Official Journal on 30 April 2024, requires Member States to provide at least one EU Digital Identity Wallet to citizens and residents who request one, allowing them "to prove a specific personal attribute, such as age, without revealing their full identity or other personal details" (9). The regulator does not just permit selective disclosure; it mandates it as a wallet property. The EU citizen using the EUDI Wallet to prove age over 18 exercises a regulator-required property, not a vendor-offered convenience.

EUDI Wallet ARF v2.7.2 — the Architecture and Reference Framework that operationalises the regulation — lists W3C Verifiable Credentials in section 5.3.4 as one of the supported credential formats the wallet must implement, alongside ISO mDoc and SD-JWT VC (10). The EU's binding architecture document makes W3C VCs the operational baseline for the European Digital Identity Wallet across all 27 Member States. The mandatory PID (Person Identification Data) set the wallet must support includes attributes such as name, date of birth, nationality and citizenship, with address listed as part of the broader credential vocabulary. Different countries — Spain, Germany, France, Italy, Sweden, Estonia, the Netherlands and others — have different deployment timelines, but the credential format the wallets settle on is the W3C standard the working group at the World Wide Web Consortium maintains. Cross-jurisdiction interoperability is what the W3C VCDM 2.0 specification (1, https://www.w3.org/TR/vc-data-model-2.0/) is designed to enable, and it is the property non-profit organisations like W3C and the OpenID Foundation are co-ordinating institutions and businesses around.

The ESAs Joint Opinion on the use of innovative solutions in the customer due diligence process, issued 23 January 2018, frames the regulator-side caution-and-permission model wrapping the EU implementation. Regulated firms "should assess the extent to which the use of innovative technological solutions can address, or might exacerbate, the ML/TF risks, particularly in non-face to face situations" — including assessment of "ICT and security risks, qualitative risks regarding the independence and reliability of information sources, and legal risks" (13). VC-style innovations are encouraged; the integrating entity retains responsibility for evaluating whether the architecture meets its CDD requirements. The community of regulated firms, fintech corporations and infrastructure providers building toward a verifiable-credential customer-onboarding model spans many domains and sectors — banking, payments, crypto, gaming, insurance — and the regulator-side framework treats each one as responsible for evaluating fitness-for-purpose.

The US public-sector baseline: NIST SP 800-63-4 and subscriber-controlled wallets

NIST's Special Publication 800-63-4, Digital Identity Guidelines (Revision 4), finalised in July 2025, is the strongest US public-sector signal that the W3C VC pattern has crossed from standards-body recommendation into operational government baseline. The revision "enhances FALs by requiring cryptographic binding in federated transactions and formally integrating user-controlled wallets and verifiable credentials" (11). The NIST document introduces the formal concept of "subscriber-controlled wallets (e.g., verifiable credentials and mobile driver's licences) into the federation model (SP 800-63C-4)" — the same wallet-and-credential pattern the W3C VCDM defines, anchored into the US federal-government identity baseline.

NIST's terminology differs from W3C's in one place: SP 800-63C-4 uses the term "attribute bundle" for what W3C calls a verifiable credential. The underlying mechanism is the same — a cryptographically signed set of claims about a subject, held in a subscriber-controlled wallet, presented to an integrating party with selective-disclosure control. The naming distinction confirms that two of the most influential standards bodies in digital identity have converged on the same model from different starting points. The US public-sector identity infrastructure is moving toward subscriber-controlled wallets and verifiable digital credentials whether the credentials are called "verifiable credentials" (W3C) or "attribute bundles" (NIST). Cross-jurisdiction interoperability rests on the convergence holding.

The unsolved corner: FATF Singapore on UBO outcomes

Even tier-one supervisors treat one corner as still unsolved: ultimate beneficial ownership disclosure. FATF and APG's 5th-round Mutual Evaluation Report on Singapore, issued 6 May 2026, rated Singapore "compliant on 20 of 40 Recommendations and substantially effective on seven of eleven Immediate Outcomes, but only moderately effective on beneficial-ownership transparency (IO5) and money-laundering investigations (IO7), with a three-year roadmap of Key Recommended Actions on UBO verification and complex-arrangement transparency" (6). The same FATF assessment frames the country's overall posture in plain terms: "Singapore's financial crime challenges are being met by a competent and coordinated regime that is willing to try new solutions to meet illicit finance challenges of today" (6), with corroboration in the joint MoF / MAS / MHA release (7). Singapore is one of the world's most coordinated regimes; the result confirms even with maximum institutional effort, the ultimate beneficial ownership corner is unsolved.

Verifiable credentials anchored to UBO attestations are a regulator-side direction-of-travel the EUDI Wallet ARF and EBSI demonstrate at framework level. The W3C VC framework can in principle support a credential whose claims are about a legal-person entity rather than a natural person; the standard does not constrain the subject type, and EU reference implementations include legal-person credential profiles in their roadmaps. Verifyo verifies natural persons only — the regulator-side ultimate beneficial owner discussion is part of the broader landscape, not part of Verifyo's current attestation set.

OpenID4VCI's adoption signal — "Over 30 jurisdictions have selected and are deploying OpenID4VCI to support their digital identity credential issuance to digital identity wallets" (12) — closes the regulatory landscape. The protocol-layer specification for the issuance leg of the verifiable credentials framework is past the experiment stage at the jurisdictional level, and the credentials offer flow it defines is the standardised mechanism web developers and wallet providers use to interoperate across issuers and credential types. The standard the W3C VCDM 2.0 specification (1, https://www.w3.org/TR/vc-data-model-2.0/) defines, the protocol the OpenID Foundation specifies (12), the regulator-mandated wallet the eIDAS 2.0 framework requires (9), and the architecture the EUDI Wallet ARF operationalises (10) all interoperate; what changes between jurisdictions is the deployment timeline, not the underlying data model.

What this means for compliance teams now

What changes in onboarding architecture

For practitioners reading the W3C specification with onboarding architecture in mind, the operational change is concrete. How verifiable credentials reshape onboarding is straightforward: the verification happens once at the issuer; the credential lives in the holder's wallet; the integrating platforms verify the credential at presentation time without re-running the underlying check or inheriting the underlying record. The integrating platform's data store does not grow with each onboarding; the user's friction does not compound across platforms; the regulator's audit trail follows the credential rather than the document copy.

Operational control over the credential remains with the holder. The integrating platform receives the verifiable presentation the holder constructed — the attributes the holder chose to disclose, with the issuer's signed proof still attached. The integrating platform retains control over its own verification policy. The user retains control over what the credential discloses. The issuer retains responsibility for the underlying verification and the residual data footprint. Each party operates inside the role the W3C three-party framework defines.

For regulated firms retaining control over verification policy, the credential is a primitive the platform composes into its own onboarding flow. Different checks compose into the same presentation — an integrating platform can require kyc_status: verified, aml.sanctioned: false, and age_over_18: true in a single presentation, and the wallet returns a single verifiable presentation containing all three. When the same check repeats across platforms, the W3C verifiable credentials specification lets the credential be reused once rather than re-collected many times.

The questions to ask a vendor claiming reusable attestations

For regulated firms evaluating any vendor that claims to issue reusable, privacy-preserving attestations, the W3C three-party framework gives a precise set of questions to ask. First — what does the credential actually attest to, and which claims does the presentation expose? The answer should be a list of specific claim types, not a marketing summary. Second — where does the underlying record live after the attestation is signed, and what is the issuer's data-retention policy? The answer separates issuers whose architecture delivers full minimum-disclosure from issuers whose architecture delivers only verifier-side minimum-disclosure. Third — what is the cryptographic binding between the credential subject and the wallet that holds it? The answer determines whether the holder presenting the credential is the same party whose identity was verified.

Fourth — what is the credential's expiry and revocation policy? The answer determines how long the integrating platform can rely on the credential before re-checking. Fifth — what credential format does the issuer use, and is it interoperable with W3C VCDM 2.0, ISO mDoc, or SD-JWT VC? The answer determines whether the integration costs fit the integrating platform's engineering budget. Sixth — what is the screening cadence at the issuer side, and what triggers a re-screening? Verifyo's screenings (sanctions, PEP, criminal, barred, military, adverse-media) refresh on a fixed expiry cadence. The cadence the issuer operates determines how stale the claims can become before the integrating platform should require a refresh.

Common questions compliance teams ask about verifiable credentials in production

Beyond vendor evaluation, regulated firms adopting VCs in production face a set of recurring operational questions, each tied to specific implementation steps. Each one has a specific answer the W3C verifiable credentials data model makes explicit, and each one is critical to understand before the credential is deployed across an integrating ecosystem.

The first question is tamper-evidence. The W3C verifiable credentials specification guarantees a credential cannot be tampered with after issuance because the cryptographic signature is the integrity mechanism the verifier checks at presentation. Once a credential is created and signed by the issuer, if anyone modifies a single claim in the credential — that is, if any field has been tampered with after issuance — the digital signatures break, and the verifier's check fails. Tampered claims never round-trip through the cryptographic check; tampered records are detected at presentation time. The proof object inside the credential carries the issuer's signed value; the verifier checks that against the issuer's public key. Tampered credentials never pass the check. This is the integrity guarantee the W3C standard provides — secure by construction, not by external assurance.

The second question is key revocation and expired credentials. When an issuer's signing key is rotated, when a credential is revoked, or when a credential is expired, the verifier needs to know. Standardized revocation registries — published lists of revoked credential identifiers — let verifiers verify whether a credential is still valid. The credential's expiry date is part of the metadata the issuer signs; the verifier checks the expiry against the current date. The integrating platform's verifier policy decides what to do with a revoked or expired credential. The mechanisms are part of the W3C framework's full toolkit; how strictly they are applied is an integrating-platform decision.

The third question is secure storage on the holder's device. A digital wallet stores credentials securely on the user's phone or device; access to the wallet requires the user's authentication mechanisms — biometric, PIN, or device-level cryptographic keys. The wallet provider is responsible for the storage and authentication architecture; the user retains full control over what is shared. If the device is lost, the wallet provider's recovery flow determines whether the user can restore credentials onto a new device. This is the user-privacy property regulators have made essential — credentials on the user's device, not on a third-party server.

The fourth question is interoperability across applications. Standardized credential formats — W3C VCDM 2.0, ISO mDoc, SD-JWT VC — let a single credential work across many applications and jurisdictions. A credential issued in one format can be presented to a verifier expecting a different format, provided the formats share a common namespace and the receiving verifier supports the conversion. The W3C standard's value is the assurance that issuers, holders and verifiers across the ecosystem speak the same language. Interoperability is the practical benefit organisations adopting verifiable credentials gain — a single credential, many use cases, no per-platform re-issuance.

The fifth question is control and benefits. Selective disclosure gives users full control over what they share at presentation time; more control over the disclosure surface is one of the credential format's numerous advantages. The benefits a regulated firm gets from re-presentable VCs include reduced onboarding friction (users verify once, present many times), reduced data-store risk (the underlying record stays at the issuer), and a defensible audit trail (every presentation is cryptographically signed). The verifiable credential is a valuable tool for the regulated firm that wants to streamline its onboarding without compromising the assurance the regulator requires. It is helpful to remember that the value the credential carries is the credential itself, not the documentation around it — the operational value comes from reuse, not from issuance ceremony.

The verdict: a boolean, not a record

The closing verdict is one sentence. When a regulated firm asks "what does the verifier learn when this credential is presented," the answer should be a boolean, not a record. That is what the W3C verifiable credentials data model lets us express precisely. FinCEN's exceptive-relief direction codifies it for the US (5); the eIDAS 2.0 European Digital Identity Wallet mandates it for the EU (9); NIST SP 800-63-4 integrates it into the US federation model (11). And that is what Verifyo's Zero-Knowledge KYC attestation set delivers as a worked example: integrating platforms ask the question, receive the boolean, and never see the underlying record; users keep the credential in their own wallet and disclose only what each verifier needs. Learn how Verifyo's Zero-Knowledge KYC works at verifyo.com.

Sources

(1) W3C. Verifiable Credentials Data Model v2.0. 15 May 2025. https://www.w3.org/TR/vc-data-model-2.0/

(2) W3C. Verifiable Credentials Overview. 24 September 2025. https://www.w3.org/TR/vc-overview/

(3) Sumsub / Chainlink (PR Newswire). Sumsub Partners with Chainlink to Power Cross-Chain Identity for On-Chain Compliance. 5 May 2026. https://www.prnewswire.com/news-releases/sumsub-partners-with-chainlink-to-power-cross-chain-identity-for-on-chain-compliance-302762707.html

(4) FinCEN. Customer Due Diligence Requirements for Financial Institutions: Frequently Asked Questions. May 2026. https://www.fincen.gov/resources/statutes-and-regulations/cdd-rule-faqs

(5) FinCEN. Exceptive Relief Order FIN-2026-R001 (Account Opening Exceptive Relief Order). 13 February 2026. https://www.fincen.gov/system/files/2026-02/FinCEN-Order-CCDExceptiveRelief.pdf

(6) FATF / APG. Mutual Evaluation Report: Singapore (5th round). 6 May 2026. https://www.fatf-gafi.org/en/publications/Mutualevaluations/mer-singapore-2026.html

(7) Ministry of Finance Singapore (joint release with MAS and MHA). Singapore Has a Robust Framework for Combatting Financial Crime According to International Body. 6 May 2026. https://www.mof.gov.sg/news-resources/press-releases/2026/singapore-has-a-robust-framework-for-combatting-financial-crime-according-to-international-body/

(8) European Commission. EBSI Verifiable Credentials. https://ec.europa.eu/digital-building-blocks/sites/spaces/EBSI/pages/600343491/EBSI%20Verifiable%20Credentials

(9) European Union. Regulation (EU) 2024/1183 amending Regulation (EU) 910/2014 (eIDAS 2.0). 30 April 2024. https://eur-lex.europa.eu/eli/reg/2024/1183/oj/eng

(10) European Digital Identity Wallet Consortium. Architecture and Reference Framework v2.7.2. https://eudi.dev/2.7.3/architecture-and-reference-framework-main/

(11) NIST. Special Publication 800-63-4: Digital Identity Guidelines (Revision 4). July 2025. https://pages.nist.gov/800-63-4/

(12) OpenID Foundation. OpenID for Verifiable Credential Issuance (OpenID4VCI) 1.0. https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html

(13) ESAs (EBA / EIOPA / ESMA Joint Committee). Opinion on the use of innovative solutions in the customer due diligence process. 23 January 2018. https://www.eba.europa.eu/publications-and-media/press-releases/esas-publish-opinion-use-innovative-solutions-customer-due