Deterministic Evidence & Witness Protocol (DEWP) Specification

1.1 Scope

DEWP specifies exclusively:¶

1. The canonical event preimage schema and deterministic serialization rules using JSON Canonicalization Scheme (JCS) [RFC8785].¶

2. Domain-separated hashing rules (0x00 leaf tag, 0x01 node tag, 0x02 empty root tag, 0x03 anchor tag, 0x04 checkpoint-chain tag) to prevent cross-domain signature and second-preimage attacks.¶

3. The two-tier Merkle log tree hierarchy (Tier 1 Block Roots and Tier 2 Daily Checkpoint Roots).¶

4. The schema for portable single-event (dewp.audit.inclusion-proof), multi-event (dewp.audit.evidence-bundle), and streaming (dewp.audit.evidence-stream) proof containers.¶

5. Content-Verified, Commitment-Only (Privacy Redacted), Signature-Verified, and Fully-Verified validation levels.¶

6. The offline inclusion and gapless completeness verification procedure executed by a Relying Party or auditor.¶

1.2 Out-of-Scope (Explicit Non-Goals)

DEWP explicitly does NOT define:¶

• Pre-Execution Intent Authorization: Synchronous step-up approvals and intent binding are governed by companion specifications such as DIV [DIV].¶

• Storage Engine & Database Schemas: Physical table storage, indexing, and database engine choice are implementation details.¶

• Public Anchor Transports: Specific block-anchoring transports (e.g., Git repositories, public transparency logs, distributed ledgers) are external integration choices.¶

1.3 Relationship to DIV

DEWP and DIV are independent but complementary protocol primitives.¶

DIV ([DIV]) provides pre-execution authorization evidence by cryptographically binding approval to an intended execution payload.¶

DEWP provides post-execution evidence by cryptographically committing completed events into an append-only audit structure.¶

A compliant implementation MAY combine DIV Intent Proofs with DEWP Witness Events by embedding the verified DIV payload, digest hash (divIntentHash), and signature metadata into the DEWP Canonical Preimage (array indices 8, 9, 10).¶

The presence of a DEWP Witness Event MUST NOT be interpreted as proof that DIV authorization occurred unless the associated DIV proof material is independently verified.¶

Nothing in the preimage or its verification ties these slots to DIV specifically: indices 6..10 carry generic signer, payload and signature material, and verification per §4.6.1 checks the signature over the payload bytes without ever interpreting the payload's schema. Any pre-execution protocol whose proof is a signature over a canonical byte string can occupy them under the same rules; DIV is the companion specification this document uses as its worked example.¶

4.1 Canonical Array Preimage Representation (DEWP Core)

The DEWP Core Canonical Preimage MUST be represented as an ordered JSON array serialized using RFC 8785 JSON Canonicalization Scheme (JCS). It is defined by a single canonical rule:¶

• Fixed core fields: indices 0..10 (seq .. sigAlg) MUST appear in the order defined in §4.2 and MUST NOT be reordered.¶

• tenantSeq is always the final element of the array (array[array.length - 1]).¶

• Bare Core: with no Application Profile, the array has exactly 12 elements — fixed fields 0..10 followed by tenantSeq at index 11.¶

• Profiles (§4.5): an Application Profile MAY insert profile fields at indices 11..N-1; tenantSeq is then relocated to the final index N. It is never at a fixed numeric index other than "last".¶

Vendor- or application-specific attributes MUST NOT be inserted among the fixed core fields 0..10; they MUST be carried in metadata (index 5) or appended as profile fields per §4.5.¶

NOTE: '\' line wrapping per RFC 8792

[
  "1048576",
  "2026-07-24T12:00:00.000Z",
  "ACTION_APPROVED",
  "SUCCESS",
  "Database drop approved",
  "{\"target\":\"users\"}",
  "did:example:human:alice",
  "base64-spki-public-key",
  "{\"actionType\":\"db:dropTable\",\"type\":\"div-intent-verificati\
  on\",\"v\":1}",
  "base64-signature",
  "ES256",
  "42"
]

4.2 Array Element Definitions (DEWP Core)

4.3 Canonical Null, Timestamp, and Size Bound Rules

• Canonical Null Rules: A bare DEWP Core array MUST contain exactly 12 elements (a profile array contains 12 + (number of profile fields) elements, with tenantSeq always last). Missing fields MUST NOT be omitted; they MUST be represented as explicit null. An empty string "" MUST NOT be treated as null.¶

• Timestamp Rules: Timestamps MUST be formatted as ISO 8601 UTC strings (YYYY-MM-DDTHH:mm:ss.sssZ) with millisecond precision and a literal 'Z' zero timezone offset. Implementations SHOULD attach RFC 3161 Timestamp Authority (TSA) tokens for high-assurance timestamp non-repudiation.¶

• Size Bounds: The detail field SHOULD NOT exceed 4,096 bytes. The metadata field SHOULD NOT exceed 65,536 bytes (64 KB). The total Canonical Preimage JCS byte string SHOULD NOT exceed 131,072 bytes (128 KB). (These were stated as MUST in an earlier revision. No producer or verifier in the reference implementation enforces them, and a verifier that started rejecting oversized leaves would fail to verify history it had already anchored. They are downgraded to SHOULD to match reality; a future revision may enforce them at the producer only.)¶

• ID Monotonicity: Event identifiers SHOULD be RFC 9562 UUIDv7 strings to guarantee time-ordered sortability across distributed systems.¶

4.4 Cryptographic Hash Definitions

All cryptographic digests in DEWP MUST use SHA-256 as defined by FIPS 180-4 [FIPS180-4].¶

Digest values MUST be encoded as 64-character lowercase ASCII hexadecimal strings (e.g. d4e5f6a1b2c3...).¶

The normative hash functions are:¶

• sha256Hex(dataBytes): Computes SHA-256(dataBytes) and returns a 64-character lowercase hex string.¶

• hashLeaf(preimageStr): Computes sha256Hex(byte(0x00) || UTF8Bytes(preimageStr)).¶

• hashPair(leftHex, rightHex): Computes sha256Hex(byte(0x01) || hexDecode(leftHex) || hexDecode(rightHex)). The two child digests are hex-decoded to their raw 32 bytes before hashing (they are NOT concatenated as hex strings). Order encodes position (left then right) and MUST NOT be sorted.¶

4.5 Application Profiles & Extension Arrays

Applications requiring additional domain-specific or platform-specific attributes MUST carry them inside element 5 (metadata) or define an explicit Application Profile.¶

4.6 Event Signature Scope

The event-level signature material carried in the preimage (signerDid, signerPublicKey, signedPayload, signature, sigAlg — indices 6..10) is embedded intent-proof material, reproduced by reference from a pre-execution authorization protocol — in this document's examples, DIV ([DIV]). Its scope MUST be understood precisely to avoid over-claiming:¶

• signedPayload is the exact, verbatim canonical byte string the signer's key signed — for a DIV approval, the DIV Intent Payload ({"actionType":...,"type":"div-intent-verification","v":1}). It is reproduced byte-for-byte; DEWP does not re-serialize it.¶

• signature covers ONLY the bytes of signedPayload. It does NOT cover any DEWP field — not seq, not tenantSeq, not createdAt, not the surrounding preimage array. A verifier MUST NOT infer that the signer attested to the DEWP sequence numbers, timestamps, or Merkle position.¶

• What binds the DEWP fields is the Merkle commitment, not the event signature. Integrity of seq/tenantSeq/createdAt/etc. derives from leafHash(CanonicalPreimage) being committed under an anchored root (§3 Invariants 2 and 3), a property independent of whether any event signature is present.¶

• Consequently, a SIGNATURE_VERIFIED result asserts "a named key signed exactly signedPayload" and nothing about the DEWP envelope; a CONTENT_VERIFIED result asserts the envelope was committed. Both are required to conclude "this signed action was recorded at this position."¶

5.1 Tree Construction & Balancing Rules

Each rule below is referenced elsewhere as §5.1.N.¶

1. §5.1.1 — Empty Tree: An empty Merkle tree has merkleRoot([]) == sha256Hex(byte(0x02)).¶

2. §5.1.2 — Single Leaf Tree: A tree with 1 leaf has merkleRoot([L1]) == L1.¶

3. §5.1.3 — Odd Node Duplication: When an odd number of nodes exists at any level during pairwise iteration, the final node MUST be duplicated (nextParent = hashPair(level[i], level[i])). This rule is why inclusion proofs require bounds — see §11.1.¶

4. §5.1.4 — Tier 1 (Block Merkle Tree): Witness events occurring within a short time window are hashed into Leaf Hashes (hashLeaf(preimage)) and balanced into a Tier 1 Block Merkle Tree.¶

5. §5.1.5 — Tier 2 (Daily Checkpoint Tree): Block Roots are re-hashed with the leaf tag (hashLeaf(blockRoot)) and aggregated into a Tier 2 Daily Checkpoint Tree, yielding a final single Daily Checkpoint Root.¶

6. §5.1.6 — Leaf-to-Root Ordering & Sibling-Relative Naming: All proof step arrays (blockProof and checkpointProof) MUST be ordered strictly from leaf to root (bottom to top). Each step MUST contain siblingHash (the digest of the sibling node) and siblingPosition ("LEFT" or "RIGHT" — the side on which the sibling sits relative to the running node). The running node is combined as hashPair(siblingHash, running) when siblingPosition == "LEFT", else hashPair(running, siblingHash).¶

5.2 Signed Anchor Preimage Specification (0x03 Domain Tag)

To anchor a Daily Checkpoint Root, an anchor provider MUST publish a signed anchor object.¶

The Canonical Anchor Preimage MUST be serialized as an ordered 7-element JSON array of strings formatted according to RFC 8785 (JCS):¶

[
  "e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c3d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8",
  "2026-07-24T23:59:00.000Z",
  "https://transparency.example.org",
  "ES256",
  "1048576",
  "1049600",
  "6ae54abac75d273317f9f369306f2fbe85f2fafc9dd30685dc4f8a375257ef2b"
]

The anchor signing input is the raw domain-separated digest:¶

anchorDigest = SHA-256(byte(0x03) || UTF8Bytes(JCS([dailyRoot, timestamp, issuer, algorithm, seqStart, seqEnd, chainHash])))¶

Why the position is bound. A root alone says nothing about where in the log it sits or when it existed. An anchor over the root alone lets a party able to rewrite the log recompute a root and have it witnessed at any later time, with nothing tying the witness to the checkpoint it is offered for. Binding seqStart/seqEnd names the range; binding chainHash — which commits to the checkpoint's root, range, entry count, commit time and its predecessor's chain hash (§5.4) — makes every anchor re-attest the entire sequence of roots before it, so an edit to any earlier checkpoint invalidates the anchors of every later one. An anchor object lacking any of the seven fields, or carrying one in another shape, MUST NOT verify. In particular algorithm MUST be one of ES256, Ed25519 and RSA-PSS for every anchor kind — external anchors carry the producer's own anchor algorithm — and a verifier MUST NOT fall back to some default scheme for any other label.¶

The signature MUST be computed over the raw 32-byte anchorDigest value, NOT over its 64-character lowercase-hex string encoding. (For algorithms that apply their own message hash — e.g. ECDSA-P256/SHA-256, RSA-PSS/SHA-256 — the anchorDigest bytes are the message input; verifiers MUST pass the 32 raw bytes, never the hex text.) A verifier that hex-encodes the digest before signature verification MUST be considered non-conformant, as it will interoperate with neither compliant signers nor the reference vectors.¶

RSA-PSS profile. An RSA-PSS anchor is RSASSA-PSS [RFC8017] with SHA-256 as the message hash, MGF1 with SHA-256 as the mask generation function, and a salt length of exactly 32 bytes (the hash length), over the raw 32-byte anchorDigest like every other algorithm. The key's modulus MUST be at least 2048 bits. A verifier MUST NOT recover the salt length from the signature or accept any other salt length, and MUST refuse a smaller key: both are properties of the signature scheme, and a verifier that auto-detects them verifies anchors that another conformant verifier refuses. Note that common signing APIs default to the MAXIMUM salt length (Node.js, OpenSSL); a producer MUST set the salt length explicitly.¶

ECDSA signature encoding. Producers MUST emit ES256 anchor signatures in ASN.1/DER, the encoding the reference producer emits and the golden vectors pin. Verifiers MUST accept both ASN.1/DER and raw IEEE-P1363 (r ‖ s, 64 bytes for P-256). Do NOT infer the encoding from length: a DER signature whose r and s both happen to be short is also 64 bytes, so a length switch mis-rejects valid DER. Attempt both encodings and accept if either verifies. Accepting only DER is non-conformant: §5.3 exists to admit anchors from issuers the producer does not control, and a WebCrypto-based issuer can emit only P1363 — refusing those makes a genuine third-party anchor read as an invalid signature in one implementation while counting toward quorum in another. Both encodings are pinned by the signedAnchor vectors.¶

5.3 Anchor Trust, Quorum & Key Discovery

A verifier evaluates anchors against a local anchor policy:¶

NOTE: '\' line wrapping per RFC 8792

{
  "requiredAnchors": 2,
  "trustedIssuers": ["https://transparency.example.org", "https://an\
  chor.example.net"],
  "quorum": "ALL_MUST_AGREE"
}

anchorVerified is true only if the policy is satisfied.¶

Time bound. An external anchor proves only that its witness saw the digest at the witness's own authenticated time — Rekor's integratedTime, an RFC 3161 token's genTime. An anchor first witnessed long after the checkpoint claims to exist says nothing about whether the checkpoint existed then, and it is exactly what re-anchoring a rewritten old root produces. A verifier MUST therefore compare each external witness time with the anchor's signed timestamp (the checkpoint's claimed time) and MUST NOT count an anchor witnessed more than maxAnchorLagSeconds after it, or more than a small clock-skew tolerance before it (the reference implementations allow 300 seconds). The verdict MUST say why such an anchor did not count, and SHOULD expose each issuer's witness time whether or not it counted. SELF anchors carry no independent time and are not subject to the bound. A producer SHOULD obtain external anchors promptly after committing a checkpoint; one whose anchoring stalled beyond the bound stays verifiable only to a relying party that deliberately widens it.¶

The bound is only as good as the checkpoint time it is measured against, and the anchor's own timestamp is chosen by the producer. A verifier MUST therefore take that time from the checkpoint the anchor is counted for (below), and MUST NOT count an external witness for a checkpoint whose claimed time it does not know: a checkpoint that states no anchoredAt or chainHash MUST NOT be reported as anchored (divergence is still evaluated), and a single inclusion proof, which carries no checkpoint (§6.2), MUST NOT count an external anchor unless the caller supplies the checkpoint's record.¶

Position. Where the verifier knows the checkpoint an anchor is counted for — an evidence bundle's checkpoints[] entry, §6.3, or a caller-trusted checkpoint record — it MUST NOT count an anchor whose signed seqStart, seqEnd, chainHash or timestamp differs from that checkpoint's seqStart, seqEnd, chainHash or anchoredAt, and it MUST NOT read such an anchor as divergence: it names another checkpoint. (The chain hash and claimed time are the exception for divergence. Both commit to the root, so a checkpoint rewritten with a different root necessarily states a different chain hash and usually a different time; a caller-obtained anchor for the same seq range that differs in them is exactly the conflicting evidence divergence exists to expose, and a verifier MUST NOT discard it for that difference alone.) A caller-trusted checkpoint record — normally the chain-verified line of the roots file (§5.4.1) for the checkpoint's root — takes precedence over the bundle's copy: a verifier given one MUST hold anchors to the record's fields where it states them, and MUST fail a bundle whose checkpoint states a different seqStart, seqEnd, entryCount, anchoredAt or chainHash for the same root. A bundle alone can re-date a checkpoint with a self-consistent chain hash over an invented predecessor; only a record the verifier already holds exposes that.¶

Rekor submitter. Rekor logs a hashedrekord under whatever key submits it, and the anchor digest is computed from public fields, so anyone can have any digest logged. A verifier that knows the producer's anchor key (§5.3 key discovery) SHOULD pin it and count a Rekor entry only when its publicKey is that key and its signature over the anchor digest verifies. The time bound, not the pin, is what defeats back-dated re-anchoring; the pin removes third parties from the picture.¶

What this does and does not establish. With the time bound and position binding, an anchored checkpoint cannot be rewritten after the bound has passed without every later anchor failing, because each binds the chain hash that commits to it. A party able to rewrite the log AND re-date every checkpoint from the edited one onward to "now" can still produce a self-consistent export; what exposes it is a roots file or earlier export retained by anyone (§5.4.1), whose chain hashes the rewrite cannot reproduce, and the months-long gap between the re-dated checkpoints and the leaf-committed createdAt of the events under them. In either quorum mode, fatal divergence can be established only from anchors the verifier obtained itself per checkpoint (out of band or through discovery), never from a bundle-carried set; valid same-root bundle anchors may still count toward quorum under verifier-trusted keys (§6.3). Divergence evidence MUST also satisfy the rules an anchor must satisfy to count toward quorum: its signed seq range MUST be the checkpoint's, an external witness time MUST lie within the time bound above of the anchor's own signed timestamp, and a REKOR entry MUST NOT establish divergence unless the verifier pinned the producer's submission key (the Rekor submitter rule above) — without it, anyone can have a digest over a different root logged under a trusted issuer's name and raise a false alarm. A SELF anchor carries no witness time; its signature under the issuer's trusted key is the evidence. If two such trusted issuers sign different roots for the same checkpoint, the verdict is INVALID (divergence), never a silent pick. A single self-hosted anchor (requiredAnchors: 1 from the platform's own issuer) provides tamper-evidence but NOT independent non-repudiation, and the verifier SHOULD surface that distinction.¶

RFC 3161 reference implementation. All five ports provide an optional OpenSSL 3 adapter. The adapter accepts SHA-256, SHA-384 or SHA-512 CMS signer digests and requires the single declared CMS digest algorithm to match the single SignerInfo digest; SHA-1 and MD5 are refused. Its caller-owned trust configuration pins the DER signer certificate's SHA-256 fingerprint to an issuer, supplies trusted CA certificates, and explicitly chooses offline CRL checking or unchecked revocation. CRL mode requires fresh, valid CRLs for the certificate chain at the caller's evaluation time. Unchecked mode makes no revocation assertion. Both modes verify certificate validity at that evaluation time and at the signed genTime; a future genTime is refused. Evaluation defaults to current time rounded up by less than one second. A caller can supply an explicit historical Unix-second evaluation time and retained CRLs; the adapter does not choose historical trust from the token itself. No network trust discovery, OCSP fetching or archival evidence renewal occurs. Unavailable OpenSSL, absent trust, or failed checks contribute zero issuers and produce a diagnostic note. Only caller-attributed evidence can establish divergence, including RFC 3161 evidence.¶

These adapters have no additional language-package dependencies but require the OpenSSL 3 executable. Their positive and negative cases are shared in rfc3161-vectors.json. They do not imply the complete Extended Profile: NDJSON evidence streaming remains outside the current implementation.¶

Verifiers MUST discover trusted anchor public keys via:¶

1. Static SPKI / JWKS public key configuration supplied to the verifier, OR¶

2. HTTPS Well-Known discovery endpoint at {issuer}/.well-known/dewp-anchors.json.¶

Anchor objects MUST carry a keyId referencing the active SPKI public key.¶

5.4 Checkpoint Continuity Chain (0x04 Domain Tag)

An inclusion proof binds an event to one daily root. It says nothing about whether the sequence of daily roots was rewritten: a published roots file with one day silently replaced or removed is internally consistent and verifies fine. Producers therefore SHOULD link each checkpoint to its predecessor.¶

The canonical chain preimage is the RFC 8785 JCS serialization of a 6-element array of strings:¶

[prevChainHash, root, seqStart, seqEnd, entryCount, anchoredAt]

chainHash = sha256Hex(byte(0x04) || UTF8Bytes(chainPreimage)).¶

Rules:¶

• Every element MUST be a JSON string, including seqStart, seqEnd and entryCount. For an array of strings JCS reduces to plain JSON.stringify, so no implementation has to reproduce RFC 8785 number canonicalization — the part of JCS where independent verifiers most often drift. §5.2 makes the same trade for the same reason.¶

• prevChainHash for the first checkpoint MUST be the empty string "". No real chain hash can collide with it, since those are always 64 hex characters, so a verifier that reaches a "" predecessor knows it is at the genuine start of the log and not at a truncation point.¶

• anchoredAt MUST be the same instant recorded on the checkpoint, ISO 8601 UTC with millisecond precision and a literal Z (§4.3).¶

• Verifiers MUST check both that each entry's chainHash recomputes and that its prevChainHash equals its predecessor's chainHash. Recomputation alone does not detect a deleted entry.¶

Transport of the chain. The chain is verifiable only over a source that carries chainHash and prevChainHash per checkpoint — normally the published roots file (§5.4.1). The Evidence Bundle of §6.3 carries both, with entryCount, for each checkpoint it includes, so a bundle-only verifier can recompute each checkpoint's chain hash and hold its anchors to it (§5.3). It cannot check that the sequence of daily roots is unbroken: a bundle carries only the checkpoints its entries fall under, which are rarely consecutive. For continuity, an auditor MUST obtain the chain from the roots file.¶

NOTE: '\' line wrapping per RFC 8792

{"seqStart":"1","seqEnd":"10000","entryCount":10000,"root":"<64-hex>\
  ","anchorRef":"<publication receipt>","anchoredAt":"2026-07-15T00:\
  00:00.000Z","prevChainHash":"","chainHash":"<64-hex>"}

6.1 Algorithm Registry Object

All DEWP proof containers SHOULD carry an algorithmRegistry metadata block:¶

{
  "hashAlgorithm": "SHA-256",
  "serialization": "RFC8785-JCS",
  "merkleVersion": 1,
  "signatureAlgorithms": ["ES256", "WEBAUTHN", "AUTO_APPROVED"]
}

6.2 Single Inclusion Proof Bundle Schema (dewp.audit.inclusion-proof)

The event.canonical object carries the raw JSON values exported by the producer. In particular, metadata is the parsed JSON value (or null when absent), not a pre-serialized JCS string. When rebuilding the ordered preimage, the verifier converts that raw value into the compact JCS string required at §4.2 index 5.¶

The example uses the registered trust.intyga.audit.v1 profile and therefore carries its six extension fields before the final tenantSeq, for an 18-element preimage.¶

NOTE: '\' line wrapping per RFC 8792

{
  "protocol": "DEWP",
  "version": "1.0",
  "kind": "dewp.audit.inclusion-proof",
  "profile": "trust.intyga.audit.v1",
  "exportedAt": "2026-07-24T12:30:00.000Z",
  "verificationLevel": "CONTENT_VERIFIED",
  "algorithmRegistry": {
    "hashAlgorithm": "SHA-256",
    "serialization": "RFC8785-JCS",
    "merkleVersion": 1
  },
  "event": {
    "seq": "1048576",
    "id": "0190e3f2-1a2b-7c3d-8e4f-5a6b7c8d9e0f",
    "createdAt": "2026-07-24T12:00:00.000Z",
    "type": "ACTION_APPROVED",
    "outcome": "SUCCESS",
    "detail": "Database drop approved",
    "actorDid": "did:example:human:alice",
    "subjectDid": null,
    "signerDid": "did:example:human:alice",
    "signature": "base64-sig",
    "sigAlg": "ES256",
    "canonical": {
      "seq": "1048576",
      "createdAt": "2026-07-24T12:00:00.000Z",
      "event": "ACTION_APPROVED",
      "outcome": "SUCCESS",
      "detail": "Database drop approved",
      "metadata": { "target": "users" },
      "signerDid": "did:example:human:alice",
      "signerPublicKey": "base64-spki",
      "signedPayload": "{\"actionType\":\"db:dropTable\",\"display\"\
  :\"...\",\"type\":\"div-intent-verification\",\"v\":1}",
      "signature": "base64-sig",
      "sigAlg": "ES256",
      "isBillable": true,
      "tenantId": "tenant-uuid-01",
      "actorNodeId": "node-uuid-alice",
      "subjectNodeId": null,
      "edgeId": null,
      "challengeId": "challenge-uuid-01",
      "tenantSeq": "42"
    }
  },
  "proof": {
    "seq": "1048576",
    "leaf": "d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a\
  1b2c3d4e5",
    "blockIndex": "0",
    "blockRoot": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1\
  b2c3d4e5f6a1b2",
    "blockProof": [
      { "siblingHash": "f1e2d3c4b5a6f1e2d3c4b5a6f1e2d3c4b5a6f1e2d3c4\
  b5a6f1e2d3c4b5a6f1e2", "siblingPosition": "RIGHT" }
    ],
    "leafIndex": 0,
    "blockLeafCount": 2,
    "checkpointId": "cp-uuid-01",
    "checkpointRoot": "e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c3d2e1f0a9b8c\
  7d6e5f4a3b2c1d0e9f8",
    "checkpointProof": [
      { "siblingHash": "c4b3a2f1e5d6c4b3a2f1e5d6c4b3a2f1e5d6c4b3a2f1\
  e5d6c4b3a2f1e5d6c4b3", "siblingPosition": "LEFT" }
    ],
    "checkpointLeafIndex": 1,
    "checkpointLeafCount": 2,
    "anchorRef": "https://transparency.example.org/roots/2026-07-24.\
  json",
    "anchored": true,
    "externallyAnchored": true,
    "externallyAnchoredRequired": 2
  },
  "anchor": {
    "dailyRoot": "e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c3d2e1f0a9b8c7d6e5\
  f4a3b2c1d0e9f8",
    "timestamp": "2026-07-24T23:59:00.000Z",
    "issuer": "https://transparency.example.org",
    "keyId": "key-2026-01",
    "algorithm": "ES256",
    "seqStart": "1048576",
    "seqEnd": "1049600",
    "chainHash": "6ae54abac75d273317f9f369306f2fbe85f2fafc9dd30685dc\
  4f8a375257ef2b",
    "signature": "base64-anchor-signature",
    "anchorRef": "https://transparency.example.org/roots/2026-07-24.\
  json",
    "anchored": true
  },
  "anchors": [
    {
      "dailyRoot": "e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c3d2e1f0a9b8c7d6\
  e5f4a3b2c1d0e9f8",
      "timestamp": "2026-07-24T23:59:00.000Z",
      "issuer": "https://transparency.example.org",
      "keyId": "key-2026-01",
      "algorithm": "ES256",
      "seqStart": "1048576",
      "seqEnd": "1049600",
      "chainHash": "6ae54abac75d273317f9f369306f2fbe85f2fafc9dd30685\
  dc4f8a375257ef2b",
      "signature": "base64-anchor-signature"
    }
  ]
}

Two anchoring flags appear in a proof, and they mean different things — both are producer claims a verifier reports for display and never treats as proof (the §5.3 quorum over the signed anchors is the check):¶

• anchored — a publication receipt (anchorRef) exists. The reference producer writes one for every checkpoint at commit time, so this is COMMITMENT only and structurally always true for a checkpointed proof; it MUST NOT be read as independence.¶

• externallyAnchored — the producer claims a §5.3 external anchor quorum exists for this root: at least externallyAnchoredRequired DISTINCT INDEPENDENT issuers hold an anchor over it. Distinct issuers, not anchor rows — re-anchoring under a rotated key is one opinion. "Independent" excludes both the producer's own SELF anchor and any WEBHOOK receipt, because a webhook endpoint is operated by the producer and is therefore not a second opinion.¶

• externallyAnchoredRequired — the quorum size the claim above was evaluated against. Producers SHOULD emit it whenever they emit externallyAnchored, and verifiers SHOULD surface it wherever they surface the flag: without it the boolean cannot be read, since a deployment requiring one issuer and a deployment requiring three publish the same true. Counting the anchors array is not a substitute — the array may be absent, and its length is the count ACHIEVED rather than the count REQUIRED. Both fields remain producer claims; anchorVerified (§7.1) is the check.¶

The single anchor field alongside the anchors array is a legacy convenience (the first entry of the set); the array is what the §5.3 quorum rule is evaluated over, and the published JSON Schema governs where this example and the schema disagree (§6).¶

A single proof carries no checkpoint record, so it gives the verifier no position or claimed time to hold an anchor to. An external (REKOR, RFC3161) anchor therefore counts toward anchorVerified only when the caller supplies the proof's checkpoint record — the roots-file line for its root (§5.4.1) — and the anchor is then held to that record's range, chain hash and anchoredAt (§5.3). A record naming a different root than the caller's trustedRoot MUST fail the proof. Where the record carries entryCount, the proof's leaf counts MUST be consistent with it (§17.3).¶

6.3 Multi-Entry Evidence Bundle Schema (dewp.audit.evidence-bundle)

NOTE: '\' line wrapping per RFC 8792

{
  "protocol": "DEWP",
  "version": "1.0",
  "kind": "dewp.audit.evidence-bundle",
  "exportedAt": "2026-07-24T12:30:00.000Z",
  "tenant": { "id": "tenant-uuid-01", "name": "Acme Corp" },
  "range": { "from": "2026-07-01T00:00:00.000Z", "to": "2026-07-24T2\
  3:59:59.000Z" },
  "tenantSequenceCommitment": {
    "tenantId": "tenant-uuid-01",
    "firstTenantSeq": "1",
    "lastTenantSeq": "42"
  },
  "entries": [
    {
      "event": {
        "seq": "1048576",
        "createdAt": "2026-07-24T12:00:00.000Z",
        "type": "ACTION_APPROVED",
        "outcome": "SUCCESS",
        "redaction": { "mode": "NONE" },
        "signerDid": "did:example:human:alice",
        "sigAlg": "ES256",
        "canonical": { "seq": "1048576", "tenantSeq": "42" }
      },
      "proof": { "seq": "1048576", "leaf": "d4e5f6...", "blockRoot"\
  : "...", "checkpointRoot": "..." }
    },
    {
      "event": {
        "seq": "1048577",
        "createdAt": "2026-07-24T12:05:00.000Z",
        "type": "USER_DELETED",
        "outcome": "SUCCESS",
        "redaction": {
          "mode": "COMMITMENT_ONLY",
          "removedFields": ["detail", "metadata", "signedPayload", "\
  signature", "signerPublicKey"],
          "redactedAt": "2027-01-15T09:00:00.000Z",
          "reason": "gdpr-erasure",
          "commitment": {
            "leaf": "b9a8c7d6e5f4b9a8c7d6e5f4b9a8c7d6e5f4b9a8c7d6e5f\
  4b9a8c7d6e5f4b9a8",
            "tenantSeq": "43"
          }
        },
        "signerDid": null,
        "sigAlg": null
      },
      "proof": { "seq": "1048577", "leaf": "b9a8c7d6e5f4b9a8c7d6e5f4\
  b9a8c7d6e5f4b9a8c7d6e5f4b9a8c7d6e5f4b9a8", "blockRoot": "...", "ch\
  eckpointRoot": "..." }
    }
  ],
  "checkpoints": [
    {
      "id": "cp-uuid-01",
      "root": "e9f8a7...",
      "anchorRef": "https://transparency.example.org/roots/2026-07-2\
  4.json",
      "anchoredAt": "2026-07-24T23:59:00.000Z",
      "seqStart": "1048576",
      "seqEnd": "1049600",
      "entryCount": 1025,
      "prevChainHash": "",
      "chainHash": "6ae54abac75d273317f9f369306f2fbe85f2fafc9dd30685\
  dc4f8a375257ef2b",
      "externallyAnchored": true,
      "externallyAnchoredRequired": 2,
      "anchors": [
        {
          "dailyRoot": "e9f8a7...",
          "timestamp": "2026-07-24T23:59:00.000Z",
          "issuer": "https://rekor.sigstore.dev",
          "keyId": "rekor-2026",
          "algorithm": "ES256",
          "seqStart": "1048576",
          "seqEnd": "1049600",
          "chainHash": "6ae54abac75d273317f9f369306f2fbe85f2fafc9dd3\
  0685dc4f8a375257ef2b",
          "signature": "",
          "kind": "REKOR",
          "evidence": "base64-rekor-set-and-inclusion-proof"
        }
      ]
    }
  ]
}

Each checkpoint entry carries seqStart / seqEnd, the global sequence range it commits, its §5.4 chain fields entryCount / prevChainHash / chainHash, and its own anchors array — the per-checkpoint anchor set the §5.3 quorum rule is evaluated over. A bundle that reports only a single top-level anchor cannot express quorum, so the array is where independence is actually assessed. A verifier supplied with an anchor policy and key resolver but no anchors of its own MAY evaluate quorum over this array — the signatures still verify only under keys the VERIFIER trusts, so a bundle cannot vouch for itself — but bundle-carried anchors MUST NOT be able to establish the fatal divergence verdict of §5.3, which requires anchors the verifier fetched per checkpoint itself (the producer chooses what a bundle carries). A verifier MUST recompute each checkpoint's chainHash from its prevChainHash, root, seqStart, seqEnd, entryCount and anchoredAt and fail the bundle when it does not recompute, and MUST hold every anchor to that checkpoint's position and claimed time (§5.3). externallyAnchored is the producer's §5.3 quorum claim for the checkpoint (distinct INDEPENDENT issuers — neither SELF nor WEBHOOK — ≥ externallyAnchoredRequired, which SHOULD be emitted beside it) — display only, per the §6.2 note; anchoredAt is the checkpoint's commit instant (self-commitment time), not evidence of external anchoring. A checkpoint that carries anchors but states no chainHash or anchoredAt — and has no caller-trusted record supplying them — MUST NOT be reported as anchored (§5.3); stripping those fields is exactly how a producer would switch off the time bound.¶

Entry-level rules, in addition to §7 and §7.2:¶

• Each committed event appears at most once. A verifier MUST fail an entry whose proof.leaf or seq already appeared in the bundle; otherwise one genuine event can fill two positions.¶

• blockLeafCount and checkpointLeafCount are properties of a tree, so every proof into the same blockRoot (respectively checkpoint root) MUST state the same value, and both MUST be consistent with the checkpoint's entryCount (caller record first, then the bundle's chain-verified value; §17.3).¶

• An entry that ships a preimage under an unrecognised profile MUST fail (§4.5); its counter is not read.¶

• The tenant rule of §7.2 applies.¶

A bundle also carries profile, algorithmRegistry and howToVerify at the top level. profile names the leaf profile in force (§4.5), algorithmRegistry pins the algorithm identifiers (§12), and howToVerify is a human-readable instruction string carrying no normative weight.¶

6.4 Streaming Evidence Export Schema (dewp.audit.evidence-stream)

Specified, not implemented. As of 31 Jul 2026 no producer emits this form and no verifier in this repository reads it — including the TypeScript reference implementation. The format below is normative for anyone who chooses to implement it, but nothing here claims DEWP Extended Profile conformance (§9.2), and no INTYGA surface streams evidence. Use dewp.audit.evidence-bundle (§6.3), which is implemented end to end.¶

For multi-gigabyte log exports, implementations SHOULD stream evidence formatted as JSON Lines (NDJSON).¶

Line 1 (Header Object):¶

NOTE: '\' line wrapping per RFC 8792

{"protocol":"DEWP","version":"1.0","kind":"dewp.audit.evidence-strea\
  m","exportedAt":"2026-07-24T12:30:00.000Z","tenantId":"tenant-uuid\
  -01"}

Line 2..N (Entry Objects):¶

NOTE: '\' line wrapping per RFC 8792

{"type":"entry","seq":"1048576","tenantSeq":"42","leaf":"d4e5f6...",\
  "canonical":[...],"proof":{...}}

Line N+1 (Trailer Commitment Object):¶

NOTE: '\' line wrapping per RFC 8792

{"type":"trailer","seqStart":"1","seqEnd":"42","entryCount":42,"chec\
  kpointRoot":"e9f8a7..."}

6.5 Kind Values

The canonical kind values are dewp.audit.inclusion-proof, dewp.audit.evidence-bundle, and dewp.audit.evidence-stream. A compliant DEWP producer MUST emit these forms and a compliant verifier MUST reject any other value. There are no vendor-prefixed aliases: kind names the protocol, never the implementer.¶

7.1 Verification Properties and Derived Level

A verifier MUST evaluate four independent boolean properties. They are orthogonal — in particular, anchor verification is NOT a strict superset of signature verification (a content-only event with no signer can still be anchor-verified; a signed event can be content-and-signature-verified without any anchor):¶

A bundle MAY carry a summary verificationLevel for display, but conformant verifiers MUST also expose the four properties so a Relying Party can apply its own policy. The summary level is derived as:¶

• INVALID : commitmentVerified == false (inclusion or leaf-hash recomputation failed), OR anchor divergence was detected.¶

• COMMITMENT_VERIFIED : commitmentVerified only (redacted / commitment-only entry).¶

• CONTENT_VERIFIED : commitmentVerified && contentVerified.¶

• SIGNATURE_VERIFIED : contentVerified && signatureVerified.¶

• FULLY_VERIFIED : all required properties for the entry passed and anchorVerified. For a signed event that is contentVerified && signatureVerified && anchorVerified; for an unsigned event that is contentVerified && anchorVerified (no signature is required to exist).¶

A Relying Party MUST NOT treat SIGNATURE_VERIFIED as implying independent non-repudiation: without anchorVerified the root is still only vendor-asserted.¶

7.2 Check 6 — Tenant Sequence Continuity: Source, Disclosure, Declared Range

An Evidence Bundle carries tenantSeq in up to three places per entry, and only one of them is covered by the Merkle commitment:¶

1. A verifier MUST read the counter from canonical.tenantSeq for every entry that carries a Canonical Preimage, and from nowhere else: a null there means the entry has no counter (rule 5), never "fall back". Preferring the display copy is a conformance failure, not an implementation shortcut: a producer that drops the incriminating events, keeps the honest ones with their genuine proofs, and renumbers the display copies to close the hole yields a bundle that passes such a check reporting no gap — which forfeits §17.2 outright. Falling back to the redaction record for a preimage whose counter is null is the same failure: a genuine tenant-less leaf, tagged with an unsigned redaction.commitment.tenantSeq, then fills the hole while counting as content-verified. (A preimage the verifier could not bind to its leaf — an entry under an unrecognised Application Profile, §4.5 — is not leaf-bound either; in an Evidence Bundle such an entry fails, and its counter is not read.)¶

2. Only where an entry has no preimage — a COMMITMENT_ONLY entry, whose content was lawfully purged — the verifier MAY fall back to redaction.commitment.tenantSeq, and then to event.tenantSeq. Without a fallback the position lawful redaction leaves behind would read as an omission.¶

3. Where a preimage IS present, the verifier MUST compare event.tenantSeq and redaction.commitment.tenantSeq, when present, against canonical.tenantSeq and fail the entry when either differs. The same applies to every other field duplicated alongside the preimage (seq, createdAt, type, outcome, signerDid, sigAlg): the displayed copy is what a human, a console or a SIEM reads, so an unchecked one is a caption over the evidence rather than part of it.¶

4. A verifier that read any counter under rule 2 MUST disclose it in its verdict. Continuity across values that are not leaf-bound rests on the producer's redaction record, not on the anchored log, and a Relying Party cannot tell that from a bare pass.¶

5. An entry carrying no tenantSeq in any of the three locations — or a preimage whose tenantSeq is null — MUST NOT be treated as continuous with its neighbours: it occupies no counter position, and the verifier MUST disclose that gaplessness could not be checked across it.¶

6. tenantSeq is a per-tenant counter, so contiguity is meaningful only over one tenant's entries. Every content-verified entry whose canonical.tenantId is non-null MUST equal tenant.id; a bundle whose tenant is absent or has a null id declares no tenant, and any entry naming one MUST fail. (Otherwise one tenant's genuine, leaf-bound counters splice into another's gap.)¶

9.1 DEWP Core Profile

Requires implementation of:¶

• RFC 8785 JCS 12-element canonical array serialization (Section 4.1).¶

• Domain-separated Merkle leaf and node hashing (Section 4.4).¶

• Single inclusion proof verification (dewp.audit.inclusion-proof).¶

The 0x04 checkpoint continuity chain (§5.4) is outside Core: it belongs to the roots-file transport, not to inclusion verification. The repository's TypeScript, Python, Go, Rust and Java verifiers implement it alongside the Core primitives. External implementations that omit it SHOULD state that limit explicitly.¶

9.2 DEWP Extended Profile

Requires implementation of DEWP Core plus:¶

• Multi-entry evidence bundle verification with tenantSeq gapless validation (dewp.audit.evidence-bundle).¶

• NDJSON evidence streaming (dewp.audit.evidence-stream) — see the §6.4 note: specified but unimplemented, so no implementation claims this profile.¶

• Signed multi-anchor verification with 0x03 domain tag (Section 5.2 & 6.2).¶

• Offline event-signature verification of embedded intent-proof material (Sections 1.3 & 7.1), evaluated per entry in a multi-entry bundle as well as for a single inclusion proof. Only signature material a leaf carries in full is checkable offline: ES256 over signedPayload, or a WEBAUTHN assertion when the Application Profile carries authenticatorData and clientDataJSON and the caller supplies signer trust, expected origin and RP ID (§4.6.1). Missing material/trust is reported as not checked; AUTO_APPROVED has no human signature and is not applicable. A caller may require trusted signatures as an additional acceptance policy. An entry whose committed signature does not verify MUST be reported, but MUST NOT by itself invalidate the entry's commitment or content verification — the signature bytes are themselves committed, so a failure there means the producer anchored proof material that does not check out, not that the bundle was altered.¶

• Support for Application Profile Extensions (Section 4.5).¶

11.1 Why Bounds Are Mandatory

Recomputing the root from a leaf and a sibling path is not sufficient to establish membership in this tree, and an implementation that stops there is non-conformant.¶

§5.1.3 pads an unpaired trailing node by hashing it against itself. Therefore merkleRoot([a,b,c]) and merkleRoot([a,b,c,c]) are equal, and a path constructed for the nonexistent index 3 recomputes the 3-leaf root exactly. A verifier with no index and no leaf count has nothing to reject it with, which falsifies §17.1's claim that forging an inclusion path requires a SHA-256 second preimage.¶

A verifier MUST therefore be given, and MUST check, the leaf's index and the tree's leafCount. Three checks follow, and all three are required:¶

1. Range — 0 ≤ index < leafCount.¶

2. Path length — proof.length MUST equal ceil(log2(leafCount)), or 0 when leafCount ≤ 1.¶

3. Self-pairing — a node hashed against itself is legitimate only at the unpaired end of an odd-sized level. Any other self-paired step MUST be rejected.¶

Check 3 is what actually closes the forgery. leafCount arrives inside the proof, so a prover can inflate it: claiming leafCount = 4 on a 3-leaf tree puts index 3 in range and makes the path length correct, and the duplicate-last root is identical — so range and length alone still accept it. Padding is observable, however: a sibling equal to the running node anywhere except the unpaired end of an odd level is the signature of an index pointing into padding.¶

Sibling side MUST also be derived from the index rather than read from the proof. Letting the prover choose each side freely restores the flexibility the length check just removed.¶

11.2 Reference Implementation

NOTE: '\' line wrapping per RFC 8792

export interface ProofStep {
  siblingHash: string                 // digest of the sibling node
  siblingPosition: "LEFT" | "RIGHT"   // side the SIBLING sits on, r\
  elative to the running node
}

/** Position of the leaf this proof is for, and how many leaves its \
  tree had. REQUIRED. */
export interface ProofBounds {
  index: number
  leafCount: number
}

export function expectedPathLength(leafCount: number): number {
  return leafCount <= 1 ? 0 : Math.ceil(Math.log2(leafCount))
}

export function verifyMerkleProof(
  leafHex: string,
  proof: ProofStep[],
  rootHex: string,
  bounds: ProofBounds
): boolean {
  const { index, leafCount } = bounds
  if (!Number.isInteger(index) || !Number.isInteger(leafCount)) retu\
  rn false
  if (leafCount < 1 || index < 0 || index >= leafCount) return false
  if (proof.length !== expectedPathLength(leafCount)) return false

  let idx = index
  let levelSize = leafCount
  let node = leafHex
  for (const step of proof) {
    // The side follows from the index; a prover-chosen side is not \
  accepted.
    const expectedSide = idx % 2 === 1 ? "LEFT" : "RIGHT"
    if (step.siblingPosition !== expectedSide) return false

    // Self-pairing is legitimate ONLY at the unpaired end of an odd\
  -sized level.
    const selfPaired = step.siblingHash === node
    const legitimatelyUnpaired = idx === levelSize - 1 && levelSize \
  % 2 === 1
    if (selfPaired && !legitimatelyUnpaired) return false

    const siblingIsLeft = step.siblingPosition === "LEFT"
    const left = siblingIsLeft ? hexDecode(step.siblingHash) : hexDe\
  code(node)
    const right = siblingIsLeft ? hexDecode(node) : hexDecode(step.s\
  iblingHash)
    node = hexEncode(sha256(concat(byte(0x01), left, right)))

    idx = Math.floor(idx / 2)
    levelSize = Math.ceil(levelSize / 2)
  }
  return node === rootHex
}

11.3 Two-Hop Inclusion

An event is committed under a daily root in two hops: event leaf → block root, then block root → daily root. The daily tree's leaves are hashLeaf(blockRoot), so the block root MUST be re-wrapped with the leaf tag (0x00) before the second hop.¶

NOTE: '\' line wrapping per RFC 8792

export function verifyInclusionProof(proof: InclusionProof, dailyRoo\
  t: string): boolean {
  if (
    !Number.isInteger(proof.leafIndex) ||
    !Number.isInteger(proof.blockLeafCount) ||
    !Number.isInteger(proof.checkpointLeafIndex) ||
    !Number.isInteger(proof.checkpointLeafCount)
  ) return false

  if (!verifyMerkleProof(proof.leaf, proof.blockProof, proof.blockRo\
  ot, {
    index: proof.leafIndex, leafCount: proof.blockLeafCount,
  })) return false

  return verifyMerkleProof(hashLeaf(proof.blockRoot), proof.checkpoi\
  ntProof, dailyRoot, {
    index: proof.checkpointLeafIndex, leafCount: proof.checkpointLea\
  fCount,
  })
}

For any verdict a Relying Party acts on, dailyRoot MUST be a root the Relying Party obtained independently of the proof — one it recorded earlier, or one from the published roots file whose chain it has verified (§5.4.1). It cannot be taken from an external anchor, which holds only a digest committing to the root (§3 Invariant 6). Trusting the root carried inside the proof lets a forged bundle vouch for itself, which defeats the entire construction, so a result computed against proof.checkpointRoot MUST NOT be reported as trusted, anchored, or non-repudiable, and MUST NOT on its own produce an overall pass. Running this same function against proof.checkpointRoot to establish commitmentVerified (§7.1) — internal consistency, when no root was supplied — is permitted, provided the verifier reports the root's provenance alongside the result; the reference implementations expose it as rootSource: "self-asserted", and a supplied root as rootSource: "caller-supplied" — never "independent", since the verifier cannot know where the caller got it.¶

12.1 Hash Algorithm Migration Procedure

If hashAlgorithm is upgraded to SHA3-256 or BLAKE3:¶

1. The new algorithm identifier MUST be announced in the algorithmRegistry.¶

2. Historical blocks signed under SHA-256 MUST remain verifiable without re-hashing past checkpoint roots.¶