Individual Submission S. Das Internet-Draft Independent Inventor Intended status: Informational 10 September 2026 Expires: 14 March 2027 Data-Purpose Laundering Prevention: Execution-Finality for Preventing Cross-Domain Data Reuse draft-das-purpose-execution-finality-02 Abstract Consider a concrete case: a user invokes a highly capable AI model under a declared purpose of education, but the resulting capability is in fact used for a military or terrorist end -- an illustrative example, not a claim about any real deployment. When such misuse surfaces, an unresolved question follows: is the model provider liable, is the user liable, or is the jurisdiction that permitted the deployment liable? This document does not answer that question -- liability determination remains an external legal question for the responsible court, regulator, or contracting parties -- but it addresses the technical gap that makes the question unanswerable today. Systems that collect data, or grant capability, for one stated purpose routinely permit that data or capability to be consumed for a different purpose, not because the second use was authorized, but because nothing in the protocol path was capable of refusing it or of recording what was actually authorized. The most common technical control in deployment today is a self-asserted purpose string: a "purpose" claim in a token, a field in an API request, a comment in a data-sharing agreement. A self-asserted string is evidence of intent, not proof of authority, and it fails precisely when it matters most -- when the requester lies. This architecture addresses that loophole deterministically: it makes an undeclared or purpose-switched use technically detectable and refusable at the point of use, and it produces verifiable evidence of what was actually authorized, so that any subsequent liability determination can be argued from that evidence rather than from an unverifiable self-assertion. Achieving that determinism introduces a bounded, measurable amount of evaluation latency at the point of use; this document treats that latency as an acceptable, secured trade-off for closing an otherwise unverifiable gap, not as a cost to be minimized at the expense of the guarantee. The premise is not that AI innovation should slow down, any more than cars should be built slower; it is that innovation moving this fast needs the technical equivalent of a seat belt. Das Expires 14 March 2027 [Page 1] Internet-Draft Data-Purpose Laundering Prevention September 2026 A runnable reference implementation accompanies this document at Purpose Execution Finality Validator -- Runnable Reference Implementation (https://github.com/sangmdas/Purpose-Execution- Finality-Validator-to-Prevent-Data-Purpose-Laundering-in-AI-Systems). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Self-Asserted Purpose Is Not Verifiable Purpose . . . . . 7 3.2. Attestation Answers a Different Question Than Authorization . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Derived Data Carries the Restriction, Not Just the Value . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. The Residual Limit: Plaintext Already Released . . . . . 8 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 8 5. Worked Example . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Collection: Binding the Data Object to a Permitted Use . 9 5.2. A Legitimate Request . . . . . . . . . . . . . . . . . . 9 Das Expires 14 March 2027 [Page 2] Internet-Draft Data-Purpose Laundering Prevention September 2026 5.3. An Unauthorized Request . . . . . . . . . . . . . . . . . 10 5.4. A Relabeled Request . . . . . . . . . . . . . . . . . . . 11 5.5. A Request From Inside an Attested Enclave . . . . . . . . 11 5.6. A Request for a Derived Value . . . . . . . . . . . . . . 12 5.7. What This Architecture Does Not Close . . . . . . . . . . 12 6. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Relation to Existing Work . . . . . . . . . . . . . . . . . . 13 8. Relevance to IETF Working Groups . . . . . . . . . . . . . . 14 8.1. GNAP . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.2. OAUTH . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.3. RATS . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.4. SPICE . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.5. SECDISPATCH . . . . . . . . . . . . . . . . . . . . . . . 15 8.6. PEARG (IRTF) . . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 13. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.1. Primary Reference Implementation . . . . . . . . . . . . 17 13.2. Other Reference Implementations . . . . . . . . . . . . 18 14. Latency Characteristics (Non-Normative) . . . . . . . . . . . 19 15. Feasibility and Legacy System Integration . . . . . . . . . . 20 16. Normative References . . . . . . . . . . . . . . . . . . . . 23 17. Informative References . . . . . . . . . . . . . . . . . . . 23 Appendix A. Primary Reference Implementation -- Detailed Validation Methodology . . . . . . . . . . . . . . . . . 27 A.1. Recorded Test Environment . . . . . . . . . . . . . . . . 27 A.2. Baseline Candidate Act, Binding Record, and Validation Context . . . . . . . . . . . . . . . . . . . . . . . . 28 A.3. PED Decision Sequence . . . . . . . . . . . . . . . . . . 28 A.4. Execution Handle Lifetime Clamping . . . . . . . . . . . 29 A.5. Mutation and Threat-Model Testing . . . . . . . . . . . . 29 A.5.1. Purpose-Relabel Attack . . . . . . . . . . . . . . . 29 A.5.2. Additional Negative-Control Conditions . . . . . . . 30 A.5.3. Derived-Data Lineage . . . . . . . . . . . . . . . . 31 A.5.4. Trusted-Record Compromise . . . . . . . . . . . . . . 31 A.6. LAVR Generation, Chaining, and Tamper Detection . . . . . 31 A.7. Replay and Concurrency Testing . . . . . . . . . . . . . 32 A.8. Cross-Language Conformance . . . . . . . . . . . . . . . 32 A.9. Deterministic Adversarial Stress Testing . . . . . . . . 32 A.10. Latency by Topology, with Repeated Runs . . . . . . . . . 33 A.11. What the Testing Supports, What It Does Not, and Residual Risks . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.12. Reproduction . . . . . . . . . . . . . . . . . . . . . . 35 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35 Das Expires 14 March 2027 [Page 3] Internet-Draft Data-Purpose Laundering Prevention September 2026 1. Introduction Purpose limitation is a stated requirement across data protection law, sectoral regulation, and internal governance policy: data collected for one purpose should not be repurposed for another without new authority. It is, at the protocol level, almost never enforced. What is typically enforced is that a request carries a "purpose" value the requester chose to write down. This gap is not a corner case. It is the default shape of most data- sharing architectures in production today: an access-control check confirms that a caller is _permitted to call the API_, and a separate, unenforced convention -- a contract clause, a privacy notice, a code comment -- says what the caller is supposed to do with the response. Nothing in the request path distinguishes a truthful purpose claim from a false one, because the claim was never checked against anything the requester does not control. This document uses a single concrete scenario to walk through what changes when purpose is treated as something to be verified rather than declared. A delivery application collects a home address in order to fulfil an order. An unrelated advertising system later attempts to use that same address to infer household income for ad targeting. Every variation of that attempt -- a direct request, a relabeled request, a request issued from inside an attested secure enclave, a request for a value merely _derived_ from the address -- is traced through an enforcement boundary that answers one question before doing anything else: is this caller, this operation, and this destination actually authorized, based on records the caller cannot write to? The architecture generalizes past the delivery/advertising example to any setting where data crosses an organizational, workload, or trust boundary and the receiving side has an incentive to reuse it for something other than what it was released for: cross-tenant AI agent tool use, cross-border data transfer under jurisdictional restriction, and inter-service data sharing inside a single company under an internal purpose limitation policy are all instances of the same problem. This document keeps the running example narrow so the mechanism stays concrete; companion drafts in the same series ([DAS-EU-AI-ACT], [DAS-GLOBAL-PRIVACY], [DAS-PRECISION-EGRESS]) apply the same underlying architecture to EU AI Act high-risk system enforcement, general-purpose privacy-execution enforcement, and precision-bounded data egress respectively. [FUTURIUM-PURPOSE-LAUNDERING] develops the GDPR purpose-limitation and high-risk AI governance framing of this same delivery/advertising pattern in regulatory detail, and [FUTURIUM-PAPER-COMPLIANCE] situates that framing within the broader argument for moving from Das Expires 14 March 2027 [Page 4] Internet-Draft Data-Purpose Laundering Prevention September 2026 paper compliance to technical enforcement under GDPR and the EU AI Act; this document is the protocol-mechanics counterpart to that discussion. See Section 13 for a Resources pointer to the drafts and the runnable reference implementation that develop these mechanics further. This document specifies an execution-finality architecture in which a Candidate Act to read, transmit, or derive from a protected data object does not become effective merely because a caller labels its request with an allowed purpose. Effect is withheld until a Protected Enforcement Domain verifies caller identity, requested operation, and destination against binding records -- not against caller-supplied metadata -- and issues a scoped, non-bearer Execution Handle before any release occurs. The document works through a single running example (a delivery address later targeted by an unrelated advertising system) to make the failure mode and the enforcement boundary concrete, and states plainly which part of the problem this architecture does not solve. It is offered as an architectural pattern for discussion, not as a proposal for a new wire protocol. Cross-referencing data across systems, including in advertising, is a legitimate and economically necessary function, and this document does not argue for eliminating it; doing so would stall innovation and materially harm the businesses that depend on it. What this architecture offers such systems is a way to make an authorized combination of data technically verifiable at the moment it happens, rather than leaving that boundary to rest on a data-sharing agreement nobody downstream actually checks -- making lawful cross-referencing demonstrable, not making cross-referencing itself the target. The same gap appears when four applications sit on a shared raw-data path. Applications A, B, and C may be known operators: they host to published standards, maintain written ethics and paper policies, and implement the technical controls those policies require. This document does not argue that such operators should be denied raw data they are authorized to receive. Application D may request that same raw object. Paper policy and a self-asserted purpose string give no technical reason to believe that D will confine the object to the purpose and jurisdiction under which it was collected, rather than reuse it for an unauthorized purpose -- including surveillance or intelligence activity directed against the jurisdiction that originally authorized collection. This architecture does not ask A, B, or C to stop receiving authorized raw data; it asks that D's Candidate Act be refused at the Protected Enforcement Domain unless binding records, not D's own label, establish that D, the requested operation, and the destination are actually authorized -- so that faith in D is replaced by a check D cannot write. Das Expires 14 March 2027 [Page 5] Internet-Draft Data-Purpose Laundering Prevention September 2026 A further motivation is stated directly here because it shapes several design choices in this document: the same technical capacity that lets an advertising system profitably combine location and behavioral signals across sources is, absent a verifiable purpose boundary, also capable of exposing patterns -- such as the movement of military personnel or the operating rhythm of critical infrastructure -- to a party in a jurisdiction other than the one the data was collected in. Aggregated commercial location and behavioral data has, in publicly reported incidents, already been shown capable of revealing exactly this kind of sensitive pattern. This document does not ask commercial systems to stop combining data for legitimate purposes; it asks that a combination authorized for commercial targeting be technically distinguishable, at the moment of use, from a combination that has crossed into cross-jurisdictional intelligence-gathering territory the data was never authorized for. The architecture does not claim to solve purpose limitation in general. Section 5.7 and Section 6 state directly what remains unsolved once data has been legitimately released as plaintext to an authorized recipient. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Terminology Candidate Act: A request to read, transmit, transform, or derive from a protected data object. A Candidate Act has no effect on its own; it is a proposal for an effect. Non-Effective State: The state of a Candidate Act prior to validation. No data release, decryption, or downstream write occurs while a Candidate Act remains in this state. Protected Enforcement Domain (PED): The component that evaluates a Candidate Act against binding records -- caller identity, order/ workflow state, recipient assignment, and policy version -- and decides whether to advance it out of the Non-Effective State. The PED does not accept caller-supplied metadata (such as a "purpose" field) as evidence on its own. Execution Handle: A short-lived, non-bearer, scoped authorization Das Expires 14 March 2027 [Page 6] Internet-Draft Data-Purpose Laundering Prevention September 2026 issued by the PED after a Candidate Act passes validation. An Execution Handle is bound to a specific data object, operation, requester identity, and recipient; it is not a general-purpose credential and is not intended to be transferable. Finality Sink: The boundary at which a protected data object, or a value derived from it, is actually released, decrypted, or written to a destination store. The Finality Sink accepts only a valid, unexpired, unrevoked Execution Handle. Ledger-Anchored Validation Receipt (LAVR): An enforcement artifact -- not an audit log -- generated by the PED at the point a Candidate Act is validated or rejected. A LAVR records the check performed, its result, and a hash-chained, domain-signed anchor, and is generated regardless of outcome. Algorithmic Logic Fingerprint (ALF): A binding of the specific operation or computation a Candidate Act requests (e.g., "obtain delivery destination" versus "infer household income") to the set of operations the governing policy actually permits on that data object. Capability-Validated Inbound Descriptor (CVID): The structured description of an inbound Candidate Act -- caller, requested operation, target object, destination -- that the PED evaluates against binding records before issuing an Execution Handle. Purpose Laundering: The practice, intentional or not, of obtaining data or a value derived from it under one declared purpose and consuming it under a different, unauthorized purpose, where the receiving system's own request format permits the original purpose label to travel with the data without being re-verified at the point of reuse. 3. Problem Statement 3.1. Self-Asserted Purpose Is Not Verifiable Purpose Most deployed systems that reference "purpose" at all do so as a string carried in a token claim (e.g., a JWT claim, see [RFC7519]), an API parameter, or a log field. That string is written by the same party requesting access. A verification step that only checks whether the field is present, well-formed, or drawn from an enumerated list does not verify that the caller's actual operation matches the label -- it verifies that the caller knows which label to write. Das Expires 14 March 2027 [Page 7] Internet-Draft Data-Purpose Laundering Prevention September 2026 3.2. Attestation Answers a Different Question Than Authorization Remote attestation (see [RFC9334]) establishes that a piece of code is running in an expected state on expected hardware. It does not establish that the workload attested is authorized to perform a specific operation on a specific data object. A correctly attested enclave running an unauthorized computation is still an unauthorized computation; attestation and purpose authorization are orthogonal checks, and treating a passed attestation as implicit authorization silently collapses that distinction. 3.3. Derived Data Carries the Restriction, Not Just the Value A value computed from restricted data (e.g., an income estimate computed from a home address) is not automatically free of the restriction that governed the source, even where the derived value contains none of the original data verbatim. Without deliberate propagation of source lineage to the derived object, a downstream consumer of the derived value bypasses every control placed on the source. 3.4. The Residual Limit: Plaintext Already Released Once a protected value is legitimately released as plaintext to an authorized recipient, this architecture -- or any architecture operating at the request/response boundary -- cannot guarantee that the recipient will not copy, screenshot, or re-transmit that value outside the enforced path. Section 5.7 and Section 6 return to this point; it is stated here because any reader evaluating this document for what it does NOT do should not have to search for the admission. 4. Architecture Overview The architecture separates two things that are frequently conflated in deployed systems: the authority to request an operation, and the capability to actually perform it. A Candidate Act carries no capability. It is evaluated by a Protected Enforcement Domain against records the requester did not write (order state, recipient assignment, policy version, workload identity). Only on a pass does the PED issue a scoped Execution Handle, and only a Finality Sink presented with a valid Execution Handle releases, decrypts, or writes the underlying value. Every evaluation, pass or fail, produces a LAVR. Das Expires 14 March 2027 [Page 8] Internet-Draft Data-Purpose Laundering Prevention September 2026 Requester --Candidate Act--> [Protected Enforcement Domain] | binding-record checks (Section 5.2) | pass? --------> Execution Handle | | fail --> LAVR Finality Sink | | LAVR release This differs from a conventional access-control gate in one load- bearing respect: the PED's checks are defined over records external to the request (what the request _is about_), not over fields internal to the request (what the request _says about itself_). A caller cannot pass validation by changing what it writes in its own request. 5. Worked Example 5.1. Collection: Binding the Data Object to a Permitted Use A customer provides a delivery address for a specific order. The address is stored as a protected data object. A separate, integrity- protected policy record binds that object to a single permitted workflow, operation, and recipient class, with an explicit disallowed-operation entry and an expiry: Data object: address-619 Allowed workflow: delivery-order-842 Allowed operation: obtain delivery destination Allowed recipient: assigned courier service Disallowed operation: advertising-profile enrichment Expiry: configured delivery-access deadline Policy version: 38 The party that will later compute an advertising profile is never given the address's decryption key or database credentials. If it were, every check described below would be enforcement theater -- bypassable at will by the party the checks are meant to constrain. 5.2. A Legitimate Request The delivery service submits a Candidate Act: Read address-619, for order-842, send to assigned-courier-6, operation: obtain delivery destination Das Expires 14 March 2027 [Page 9] Internet-Draft Data-Purpose Laundering Prevention September 2026 The PED checks this against binding records, not against the request's own claims: +======================================+=======================+ | Check | Evidence checked | +======================================+=======================+ | Is this really the delivery service? | Authenticated | | | workload identity | +--------------------------------------+-----------------------+ | Does this order exist? | Order-management | | | record | +--------------------------------------+-----------------------+ | Does this address belong to the | Protected order-to- | | order? | address association | +--------------------------------------+-----------------------+ | Is this courier assigned? | Current courier- | | | assignment record | +--------------------------------------+-----------------------+ | Is the requested operation | Versioned policy (ALF | | permitted? | match) | +--------------------------------------+-----------------------+ | Is access still valid? | Order status, expiry, | | | revocation state | +--------------------------------------+-----------------------+ Table 1: PED validation checks for the delivery Candidate Act A pass issues a short-lived Execution Handle scoped to this exact address, order, operation, and recipient; the Finality Sink releases the minimum necessary delivery data on presentation of that handle. Any check that cannot be completed -- a stale record, an ambiguous assignment, an expired policy version -- MUST be treated as a failed check. The PED fails closed by default; it does not proceed on missing or ambiguous evidence. 5.3. An Unauthorized Request An advertising workload submits: Read address-619, operation: infer household income, destination: advertising-profile-database Das Expires 14 March 2027 [Page 10] Internet-Draft Data-Purpose Laundering Prevention September 2026 Every check in Section 5.2 fails: the caller is not the delivery service, the operation is not the permitted operation, and the destination is not the permitted recipient. No Execution Handle is issued, no address is released, and no decryption authority is granted. The rejection occurs before the income computation begins -- blocking only the resulting advertisement, after the profiling computation has already run on the address, would not have prevented the unauthorized use; it would only have hidden its output. 5.4. A Relabeled Request The advertising workload resubmits with a relabeled purpose field: Purpose: delivery, order: order-842 This does not change the outcome. The PED's checks are defined over the caller's authenticated identity, its destination, and its actual delivery-workflow authority -- none of which change because the request's purpose field changed. A caller that presents even a validly issued delivery Execution Handle from the wrong workload identity or toward the wrong destination MUST fail validation, provided identity and destination binding are actually enforced at the Finality Sink and not only at issuance time. Purpose, in this architecture, is a conclusion the PED reaches from verifiable relationships -- not an input the caller supplies. 5.5. A Request From Inside an Attested Enclave Suppose the income-inference computation runs inside a hardware Trusted Execution Environment (TEE) that successfully attests its own integrity. A successful attestation establishes that the enclave is running the code it claims to run; it does not establish that the code is authorized to decrypt address-619 for this purpose. The PED still evaluates workload identity and requested operation against the same binding records, and an enclave running an income-profiling workload receives no authority to decrypt a delivery address it was never granted. A caveat: if a broadly authorized enclave already holds unrestricted plaintext access to the address for an unrelated legitimate reason, an output-only Finality Sink cannot retroactively undo profiling computation that already occurred inside it. Access and computation boundaries require enforcement at the point capability is granted, not only at the point output is written. Das Expires 14 March 2027 [Page 11] Internet-Draft Data-Purpose Laundering Prevention September 2026 5.6. A Request for a Derived Value The advertising system instead attempts to write a value computed from, but not textually identical to, the address: customer-17 -> estimated high-income household The value contains no street address. A Finality Sink that checks only for the literal restricted value would pass it. A Finality Sink that checks propagated source lineage does not: Derived object: income-estimate-52 Restricted source: address-619 Requested use: advertising The profile-write boundary rejects the write on the lineage binding, not on pattern-matching the output. This requires deliberate, non- removable tracking of derived-data provenance; a label attached to the output that the producing workload can choose to omit provides no enforcement at all. 5.7. What This Architecture Does Not Close If an authorized courier receives the plaintext address and copies it into an unrelated application, the protected data service cannot guarantee the copy is never reused. Containment beyond this point requires controlled recipient software, restricted export paths, minimal disclosure, and downstream enforcement at the recipient's own boundary -- outside what a source-side PED can observe. Human observation, screenshots, and compromised endpoints remain outside this architecture's reach. The claim this document makes is therefore bounded: within an enforced system boundary, data can be made unavailable to unauthorized workloads, and unauthorized derived- value writes can be blocked. Preventing every possible reuse after legitimate plaintext disclosure is a different, and materially harder, problem that this document does not claim to solve. 6. Threat Model In scope: * A requester relabels or forges the purpose field of a request to obtain access to data it is not authorized to use for that purpose (Section 5.4). * A requester assumes that running inside an attested TEE substitutes for a purpose-authorization check (Section 5.5). Das Expires 14 March 2027 [Page 12] Internet-Draft Data-Purpose Laundering Prevention September 2026 * A requester attempts to obtain a value derived from restricted data as a way of evading a restriction on the source value (Section 5.6). * A requester replays a validly issued Execution Handle from a different workload identity or toward a different destination than the one it was scoped to. Out of scope / residual risk: * Reuse of data after legitimate plaintext release to an authorized recipient (Section 5.7). * Compromise of the Protected Enforcement Domain itself, or of the binding records it evaluates against; this architecture assumes the PED and its record store are not themselves attacker- controlled. * Side-channel or covert-channel exfiltration from within an authorized, attested computation. 7. Relation to Existing Work The pattern of checking a request's declared purpose against a policy before granting access is not new in the access-control literature; purpose-based access control (PBAC) models and attribute-based access control frameworks such as XACML define policy evaluation over request attributes including purpose. This document's distinguishing element is that the evaluated attributes are drawn from binding records external to the request (order state, recipient assignment, workload identity), the resulting grant is a short-lived, non-bearer, single-scope Execution Handle rather than a general session grant, and derived-value writes are checked against propagated source lineage rather than against the presence or absence of a purpose label on the output. Decentralized information flow control (DIFC) systems address the derived-data problem in Section 5.6 by propagating labels through computation at the operating-system or language-runtime level. This document does not specify a label-propagation mechanism; it specifies that a Finality Sink MUST reject a derived-value write that cannot demonstrate valid source lineage, leaving the propagation mechanism to the implementing system. Das Expires 14 March 2027 [Page 13] Internet-Draft Data-Purpose Laundering Prevention September 2026 [RFC8707] (Resource Indicators for OAuth 2.0) and audience restriction in OAuth 2.0 bearer tokens address a related but narrower problem: binding a token to an intended resource server. This document's Execution Handle extends that idea to bind a grant to a specific operation and destination, evaluated per Candidate Act rather than issued once per session. 8. Relevance to IETF Working Groups 8.1. GNAP GNAP [RFC9635] already separates the negotiation of a grant from its use, and supports fine-grained, per-request access rather than a single broad session token. The Execution Handle described here is compatible with a GNAP access token scoped to a single resource/ operation pair; this document's contribution to GNAP-adjacent work is the requirement that the Authorization Server's grant decision be made against externally-verified binding records rather than against client-supplied purpose or context claims, and that a derived- resource request be evaluated against source lineage rather than treated as a fresh, unrelated grant. 8.2. OAUTH OAuth 2.0 [RFC6749] deployments that rely on a "purpose" or "scope" string supplied by the client are exposed to exactly the relabeling attack in Section 5.4. [RFC8707]'s audience restriction is a partial mitigation already in the OAuth toolkit; this document suggests that audience restriction alone is insufficient where the threat model includes a legitimately audience-scoped token presented for an operation outside its intended purpose, and that purpose SHOULD be a property the authorization server derives from verifiable request context rather than a bearer-supplied claim. 8.3. RATS Section 5.5 is directly a RATS-relevant finding: this document treats a RATS [RFC9334] Attestation Result as answering "is this code running as expected" and treats purpose/operation authorization as a separate, subsequent check that a Relying Party MUST perform independently. Where RATS-based systems are used to gate access to sensitive data, this document's caution against conflating attestation with authorization is offered as an applicability consideration. Das Expires 14 March 2027 [Page 14] Internet-Draft Data-Purpose Laundering Prevention September 2026 8.4. SPICE SPICE's work on credential formats and selective disclosure is relevant to Section 5.1's binding of a data object to a specific permitted workflow: a credential-based encoding of the "allowed workflow / allowed operation / allowed recipient" policy record would let the binding travel with the data object in a verifiable form rather than living only in a centralized policy store, which may be of interest to SPICE's scope on interoperable credential structures. 8.5. SECDISPATCH This document is submitted as an individual architectural pattern rather than a protocol specification, and the author does not assert a specific IETF venue for standardization. SECDISPATCH is the appropriate venue to determine whether, and where, a purpose-binding and derived-data-lineage mechanism of this kind warrants protocol- level standardization versus remaining an architectural pattern referenced by implementers of GNAP, OAuth, and RATS-based systems. 8.6. PEARG (IRTF) The Privacy Enhancements and Assessment Research Group is an IRTF research group rather than an IETF working group, and is noted here because Section 3.3 and Section 5.6 (derived-data lineage) and Section 5.7 (the residual plaintext-reuse limit) are research questions as much as engineering ones; PEARG's work on privacy threat modeling and assessment methodology is relevant to evaluating how completely a lineage-propagation mechanism actually closes the derived-data gap in practice. 9. Security Considerations The security of this architecture reduces to the integrity of the Protected Enforcement Domain and the binding records it evaluates against. An attacker who can write to the order-management record, the courier-assignment record, or the policy-version store used in Section 5.2 can forge a passing evaluation without needing to compromise the PED's logic itself; those records MUST be integrity- protected to a standard at least as strong as the PED's own decision logic. Execution Handles MUST be short-lived, single-scope, and non- bearer (i.e., bound to and unusable outside the requester identity and destination they were issued for) to limit the value of a captured handle. LAVR generation on both pass and fail outcomes is REQUIRED so that a rejected Candidate Act is not silently dropped in a way that hides a probing attack pattern. Das Expires 14 March 2027 [Page 15] Internet-Draft Data-Purpose Laundering Prevention September 2026 10. Privacy Considerations This architecture is itself a privacy control, but it introduces its own data: the PED's binding records, and the LAVR trail, together describe who requested what data for what purpose and when. That record is sensitive in its own right and access to it SHOULD be governed by the same purpose-binding discipline described in this document, to avoid recreating the original problem one layer up. Implementations SHOULD apply data minimization to LAVR contents -- recording that a check passed or failed and against which policy version, rather than the full content of the Candidate Act, where the Candidate Act's content is itself sensitive. 11. IANA Considerations This document has no IANA actions. 12. Acknowledgments None yet. 13. Resources [DAS-EU-AI-ACT] and [DAS-GLOBAL-PRIVACY] develop the execution- enforcement model summarized in this document in greater technical detail, including Candidate Acts, protected validation, scoped non- bearer authority, Finality Sink enforcement, and privacy and jurisdictional controls, together with deployment considerations not repeated here. Readers interested in the protocol mechanics are encouraged to review those drafts alongside [DAS-PRIVACY-FINALITY-IMPL], a runnable reference implementation of the privacy/purpose-enforcement path described in Section 5. [DAS-PRIVACY-FINALITY-IMPL]'s built-in demo enforces GDPR Article 5(1)(b) purpose limitation and AI Act-style technical enforcement obligations as one concrete instance of the general mechanism specified in this document. The demo models a customer support request scoped to CUSTOMER_SUPPORT (delivery_status, expected_delivery_date) and denies a resubmission of the same request under TARGETED_MARKETING before any Finality Sink effect is recorded -- the same Candidate Act / Protected Enforcement Domain / Finality Sink pattern this document describes, in regulation-agnostic form, as the delivery-address / advertising-profiling example in Section 5. The mapping between the two is direct: Das Expires 14 March 2027 [Page 16] Internet-Draft Data-Purpose Laundering Prevention September 2026 +====================================+=============================+ | Reference implementation | This document | +====================================+=============================+ | Candidate Act (canonical JSON, | Candidate Act (Section 2) | | SHA-256 digest) | | +------------------------------------+-----------------------------+ | Protected Enforcement Domain (PED) | Protected Enforcement | | | Domain (Section 2) | +------------------------------------+-----------------------------+ | Signed act-bound Validation Permit | Execution Handle, non- | | + workload proof-of-possession | bearer, scoped (Section 2) | +------------------------------------+-----------------------------+ | Finality Sink (independent re- | Finality Sink (Section 2) | | verification) | | +------------------------------------+-----------------------------+ | Denied TARGETED_MARKETING | Section 5.4, relabeled / | | substitution | purpose-substituted request | +------------------------------------+-----------------------------+ Table 2: Mapping between the reference implementation and this document GDPR and the EU AI Act are the regulatory framing the reference implementation was built to demonstrate; the enforcement mechanism itself, as specified in this document, is regulation-agnostic and does not depend on any one jurisdiction's law. [DAS-PRIVACY-FINALITY-IMPL] explicitly disclaims that it decides whether a purpose is legally legitimate, whether consent is valid, or whether a controller satisfies any specific data-protection statute; it enforces machine-readable rules supplied to it, which is the same scope this document claims for the architecture in Section 4. 13.1. Primary Reference Implementation A second, purpose-built reference implementation, [DAS-PURPOSE-FINALITY-IMPL] (the primary reference implementation for this document), models the exact worked example in Section 5 directly rather than a GDPR-framed analogue: its baseline Candidate Act is a delivery-service request for address-619 to obtain a delivery destination for assigned-courier-6, and its principal negative- control test is an advertising-service requester submitting the same object under a permitted-looking declared_purpose ("delivery") while its authenticated requester, workload, operation, and destination are all substituted for the advertising path -- exercising Section 5.4 directly rather than by analogy. It additionally implements the Legitimacy and Authority Verification Record (LAVR) construct as a hash-chained, HMAC-authenticated decision log, and tests derived-data lineage propagation (Section 3.3) with both a positive control Das Expires 14 March 2027 [Page 17] Internet-Draft Data-Purpose Laundering Prevention September 2026 (permitted lineage) and two documented negative controls (a lineage- stripping limitation and a compromised trusted-binding-record limitation), rather than treating lineage enforcement as unconditionally solved. The primary implementation's validation package comprises 88 automated Python tests, 19 deterministic conformance vectors independently re-executed in Python, Go, and Node.js (57 total cross- language executions), and 2,000 seeded adversarial mutation trials (1,000 post-issuance field mutations, 500 purpose-relabel attacks, and 500 wrong-holder proof-of-possession attempts), all denied as expected. Measured local software latency (p95, recorded Linux/ x86-64 host) was benchmarked across three topologies: +========================+===========+==============================+ | Topology | p95 | Repository regression target | +========================+===========+==============================+ | In-process memory | 0.2106 ms | <= 5 ms | +------------------------+-----------+------------------------------+ | In-process SQLite/WAL | 0.2560 ms | <= 10 ms | +------------------------+-----------+------------------------------+ | Localhost HTTP | 2.1363 ms | <= 20 ms | | sidecar | | | +------------------------+-----------+------------------------------+ Table 3: Primary reference implementation p95 latency by topology As with [DAS-PRIVACY-FINALITY-IMPL], these are reference-software engineering regression targets measured on a single local host, not IETF protocol requirements, and not TEE, HSM, GPU, WAN, or production-system performance claims; the sidecar figure is localhost loopback and excludes any real network round-trip. The implementation's own documented residual risks -- an authorized recipient copying plaintext after legitimate release, a compromised PED, a maliciously modified trusted binding record, stripped derived- data lineage, and covert/side channels -- match the limitations already stated in Section 3.3 and Section 5.7, and are not resolved by this or any other implementation in this family. 13.2. Other Reference Implementations Other reference implementations from the same author, supporting companion drafts in the same execution-finality portfolio, are provided here for context and are not relied upon by this document's normative content: [DAS-HALLUCINATION-IMPL] (preventing AI hallucination-driven and other unauthorized actions), [DAS-EGRESS-IMPL] (precision-bounded location release), and [DAS-6G-IMPL] (execution finality for AI-native 5G/6G and O-RAN). Das Expires 14 March 2027 [Page 18] Internet-Draft Data-Purpose Laundering Prevention September 2026 14. Latency Characteristics (Non-Normative) This section reports measured, not projected, latency for the [DAS-PRIVACY-FINALITY-IMPL] reference implementation's three sequential stages -- PED validation (Section 5.2's checks), permit issuance plus workload proof-of-possession (the Execution Handle of Section 2), and Finality Sink verify-and-commit (the atomic effect record of Section 4) -- each timed within a single request iteration so the three figures compose into one end-to-end path, at 500 iterations, on the SME support-agent demo Candidate Act. Two runs are reported: the implementation's own published figures, and an independent re-run performed for this document on different hardware, as a sanity check rather than a replacement measurement. +=================+==========================+====================+ | Stage | Published median/p95/p99 | Independent re-run | | | | median/p95/p99 | +=================+==========================+====================+ | PED validation | 21.5 / 33.1 / 118.9 | 31.2 / 52.4 / 65.9 | +-----------------+--------------------------+--------------------+ | Permit + PoP | 95.1 / 145.1 / 338.1 | 120.1 / 154.0 / | | | | 190.5 | +-----------------+--------------------------+--------------------+ | Sink verify + | 271.4 / 371.9 / 499.7 | 335.4 / 385.9 / | | commit | | 459.9 | +-----------------+--------------------------+--------------------+ | End-to-end (sum | ~388.0 | ~486.7 | | of medians) | | | +-----------------+--------------------------+--------------------+ Table 4: PED / permit / sink latency, published vs. independent re-run (microseconds) Two observations follow directly from the data. First, the Finality Sink's atomic commit step (SQLite BEGIN IMMEDIATE plus unique-JTI replay check) dominates the total in both runs -- roughly 60-70% of end-to-end median latency -- not the cryptographic verification steps (signature check, proof-of-possession). This is consistent with the general expectation that the fail-closed, atomic finality boundary of Section 4 is the more expensive operation to make correct, not the identity or purpose checks upstream of it. Second, both runs land the end-to-end path under half a millisecond, which is the basis for describing this as a hot-path-suitable operation for interactive request/response flows, subject to Section 15's caveats about the sink's storage backend. Das Expires 14 March 2027 [Page 19] Internet-Draft Data-Purpose Laundering Prevention September 2026 As stated directly in the reference implementation and repeated here: this is a local Python microbenchmark on a single process, not a distributed-system or network-inclusive measurement, and it is NOT a protocol performance claim. It excludes network round-trip time between requester, PED, and Finality Sink when these run as separate services; excludes the cost of the binding-record lookups in Section 5.2's check table (the demo's vaults are in-process, not a networked identity/order/policy store); and excludes concurrency effects -- SQLite's single-writer model means throughput, not just per-request latency, is the binding constraint at production scale (see Section 15). A deployment claiming this latency profile MUST re-measure against its own storage backend, network topology, and binding-record sources before relying on these figures. 15. Feasibility and Legacy System Integration *Deployment topology.* The PED, the Execution Handle issuer, and the Finality Sink are logically separable and MAY run as one process, as a sidecar per protected service, or as independently administered services (a pattern already anticipated by [DAS-PRIVACY-FINALITY-IMPL]'s note that vaults/PED/sink state can move into separate processes, TEEs, HSMs, confidential VMs, or DPUs/ SmartNICs). The architecture is agnostic to which topology an adopter chooses; Section 14's figures were measured in-process and should be treated as a floor, not a ceiling, once a real network hop separates these components. *Cold path / hot path split.* Companion draft draft-das-execution- finality-protocol-layer-00 separates policy reasoning (which bindings apply, which policy version is current) from deterministic verification (does this specific Candidate Act satisfy those bindings). The former can be cached, precomputed, or evaluated asynchronously as records change; the latter is what Section 14 measures and is designed to stay on the interactive request path. Implementers SHOULD keep policy lookups (the "cold" work) out of the per-request hot path so that the Finality Sink's atomic commit remains the dominant, and only, per-request cost. *Throughput and storage backend.* The reference implementation's SQLite-backed replay/effect store uses a single-writer commit model; at the measured ~330-490 us per commit, a single Finality Sink instance backed by SQLite is bounded to roughly two to three thousand committed effects per second before write contention dominates. This is adequate for the SME demo's scale and NOT representative of a production deployment's requirements; a production Finality Sink SHOULD replace the single-writer store with a backend that supports concurrent atomic commit with equivalent replay-prevention guarantees (e.g., a transactional database cluster or an append-only ledger with Das Expires 14 March 2027 [Page 20] Internet-Draft Data-Purpose Laundering Prevention September 2026 unique-nonce enforcement), and MUST preserve the fail-closed, atomic- consume property of Section 5.2 when doing so -- a faster backend that weakens atomicity reintroduces the race this architecture exists to close. *Legacy system integration without a flag day.* This architecture is intended to be adopted incrementally, not as a wholesale replacement of existing access control: * It SHOULD be deployed as an additional enforcement point positioned at or behind an existing API gateway, service mesh, or authorization layer (OAuth, GNAP, internal ABAC), not as a replacement for those systems. Coarse-grained authentication and general access control continue to run unchanged; this architecture adds a finer-grained, purpose-and-lineage-aware check at the specific data objects and operations an adopter chooses to protect. * Adoption SHOULD proceed data-object-class by data-object-class. A newly protected class (e.g., delivery addresses, as in Section 5) is bound to policy and enforced from the moment it is onboarded; classes not yet onboarded continue to be served by whatever legacy access control already governs them. * An unmigrated resource MUST NOT be represented, in logs, dashboards, or documentation, as being under this architecture's enforcement. A resource with no binding record is not "permissively allowed" by this architecture -- it is simply outside its scope, and an adopter that fails to mark that distinction risks the false sense of security this document argues against in Section 3.1. * No retroactive protection is created for data already released under a legacy regime before onboarding. Section 5.7's residual limitation applies identically here: onboarding a data class going forward does not constrain copies already made under the prior regime. *Real-time bidding and other latency-constrained environments.* Real- time bidding (RTB) in programmatic advertising operates within an auction window commonly on the order of 100 milliseconds end-to-end across multiple participants (supply-side platform, ad exchange, and one or more demand-side platforms). This is among the tightest latency budgets this architecture might be applied to and deserves direct treatment rather than a general feasibility claim. Das Expires 14 March 2027 [Page 21] Internet-Draft Data-Purpose Laundering Prevention September 2026 Cross-referencing data across advertising systems -- combining signals from multiple sources to select or price an ad -- is a legitimate, economically load-bearing function of the industry and is not, by itself, the problem this document addresses. The problem is unauthorized cross-referencing: a system consuming a signal for a use it was never granted, the same reuse pattern illustrated with delivery data in Section 5.3. Removing an advertising system's ability to combine data in order to make it "safe" would eliminate the function the system exists to perform and would stall a significant share of the economic activity the industry depends on; that is not this document's goal. The goal is to make an authorized combination technically demonstrable, and an unauthorized one technically blocked, rather than leaving the boundary between the two resting entirely on a data-sharing agreement that no downstream system actually checks -- this architecture is offered as a way to make lawful cross-referencing verifiable, not as a way to stop cross- referencing. Whether this is achievable inside a 100ms RTB budget is a question of where in the bid path enforcement is placed, not whether enforcement is possible at all: * A per-bid Candidate Act evaluated against a live policy store, with a TEE remote-attestation round-trip inline in the bid path, is not compatible with a 100ms budget; the attestation handshake alone commonly consumes a large share of that budget on its own, independent of anything measured in Section 14. * Section 14's measurements (sub-millisecond PED validation, permit issuance, and Finality Sink commit) are achievable in-path only if the expensive part -- deciding whether a given combination of data sources is authorized for a given advertiser/publisher/purpose triple -- is treated as cold-path work, evaluated and cached well before any individual bid, and refreshed on a policy change rather than on every auction. What remains in the 100ms hot path is then the cheap, deterministic step: verifying that this bid's Candidate Act matches an already-issued, still-valid Execution Handle for this exact combination -- the sub-millisecond range Section 14 measured, not a fresh policy evaluation or a fresh attestation. * Under this split, the architecture does not ask an RTB system to slow its auction down to perform compliance work live; it asks the system to be able to produce, on demand, a verifiable record that a specific data combination used in a specific bid was covered by a specific, current authorization -- which is close to what a regulator asking for evidence of purpose-limitation compliance is already asking advertising companies to be able to produce, typically without machine-checkable evidence to offer today. Das Expires 14 March 2027 [Page 22] Internet-Draft Data-Purpose Laundering Prevention September 2026 An implementer that attempts to fit full live policy evaluation and attestation into the per-bid path will fail the latency budget and should not attempt to. An implementer that separates authorization (cold, cacheable, amortized across many bids) from verification (hot, sub-millisecond, per bid) has a credible path to a compliance record without materially affecting auction latency -- and a credible, auditable basis for arguing that its cross-referencing practice is lawful, rather than merely asserted to be. *Feasibility summary.* The mechanism itself -- Candidate Act, binding-record check, scoped Execution Handle, atomic Finality Sink commit -- is implementable with commodity components (a policy/record store, an Ed25519 signing service, and a transactional commit boundary) and does not require new hardware, though Section 5.5 notes that hardware-rooted attestation strengthens, without being required by, the workload-identity leg of Section 5.2's checks. The primary adoption cost is organizational rather than cryptographic: identifying which binding records (order state, recipient assignment, workload identity) an adopter's systems already maintain reliably, versus which must be newly built, since the PED's validity depends entirely on the trustworthiness of the records it checks against (Section 9). 16. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 17. Informative References [DAS-6G-IMPL] Das, S., "Execution-Finality for AI-Native 5G/6G and O-RAN -- Runnable Reference Implementation", GitHub repository, . Das Expires 14 March 2027 [Page 23] Internet-Draft Data-Purpose Laundering Prevention September 2026 [DAS-AGENTIC-ZEROTRUST-REFERENCE-IMPLEMENTATION] Das, S., "Execution Finality for AI Agents, GPUs, Confidential Computing, and Zero-Trust Automation", GitHub repository, . [DAS-AI-GOV-REFERENCE-IMPLEMENTATION] Das, S., "Execution-Finality Technical Enforcement for EU AI Act and AI Governance Constraints -- Runnable Reference Implementation", GitHub repository, . [DAS-DIGITAL-SOVEREIGNTY-REFERENCE-IMPLEMENTATION] Das, S., "Digital Sovereignty Without Data Localisation: Compute-Plane / Authority-Plane Execution Finality", GitHub repository, . [DAS-EGRESS-IMPL] Das, S., "Access Is Not Egress: Precision-Bounded Location Release -- Reference Implementation", GitHub repository, . [DAS-EU-AI-ACT] Das, S., "Technical Execution Enforcement for the EU AI Act", Work in Progress, . [DAS-FUTURIUM-DIGITAL-SOVEREIGNTY-ARTICLE] Das, S., "Protecting Europe: A Technical Foundation for Digital Sovereignty, Data Protection, and AI Governance", EU AI Alliance Futurium, . [DAS-GLOBAL-PRIVACY] Das, S., "Global Privacy Execution Enforcement", Work in Progress, . Das Expires 14 March 2027 [Page 24] Internet-Draft Data-Purpose Laundering Prevention September 2026 [DAS-GPU-CONFIDENTIAL-REFERENCE-IMPLEMENTATION] Das, S., "Execution Finality for GPU AI Accelerators and Confidential Workloads", GitHub repository, . [DAS-HALLUCINATION-IMPL] Das, S., "Preventing AI Hallucinations and Unauthorized Actions -- Runnable Reference Implementation", GitHub repository, . [DAS-HARDWARE-FINALITY-REFERENCE-IMPLEMENTATION] Das, S., "Hardware Execution Finality for AI and Autonomous Systems", GitHub repository, . [DAS-PRECISION-EGRESS] Das, S., "Precision-Bounded Egress", Work in Progress, . [DAS-PRIVACY-FINALITY-IMPL] Das, S., "Privacy Finality Reference Implementation", GitHub repository, . [DAS-PURPOSE-FINALITY-IMPL] Das, S., "Purpose-Execution-Finality Validator: Preventing Data-Purpose Laundering in AI Systems -- Runnable Reference Implementation", GitHub repository, . [DAS-RATS-MODEL-RELEASE-REFERENCE-IMPLEMENTATION] Das, S., "Execution Finality (RATS) for AI Model Release", GitHub repository, . [DAS-REFERENCE-IMPLEMENTATION-V010] Das, S., "Privacy Finality Reference Implementation, Release v0.1.0", GitHub repository, . Das Expires 14 March 2027 [Page 25] Internet-Draft Data-Purpose Laundering Prevention September 2026 [DAS-SECURITY-CROSS-DOMAIN-REFERENCE-IMPLEMENTATION] Das, S., "Execution-Finality Security for Agentic AI, Autonomous Systems, Cloud, Payments, Telecom, OS, and Robotics", GitHub repository, . [DAS-TOOL-BINDING-REFERENCE-IMPLEMENTATION] Das, S., "tool_use Is Not invoke(): Binding Execution- Finality to Agentic Tool-Call Interfaces and MCP", GitHub repository, . [FUTURIUM-PAPER-COMPLIANCE] Das, S., "From Paper Compliance to Technical Enforcement: Making GDPR and the EU AI Act Executable in the AI Era", EU AI Alliance Futurium, . [FUTURIUM-PURPOSE-LAUNDERING] Das, S., "Preventing Data-Purpose Laundering by Agentic AI: A Hardware-Rooted Pre-Effectuation Layer for GDPR Purpose Limitation and High-Risk AI Governance", EU AI Alliance Futurium, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8707] Campbell, B. and A. Bansal, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . Das Expires 14 March 2027 [Page 26] Internet-Draft Data-Purpose Laundering Prevention September 2026 [RFC9635] Richer, J. and F. Imbault, "Grant Negotiation and Authorization Protocol (GNAP)", RFC 9635, DOI 10.17487/RFC9635, October 2024, . Appendix A. Primary Reference Implementation -- Detailed Validation Methodology This appendix records the detailed validation methodology for the primary reference implementation ([DAS-PURPOSE-FINALITY-IMPL], Section 13.1), at a level of granularity beyond the summary given in Section 13.1. It is provided so that the specific test conditions, decision ordering, and negative controls behind the summary figures are independently inspectable. As throughout this document, these are reference-software engineering results, not protocol requirements. A.1. Recorded Test Environment The validation was executed once, on the following recorded environment; the repository does not claim these figures on Windows, macOS, ARM64, HSMs, TEEs, GPUs, DPUs, SmartNICs, confidential VMs, Kubernetes, WAN networks, or production advertising systems: +=================+===================================+ | Parameter | Recorded value | +=================+===================================+ | Validation date | 9 September 2026 | +-----------------+-----------------------------------+ | OS / kernel | Linux 6.18.35, x86-64, glibc 2.41 | +-----------------+-----------------------------------+ | CPU | Intel Xeon Platinum 8370C @ 2.80 | | | GHz (5 logical CPUs visible) | +-----------------+-----------------------------------+ | Python | 3.13.5 (GCC 14.2.0 build) | +-----------------+-----------------------------------+ | SQLite / | 3.46.1 / 3.5.5 | | OpenSSL | | +-----------------+-----------------------------------+ | Go / Node.js | 1.23.2 linux/amd64 / 22.16.0 | +-----------------+-----------------------------------+ | Benchmark timer | time.perf_counter_ns() | +-----------------+-----------------------------------+ Table 5: Recorded test environment Das Expires 14 March 2027 [Page 27] Internet-Draft Data-Purpose Laundering Prevention September 2026 A.2. Baseline Candidate Act, Binding Record, and Validation Context A deterministic baseline was used so every mutation could be compared against a known-valid act. The Candidate Act (act-001, policy version 38, 10-second validity window) requests obtain delivery destination on object address-619 for workflow delivery-order-842, from requester/workload delivery-service / delivery-workload, to destination assigned-courier-6, carrying declared_purpose: delivery. The matching external binding record independently authorizes the same object/workflow/requester/workload/operation/destination/policy- version tuple and is valid for 60 seconds. The declared_purpose field is deliberately treated as untrusted requester-supplied metadata, never as authorization evidence -- the central test in Appendix A.5.1 is whether relabeling it can rescue an unauthorized request; it cannot. The baseline validation context (authenticated requester/workload, order existence, object association, recipient assignment, binding store availability and integrity, attestation result, timeout flag) is independently varied in the negative tests below. A.3. PED Decision Sequence The PED applies a deterministic, fail-closed evaluation order; any earlier failure short-circuits to DENY with an associated failure LAVR, and later checks are not reached: 1. Validation timeout? 2. Binding store available? 3. Binding store integrity acceptable? 4. Binding record exists? 5. Candidate Act still fresh? 6. Binding record still fresh? 7. Binding revoked? 8. Policy version correct? 9. Requester identity correct? 10. Workload identity correct? 11. Protected object correct? 12. Workflow correct? 13. Operation permitted? 14. Destination permitted? 15. Workflow/order exists? 16. Object belongs to workflow? 17. Recipient assignment current? 18. Required attestation valid? Das Expires 14 March 2027 [Page 28] Internet-Draft Data-Purpose Laundering Prevention September 2026 Only after all eighteen checks succeed is the result ALLOW. A key architectural test verifies that attestation_ok = true does not override an OPERATION_MISMATCH, REQUESTER_MISMATCH, DESTINATION_MISMATCH, or WORKLOAD_MISMATCH -- i.e., attested is not authorized. A.4. Execution Handle Lifetime Clamping With max_handle_ms = 2000, handle expiration is min(Candidate Act expiration, issuance time + 2000 ms). Boundary tests at candidate lifetimes of 0, 1, 10, 100, 1000, and 1999 ms from PED issuance time all produced a clamped handle; 2000 ms produced the maximum unclamped handle -- verifying the PED cannot issue a handle exceeding either its own configured maximum or the Candidate Act's own expiration. The handle itself binds handle_id, the Candidate Act digest, object, workflow, operation, requester, workload, destination, policy version, nonce, issuance/expiry times, and the proof-of-possession key ID -- i.e., authorization for this exact act under this exact binding state, not general access. A.5. Mutation and Threat-Model Testing Canonical JSON serialization (sorted keys, no incidental whitespace, UTF-8, deterministic separators) is SHA-256 hashed to produce the Candidate Act digest, so any load-bearing field change alters the digest. Two independent mutation surfaces were tested: * *Post-issuance mutation* (handle already issued): each of object, workflow, operation, destination, requester, workload, declared purpose, nonce, and policy version was individually mutated after issuance; every case produced ACT_DIGEST_MISMATCH, since the previously issued handle no longer matches the altered act's digest. * *PED-side mutation* (before issuance): the same fields were mutated before the PED evaluated the act; each independently produced its corresponding *_MISMATCH denial (e.g., requester, workload, object, workflow, operation, or destination mismatch). A.5.1. Purpose-Relabel Attack The principal threat-model test: an advertising requester/workload submits an act for operation infer household income against destination advertising-profile-database, but writes declared_purpose: delivery. Result: DENY, because the external binding record still reflects the delivery requester/workload/operation/destination tuple -- the purpose-string relabel does not change those externally-held facts. This was Das Expires 14 March 2027 [Page 29] Internet-Draft Data-Purpose Laundering Prevention September 2026 additionally tested against several plausible-sounding purpose strings (customer_support, legitimate_interest, consent, security, fraud_prevention), all denied with OPERATION_MISMATCH, and conversely the legitimate delivery act was tested with several different declared-purpose values (including DELIVERY, targeted_marketing, an empty string, and a 128-character arbitrary string) and remained allowed in every case, confirming the decision is driven by the binding relationship, not the spelling of the purpose field in either direction. A.5.2. Additional Negative-Control Conditions Further independently-tested failure conditions and their results: +================================+==================================+ | Condition varied | Result code | +================================+==================================+ | Attestation required but false | ATTESTATION_FAILURE | | (with otherwise-valid act) | | +--------------------------------+----------------------------------+ | Attestation true but operation | OPERATION_MISMATCH (attested is | | still unauthorized | not authorized) | +--------------------------------+----------------------------------+ | Binding store unavailable | BINDING_STORE_UNAVAILABLE | +--------------------------------+----------------------------------+ | Binding store integrity | BINDING_STORE_INTEGRITY_FAILURE | | uncertain | | +--------------------------------+----------------------------------+ | Binding record missing | NO_BINDING_RECORD | +--------------------------------+----------------------------------+ | Candidate Act / binding record | CANDIDATE_EXPIRED / | | / handle expired | BINDING_EXPIRED / | | | HANDLE_EXPIRED | +--------------------------------+----------------------------------+ | Binding revoked | BINDING_REVOKED | +--------------------------------+----------------------------------+ | Policy version incorrect (0, | POLICY_VERSION_MISMATCH (every | | 1, 37, 39, 40, 1000 tested) | value) | +--------------------------------+----------------------------------+ | Workflow missing / object | WORKFLOW_NOT_FOUND / | | association broken / recipient | OBJECT_ASSOCIATION_MISMATCH / | | assignment changed | RECIPIENT_ASSIGNMENT_MISMATCH | +--------------------------------+----------------------------------+ | Validation timeout forced | VALIDATION_TIMEOUT (not | | | interpreted as permission) | +--------------------------------+----------------------------------+ Table 6: Additional negative-control test conditions Das Expires 14 March 2027 [Page 30] Internet-Draft Data-Purpose Laundering Prevention September 2026 A.5.3. Derived-Data Lineage A derived object (income-estimate-52, sourced from address-619) submitted by the advertising requester for write advertising profile is deliberately given a binding record that would otherwise allow the write, so the PED issues a valid Execution Handle; the Finality Sink independently checks source_lineage against the protected lineage rule (which permits address-619 only for the delivery operation/ destination) and denies with LINEAGE_RESTRICTION_MISMATCH even though a valid handle exists -- confirming the sink remains independently load-bearing rather than trusting a prior PED ALLOW. A positive control (the same lineage attached to the legitimate delivery act) returns EFFECTUATED, confirming lineage presence alone is not a denial trigger. A documented negative control -- stripping source_lineage from the derived object before it reaches the sink -- results in EFFECTUATED, an intentionally disclosed limitation: lineage must be protected from stripping or independently reconstructable, or this control is bypassable. A.5.4. Trusted-Record Compromise A separate negative control deliberately rewrites the authoritative binding record itself to authorize the advertising operation; the PED (correctly, given its inputs) returns ALLOW. This is intentional: it demonstrates that a correct PED cannot compensate for corrupted authoritative truth, and that the binding-record system's integrity must be protected to at least the assurance level of the enforcement decision itself -- stated as a residual security assumption, not hidden. A.6. LAVR Generation, Chaining, and Tamper Detection Every PED decision (PASS or FAIL) generates a Legitimacy and Authority Verification Record (LAVR) containing a monotonic sequence number, the previous LAVR's hash, the Candidate Act digest, the PASS/ FAIL result and reason code, policy version, and timestamp, HMAC- authenticated as a body. The first LAVR's previous-hash field is 64 zero characters; each subsequent record's prev_hash is the SHA-256 of the prior LAVR, and the suite verifies sequence continuity, hash- chain continuity, and HMAC integrity. A deliberately tampered LAVR signature is correctly detected by chain verification. This is a local authenticated hash chain, not a public blockchain or distributed ledger. Das Expires 14 March 2027 [Page 31] Internet-Draft Data-Purpose Laundering Prevention September 2026 A.7. Replay and Concurrency Testing A valid Execution Handle used once returns EFFECTUATED; the identical handle reused returns REPLAY_DETECTED. Two replay backends were tested: an in-memory lock-protected set of consumed handle IDs, and a persistent SQLite/WAL-backed table keyed on handle_id (primary-key violation on reuse, transaction rolled back). Concurrency was tested directly rather than only sequentially: for the memory backend, five profiles (2/4/8/16/32 worker threads issuing 10/32/64/100/128 concurrent attempts against the same handle) each produced exactly one EFFECTUATED and (attempts - 1) REPLAY_DETECTED outcomes; for the SQLite backend, four profiles (2/4/8/16 threads, 8/16/32/64 attempts) produced the same exactly-one-success invariant. Persistence was additionally verified across a simulated restart: issue, consume, close the SQLite connection, reopen, and re-attempt the same handle -- REPLAY_DETECTED, confirming local persistent replay state (not distributed multi-node replay consensus, which remains out of scope). A.8. Cross-Language Conformance Nineteen deterministic conformance vectors (each a Candidate Act, binding record, validation context, expected decision, and expected SHA-256 Candidate Act digest) were independently re-implemented and executed in Python 3.13.5, Go 1.23.2, and Node.js 22.16.0, covering: baseline valid request; wrong requester/workload/object/workflow/operation/destination; changed- but-untrusted purpose only (still ALLOW); wrong policy version; revoked, expired, or missing binding; missing workflow; broken object association; changed recipient assignment; unavailable or integrity- failed binding store; attestation failure; and forced timeout. Each language independently canonicalizes, digests, and decides; results were 19/19 in all three languages (57 total executions of the 19 shared vectors -- not 57 distinct threats). This demonstrates that canonicalization, digest semantics, binding-record checks, decision ordering, and reason-code behavior can be implemented consistently across languages; it does not establish that the Go and Node conformance programs are complete production equivalents of the full Python reference (LAVR lifecycle, replay store, and PoP lifecycle remain primarily implemented in Python). A.9. Deterministic Adversarial Stress Testing A seeded (20260909), reproducible stress test outside the pytest suite ran 2,000 total trials in three groups: 1,000 post-issuance field mutations (a random load-bearing field replaced with a random value after handle issuance), 500 purpose-relabel attacks (advertising requester/workload/operation/ destination with a random 0-40-character purpose label), and 500 wrong-holder proof-of- Das Expires 14 March 2027 [Page 32] Internet-Draft Data-Purpose Laundering Prevention September 2026 possession attempts (proof generated with the non-bound holder key). All 2,000 trials were denied. This volume is reported separately from, not summed with, the 88 pytest cases and 57 cross-language executions, since the categories overlap conceptually and a combined "2,145 tests" figure would overstate distinct coverage. A.10. Latency by Topology, with Repeated Runs Three local software topologies were benchmarked, each with a fresh Candidate Act per iteration (avoiding replay-state contamination across iterations) and a distinct engineering regression target: +============+===========+======+======+======+======+=======+======+ | Topology | Warm-up |p50 |p95 |p99 |mean |max |Target| | | / | | | | | | | | | measured | | | | | | | +============+===========+======+======+======+======+=======+======+ | In-process | 300 / |0.1678|0.2106|0.2618|0.1796|3.0804 |<= 5 | | memory | 3,000 |ms |ms |ms |ms |ms |ms | +------------+-----------+------+------+------+------+-------+------+ | In-process | 200 / |0.1987|0.2560|0.3841|0.2147|2.7283 |<= 10 | | SQLite/WAL | 2,000 |ms |ms |ms |ms |ms |ms | +------------+-----------+------+------+------+------+-------+------+ | Localhost | 100 / |1.4670|2.1363|3.7796|1.5826|10.5086|<= 20 | | HTTP | 1,000 |ms |ms |ms |ms |ms |ms | | sidecar | | | | | | | | +------------+-----------+------+------+------+------+-------+------+ Table 7: Primary latency run by topology Each topology's p95 was additionally repeated three further times to avoid accepting a single favorable run: memory 0.2154-0.2424 ms, SQLite 0.2605-0.4145 ms, HTTP sidecar 2.0291-2.3466 ms across the three repeats, every repeat remaining under its target. One HTTP- sidecar repeat recorded a maximum latency of 47.9501 ms (retained, not discarded as an inconvenient outlier) while its p95 remained 2.2572 ms -- illustrating that an isolated scheduler/runtime pause can inflate the maximum without moving the percentile figures the targets are defined against. The HTTP-sidecar figures are localhost loopback only and exclude any real network round-trip, remote policy lookup, or remote attestation. Das Expires 14 March 2027 [Page 33] Internet-Draft Data-Purpose Laundering Prevention September 2026 A.11. What the Testing Supports, What It Does Not, and Residual Risks On the recorded Linux/x86-64 environment, the evidence supports the bounded claim that the Candidate Act -> external-binding-validation -> LAVR -> scoped non-bearer handle -> holder proof -> independent Finality Sink -> atomic single-use effectuation path executed correctly under the tested threat, mutation, concurrency, storage, language, and local-topology variations, within the repository's own p95 regression thresholds. It does not establish that all implementations of this pattern are secure; that production systems will see sub-millisecond or WAN-equivalent latency; that TEE/HSM latency matches this software path; that lineage can never be stripped; that the authoritative binding database cannot itself be compromised; that plaintext cannot be copied after legitimate release; that covert channels are prevented; that the protocol is formally verified; or that the architecture by itself establishes legal compliance. +====================================+==========================+ | Residual risk | Status | +====================================+==========================+ | Authorized recipient copies | Not solved by source- | | plaintext after legitimate release | side finality alone | +------------------------------------+--------------------------+ | PED itself compromised | Outside the PED's own | | | protection | +------------------------------------+--------------------------+ | Trusted binding record maliciously | Can produce a false PASS | | modified | (Appendix A.5) | +------------------------------------+--------------------------+ | Derived lineage stripped before | Sink may lose provenance | | the sink | | +------------------------------------+--------------------------+ | Side/covert channel inside | Not solved | | authorized computation | | +------------------------------------+--------------------------+ | Human screenshot/observation of | Not solved | | released data | | +------------------------------------+--------------------------+ | Software-held test key compromise | Reference-implementation | | | limitation | +------------------------------------+--------------------------+ | SQLite single-host replay/effect | Not hyperscale evidence | | store | | +------------------------------------+--------------------------+ Table 8: Main residual risks (documented, not hidden) Das Expires 14 March 2027 [Page 34] Internet-Draft Data-Purpose Laundering Prevention September 2026 These match, and do not extend, the limitations already stated for the architecture generally in Section 3.3 and Section 5.7. Recommended next-level validation, replacing one software assumption at a time with a real deployment component, includes: a protected or cryptographically signed external binding-record store; a non- exportable holder proof-of-possession key; HSM- or TEE-backed handle signing; a replicated transactional replay/effect database; real service-mesh/API-gateway integration; remote-attestation freshness and revocation integration; protected lineage propagation through a real computation pipeline; network-partition and stale-replica fault injection; sustained concurrency/throughput measurement at production scale; and an independent interoperable implementation built solely from the published conformance vectors. A.12. Reproduction The validation package's expected primary results are 88 passed Python tests; 19/19 conformance vectors in each of Python, Go, and Node.js; and 1,000/1,000, 500/500, and 500/500 denied outcomes for the three deterministic stress groups of Appendix A.9, reproducible via the commands and version pins published alongside [DAS-PURPOSE-FINALITY-IMPL]. Author's Address Sangam Kumar Das Independent Inventor Balasore Odisha India Email: info@sangamdas.com Das Expires 14 March 2027 [Page 35]