Network Working Group Wallace
Internet-Draft LicenseFoundry
Intended status: Standards Track 27 October 2026
Expires: 30 April 2027
A Verifiable-Credential Binding for AI Usage Preferences: Expressing
Grants that Lift AIPREF Preferences
draft-wallace-aipref-grant-binding-03
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, 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.
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 30 April 2027 [Page 1]
Internet-Draft AIPREF Grant Binding October 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 30 April 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 . . . . . . . . . . . . . . . . . . . . 6
4.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Verification Procedure . . . . . . . . . . . . . . . . . . . 8
6. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. As-of-Use Evaluation . . . . . . . . . . . . . . . . . . 10
7. Discussion and Open Questions . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Changes Since -02 . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
Wallace Expires 30 April 2027 [Page 2]
Internet-Draft AIPREF Grant Binding October 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" 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.
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
Wallace Expires 30 April 2027 [Page 3]
Internet-Draft AIPREF Grant Binding October 2026
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 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.
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 (Section 3).
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 (Section 5).
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.
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,
Wallace Expires 30 April 2027 [Page 4]
Internet-Draft AIPREF Grant Binding October 2026
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.
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, 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
Wallace Expires 30 April 2027 [Page 5]
Internet-Draft AIPREF Grant Binding October 2026
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.
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;
Wallace Expires 30 April 2027 [Page 6]
Internet-Draft AIPREF Grant Binding October 2026
* an *issuer* identifier that a verifier can resolve to a public key
-- for example a "did:web" [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
[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].
Wallace Expires 30 April 2027 [Page 7]
Internet-Draft AIPREF Grant Binding October 2026
{
"@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.
5. 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 [DID-WEB]) and verifies the
signature over the credential;
2. confirms the evaluation time is within the validity period;
Wallace Expires 30 April 2027 [Page 8]
Internet-Draft AIPREF Grant Binding October 2026
3. determines the grant's revocation status as of the evaluation
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
(where the grant is carried by a contract, the party is matched
as described in Section 3).
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 (Section 6.1). 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 Section 6.1.
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.
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
Wallace Expires 30 April 2027 [Page 9]
Internet-Draft AIPREF Grant Binding October 2026
[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
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:
* 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
Wallace Expires 30 April 2027 [Page 10]
Internet-Draft AIPREF Grant Binding October 2026
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.
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 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 (Section 3), the composition is
Wallace Expires 30 April 2027 [Page 11]
Internet-Draft AIPREF Grant Binding October 2026
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
(Section 5) 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 [RFC3161] 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.
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.
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
Wallace Expires 30 April 2027 [Page 12]
Internet-Draft AIPREF Grant Binding October 2026
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.
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. References
10.1. 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-08, September
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.2. Informative References
Wallace Expires 30 April 2027 [Page 13]
Internet-Draft AIPREF Grant Binding October 2026
[BITSTRING]
W3C, "Bitstring Status List v1.0", 2025,
.
[DID-WEB] W3C Credentials Community Group, "did:web Method
Specification", 2025,
.
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, August 2001,
.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, December 2017,
.
[RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
February 2024, .
[VDAC] Jovancevic, S., "Verifiable Data Access Contract (VDAC)",
Work in Progress, Internet-Draft, draft-jovancevic-vdac,
2026,
.
Appendix A. Changes Since -02
This section is to be removed before publishing as an RFC.
* Verification (Section 5): 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 (Section 6.1): -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.
Wallace Expires 30 April 2027 [Page 14]
Internet-Draft AIPREF Grant Binding October 2026
* Bilateral contracts (Section 3): 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 (Section 2): 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.
Author's Address
Wallace
LicenseFoundry
Netherlands
Email: wallace@licensefoundry.com
Wallace Expires 30 April 2027 [Page 15]