]> VERAX TEKNOLOJİ LİMİTED ŞİRKETİ

TR e.dogru@conarium.dev

Security SCITT receipt masking reconciliation transparency disclosure Audit receipts for automated data access attest to what a gateway recorded. Two questions remain outside their reach: what was changed in the data before it was disclosed, and whether the set of receipts is complete with respect to the data source's own accounting of activity. This document defines two evidence structures that answer those questions: Transformation Evidence, a per-disclosure statement of which classes of values were transformed and how, carrying counts and class names but never values; and Coverage Reconciliation, a procedure and result statement that compares a source's own activity counters against a receipt set over a time window and classifies what the comparison establishes. The reconciliation result distinguishes what was matched under a declared correspondence from what was observed without a receipt, receipted without a corresponding observation, excluded before comparison, or left indeterminate; it does not report a bare pass. Both structures are designed to be registered as Signed Statements on a Transparency Service as described in the SCITT architecture. This document defines evidence payloads; it does not define a new receipt format, a new transparency mechanism, or a new signature format.

Introduction Systems that place a policy gateway between an automated client (for example, an AI assistant) and a data source increasingly emit signed, hash-chained access receipts. Several receipt formats exist. They share a property that limits what they can prove: a receipt is evidence produced by the party that performed the access, about an event that party chose to record. Two gaps follow from that property. First, receipts typically state that access happened and under which policy decision, but not what happened to the data between the source and the client. When a gateway masks, redacts, or tokenizes values before disclosure, that transformation is the substance of the privacy claim the operator makes — and it is precisely the part a conventional receipt does not describe. An auditor reading such a receipt learns that a table was read, but not whether the protected columns in it left the gateway transformed or in the clear. Second, a set of receipts, however well chained and anchored, only covers the accesses for which receipts were produced. A client that reaches the data source without passing through the gateway produces no receipt, and no property of the receipt chain reveals this. Hash chains detect removal and reordering of records that exist; they are silent about records that were never created. Establishing completeness requires a second account of activity, produced by a party other than the gateway: the data source itself. This document defines two evidence structures addressing these gaps: Transformation Evidence (): a statement, bound to a single disclosure, of which classes of values were transformed before disclosure, by which action, and in what count. It never carries the values themselves. Coverage Reconciliation (): a procedure that compares snapshots of a data source's own activity counters, taken at the boundaries of a time window, against the receipt set for that window, and a signed result statement classifying each item of either account. The comparison is between two populations, neither assumed complete, under a correspondence the operator declares (); the result distinguishes what was matched from what was observed without a receipt, receipted without an observation, excluded before comparison, or left undecided. Both structures are payloads. They are intended to be carried in Signed Statements and registered on a Transparency Service as described in the SCITT architecture , which supplies the append-only, third-party-auditable registration this document deliberately does not reinvent. This document defines no new receipt format, no policy evaluation semantics, and no transparency mechanism.

What these structures do not claim Both structures are designed around a discipline of stating the limits of their own evidence. Transformation Evidence describes the disclosure surface; it does not claim a value is unlearnable, and it is the Issuer's signed assertion that a transformation was applied rather than proof that it was (). A Coverage Reconciliation result reporting activity without a receipt is a statement about absent evidence; it is not, and MUST NOT be presented as, proof of intent or of a breach (). Neither structure reports a bare pass. A reconciliation computed against an operator-declared correspondence cannot yield an outcome stronger than that declaration (), and an outcome the evidence does not decide is reported as undecided rather than folded into a proportion.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are used throughout:

Data Source:

The system holding the data, with its own accounting of query or access activity (for example, a database's statement statistics).

Gateway:

The component that mediates access between an automated client and a Data Source, applies policy, transforms results, and emits receipts.

Disclosure:

A single delivery of data (possibly transformed) from the Gateway to a client.

Receipt:

A signed record of a Disclosure produced by the Gateway. This document is agnostic to the receipt format in use.

Protected Class:

A named category of values that policy subjects to transformation (for example, "email", "national-id", "phone").

Window:

A time interval over which reconciliation is performed, bounded by two snapshots of the Data Source's activity counters.

Mapping Profile:

A versioned statement, declared by the operator, of the correspondence expected between one client-level operation and the source-level activity it produces — including the bound on that multiplicity and the rules by which activity is excluded from comparison. A Mapping Profile is a declaration about a deployment, not a measurement performed by the Gateway ().

Transformation Evidence

Purpose Transformation Evidence answers, for one Disclosure: which Protected Classes were transformed in the disclosed result, by which action, and in what count. It exists so that the transformation claim is a first-class, signed, registrable artifact rather than prose in an operator's documentation.

Structure Transformation Evidence is a JSON object with the following members:

v:

Structure version string. For this document: transformation-evidence/1.

disclosure:

A digest binding this evidence to exactly one Disclosure, computed over the receipt for that Disclosure (or, where the receipt format defines a canonical record hash, that hash). Digest form is defined in .

request:

A digest of the request that produced the Disclosure. The digest of the request, never the request text: query text can itself contain protected values.

policy:

An object with id (an identifier of the policy version applied) and decision (the policy outcome under which disclosure proceeded).

classes:

An array of objects, one per Protected Class that the applied policy recognizes and that occurred in the disclosed result, each with:

class:

The Protected Class name, as named by the policy.

action:

One of mask, redact, tokenize, truncate, or none. The value none states that the class occurred and was disclosed untransformed — an honest statement some deployments need to make.

count:

The number of values of this class in the disclosed result to which the action was applied.

The structure MUST NOT carry data values, transformed or otherwise. Only class names, action names, counts, digests, and identifiers appear. An implementation encountering a value in a field defined here MUST reject the structure.

Serialization and digests For digesting and signing, the structure is serialized with the JSON Canonicalization Scheme . Digests in this document are SHA-256 and are written as strings prefixed with sha256: followed by lowercase hexadecimal. Future documents may register alternative digest prefixes; an implementation MUST reject a digest whose prefix it does not recognize rather than guessing. A CBOR/COSE serialization of the same data model is expected to be specified once the JSON model has received review; nothing in the model depends on JSON specifically.

What Transformation Evidence does not prove Transformation Evidence describes the disclosure surface of one result. It does not state that a protected value is unlearnable by the client. In particular, where the request language permits predicates over protected columns, an allowed request can answer questions about a masked value without the value ever being disclosed (a result-count of one versus zero is one bit of the value). Transformation Evidence for such a Disclosure is accurate — the value was transformed in the result — and still compatible with the client having learned something about the value. Consumers MUST NOT present Transformation Evidence as proof of non-exposure. Nor is it proof that the transformation was applied: the payload is a signed assertion by the Issuer that it was. Unless a Verifier independently establishes that the disclosed bytes carry the transformation the Issuer describes, the evidence available is evidence of what the pinned Issuer asserted. Where the Issuer is the Gateway that performed the transformation, that assertion is self-attested, and a consumer who treats it as verified has removed the Issuer from the trust statement without replacing it with anything. A deployment whose requirement is that a class be unlearnable rather than hidden must enforce that requirement in policy (for example, by not allowing the objects that carry the class at all); no evidence structure substitutes for that enforcement. The classes array is bounded by what the applied policy recognizes. A value belonging to a class the policy does not name is not counted. The absence of a class from the array is therefore a statement about the policy's vocabulary as much as about the data, and MUST be read that way.

Coverage Reconciliation

Purpose Coverage Reconciliation answers, for one Window: did the Data Source's own accounting record activity for which no Receipt exists? It is the mechanism by which "the gateway was bypassed" or "the receipt sink failed" becomes detectable, rather than invisible. The essential property is that the two accounts being compared originate from different components: the receipt set from the Gateway, the activity counters from the Data Source. A Gateway cannot make bypassed activity disappear from an account it does not produce.

Activity snapshots A snapshot is a JSON object capturing the Data Source's cumulative activity counters at a point in time:

v:

Snapshot version string. For this document: activity-snapshot/1.

ts:

The time the snapshot was taken (ISO 8601).

source:

An identifier of the Data Source and the accounting scope within it (for example, the database role whose activity is counted). Both snapshots of a Window MUST carry the same source; a mismatch invalidates the Window.

entries:

An array of objects, one per activity pattern the source's accounting distinguishes, each with:

pattern:

A digest of the normalized activity pattern (for example, a normalized statement with constants removed). The digest, not necessarily the text: pattern text can embed protected values and schema detail. Deployments MAY retain pattern text privately for diagnosis; only the digest is required here.

count:

The cumulative counter value for this pattern at ts.

Reconciliation procedure Given a start snapshot, an end snapshot, and the receipt set for the Window, a reconciler proceeds as follows. Window validity is checked first. The two snapshots MUST carry the same v and source, the end ts MUST be later than the start ts, and no pattern's counter may be lower at the end than at the start. A counter regression means the source's accounting was reset or altered inside the Window; the Window is then unreliable, and the reconciler MUST report failure for the Window as a whole rather than reconciling the surviving patterns. An attacker who can reset counters must gain an error, not a clean report. For each pattern whose counter increased during the Window, the reconciler attributes the pattern to the data objects it touches and checks whether any Receipt in the Window names those objects. Matching is per pattern and per data object, not per call count: one client-level request may legitimately produce more than one source-level statement, so call counts and receipt counts MUST NOT be compared one-to-one. A pattern whose target objects cannot be determined MUST NOT be silently ignored; it receives the indeterminate outcome below. The comparison is between two populations — source-level activity and Receipts — and neither population is assumed complete. Each item in either population receives exactly one of the following outcomes:

matched:

The item corresponds to an item in the other population within the bounds of the applicable Mapping Profile ().

observed-without-receipt:

The Data Source recorded activity against an object that no Receipt in the Window names.

receipted-without-observation:

A Receipt in the Window names an object for which the Data Source's counters record no activity.

excluded:

The item was removed from comparison before matching by a rule stated in the Mapping Profile ().

indeterminate:

The evidence or the Mapping Profile does not determine an outcome — the pattern's objects could not be attributed, a required multiplicity bound is undeclared, or the Window's evidence is insufficient to decide.

An implementation MUST NOT report an item as matched when the outcome is indeterminate; the absence of a decision is not a decision. In particular, where a Mapping Profile does not declare the multiplicity bound that the comparison requires, the affected items are indeterminate and not clean coverage. A reconciliation with no observed-without-receipt items establishes that each observed source-level item is attributable to a Receipt naming the same object, under the declared correspondence. It does not establish that every source-level statement was itself receipted, and a result MUST NOT be stated in terms that assert it. Where one Receipt naming an object clears an unbounded number of further statements against that object inside the Window, the procedure has established object attribution and nothing stronger.

Mapping profiles One client-level operation may produce several source-level statements. The multiplicity is not a property of the Gateway; it is a property of the deployment — the version of the intermediary in front of the Data Source, a connection pooler, an object-relational mapper. A Gateway cannot measure a correspondence it does not produce. A Mapping Profile is therefore declared by the operator. It states, for each client-level operation it covers, the expected bounded set of source-level patterns, the bound on their multiplicity, and the exclusion rules applied before comparison (). It carries a version identifier and is serialized and digested as in . A reconciliation result computed against a Mapping Profile MUST bind that profile's digest, and MUST state, for each bound it relies on, whether the bound is protocol-defined, measured, operator-declared, or undeclared. A result MUST NOT present an operator-declared bound as a measured one. The consequence is a ceiling: a coverage outcome computed against a declared correspondence cannot be stronger than the declaration. Where the declaration is an operator statement, the outcome inherits that standing and the result statement is required to show it. This is the same discipline this document applies to absent evidence in , one layer up: a declaration presented as a measurement is an overclaim regardless of whether the declaration happens to be true. Where a required multiplicity bound is undeclared, the affected items are indeterminate (). An implementation MUST NOT substitute a default bound of one; a one-to-one rule reports false observed-without-receipt items on any deployment with a pooler in front of the Data Source, and a silent default would make that error look like a finding.

Exclusions Exclusion differs from the other outcomes in kind. matched, observed-without-receipt, receipted-without-observation, and indeterminate are produced by the comparison. excluded is a decision taken before it, about what will be compared at all. It is therefore the outcome through which a reconciliation can be made to come out clean, and it requires the tightest reporting rules of the five. Exclusion rules MUST be stated in the Mapping Profile and are therefore covered by its digest. A result statement MUST report the count of excluded items and the rule that excluded each of them. An implementation MUST NOT exclude items by a rule that is not in the profile. Without these constraints, a clean result and a result cleaned by exclusion are indistinguishable to a reader, and the digest that is supposed to pin what was compared does not cover the step that decided what was compared. Session or catalog housekeeping is a legitimate exclusion; the requirement is not that exclusions be rare, but that they be visible and pinned.

Result statement The reconciliation result is a JSON object:

v:

coverage-reconciliation/2. The outcome vocabulary of coverage-reconciliation/1 is not a subset of this one: a /1 result reporting covered asserts more than the procedure establishes, and is not re-expressible here. A consumer MUST NOT read a /1 result as a /2 result.

window:

Object with start and end (the two snapshot ts values).

source:

The common source identifier of the two snapshots.

snapshots:

Object with start and end digests of the two snapshot structures.

receipts:

A digest identifying the receipt set that was compared (for chained receipt formats, the chain head digest and the sequence range are RECOMMENDED as the identifying material).

profile:

The digest and version identifier of the Mapping Profile the comparison was computed against (), or null when none was declared. When null, every item whose outcome depends on a multiplicity bound is indeterminate.

bounds:

For each bound the comparison relied on, its source: protocol-defined, measured, operator-declared, or undeclared. A result whose bounds are operator-declared states an outcome of that standing, no stronger.

outcome:

invalid-window when the Window is unreliable (); otherwise no-exceptions when every item is matched or excluded, and exceptions when any item is observed-without-receipt, receipted-without-observation, or indeterminate.

The name states what the comparison left open, not what it proved. A result MUST NOT carry an outcome name that asserts coverage of the source activity, and no-exceptions is not such an assertion: it says the comparison produced no open item under the declared correspondence, which is bounded by that correspondence () and by the fact that neither population is assumed complete.

items:

The list of items whose outcome is not matched, each with its outcome and, for excluded, the profile rule that excluded it. Pattern digests, not pattern text, for the reasons in .

counts:

The number of items in each outcome, including matched and excluded. An implementation MUST NOT aggregate indeterminate items into a proportion of coverage: an outcome that does not decide cannot be averaged into one that does, and reporting it as a percentage restores precisely the overclaim this vocabulary exists to prevent.

The result statement is serialized and digested as in and is intended to be signed by the reconciling party and registered (). The reconciler SHOULD be operationally independent of the Gateway; where it is not, registration on a Transparency Service at least makes the result's existence and timing third-party-visible.

Semantics of the outcomes An observed-without-receipt outcome is a statement that evidence is absent, not a statement about why. Gateway bypass, receipt sink failure, and accounting scope mismatch all produce it. A result statement MUST NOT label such activity as an intrusion, a breach, or an intentional act, and consumers MUST NOT present it as such. The value of the mechanism is precisely that it surfaces the condition; attributing cause is investigation, not reconciliation. A receipted-without-observation outcome is likewise a statement about evidence, and it is not by itself a fault. A counter reset at the Window boundary, an intermediary that collapses statements, and an increment that lands outside the snapshot pair all produce the same shape as a receipt describing activity that did not occur. An implementation MAY treat it as a failure condition under a policy of its own; this document does not define it as one, because the shape does not distinguish the cases. An indeterminate outcome is a result, not a degraded pass. It MUST NOT be resolved by assumption in either direction: neither counted as matched because nothing contradicts it, nor reported as missing activity because nothing confirms it. An implementation under pressure to produce a single number will be tempted to fold indeterminate into a coverage proportion; that operation destroys the only property that distinguishes this vocabulary from a bare pass, and MUST NOT be performed. Verification of receipt signatures and chain integrity is out of scope for reconciliation and is assumed to have happened first, under the rules of the receipt format in use. Reconciliation compares an already-verified receipt set against source accounting; it does not re-verify.

Registration on a Transparency Service Both structures defined here are payloads for Signed Statements in the sense of the SCITT architecture . An Issuer (the Gateway operator for Transformation Evidence; the reconciling party for a Coverage Reconciliation result) signs the serialized structure and registers the Signed Statement on a Transparency Service, obtaining a Receipt in the SCITT sense: proof of the statement's inclusion, at a position, in an append-only log operated by a party other than the Issuer. This layering is deliberate. The structures in this document gain their audit value from being registered somewhere the Issuer cannot quietly rewrite; SCITT already defines that somewhere, together with its trust model and verification procedures. This document therefore defines no countersignature, no anchoring, and no log format of its own. Where this document's mechanisms speak of digests binding evidence to receipts, the binding survives registration unchanged: digests are over the payload, not the envelope.

Security Considerations

Same-operator collusion.

In many deployments the Gateway and the Data Source are operated by the same party. Coverage Reconciliation's value against that party is reduced: an operator with administrative access to the source's accounting can suppress the counters themselves. The mandatory invalid-window rule () turns counter resets into visible failures, and registration () makes suppression of already-issued results detectable, but an operator who controls both accounts and never registers anything is outside this mechanism's reach. Deployments needing assurance against the operator itself require an accounting path the operator cannot write to; that is a deployment property, not a payload property.

Counter manipulation.

An attacker who can reset or rewind source counters could otherwise hide activity between snapshots. The MUST-fail rule exists for this case: a Window containing a regression is reported unreliable in its entirety. Snapshot frequency bounds the exposure — shorter Windows mean a reset costs the attacker a visible failure sooner.

Declared correspondence as an attack surface.

The Mapping Profile () is written by the operator, and it decides both what counts as a match and what is excluded before matching. An operator who can widen a multiplicity bound can absorb unreceipted activity into an expected range; one who can add an exclusion rule can remove it from comparison entirely. This mechanism does not defend against that operator — nothing computed against a declaration can. What it does is make the declaration part of the evidence: the profile is versioned, its digest is bound into the result, exclusions are reported with their count and rule, and the result states that its bounds are operator-declared. A reader who trusts the result inherits a visible dependency on the profile rather than an invisible one. Registration () makes the sequence of profiles an operator has declared third-party-visible, which is the property a silently edited profile would otherwise remove.

Digest agility.

Digests are prefixed (); an implementation MUST reject unknown prefixes. Accepting an unknown prefix as an opaque match would let an attacker route around comparison.

Signature and key compromise.

Signing and registration are inherited from the SCITT layer; key management, revocation, and the consequences of Issuer key compromise are governed there, not here. A compromised Issuer key voids the evidentiary value of statements under that key, as it does for any signed artifact.

Privacy Considerations Every structure in this document was shaped by one rule: evidence about protected data must not itself become a disclosure channel. Transformation Evidence carries class names, action names, and counts — never values. Request and pattern references are digests because query and pattern text can embed values and schema detail. Class names and counts do reveal that data of a class was present in a result in a given quantity; deployments for which even that is sensitive can keep the payloads private and register only their digests, at the cost of making third-party audit a permissioned rather than public act.

IANA Considerations This document, if progressed, will request registration of two media types: application/transformation-evidence+json and application/coverage-reconciliation+json, with the structures of and as their content. No registrations are requested at this stage.

Implementation Status This section is to be removed before publication as an RFC, per . One implementation of both mechanisms exists: the Conarium gateway (TypeScript, MIT license, @conarium-ai/core on npm), in production at one site since July 2026. Its receipts carry per-class masking counts as in ; its conarium-reconcile tool implements the procedure of against PostgreSQL statement statistics, as a single file with no dependency on the package, so that a third party can run the reconciliation without trusting the implementation under audit. Conformance test vectors ship with the package. The implementation is partial with respect to this revision, and the gaps are stated here rather than left for a reader to discover: It reports observed-without-receipt and, since 0.2.23, receipted-without-observation. It does not yet emit the outcome vocabulary of under those names, and its result carries no profile or bounds field. It does not implement Mapping Profiles (). Every bound it relies on is therefore undeclared, and by the rule in the items depending on those bounds are indeterminate; the tool does not currently report them as such. It excludes session and catalog statements from comparison and prints each excluded statement individually, but those rules are compiled into the tool rather than declared in a profile, so they are not covered by a profile digest as requires. Its exit codes predate this vocabulary and are not a mapping of it. They were left unchanged deliberately: an exit code is a compatibility contract with existing deployments, and renumbering it to match a revision of this document would break running installations to make a specification look implemented. Earlier revisions of this document, and releases of that implementation up to 0.2.21, described a clean reconciliation as "covered". That word asserted more than the procedure establishes; it was corrected in the implementation in 0.2.22 and in this document in this revision.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152.

Acknowledgments The discipline of stating what each structure does not prove is owed to every auditor who has been handed a green dashboard and asked to trust it. Iman Schrock reviewed revision -02 on the SCITT mailing list and identified two overclaims in it: that a clean reconciliation established coverage of the source activity, and that Transformation Evidence proved the transformation rather than the Issuer's assertion of it. Both are corrected in this revision. The outcome vocabulary of and the requirement that a declared bound cannot yield an outcome stronger than the declaration follow from that exchange.