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

A verifiable data package (VDP) is a portable bundle of structured data plus cryptographic evidence proving who created it, what it contains, and when it was produced. This guide distills the latest standards and field practices so your team can design VDPs that interoperate across wallets, clouds, devices, and ledgers—and stand up to audits and attacks.

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

• W3C finalized the Verifiable Credentials (VC) 2.0 family on May 15, 2025, including Data Integrity 1.0 and “Securing VCs with JOSE/COSE,” making JSON/JWT, SD‑JWT, and CBOR/COSE first-class ways to secure credentials. (w3.org)
• Selective Disclosure for JWTs is now an IETF standard (RFC 9901, Nov 2025), enabling holders to reveal only slices of signed data. (rfc-editor.org)
• Device and runtime attestation matured: the Entity Attestation Token (EAT) became RFC 9711 (Apr 2025), aligning JWT/CWT claims with the IETF RATS architecture (RFC 9334). (datatracker.ietf.org)
• Sigstore’s Rekor transparency log advanced (v2 GA Oct 10, 2025), lowering costs and adding client conformance; you can now verify inclusion and monitor logs at scale. (blog.sigstore.dev)

Below is a reference design you can apply today.

---

A reference architecture for verifiable data packages

A production-grade VDP usually includes:

1. Envelope and media type

• JSON + JWS/JWT when human readability and web tooling matter; CBOR + COSE when bandwidth or constrained devices matter. W3C VC-JOSE-COSE defines media types like application/vc+jwt and application/vc+cose for credentials and presentations. (w3.org)

1. Schema

• Use JSON Schema 2020‑12 for JSON payloads; use CDDL for CBOR payloads. Both are stable and widely tooled. (json-schema.org)

1. Signatures and keys

• JOSE (JWS/JWT) and COSE (COSE_Sign1, COSE_Sign) are the IETF standards; use key IDs (kid), algorithm agility, and validation rules from these specs. (datatracker.ietf.org)

1. Attestation (optional but recommended)

• For software provenance, use DSSE envelopes and SLSA attestations, optionally notarized in a transparency log (Rekor). For devices, use EAT/CWT or JWT following RATS roles. (github.com)

1. Replay protection and freshness

• Bind to domains and sessions (web), bind to chain IDs (blockchain), and bind to HTTP methods/URLs (API calls). Use nonces, issued-at, expiry, and key-binding proofs (DPoP, SD‑JWT KB). (eips.ethereum.org)

1. Distribution

• Package and distribute as OCI artifacts with content addressing (digests/CIDs) so auditors can reproduce byte-for-byte inputs. (oci-playground.github.io)

---

1) Schema: make it precise and future‑proof

• JSON payloads: author a JSON Schema (draft 2020‑12). Prefer closed-world schemas (“additionalProperties”: false) and explicit formats; pin

  $schema

  and

  $id

  URIs. (json-schema.org)
• CBOR payloads: publish a CDDL that defines field names, integer label maps, and claim types. CDDL is the IETF notational standard for CBOR and JSON. (datatracker.ietf.org)

Example: Shipping Notice schema (JSON, excerpt)

{
  "$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: the same structure in CDDL (CBOR), using numeric labels for compactness

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 improves determinism for COSE/CWT flows and makes encoders interoperable. (datatracker.ietf.org)

Implementation notes

• Validate producer outputs against the schema/CDDL in CI/CD, and embed the schema URI/version in the envelope’s protected headers for discoverability.
• For content addressing or registry storage, normalize canonical serialization (e.g., JCS for JSON) before hashing to avoid re‑encoding drift. The multiformats approach (multihash/CIDv1) helps with algorithm agility. (multiformats.io)

---

2) Signatures: JOSE, COSE, and VC cryptosuites

Use the standards your verifiers already support:

• JOSE/JWS + JWT

  • JWS (RFC 7515) and JWT (RFC 7519) define signing and registered claims. Enforce kid, alg, typ; reject “alg”: “none”; and validate critical headers. (datatracker.ietf.org)

• COSE/CBOR

  • COSE (RFC 9052, STD 96) defines COSE_Sign1 for compact signatures over CBOR payloads; pair with CWT (RFC 8392) to reuse familiar claims like iss, sub, iat, nbf, exp. (rfc-editor.org)

• VC cryptosuites and media types

  • The W3C VC-JOSE-COSE Recommendation defines how to secure VC Data Model 2.0 objects using JWS, SD‑JWT, or COSE, and registers media types like application/vc+jwt and application/vc+cose. If you’re issuing credentials as VDPs, align with this to reduce custom glue. (w3.org)

Algorithm choices

• Interop defaults: ES256 (P‑256) or Ed25519 for signatures. Data Integrity EdDSA/ECDSA cryptosuites are W3C Recommendations (May 2025) and map well to VDPs that follow VC patterns. (w3.org)

Key discovery

• For JWT/JWS, embed kid and publish a JWKS; for COSE/CWT, use COSE key parameters or reference a DID document. VC-JOSE-COSE also covers key discovery via header params and “Controlled Identifier” docs. (w3.org)

---

3) Attestation: prove the environment and the build

Device/runtime attestation (RATS/EAT)

• If your package claims “generated inside a TEE at firmware X with measurement Y,” carry an EAT (JWT or CWT) with eat_nonce, ueid, and measurements. EAT (RFC 9711) profiles align with RATS roles from RFC 9334 so verifiers can appraise evidence and issue “attestation results.” (datatracker.ietf.org)

Software supply chain attestation

• Capture build provenance using DSSE envelopes and SLSA attestations; distribute alongside the artifact. This is now common across ecosystems and reduces toil for auditors. (github.com)
• Register signatures/provenance in Sigstore Rekor; include inclusion proofs in your verification bundle, and consider running or subscribing to a Rekor monitor. Rekor v2 GA (Oct 2025) improves operability; clients (Cosign v2.6+) already support it. (blog.sigstore.dev)

Transparency and time

• For long-lived compliance, pair your signature with a transparency receipt (inclusion proof) rather than relying solely on local clocks or RFC3161-style timestamps. CT v2 (RFC 9162) explains the verifiable log model widely reused by software transparency systems. (rfc-editor.org)

---

4) Replay protection and freshness

Threats you must handle

• Interception and reuse of signatures outside intended domains or time windows
• Cross-chain or cross-environment replay of authorizations
• Reuse of device attestations in new sessions

Practical controls by channel

• Web login/consent: Sign‑In with Ethereum (EIP‑4361) includes domain binding, a server-chosen nonce (≥8 chars), chainId, and issued‑at; validate all fields and require TLS. (eips.ethereum.org)
• API calls: OAuth DPoP (RFC 9449) binds the request to a key and to the HTTP method/URL (htm/htu) with a unique jti per request—robust protection against token replay. (rfc-editor.org)
• Device attestation: EAT defines eat_nonce with ≥64 bits entropy; require verifier-specified nonces and short validity, and enforce audience binding. (datatracker.ietf.org)
• JWT/CWT generally: use iat, nbf, exp for strict time windows and a unique jti per authorization. (rfc-editor.org)
• Blockchain-adjacent off-chain signatures: include EIP‑712 domain separator with chainId and verifyingContract, or SIWE fields; for on-chain transactions EIP‑155 chainId remains the canonical replay separator. (eips.ethereum.org)
• Smart accounts and counterfactual wallets: if you accept contract signatures, support ERC‑1271 and ERC‑6492 so you can verify pre-deploy signatures safely; check magic bytes and factory calldata before calling isValidSignature. (ercs.ethereum.org)
• Selective disclosure with key binding: SD‑JWT+KB binds disclosures to a holder key; verify the KB‑JWT along with the disclosed claims. (rfc-editor.org)

Nonce and randomness guidance

• Generate nonces with a CSPRNG; follow RFC 4086 guidance and modern DRBGs (NIST SP 800‑90A/90C). Avoid clocks or increments. (rfc-editor.org)

Example: minimal replay defenses in a JWS payload

{
  "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"
}

Verify aud/nbf/exp/jti/nonce and reject replays or mismatched audiences. (rfc-editor.org)

---

5) Distribution: registries and content addressing

• Store VDPs and their attestations as OCI artifacts with artifactType and subject linkage (referrers). This lets you push/pull via any OCI registry and pin by digest across environments. (oci-playground.github.io)
• For large or multi-part packages, keep the schema and envelope small, and reference binary parts as blobs by digest. Prefer CIDv1/multibase for future-proof content addressing when IPFS or content routing is in scope. (docs.ipfs.tech)

---

6) Concrete design patterns you can reuse

Pattern A: “Sign-then-attest”

• Produce canonical payload → JWS/COSE signature → wrap signature metadata and build info in a DSSE envelope → upload both to a registry → record in Rekor → ship the bundle.
• Verifiers: fetch by digest; verify signature, schema conformance, and Rekor inclusion; verify DSSE/SLSA; evaluate policy. (github.com)

Pattern B: “VC-style package”

• Encode the payload as a VC Data Model 2.0 credential; secure with application/vc+jwt or application/vc+cose; optionally use SD‑JWT for selective disclosure; distribute via your preferred channel. (w3.org)

Pattern C: “Attested device report”

• Device emits EAT (CWT) with measurements and eat_nonce; the service issues a verifiable package that embeds the EAT + business data; a relying party verifies both the business signature and the attestation result per RATS. (datatracker.ietf.org)

---

7) Practical examples

Example 1: 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
  }
}

Include chainId and verifyingContract in the domain for robust domain separation. (eip.info)

Example 2: SD‑JWT with key binding (conceptual)

• Issuer creates SD‑JWT with salted digests for disclosable fields (e.g., address.line2). Holder presents the SD‑JWT plus selected disclosures and a KB‑JWT signed by their key, preventing relay attacks. (rfc-editor.org)

Example 3: EAT nonce and claims (JSON form)

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

Require verifier-provided nonces (≥64 bits entropy) and short lifetime. (datatracker.ietf.org)

---

8) Emerging best practices we recommend

• Cryptographic agility

  • Support at least ES256 and Ed25519; declare alg explicitly; rotate keys with overlapping validity and JWKS rollovers. VC cryptosuites for EdDSA/ECDSA are now W3C RECs. (w3.org)

• Deterministic encoding and hashing

  • Fix canonical JSON (or use CBOR determinism), then address by digest (SHA‑256) or by CIDv1 when distributing widely. Multihash avoids lock‑in to a single hash. (multiformats.io)

• Attest what matters, not everything

  • For software, SLSA v1.1 clarifies provenance and verification; for devices, stick to a specific EAT profile and RATS flow (“passport” vs “background check”) so verifiers know what to appraise. (slsa.dev)

• Freshness and anti‑replay by design

  • Always include aud/nbf/exp and jti; require verifier-chosen nonces; for web APIs use DPoP; for wallet sign-in use SIWE’s nonce + domain. Don’t rely on transport security alone. (rfc-editor.org)

• Smart-account signatures

  • If you accept contract-based signatures, implement ERC‑1271 and ERC‑6492 verification paths. This closes gaps for counterfactual accounts and reduces false negatives. (ercs.ethereum.org)

• Transparency over timestamping when possible

  • Prefer verifiable logs (Rekor) with inclusion proofs and independent monitoring to strengthen long-term non-repudiation. (docs.sigstore.dev)

• Nonce quality

  • Use CSPRNGs (per RFC 4086, NIST SP 800‑90A/90C); 128-bit nonces are cheap and robust; never reuse. (rfc-editor.org)

---

9) A verification checklist your team can automate

• Parse envelope and detect media type (vc+jwt, vc+cose, application/jwt, cose-sign1). (w3.org)
• Validate schema (JSON Schema or CDDL); reject unknown properties if your policy requires it. (json-schema.org)
• Verify signature per JWS/COSE rules; resolve kid; enforce critical headers; check alg against allowlist. (datatracker.ietf.org)
• Enforce freshness: iat within tolerance; nbf/exp; jti not seen; nonce matches verifier challenge. (rfc-editor.org)
• If VC style: apply VC-JOSE-COSE processing and status checks (e.g., bitstring status lists) per W3C specs. (w3.org)
• If attested: verify EAT/CWT or JWT EAT against policy; if software: verify DSSE/SLSA and Rekor inclusion proof. (datatracker.ietf.org)
• If blockchain context: validate EIP‑712 domain or SIWE fields; if on-chain, validate EIP‑155 domain separation. Support ERC‑1271/6492 if signers are contracts. (eips.ethereum.org)

---

10) Small decisions that pay off at scale

• Put the schema/CDDL version into the protected header so upgrades are machine-detectable.
• Assign stable “profile” URNs for each VDP type and version.
• Treat transparency evidence (e.g., Rekor UUID, checkpoint) as first-class fields to simplify audits later. (docs.sigstore.dev)
• Use CAIP‑10 or did:pkh for cross‑chain account identifiers to avoid ad‑hoc address parsing. (chainagnostic.org)

---

Summary

If you design a verifiable data package today, target JOSE/COSE envelopes, pin your schema with JSON Schema or CDDL, add attestation where it moves the risk needle, and make replay protection non-negotiable. With W3C VC 2.0 and IETF standards (SD‑JWT, EAT, DPoP) now stable, you can ship interoperable, auditable VDPs that work across wallets, registries, and devices—without reinventing crypto. (w3.org)

---

About 7Block Labs

We help startups and enterprises design, ship, and audit verifiable systems. If you want a reference implementation (JSON/JOSE and CBOR/COSE), a schema/CDDL linting pipeline, or a Rekor-backed publishing flow, we’re happy to share templates and code.