L2 Formal Requirements

All attestations MUST be cryptographically signed using a digital signature algorithm. The attestation MUST be wrapped in a DSSE envelope containing the signature.

Signatures MUST use one of the following algorithms:

• ECDSA P-256 (ES256) — RECOMMENDED for most use cases
• ECDSA P-384 (ES384) — For higher security requirements
• Ed25519 — For performance-sensitive applications
• RSA-PSS (PS256, PS384, PS512) — For legacy compatibility only

Producers SHOULD use Sigstore keyless signing when possible. Keyless signing binds attestations to OIDC identities without requiring long-lived signing keys, simplifying key management and improving auditability.

Each signature MUST be bound to a verifiable identity through one of the following mechanisms:

• X.509 certificate — Certificate chain to trusted root CA
• Sigstore/Fulcio certificate — Short-lived certificate from OIDC identity
• Published public key — Key published at well-known location with documented ownership

The attestation predicate MUST include a reference to the signing identity in the collector.id (for origin attestations) or executor.id (for transform attestations) field. This identifier MUST match or be verifiable against the signing identity.

{
  "predicate": {
    "collector": {
      "id": "https://expanso.io/collectors/prod-west-1",
      // This ID must match the signing certificate's subject
    }
  }
}

All attestations MUST include a verifiable timestamp proving when the attestation was created. This MUST be achieved through one of:

• RFC 3161 timestamp token — From a trusted Timestamp Authority
• Sigstore Rekor entry — Attestation logged to transparency log with timestamp
• Certificate-embedded timestamp — When using short-lived signing certificates

The attestation predicate MUST include metadata.startedOn and metadata.finishedOn (for transforms) or origin.collectionTimestamp (for origins) as ISO 8601 timestamps. These self-reported times SHOULD be consistent with the verifiable timestamp (within reasonable clock skew).

Transform attestations MUST include cryptographic digests of all input datasets in the predicate.inputs array. Each input MUST specify at minimum a sha256 digest.

{
  "predicate": {
    "inputs": [{
      "name": "dataset:raw_transactions",
      "digest": {
        "sha256": "a1b2c3d4e5f6..."
      },
      "attestationRef": "https://attestations.example.com/abc123"
    }]
  }
}

Transform attestations MUST include attestationRef URIs for each input, pointing to the signed attestation for that input dataset. This enables recursive lineage verification.

For streaming data, stream-window attestations SHOULD include a reference to the previous window's attestation in predicate.integrity.previousWindow. This creates a tamper-evident chain of windows.

Verifiers MUST validate that the DSSE envelope signature is cryptographically valid for the payload. The verification process MUST:

• Parse the DSSE envelope and extract payload and signatures
• Reconstruct the PAE (Pre-Authentication Encoding) from payload type and payload
• Verify at least one signature against the PAE using the signer's public key

Verifiers MUST reject attestations where signature verification fails. The data associated with a failed attestation MUST NOT be trusted for L2-requiring use cases.

Verifiers MUST determine and validate the signing identity. For X.509 certificates, this means validating the certificate chain to a trusted root. For Sigstore, this means verifying the Fulcio certificate and OIDC claims.

Verifiers MUST apply a trust policy to determine if the signing identity is authorized to produce attestations for the given data. Trust policies MAY be based on:

• Explicit list of trusted signing identities
• Organizational membership (e.g., any identity from @example.com)
• Certificate attributes (e.g., specific OU or SAN values)

Verifiers SHOULD check that the signing identity is consistent with the collector.id or executor.id in the attestation predicate. Mismatches MAY indicate attestation reuse or forgery attempts.

Verifiers MUST verify that the attestation has a valid timestamp from a trusted source. For RFC 3161 timestamps, verify the TSA signature. For Rekor entries, verify inclusion proof.

Verifiers SHOULD check that the attestation timestamp is consistent with expected data freshness. Attestations with timestamps significantly older than expected MAY indicate stale or replayed data.

For transform attestations, verifiers MUST verify that the inputs[].digest values match the subject.digest values of the referenced input attestations. Mismatches indicate data tampering between pipeline stages.

Verifiers SHOULD recursively fetch and verify all attestations in the lineage chain, back to origin attestations. This provides full provenance verification. Verification depth MAY be limited by policy for performance reasons.

Verifiers MUST compute the cryptographic digest of the received data and compare it to the subject.digest in the attestation. If digests do not match, the data has been modified after attestation and MUST NOT be trusted.