]>

justinflores@pm.me

Security Individual Submission provenance inference attribution signature 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.

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.

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. defines a binding for HTTP, which is where inference APIs are deployed today.

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.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Provider:

The party that performs inference serving and whose identity a seal asserts. A provider holds one or more seal signing keys and one register entry.

Verifier:

The party that receives a response and evaluates its seal. Typically the client software acting for the end user.

Serving endpoint:

A network location, expressed as an absolute URI, at which a provider's models are served.

Register entry:

The record in the Serving Register describing one provider: its authorized serving endpoints, its seal public keys, the model identifiers it is registered to serve, and its declared sealing policy.

Selector:

A short label identifying one seal key within a register entry, permitting a provider to hold several keys concurrently and to rotate them independently.

Registrar:

The party that publishes and signs a Serving Register document.

The Provenance Seal

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 .

alg:

The signature algorithm. This document defines one value, ed25519, denoting Ed25519 as specified in .

signature:

The signature over the canonical payload of , encoded in base64url without padding .

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.

Field Value Constraints The canonical payload of 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.

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: register-entry: selector: model: provider: signed-at: content-length: ]]> 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.

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 () MUST seal every response it serves.

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 . Member order in the JSON representation is not significant; the canonical payload of 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.

The Serving Register

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 .

registrar:

An object identifying the publishing registrar.

entries:

An array of register entries, as specified in .

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

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 .

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 .

sealPolicy:

Either all or none, as specified in .

Keys and Selectors Each key object carries a selector, a publicKeyPem holding the public key in PEM-encoded SubjectPublicKeyInfo form , 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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

IANA Considerations

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

Field Name:

AIDP-Seal

Status:

permanent

Reference:

This document,

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

Underscored Node Name Registration IANA is requested to register the following entry in the "Underscored and Globally Scoped DNS Node Names" registry defined in :

RR Type:

TXT

_NODE NAME:

_aidp

Reference:

This document,

AIDP Provenance Seal Algorithms Registry IANA is requested to create a registry titled "AIDP Provenance Seal Algorithms", with registration policy Specification Required . Each entry carries an algorithm token, a reference, and a status of either current or deprecated. The initial contents are:

Token	Status	Reference
ed25519	current	This document,

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

Security Considerations

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

Canonical Payload Injection 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.

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

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

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

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.

Endpoint Authorization Is Not Transport Security The endpoint check of 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.

Normative References Informative References

Implementation Status An open-source implementation of the verification procedure of is available at under the Apache License 2.0. It implements entry selection, entry status, seal presence and policy, freshness, key resolution, signature validation, model authorization, and endpoint matching, with a test covering each requirement of this document. It ships a mock signing provider so that the signing half is exercisable without a cooperating provider. The deployed Serving Register described in does not exist. The implementation loads a signed register document from local storage and validates it against a pinned registrar key, which is the same check a retrieved document receives. No production register, registrar, or accreditation process is operating. No inference provider known to the author currently signs its responses. Every response reaching a deployed verifier today is unsealed, which this document treats as a reportable condition rather than an error precisely so that verification can be deployed before signing exists. This section is to be removed before publication as an RFC.

Relationship to Electronic Mail Authentication The correspondence to mail authentication is close enough to be worth stating plainly, both to credit the design and to help implementers reason by analogy. The Provenance Seal corresponds to DKIM : a detached signature over a message, validated with a key published by the signing party under a selector. departs from DKIM deliberately. DKIM takes the signing domain from the signature header itself, which is sound in mail because the result feeds an alignment check against a separately obtained identity. This document has no equivalent later alignment step, so it forbids the seal from selecting its own validating entry rather than permitting it and correcting for it afterward. The Serving Register corresponds to SPF : a published statement of which hosts may act for a named party. It is carried as a signed document rather than in DNS because the data is larger, changes more often, and benefits from audit history, while DNS retains the jobs it does well: proof of domain control and the binding of . The declared sealing policy of corresponds to the published policy of DMARC . Its function is identical: to convert the absence of authentication from an ambiguous condition into a declared failure.

Acknowledgments The architecture from which these two mechanisms are drawn is described in .