Sovereign Validation Protocol (SOVP)

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

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

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

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

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

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

7. Security Considerations

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

Author's Address