LicenseFoundry

NL wallace@licensefoundry.com

AI preferences text and data mining verifiable credentials licensing 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.

Introduction The AI Preferences vocabulary 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:

• a party acting on a permission cannot prove, to a third party, that it held that permission for a given asset on a given date;
• a rights holder that granted a permission cannot withdraw it in a way that downstream verifiers can observe; and
• a dispute over whether an asset was permitted for a use cannot be resolved on independently checkable evidence.

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.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

Preference:

An AIPREF value (e.g. "allowed"/"disallowed") assigned to a usage category for an asset, per .

Grant:

A statement that a named party is permitted a specific usage category for a specific asset, over a validity period, expressed as the credential defined in .

Grantor:

The party that issues (signs) a grant. Typically the rights holder or an authorised issuer acting on the rights holder's behalf.

Grantee:

The party a grant names as permitted.

Presenting party:

The party that presents a grant, or on whose behalf a grant is presented, in a given interaction. The presenting party is matched to the grantee by the layer that carries the grant ().

Verifier:

Any party that checks a grant -- for example an AI system, an auditor, a court, or a counterparty.

Evaluation time:

The point in time at which a grant is evaluated: the present, when a verifier is deciding whether to act on a grant now; or the stated time of a past use, when a verifier is evaluating that use ().

Relationship to the AIPREF Vocabulary A grant references an AIPREF usage category by its label (for example "train-ai" from , 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 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.

Relationship to Bilateral Contracts 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 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 ; it identifies the grant by the grant's resolvable identifier (); and it pins the specific artifact by a cryptographic digest, expressed using the Digest Fields representation . 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 , including revocation under the as-of-use rule (). 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 (). 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 (). 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.

The Grant Credential

Structure A grant is expressed as a Verifiable Credential , secured as a JSON Web Signature per , with the JWS header parameters "typ: vc+jwt" and "cty: vc". It carries at least:

• a resolvable identifier for the grant itself, so that a party holding a reference to the grant -- for example a contract that carries it () -- can retrieve the credential; typically an HTTPS URL;
• an issuer identifier that a verifier can resolve to a public key -- for example a "did:web" identifier resolvable over HTTPS;
• the asset the grant concerns, identified by a cryptographic content digest (e.g. SHA-256) so the grant binds to specific content without carrying the content itself;
• the grantee the grant names;
• one or more usage entries, each naming an AIPREF category and the granted value (e.g. "train-ai" = "allowed");
• a validity period (validFrom / validUntil); and
• a revocation reference, such as a Bitstring Status List entry, that a verifier can check.

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.

Example The following is the (unsecured) JSON 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 . The "category" value ("train-ai") is an AIPREF category . The "value" ("allowed") lifts a "disallowed" preference for that category, for the named grantee, over the validity period, unless the grant has been revoked.

Verification Procedure 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:

1. resolves the issuer identifier to a public key (for "did:web", by fetching the DID document over HTTPS ) and verifies the signature over the credential;
2. confirms the evaluation time is within the validity period;
3. determines the grant's revocation status as of the evaluation time, by checking the referenced status list under the as-of-use rule ();
4. confirms the asset digest matches the content in question, and that the category and grantee match the use and party at hand (where the grant is carried by a contract, the party is matched as described in ).

Verification has three outcomes:

Valid:

every check passes. A grant existed for that (asset, category, grantee) at the evaluation time, and the corresponding preference was lifted for that grantee at that time.

Invalid:

a check fails: the signature does not verify; the evaluation time is outside the validity period; the grant is established to have been revoked at or before the evaluation time; or the digest, category, or grantee does not match.

Indeterminate:

every other check passes, but the evidence available to the verifier does not establish the grant's revocation status as of the evaluation time (). For evaluation at the current time this arises when no status list can be obtained; for evaluation of a past use it arises as described in .

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.

Revocation 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 only ever moves a grant's entry from valid to revoked, never back.

As-of-Use Evaluation 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 (), the evidence is asymmetric:

• A snapshot signed at or after the time of use that shows the grant unrevoked establishes that the grant was not revoked at the time of use: a grant unrevoked later was unrevoked earlier.
• A snapshot signed at or before the time of use that shows the grant revoked establishes that the grant was revoked at the time of use: a grant revoked earlier is revoked later.

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 (). 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.

Discussion and Open Questions This document is a discussion starter. The mechanism in is one candidate, not a final design. The author invites discussion of the following in particular:

• Venue. The AI Preferences Working Group chairs have stated that this work is out of scope for the group under its current charter and that the group is not looking to take on more work at present. The author is therefore seeking venue guidance from the DISPATCH area, and invites views on where a grant layer above the vocabulary belongs.
• Should the AIPREF vocabulary define any hook that indicates a category value is conditional on, or may be lifted by, a grant -- or should grants remain entirely a separate layer, as sketched here? Any such hook would follow the vocabulary's own extension process and is a separate question from this mechanism.
• Is a Verifiable Credential the right container, or should a lighter or different encoding be preferred? This document uses VCs because they provide issuer identity, offline verification, and revocation as existing, interoperable building blocks, but does not assert they are the only viable choice.
• Grantee identity. A grant names its grantee by a resolvable identifier -- for example a "did:web" identifier. Where a grant is carried by a bilateral contract (), the composition is required to match the authenticated presenting party to the named grantee by identifier correspondence. Whether a grant should additionally carry its own request-time binding -- a proof that the presenter controls the grantee identifier -- is left open.
• Indeterminate outcomes. The third verification outcome () is new in this revision. Whether an effective time of revocation, or the revocation state throughout an interval, should be representable, so that a use falling between two snapshots can be resolved, is open. A time asserted by the issuer alone rests entirely on trust in the issuer, who may be a party to the question the time decides. A trusted timestamp, for example from a timestamping authority or a transparency log, is a possible ingredient but not a solution: under its own trust and policy assumptions it establishes that the bound data existed by a given time, not when a revocation took effect or that no earlier revocation was omitted. A future specification would need a grant-bound, authenticated revocation record, an explicit rule connecting its trusted registration to the operative revocation time, and a clear statement of the trust it still places in the issuer.

Security Considerations 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 () 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 (), 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 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.

IANA Considerations 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.

References Normative References W3C W3C Informative References W3C Credentials Community Group W3C

Changes Since -02

• Verification (): the evaluation time is now a parameter of the procedure -- the current time when acting on a grant, the stated time of use when evaluating a past use -- and step 2 checks the validity period against it rather than against the current time, which in -02 contradicted the as-of-use rule for past uses.
• Verification: a third outcome, indeterminate, is defined for the case where the evidence does not establish revocation status as of the evaluation time.
• As-of-use evaluation (): -02 stated that a snapshot taken at or after the time of use is sufficient to establish that a grant was not revoked. That holds only for a snapshot showing the grant unrevoked. A snapshot is now defined as a point-in-time statement, distinct from its own validity period; the evidence cases are stated; and a use falling between an unrevoked and a revoked snapshot is indeterminate, however frequent the snapshots.
• Bilateral contracts (): a composition carrying a grant is now required to match the authenticated presenting party to the named grantee by identifier correspondence and to state when the check occurs.
• Relationship to the vocabulary (): acknowledges the vocabulary's current category set and scoping, and cites its own observation that specific arrangements may override a statement of preference.
• Editorial: references consolidated under one section.

Acknowledgements 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.