A Verifiable-Credential Binding for AI Usage Preferences: Expressing Grants that Lift AIPREF Preferences
draft-wallace-aipref-grant-binding-02

Network Working Group                                            Wallace
Internet-Draft                                            LicenseFoundry
Intended status: Standards Track                          18 August 2026
Expires: 19 February 2027

  A Verifiable-Credential Binding for AI Usage Preferences: Expressing
                  Grants that Lift AIPREF Preferences
                 draft-wallace-aipref-grant-binding-02

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, 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, is unrevoked, and was in force at a stated
   time.  It does not adjudicate whether the grantor had standing to
   grant, and it is not an enforcement or access-control mechanism.

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

Wallace                 Expires 19 February 2027                [Page 1]
Internet-Draft            AIPREF Grant Binding               August 2026

   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 19 February 2027.

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.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Relationship to the AIPREF Vocabulary . . . . . . . . . . . .   4
   3.  Relationship to Bilateral Contracts . . . . . . . . . . . . .   5
   4.  The Grant Credential  . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Structure . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Verification Procedure  . . . . . . . . . . . . . . . . . . .   7
   6.  Revocation  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  As-of-Use Evaluation  . . . . . . . . . . . . . . . . . .   7
   7.  Discussion and Open Questions . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   9
   11. Informative References  . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

Wallace                 Expires 19 February 2027                [Page 2]
Internet-Draft            AIPREF Grant Binding               August 2026

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

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

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

Wallace                 Expires 19 February 2027                [Page 3]
Internet-Draft            AIPREF Grant Binding               August 2026

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

   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.

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.

Wallace                 Expires 19 February 2027                [Page 4]
Internet-Draft            AIPREF Grant Binding               August 2026

3.  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 [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 of the credential as
   retrieved, expressed using the Digest Fields representation
   [RFC9530].  The contract layer establishes _which_ document is
   carried; this document establishes _whether_ it is valid, and as of
   when.  The contract does not interpret the grant beyond resolving and
   hashing it; a receiver that can process a carried grant reference
   verifies it per Section 5, including revocation under the as-of-use
   rule (Section 6.1).

   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.

4.  The Grant Credential

4.1.  Structure

   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 resolvable *identifier* for the grant itself, so that a party
      holding a reference to the grant -- for example a contract that
      carries it (Section 3) -- 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" [DID-WEB] identifier resolvable over
      HTTPS;

Wallace                 Expires 19 February 2027                [Page 5]
Internet-Draft            AIPREF Grant Binding               August 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.

4.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"],
     "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"
     }
   }

Wallace                 Expires 19 February 2027                [Page 6]
Internet-Draft            AIPREF Grant Binding               August 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.

5.  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 was not revoked as of the relevant time, by
       checking the referenced status list [BITSTRING] under the as-of-
       use rule (Section 6.1);

   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.

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

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

Wallace                 Expires 19 February 2027                [Page 7]
Internet-Draft            AIPREF Grant Binding               August 2026

   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 an issuer-signed snapshot of the
   status list whose signed validity time covers the time of use.  The
   snapshot establishes the revocation state that was in force at that
   time, independently of the current list.  Because revocation is
   monotonic (Section 6), a snapshot taken at or after the time of use
   is sufficient to establish that a grant was not revoked as of that
   time.

7.  Discussion and Open Questions

   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:

   *  Venue.  The AI Preferences Working Group has, to date, scoped
      mechanisms above the vocabulary -- attachment, transmission,
      grants, and identity -- out of its charter.  On that reading,
      grants and related mechanisms are better progressed elsewhere;
      this document suggests the DISPATCH area as their home, and
      invites confirmation that this is the right venue.

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

   *  Grantee identity.  A grant names its grantee by a resolvable
      identifier -- for example a "did:web" identifier.  Where a grant
      is exercised through a bilateral contract (Section 3), binding the
      presenting party to the named grantee at request time is a
      function of that contract layer rather than of the grant itself.
      Whether a grant should additionally carry its own request-time
      binding is left open.

Wallace                 Expires 19 February 2027                [Page 8]
Internet-Draft            AIPREF Grant Binding               August 2026

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

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

10.  Normative References

   [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,
              <https://datatracker.ietf.org/doc/draft-ietf-aipref-
              vocab/>.

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

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

   [VC-DATA-MODEL]
              W3C, "Verifiable Credentials Data Model v2.0", 2025,
              <https://www.w3.org/TR/vc-data-model-2.0/>.

Wallace                 Expires 19 February 2027                [Page 9]
Internet-Draft            AIPREF Grant Binding               August 2026

   [VC-JOSE-COSE]
              W3C, "Securing Verifiable Credentials using JOSE and
              COSE", 2025, <https://www.w3.org/TR/vc-jose-cose/>.

11.  Informative References

   [BITSTRING]
              W3C, "Bitstring Status List v1.0", 2025,
              <https://www.w3.org/TR/vc-bitstring-status-list/>.

   [DID-WEB]  W3C Credentials Community Group, "did:web Method
              Specification", 2025,
              <https://w3c-ccg.github.io/did-method-web/>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC9530]  Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
              February 2024, <https://www.rfc-editor.org/info/rfc9530>.

   [VDAC]     Jovancevic, S., "Verifiable Data Access Contract (VDAC)",
              Work in Progress, Internet-Draft, draft-jovancevic-vdac,
              2026,
              <https://datatracker.ietf.org/doc/draft-jovancevic-vdac/>.

Author's Address

   Wallace
   LicenseFoundry
   Netherlands
   Email: wallace@licensefoundry.com

Wallace                 Expires 19 February 2027               [Page 10]