AI Preferences L. J. Reilly Internet-Draft Independent Intended status: Standards Track 2 August 2026 Expires: 3 February 2027 Verifiable Compliance Records for AI Usage Preferences draft-reilly-aipref-compliance-00 Abstract Work in the AI Preferences (AIPREF) Working Group defines a vocabulary for expressing preferences about how digital assets may be used by automated processing systems, together with mechanisms for attaching those preferences to content. Neither component provides a way for a processing entity to demonstrate that it observed an expressed preference, nor for a publisher or auditor to verify such a demonstration after the fact. This document defines the AI Usage Compliance Record (AUCR), a structure that binds a retrieved asset, the preference expression in force at the moment of retrieval, and the usage category the processing entity assigned to that asset. It defines an aggregation scheme that allows a processing entity to attest to very large numbers of records with a single signature, a proof mechanism that allows an individual publisher to audit only the records concerning its own assets, and a discovery mechanism for locating attestations and verification keys. The mechanism is deliberately confined to evidence: it makes claims of compliance falsifiable and non- repudiable, and takes no position on the legal effect of any preference or any record. 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 3 February 2027. Reilly Expires 3 February 2027 [Page 1] Internet-Draft AI Usage Compliance Records August 2026 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. The AI Usage Compliance Record . . . . . . . . . . . . . . . 6 4.1. Information Model . . . . . . . . . . . . . . . . . . . . 6 4.2. Disposition Values . . . . . . . . . . . . . . . . . . . 8 4.3. Serialization . . . . . . . . . . . . . . . . . . . . . . 8 5. Aggregation and Attestation . . . . . . . . . . . . . . . . . 9 5.1. Epoch Tree Construction . . . . . . . . . . . . . . . . . 9 5.2. Compliance Attestation . . . . . . . . . . . . . . . . . 9 6. Publisher Audit . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Requesting Records . . . . . . . . . . . . . . . . . . . 10 6.2. Proofs . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Verification . . . . . . . . . . . . . . . . . . . . . . 11 7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Binding to Request-Signing Identity . . . . . . . . . . . . . 12 9. Registration with a Transparency Service . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10.1. False Records . . . . . . . . . . . . . . . . . . . . . 13 10.2. Omission . . . . . . . . . . . . . . . . . . . . . . . . 13 10.3. Split-View and Equivocation . . . . . . . . . . . . . . 14 10.4. Key Compromise and Rotation . . . . . . . . . . . . . . 14 10.5. Audit Interface Abuse . . . . . . . . . . . . . . . . . 14 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12.1. Well-Known URI Registration . . . . . . . . . . . . . . 15 12.2. Media Type Registrations . . . . . . . . . . . . . . . . 15 12.3. AUCR Member Registry . . . . . . . . . . . . . . . . . . 15 12.4. AUCR Disposition Registry . . . . . . . . . . . . . . . 16 12.5. AUCR Preference Source Registry . . . . . . . . . . . . 16 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 Reilly Expires 3 February 2027 [Page 2] Internet-Draft AI Usage Compliance Records August 2026 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 14.1. Normative References . . . . . . . . . . . . . . . . . . 17 14.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Example Record in JSON Form . . . . . . . . . . . . 18 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction The AI Preferences (AIPREF) Working Group is chartered to standardize building blocks for expressing preferences about how content is collected and processed for the development, deployment, and use of Artificial Intelligence models. That work has two parts: a vocabulary of preference terms [I-D.ietf-aipref-vocab], and mechanisms for attaching an expression of those terms to content, including the Robots Exclusion Protocol [RFC9309], Well-Known URIs [RFC8615], and HTTP response header fields. Both parts are concerned with the publisher side of the exchange. A publisher can state a preference and can make that statement discoverable. What the publisher cannot do is determine whether the statement was read, which interpretation was applied to it, or what the processing entity subsequently did with the asset. Assertions of compliance are today made in corporate policy documents and public statements, at a level of granularity that cannot be checked against any particular asset and cannot be tested after the preference expression itself has changed. This asymmetry has consequences beyond the immediate dispute between publishers and model developers. A processing entity that behaves correctly has no means of distinguishing itself from one that does not. A publisher that suspects non-observance has no artifact to point to. An auditor, whether commercial, institutional, or regulatory, has nothing to audit. The result is that the preference expression carries the entire weight of the mechanism while supplying none of the evidence. This document specifies the missing evidentiary component. It defines a record that a processing entity produces at retrieval time, capturing what it fetched, what preference expression was in force when it fetched it, what the source of that expression was, and what usage category it assigned. Records are aggregated into a Merkle tree; the root of each epoch's tree is signed, producing a Compliance Attestation that covers an arbitrary number of records at constant cost. A publisher may request proofs for the records concerning its own assets without receiving, or being able to enumerate, records concerning anyone else's. Reilly Expires 3 February 2027 [Page 3] Internet-Draft AI Usage Compliance Records August 2026 The mechanism does not prevent a processing entity from producing a false record. It changes the character of the falsehood: a false AUCR is a signed, timestamped, publicly-anchored statement, retained indefinitely, that can be contradicted by evidence the publisher independently holds. This is the same posture adopted by Certificate Transparency [RFC9162], which does not prevent misissuance but makes misissuance discoverable and durable. 1.1. Scope and Non-Goals This document is confined to the production, aggregation, verification, and discovery of evidence. The following are explicitly out of scope: * The legal effect, enforceability, or interpretation of any preference expression, in any jurisdiction. This document takes no position on whether a preference creates an obligation. * Licensing, compensation, payment, or any other commercial arrangement between publishers and processing entities. * Enforcement. Nothing here blocks, throttles, or penalizes any party. * The vocabulary of preference terms itself, which is defined elsewhere. This document treats preference terms as opaque strings drawn from a registry it does not control. * Attestation of model internals, training procedures, dataset composition, or the presence or absence of a particular asset in a particular model. An AUCR concerns the disposition of an asset at the point of collection, not the downstream behavior of any model. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Asset: A digital resource retrieved over HTTP, identified in this document by the cryptographic digest of the representation actually received. Processing Entity: The party that retrieves an asset and applies Reilly Expires 3 February 2027 [Page 4] Internet-Draft AI Usage Compliance Records August 2026 some usage category to it. In practice this is the operator of a crawler, fetcher, or agent, and it is the party that produces AUCRs. Publisher: The party that serves an asset and expresses preferences about its use. Preference Expression: A statement of AI usage preferences attached to content by one of the mechanisms defined by the AIPREF Working Group. AI Usage Compliance Record (AUCR): The per-asset record defined in Section 4. Epoch: A bounded interval over which a Processing Entity collects AUCRs for aggregation into a single attestation. Compliance Attestation: A signed statement over the Merkle root of an epoch's AUCRs, defined in Section 5. 3. Overview The mechanism has four moving parts, in the order they occur. 1. *Record.* At the time it retrieves an asset, the Processing Entity constructs an AUCR. The record captures the digest of the retrieved representation, the digest and source of the preference expression that was in force, the usage category assigned, and the identity under which the retrieval was performed. 2. *Aggregate.* At the close of each epoch, the Processing Entity computes a Merkle tree over the epoch's AUCRs and signs the root, producing a Compliance Attestation. The cost of attestation is independent of the number of records. 3. *Publish.* The Processing Entity publishes its attestations, and the keys that verify them, at a well-known location on a domain it controls, and SHOULD register each attestation with a Transparency Service so that the sequence of attestations is itself append-only and auditable. 4. *Audit.* A Publisher, presenting evidence of authority over a set of asset locators, requests the AUCRs concerning those assets together with proofs of their inclusion in a published attestation. The Publisher compares each record against what it independently knows it served. Reilly Expires 3 February 2027 [Page 5] Internet-Draft AI Usage Compliance Records August 2026 The central design constraint is asymmetry of scale. A Processing Entity may retrieve billions of assets per epoch; a Publisher typically cares about a few thousand of its own. The aggregation and proof scheme in Section 5 and Section 6 is chosen so that attestation cost is constant for the Processing Entity and audit cost is proportional to the Publisher's own holdings rather than to the size of the log. A second design constraint is that preference expressions are mutable. A publisher may change its robots.txt or its response headers at any time, and disputes about compliance are frequently disputes about what the expression said at a particular past moment. An AUCR therefore records the digest of the expression source as retrieved, not merely the interpretation the Processing Entity drew from it. Where the Publisher retains its own history of that source, the two can be compared directly; where it does not, the recorded digest still binds the Processing Entity to a specific claim about what it saw. 4. The AI Usage Compliance Record 4.1. Information Model An AUCR is a map with the following members. Members marked REQUIRED MUST be present in every record. asset-digest (REQUIRED) A digest of the representation of the asset as received, computed over the octets of the response body after decoding of any content codings. The digest is carried together with an identifier of the hash algorithm used, drawn from the "Named Information Hash Algorithm Registry". Implementations MUST support SHA-256. asset-locator (REQUIRED) The URI from which the asset was retrieved. This member is informational with respect to identity: a URI does not uniquely determine a representation, and verification is performed against asset-digest. The locator is present so that a Publisher can select the records relevant to it. retrieval-time (REQUIRED) The time at which the response was received, expressed as an integer number of seconds since the epoch defined in [RFC8949]. Processing Entities SHOULD NOT record precision finer than one second; see Section 11. Reilly Expires 3 February 2027 [Page 6] Internet-Draft AI Usage Compliance Records August 2026 preference-source (REQUIRED) An indication of where the preference expression was obtained, drawn from the registry established in Section 12.5. Initial values distinguish expressions obtained from the Robots Exclusion Protocol, from an HTTP response header field on the asset response itself, from a Well-Known URI, and from within the asset representation. preference-source-digest (REQUIRED) A digest, computed as for asset-digest, over the octets of the preference expression source as retrieved. Where the source is a separately fetched resource such as a robots.txt file, this is a digest of that entire resource. Where the source is a header field value, it is a digest of the field value as received. Where no preference expression was found, this member MUST be present and MUST be the digest of the zero-length octet string. preference-source-time (OPTIONAL) The time at which the preference expression source was retrieved, where this differs from retrieval-time. A Processing Entity that caches robots.txt MUST include this member and MUST set it to the time of the cached fetch rather than the time of asset retrieval. preference-observed (REQUIRED) The set of preference terms the Processing Entity determined to be applicable to this asset, as a list of strings drawn from the AIPREF vocabulary. An empty list indicates that a source was consulted and no applicable preference was found. usage-category (REQUIRED) The usage category the Processing Entity assigned to the asset, expressed using the same vocabulary as preference-observed. This is the member that makes the record falsifiable: it is a positive claim about what the entity did, not merely about what it read. disposition (REQUIRED) One of the values registered in Section 12.4, summarizing the relationship between preference-observed and usage-category. The initial values are described in Section 4.2. agent-identity (REQUIRED) An identifier for the signing identity under which the retrieval was performed. Where the retrieval was authenticated using HTTP Message Signatures [RFC9421] in the manner described in Section 8, this member MUST be the JWK thumbprint [RFC7638] of the key used to sign the request. Reilly Expires 3 February 2027 [Page 7] Internet-Draft AI Usage Compliance Records August 2026 retention (OPTIONAL) A hint as to how long the Processing Entity intends to retain the asset. Absence of this member carries no meaning. 4.2. Disposition Values The disposition member exists so that a verifier can triage a large set of records without evaluating vocabulary semantics on each one. It is a summary and is not authoritative: where disposition and the pair (preference-observed, usage-category) disagree, a verifier MUST treat the pair as authoritative and the record as malformed. The initial values are: honored: An applicable preference was found and the assigned usage- category is permitted by it. no-preference: A preference source was consulted and contained no expression applicable to this asset. no-source: No preference source was available. A Processing Entity MUST NOT use this value where a source was available but was not consulted. superseded: An applicable preference was found, and the assigned usage-category is not permitted by it, and the Processing Entity asserts that it applied some other basis for the use. This document does not define what such a basis may be and takes no position on its validity. The value exists so that such cases are recorded rather than omitted; a Processing Entity that would otherwise suppress the record produces a weaker log than one that declares the divergence. There is deliberately no value meaning "not honored without further qualification". A record whose usage-category is not permitted by its preference-observed and whose disposition is honored is simply a false record, and the mechanism's purpose is to make such records durable and attributable rather than to provide a vocabulary for them. 4.3. Serialization An AUCR MUST be serialized as a CBOR map [RFC8949] using deterministically encoded CBOR as specified in Section 4.2.1 of that document. Member names are encoded as unsigned integers according to the registry in Section 12.3. Reilly Expires 3 February 2027 [Page 8] Internet-Draft AI Usage Compliance Records August 2026 The leaf value used in the aggregation of Section 5 is the digest of the deterministically encoded record, computed with the same hash algorithm used for the epoch's Merkle tree. Individual AUCRs are not separately signed; a record derives its authenticity entirely from the Compliance Attestation over the tree in which it is included. This is deliberate: per-record signatures at crawl scale are computationally prohibitive and provide no property that inclusion in a signed tree does not already provide. A JSON form of the record is given in Appendix A for human inspection and for use in audit interfaces. The JSON form MUST NOT be used as the input to any digest computation. 5. Aggregation and Attestation 5.1. Epoch Tree Construction A Processing Entity divides its activity into epochs. Epoch boundaries are a matter of local policy, subject to the constraint that an epoch MUST NOT exceed 24 hours of wall-clock time; longer epochs delay the availability of evidence to the point where the mechanism ceases to serve its purpose. Within an epoch, the Processing Entity computes a Merkle tree over the leaf digests of its AUCRs using the tree construction of [RFC9162], Section 2.1. Leaves MUST be ordered by the tuple (asset- locator authority component, asset-locator, asset-digest), compared as octet strings. Ordering by authority is what makes the audit mechanism of Section 6 efficient: all records concerning a single Publisher's origin occupy a contiguous range of leaves, and a proof over that range is a proof over a bounded set of complete subtrees rather than over each leaf individually. 5.2. Compliance Attestation At the close of an epoch, the Processing Entity produces a Compliance Attestation: a COSE_Sign1 structure [RFC9052] whose payload is a CBOR map containing the epoch identifier, the epoch's start and end times, the Merkle root, the leaf count, the hash algorithm identifier, and the identifier of the immediately preceding epoch's attestation. Including the predecessor identifier chains the sequence of attestations, so that a Processing Entity cannot silently remove a published epoch from its history. Reilly Expires 3 February 2027 [Page 9] Internet-Draft AI Usage Compliance Records August 2026 The attestation MUST be signed with a key that is discoverable by the mechanism in Section 7. The same key SHOULD be one of the keys the Processing Entity publishes for the purpose described in Section 8, so that the identity that performed the retrievals and the identity that attests to their disposition are provably the same. 6. Publisher Audit 6.1. Requesting Records A Publisher audits by requesting, for a given epoch, the AUCRs whose asset-locator authority component matches an origin over which it has demonstrated authority, together with proofs of their inclusion in the epoch's attested Merkle root. The Processing Entity MUST require a demonstration of authority over the requested origin before returning records. Any mechanism by which the requester proves control of the origin is acceptable; the mechanisms of [RFC8555], Section 8 are RECOMMENDED where an existing implementation is available. Records MUST NOT be returned to a requester that has not demonstrated authority over the origin named in the request, for the reasons given in Section 11. 6.2. Proofs Because leaves are ordered by authority as specified in Section 5.1, the records concerning a single origin occupy a contiguous leaf range. The Processing Entity MUST return the records in that range together with a proof that the range is included in the attested root. A verifier MUST be able to determine, from the proof alone, both that every returned record is included in the root and that no record in the range was withheld. A proof consisting of independent inclusion proofs for each returned leaf satisfies the former but not the latter: a Processing Entity could omit an unfavourable record and the remaining proofs would still verify. The proof MUST therefore establish the boundaries of the range, by including inclusion proofs for the leaves immediately preceding and following the range together with the returned records, so that a verifier can confirm the range is complete with respect to the ordering. For ranges spanning a large number of leaves, transmitting an independent inclusion proof per leaf is wasteful by a factor proportional to the tree depth. A bulk proof construction that tiles the range with complete subtrees and verifies by descent, such as that of [I-D.reilly-plants-bulk-subtree-proofs], reduces the proof to a number of nodes logarithmic in the size of the log rather than in Reilly Expires 3 February 2027 [Page 10] Internet-Draft AI Usage Compliance Records August 2026 the size of the range, and SHOULD be used where available. Support for per-leaf inclusion proofs as specified in [RFC9162] remains REQUIRED as a baseline. 6.3. Verification Having obtained records and proofs, a verifier MUST: 1. verify the signature on the Compliance Attestation for the epoch against a key obtained by the mechanism in Section 7; 2. verify that each returned record is included in the attested root, and that the returned range is complete; 3. for each record, recompute the digest of the representation it served, or consult its own history, and compare against asset- digest; 4. compare preference-source-digest against the digest of the preference expression source it served at the recorded time; 5. evaluate whether usage-category is permitted by preference- observed, and whether preference-observed is the correct interpretation of the source whose digest is recorded. Steps 3 and 4 require the Publisher to retain its own history. A Publisher that does not retain such a history can still verify steps 1, 2, and 5, and so can still detect an internally inconsistent record, but cannot detect a record that misstates what it was served. Publishers intending to rely on this mechanism SHOULD retain digests of served representations and of preference expression sources for at least as long as they intend to be able to audit. 7. Discovery A Processing Entity that produces Compliance Attestations MUST publish, at the Well-Known URI "/.well-known/ai-usage-compliance" [RFC8615] on a domain it controls, a JSON document containing: * the set of keys that verify its attestations, as a JWK Set [RFC7517]; * the identifier and location of the most recent attestation, and a means of enumerating prior attestations; * the URI of the audit interface described in Section 6; Reilly Expires 3 February 2027 [Page 11] Internet-Draft AI Usage Compliance Records August 2026 * optionally, the identifier of a Transparency Service with which attestations are registered. The domain at which this document is published MUST be the domain from which the Processing Entity's request signing keys are published, where Section 8 applies. This binds the compliance claim to the fetching identity at the level of domain control rather than assertion. 8. Binding to Request-Signing Identity Work in progress on authenticating automated traffic [I-D.meunier-web-bot-auth-architecture] applies HTTP Message Signatures [RFC9421] to requests made by crawlers and agents, with each operator publishing verification keys at a Well-Known URI on a domain it controls. Where a Processing Entity signs its requests in this manner, the two mechanisms compose directly and SHOULD be deployed together. The composition matters because the two mechanisms answer complementary questions and neither answers both. Request signing establishes who made a request but says nothing about what was done with the response. Compliance records describe what was done with a response but, standing alone, are assertions by a party whose identity at retrieval time was not established. A Publisher that verifies a request signature and later receives an AUCR recording the thumbprint of that same key in its agent-identity member has a chain from the observed request to the claimed disposition. Processing Entities SHOULD use the same key for request signing and attestation signing, or, where key separation is required by local policy, MUST publish both keys in the same JWK Set so that their common control is evident. 9. Registration with a Transparency Service Publication at a Well-Known URI is sufficient for verification but not for detecting equivocation: a Processing Entity that serves different attestations to different verifiers, or that rewrites its history, is not detectable by a verifier acting alone. A Processing Entity SHOULD therefore register each Compliance Attestation as a Signed Statement with a Transparency Service [I-D.ietf-scitt-architecture] and SHOULD publish the resulting Receipt alongside the attestation. Registration is RECOMMENDED rather than REQUIRED because the choice of Transparency Service is a matter of deployment policy and no single service can be assumed available to all parties. Verifiers Reilly Expires 3 February 2027 [Page 12] Internet-Draft AI Usage Compliance Records August 2026 MUST NOT treat the absence of a Receipt as evidence of misbehavior, but MAY apply local policy that declines to rely on unregistered attestations. Deployments requiring evidence to remain verifiable beyond the lifetime of the signing keys, or beyond the security lifetime of the signature algorithm, SHOULD additionally maintain evidence records as described in [RFC4998]. The hash-tree renewal procedure defined there applies to the epoch trees of Section 5.1 without modification. 10. Security Considerations 10.1. False Records Nothing in this document prevents a Processing Entity from producing a record that misstates what it did. This is the central limitation and it is not remediable by protocol design: the disposition of an asset inside a party's own systems is not externally observable, and any claim about it is ultimately an assertion by that party. What the mechanism provides is that the assertion is specific, signed, bound to a particular asset and moment, incorporated into an append-only history the entity cannot later revise, and contradictable by evidence the Publisher independently holds. A Processing Entity that produces false records at scale accumulates a durable body of signed statements, any one of which may later be shown false. Implementers and deployers should understand the mechanism as raising the cost and persistence of misrepresentation, not as establishing ground truth. 10.2. Omission A Processing Entity may simply not produce a record for an asset it retrieved. Omission is materially easier than falsification and the range-completeness requirement of Section 6.2 addresses it only partially: it prevents withholding a record from a returned range, not declining to create the record at all. Publishers can detect omission where they retain server logs correlated with the request-signing identity described in Section 8: a signed request from an identity that produces no corresponding record in the epoch covering that request is a detectable discrepancy. This detection is available only to Publishers who both verify request signatures and retain logs, and deployers relying on this mechanism should recognize that completeness of the log is only as strong as the Publisher's own records. Reilly Expires 3 February 2027 [Page 13] Internet-Draft AI Usage Compliance Records August 2026 10.3. Split-View and Equivocation A Processing Entity could publish one attestation to one verifier and a different attestation, over a different tree, to another. The predecessor chaining of Section 5.2 makes a single consistent history harder to fork silently but does not by itself prevent maintaining two histories. Registration with a Transparency Service (Section 9) is the primary mitigation; verifiers that require strong guarantees against equivocation SHOULD rely only on attestations for which a Receipt from a Transparency Service they trust is available, and SHOULD gossip observed attestation identifiers with other verifiers where a mechanism to do so exists. 10.4. Key Compromise and Rotation Compromise of an attestation signing key permits forgery of attestations and, transitively, of every record they cover. Because attestations are chained, a verifier that has previously observed a valid attestation can detect an attempt to substitute a forged history from the point of divergence, but cannot distinguish a forged branch from a genuine one without an external reference such as a Transparency Service Receipt. Key rotation is expected and is handled by publishing the new key in the JWK Set of Section 7 while retaining prior keys for the verification of historical attestations. A Processing Entity MUST NOT remove a key from the published set while any attestation signed with it remains within the period for which the entity offers audit. 10.5. Audit Interface Abuse The audit interface of Section 6 performs proof computation on demand and is therefore a candidate for resource exhaustion. Processing Entities SHOULD rate-limit audit requests per authenticated origin and MAY serve precomputed proofs for common ranges. The authority demonstration requirement of Section 6.1 also serves as an admission control mechanism. 11. Privacy Considerations A complete, publicly readable log of AUCRs would disclose the full retrieval inventory of the Processing Entity, which is commercially sensitive, and would also disclose which resources of a Publisher were retrieved and when, which the Publisher may not wish to expose to third parties. This is why records are released only to a requester that has demonstrated authority over the relevant origin (Section 6.1), and why only the Merkle root, and not the leaf set, is published. Reilly Expires 3 February 2027 [Page 14] Internet-Draft AI Usage Compliance Records August 2026 The Merkle root itself leaks the leaf count of the epoch, and therefore a coarse measure of retrieval volume. Processing Entities for which this is unacceptable MAY pad the tree with records whose asset-locator authority is a reserved value; such padding MUST NOT be placed within the leaf range of any real origin, as this would defeat the range completeness property of Section 6.2. Where assets are served to identified end users, the retrieval-time member can contribute to correlation between a Processing Entity's activity and an individual user's activity, particularly for user- triggered fetches as opposed to bulk crawling. This is the reason for the recommendation in Section 4.1 against sub-second precision. Processing Entities producing records for user-triggered retrievals SHOULD consider coarser time quantization, at the cost of some evidentiary precision. AUCRs concern assets, not people, and MUST NOT be used to carry information about the individual on whose behalf a retrieval was performed. 12. IANA Considerations 12.1. Well-Known URI Registration IANA is requested to register the following entry in the "Well-Known URIs" registry established by [RFC8615]: URI suffix: ai-usage-compliance Change controller: IETF Specification document: This document, Section 7 Status: permanent 12.2. Media Type Registrations IANA is requested to register the media type "application/aucr+cbor" for the record serialization of Section 4.3, and the media type "application/aucr-attestation+cose" for the Compliance Attestation of Section 5.2. The full registration templates will be supplied in a subsequent revision. 12.3. AUCR Member Registry IANA is requested to establish the "AI Usage Compliance Record Members" registry, with a registration policy of Specification Required [RFC8126]. Each entry comprises an integer key, a member name, a CBOR type, and a reference. Initial entries correspond to the members defined in Section 4.1, assigned integer keys 1 through 10 in the order presented there. Reilly Expires 3 February 2027 [Page 15] Internet-Draft AI Usage Compliance Records August 2026 12.4. AUCR Disposition Registry IANA is requested to establish the "AI Usage Compliance Record Dispositions" registry, with a registration policy of Specification Required. Initial entries are the four values defined in Section 4.2. 12.5. AUCR Preference Source Registry IANA is requested to establish the "AI Usage Compliance Record Preference Sources" registry, with a registration policy of Specification Required. Initial entries correspond to the sources described in Section 4.1 under preference-source. Additional entries are expected as the AIPREF Working Group defines further attachment mechanisms; the registry is deliberately separate from this document so that it can track that work without requiring revision here. 13. Open Issues This section is to be removed before publication. * The relationship between preference-observed and usage-category depends on the semantics the AIPREF vocabulary ultimately assigns to its terms, particularly with respect to the boundary between search and training uses. This document deliberately treats terms as opaque, but the disposition values of Section 4.2 assume a permits relation exists and is computable. If the vocabulary does not supply one, disposition may need to be reduced to a purely declarative member. * Whether attestation should cover retrieval or use is arguable. This document records the usage category assigned at retrieval, which is observable at the point where the record is made. A record of actual downstream use would be more informative and considerably less verifiable; the author considers the weaker, checkable claim to be worth more than the stronger, uncheckable one, but this is a design choice open to challenge. * The range completeness construction in Section 6.2 assumes stable ordering. Interaction with a log that admits late-arriving records within an epoch is unspecified and needs treatment. * Whether a single epoch tree should span all origins, or one tree per origin should be maintained, is a tradeoff between attestation cost and audit simplicity. The present design chooses a single tree; a per-origin variant would simplify proofs at the cost of signature volume. Reilly Expires 3 February 2027 [Page 16] Internet-Draft AI Usage Compliance Records August 2026 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, May 2015, . [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, September 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, May 2019, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, August 2022, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, December 2021, . [RFC9421] Backman, A., Richer, J., and M. Sporny, "HTTP Message Signatures", RFC 9421, February 2024, . 14.2. Informative References Reilly Expires 3 February 2027 [Page 17] Internet-Draft AI Usage Compliance Records August 2026 [I-D.ietf-aipref-vocab] Keller, P. and M. Thomson, "A Vocabulary For Expressing AI Usage Preferences", Work in Progress, Internet-Draft, draft-ietf-aipref-vocab, 2026, . [I-D.ietf-scitt-architecture] Birkholz, H., "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture, 2026, . [I-D.meunier-web-bot-auth-architecture] Meunier, T., "HTTP Message Signatures for automated traffic Architecture", Work in Progress, Internet-Draft, draft-meunier-web-bot-auth-architecture, 2026, . [I-D.reilly-plants-bulk-subtree-proofs] Reilly, L. J., "Bulk Subtree Consistency Proofs for Merkle Tree Certificates", Work in Progress, Internet-Draft, draft-reilly-plants-bulk-subtree-proofs, 2026, . [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence Record Syntax (ERS)", RFC 4998, August 2007, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, March 2019, . [RFC9309] Koster, M., Illyes, G., Zeller, H., and L. Sassman, "Robots Exclusion Protocol", RFC 9309, September 2022, . Appendix A. Example Record in JSON Form The following is a non-normative rendering of a single AUCR, given in JSON for readability. Digests are truncated for presentation. Reilly Expires 3 February 2027 [Page 18] Internet-Draft AI Usage Compliance Records August 2026 { "asset-digest": "sha-256:9f86d081884c7d659a2feaa0c55ad015...", "asset-locator": "https://example.com/articles/tide", "retrieval-time": 1785283200, "preference-source": "robots-exclusion", "preference-source-digest": "sha-256:2c26b46b68ffc68ff99b453c1d304134...", "preference-source-time": 1785279600, "preference-observed": ["train-ai=n", "search=y"], "usage-category": "search", "disposition": "honored", "agent-identity": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs" } The Publisher of example.com, auditing this record, checks that the digest of the representation it served at that URI matches asset- digest, that the digest of the robots.txt it served at 1785279600 matches preference-source-digest, that preference-observed is a correct reading of that file, and that a usage category of search is permitted by it. Each of these four checks can fail independently, and each failure identifies a different kind of problem. Acknowledgements This document builds on the framing of curation disclosure developed in the author's earlier work on cognitive sovereignty, and on the aggregation techniques developed for bulk subtree proofs. Author's Address Lawrence J. Reilly Independent Email: lawrencejohnreilly@gmail.com Reilly Expires 3 February 2027 [Page 19]