Verifiable Data Access Contract (VDAC)
draft-jovancevic-vdac-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Srecko Jovancevic | ||
| Last updated | 2026-08-05 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jovancevic-vdac-03
Network Working Group S. Jovancevic
Internet-Draft SKGO, IKT Support
Intended status: Informational 5 August 2026
Expires: 6 February 2027
Verifiable Data Access Contract (VDAC)
draft-jovancevic-vdac-03
Abstract
This document specifies the Verifiable Data Access Contract (VDAC),
a protocol for cryptographically verifiable bilateral agreement
between a content publisher and an automated agent regarding the
terms of programmatic data access. VDAC defines the mechanism by
which a site issues an access offer, an agent accepts that
offer, both parties sign the resulting contract, and per-request
references bind individual interactions to agreed terms.
VDAC is the protocol-layer realization of the bilateral commitment
principle introduced in Section 6.6 of the Verifiable Identity
Claims and Delegation Model [VICDM] and operates as a companion
specification to the Signed Agent Identity Protocol [SAIP].
This document defines mechanism, not content: VDAC verifies the
existence and integrity of an agreement; the substance of what is
agreed remains entirely between the contracting parties.
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 6 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.
Table of Contents
1. Introduction
1.1. Relationship to VICDM
1.2. The Emerging Architectural Stack
1.3. Relationship to SAIP and ALOI
1.3.1. Identity Mechanism Requirements
1.4. Relationship to webbotauth Work
1.5. Protocol Scope and Non-Goals
2. Terminology
3. Conceptual Overview
3.1. The Progression from Anonymous to Contracted
3.2. Programmable Bilateral Consent
3.3. Contracted Web Semantics
3.4. Separation of Identity Trust and Behavior Trust
3.5. Mechanism, Not Content
4. Site Offer Document
4.1. Publication Location
4.2. Offer Document Format
4.3. Multiple Concurrent Offers
4.4. Discovery and Capability Advertisement
5. Agent Acceptance Document
5.1. Acceptance Format
5.2. Submission and Server Response
6. Contract Document
6.1. Contract Format
6.2. Contract Identifier Derivation
6.3. Contract Storage Obligations
6.4. Delegated Contracting and Infrastructure Scale
7. Per-Request Contract Reference
8. Mutual Tracking Obligation
8.1. Site-Side Log Entry Format
8.2. Agent-Side Log Entry Format
8.3. End-User Privacy Boundaries
8.4. Log Retention
9. Reconciliation and Dispute Evidence
9.1. Reconciliation Manifest Format
10. Violation Detection and Sanctions
10.1 Violation Notice Format
10.2 Sanction Progression
10.3 Self-Reporting (Good Faith Mechanism)
11. Contract Termination
11.1 Termination Conditions
11.2 Termination Notice Format
11.3 Post-Termination Obligations
12. Relationship to ALOI and Contract Formation
12.1. How a Contract Is Formed
12.2. Sequence of an Exchange
12.3. Revision Limit
13. Use Case Profiles (Informative)
13.1. AI Training Data Access
13.2. Content Retrieval and Inference Access
13.3. Monitoring and Health-Check Access
14. Security Considerations
15. Privacy Considerations
16. IANA Considerations
17. References
17.1. Normative References
17.2. Informative References
Appendix A. Document History
Author's Address
1. Introduction
The Verifiable Data Access Contract (VDAC) provides a cryptographic
mechanism by which a content publisher (the Site) and an automated
client (the Agent) can establish a verifiable bilateral agreement
regarding the terms of programmatic data access.
Modern content publishers face a recurring problem: automated
agents -- AI training crawlers, retrieval systems, monitoring
services, IoT telemetry consumers -- access publisher resources at
scale, often outside the scope envisioned by the publisher.
Existing mechanisms address this only partially:
o robots.txt declares what a site permits, but is unilateral,
advisory, and cryptographically unverified.
o Terms-of-service URLs declare legal terms, but bind no party
cryptographically and are difficult to enforce per-request.
o Anonymous attestation models (such as those developed in the
IETF webbotauth working group) verify that a bot is vouched
for, but do not establish any agreement between bot and site
about what the bot will do.
o Identity attestation models (such as [SAIP]) verify who the
bot is, but make no statement about agreed terms of access.
VDAC fills the gap between identity verification and behavioral
agreement. Once a Site and Agent have both signed a VDAC contract,
each subsequent request from the Agent references the contract
cryptographically, and both parties retain non-repudiable logs of
the actual interaction. Discrepancies between intent and behavior
become provable rather than asserted.
Conceptually, VDAC performs two functions. First, it notarizes:
it provides the bilateral, cryptographic act by which an already-
reached agreement becomes sealed and mutually attested. Second,
it safeguards: once sealed, the contract is bound to every
subsequent interaction, so that what was agreed remains provably
in force over the entire life of the contract. VDAC is, in this
sense, the final link in the chain to a concluded agreement --
it does not negotiate or author the agreement, but it is the
mechanism by which the agreement becomes sealed and is then kept
faithful to itself.
1.1. Relationship to VICDM
This document develops the bilateral agreement mechanism originally
introduced in Section 6.6 of [VICDM]. VDAC is extracted into a
standalone specification to enable focused review and independent
deployment.
VDAC implements the fifth principle of the VICDM model:
Agreed intent MUST be honored bilaterally.
An Agent operating under a valid VDAC contract is classified as
Class 4 (Contracted Agent) under the VICDM trust model, receiving
the highest trust level in that classification.
The two documents are companion specifications: [VICDM] provides
the conceptual framework and identity classification within which
VDAC operates; this document defines the wire protocol, document
formats, and operational mechanics.
1.2. The Emerging Architectural Stack
The automated web ecosystem naturally separates into distinct
functional layers. Each layer is a responsibility, and one or
more protocols may fulfill that responsibility:
+==================+=====================+======================+
| Layer | Responsibility | Protocol(s) |
+==================+=====================+======================+
| Identity | Establishing a | SAIP (full identity |
| | verifiable agent | framework), or |
| | identity | VICDM DNS-based |
| | | verification |
+------------------+---------------------+----------------------+
| Framework | Trust | VICDM |
| | classification and | |
| | delegation | |
+------------------+---------------------+----------------------+
| Intent | Unilateral intent | ALOI (defined in |
| | declaration | VICDM) |
+------------------+---------------------+----------------------+
| Agreement | Bilateral | VDAC |
| | operational | |
| | agreement | |
+------------------+---------------------+----------------------+
The Identity layer is deliberately shown with two protocol
options. SAIP and VICDM both provide identity verification, by
different mechanisms: SAIP is a complete identity and signature
framework with per-request key rotation and related operational
features, while VICDM additionally defines a lighter-weight
DNS-based verification suitable for agents that do not need the
full SAIP machinery. A protocol at a higher layer -- such as
VDAC -- consumes "an identity", not "SAIP specifically". This
is what makes the stack composable: each layer can be satisfied
by whichever protocol fits the deployment.
This separation is fundamental to modern automated network
interactions because identity trust does not equate to
behavioral trust. Cryptographic identity alone cannot establish
operational accountability. VDAC introduces an explicit,
operational layer where identity answers "who you are", and
VDAC answers "whether you honored what was agreed".
1.3. Relationship to SAIP and ALOI
VDAC requires that every participating Agent possess a verified
identity: a cryptographically verifiable public key bound to the
Agent and discoverable by the Site. VDAC does NOT mandate any
single identity mechanism.
The Signed Agent Identity Protocol [SAIP] is the RECOMMENDED
identity mechanism for VDAC, as it provides a complete identity
and signature framework designed for automated agents. However,
SAIP is not required. An Agent MAY establish its identity through
any of the following:
o SAIP -- the RECOMMENDED full identity framework.
o The DNS-based identity verification described in [VICDM]
Section 5, which publishes an Agent public key in DNS without
requiring the full SAIP machinery. This is a lighter-weight
option suitable for Agents that do not need per-request key
rotation or the other operational features of SAIP.
o Any equivalent mechanism that provides a verifiable Agent
public key, provided both Site and Agent can rely on it.
VDAC and SAIP are complementary, not interdependent. VDAC defines
the bilateral contract layer; how the Agent proves its identity
is a separate concern that VDAC deliberately leaves open. Where
this document refers to an Agent's signing key, that key is
whatever public key the chosen identity mechanism establishes.
VDAC is complementary to the Agent Letter of Intent (ALOI) defined
in Section 6.5 of [VICDM]:
o ALOI is unilateral: the Agent declares its intent in DNS, and
any Site may observe and enforce that declaration.
o VDAC is bilateral: a specific Site and a specific Agent enter
into a mutually signed agreement that supersedes general ALOI
declarations for interactions under the contract.
An Agent MAY operate under ALOI alone (Intent-Declaring mode),
under VDAC with a specific Site (Contracted Agent mode), or under
both simultaneously. When in conflict, the more specific commitment
governs: VDAC terms supersede ALOI declarations for requests under
the contract; ALOI continues to apply outside any VDAC contract.
1.3.1. Identity Mechanism Requirements
VDAC is identity-mechanism-agnostic. The protocol does not
privilege any particular identity system. Any identity
mechanism MAY be used as the Identity layer for VDAC, provided
it satisfies all of the following requirements:
o It MUST yield a public key that is cryptographically bound
to the Agent.
o It MUST allow the Site to verify that public key
independently, without contacting the Agent out-of-band.
o It MUST produce per-request signatures that can cover the
contract-id and contract-hash parameters defined in
Section 7, so that each request is bound to a specific
contract version.
Any mechanism meeting these three requirements is suitable as
the VDAC Identity layer.
SAIP and the VICDM DNS-based verification are two such
mechanisms specified within this document family. They are
RECOMMENDED for convenience and for interoperability across
independent implementations, but they are in no way privileged
by the protocol itself. A VDAC implementation that relies on
neither SAIP nor VICDM is fully conformant, provided its chosen
identity mechanism meets the requirements above.
Implementers MAY therefore use existing identity infrastructure
-- including mechanisms not authored within this document
family, and including organization-internal identity systems
-- wherever that infrastructure satisfies the stated
requirements. The Identity layer is a replaceable component,
not a fixed dependency. This is a deliberate design property:
it keeps VDAC composable and avoids binding adopters to any
single identity ecosystem.
The agent.id_method field in the Acceptance Document
(Section 5.1) names the identity mechanism actually in use,
allowing the Site to apply the correct verification procedure.
1.4. Relationship to webbotauth Work
The IETF webbotauth working group is developing mechanisms for
anonymous bot attestation [WEBBOTAUTH-ARCH]. VDAC is complementary
to that work:
o Anonymous attestation addresses the privacy use case: rate
limiting and abuse prevention without per-instance disclosure.
o VDAC addresses the bilateral accountability use case: explicit
mutual agreement on terms of access, with cryptographic evidence
retained by both parties.
A deployment MAY support anonymous attestation for general traffic
and require VDAC for specific access tiers (e.g., bulk data
retrieval, AI training, premium API endpoints). The two mechanisms
address different threat models and need not be mutually exclusive.
1.5. Protocol Scope and Non-Goals
VDAC defines the mechanism for verifiable bilateral agreement. It
addresses:
o Offer issuance by Sites.
o Acceptance by Agents.
o Cryptographic binding of both parties to agreed terms.
o Per-request contract reference.
o Mutual tracking and audit obligations.
o Dispute evidence format.
o Contract termination.
VDAC explicitly does NOT address:
o Pricing, payment, or commercial settlement mechanisms.
o Legal enforcement, arbitration, or jurisdiction.
o Tax, regulatory, or compliance matters.
o Open-ended negotiation. VDAC permits each party a single
revision (Section 12.3); anything beyond that takes place
out of band and outside this protocol.
These elements are private between the contracting parties or
addressed by other documents. VDAC provides only the mechanism
for verifiable agreement.
2. Terminology
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.
Site: The party publishing content and offering
access terms. Identified by a DNS domain.
Agent: The automated client seeking access. Holds a
verified identity providing a cryptographically
verifiable public key (see Section 1.3).
Offer Document: A signed JSON object describing access terms.
Ordinarily issued by the Site.
Acceptance Document: A signed JSON object produced by the Agent
indicating intent to operate under a specific
Offer.
Contract Document: The mutually signed JSON object representing
the final bilateral agreement. Contains both
the Offer and the Acceptance, plus signatures
from both parties.
Proposal: Any document put forward by one party for the
other's consideration: an Offer, a revision
of an Offer, or an ALOI observed by a Site.
Revision: A proposal that modifies terms previously
proposed by the other party. An opening
proposal is not a revision. See Section 12.3.
Contract Identifier: A unique value identifying a specific
Contract Document, used as a per-request
reference.
Contract Hash: SHA-256 hash of the canonical Contract
Document, used to bind individual requests
cryptographically to a specific contract
version.
3. Conceptual Overview
3.1. The Progression from Anonymous to Contracted
VDAC sits at the top of the VICDM interaction progression:
+======================+============+============+============+
| Interaction Mode | Identity | ALOI | VDAC |
+======================+============+============+============+
| Anonymous | No | No | No |
+----------------------+------------+------------+------------+
| Identified | Yes | No | No |
+----------------------+------------+------------+------------+
| Intent-Declaring | Yes | Yes | No |
+----------------------+------------+------------+------------+
| Contracted Agent | Yes | Yes opt. | Yes |
+----------------------+------------+------------+------------+
Each level is opt-in. No Agent is compelled to enter a VDAC
contract; no Site is compelled to issue a VDAC Offer. Where
bilateral terms make sense, the mechanism is available.
3.2. Programmable Bilateral Consent
VDAC introduces a transition from static legal declarations to
machine-verifiable operational consent. Traditional mechanisms
are unsuited for programmatic execution: robots.txt is advisory
only, Terms of Service documents are legally descriptive but
unparseable by systems, and API keys grant entry without
tracking ongoing behavioral obligations.
Under the Programmable Bilateral Consent model:
1. Both parties cryptographically bind themselves to
operational scopes.
2. The operational scope is explicitly machine-readable.
3. Violations become algorithmically provable rather than
merely asserted.
3.3. Contracted Web Semantics
VDAC establishes a structural shift in web interaction
philosophy. The historical web model relies on anonymous,
unilateral, advisory, and loosely enforceable interactions.
VDAC formalizes mutually authenticated interactions,
cryptographically verifiable obligations, and bilateral
accountability. This introduces a transition from advisory web
semantics toward verifiable bilateral interaction semantics.
3.4. Separation of Identity Trust and Behavior Trust
A critical distinction within this architecture is the complete
decoupling of identity verification from behavioral tracking:
o Identity Trust establishes who the Agent is, whether the
identity is cryptographically valid, and whether delegation
roots are intact. This is provided by an identity mechanism
such as SAIP or the DNS-based verification of [VICDM].
o Behavior Trust (VDAC) verifies whether the Agent and Site
have honored the underlying agreement over time, and
preserves independent mathematical logs.
Because a valid identity does not automatically guarantee
compliant behavior, VDAC serves as the explicit operational
accountability layer above whatever identity mechanism is in
use.
3.5. Mechanism, Not Content
VDAC is a protocol primitive. It cryptographically establishes
that:
o The Site offered specific terms at a specific time.
o The Agent accepted those specific terms at a specific time.
o Both parties bound themselves to the contract by signature.
o Each subsequent request was made under the claimed contract.
o Both parties retained matching logs of the interaction.
What the terms ARE -- whether they permit AI training, restrict
to ten requests per minute, require attribution, exclude personal
data paths, or impose specific structural limits -- is outside
the scope of this document. VDAC verifies that an agreement exists
and is honored. The wisdom or commercial value of the agreement
is for the contracting parties to determine.
This separation makes VDAC policy-source-agnostic. The terms of
a contract MAY incorporate a resolved policy outcome produced by
an external preference or policy system -- for example, the
AIPREF framework, robots.txt, or a Site's internal policy. VDAC
does not depend on, and does not privilege, any particular such
system. Where an ALOI carries policy compliance content (see
[VICDM] Section 6.5.1.1), a Site that responds to that ALOI with
an Offer MAY adopt that content as one of the Offer's terms. It
is then a clause that both parties have signed. VDAC binds the
clause; it does not interpret it. No AIPREF-specific,
robots-specific, or other source-specific machinery is required
in this document, because the policy source is named by
whichever layer produced the term, and the term is carried, not
parsed, by VDAC.
The same separation governs the grant_ref member defined in
Section 4.2. A grant_ref names an externally defined procedure
by which a term can be resolved and verified. VDAC defines the
extension point and the integrity of the reference; it does not
define, endorse, or require any particular procedure, and the
type tokens registered under Section 16 are equally available to
any specification that registers one. A VDAC implementation that
carries no grant_ref is fully conformant.
4. Site Offer Document
4.1. Publication Location
A Site that wishes to enable VDAC-based access SHOULD publish an
Offer Document at a well-known location, per [RFC8615]:
https://<site-domain>/.well-known/vdac-offer
When multiple Offers are published, they MAY be available at
versioned paths:
https://<site-domain>/.well-known/vdac-offer/<offer-id>
The Offer Document MUST be served over TLS. Servers MAY include
the Offer Document inline in API responses where convenient, but
the well-known URL remains the authoritative source.
An Offer need not be published to be valid. A Site MAY also
issue an Offer directly to a specific Agent in response to a
prior proposal, as described in Section 12. Such an Offer is
not published at the well-known location and carries an
in_response_to member identifying what it answers.
4.2. Offer Document Format
The Offer Document is a JSON object signed by the issuing
party's identity key:
{
"offer_id": "premium-ai-training-v1",
"site": {
"domain": "site.domain",
"pubkey": "pX023...[Truncated Base64URL]"
},
"in_response_to": {
"scheme": "aloi",
"ref": "Base64URLValue...[Truncated]"
},
"valid_from": 1779369600,
"valid_until": 1795132800,
"terms": {
"scope": ["/api/v1/public/*", "/articles/archived/*"],
"exclusions": ["/api/v1/public/users/*", "/articles/premium/*"],
"rate_limit": {
"window_seconds": 60,
"requests_per_window": 120,
"burst_allowance": 15,
"max_concurrent_connections": 4,
"bandwidth_cap_bytes_per_day": 1073741824
},
"obligations": ["attribution_required", "no_resell"],
"custom_terms_uri": "https://site.domain/legal/tos-ai.html",
"custom_terms_hash": "47DEQpj8HBSa...[Truncated Base64URL]",
"grant_ref": {
"type": "verifiable-grant",
"uri": "https://grants.example/g/8817",
"digest": "sha-256=:X48E9qOo...[Truncated]:"
}
},
"offer_sig": "SigVal...[Truncated Base64URL]"
}
Field semantics:
offer_id Unique identifier issued by the Site. MUST be
unique within the scope of the Site for the
Offer's validity period. A revision issued by
the Agent (Section 12.2) carries the offer_id
of the Offer it revises; Agents do not mint
offer_id values of their own.
site.domain The DNS domain of the Site, matching the host
portion of the publication URL where the Offer
is published. In a revision issued by the
Agent, this member continues to identify the
Site whose Offer is being revised.
site.pubkey The Site's Ed25519 public key.
in_response_to OPTIONAL. Present when this document answers
a proposal made by the other party. Absent
when this document opens the exchange.
in_response_to.scheme
A string naming the kind of proposal being
answered, so that the receiving party knows
which layer produced it. Defined values:
"aloi" (an Agent Letter of Intent per [VICDM]
Section 6.5) and "vdac-offer" (an Offer
Document, including one issued as a revision).
Other implementation-defined strings MAY be
used, following the same convention as
agent.id_method (Section 5.1).
in_response_to.ref An opaque reference to the proposal being
answered, as supplied by the layer that
produced that proposal. VDAC does not parse,
resolve, or interpret this value; it records
which proposal was answered so that the
sequence of an exchange is verifiable. For
scheme "vdac-offer" the value is the SHA-256
hash of the canonicalized document, Base64URL-
encoded.
valid_from Unix timestamp before which the Offer MUST
NOT be accepted.
valid_until Unix timestamp after which the Offer MUST
NOT be accepted.
terms Substantive content of the Offer.
terms.scope An array of URL path matchers defining
permitted endpoints. Pattern matching follows
standard glob/wildcard semantics relative to
the site root path.
terms.exclusions An array of URL path matchers defining
explicit blocks within the permitted scope.
Exclusions MUST override scope definitions
when paths overlap.
terms.rate_limit Stated operational performance constraints.
Parsers MUST support the primitive integer
definitions for windows, requests,
concurrency, and optional daily bandwidth
caps.
terms.obligations Free-form list of obligations the Agent agrees
to fulfill if accepting. The protocol does not
parse these strings natively.
terms.custom_terms_uri
An optional URI pointing to additional
contract terms that do not fit within JSON.
terms.custom_terms_hash
REQUIRED when custom_terms_uri is present,
otherwise absent. SHA-256 hash of the octets
retrieved from custom_terms_uri at Offer
issuance time, Base64URL-encoded. A party
that retrieves the referenced document and
computes a different value MUST treat the
terms as unavailable rather than substituted.
terms.grant_ref OPTIONAL. A reference to an externally
defined grant, licence, or authorization
whose resolution procedure is specified
outside this document. VDAC carries the
reference and guarantees its integrity; it
does not resolve or interpret it. A Contract
containing no grant_ref is fully conformant.
terms.grant_ref.type
A type token naming the procedure by which
the reference is resolved and verified. The
token MUST be registered in the VDAC Grant
Reference Types registry (Section 16). The
normative procedure for a given token is
named by that registry entry, not by this
document.
terms.grant_ref.uri A URI at which the referenced grant is
retrievable.
terms.grant_ref.digest
An integrity digest of the representation
retrievable at uri, expressed as a Digest
field value per [RFC9530]. A party that
retrieves the grant and computes a different
digest MUST treat the grant as unavailable
rather than substituted.
offer_sig Ed25519 signature over the canonicalized
offer object excluding the signature field
itself, produced by the party issuing the
document. Canonicalization follows [RFC8785].
The Digest field encoding of [RFC9530] is used at the grant_ref
boundary only, because that is where VDAC hands off to a
representation it did not produce and whose retrieval is an HTTP
concern. Hashes internal to VDAC's own notarial operations --
offer_hash, contract_hash, custom_terms_hash, log_summary_hash --
are plain SHA-256 values encoded as Base64URL per [RFC4648]
Section 5, without padding, as defined where each is introduced.
4.3. Multiple Concurrent Offers
A Site MAY publish multiple Offers concurrently representing
different access tiers. Each Offer MUST have a distinct offer_id.
The set of currently valid Offers MAY be enumerated at:
https://<site-domain>/.well-known/vdac-offer-index
4.4. Discovery and Capability Advertisement
To minimize the application layer overhead of fetching offer
indexes proactively, implementations SHOULD leverage discovery
mechanisms.
4.4.1. HTTP Capability Advertisement
Sites MAY advertise contract capabilities during standard HTTP
interactions by including a VDAC-Advertise header in responses:
VDAC-Advertise:
offer="https://site.domain/.well-known/vdac-offer",
types="ai-training, retrieval",
index="https://site.domain/.well-known/vdac-offer-index"
4.4.2. DNS-Based Discovery
Agents wishing to evaluate a domain's VDAC enforcement posture
before initiating application-layer handshakes MAY query the
zone's DNS records. The VDAC pointer is constructed as a TXT
record located at a dedicated subdomain string:
_vdac.site.domain. IN TXT
"v=vdac1;
index=https://site.domain/.well-known/vdac-offer-index"
5. Agent Acceptance Document
5.1. Acceptance Format
An Agent that wishes to accept a Site Offer constructs an
Acceptance Document:
{
"contract_id": "Z21h...[Truncated Base64URL]",
"offer_hash": "SHA256Val...[Truncated Base64URL]",
"agent": {
"agent_id": "id=master-agent-identity",
"id_method": "saip",
"pubkey": "aF912...[Truncated Base64URL]",
"vendor": "vendor-domain.com",
"delegation_allowed": true
},
"accepted_at": 1779370000,
"expires_at": 1795132800,
"agent_sig": "SigVal...[Truncated Base64URL]"
}
Field semantics:
contract_id The Contract Identifier derived per Section
6.2. The Agent computes this value at
acceptance time.
offer_hash SHA-256 hash of the canonicalized Offer
Document. This binds the Acceptance to a
specific version of the Offer.
agent.agent_id The Agent's identity string, as established
by the chosen identity mechanism (Section
1.3). For SAIP, this is the id= value per
[SAIP].
agent.id_method The identity mechanism in use. Defined
values: "saip" (SAIP identity), "vicdm-dns"
(DNS-based verification per [VICDM] Section
5), or an implementation-defined string for
other mechanisms.
agent.pubkey The Agent's public key. MUST match the key
discoverable through the identity mechanism
named in id_method (for SAIP, the key in the
Agent's DNS _saip record; for vicdm-dns, the
key published per [VICDM] Section 5).
agent.vendor The DNS domain of the vendor operating the
Agent.
agent.delegation_allowed
A boolean flag declaring whether the contract
intends to utilize distributed worker nodes
authenticated via VICDM delegation
structures.
accepted_at Unix timestamp at which the Acceptance was
constructed. MUST be within the Offer's
validity period.
expires_at Unix timestamp at which the resulting
Contract expires. MUST NOT be later than the
Offer's valid_until.
agent_sig Ed25519 signature over the canonicalized
acceptance object excluding the signature
field.
5.2. Submission and Server Response
The Agent submits the Acceptance Document to the Site via HTTP
POST:
POST https://<site-domain>/.well-known/vdac-accept
Content-Type: application/json
The request body is the Acceptance Document. If validation
succeeds, the Site returns the complete signed Contract Document
(Section 6) with HTTP status 201 (Created).
The same endpoint is used to submit a revision (Section 12.2).
The request body is then an Offer Document carrying an
in_response_to member and signed by the Agent. A revision does
not form a Contract; the Site responds per Section 12.
If validation fails, the Site returns HTTP status 400 (Bad
Request) with structured error codes: `offer_not_found`,
`offer_expired`, `expiry_exceeds`, `signature_invalid`,
`identity_unverified`, `duplicate_contract`, or
`revision_limit_exceeded`.
expiry_exceeds indicates that the expires_at value in the
Acceptance is later than the Offer's valid_until.
revision_limit_exceeded indicates that the submitting party has
already issued its one permitted revision (Section 12.3).
6. Contract Document
6.1. Contract Format
The Contract Document is the canonical record of the bilateral
agreement:
{
"contract_id": "DerivedID-Value",
"offer": { ... complete Offer Document ... },
"acceptance": { ... complete Acceptance Document ... },
"prior_exchange": [
{ "scheme": "aloi", "ref": "Base64URLValue..." },
{ "scheme": "vdac-offer", "ref": "Base64URLValue..." }
],
"site_sig": "SigVal...[Truncated Base64URL]",
"agent_sig": "SigVal...[Truncated Base64URL]"
}
The site_sig and agent_sig fields are Ed25519 signatures
computed over the canonicalized concatenation of the offer,
acceptance, and prior_exchange members (in that order), per
[RFC8785].
The prior_exchange member lists, in chronological order, every
proposal that preceded and was superseded by the Offer contained
in this Contract. Each entry has the same structure as the
in_response_to member defined in Section 4.2. The list is empty
when the Offer opened the exchange and was accepted without
revision.
Because prior_exchange is covered by both signatures, either
party -- or a third party examining the Contract -- can verify
that the revision limit of Section 12.3 was observed, without
retaining the superseded documents themselves.
6.2. Contract Identifier Derivation
The contract_id is deterministically derived to allow either
party to compute it independently:
contract_id = Base64URL(SHA256(
offer_hash || agent.agent_id || accepted_at
))
Where || denotes concatenation of the UTF-8 octets of each
value, with a single ASCII null byte (0x00) inserted between
consecutive values as a strict delimiter.
offer_hash, rather than offer_id, is used so that two Offers
sharing an offer_id but differing in terms cannot produce the
same Contract Identifier.
6.3. Contract Storage Obligations
Both parties MUST retain identical copies of the Contract
Document until the contract's expires_at timestamp (Section 5.1)
has passed, plus the log retention period (Section 8.4).
The Contract Document contains the complete Offer and
Acceptance, and therefore the full text of the agreed terms. No
party needs to resolve any external source to determine what was
agreed. Where a term references material outside the Contract --
through custom_terms_uri or grant_ref -- the Contract retains
the reference and its digest, so that the integrity of the
referenced material remains verifiable even if that material
later changes or becomes unavailable.
6.4. Delegated Contracting and Infrastructure Scale
For large-scale, enterprise, and distributed systems where
scraping or API consumption is handled by clustered pools of
machines, executing unique contracts per ephemeral node is
unfeasible. VDAC addresses this by integrating with the [VICDM]
delegation mechanism.
If `agent.delegation_allowed` is true in the signed contract,
application requests operating under the contract_id MAY be
signed by distinct, ephemeral operational public keys. The Agent
node MUST include the matching umbrella corporate `Delegation
Token` within the request protocol metadata, proving that the
ephemeral node's key is a legitimate downstream delegate of the
contract's `agent.pubkey`.
7. Per-Request Contract Reference
Once a Contract is established, the Agent includes a contract
reference in every signed request to the Site:
contract-id=<contract_id>; contract-hash=<contract_hash>
Where contract_hash is the SHA-256 hash of the canonicalized
Contract Document, encoded as Base64URL.
The contract-id and contract-hash parameters MUST be covered by
the request signature produced by the Agent's identity mechanism,
so that each request is cryptographically bound to a specific
contract version. When SAIP is the identity mechanism, these
parameters MUST be included in the SAIP canonical signature
string per [SAIP] Section 6.4.2. When another identity mechanism
is used, the parameters MUST be covered by that mechanism's
request signature in an equivalent manner.
8. Mutual Tracking Obligation
VDAC requires mutual logging by both parties. Tracking is an
integral part of the contract, not an optional feature.
In both log entry formats defined below, ts is the request
timestamp asserted by the Agent and covered by the request
signature of the identity mechanism in use. It is not the local
clock reading of either party. Both parties therefore record the
same value for the same request, and reconciliation (Section 9)
is not sensitive to clock skew between them.
8.1. Site-Side Log Entry Format
{
"contract_id": "DerivedID-Value",
"ts": 1779371050,
"endpoint": "/articles/archived/news-item",
"method": "GET",
"bytes_sent": 45120,
"status_code": 200,
"agent_sig": "SigVal...[Truncated Base64URL]",
"site_log_sig": "SigVal...[Truncated Base64URL]"
}
8.2. Agent-Side Log Entry Format
{
"contract_id": "DerivedID-Value",
"ts": 1779371050,
"endpoint": "/articles/archived/news-item",
"method": "GET",
"agent_sig": "SigVal...[Truncated Base64URL]",
"response_hash": "SHA256Val...[Truncated Base64URL]",
"bytes_received": 45120,
"agent_log_sig": "SigVal...[Truncated Base64URL]"
}
agent_sig is the request signature the Agent produced for the
request, as recorded by both parties. It is the value on which
reconciliation is computed (Section 9.1). Because it is produced
by the Agent and verified by the Site, it is the only
per-request value both parties are guaranteed to hold
identically.
8.3. End-User Privacy Boundaries
This section addresses a critical constraint: VDAC tracking MUST
NOT become a vector for surveillance of end-users whose
interactions are mediated by a contracted Agent.
The following constraints apply to all VDAC log entries:
1. End-user identifying information MUST NOT be included in
VDAC log entries. This includes, but is not limited to:
end-user IP addresses, user-agent strings of human users
whose interaction is proxied by the Agent, end-user
authentication tokens, session identifiers, and personally
identifiable URL parameters.
2. The endpoint field MUST be normalized to exclude query
parameters that could identify end-users. Implementations
MUST log only the path component, or a redacted form of
the query string where retention of certain parameters is
operationally necessary.
3. Response content MUST NOT be logged in raw form. Only a
hash (response_hash) is logged. The hash provides
verification capability without retaining the content
itself.
8.4. Log Retention
Both parties retain logs for the duration specified in the
contract terms. The RECOMMENDED minimum retention is 90 days
from the request timestamp. Logs older than the retention period
SHOULD be securely deleted.
9. Reconciliation and Dispute Evidence
Periodic reconciliation between Site and Agent logs is
RECOMMENDED. To facilitate rapid, automated cross-checking
without mass data transfer, parties utilize a structural summary
document.
9.1. Reconciliation Manifest Format
When performing an audit checkpoint, a party compiles state
records into a canonical Manifest object:
{
"contract_id": "DerivedID-Value",
"period_start": 1779369600,
"period_end": 1779456000,
"total_requests": 14500,
"total_bytes": 48291045,
"log_summary_hash": "SHA256Val...[Truncated Base64URL]",
"manifest_sig": "SigVal...[Truncated Base64URL]"
}
The log_summary_hash is derived as follows:
1. Select every log entry under this contract_id whose ts falls
in the interval [period_start, period_end). ts is the
Agent-asserted request timestamp defined in Section 8, so
both parties select the same set.
2. Take the agent_sig value of each selected entry, as the
Base64URL string recorded in the log.
3. Sort the values in ascending order by the octet values of
those strings. Sorting on the signature rather than on the
timestamp is deliberate: it makes the ordering independent
of any clock and total even when several requests carry the
same ts.
4. Concatenate the sorted values, each followed by a single
line feed octet (0x0A), including after the last.
5. log_summary_hash = Base64URL(SHA256(that octet sequence)).
total_requests MUST equal the number of entries selected in
step 1.
If both local calculations match the log_summary_hash, the
historical block is mutually verified. If hashes diverge,
systems enter detailed reconciliation by repeating the procedure
over narrower sub-intervals of the period to isolate the precise
mismatched request signatures.
10. Violation Detection and Sanctions
10.1. Violation Notice Format
{
"contract_id": "DerivedID-Value",
"violation": "rate_limit_exceeded",
"evidence_ref": "ManifestHashOrLogID",
"detected_at": 1779372000,
"site_sig": "SigVal..."
}
The notice MAY be delivered via HTTP response header on the
offending request:
VDAC-Violation: <base64url-encoded violation notice>
10.2. Sanction Progression
Sanctions for VDAC violations SHOULD follow the same progressive
model defined for ALOI in [VICDM] Section 6.5.7:
+=================+============+================================+
| Violation Count | Sanction | Action |
+=================+============+================================+
| 1 | Warning | Notice only; no rate change. |
+-----------------+------------+--------------------------------+
| 2-3 | Throttle | Reduce to minimal rate. |
+-----------------+------------+--------------------------------+
| 4-5 | Downgrade | Trust downgrade. |
+-----------------+------------+--------------------------------+
| 6-10 | Block | Reject contract requests. |
+-----------------+------------+--------------------------------+
| >10 | Termination| Terminate contract per |
| | | Section 11. |
+-----------------+------------+--------------------------------+
10.3. Self-Reporting (Good Faith Mechanism)
An Agent that detects an unintentional violation of contract
terms MAY self-report the violation before the Site detects it,
per the Good Faith Mechanism defined in [VICDM] Section 6.5.8.
Self-reporting under VDAC uses the same signal format as ALOI
self-reporting:
VDAC-Self-Report: contract-id=<contract_id>;
violation=<violation-type>;
ts=<unix-timestamp-of-violation>;
self-sig=<signature per VICDM 6.5.8>
11. Contract Termination
11.1. Termination Conditions
A VDAC contract terminates in any of the following conditions:
o Natural expiry: reaching the contract's expires_at timestamp.
o Mutual termination: both parties signing a termination notice.
o Unilateral termination by either party, with signed notice.
o Material breach: severe violation as defined in contract terms.
11.2. Termination Notice Format
{
"contract_id": "DerivedID-Value",
"terminated_by": "site",
"reason": "material_breach",
"effective_at": 1779373000,
"evidence_ref": "ViolationNoticeHash",
"terminator_sig": "SigVal..."
}
Defined reason codes: `natural_expiry`, `mutual_consent`,
`site_initiated`, `agent_initiated`, `material_breach`, or
`offer_revoked`.
11.3. Post-Termination Obligations
After termination, the Agent MUST cease using the contract_id in
requests. Both parties retain logged evidence for the contract's
log retention period. The Agent reverts to its prior interaction
mode (Anonymous, Identified, or Intent-Declaring per the VICDM
progression).
12. Relationship to ALOI and Contract Formation
ALOI and VDAC are complementary. ALOI, defined in [VICDM]
Section 6.5, is a unilateral declaration by the Agent. VDAC is
a bilateral agreement in which both parties are bound.
An Agent MAY operate under both simultaneously. ALOI defines the
Agent's general operational scope across all interactions; VDAC
defines specific terms for one particular Site. When in
conflict, the more specific commitment governs: VDAC terms
supersede ALOI declarations for requests made under the
contract, while ALOI continues to apply outside any VDAC
contract.
12.1. How a Contract Is Formed
A VDAC Contract is always the same object: an Offer and an
Acceptance, each signed by its author, together constituting a
dual-signed agreement (Section 6). Every Contract is formed by
the same final two acts:
the Site issues an Offer, and the Agent signs an Acceptance
of that Offer.
This is invariant. It follows from the structure of the Contract
Document itself, which contains exactly one Offer and exactly
one Acceptance.
What may differ is what precedes those two acts. Two entry
points are defined:
Entry 1 -- Site-initiated.
The Site publishes one or more Offers (Section 4). The Agent
selects an Offer and either accepts it (Section 5) or answers
with a revision (Section 12.3).
Entry 2 -- Agent-initiated, via ALOI.
The Agent has published an ALOI: a declaration of what it
intends to do, per [VICDM] Section 6.5. A Site observing that
ALOI MAY respond with an Offer that identifies the ALOI in
its in_response_to member.
An ALOI is not an offer of access. It states what the Agent
intends to do; it does not and cannot state what the Site
will provide. A Site that finds an ALOI acceptable expresses
that by issuing an Offer whose terms adopt the ALOI's
declared boundaries; a Site that finds it partly acceptable
issues an Offer whose terms adjust them. Either way, the Site
states its own side of the arrangement for the first time,
and no agreement exists until the Agent signs an Acceptance
in return.
A Site MAY also decline, by issuing a signed refusal, or
remain silent. Silence forms no agreement and MUST NOT be
interpreted as acceptance. In both cases the ALOI remains in
force as a unilateral declaration under [VICDM].
Both entry points converge on an identical Contract Document.
Neither forms a Contract by the action of one party alone.
12.2. Sequence of an Exchange
The following sequences are the longest permitted under the
revision limit of Section 12.3. Shorter sequences are the common
case.
Entry 1 -- Site-initiated:
Site Offer opening
Agent Offer (in_response_to) Agent's revision
Site Offer (in_response_to) Site's revision
Agent Acceptance Contract formed
Entry 2 -- Agent-initiated:
Agent ALOI opening [VICDM]
Site Offer (in_response_to: aloi) Site's first terms
Agent Offer (in_response_to) Agent's revision
Site Offer (in_response_to) Site's revision
Agent Acceptance Contract formed
In Entry 2 the Site's first Offer is not a revision. There was
no Offer to revise; an ALOI states intent, not access terms. The
Site is stating access terms for the first time, whether or not
it adopts the Agent's declared boundaries unchanged.
A revision issued by the Agent has the Offer Document structure
(Section 4.2) and is signed by the Agent rather than the Site.
It is a proposal, not an Offer the Agent could publish: an Agent
does not publish Offers, and such a document has no meaning
outside the exchange that produced it. The Site answers it
either by issuing an Offer of its own -- adopting the Agent's
terms unchanged, or adjusting them once -- or by refusing.
Submission of Offers and revisions between the parties uses the
endpoint defined in Section 5.2.
12.3. Revision Limit
Each party MAY revise at most once in a given exchange.
A revision is a proposal that modifies terms previously proposed
by the other party. An opening proposal is not a revision:
neither an ALOI, nor a Site's first Offer, modifies anything.
A party that has already issued one revision MUST respond to any
subsequent proposal with either an Acceptance or a refusal. It
MUST NOT issue a further revision under this protocol. A party
receiving a further revision from a party that has exhausted its
allowance MUST treat the exchange as terminated and MUST NOT
form a Contract from it.
The prior_exchange member of the Contract (Section 6.1) records
the sequence, so that the limit is verifiable after the fact
rather than merely asserted.
This limit is deliberate:
o It captures the common real-world case, in which one party
accepts the substance of a proposal but adjusts one or two
terms.
o It gives each party the same allowance regardless of who
opened. A party is not penalized for having made the first
move.
o It avoids an unbounded exchange, which would introduce
open-ended state, replay surface, and a denial-of-service
vector, and would exceed the intent of a contract-sealing
mechanism.
Multi-round negotiation, where genuinely required, takes place
out of band, outside this protocol; VDAC is then used only to
seal the agreement ultimately reached.
13. Use Case Profiles (Informative)
13.1. AI Training Data Access
An AI model vendor wishes to access bulk content from a
publisher Site for training purposes. The structural
`rate_limit` block maps a macro configuration (e.g., aggregate
daily byte caps, low multi-concurrency connections) alongside
obligations like `no_resell` and explicit content path
exclusions.
13.2. Content Retrieval and Inference Access
A retrieval-augmented AI assistant accesses individual articles
in real time to answer user queries. Configuration profiles
employ lower window boundaries, higher burst thresholds, and
shorter termination spans. Under this profile, the privacy
constraints of Section 8.3 are strictly critical.
13.3. Monitoring and Health-Check Access
A third-party monitoring service accesses Site endpoints to
verify availability. The profile establishes lightweight logging
structures with simple token structures and predictable
heartbeat windows.
14. Security Considerations
14.1. Signature Forgery
The integrity of VDAC depends entirely on the security of the
Ed25519 signature scheme [RFC8032] and the secrecy of private
keys. Agent private keys SHOULD be protected by hardware-backed
key storage (TPM, HSM, or Secure Enclave). When SAIP is the
identity mechanism, Agent keys are protected per [SAIP] key
protection requirements.
14.2. Replay of Acceptance
Resubmission of the same Acceptance Document produces an
identical contract_id (per Section 6.2). The Site MUST detect
duplicate contract_id values and reject duplicate Acceptance
submissions.
14.3. Offer Substitution
The offer_hash field in the Acceptance Document binds the
Acceptance to a specific Offer version. A Site cannot substitute
different terms after Acceptance without invalidating agent_sig.
14.4. Exhaustion of the Exchange
The revision limit of Section 12.3 bounds an exchange to a fixed
number of documents, which limits the state a party must retain
for an exchange that has not yet produced a Contract. A party
that receives proposals beyond the limit MUST terminate the
exchange rather than continue it, and SHOULD apply ordinary
rate limiting to repeated exchange attempts from the same
counterparty.
14.5. Integrity of External References
A term may reference material outside the Contract through
custom_terms_uri or grant_ref. In both cases the Contract
retains a digest of the referenced representation, so that
substitution of that material after signature is detectable. A
party that cannot retrieve the material, or that computes a
different digest, MUST treat the referenced terms as unavailable
rather than assume the current representation is the agreed one.
15. Privacy Considerations
See Section 8.3 (End-User Privacy Boundaries) for the core
privacy requirements applicable to VDAC tracking. Because
reconciliation logs map hashes and paths rather than raw states,
they protect end-user activity while preserving behavioral audit
trails.
16. IANA Considerations
This document requests IANA to register the following well-known
URIs per [RFC8615]: `vdac-offer`, `vdac-offer-index`,
`vdac-accept`, and `vdac-contract`.
This document requests IANA to register the following HTTP
header fields per [RFC3864]: `VDAC-Violation` and
`VDAC-Self-Report`.
This document requests IANA to create the VDAC Termination
Reason Codes registry.
This document requests IANA to create the VDAC Grant Reference
Types registry.
Registry name: VDAC Grant Reference Types
Registration policy: Specification Required
Fields per entry: Type token; Resolution procedure (a
normative reference to the specification
defining how a reference of this type is
resolved and verified); Change controller;
Reference.
The resolution procedure for a type token is defined by the
specification named in its registry entry. This document defines
the extension point and the integrity of the reference; it does
not define any resolution procedure and does not privilege any
registered token over another.
Initial contents:
+====================+========================================+
| Type token | Resolution procedure |
+====================+========================================+
| verifiable-grant | draft-wallace-aipref-grant-binding |
+--------------------+----------------------------------------+
An implementation encountering an unregistered type token, or a
registered token whose procedure it does not implement, MUST
treat the grant as unresolvable. It MUST NOT infer a resolution
procedure from the uri member.
17. References
17.1. Normative References
[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.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, January 2017.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, May 2019.
[RFC8785] Rundgren, A., "JSON Canonicalization Scheme (JCS)",
RFC 8785, June 2020.
[RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
February 2024.
[RFC3864] Klyne, G., "Registration Procedures for Message Header
Fields", RFC 3864, September 2004.
[VICDM] Jovancevic, S., "Verifiable Identity Claims and
Delegation Model (VICDM)", Work in Progress, Internet-
Draft, draft-jovancevic-vicdm-09, August 2026.
[SAIP] Jovancevic, S., "SAIP: Signed Agent Identity
Protocol", Work in Progress, Internet-Draft,
draft-jovancevic-saip-08, April 2026.
17.2. Informative References
[WEBBOTAUTH-ARCH]
Meunier, T. and S. Major, "HTTP Message Signatures
for automated traffic Architecture", Work in Progress,
Internet-Draft, draft-meunier-web-bot-auth-architecture,
March 2026.
Appendix A. Document History
The Verifiable Data Access Contract (VDAC) was originally
defined in Section 6.6 of draft-jovancevic-vicdm-05. It was
extracted into this standalone specification to enable focused
review and independent versioning.
Changes in draft-jovancevic-vdac-03:
o Corrected contract formation. An ALOI is a declaration of the
Agent's intent, not an offer of access; a Site's acceptance
of an ALOI therefore cannot by itself constitute a Contract,
because the Site's own terms have not been stated. Section 12
now defines two entry points, both converging on the same
final acts: a Site Offer and an Agent Acceptance. The ALOI is
an entry point, not a parallel path to a Contract.
o Replaced the single-round counter-offer rule with a revision
limit stated per party: each party may revise at most once,
and an opening proposal is not a revision. This gives both
parties the same allowance regardless of who opened.
o Moved in_response_to from Section 12.3 into the Offer
Document (Section 4.2), and defined it as an opaque reference
carrying a scheme name. VDAC records which proposal was
answered without parsing it.
o Added prior_exchange to the Contract Document (Section 6.1),
so that the revision limit is verifiable rather than merely
asserted.
o Added the OPTIONAL terms.grant_ref member (Section 4.2) and
the VDAC Grant Reference Types registry (Section 16). The
normative resolution procedure for a type token lives in its
registry entry, not in this document. Added [RFC9530] for the
grant_ref digest; hashes internal to VDAC's own operations
are unchanged.
o Changed the contract_id derivation (Section 6.2) to use
offer_hash in place of offer_id, so that two Offers sharing
an offer_id but differing in terms cannot produce the same
Contract Identifier.
o Corrected Section 6.3, which required retention "for the
duration specified in terms.duration"; no such field exists.
Retention is now tied to expires_at.
o Corrected the Section 5.2 error code duration_exceeds, which
named the same non-existent field; added
revision_limit_exceeded.
o Added a field semantics entry for terms.custom_terms_hash,
which was previously described only inside the entry for
custom_terms_uri, and made its encoding consistent with every
other hash in the document.
o Defined the meaning of ts in log entries (Section 8) as the
Agent-asserted request timestamp, so that both parties record
the same value.
o Added agent_sig to the Agent-side log entry (Section 8.2).
Without it the two log formats shared no per-request value
and the reconciliation of Section 9 could not be computed.
o Defined the derivation of log_summary_hash (Section 9.1),
which was previously named but never specified.
o Added Sections 14.4 and 14.5 to Security Considerations,
covering exhaustion of an exchange and the integrity of
external references.
o Added [RFC4648], which the document had relied on throughout
without citing; updated [VICDM] to draft-jovancevic-vicdm-09.
Changes in draft-jovancevic-vdac-02:
o Added notarization-and-safeguarding framing to the
Introduction: VDAC notarizes (seals an already-reached
agreement) and then safeguards it (binds it to every
subsequent interaction).
o Added a policy-source-agnostic paragraph to Section 3.5,
stating that contract terms MAY incorporate a resolved
policy outcome from any external system (AIPREF, robots.txt,
internal policy) and that VDAC carries such terms without
parsing them. No source-specific machinery is required.
o Expanded Section 12 into "Relationship to ALOI and Contract
Formation": added Section 12.1 (Three Paths to a Contract --
Site-initiated, Agent-initiated via ALOI, and negotiated),
Section 12.2 (the ALOI-to-VDAC transition with three explicit
outcomes), and Section 12.3 (single-round counter-offer).
o Editorial: corrected line wrapping in Section 12.
Changes in draft-jovancevic-vdac-01:
o Made the identity layer mechanism-independent. SAIP is now
RECOMMENDED rather than mandatory. Section 1.3 rewritten to
permit SAIP, VICDM DNS-based verification, or any equivalent
identity mechanism providing a verifiable Agent public key.
o Added Section 1.3.1 (Identity Mechanism Requirements)
defining the three properties any identity mechanism must
satisfy to serve as the VDAC Identity layer, and stating
explicitly that no identity system is privileged by the
protocol.
o Reorganized the Section 1.2 architectural stack table by
functional layer rather than by protocol, showing that the
Identity layer can be satisfied by SAIP or by VICDM DNS-based
verification.
o Renamed the agent.saip_id field to agent.agent_id and added
an agent.id_method field naming the identity mechanism in
use.
o Section 7 (Per-Request Contract Reference) generalized so
that contract parameters are covered by whatever request
signature the chosen identity mechanism provides.
o Editorial: corrected line wrapping in Sections 3.4, 14, 15.
Changes relative to VICDM Section 6.6 (in draft -00):
o Expanded Privacy Considerations with explicit Section 8.3
boundaries.
o Added Section 4.4 Capability Discovery architectures
(HTTP/DNS).
o Formalized structural standard fields for rate_limit JSON.
o Introduced Section 6.4 Enterprise Infrastructure Key
Delegation.
o Added Section 9.1 Fast Reconciliation Manifest hashes.
Author's Address
Srecko Jovancevic
SKGO, IKT Support
Makedonska 22
11000 Belgrade
Serbia
Email: srecko.jovancevic@skgo.org
Email: srecko.jovancevic@gmail.com
URI: https://github.com/sreckojovancevic