verifiable data package Design: Schema, Signatures, Attestation, and Replay Protection

A verifiable data package (VDP) is basically a compact set of structured data that’s packed with cryptographic proof. This proof shows who made the data, what’s inside it, and when it was created. In this guide, we’re breaking down the most up-to-date standards and best practices so your team can create VDPs that work seamlessly across wallets, clouds, devices, and ledgers. Plus, they’ll be tough enough to hold up against audits and attacks.

What changed in 2024-2025 (why this matters now)

On May 15, 2025, W3C wrapped up the Verifiable Credentials (VC) 2.0 family, which includes the Data Integrity 1.0 and a cool feature called “Securing VCs with JOSE/COSE.” This means that JSON/JWT, SD‑JWT, and CBOR/COSE are now top-notch options for securing credentials. Check it out here.
Big news: Selective Disclosure for JWTs is officially an IETF standard now (RFC 9901, November 2025)! This allows holders to share only specific pieces of their signed data. You can read more about it here.
Device and runtime attestation have stepped up their game with the Entity Attestation Token (EAT) now being RFC 9711 as of April 2025. This aligns JWT/CWT claims with the IETF RATS architecture (RFC 9334). Details can be found here.
Sigstore's Rekor transparency log just got better with the launch of v2 GA on October 10, 2025! It’s more cost-effective now and supports client conformance. You can also verify inclusion and keep an eye on logs on a larger scale. For more info, check out the update here.

Here’s a reference design you can start using right now.

A reference architecture for verifiable data packages

A solid production-grade VDP typically comes with:

Envelope and media type

Use JSON + JWS/JWT when you need something human-readable and want to take advantage of web tools. On the flip side, go for CBOR + COSE if you’re dealing with limited bandwidth or constrained devices. The W3C VC-JOSE-COSE has defined media types such as application/vc+jwt and application/vc+cose specifically for credentials and presentations. (w3.org)

2) Schema

When it comes to handling JSON payloads, stick with JSON Schema 2020‑12; for CBOR payloads, go with CDDL. Both options are solid and have plenty of tools available. Check it out over at (json-schema.org).

3) Signatures and Keys

JOSE (JWS/JWT) and COSE (COSE_Sign1, COSE_Sign) are the go-to IETF standards. Make sure to use key IDs (kid), stay flexible with your algorithms, and follow the validation rules laid out in these specs. For more details, check out the IETF documentation.

4) Attestation (optional but recommended)

When it comes to software provenance, it’s a good idea to use DSSE envelopes and SLSA attestations. You might also want to get these notarized in a transparency log like Rekor. For devices, sticking to EAT/CWT or JWT in line with RATS roles is the way to go.

5) Replay Protection and Freshness

Make sure to bind to domains and sessions for the web, chain IDs for blockchain, and HTTP methods/URLs for API calls. It’s also a good idea to use nonces, along with timestamps like issued-at, expiry, and key-binding proofs (like DPoP and SD-JWT KB). You can check out more about this on eips.ethereum.org.

Distribution

Package and get things out there as OCI artifacts using content addressing (digests/CIDs). This way, auditors can easily reproduce those byte-for-byte inputs. Check out the details here: (oci-playground.github.io)

1) Schema: make it precise and future‑proof

JSON payloads: Create a JSON Schema (draft 2020‑12) that sticks to closed-world schemas by using “additionalProperties”: false. Oh, and make sure to include explicit formats too; it’s a good idea to pin down those $schema and $id URIs. Check it out here.
CBOR payloads: You’ll want to roll out a CDDL that lays out the field names, integer label maps, and claim types. Just a heads up: CDDL is the IETF's official way to represent both CBOR and JSON. You can find more info here.

Example: Shipping Notice Schema (JSON, Excerpt)

Here’s a quick look at what the Shipping Notice schema might look like in JSON format:

{
  "@context": "http://schema.org",
  "@type": "ShippingNotice",
  "identifier": "12345",
  "itemShipped": {
    "@type": "Product",
    "name": "Wireless Headphones",
    "sku": "WH123"
  },
  "shippingMethod": {
    "@type": "ShippingMethod",
    "name": "Express Shipping"
  },
  "carrier": {
    "@type": "Organization",
    "name": "Fast Shipping Co."
  },
  "deliveryDate": "2023-10-15",
  "trackingURL": "http://tracking.example.com/12345"
}

This is just a snippet, but it gives you a solid idea of how you can structure your shipping notice using JSON. Happy coding!

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://schemas.7blocklabs.com/vdp/shipping-notice-1.0.json",
  "type": "object",
  "additionalProperties": false,
  "required": ["noticeId", "shipper", "items", "issuedAt"],
  "properties": {
    "noticeId": {"type": "string", "pattern": "^[A-Z0-9-]{10,}$"},
    "shipper": {
      "type": "object",
      "required": ["did"],
      "properties": {"did": {"type": "string"}}
    },
    "items": {
      "type": "array",
      "items": {"$ref": "#/$defs/lineItem"},
      "minItems": 1
    },
    "issuedAt": {"type": "string", "format": "date-time"}
  },
  "$defs": {
    "lineItem": {
      "type": "object",
      "required": ["sku", "qty"],
      "properties": {
        "sku": {"type": "string"},
        "qty": {"type": "integer", "minimum": 1}
      },
      "additionalProperties": false
    }
  }
}

Example: Using Numeric Labels for Compactness in CDDL (CBOR)

Here's a streamlined version of the same structure in CDDL (Concise Data Definition Language) with numeric labels to keep things compact and efficient.

# MyDataStructure
MyDataStructure = (
    # Numeric labels for fields
    0 : integer,                # Field 0: Integer value
    1 : text,                   # Field 1: Text value
    2 : array,                  # Field 2: Array of items
    3 : map                     # Field 3: Key-value pairs
)

By going for numeric labels, we can cut down on space while keeping everything clear and manageable!

shipping-notice = {
  1: tstr,               ; noticeId
  2: { 1: tstr },        ; shipper.did
  3: [+ line-item],      ; items
  4: tstr                ; issuedAt (RFC3339)
}

line-item = {
  1: tstr,               ; sku
  2: uint                ; qty
}

CDDL really enhances how predictable COSE/CWT flows are and helps different encoders work together seamlessly. You can check out more about it here.

Implementation Notes

Make sure to validate producer outputs against the schema/CDDL in your CI/CD process. Also, don’t forget to include the schema URI/version in the envelope’s protected headers for easy discoverability.
When it comes to content addressing or storing in a registry, it's a good idea to normalize your canonical serialization (like using JCS for JSON) before hashing. This helps prevent any pesky re-encoding drift. Embracing the multiformats approach (multihash/CIDv1) can really boost your algorithm agility. Check it out at multiformats.io!

2) Signatures: JOSE, COSE, and VC cryptosuites

Use the standards that your verifiers are already on board with:

JOSE/JWS + JWT
- So, JWS (RFC 7515) and JWT (RFC 7519) are all about signing and handling those registered claims. Make sure to check for kid, alg, and typ; definitely don't accept "alg": "none"; and always validate those critical headers. Check out more on this at datatracker.ietf.org.
COSE/CBOR
- COSE (RFC 9052, STD 96) introduces COSE_Sign1, which is all about creating compact signatures for CBOR payloads. You can easily combine this with CWT (RFC 8392) to make the most of familiar claims like iss, sub, iat, nbf, and exp. Check it out here: (rfc-editor.org)
VC Cryptosuites and Media Types
- The W3C VC-JOSE-COSE Recommendation lays out the guidelines for securing VC Data Model 2.0 objects using JWS, SD-JWT, or COSE. It also registers media types such as application/vc+jwt and application/vc+cose. If you're in the process of issuing credentials as VDPs, it's a good idea to follow this to keep things streamlined and avoid unnecessary complications. Check it out here: (w3.org).

Algorithm Choices

Interop Defaults: We typically go with ES256 (P‑256) or Ed25519 for our signature algorithms. The Data Integrity EdDSA/ECDSA cryptosuites are W3C Recommendations as of May 2025, and they fit nicely with VDPs that stick to VC patterns. You can check it out here.

Key Discovery

When it comes to JWT/JWS, make sure to include the kid and share a JWKS. For COSE/CWT, you can either use COSE key parameters or point to a DID document. Don’t forget, VC-JOSE-COSE also talks about discovering keys through header parameters and “Controlled Identifier” documents. Check it out here: (w3.org)

3) Attestation: prove the environment and the build

Device/runtime attestation (RATS/EAT)

When your package says it’s “generated inside a TEE at firmware X with measurement Y,” make sure to include an EAT (either a JWT or CWT) that has the eat_nonce, ueid, and measurements. The EAT (RFC 9711) profiles match up nicely with the RATS roles in RFC 9334, allowing verifiers to evaluate the evidence and hand out “attestation results.” You can find more details here.

Software Supply Chain Attestation

First off, grab that build provenance using DSSE envelopes and SLSA attestations, and make sure to send it out with the artifact. This practice is becoming pretty standard across different ecosystems and really helps cut down on the hassle for auditors. Check it out here: (github.com).
Next, you'll want to register your signatures and provenance in Sigstore Rekor. Don’t forget to add those inclusion proofs to your verification bundle, and it might be wise to run or subscribe to a Rekor monitor. The good news? Rekor v2 GA is rolling out in October 2025, and it’s all about making things more user-friendly; plus, clients like Cosign v2.6+ are already on board. Get the scoop here: (blog.sigstore.dev).

Transparency and Time

To ensure compliance that stands the test of time, link your signature with a transparency receipt (also known as inclusion proof) instead of just depending on local clocks or those RFC3161-style timestamps. Check out CT v2 (RFC 9162) for a deep dive into the verifiable log model that's become a go-to for many software transparency systems. You can read more about it here.

4) Replay protection and freshness

Threats You Need to Tackle

Interception and Reuse of Signatures: Watch out for signatures being snagged and used in places they shouldn’t be, whether it’s outside their intended domains or after their time windows have passed.
Cross-Chain or Cross-Environment Replay: Keep an eye on authorizations that might get replayed across different chains or environments. This could lead to some serious security holes.
Reuse of Device Attestations: Be cautious about device attestations being reused in new sessions. This can create vulnerabilities that you definitely want to avoid.

Practical Controls by Channel

When it comes to managing your channels effectively, it's all about implementing the right practical controls. Here’s a breakdown of how to keep everything in check, no matter the platform!

Social media can be a double-edged sword. To navigate it well, consider these controls:

Content Calendar: Keep your posts organized with a clear schedule. This helps in maintaining a consistent presence.
Analytics Tools: Use tools like Hootsuite or Buffer to track engagement and adjust your strategy based on what works.
Community Guidelines: Set up rules for interaction to maintain a positive environment.

2. Email Marketing

Email remains a powerful channel, so make sure you’ve got these controls in place:

Segmentation: Divide your email list based on customer preferences or behaviors for more targeted campaigns.
A/B Testing: Experiment with subject lines, layouts, or send times to see what gets the best response.
Unsubscribe Options: Always provide an easy way for users to opt out. It keeps your list clean and your audience engaged.

3. Website Management

Your website is often the first point of contact, so it’s essential to have these controls:

SEO Practices: Optimize your site with keywords and meta descriptions to improve visibility.
Security Measures: Implement SSL certificates and regular backups to protect against breaches.
User Experience (UX): Regularly test for a good user experience, ensuring that visitors can easily find what they need.

4. Online Advertising

When diving into online ads, these practical controls can help maximize your ROI:

Budget Tracking: Keep a close eye on your spending and adjust as necessary based on performance.
Targeting Options: Use demographic and interest-based targeting to reach the right audience.
Conversion Tracking: Set up tools like Google Analytics to measure how well your ads lead to conversions.

5. Customer Support Channels

Last but not least, managing customer support effectively is key:

Multi-Channel Support: Offer assistance through chat, email, and social media to meet customers where they are.
Response Time Goals: Set and monitor response time goals to ensure quick replies and happy customers.
Feedback Systems: Encourage customers to leave feedback, helping you improve your service.

By putting these practical controls to use across various channels, you’ll be better equipped to engage your audience and drive results. Happy managing!

Web login/consent: When you're signing in with Ethereum (EIP‑4361), make sure you include domain binding, a server-chosen nonce (at least 8 characters), chainId, and the issued-at field. It’s super important to validate all these fields and use TLS. Check out more info here.
API calls: With OAuth DPoP (RFC 9449), the request is tied to a specific key and the HTTP method/URL (htm/htu) using a unique jti for each request. This offers solid protection against token replay attacks. You can read the details here.
Device attestation: The EAT specifies the eat_nonce with at least 64 bits of entropy. Make sure to require nonces specified by the verifier and keep their validity short while enforcing audience binding. Learn more here.
JWT/CWT in general: It’s best to use iat, nbf, and exp for precise time windows, along with a unique jti for every authorization. More info can be found here.
Blockchain-adjacent off-chain signatures: When dealing with signatures, make sure to include the EIP‑712 domain separator along with chainId and verifyingContract, or utilize SIWE fields. For on-chain transactions, remember that EIP‑155 chainId is the go-to replay separator. You can dive deeper here.
Smart accounts and counterfactual wallets: If you’re accepting contract signatures, don’t forget to support ERC‑1271 and ERC‑6492. This way, you can safely verify pre-deploy signatures by checking the magic bytes and factory calldata before calling isValidSignature. Details can be found here.
Selective disclosure with key binding: SD‑JWT+KB ties disclosures to a holder key. Be sure to verify the KB‑JWT along with the claims you’re disclosing. For more info, check here.

Nonce and Randomness Guidance

When generating nonces, make sure to use a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). Check out the recommendations in RFC 4086 and stick to modern Deterministic Random Bit Generators (DRBGs) like those described in NIST SP 800-90A/90C. And remember, stay away from using clocks or simple increments. You can find more details in the RFC document.

Example: Minimal Replay Defenses in a JWS Payload

When it comes to protecting your data, implementing replay defenses is crucial. A JSON Web Signature (JWS) payload can play a big role in not letting attackers re-use valid signatures. Here’s a simple example to illustrate minimal replay defenses in a JWS payload.

JWS Structure

A JWS typically consists of three parts:

Header: Contains metadata about the signature, such as the algorithm used.
Payload: The actual data you want to send.
Signature: The cryptographic signature that validates the message.

Sample Payload

Here's a basic example of a JWS payload that includes minimal replay defenses:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "jti": "unique-jwt-id-123"
}

Key Components

iat (Issued At): This timestamp indicates when the token was issued. It's a straightforward way to make sure tokens can’t be used after a certain time.
jti (JWT ID): A unique identifier for the token that you can track. If you’ve already seen it, you can reject any future uses of that same token.

Implementation

When you create your JWS, make sure to include both iat and jti claims. It’ll look something like this when you sign your payload:

jwt.sign(payload, secret, { algorithm: 'HS256' });

Why It Matters

Adding these simple claims can go a long way in bolstering your application's security. By preventing replay attacks, you’re making sure that even if someone gets hold of a valid token, they won’t be able to use it multiple times.

Keep these strategies in mind as you work with JWS. A little foresight can save you a lot of trouble down the line!

{
  "iss": "did:pkh:eip155:1:0xabc...def",
  "aud": "https://api.vendor.example",
  "nbf": 1733352000,
  "exp": 1733352300,
  "jti": "f1d9f962-5e4c-4765-9d78-1b2a62f3c0af",
  "nonce": "dYc2s0Kq9V4aP1cG",
  "subject": "shipping-notice:SN-AX4C7-2025-12-08"
}

Make sure to check aud, nbf, exp, jti, and nonce, and don’t forget to reject any replay attacks or mismatched audiences. You can find more details in the official documentation here: (rfc-editor.org).

5) Distribution: registries and content addressing

Store VDPs along with their attestations as OCI artifacts by using artifactType and linking them to subjects (referrers). This approach allows you to easily push or pull through any OCI registry and pin by digest across different environments. Check out the details here.
When dealing with large or multi-part packages, try to keep the schema and envelope lightweight, and point to binary parts as blobs using their digest. It's a good idea to go for CIDv1/multibase for content addressing; this will help you stay future-proof, especially when IPFS or content routing comes into play. Dive into the specifics here.

6) Concrete design patterns you can reuse

Pattern A: “Sign-then-attest”

Start by creating your canonical payload.
Sign it using JWS/COSE.
Wrap the signature metadata and any extra info in a DSSE envelope.
Upload both the payload and the DSSE envelope to a registry.
Record the details in Rekor.
Finally, ship the entire bundle.

Verifiers:

When it comes to verification, they’ll fetch by digest. Then, they’ll check the signature, ensure that the schema is up to snuff, and confirm the inclusion in Rekor. They’ll also take a look at the DSSE/SLSA and evaluate the policy. Check it out here!

Pattern B: “VC-style package”

Start by encoding your payload as a VC Data Model 2.0 credential. Then, secure it using application/vc+jwt or application/vc+cose. If you want to allow selective disclosure, you can optionally include SD-JWT. Finally, share it over whichever channel you like. (w3.org)

Pattern C: “Attested Device Report”

The device sends out an EAT (CWT) that includes some measurements and an eat_nonce. Then, the service puts together a verifiable package that combines the EAT with some business data. Finally, a relying party checks both the business signature and the attestation result according to RATS. (datatracker.ietf.org)

7) Practical examples

Example 1: EIP‑712 Typed Data for Off-Chain Authorization

Here’s a simple example of how to use EIP-712 typed data for off-chain authorization. This approach can help you create a structured way to sign and verify data, making your interactions more secure and reliable.

Structure of the EIP-712 Domain

First, let's define the domain separator. This serves as a unique identifier for your contract and helps prevent replay attacks. Here’s what that looks like in code:

const domain = {
  name: "YourContractName",
  version: "1",
  chainId: 1, // Mainnet
  verifyingContract: "0xYourContractAddress",
};

Defining the Message

Now, let’s define the message you want to sign. This could be a simple structure that needs to include specific fields. For instance:

const types = {
  Message: [
    { name: "sender", type: "address" },
    { name: "amount", type: "uint256" },
    { name: "nonce", type: "uint256" },
  ],
};

const value = {
  sender: "0xYourAddress",
  amount: 1000,
  nonce: 1,
};

Signing the Data

Once you’ve got your domain and message set up, you can sign the data with a wallet. Here’s a quick look at how you might do this with a library like Ethers.js:

const signature = await wallet._signTypedData(domain, types, value);

Verifying the Signature

Finally, you can verify the signature on-chain to ensure everything checks out. This step is crucial for maintaining security. You can accomplish this with a function like this:

const recoveredAddress = ethers.utils.verifyTypedData(domain, types, value, signature);

And that’s a wrap! With these steps, you've got a solid foundation for using EIP-712 typed data for off-chain authorization.

{
  "types": {
    "EIP712Domain": [
      {"name": "name", "type": "string"},
      {"name": "version", "type": "string"},
      {"name": "chainId", "type": "uint256"},
      {"name": "verifyingContract", "type": "address"}
    ],
    "PermitNotice": [
      {"name": "noticeId", "type": "string"},
      {"name": "aud", "type": "address"},
      {"name": "expires", "type": "uint256"}
    ]
  },
  "domain": {
    "name": "7Block VDP",
    "version": "1",
    "chainId": 1,
    "verifyingContract": "0x0000000000000000000000000000000000000000"
  },
  "primaryType": "PermitNotice",
  "message": {
    "noticeId": "SN-AX4C7-2025-12-08",
    "aud": "0x1234...cafe",
    "expires": 1764710400
  }
}

Make sure to include chainId and verifyingContract in the domain for better domain separation. You can check out more details here.

Example 2: SD-JWT with Key Binding (Conceptual)

So, here's how it goes: the Issuer puts together an SD-JWT that includes salted digests for fields that can be disclosed, like address.line2. Then, the Holder shows off the SD-JWT along with the chosen disclosures and a KB-JWT, which they sign with their own key. This setup helps keep things safe from relay attacks. Check it out in more detail over at (rfc-editor.org).

Example 3: EAT Nonce and Claims (JSON Form)

In this example, we’ll take a closer look at the EAT nonce and its claims, represented in JSON format. This can really help clarify how the data is structured and what it all means.

EAT Nonce

The nonce is a unique identifier that's used to ensure the authenticity of the claim. It helps prevent replay attacks, meaning that an old claim can’t be reused maliciously.

JSON Representation

Here’s how a simple JSON representation of an EAT nonce and claims might look:

{
  "nonce": "abc123",
  "claims": {
    "iss": "https://example.com",
    "sub": "user@example.com",
    "exp": 1625245142,
    "iat": 1625241542,
    "aud": "https://example-audience.com",
    "scope": "read write"
  }
}

Breakdown of the Claims

nonce: A unique value, in this case, "abc123".
iss: This is the issuer of the claim. Here, it’s pointing to "https://example.com"--the source you can trust.
sub: This identifies the subject of the claim, which is "user@example.com" in our example.
exp: This is the expiration time of the claim in Unix timestamp format. In our case, it’s set to 1625245142.
iat: The time when the claim was issued, also in Unix timestamp; here it’s 1625241542.
aud: The audience for this claim, which is "https://example-audience.com".
scope: This defines the permissions granted, such as "read write".

With this setup, you can see how the nonce and claims work in a real-world scenario, ensuring the integrity and security of the data being shared.

{
  "eat_nonce": "k6A0n1WQH3xpv3C7",
  "ueid": "01-23-45-67-89-ab",
  "iat": 1733352102,
  "submods": [{
    "measurement": {"sha256": "f0..."},
    "swName": "agent-collector",
    "swVersion": "2.1.3"
  }]
}

Make sure to use nonces provided by the verifier that have at least 64 bits of entropy and are short-lived. You can check out more details in the official RFC document here: (datatracker.ietf.org)

Cryptographic agility
- Make sure to support at least ES256 and Ed25519; declare the algorithm clearly; rotate keys while keeping some overlap in their validity and JWKS rollovers. The VC cryptosuites for EdDSA/ECDSA have now become W3C RECs. (w3.org)
Deterministic encoding and hashing
- Start by fixing the canonical JSON (or you can go with CBOR for that deterministic vibe), then use a digest (like SHA‑256) or CIDv1 for wide distribution. Multihash is great because it keeps you from getting locked into just one hashing option. Check out more on this at (multiformats.io).
Focus on what truly counts, not everything
- When it comes to software, SLSA v1.1 really helps with understanding provenance and verification. For devices, it’s best to use a specific EAT profile along with a RATS flow--think “passport” versus “background check” so that verifiers have a clear idea of what they need to evaluate. (slsa.dev)
Freshness and anti‑replay by design
- Make sure to always include aud/nbf/exp and jti; also, it’s a good idea to require nonces chosen by the verifier. For web APIs, go with DPoP, and when it comes to wallet sign-ins, use SIWE’s nonce along with the domain. And remember, don’t just depend on transport security alone. (rfc-editor.org)
Smart-account signatures
- When you’re accepting contract-based signatures, make sure to implement the ERC‑1271 and ERC‑6492 verification paths. This will help you fill in the gaps for counterfactual accounts and cut down on those pesky false negatives. Check it out here: (ercs.ethereum.org)
Keep things transparent when it comes to timestamping
- It's better to use verifiable logs (like Rekor) that come with inclusion proofs and are independently monitored. This approach really boosts long-term non-repudiation. Check it out here: (docs.sigstore.dev)
Nonce quality
- Make sure to use CSPRNGs (check out RFC 4086, NIST SP 800‑90A/90C); 128-bit nonces are both affordable and reliable--just remember, never reuse them. (rfc-editor.org)

9) A verification checklist your team can automate

First up, you’ll want to parse the envelope and figure out what kind of media type you’re dealing with (vc+jwt, vc+cose, application/jwt, cose-sign1). Check out the details here.
Next, make sure to validate the schema using either JSON Schema or CDDL. If your policy demands it, reject any unknown properties. You can get the scoop on that here.
Then, move on to verifying the signature according to JWS/COSE rules. Don't forget to resolve the kid, enforce those critical headers, and check that the alg is on your allowlist. More info can be found here.
It’s important to enforce freshness too: check that the iat is within your set tolerance, nbf/exp are correct, the jti hasn’t been seen before, and that the nonce matches your verifier challenge. You can read up on this here.
If you’re dealing with a VC style, don't forget to apply VC-JOSE-COSE processing and run those status checks, like bitstring status lists, following the W3C specs. All the details are here.
If there’s an attestation in play, be sure to verify the EAT/CWT or JWT EAT against your policy. And if it’s software, check the DSSE/SLSA and the Rekor inclusion proof. Find more about this here.
Lastly, in the blockchain context, you’ll want to validate the EIP‑712 domain or SIWE fields. If it’s on-chain, make sure to validate the EIP‑155 domain separation. Plus, if your signers are contracts, support ERC‑1271/6492. Get the details here.

10) Small decisions that pay off at scale

Include the schema/CDDL version in the protected header so that upgrades can be easily detected by machines.
Give each VDP type and version a stable “profile” URN.
Treat transparency evidence, like the Rekor UUID and checkpoints, as important fields to make audits easier down the line. (docs.sigstore.dev)
Use CAIP‑10 or did:pkh for cross‑chain account identifiers--this helps to sidestep the hassle of ad-hoc address parsing. (chainagnostic.org)

Summary

If you're diving into designing a verifiable data package today, consider a few key things: aim for JOSE/COSE envelopes, make sure to pin your schema using either JSON Schema or CDDL, and definitely include attestation where it really makes a difference in managing risk. And don't forget that replay protection should be a must-have, no questions asked.

With the W3C VC 2.0 and IETF standards like SD‑JWT, EAT, and DPoP all stable and ready to roll, you can confidently create interoperable, auditable VDPs that seamlessly work across different wallets, registries, and devices--no need to start from scratch with crypto. Check out more about it here.

About 7Block Labs

We’re here to support startups and big companies in creating, launching, and reviewing verifiable systems. Whether you need a reference implementation (like JSON/JOSE and CBOR/COSE), a schema/CDDL linting pipeline, or want a Rekor-backed publishing flow, we’ve got you covered with templates and code to help out.