| Internet-Draft | AIPREF Grant Binding | October 2026 |
| Wallace | Expires 30 April 2027 | [Page] |
The AI Preferences (AIPREF) vocabulary lets those with rights in a digital asset express preferences -- for example, that training of AI models is disallowed -- about how automated systems process that asset. Such a preference expresses a reservation. It does not, by itself, provide a verifiable, revocable record of a specific grant that lifts a preference for a specific party.¶
This document describes that gap and proposes a candidate mechanism: a cryptographically signed, offline-verifiable credential that expresses a grant referencing an AIPREF usage category and a specific asset, that any party can verify without contacting the grantor, and that the grantor can revoke. It is intended as a starting point for discussion, not as a finished specification.¶
The mechanism is preference-general. Training is used throughout as the worked example because it is the reservation most widely discussed, but nothing in the construction is specific to it: the credential binds whichever usage category was reserved to a named party, and the same procedure applies to any other category the vocabulary expresses. What the mechanism establishes is that a grant exists, is authentic, and was in force and unrevoked at a stated evaluation time -- or that the evidence available does not determine this, which it reports as a distinct outcome rather than guessing. It does not adjudicate whether the grantor had standing to grant, and it is not an enforcement or access-control mechanism.¶
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 30 April 2027.¶
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.¶
The AI Preferences vocabulary [AIPREF-VOCAB] defines a machine-readable way to express preferences about how automated systems process a digital asset. Each usage category (for example, "train-ai" or "ai-use") is assigned a value such as "allowed" or "disallowed". A preference of "train-ai=disallowed" is a standing statement of intent by a party with rights in the asset: a reservation.¶
Preferences describe a default posture toward the world. They do not express what a specific party has been permitted to do. When a rights holder does permit a specific use by a specific party -- under a license, a negotiated agreement, or otherwise -- there is at present no interoperable, verifiable way to express and check that grant. This produces three operational problems:¶
Informally: an AIPREF preference is the lock; what is missing is a verifiable key, and a receipt for it that survives inspection later. This document sketches that missing piece as a signed, revocable credential that sits on top of the AIPREF vocabulary rather than replacing it, and asks where such a mechanism belongs.¶
This document does not propose changes to the AIPREF vocabulary itself, nor does it assert that a preference is legally binding or that any particular use is or is not permitted absent a grant. Those questions are out of scope.¶
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.¶
A grant references an AIPREF usage category by its label (for example "train-ai" from [AIPREF-VOCAB], or a category introduced through that document's vocabulary-extension mechanism). A grant is scoped to a tuple of (asset, category, grantee, validity period). A grant that asserts "allowed" for a category lifts a "disallowed" preference for that category for the named grantee only; it makes no statement about any other party.¶
The vocabulary's current revision (draft -08 at the time of writing) defines three usage categories -- AI Training ("train-ai"), AI Use ("ai-use"), and Search ("search") -- and scopes the first two to generative AI models. A grant names a category by the label the vocabulary assigns it and lifts that category only; the mechanism makes no assumption about how the vocabulary defines, scopes, or revises its categories. A rights holder that has reserved more than one category and wishes to lift more than one for a grantee issues a grant naming each.¶
The vocabulary itself anticipates arrangements of this kind. Section 5.2 of [AIPREF-VOCAB] observes that contractual agreements or other specific arrangements might override statements of preference, and that where arrangements exist that explicitly permit the use of an asset, those arrangements likely apply despite a machine-readable statement of preference. A grant is a machine-checkable record that such an arrangement exists, for a named party and a named asset; it is the verifiable form of the override the vocabulary already contemplates.¶
Grants and preferences are therefore complementary layers. The preference is authored by the rights holder as a standing signal; the grant is a discrete, verifiable exception issued to a specific party. A verifier that observes both applies the grant in preference to the standing preference for the named grantee, and applies the standing preference otherwise.¶
This document does not require AIPREF to define any new category to carry grants. It observes only that a category value MAY be lifted, for a named grantee, by a grant that the grantee can present and any verifier can check.¶
Preferences and grants also differ in how they are distributed. AIPREF preferences are typically attached to content and expressed to the world -- for example through robots.txt or HTTP header fields -- as a broadcast, party-agnostic signal of a default posture. A grant is not distributed that way: it is a signed artifact bound to a named grantee, held and presented by that grantee (or retrieved by reference), and checkable by any verifier without being attached to the content or announced to the world. A grant therefore complements a content-attached preference rather than competing with it: the preference is the broadcast reservation; the grant is the verifiable, per-party exception.¶
A grant is a unilateral artifact: it is signed by the grantor alone. A separate class of mechanism expresses a bilateral agreement -- an offer made and accepted, signed by both parties. VDAC [VDAC] is one such mechanism. Grants and bilateral contracts are complementary layers, and they compose: a contract MAY carry a grant as one of its terms.¶
A contract carries a grant by reference. It names the grant with a type token -- for example "verifiable-grant" -- whose meaning is the resolution-and-verification procedure of Section 5; it identifies the grant by the grant's resolvable identifier (Section 4.1); and it pins the specific artifact by a cryptographic digest, expressed using the Digest Fields representation [RFC9530]. The digest is computed once, by the party that issues the contract, which retrieves and hashes the credential when the contract is formed. The contract itself neither resolves nor interprets the grant: it carries the reference and the digest. Resolution and verification belong to a receiver, at use: a receiver that can process a carried grant reference retrieves the grant, confirms the digest, and verifies it per Section 5, including revocation under the as-of-use rule (Section 6.1). The contract establishes which document is carried; this document establishes whether it is valid, and as of when.¶
A grant names its grantee by a resolvable identifier (Section 4.1). It does not, by itself, establish who is presenting it now. The layer that carries a grant -- a bilateral contract, or the transport over which the grant is presented -- authenticates a presenting party and names that party by an identifier of its own. A composition that carries a grant MUST require that the authenticated presenting party's identifier correspond to the grant's grantee identifier, and MUST state at which point the correspondence is checked -- at the latest, when the receiver decides whether to act on the carried grant. A recorded agreement alone does not establish who is presenting a grant: the agreement names the parties, the authenticating layer establishes who is present, and the correspondence check joins the two. How the presenting party is authenticated is a property of that layer, not of the grant; the grant carries no request-time binding of its own (Section 7).¶
Revocation composes across the two layers without conflict. A bilateral contract, once signed, is an immutable record that an agreement was reached; revoking a grant carried within it does not un-sign the contract. The grant's own status list carries the revocation, which the contract references. A grant marked revoked is void from the time of revocation forward, while the fact that the contract was agreed remains true. The two layers answer different questions -- what was agreed, and whether a carried grant still applies -- and both remain independently checkable.¶
A grant is expressed as a Verifiable Credential [VC-DATA-MODEL], secured as a JSON Web Signature per [VC-JOSE-COSE], with the JWS header parameters "typ: vc+jwt" and "cty: vc". It carries at least:¶
A grant MUST be signed by the grantor's key. A grant MUST identify the asset by content digest. A grant SHOULD carry a revocation reference; a grant without one cannot be withdrawn after issuance.¶
The following is the (unsecured) JSON [RFC8259] payload of a grant that permits "train-ai" of a specific asset to a named grantee for one year. In transit it is secured as a JWS per [VC-JOSE-COSE].¶
{
"@context": ["https://www.w3.org/ns/credentials/v2"],
"id": "https://publisher.example/grants/abc123",
"type": ["VerifiableCredential", "AIUsageGrantCredential"],
"issuer": "did:web:publisher.example",
"validFrom": "2026-07-01T00:00:00Z",
"validUntil": "2027-07-01T00:00:00Z",
"credentialSubject": {
"asset": {
"id": "urn:asset:sha-256",
"digest": "sha-256:0f7e...c19a"
},
"grantee": "did:web:ai-lab.example",
"usage": [
{ "category": "train-ai", "value": "allowed" }
]
},
"credentialStatus": {
"type": "BitstringStatusListEntry",
"statusPurpose": "revocation",
"statusListIndex": "94",
"statusListCredential": "https://publisher.example/status/1"
}
}
¶
The "category" value ("train-ai") is an AIPREF category [AIPREF-VOCAB]. The "value" ("allowed") lifts a "disallowed" preference for that category, for the named grantee, over the validity period, unless the grant has been revoked.¶
A verifier evaluates a grant at an evaluation time. The evaluation time is the current time when the verifier is deciding whether to act on the grant now, and the stated time of a past use when the verifier is evaluating that use -- for example, an auditor asking whether a use was permitted when it occurred. The procedure is the same in both cases; only the time differs. In particular, a grant that expired or was revoked after a use remains valid for that use.¶
To evaluate a grant, a verifier:¶
Verification has three outcomes:¶
Indeterminate is a statement about the evidence, not about the grant: the grant may or may not have been revoked at the evaluation time, and the verifier cannot tell from what it holds. A verifier MUST NOT report an indeterminate outcome as valid, and MUST report it distinctly from invalid. What a consumer then does with an indeterminate outcome -- treat it as invalid, seek further evidence, or accept it under its own policy -- is a matter of that consumer's trust policy, outside this procedure.¶
Verification requires no interaction with the grantor beyond fetching the (cacheable) issuer key and status list, and can be performed offline against cached copies.¶
A grantor withdraws a grant by updating the referenced status list so that the grant's entry indicates revocation. Verifiers observe the change the next time they refresh the status list, bounded by their cache policy. Revocation lets a rights holder end a permission after issuance -- a property that a standing preference change alone cannot provide for permissions already relied upon. Revocation is monotonic: a status list using the "revocation" status purpose [BITSTRING] only ever moves a grant's entry from valid to revoked, never back.¶
The relevant time for a revocation check depends on the question being asked. A verifier deciding whether to act on a grant now checks the current status list: the question is whether the grant is revoked at present. A verifier instead evaluating a past use -- for example an auditor asking whether a use was permitted at the time it occurred -- asks a different question, and the relevant time is the time of that use, not the present.¶
Because a grant may be validly relied upon and only later revoked, checking a past use against the current status list would incorrectly report the use as unpermitted whenever the grant was revoked after the use. A verifier evaluating a past use therefore checks revocation status as of the time of use. This is the as-of-use rule.¶
As-of-use evaluation is supported by issuer-signed snapshots of the status list. A snapshot is a point-in-time statement: it records the revocation state as of the time at which the issuer signed it, and says nothing about the state at any other time. A snapshot signed at the time of use establishes the state at that time, independently of the current list.¶
A snapshot is itself a credential and carries its own validity period. That period states when the snapshot may be relied upon; it is not a statement that the revocation state was unchanged throughout the period, and a verifier MUST NOT treat it as one.¶
Where no snapshot was signed at the time of use, snapshots signed before and after it may still decide the question. Because revocation is monotonic (Section 6), the evidence is asymmetric:¶
Where neither decisive rule applies, available snapshots may bound a possible changeover interval on one or both sides; they need not establish that revocation occurred. A bound on either side requires an actual snapshot: the start of a grant's validity period is not an unrevoked observation. For example, an unrevoked snapshot at time 0 and a revoked snapshot at time 10 are consistent both with revocation at time 3 and with revocation at time 7, and a use at time 5 has a different status in each.¶
Unless other authenticated evidence resolves the question, any use whose revocation status is not established remains indeterminate (Section 5). Such evidence could be an authenticated statement from the issuer of the time at which a revocation took effect, or of the revocation state throughout an interval containing the time of use; this document defines neither, and a status list entry records that a grant is revoked, not when.¶
An issuer that wishes its past revocation state to be checkable SHOULD sign and retain status-list snapshots at regular intervals. Retained snapshots narrow the interval within which a revocation can be placed; they do not close it. A use that falls between the latest unrevoked snapshot and the earliest revoked one remains indeterminate.¶
This document is a discussion starter. The mechanism in Section 4 is one candidate, not a final design. The author invites discussion of the following in particular:¶
A grant proves who issued it, when, and what was declared. It does not attest that the grantor holds the rights it purports to grant: anyone in possession of an asset can compute its digest and issue a self-asserted grant over it. A verifier therefore MUST evaluate whether it trusts the issuer for the asset in question; the signature establishes the issuer's identity and the integrity of the declaration, not the truth of the underlying claim. Mechanisms for establishing that an issuer is authoritative for an asset are out of scope for this document.¶
Because a grant identifies its asset by content digest and does not carry the content, presenting a grant does not disclose the asset. Verifiers MUST confirm the digest matches the content actually processed; a grant for one asset says nothing about another.¶
Revocation is only as timely as verifiers' status-list refresh policy; a verifier relying on a stale cache may act on a revoked grant. Grants SHOULD carry a validity period so that a lost or unreachable status list does not extend a grant indefinitely.¶
An indeterminate outcome (Section 5) is not a weaker form of valid. A consumer whose trust policy accepts an indeterminate outcome accepts the possibility that the grant had been revoked before the use; a consumer that treats it as invalid may reject uses that were in fact permitted. Both are policy choices. The verification procedure reports the state of the evidence and takes neither. Only the issuer can supply evidence that resolves an indeterminate case (Section 6.1), so a consumer that defers resolution is relying on the issuer.¶
A grant presented by a party other than its named grantee is not thereby invalid, but it establishes nothing about that party. The correspondence check in Section 3 is what connects a presented grant to the party presenting it; a receiver that acts on a carried grant without that check is acting on a document, not on a permission held by its counterparty.¶
This document has no IANA actions. Should the mechanism advance, a registry for the credential "type" and any grant-specific fields would be considered at that time.¶
This section is to be removed before publishing as an RFC.¶
Songbo Bu identified the inconsistency between the verification procedure's time check and the as-of-use rule, the missing conditional in the snapshot evidence, and the gap that point snapshots leave between them, and proposed the indeterminate outcome. Srecko Jovancevic's work on VDAC shaped the composition with bilateral contracts.¶