Network Working Group T. Litzki Internet-Draft Litzki Systems LLC Intended status: Informational 12 May 2026 Expires: 13 November 2026 Sovereign Validation Protocol (SOVP) draft-litzki-sovp-00 Abstract This document specifies a protocol for the decentralized validation of entity integrity within the agentic web. The objective is to establish a machine-readable trust anchor (Layer 0) that enables Large Language Models (LLMs) and autonomous agents to deterministically verify the authenticity and structural consistency of a data source prior to ingestion. By shifting validation to the infrastructure ingress, the protocol minimizes resource waste and prevents the propagation of unverified signal noise. This document reflects the current state of the protocol specification, including formal header structures, clarified pre-hash procedures, and explicitly defined protocol non-goals. Note This document describes work by Litzki Systems LLC. Requirements Language 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. 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/. Litzki Expires 13 November 2026 [Page 1] Internet-Draft SOVP May 2026 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 13 November 2026. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Resonance Proof: Psi_core . . . . . . . . . . . . . . . . 3 4. Technical Specification: The sovp-identity.json Structure . . 4 5. Atomic State Drift and Entropy Suppression . . . . . . . . . 4 6. Protocol Execution Sequence . . . . . . . . . . . . . . . . . 5 6.1. Mode B Fallback Logic . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7.1. Key Revocation and DNS TTL . . . . . . . . . . . . . . . 6 7.2. Replay Protection . . . . . . . . . . . . . . . . . . . . 6 7.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 6 7.4. DNS Security (DNSSEC) . . . . . . . . . . . . . . . . . . 6 8. Deployment Architecture: Layer 0 Positioning . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9.1. Underscored and Globally Scoped DNS Node Names . . . . . 6 9.2. Permanent Message Header Field Names . . . . . . . . . . 7 10. Normative References . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The proliferation of autonomous agents and Large Language Models (LLMs) operating across the web has created a critical need for deterministic, infrastructure-level trust verification. Existing approaches to data integrity - including transport-layer encryption and application-level validation - operate downstream of the ingress point, allowing unverified signals to consume computational resources before rejection. Litzki Expires 13 November 2026 [Page 2] Internet-Draft SOVP May 2026 The Sovereign Validation Protocol (SOVP) addresses this gap by establishing a cryptographic trust anchor at Layer 0, prior to any data ingestion. An entity declares its sovereign identity via a signed JSON object and a DNS-anchored public key. Any Validating Agent or Sovereign Gateway can verify this identity deterministically, without prior relationship or shared secret, and reject non-conformant requests at the network boundary. This document specifies the protocol data structures, cryptographic procedures, and operational modes constituting SOVP. It is published as an Informational document describing an existing protocol deployment. 2. Non-Goals The Sovereign Validation Protocol (SOVP) is designed to prove the cryptographic authenticity and the non-repudiation of the source. It is critical to note that SOVP does not validate the semantic accuracy or the truthfulness of the content provided by the entity. The protocol guarantees that the signal originates from the declared sovereign identity and has not been tampered with since signing. It does not replace downstream fact-checking or qualitative analysis. 3. The Resonance Proof: Psi_core The core of the validation is the determination of the system resonance, denoted as Psi_core. It describes a binary state of cryptographic alignment between the declared entity identity and its digital output. To ensure global interoperability, the identity metadata (M) must be processed using the JSON Canonicalization Scheme (JCS) as defined in RFC 8785 before hashing. The validation follows the formal function of the Edwards-curve Digital Signature Algorithm (Ed25519). For the purpose of this protocol, the cryptographic hash function (H) is SHA-512 per RFC 6234, serving as the required pre-hash for the Ed25519 verification process. Psi_core = Verify(K_pub, sigma, H(JCS(M))) Where: * K_pub is the public key, retrieved via a DNS TXT record or the X- SOVP-Identity header. * sigma is the digital signature provided within the integrity_proof. Litzki Expires 13 November 2026 [Page 3] Internet-Draft SOVP May 2026 * H(JCS(M)) is the SHA-512 hash of the canonicalized identity metadata used for signature verification. * Verify is the deterministic function returning 1 (true) if the signature is valid, or 0 (false) if the integrity is compromised. 4. Technical Specification: The sovp-identity.json Structure The implementation relies on a signed JSON-LD object located in the root directory of the host. This object serves as the primary data carrier for the sovereign identity. Proposed Schema for sovp-identity.json: { "@context": "https://litzki.systems/protocol/v1.4", "@type": "SovereignIdentity", "entity": { "uid": "urn:sovp:litzki-systems-llc", "canonical_url": "https://litzki.systems", "verification_method": "Ed25519" }, "integrity_proof": { "signature": "z58D...v9A", "created": "2026-03-14T17:00:00Z", "public_key_ref": "dns:txt:_sovp.litzki.systems", "nonce": "optional-unique-string-123" }, "parameters": { "entropy_threshold": 0.12, "determinism_score": 0.98 } } The attributes entropy_threshold and determinism_score are defined as Sovereign Commitments. They represent the signer's self-reported integrity parameters. While not cryptographically verified by the signature itself, they allow the Validating Agent to perform heuristic sanity checks against the actual data stream. 5. Atomic State Drift and Entropy Suppression Atomic State Drift refers to the divergence between the physical reality of a data source and its digital representation during the ingestion process. SOVP suppresses this entropy by enforcing a deterministic handshake. The ingestion is blocked at the ingress layer if the resonance threshold is not met, ensuring that no inconsistent state changes occur within the processing pipeline. Litzki Expires 13 November 2026 [Page 4] Internet-Draft SOVP May 2026 6. Protocol Execution Sequence The protocol execution follows a non-interactive, zero-trust sequence to establish the Resonance Proof. SOVP 1.5 defines two primary operational modes: +======+==================+=========================================+ | Mode | Actor | Description | +======+==================+=========================================+ | Mode | Validating | The agent performs verification locally | | A | Agent (Client) | before committing data to memory. | +------+------------------+-----------------------------------------+ | Mode | Sovereign | An infrastructure-level gateway | | B | Gateway | validates requests on behalf of a | | | (Server) | protected cluster. | +------+------------------+-----------------------------------------+ Table 1 Execution Sequence: 1. Public Key Exposure: The entity publishes its Ed25519 public key via a DNS TXT record (typically at _sovp.yourdomain.tld) or injects it via the X-SOVP-Identity HTTP header. 2. Artifact Retrieval: The Validating Agent or Gateway retrieves the sovp-identity.json from the host's root directory. 3. Integrity Verification: The actor canonicalizes the payload according to RFC 8785, hashes it, and executes the Verify function. 4. Deterministic Ingestion: Ingestion into the internal processing pipeline proceeds exclusively if Psi_core = 1. If the verification fails, the connection is terminated at the ingress layer. 6.1. Mode B Fallback Logic If a requesting entity does not support SOVP or provides an invalid signature, the Sovereign Gateway must act according to the Zero Waste Policy: * Standard Action: The request is rejected with HTTP Status Code 422 (Unprocessable Entity) or 403 (Forbidden) before body parsing occurs. Litzki Expires 13 November 2026 [Page 5] Internet-Draft SOVP May 2026 * Exception: Local allow-lists may be defined for legacy systems, though these bypass the Layer 0 integrity guarantee. 7. Security Considerations 7.1. 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. 7.2. Replay Protection All integrity_proof objects must contain a created timestamp. Validating Agents MUST 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. 7.3. Non-Repudiation SOVP provides non-repudiation by binding metadata to an Ed25519 signature. Malicious actors are forced to sign their own identities, making them identifiable and blockable by global reputation systems. 7.4. 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. 8. Deployment Architecture: Layer 0 Positioning SOVP functions at Layer 0 (Infrastructure Ingress). The Sovereign Gateway acts as a physical barrier at the network interface. Computational costs are shifted to the requester, preventing cluster resource exhaustion by unvalidated signals. 9. IANA Considerations 9.1. Underscored and Globally Scoped DNS Node Names Per RFC 8552, the following entry is to be added to the IANA registry: * Label: _sovp Litzki Expires 13 November 2026 [Page 6] Internet-Draft SOVP May 2026 * Protocol: SOVP * Reference: This document (Section 8.1) 9.2. Permanent Message Header Field Names Per RFC 3864, the following header is to be registered: * Header field name: X-SOVP-Identity * Applicable protocol: HTTP * Status: Experimental * Author/Change controller: Litzki Systems LLC * Specification document: This document (Section 8.2) 10. Normative References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, RFC 8174, March 1997, . [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, . [RFC8552] Crocker, S., "Scoped DNS Node Names", RFC 8552, March 2019, . [RFC3864] Klyne, G., "Registration Procedures for Message Header Fields", RFC 3864, September 2004, . [RFC8785] Rundgren, A., "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . [RFC6234] Eastlake 3rd, D., "US Secure Hash Algorithms (SHA and SHA- based HMAC and HKDF)", RFC 6234, May 2011, . Litzki Expires 13 November 2026 [Page 7] Internet-Draft SOVP May 2026 [RFC3552] Rescorla, E., "Guidelines for Writing RFC Text on Security Considerations", RFC 3552, July 2003, . Author's Address Thorsten Litzki Litzki Systems LLC 7901 4th St N, #32272 St. Petersburg, FL 33702 United States of America Email: ietf@litzki-systems.com Litzki Expires 13 November 2026 [Page 8]