Verifiable Data Vendor, Verifiable Data Solutions, and Verifiable Data Indicative vs Surveillance Data

Description: A buyer’s guide to modern verifiable data—what to require from vendors, which solutions actually work at scale, and how to design data flows that deliver business value while avoiding surveillance risk. Includes concrete blueprints using VC 2.0, SD‑JWT, OpenID4VC, Chainlink Data Streams, EAS, TLSNotary, TradeTrust, and ISO mDL.

Why this matters now

If your product depends on facts about people, organizations, assets, or events, you can now verify those facts cryptographically instead of collecting raw, surveillance‑style data exhaust. Between 2024 and 2025, the standards stack for verifiable data went from fragmented to production‑ready: W3C Verifiable Credentials 2.0 became a Recommendation (with revocation, JOSE/COSE, and DID/identifier updates), SD‑JWT reached RFC status, and OpenID issued wallet‑friendly protocols for issuance and presentation. Regulators also moved: NIST finalized SP 800‑63‑4 with wallet guidance, eIDAS 2.0 entered into force, and California finalized risk assessment and ADMT rules for 2026. (w3.org)

This post gives decision‑makers at startups and enterprises a precise, up‑to‑date playbook: how to choose a verifiable data vendor, which solution patterns to implement, and how to operationalize “indicative not surveillance” data.

The 2025–2026 verifiable data stack you should expect from any vendor

Require these, with dates and evidence:

W3C Verifiable Credentials 2.0 family (Recommendation since May 15, 2025), including:
- VC Data Model v2.0
- Verifiable Credential Data Integrity 1.0
- Securing VCs using JOSE and COSE (incl. SD‑JWT)
- Controlled Identifiers v1.0
- Bitstring Status List v1.0 (privacy‑preserving revocation at scale) (w3.org)
SD‑JWT is now an IETF standard (RFC 9901, Nov 2025) for selective disclosure with familiar JWT tooling. If your vendor still treats SD‑JWT as a draft, push back. (rfc-editor.org)
OpenID for Verifiable Credential Issuance (OID4VCI) 1.0 and OpenID for Verifiable Presentations (OID4VP) 1.0. These protocols let wallets and RPs use OAuth/OIDC rails for issuance and presentation; 1.0 versions landed in 2025 and are being implemented by identity platforms. (openid.github.io)
NIST SP 800‑63‑4 (final as of August 1, 2025) updated digital identity guidance, including subscriber‑controlled wallets and syncable authenticators—important for U.S. public‑sector or regulated‑adjacent deployments. (pages.nist.gov)
eIDAS 2.0 (Regulation (EU) 2024/1183), published April 30, 2024; entered into force May 20, 2024. Member States must provide EU Digital Identity Wallets on a tight timetable following implementing acts. If you serve EU users, verify your vendor’s wallet interop roadmap. (op.europa.eu)
ISO/IEC 18013‑5 mDL (2021; revision in progress). If you need government‑issued identity on mobile, ensure planned compatibility with ISO mDL and wallet presentation to relying parties. (iso.org)

What “verifiable data” means in practice

Cryptographic authenticity: A claim (e.g., “over 21,” “accredited investor,” “U.S. resident,” “asset price at T”) is signed by an issuer or produced from a verifiable mechanism (oracle, TEE attestation, ZK proof).
Selective disclosure: Only what’s necessary is revealed—age band, jurisdiction, eligibility—not full PII. SD‑JWT and VC 2.0/BBS+ enable this. (rfc-editor.org)
Status and lifecycle: Credentials can be suspended or revoked via privacy‑preserving status lists (bitstrings) without phoning home to issuers. (w3.org)
Wallet‑native flows: Issuance and presentation ride OAuth/OIDC via OID4VCI/OID4VP, fitting enterprise SSO mental models and infrastructure. (openid.github.io)

Verifiable data solutions: proven patterns and when to use them

Verifiable credentials (people/org attributes)

Use for: KYC/KYB attestations, age/risk gating, employment/education proofs, compliance attestations, sector credentials (health, finance).
Implementation specifics:
- Formats: VC 2.0 (Data Integrity or JOSE/COSE), SD‑JWT VCs.
- Transport: OID4VCI/OID4VP for wallet flows; Status via Bitstring Status List 1.0.
- Example: Polygon ID or similar ZK stacks for age‑over‑18 using range proofs; SD‑JWT for JWT‑native ecosystems. (openid.github.io)

On‑chain/off‑chain attestations (statements about anything)

Use for: reputation, allowlists, proof‑of‑attendance/contribution, policy compliance signals, machine‑readable agreements.
Example: Ethereum Attestation Service (EAS) supports on‑chain and off‑chain attestations (EIP‑712). Off‑chain signatures verify without gas; settle on‑chain only when needed. (attest.org)

Market/asset data for tokenized markets and DeFi

Use for: mark prices, OHLC, market status, staleness detection for RWA and long‑tail crypto assets.
Example: Chainlink Data Streams—sub‑second delivery, 700+ assets per DON, OHLC Candlestick API, and the State Pricing methodology optimized for DEX‑native assets; costs dropped >50% in 2025. (blog.chain.link)

Web2 data proofs (turn existing web data into verifiable claims)

TLSNotary: Prove what a website returned (e.g., a bank balance, invoice, payout) via MPC‑TLS, with selective disclosure; currently supports TLS 1.2. (tlsnotary.org)
zkEmail: Generate ZK proofs over DKIM‑signed emails—prove sender domain or specific content without revealing the rest; SDKs and on‑chain verifiers exist. (github.com)

Confidential computing attestation

Use for: proving computations ran in a Trusted Execution Environment (TEE) with a measured enclave; gate keys and API access to attested workloads.
Example: AWS Nitro Enclaves produce signed attestation documents (CBOR/COSE) verifiable by external services/KMS. (docs.aws.amazon.com)

Trade documents and content provenance

TradeTrust/OpenAttestation: Open, blockchain‑anchored verification of trade docs; supports Electronic Transferable Records (eBL) aligned with MLETR, Singapore ETA 2021 amendments, UK ETDA, and certain U.S. state laws—critical for interoperable cross‑border trade finance. (imda.gov.sg)
GovTech Singapore’s OpenAttestation powers verifiable education certs and health certs; the framework is open source and production‑used. (tech.gov.sg)
C2PA Content Credentials: Cryptographic provenance for media; adoption growing across Adobe ecosystem and select camera vendors (e.g., Nikon Z6 III service, 2025). Treat as complementary provenance to VCs/attestations. (nikonusa.com)

Indicative vs surveillance data (and why it changes your risk profile)

Indicative data: Minimal, purpose‑bound signals that indicate eligibility or compliance without raw PII or continuous tracking. Examples:
- “Age ≥ 21,” “Residency: CA,” “Accredited investor: true,” “Salary band: 150–200k,” “Market data timestamp within 500 ms,” “Shipment title transferred.”
- Delivered as SD‑JWT claims, VC proofs (possibly ZK), EAS attestations, or Chainlink stream metadata.
Surveillance data: Raw, continuous logs (exact DOB, GPS traces, full bank statements, browsing histories). High breach/compliance risk; often unnecessary for the purpose.

Regulatory drivers are explicit: GDPR’s data minimization principle (Art. 5(1)(c)) requires collecting only what’s necessary, and CPPA’s 2025 rulemaking culminated in final regulations effective January 1, 2026 for risk assessments/cybersecurity audits, plus ADMT requirements from Jan 1, 2027—practically nudging businesses toward purpose‑bounded, high‑assurance signals. (gdpr.org)

Best practice: start with an indicative signal map. For each use case, define the minimum proof needed (e.g., “over 18 in California within last 30 days”) and choose a verifiable mechanism (SD‑JWT claim set, VC with BBS+ selective disclosure, or a ZK range proof). Only collect surveillance data if absolutely needed and justified.

Four implementation blueprints you can ship in Q1–Q2

Age‑gated onboarding with SD‑JWT and OpenID4VC

Goal: Let U.S. users prove “over 21” without DOB storage; align with NIST SP 800‑63‑4 and future EUDI wallet interop.
Flow:
1. Issue SD‑JWT VC “age_over_21” via OID4VCI 1.0; bind to holder key.
2. Present via OID4VP 1.0 to your RP; verify SD‑JWT per RFC 9901.
3. Check status via Bitstring Status List; store only a non‑correlatable receipt + issuer DID.
4. Set risk controls: require re‑presentation if status changes or after 90 days.
Notes: SD‑JWT is standardized (RFC 9901, Nov 2025); OID4VCI/VP 1.0 finalized in 2025. (rfc-editor.org)

Tokenized assets with verifiable market data

Goal: Price‑safe perps/RWA with sub‑second updates and staleness guards.
Architecture: Use Chainlink Data Streams for pull‑based, low‑latency market data; add guards for market status, price type, and out‑of‑hours detection; optionally adopt State Pricing for DEX‑heavy assets and OHLC Candlestick API for analytics. A single low‑latency DON can support 700 assets in parallel; operating costs fell >50% in 2025 with the Multistream upgrade. (blog.chain.link)
Smart contract controls:
- Reject updates if “staleness > X ms,” “market_status != OPEN,” or “stream schema version < required.”
- Separate mark price and execution price; record stream ID and report UID for audit.

Paperless trade with legal certainty

Goal: Move Bills of Lading and other transferable records to digital with cross‑border enforceability.
Approach:
- Build on TradeTrust/OpenAttestation to issue/verify Electronic Transferable Records aligned with MLETR and Singapore ETA amendments; align with UK ETDA and applicable U.S. state frameworks where relevant. Use QR‑linked verifiable documents to interoperate with mixed digital/paper parties during transition. (imda.gov.sg)
- KPIs: End‑to‑end cycle time, error rate in title transfer, finance approval cycle reduction.

Web2 proofs without data dumps

Goal: Verify a bank payout, payroll, or invoice without uploading PDFs.
Options:
- TLSNotary: Prove response content from a bank or payroll portal; selectively disclose numeric amounts and dates. Today TLS 1.2 is supported; verify roadmap for TLS 1.3. (tlsnotary.org)
- zkEmail: Prove a DKIM‑signed email from “payroll@company.com” states “Net Pay: $X” without revealing full email; verify on‑chain where needed via provided verifiers/SDKs. (github.com)
Bonus: Wrap result as an EAS off‑chain attestation; settle on‑chain only if a dispute triggers arbitration logic. (github.com)

How to evaluate a “verifiable data vendor” in 2026

Ask for concrete, testable answers:

Standards conformance
- VC 2.0 test vectors? Bitstring Status List 1.0 support? SD‑JWT RFC 9901? OID4VCI/OID4VP 1.0 conformance results and interop events participated in? (w3.org)
Wallets and IDs
- NIST SP 800‑63‑4 alignment for U.S.; eIDAS 2.0/EUDI wallet interop plans for EU; ISO mDL for state‑issued IDs in Wallets. (pages.nist.gov)
Revocation and status
- How is revocation checked offline? What’s the worst‑case latency to propagate a status change?
Data minimization and compliance
- Can the solution meet GDPR Art. 5(1)(c) with architecture, not policy alone? Does it support purpose binding and selective disclosure by default? For California, how will your risk assessments and ADMT obligations (effective 2026/2027) be evidenced? (gdpr.org)
Chain and oracle choices (if using on‑chain)
- For market data: Streams latency SLA, supported assets per DON, staleness guards, OHLC availability; operational runbooks. (blog.chain.link)
- For attestations: Off‑chain vs on‑chain pathways, signature suite details (EIP‑712), settlement strategy, and gas mitigation plans. (github.com)
Verifiable compute and Web2 bridges
- TEE attestation support (Nitro/SGX) and verification libraries; TLSNotary or zkEmail integrations for real‑world proofs. (docs.aws.amazon.com)
Operational evidence
- Pen tests/security audits on cryptosuites; incident runbooks; SLA/OLA for issuer downtime and status list publication.

KPIs to run a 90‑day pilot

Privacy and compliance
- Percentage of decisions made from indicative signals (no raw PII persisted).
- Evidence of minimization: fields eliminated vs baseline; revocation tested. (gdpr.org)
Performance
- Presentation success rate; median end‑to‑end presentation latency; cache hit ratio for status lists; Streams staleness budget adherence. (blog.chain.link)
Cost
- Cost per verified decision (including wallet UX, verification, status checks); on‑chain settlement ratio for attestations (target <5%).
Interoperability
- OID4VCI/OID4VP interop across two independent wallets; SD‑JWT verification across two libraries; mDL reader flow with ISO‑conformant test vectors. (openid.github.io)

Pitfalls to avoid

Treating verifiable data like static PDFs. Use status lists and short‑lived presentations; never store raw claims if a boolean will do.
Building your own crypto unless you must. Stick to VC 2.0, SD‑JWT, OID4VC, and established attestation/oracle networks; you gain interoperability and auditability. (w3.org)
Ignoring legal enforceability in trade/finance flows. For title transfer or negotiable instruments, lean on frameworks like TradeTrust that align with MLETR/ETA/ETDA and provide model terms. (imda.gov.sg)
Hoarding surveillance data “just in case.” GDPR/UK GDPR minimization and California’s finalized rules make this an expensive liability; use selective disclosure and indicative signals instead. (ico.org.uk)

Where this is going in 2026

EU Digital Identity Wallets will harden the wallet‑first model; U.S. agencies are aligning via SP 800‑63‑4. Expect high‑assurance interop profiles (e.g., OpenID4VC HAIP) to define what “production‑grade” means across issuers, wallets, and verifiers. (openid.github.io)
In financial markets, low‑latency data streams and verifiable analytics (e.g., ZK‑verified SQL) will become table stakes for RWA and complex DeFi, reducing oracle risk and improving transparency. (spaceandtimefdn.github.io)
Web2 bridges will mature: TLSNotary expands TLS coverage; zkEmail pushes domain proofs and JWT/ZK hybrids to mainstream app login and compliance workflows. (tlsnotary.org)

How 7Block Labs can help

Vendor selection and RFPs with hands‑on conformance testing against VC 2.0/SD‑JWT/OID4VCI/VP.
Reference implementations:
- SD‑JWT + OID4VP age/risk gating
- EAS‑based reputation/compliance attestations
- Chainlink Data Streams price‑safe perps/RWA
- TradeTrust/OpenAttestation eBL pilot
- TLSNotary/zkEmail bridges for bank/payroll proofs
Privacy threat modeling to shift from surveillance data to indicative signals, mapping directly to GDPR/CPPA obligations with audit artifacts. (gdpr.org)

If you want a 6–8 week pilot plan with measurable KPIs and a build‑buy‑partner decision at the end, we can scope it in a single working session.

Appendix: quick‑reference links

W3C VC 2.0 family (Rec, May 15, 2025) and components (Data Integrity, JOSE/COSE, Controlled Identifiers, Bitstring Status List). (w3.org)
SD‑JWT RFC 9901 (Nov 2025). (rfc-editor.org)
OpenID4VCI 1.0 and OID4VP 1.0 (2025). (openid.github.io)
NIST SP 800‑63‑4 (final, Aug 1, 2025). (pages.nist.gov)
eIDAS 2.0 (Reg. 2024/1183): OJ publication Apr 30, 2024; in force May 20, 2024. (op.europa.eu)
ISO/IEC 18013‑5 mDL (2021; revision underway). (iso.org)
Chainlink Data Streams performance and features (Q2/Q1 2025). (blog.chain.link)
EAS (on/off‑chain attestations). (attest.org)
TLSNotary docs (TLS 1.2 support). (tlsnotary.org)
TradeTrust/OpenAttestation (MLETR/ETA/ETDA alignment). (imda.gov.sg)
GDPR/UK GDPR data minimization guidance. (ico.org.uk)
CPPA final regulations (effective 2026; ADMT 2027). (cppa.ca.gov)