Skip to main content

The AIDP Provenance Seal and Serving Register
draft-flores-aidp-provenance-00

Document Type Replaced Internet-Draft (individual)
Expired & archived
Author Justin Philip Flores
Last updated 2026-08-03
Replaced by draft-flores-airp-provenance
RFC stream (None)
Intended RFC status (None)
Formats
Additional resources Reference implementation of the verification procedure
Running inference advocate client
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Replaced by draft-flores-airp-provenance
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

Abstract

A response served by an inference provider carries no verifiable statement of what produced it. A recipient cannot determine which model generated a given output, nor whether the endpoint that served it was authorized by the party whose name is on it. Attribution today rests on the serving party's own account of events, offered after the fact and at its own discretion. This document specifies two mechanisms that together make that determination decidable by a recipient. The Provenance Seal is a detached signature by which a provider binds a model identifier, its own identity, and a timestamp to the exact bytes of a served response. The Serving Register is a signed document listing, for each provider, the endpoints authorized to serve its models, the public keys that validate its seals, and whether the provider declares that it seals every response. A DNS record under the provider's own domain binds that domain to its register entry and to its declared sealing policy, so that a suppressed seal is detectable rather than merely absent. The design follows electronic mail authentication: the seal is patterned on DKIM, the register on SPF, and the declared sealing policy on the published policy record of DMARC.

Authors

Justin Philip Flores

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)