KYE DSAR Evidence Pack™ · constitution §31 · GDPR Art. 15

A subject access response your regulator can re-verify offline.

A KYE DSAR Evidence Pack™ is a signed bundle of every audit-chain entry involving a named data subject across the configured window, with the dsar-handling rule pack's inclusion / confidence / exclusion / redaction decisions applied. The requesting subject (or their counsel, or the supervisory authority) verifies the pack offline using only the controller's published JWKS — no controller cooperation required.

rocket_launch Apply for pilot → menu_book Read the docs

Why DSAR responses get challenged

In a typical SaaS posture, the controller hand-assembles a DSAR response from a SQL export, a CSV from a CRM, and a screenshot of a permissions screen. The subject (and increasingly, the supervisory authority) cannot independently verify:

  • that every audit-chain row mentioning the subject was actually considered;
  • that no row was silently omitted because it was inconvenient;
  • that the redactions are principled (third-party rights under GDPR Art. 15(4)) rather than expedient;
  • that the response would be identical if reassembled tomorrow from the same data.

A KYE DSAR Evidence Pack™ closes all four gaps in one bundle.

What's in the pack

Schema: kye.dsar_evidence_pack.v1. Reference example: github.com/KYE-Protocol/examples/dsar-evidence-pack.json ↗.

  • Pack header — pack_id, subject_request_id (your case-management ticket), subject_ref_hash (SHA-256 of the subject reference; the raw value never leaves your audit chain).
  • Window — inclusive (from / to) search window. Default `from` is the tenant retention floor; default `to` is `issued_at`.
  • Inclusion policy — inclusion_min_confidence, third_party_redaction (`full` / `field_level` / `none`), exclude_classifications (e.g. security_monitoring rows that would prejudice an investigation under GDPR Art. 23).
  • evidence_rows — one entry per included audit-chain row. Sorted ascending by occurred_at for deterministic content_hash. Each row carries the original decision_id (joinable back to the Decision Map™), the asset_id touched, action / classification / purpose, decision, the per-field redactions_applied with reason codes, and the evidence_pack_id for the full Evidence Pack™.
  • excluded_rows_summary — aggregate count + reason_code_distribution. The subject sees that N rows were considered and excluded, without seeing the row contents. Defence-in-depth against silent omission.
  • summary — assets_touched, actions_taken, decision_distribution.
  • content_hash — SHA-256 over the RFC-8785 JCS canonical form of the pack minus the signature field. Byte-stable.
  • signature — Ed25519 detached signature by a KID resolvable in your published JWKS.

The 5-rule assembly pipeline

Rule pack: dsar-handling. Constitution §31 §2 (#12). 5 rules, deterministic order.

  1. dsar_include_if_subject_ref_matches — first-pass selector. Any audit-chain row whose data_subject_ref.ref_value_hash equals the request's subject_ref_hash is a candidate.
  2. dsar_exclude_if_below_inclusion_confidence — drop candidates whose match_confidence falls below inclusion_policy.inclusion_min_confidence. Counted in excluded_rows_summary with reason dsar_inclusion_threshold_not_met.
  3. dsar_exclude_if_classification_excluded — drop candidates whose classification is in inclusion_policy.exclude_classifications (GDPR Art. 23 restrictions). Counted in excluded_rows_summary.
  4. dsar_redact_third_party_fields — apply per-field redaction_strategy (drop / partial_mask / tokenise / preserve_only_for_subject) from the asset's pii_inventory to any field whose subject differs from the requester. GDPR Art. 15(4). Recorded in row.redactions_applied with reason dsar_third_party_redacted.
  5. dsar_require_signed_pack — assembly-completion gate. Refuse delivery if content_hash + Ed25519 signature absent or malformed.

How a subject verifies the pack offline

Same posture as the regulator probe playbook, scoped to a single subject's view.

# 1. Fetch the pack
curl -s https://controller.example/dsar/<pack_id>.json > pack.json

# 2. Fetch the controller's JWKS (always discoverable)
curl -s https://controller.example/.well-known/jwks.json > jwks.json

# 3. Verify the pack signature with the open SDK
npx @kye-protocol/sdk verify-dsar-pack \
  --pack pack.json \
  --jwks jwks.json

# 4. (Optional) for any row in evidence_rows, fetch its parent Evidence Pack
#    and walk the Decision Map for the full authority chain at the time
#    of the decision. Same verifier, no controller cooperation required.

Determinism + replay

Every claim here is backed by the open KYE Protocol™ contracts and verifiable end-to-end from the publisher's JWKS — you check it yourself, you don't take our word for it.

  • Byte-stable content_hash. Re-issue the same pack tomorrow from the same audit-chain state and the bytes match. The DSAR pack is reproducible evidence, not a snapshot rendered fresh each time.
  • Deterministic row ordering. evidence_rows are sorted ascending by occurred_at. Tie-break is by event_id (ascending). No clock-skew, no ordering ambiguity.
  • Canonical JCS encoding. RFC 8785. The same bytes regardless of whether the pack is rendered in TypeScript, Python, Go, or via the open SDK.
  • Replay receipt. Each evidence row keeps its evidence_pack_id pointer; an investigator can re-verify any single decision in the bundle independently of the pack.

Honest limits

Every claim here is backed by the open KYE Protocol™ contracts and verifiable end-to-end from the publisher's JWKS — you check it yourself, you don't take our word for it.

  • We don't discover subjects. The pack is keyed off subject_ref_hash. You produce the hash by salting your identifier and SHA-256-ing; KYE Protocol™ never sees the raw subject identifier.
  • We don't interpret legal basis. If a row should have been refused at decision-time (e.g. consent withdrawn), the Pack records the row + reason. Whether that constitutes a breach is for your DPO / counsel / regulator to decide.
  • We don't decide what to exclude under Art. 23. exclude_classifications is set by the controller, per request, with justification recorded in your case file. KYE™ applies the policy deterministically and reports the count.
  • We don't certify delivery. Pack assembly is offline-verifiable; delivery channel + identity of the requester remain the controller's responsibility.

File a Data Subject Access Request

Free of charge. Acknowledged within 48 hours. Reply via secure delivery within the statutory window for the regime you elect (30 days GDPR / 45 days CCPA / 90 days POPIA).

If you don’t know the controller’s legal name, describe the service.
Used solely for identity verification + DSAR Pack delivery. Hashed at rest (SHA-256). Plain text never persisted.

Or email dsar@kyeprotocol.com directly. We log every request to the per-tenant audit chain and emit a §0.3 evidence event before forwarding to the controller.

Next steps

Every claim here is backed by the open KYE Protocol™ contracts and verifiable end-to-end from the publisher's JWKS — you check it yourself, you don't take our word for it.