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

Buyer’s Guide to Modern Verifiable Data

Looking to navigate the world of modern verifiable data? You’ve come to the right place! This guide will walk you through what to ask vendors, which solutions really deliver at scale, and how to set up data flows that not only add value to your business but also steer clear of surveillance risks. We’ve got some solid blueprints for you using the latest tech like VC 2.0, SD-JWT, OpenID4VC, Chainlink Data Streams, EAS, TLSNotary, TradeTrust, and ISO mDL.

What to Require from Vendors

When you’re evaluating vendors, keep these key points in mind:

Transparency: Ensure they’re open about their data handling practices.
Compliance: Check if they align with relevant regulations and standards.
Scalability: Make sure their solutions can grow with your needs.
Integration: Look for vendors that make it easy to integrate their systems with your existing infrastructure.

Solutions that Work at Scale

Not all solutions are created equal. Here’s a rundown of some that really shine when it comes to scalability:

VC 2.0: This version brings improved interoperability and usability.
SD-JWT: A simple and efficient way to carry security claims.
OpenID4VC: Great for decentralized identity solutions.
Chainlink Data Streams: Perfect for linking on-chain and off-chain data.
EAS: Ensures easy access and sharing of credentials.
TLSNotary: Adds a layer of trust to online interactions.
TradeTrust: Focused on digital trade documentation.
ISO mDL: A standardized mobile driver’s license solution.

Designing Data Flows

Creating data flows that deliver real business value while minimizing surveillance risk is all about balance. Here’s a quick guide to help you out:

Identify Your Goals: Know what you want to achieve with the data.
Map Your Data Sources: Understand where your data is coming from.
Choose the Right Tools: Select the appropriate tech stack that aligns with your goals.
Implement Strong Security Measures: Protect your data from unauthorized access.
Monitor and Optimize: Regularly check your data flows and tweak them as needed.

By following these guidelines, you’ll be well on your way to leveraging modern verifiable data in a way that’s effective and responsible!

Why this matters now

If your product relies on facts about people, organizations, assets, or events, you can now verify those details in a cryptographic way rather than relying on raw data collected through surveillance. Between 2024 and 2025, the standards for verifiable data really came together and moved from being all over the place to being ready for real-world use. For instance, W3C Verifiable Credentials 2.0 became an official Recommendation, adding features like revocation, JOSE/COSE updates, and improvements to DIDs and identifiers. Plus, SD‑JWT hit the RFC status, and OpenID rolled out some wallet-friendly protocols for issuing and presenting data. Regulators got in on the action too; NIST wrapped up SP 800‑63‑4 with some wallet guidance, eIDAS 2.0 came into play, and California nailed down its risk assessment and ADMT rules set for 2026. Check out more about it here: (w3.org).

This post is all about giving startup and enterprise decision-makers a clear, current guide on selecting a verifiable data vendor. It covers which solution patterns to adopt and offers insights on how to turn “indicative, not surveillance” data into real operational practices.

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

Sure thing! Here’s what you need:

Requirements:

Dates: Please specify the dates associated with the information you’re looking for.
Evidence: Make sure to provide any supporting documentation or evidence for your claims.

Let me know if there’s anything specific you want to dive into!

The W3C Verifiable Credentials 2.0 family is officially a Recommendation as of May 15, 2025, and it includes:
- VC Data Model v2.0
- Verifiable Credential Data Integrity 1.0
- Securing VCs using JOSE and COSE (including SD-JWT)
- Controlled Identifiers v1.0
- Bitstring Status List v1.0 (which offers privacy-preserving revocation at scale) (w3.org)
SD‑JWT has officially become an IETF standard (RFC 9901, Nov 2025) for selective disclosure, and it works seamlessly with the JWT tools you already know. If your vendor is still treating SD‑JWT like it’s just a draft, it’s time to push back. (rfc-editor.org)
OpenID for Verifiable Credential Issuance (OID4VCI) 1.0 and OpenID for Verifiable Presentations (OID4VP) 1.0 are pretty cool protocols. They allow wallets and Relying Parties (RPs) to utilize OAuth/OIDC frameworks for both issuing and presenting credentials. The 1.0 versions made their debut in 2025 and are currently being rolled out by various identity platforms. You can check out more details here.
NIST SP 800‑63‑4 (finalized as of August 1, 2025) brings fresh digital identity guidance that covers subscriber-controlled wallets and syncable authenticators. This is super relevant for anyone in the U.S. public sector or those in regulated industries. Check it out here: (pages.nist.gov)
eIDAS 2.0 (Regulation (EU) 2024/1183), which hit the scene on April 30, 2024, is now officially in action as of May 20, 2024. Member States are on a tight schedule to roll out EU Digital Identity Wallets following some specific implementing acts. If you're working with EU users, make sure to check out your vendor’s roadmap for wallet interoperability. You can find more details here: (op.europa.eu).
ISO/IEC 18013‑5 mDL (2021; revision in the works). If you're looking to have government-issued ID on your mobile device, make sure it’s set up to work with ISO mDL and can be presented to those who need it. (iso.org)

What “verifiable data” means in practice

Cryptographic authenticity: When you make a claim like “over 21,” “accredited investor,” or “U.S. resident,” it’s backed by an issuer’s signature or comes from a verifiable method, like an oracle, TEE attestation, or ZK proof.
Selective disclosure: You only share what’s needed--like your age range, where you live, and whether you’re eligible--without disclosing your full personal info. This is made possible by SD‑JWT and VC 2.0/BBS+. Check it out here.
Status and lifecycle: Credentials can be temporarily suspended or completely revoked through privacy-preserving status lists (think bitstrings), so there’s no need to contact issuers directly. More details can be found here.
Wallet-native flows: The whole process of issuing and presenting credentials works smoothly with OAuth/OIDC, thanks to OID4VCI/OID4VP. This setup aligns well with enterprise SSO approaches and infrastructure. You can learn more here.

Verifiable data solutions: proven patterns and when to use them

1) Verifiable Credentials (People/Org Attributes)

Use for: KYC/KYB attestations, age or risk gating, proofs of employment or education, compliance attestations, and sector-specific credentials like health and finance.
Implementation specifics:
- Formats: VC 2.0 (Data Integrity or JOSE/COSE), SD‑JWT VCs.
- Transport: OID4VCI/OID4VP for wallet flows; check the status with Bitstring Status List 1.0.
- Example: Think of Polygon ID or similar ZK stacks that use range proofs for verifying if someone is over 18; also, you can use SD‑JWT for JWT-native ecosystems. (openid.github.io)

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

Use for: things like reputation, allowlists, proof of attendance or contribution, policy compliance signals, and machine-readable agreements.
Example: The Ethereum Attestation Service (EAS) is a great option that supports both on-chain and off-chain attestations (thanks to EIP-712). With off-chain signatures, you can verify without using gas, and you only need to settle on-chain when it’s really necessary. Check it out here: (attest.org).

3) Market/Asset Data for Tokenized Markets and DeFi

Use for: mark prices, OHLC, keeping an eye on market status, and detecting staleness in RWA and those long-tail crypto assets.
Example: Check out Chainlink Data Streams--they offer sub-second delivery, support over 700 assets per DON, provide an OHLC Candlestick API, and have a State Pricing methodology that's tailored for DEX-native assets. Plus, costs have dropped by more than 50% in 2025! (You can read more about it here).

4) Web2 Data Proofs (Turning existing web data into verifiable claims)

TLSNotary: This nifty tool helps you prove what a website gave you, whether it’s your bank balance, an invoice, or a payout. It uses MPC-TLS with selective disclosure and currently works with TLS 1.2. Check it out here.
zkEmail: With zkEmail, you can create ZK proofs for DKIM-signed emails. This lets you prove details like the sender's domain or specific content without showing everything else. They’ve even got SDKs and on-chain verifiers ready for you. Dive into it on GitHub.

5) Confidential Computing Attestation

Use for: Showing that computations were performed in a Trusted Execution Environment (TEE) with a measured enclave; this helps manage keys and API access for verified workloads.
Example: AWS Nitro Enclaves create signed attestation documents (CBOR/COSE) that can be verified by external services or KMS. Check it out here: AWS Documentation.

Trade Documents and Content Provenance

TradeTrust/OpenAttestation: This cool system offers open, blockchain-based verification for trade documents. It backs up Electronic Transferable Records (eBL) that sync up with MLETR, Singapore’s ETA 2021 updates, the UK ETDA, and various state laws in the U.S. That makes it super important for smooth cross-border trade finance. You can learn more about it here.
GovTech Singapore’s OpenAttestation: This nifty framework supports verifiable education and health certificates. It's open source and has already been put to use in real-world applications. Check it out here.
C2PA Content Credentials: This provides cryptographic proof of media origins and is gaining traction, especially within the Adobe ecosystem and with specific camera brands (like the Nikon Z6 III service coming in 2025). Think of it as a helpful addition to verifiable credentials and attestations. More details are available here.

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

Indicative data: These are simple, purpose-driven signals that show if someone is eligible or in compliance, all without using any raw personal info or constant tracking. Here are some examples:
- “Age ≥ 21,” “Residency: CA,” “Accredited investor: true,” “Salary band: 150-200k,” “Market data timestamp within 500 ms,” “Shipment title transferred.”
- You can find these delivered as SD‑JWT claims, VC proofs (maybe even ZK), EAS attestations, or Chainlink stream metadata.
Surveillance data: This is the heavy stuff--raw, continuous logs that include exact dates of birth, GPS traces, full bank statements, and browsing histories. It's a high-risk area for breaches or compliance issues and usually isn’t necessary for what we need.

Regulatory drivers are pretty clear-cut: the GDPR's data minimization principle (Art. 5(1)(c)) says you should only gather what's absolutely necessary. On top of that, the CPPA's 2025 rulemaking wrapped up with final regulations that kick in on January 1, 2026, focusing on risk assessments and cybersecurity audits. Then, from January 1, 2027, businesses will also have to meet ADMT requirements. All of this is really pushing companies toward collecting data that’s purpose-driven and secure. (gdpr.org)

Best Practice: Start with an Indicative Signal Map

Kick things off by creating a clear signal map. For every use case, nail down the minimum proof you need (like, “over 18 in California within the last 30 days”) and pick a solid verifiable mechanism--this could be an SD-JWT claim set, VC with BBS+ selective disclosure, or even a ZK range proof. Remember, only gather surveillance data if it’s absolutely essential and you’ve got a good reason for it.

Four implementation blueprints you can ship in Q1-Q2

1) Age‑gated onboarding with SD‑JWT and OpenID4VC

Goal: We want to help U.S. users easily prove they're "over 21" without needing to store their date of birth. This also keeps us in line with NIST SP 800‑63‑4 and sets us up for future EUDI wallet compatibility.
Flow:
1. Start by issuing an SD‑JWT VC called “age_over_21” through OID4VCI 1.0, binding it to the holder's key.
2. Present it using OID4VP 1.0 to your RP and make sure to verify the SD‑JWT according to RFC 9901.
3. Check the status with the Bitstring Status List; only keep a non‑correlatable receipt along with the issuer's DID.
4. Implement some risk controls: ask for re‑presentation if the status changes or after 90 days.
Notes: SD‑JWT is standardized (check out RFC 9901, Nov 2025); OID4VCI/VP 1.0 will be finalized in 2025. (rfc-editor.org)

2) Tokenized Assets with Verifiable Market Data

Goal: We’re aiming to create price-safe perpetual contracts and real-world assets that get updates in under a second, plus some smart safeguards against stale data.
Architecture: We’ll be tapping into Chainlink Data Streams for quick, pull-based market data that doesn’t keep you waiting. We’ll set up guards to check for market status, price types, and figure out if the market’s closed. For those decentralized exchange (DEX) heavy assets, we might want to use State Pricing and the OHLC Candlestick API for some solid analytics. One low-latency Decentralized Oracle Network (DON) can handle up to 700 assets at the same time, and with the Multistream upgrade, our operating costs dropped by more than 50% in 2025. Check out more about it here.
Smart Contract Controls:
- We’ll make sure to reject any updates if “staleness > X ms,” “market_status != OPEN,” or “stream schema version < required.”
- We’ll keep the mark price separate from the execution price, and we’ll log the stream ID and report UID for good measure when it comes to audits.

3) Paperless Trade with Legal Certainty

Goal: Let's get those Bills of Lading and other transferable records into the digital world while ensuring they can be enforced across borders.
Approach:
- We’re building on TradeTrust/OpenAttestation to create and verify Electronic Transferable Records that line up with MLETR and the recent amendments to Singapore's ETA. We’ll also make sure it works with the UK ETDA and any relevant U.S. state rules. Plus, we plan to use QR-linked verifiable documents to help bridge the gap for parties still using a mix of digital and paper during this transition. Check it out for more info: imda.gov.sg.
- KPIs: We're looking at things like the end-to-end cycle time, the error rate in title transfer, and cutting down the finance approval cycle.

4) Web2 Proofs Without Data Dumps

Goal: Verify a bank payout, payroll, or invoice without having to upload PDFs.
Options:
- TLSNotary: This tool lets you prove the response content from a bank or payroll portal, allowing you to selectively share numeric amounts and dates. Currently, it supports TLS 1.2, and you can check out the plans for TLS 1.3 in their roadmap. Check it out here.
- zkEmail: With zkEmail, you can prove that a DKIM-signed email from “payroll@company.com” states “Net Pay: $X” without sharing the entire email. It also offers on-chain verification where necessary, using provided verifiers and SDKs. Find out more on GitHub.
Bonus: You can package the result as an EAS off-chain attestation. This way, you only settle on-chain if a dispute pops up that triggers the arbitration logic. More details can be found here.

How to evaluate a “verifiable data vendor” in 2026

Ask for Concrete, Testable Answers

When you're diving into discussions or seeking solutions, it's super important to keep things clear and specific. Here are a few pointers to help you get those solid, testable answers you’re after:

Be Direct: Instead of vague questions, ask something specific. For example, instead of “What do you think about this?” try “Can you explain how this impacts our project timeline?”
Use Examples: If you’re talking about a concept, throw in some examples. This makes it easier for others to understand and gives them a clear reference point.
Clarify the Criteria: Let them know what you consider a “testable” answer. Is it a date, a measurable outcome, or a step-by-step plan? Being clear helps everyone stay on the same page.
Encourage Evidence: Ask for data or sources that back up their points. Something like, “Could you share any data that supports this?” works wonders.
Don’t Hesitate to Probe: If an answer seems a bit fuzzy, don’t be afraid to dig a little deeper. Questions like, “Can you break that down for me?” or “What makes you say that?” can lead to better insights.

By asking for specific, testable answers, you're not just seeking clarity--you’re fostering a more productive and engaged conversation. Good luck!

Standards conformance
- What’s the deal with VC 2.0 test vectors? Are we all set for Bitstring Status List 1.0 support? And how about the SD-JWT RFC 9901? Let’s also check the OID4VCI/OID4VP 1.0 conformance results and any interop events we’ve been a part of. (w3.org)
Wallets and IDs
- Are we aligning with NIST SP 800‑63‑4 for the U.S.? What’s going on with eIDAS 2.0/EUDI wallet interoperability plans in the EU? Plus, what’s the scoop on supporting ISO mDL for state-issued IDs in Wallets? (pages.nist.gov)
Revocation and status
- How are we checking revocation offline? And seriously, what’s the worst-case latency for getting a status change out there?
Data minimization and compliance
- Can our solution really hit the mark for GDPR Art. 5(1)(c) just based on architecture, rather than just policy? Does it allow for purpose binding and selective disclosure as a default setting? For our friends in California, how are we going to prove our risk assessments and ADMT obligations (kicking in 2026/2027)? (gdpr.org)
Chain and oracle choices (if using on-chain)
- When it comes to market data: What’s our Streams latency SLA like? What assets are supported per DON, what about staleness guards, and are OHLCs available? Don’t forget the operational runbooks! (blog.chain.link)
- For attestations: Are we going off-chain or on-chain? Let’s get into the details of the signature suite (EIP-712), our settlement strategy, and how we plan to mitigate gas costs. (github.com)
Verifiable compute and Web2 bridges
- What about TEE attestation support (Nitro/SGX) and the verification libraries? Are we integrating TLSNotary or zkEmail for some real-world proofs? (docs.aws.amazon.com)
Operational evidence
- Have we had any pen tests or security audits on our cryptosuites? Let’s talk incident runbooks, and what’s our SLA/OLA for issuer downtime and status list publication looking like?

KPIs to run a 90‑day pilot

Privacy and Compliance
- Percentage of decisions based on indicative signals (no raw PII kept around).
- Proof of minimization: fields removed compared to baseline; revocation testing is in place. (gdpr.org)
Performance
- Success rate of presentations; median time taken from start to finish for presentations; how often we hit the cache for status lists; adherence to our Streams staleness budget. (blog.chain.link)
Cost
- Cost for each verified decision (this covers wallet user experience, verification, and status checks); aiming for an on-chain settlement ratio for attestations below 5%.
Interoperability
- OID4VCI/OID4VP working smoothly across two different wallets; verifying SD-JWT with two separate libraries; mDL reader flow using ISO-compliant test vectors. (openid.github.io)

Pitfalls to avoid

Treat verifiable data like you would with static PDFs. Stick to status lists and short-lived presentations; there’s no need to keep raw claims if a simple boolean can do the trick.
Build your own crypto only if it’s absolutely necessary. It’s better to go with VC 2.0, SD-JWT, OID4VC, and other established attestation/oracle networks. This way, you’ll have better interoperability and auditability. (w3.org)
Don’t overlook legal enforceability in trade and finance flows. When it comes to title transfers or negotiable instruments, make sure you’re using frameworks like TradeTrust that align with MLETR/ETA/ETDA and offer model terms. (imda.gov.sg)
Avoid hoarding surveillance data “just in case.” With GDPR/UK GDPR minimization and California’s finalized rules, holding on to extra data can turn into a costly liability. Instead, go for selective disclosure and indicative signals. (ico.org.uk)

Where this is going in 2026

The EU Digital Identity Wallets are set to strengthen this wallet-first approach, and U.S. agencies are getting on the same page with SP 800‑63‑4. We can expect those high-assurance interoperability profiles (like OpenID4VC HAIP) to really clarify what “production-grade” actually means for issuers, wallets, and verifiers. Check it out here.
In the financial markets, having low-latency data streams and verifiable analytics (think ZK-verified SQL) is going to be essential for Real World Assets (RWA) and more complex DeFi setups. This will help minimize oracle risk and boost transparency. Dive into the details here.
We’ll see Web2 bridges coming into their own: TLSNotary is broadening its TLS coverage, while zkEmail is pushing domain proofs and JWT/ZK hybrids into the spotlight for app logins and compliance tasks. Check it out here.

How 7Block Labs can help

When it comes to vendor selection and RFPs, we've got hands-on conformance testing lined up that looks at VC 2.0, SD-JWT, OID4VCI, and VP.
Here are some reference implementations we’re working with:
- SD-JWT paired with OID4VP for age/risk gating
- EAS-based rep and compliance attestations
- Chainlink Data Streams for price-safe perps and RWA
- TradeTrust/OpenAttestation’s eBL pilot
- TLSNotary and zkEmail bridges for bank/payroll proofs
We're also diving into privacy threat modeling. The goal is to shift from relying on surveillance data to using indicative signals that align directly with GDPR and CPPA obligations, all backed by audit artifacts. For more on GDPR, check out this link: (gdpr.org).

If you're looking to create a 6-8 week pilot plan that includes measurable KPIs and a decision on whether to build, buy, or partner at the end, we can outline everything in just one working session.

Appendix: quick‑reference links

The W3C VC 2.0 family (Rec, May 15, 2025) and its components (including Data Integrity, JOSE/COSE, Controlled Identifiers, and Bitstring Status List) are now official! Check it out here.
SD‑JWT RFC 9901 is set to drop in November 2025. Get the details here.
Keep an eye out for OpenID4VCI 1.0 and OID4VP 1.0, both coming your way in 2025. More info is available here.
NIST SP 800‑63‑4 is final and will be released on August 1, 2025. You can find the specifics here.
eIDAS 2.0 (Reg. 2024/1183) is on the horizon: it’ll be published in the OJ on April 30, 2024, and goes into force on May 20, 2024. Check out more here.
The ISO/IEC 18013‑5 mDL is from 2021 and has a revision in the works. Details can be found here.
Take a look at the performance and features of Chainlink Data Streams, expected in Q1/Q2 of 2025. More information is available here.
EAS is covering both on and off‑chain attestations. You can learn more about it here.
The TLSNotary docs now support TLS 1.2. Check them out here.
TradeTrust/OpenAttestation is aligning with MLETR/ETA/ETDA standards. Learn more here.
If you're looking into GDPR/UK GDPR, there's guidance on data minimization that you might find handy. More info is available here.
The final regulations for the CPPA will take effect in 2026, with ADMT rolling out in 2027. You can read all about it here.