AI Preferences Wallace Internet-Draft LicenseFoundry Intended status: Standards Track 3 July 2026 Expires: 4 January 2027 A Verifiable-Credential Binding for AI Usage Preferences: Expressing Grants that Lift AIPREF Preferences draft-wallace-aipref-grant-binding-00 Abstract 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 in the AI Preferences Working Group, not as a finished specification. 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 4 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Wallace Expires 4 January 2027 [Page 1] Internet-Draft AIPREF Grant Binding July 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Relationship to the AIPREF Vocabulary . . . . . . . . . . . . 4 3. The Grant Credential . . . . . . . . . . . . . . . . . . . . 4 3.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Verification Procedure . . . . . . . . . . . . . . . . . . . 6 5. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Discussion and Open Questions . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 10. Informative References . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction 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") 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 Wallace Expires 4 January 2027 [Page 2] Internet-Draft AIPREF Grant Binding July 2026 * 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 the Working Group whether and 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. 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology Preference: An AIPREF value (e.g. "allowed"/"disallowed") assigned to a usage category for an asset, per [AIPREF-VOCAB]. 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 Section 3. 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. Verifier: Any party that checks a grant -- for example an AI system, an auditor, a court, or a counterparty. Wallace Expires 4 January 2027 [Page 3] Internet-Draft AIPREF Grant Binding July 2026 2. Relationship to the AIPREF Vocabulary 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. 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. 3. The Grant Credential 3.1. Structure A grant is expressed as a Verifiable Credential [VC-DATA-MODEL], secured as a JSON Web Signature per [VC-JOSE-COSE]. It carries at least: * an *issuer* identifier that a verifier can resolve to a public key -- for example a "did:web" [DID-WEB] identifier resolvable over HTTPS; Wallace Expires 4 January 2027 [Page 4] Internet-Draft AIPREF Grant Binding July 2026 * 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 [BITSTRING] 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. 3.2. Example 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"], "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" } } Wallace Expires 4 January 2027 [Page 5] Internet-Draft AIPREF Grant Binding July 2026 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. 4. Verification Procedure To act on a grant, a verifier: 1. resolves the issuer identifier to a public key (for "did:web", by fetching the DID document over HTTPS [DID-WEB]) and verifies the signature over the credential; 2. confirms the current time is within the validity period; 3. confirms the grant has not been revoked, by checking the referenced status list [BITSTRING]; 4. confirms the asset digest matches the content in question, and that the category and grantee match the use and party at hand. If all checks pass, a valid grant exists for that (asset, category, grantee); the corresponding preference is lifted for that grantee. Verification requires no interaction with the grantor beyond fetching the (cacheable) issuer key and status list, and can be performed offline against cached copies. 5. 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. 6. Discussion and Open Questions This document is a discussion starter. The mechanism in Section 3 is one candidate, not a final design. The author invites the Working Group's view on the following questions in particular: * Is the expression of grants that lift preferences in scope for the AI Preferences Working Group, or is it better pursued elsewhere? Wallace Expires 4 January 2027 [Page 6] Internet-Draft AIPREF Grant Binding July 2026 * 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? * 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. * How should grantee identity be expressed for interoperability across ecosystems? 7. 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. 8. 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. 9. Normative References Wallace Expires 4 January 2027 [Page 7] Internet-Draft AIPREF Grant Binding July 2026 [AIPREF-VOCAB] Keller, P. and M. Thomson, Ed., "A Vocabulary For Expressing AI Usage Preferences", Work in Progress, Internet-Draft, draft-ietf-aipref-vocab, 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [VC-DATA-MODEL] W3C, "Verifiable Credentials Data Model v2.0", 2025, . [VC-JOSE-COSE] W3C, "Securing Verifiable Credentials using JOSE and COSE", 2025, . 10. Informative References [BITSTRING] W3C, "Bitstring Status List v1.0", 2025, . [DID-WEB] W3C Credentials Community Group, "did:web Method Specification", 2025, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, . Author's Address Wallace LicenseFoundry Netherlands Email: wallace@licensefoundry.com Wallace Expires 4 January 2027 [Page 8]