Verifiable Compliance Records for AI Usage Preferences
draft-reilly-aipref-compliance-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Lawrence John Reilly Jr | ||
| Last updated | 2026-08-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-reilly-aipref-compliance-00
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", RFC 7638, September 2015,
<https://www.rfc-editor.org/info/rfc7638>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, December 2021,
<https://www.rfc-editor.org/info/rfc9162>.
[RFC9421] Backman, A., Richer, J., and M. Sporny, "HTTP Message
Signatures", RFC 9421, February 2024,
<https://www.rfc-editor.org/info/rfc9421>.
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,
<https://datatracker.ietf.org/doc/draft-ietf-aipref-
vocab/>.
[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,
<https://datatracker.ietf.org/doc/draft-ietf-scitt-
architecture/>.
[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,
<https://datatracker.ietf.org/doc/draft-meunier-web-bot-
auth-architecture/>.
[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,
<https://datatracker.ietf.org/doc/draft-reilly-plants-
bulk-subtree-proofs/>.
[RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
Record Syntax (ERS)", RFC 4998, August 2007,
<https://www.rfc-editor.org/info/rfc4998>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
[RFC9309] Koster, M., Illyes, G., Zeller, H., and L. Sassman,
"Robots Exclusion Protocol", RFC 9309, September 2022,
<https://www.rfc-editor.org/info/rfc9309>.
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]