Sovereign Validation Protocol (SOVP)

Introduction The increasing deployment of autonomous agents and large language model (LLM) pipelines that consume web-published data creates a need for infrastructure-level verification of data origin and integrity. Existing mechanisms such as TLS operate at the transport layer and do not verify the integrity of application-layer data after delivery. Application-level validation typically occurs after data has been parsed and partially processed, consuming resources before unauthenticated content can be rejected. SOVP addresses this by enabling a publisher to bind machine-readable identity metadata to an Ed25519 signature, with the corresponding public key anchored in DNS. A consuming agent or gateway (referred to as a Validating Agent or SOVP Gateway) can verify this binding without prior relationship or shared secret, and reject non-conformant data at the ingestion boundary before body parsing occurs. Layer 0, as used in this document, refers to the ingestion boundary: the point at which a consuming system decides whether to accept or reject data from an external source, prior to any application-level processing. This document specifies the protocol data structures, cryptographic procedures, and operational modes constituting SOVP. It is published as an Informational document describing the current protocol specification. 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.

Non-Goals SOVP enables verification of origin and integrity for publisher-provided identity metadata. Specifically, a successful verification (Psi_core = 1) indicates that the sovp-identity.json retrieved from a domain was signed by the holder of the private key corresponding to the DNS-published public key, and that the signed content has not been modified since signing. SOVP does not validate the semantic accuracy or truthfulness of the content. It does not replace downstream fact-checking or content analysis. SOVP provides origin binding, not content truth.

Validation Function: Psi_core The core of the protocol is the validation function Psi_core. It produces a binary result indicating whether the identity metadata retrieved from a domain was signed by the holder of the corresponding DNS-published public key. The identity metadata (M) MUST be canonicalized using the JSON Canonicalization Scheme (JCS) as defined in before signature verification, to ensure consistent byte representation across implementations. The implementation uses Ed25519 in pure mode per . The canonicalized identity metadata is passed directly to the Ed25519 sign and verify functions. No external pre-hash is applied. Where:

K_pub is the public key, retrieved via a DNS TXT record or the SOVP-Identity header.
sigma is the digital signature provided within the integrity_proof.
JCS(M) is the canonicalized identity metadata per , passed directly to the Ed25519 verify function.
Verify is the Ed25519 verification function, returning 1 if the signature is valid for the given key and message, or 0 otherwise.

Technical Specification: The sovp-identity.json Structure The implementation relies on a signed JSON object located at the well-known path of the host (/.well-known/sovp-identity.json, per ). This object serves as the primary data carrier for the publisher identity declaration. The signature covers the fields outside the integrity_proof object. The integrity_proof object itself, including the signature field, is excluded from the signed scope. Implementations MUST canonicalize only the non-proof fields of M when computing or verifying JCS(M). Proposed Schema for sovp-identity.json: The parameters object and its attributes entropy_threshold and determinism_score are non-normative and optional. They represent publisher-supplied advisory values and are not cryptographically bound by the Ed25519 signature. Validating Agents MUST NOT use these values as a basis for trust decisions. They MAY be used for informational or monitoring purposes only.

Signature Mismatch and Verification Failure A verification failure (Psi_core = 0) occurs when the sovp-identity.json retrieved from a domain does not produce a valid signature verification result. This may indicate that the identity declaration has been modified since signing, that the wrong key was used, or that the document is malformed. A Validating Agent or SOVP Gateway MUST treat Psi_core = 0 as a rejection condition and MUST NOT proceed with ingestion of data from the non-conformant source.

Protocol Execution Sequence The protocol execution follows a non-interactive sequence to compute Psi_core. SOVP defines two primary operational modes:

Mode	Actor	Description
Mode A	Validating Agent (Client)	The agent performs verification locally before committing data to memory.
Mode B	SOVP Gateway (Server)	An infrastructure-level gateway validates requests on behalf of a protected cluster.

Execution Sequence:

Public Key Exposure: The entity publishes its Ed25519 public key via a DNS TXT record (typically at _sovp.yourdomain.tld) or via the SOVP-Identity HTTP header.
Artifact Retrieval: The Validating Agent or Gateway retrieves the sovp-identity.json from the host's well-known path (/.well-known/sovp-identity.json).
Integrity Verification: The actor canonicalizes the payload according to and executes the Verify function using Ed25519 pure mode per .
Verification Result: Ingestion proceeds if Psi_core = 1. If Psi_core = 0, the Validating Agent or SOVP Gateway MUST reject the data and MUST NOT commit it to the processing pipeline.

Mode B Rejection Policy If a source does not provide a valid sovp-identity.json, or if Psi_core = 0, the SOVP Gateway MUST reject the request. The RECOMMENDED HTTP status code for rejection is 403 (Forbidden). Implementations MAY use 422 (Unprocessable Content) where the rejection is specifically due to a malformed or invalid SOVP identity document. Rejection SHOULD occur before body parsing to avoid unnecessary resource consumption.

Exception: Local allow-lists MAY be defined for legacy systems, though these bypass the Layer 0 integrity guarantee.

Security Considerations This section addresses security considerations per .

Key Revocation and DNS TTL To minimize the window of vulnerability during a key compromise, SOVP records in DNS SHOULD use a low Time-To-Live (TTL), with a recommended value of 300 seconds. Revocation is achieved by updating or removing the _sovp TXT record.

Replay Protection All integrity_proof objects MUST contain a created timestamp. Validating Agents SHOULD reject signatures with a timestamp older than 600 seconds. For high-frequency pipelines, agents SHOULD implement nonce-based deduplication within the validity window to prevent replayed requests. Note: timestamp and nonce validation are not yet implemented in the reference implementation and are planned for a future release.

Origin Binding SOVP binds the signed identity metadata to the Ed25519 key pair whose public component is published in DNS. A successful verification (Psi_core = 1) demonstrates that the holder of the private key signed the identity document. This enables attribution of the signed content to the DNS-identified publisher. SOVP does not provide legal non-repudiation and does not establish the real-world identity of the key holder beyond DNS control.

DNS Security (DNSSEC) Since the trust anchor relies on DNS TXT records, protection against DNS spoofing is critical. The use of DNSSEC is RECOMMENDED for the zone hosting the _sovp record to ensure the authenticity of the public key.

Deployment Architecture: Ingestion Boundary Positioning SOVP is designed to operate at the ingestion boundary (Layer 0), prior to application-level processing. In Mode B, the SOVP Gateway intercepts incoming data requests and performs verification before forwarding to backend systems. This positions verification upstream of resource-intensive processing, allowing unauthenticated data to be rejected early. DNS serves as the trust anchor for public key distribution, with DNSSEC recommended to protect against DNS-based attacks on key material.

IANA Considerations

Underscored and Globally Scoped DNS Node Names Per , the following entry is to be added to the IANA registry:

Label: _sovp
Protocol: SOVP
Reference: This document (Section 9.1)

Permanent Message Header Field Names Per and , the following header is to be registered. The SOVP-Identity header name does not use the deprecated "X-" prefix per :

Header field name: SOVP-Identity
Applicable protocol: HTTP
Status: Experimental
Author/Change controller: Litzki Systems LLC
Specification document: This document (Section 9.2)