The AIDP Provenance Seal and Serving Register

Internet-Draft	AIDP Provenance Seal and Register	August 2026
Flores	Expires 4 February 2027	[Page]

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

1. Introduction

Inference responses arrive as unattributed text. A recipient holding a response has no mechanism for establishing which model produced it, whether the model named in the response metadata is the model that ran, or whether the host that answered was one the named provider had authorized to answer on its behalf. Every element of that chain is asserted by the serving party and verified by no one.¶

The consequences are ordinary rather than exotic. A router may substitute a cheaper model for the one a caller selected and bill for the one selected. Weights obtained outside a provider's distribution may be served under that provider's name. A response may be altered between the serving host and the recipient. When an incident occurs and the parties disagree about what happened, no party holds evidence, and the account that prevails is the account of whoever controlled the pipeline.¶

Electronic mail faced the structurally identical problem and solved it with three composable pieces: a signature binding a message to a signing domain, a published list of hosts authorized to send for a domain, and a published policy stating what a receiver should do when the first two are absent or fail. This document adapts that pattern.¶

1.1. Scope

This document specifies the wire artifacts and the verification procedure: the Provenance Seal, the Serving Register, the DNS binding between them, and the ordered checks a verifier performs. It does not specify what a recipient does with a verification result. Deferring delivery, annotating output, accumulating findings over time, and refusing further exchange are policy behaviors outside the scope of this document.¶

The mechanisms here are transport-agnostic in principle. Section 3.5 defines a binding for HTTP, which is where inference APIs are deployed today.¶

1.2. Non-Goals

A valid Provenance Seal establishes that a party holding a registered private key asserted that a named model produced exactly these bytes at approximately this time. It establishes nothing else. In particular, a seal is not evidence that the named model actually performed the computation. A provider that signs a false model identifier produces a cryptographically valid seal carrying a false claim.¶

What the seal changes is the character of that falsehood. An unsigned false claim is deniable; a signed one is a durable, attributable artifact held by the party who was deceived. This document specifies the mechanism that makes such a claim non-repudiable. It offers no mechanism for detecting it, and readers should not treat seal validity as a statement about model behavior, output quality, or safety.¶

3. The Provenance Seal

3.1. Fields

A Provenance Seal consists of the following fields. All are REQUIRED.¶

register-entry:: The identifier of the provider's register entry.¶
selector:: The selector identifying the signing key within that entry.¶
model:: The model identifier the provider asserts produced the response.¶
provider:: The provider identity as it appears in the register entry.¶
signed-at:: The time of signing, as an Internet date/time string [RFC3339].¶
alg:: The signature algorithm. This document defines one value, ed25519, denoting Ed25519 as specified in [RFC8032].¶
signature:: The signature over the canonical payload of Section 3.3, encoded in base64url without padding [RFC4648].¶

Model identity travels as signed plaintext in the model field and is verified by checking the signature against a public key obtained from the register entry. It is not derived from, encoded within, or extracted from the signature value itself.¶

3.2. Field Value Constraints

The canonical payload of Section 3.3 is a line-oriented format in which header fields are separated by LF and the header block is terminated by an empty line. A field value containing LF or CR could therefore introduce additional apparent header lines within the signed region, producing bytes that two conforming implementations parse differently while both compute the same valid signature.¶

Accordingly, the values of register-entry, selector, model, provider, and signed-at MUST NOT contain LF (0x0A) or CR (0x0D). A signer MUST reject such a value rather than sign it, and a verifier MUST treat a seal carrying such a value as invalid without evaluating its signature.¶

The response content is exempt from this constraint. It is the final element of the payload and its length in bytes is bound in the header block above it, so no content byte sequence can be reinterpreted as a header field.¶

3.3. Canonical Payload

The signature is computed over the following byte sequence, in which <LF> denotes a single LF octet (0x0A), field values are substituted verbatim, and content-length is the length of the response content in bytes when encoded as UTF-8:¶

aidp-seal/v1<LF>
register-entry:<register-entry><LF>
selector:<selector><LF>
model:<model><LF>
provider:<provider><LF>
signed-at:<signed-at><LF>
content-length:<content-length><LF>
<LF>
<content>

Field order is fixed as shown and MUST NOT vary. No whitespace surrounds the colon separator. There is no trailing LF after the content. The entire payload is encoded as UTF-8.¶

The version token aidp-seal/v1 is the first line and is inside the signed region, so a payload constructed under a future version cannot be validated as a version 1 payload.¶

No canonicalization is performed on the content. The signature covers the served bytes exactly as served. A verifier MUST NOT normalize whitespace, line endings, or Unicode representation before verifying.¶

3.4. Signing

A provider signs the canonical payload with the private key corresponding to the public key published under the stated selector in its register entry. The value of signed-at MUST be the time at which the signature was computed.¶

A provider that declares a sealing policy of all (Section 4.4) MUST seal every response it serves.¶

3.5. HTTP Transport Binding

Over HTTP, the seal is carried in the AIDP-Seal response header field. Its value is the JSON object representation of the seal fields, encoded in base64url without padding.¶

The JSON member names are registerEntryId, selector, model, providerIdentity, signedAt, alg, and signature, corresponding in order to the fields of Section 3.1. Member order in the JSON representation is not significant; the canonical payload of Section 3.3 is what is signed, and it fixes its own order.¶

The response content over which the signature is computed is the assistant text as served, not the enclosing JSON body. A verifier extracts that text according to the API in use before computing the canonical payload.¶

A provider MAY additionally carry the same seal as a member of the response body. Where both are present and disagree, the header field is authoritative.¶

4. The Serving Register

4.1. Document Structure

A Serving Register document is a JSON object with the following members:¶

aidpRegisterVersion:: The register format version. This document defines 1.¶
issuedAt:: The time of issuance, as an Internet date/time string [RFC3339].¶
registrar:: An object identifying the publishing registrar.¶
entries:: An array of register entries, as specified in Section 4.2.¶

The document is accompanied by a detached signature over its exact bytes, computed by the registrar.¶

4.2. Entries

Each entry is a JSON object with the following members:¶

id:: The entry identifier, unique within the document. This is the value a seal carries in its register-entry field.¶
providerIdentity:: The provider's identity as asserted in the provider field of its seals.¶
status:: One of active, probationary, or revoked.¶
authorizedEndpoints:: An array of absolute URIs. A response is authorized only if the endpoint contacted matches one of these under Section 5.7.¶
models:: An array of model identifiers this provider is registered to serve. A seal naming a model outside this array is invalid.¶
keys:: An array of key objects, as specified in Section 4.3.¶
sealPolicy:: Either all or none, as specified in Section 4.4.¶

4.3. Keys and Selectors

Each key object carries a selector, a publicKeyPem holding the public key in PEM-encoded SubjectPublicKeyInfo form [RFC8410], and a status of current, rotating, or retired.¶

Selectors MUST be unique within an entry. A verifier MUST reject a seal whose selector names a key with status retired, and MUST accept keys with status current or rotating as valid for verification.¶

A provider rotating a key publishes the new key as rotating alongside the current key, begins signing under the new selector once the updated register has propagated, and subsequently marks the old key retired. Marking a key retired invalidates every seal made under it, including seals made before retirement, so this state is appropriate for key compromise and not for ordinary scheduled rotation.¶

4.4. Declared Sealing Policy

A provider's sealPolicy declares whether the absence of a seal is meaningful. A value of none means the provider does not commit to sealing, and an unsealed response is simply unsealed. A value of all means the provider commits to sealing every response it serves, and an unsealed response purporting to come from it is therefore invalid on its face rather than merely unattributed.¶

This is the mechanism by which stripping a seal becomes detectable. Without it, an attacker able to remove the AIDP-Seal header field would reduce a sealed exchange to an unsealed one and gain the treatment afforded to providers that never sealed at all.¶

4.5. Distribution and Trust Anchor

A verifier obtains a register document and its detached signature by any means, and validates the signature against a registrar public key it holds independently. The registrar identification carried inside the document is descriptive only. A verifier MUST NOT validate a register document against a key obtained from that document.¶

A verifier MUST NOT use a register document whose signature does not validate against an independently held registrar key.¶

Because the document is signed and validated independently of how it arrived, the transport carries no security burden. A register served over HTTPS, retrieved from a transparency log, or shipped with the verifier is subject to the same check.¶

4.6. DNS Binding

A provider binds its own domain to its register entry by publishing a TXT record at the _aidp underscored node name [RFC8552] beneath that domain. The record value is a sequence of tag-value pairs separated by semicolons:¶

_aidp.provider.example. IN TXT
    "v=aidp1; e=provider.example.entry;
     r=https://register.example.net/aidp; p=all"

v:: Version. MUST be aidp1 and MUST be first.¶
e:: The provider's register entry identifier.¶
r:: The URI of the register document that carries the entry.¶
p:: The declared sealing policy, all or none.¶

The record is anchored at the provider's identity domain, not at any serving endpoint. A provider serving from many hosts, from a content delivery network, or from infrastructure it does not administer publishes one record under the domain whose name its seals assert.¶

The binding is what makes register substitution ineffective. An attacker who controls a register document but not the provider's DNS cannot make a verifier consult a forged entry, because the entry identifier and the register location both come from the provider's own zone. An attacker who controls the provider's DNS but not the registrar's signing key cannot produce a validly signed entry. Both are required, and they are held by different parties.¶

Where the DNS record and the register entry both declare a sealing policy and the two disagree, a verifier MUST apply the policy all if either source declares it. Where the DNS lookup does not complete, a verifier MUST apply the policy declared in the register entry and MUST NOT treat the failed lookup as a declaration of none.¶

5. Verification

A verifier evaluates a response against the register entry of the provider it intended to contact. The checks below are performed in order. Each check that fails produces a finding; findings marked as refusing mean the response MUST NOT be treated as attributed to the named provider.¶

5.1. Entry Selection

The verifier MUST select the register entry from the provider identity it intended to contact. It MUST NOT select the entry using the register-entry field of the received seal.¶

Where a seal is present and its register-entry field does not equal the identifier of the selected entry, the verifier MUST treat the response as unattributed. This is a refusing finding and is not a direction to consult the entry the seal named.¶

The requirement exists because a signed object that selects its own validating authority proves only self-consistency. A response naming an entry that legitimately holds the key that signed it produces a seal that verifies perfectly and attests to a provider the user never chose to contact.¶

5.2. Entry Status

Where the selected entry is not present in the register, the response MUST be treated as unattributed. Where the entry carries status revoked, the response MUST be treated as unattributed regardless of seal validity.¶

5.3. Seal Presence

Where no seal is present and the applicable sealing policy is none, the verifier reports the response as unsealed and continues. This is not a failure.¶

Where no seal is present and the applicable sealing policy is all, the verifier MUST treat this as a downgrade and the response MUST NOT be treated as attributed.¶

5.4. Freshness

Where a seal is present, the verifier MUST evaluate its signed-at value against the time at which the response was received.¶

A seal dated more than a permitted forward skew after the receipt time MUST be treated as invalid. Signing necessarily precedes receipt, so any forward offset is clock disagreement. The RECOMMENDED forward skew allowance is 300 seconds.¶

A seal dated more than a permitted age before the receipt time MUST be treated as invalid. The RECOMMENDED maximum age is 3600 seconds.¶

Freshness is evaluated against the receipt time of the response that carried the seal, and not against the verifier's clock at the moment of evaluation. This distinction matters where a verifier re-evaluates a stored exchange: verification of a retained response yields the same verdict later that it yielded at delivery, which would not hold if the comparison were against present time.¶

A seal whose signed-at value is not a parseable Internet date/time string MUST be treated as invalid.¶

5.5. Key Resolution and Signature

The verifier locates the key in the selected entry whose selector equals the selector field of the seal and whose status is not retired. Where no such key exists, the response MUST be treated as unattributed.¶

The verifier reconstructs the canonical payload of Section 3.3 from the seal fields and the received content, and validates the signature against the located public key. Where the signature does not validate, the response MUST be treated as unattributed.¶

5.6. Model Authorization

Where the signature validates, the verifier MUST check that the model field of the seal appears in the models array of the selected entry. A seal naming a model the entry is not registered to serve MUST be treated as invalid.¶

5.7. Endpoint Authorization

The verifier MUST check the endpoint actually contacted against the authorizedEndpoints array of the selected entry. A contacted URI matches a registered URI when all of the following hold:¶

Neither URI carries userinfo.¶
The two URIs have identical origins: the same scheme, the same host compared case-insensitively, and the same port after normalization of the scheme's default port.¶
The contacted path, after removal of trailing slash characters, either equals the registered path after the same removal, or begins with the registered path followed by a slash.¶

Matching MUST NOT be performed by string prefix comparison on the URIs. Such a comparison authorizes a contacted URI of https://api.example.com/v1evil against a registered URI of https://api.example.com/v1, because the registered string is a prefix of the contacted string without being a prefix of its path segments.¶

Where the contacted endpoint does not match, the response MUST be treated as unattributed, whether or not its seal validates.¶

6. IANA Considerations

6.1. HTTP Field Name Registration

IANA is requested to register the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined in [RFC9110]:¶

Field Name:: AIDP-Seal¶
Status:: permanent¶
Reference:: This document, Section 3.5 ¶

Deployments predating this document carry the same value in a field named X-AIDP-Seal. That name is deprecated in accordance with [RFC6648] and is not registered. A verifier MAY accept it for compatibility with existing deployments and MUST prefer AIDP-Seal where both are present.¶

6.2. Underscored Node Name Registration

IANA is requested to register the following entry in the "Underscored and Globally Scoped DNS Node Names" registry defined in [RFC8552]:¶

RR Type:: TXT¶
_NODE NAME:: _aidp¶
Reference:: This document, Section 4.6 ¶

6.3. AIDP Provenance Seal Algorithms Registry

IANA is requested to create a registry titled "AIDP Provenance Seal Algorithms", with registration policy Specification Required [RFC8126]. Each entry carries an algorithm token, a reference, and a status of either current or deprecated.¶

The initial contents are:¶

Table 1
Token	Status	Reference
ed25519	current	This document, [RFC8032]

A verifier MUST treat a seal carrying an algorithm token that is absent from this registry, or present with status deprecated, as invalid.¶

7. Security Considerations

7.1. What a Valid Seal Establishes

A valid seal establishes that a holder of a registered private key asserted the named model, the named provider identity, and the given time over exactly the received bytes. It does not establish that the named model performed the computation. Section 1.2 states this limit; it bears repeating here because the failure mode is a verifier that reports a valid seal in language a user reads as a guarantee about what answered them.¶

Implementations SHOULD surface seal validity in terms of attribution rather than in terms of correctness, safety, or identity of computation.¶

7.2. Canonical Payload Injection

Section 3.2 forbids LF and CR in header field values. The constraint is enforced at signing rather than only at verification so that an ambiguous payload cannot be produced at all. A signer that enforces the constraint only on verification remains capable of emitting a seal that a divergent parser reads differently, which is the condition the constraint exists to prevent.¶

7.3. Replay

A seal is bound to its content, so a captured seal cannot be attached to different content. It can, however, be replayed together with its original content. The freshness bounds of Section 5.4 limit that window.¶

Within the freshness window, replay of a response together with its seal is not detected by this specification. Where a verifier requires stronger assurance, a binding between the request and the response is necessary. Such a binding is not specified in this document.¶

7.4. Downgrade

The declared sealing policy is the sole defense against seal stripping, and it is only as reliable as the verifier's ability to learn it. An attacker positioned to strip the AIDP-Seal field is frequently also positioned to interfere with the verifier's DNS resolution.¶

Section 4.6 therefore requires that a failed DNS lookup fall back to the register-declared policy rather than to none. Verifiers SHOULD additionally cache observed policy declarations and SHOULD treat a transition from all to none for a previously observed provider as suspicious rather than as a routine update.¶

7.5. Registrar Compromise

A registrar signing key is a trust anchor. Its compromise permits forged entries, which permits attribution of arbitrary responses to arbitrary providers. The DNS binding of Section 4.6 constrains this: an attacker holding a registrar key but not a provider's DNS cannot cause a verifier to consult a forged entry for that provider.¶

The residual exposure is a provider for which the verifier has no DNS binding. Verifiers SHOULD distinguish, in whatever they report, between an entry confirmed by a DNS binding and an entry taken from a register document alone.¶

This document does not specify registrar governance, registrar accreditation, or the process by which a provider obtains an entry.¶

7.6. Privacy

A verifier that resolves _aidp beneath a provider's domain before or during an exchange discloses to its resolver, and to any observer of that resolution, which inference providers a user is contacting and approximately when. The DNS queries are a side channel that the exchange itself, carried over TLS to a possibly shared host, may not otherwise expose.¶

Verifiers SHOULD cache DNS bindings for their full TTL rather than resolving per exchange, and SHOULD use encrypted DNS transport where available.¶

The register document itself carries no user-specific information, and retrieving it in full rather than querying for individual entries avoids disclosing which entries a verifier is interested in. Verifiers SHOULD retrieve whole register documents for this reason.¶

7.7. Endpoint Authorization Is Not Transport Security

The endpoint check of Section 5.7 establishes that the contacted URI is one the provider registered. It is not a substitute for authenticating the connection. A verifier MUST continue to perform normal TLS server authentication; a registered endpoint reached over an unauthenticated connection offers no assurance.¶

8. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3339]: Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC4648]: Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC6648]: Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, DOI 10.17487/RFC6648, June 2012, <https://www.rfc-editor.org/info/rfc6648>.
[RFC8032]: Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.
[RFC8126]: Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8410]: Josefsson, S. and J. Schaad, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", RFC 8410, DOI 10.17487/RFC8410, August 2018, <https://www.rfc-editor.org/info/rfc8410>.
[RFC8552]: Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/info/rfc8552>.
[RFC9110]: Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.