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 15 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 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

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

3. 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 [RFC8785] before signature verification, to ensure consistent byte representation across implementations.¶

The implementation uses Ed25519 in pure mode per [RFC8032]. The canonicalized identity metadata is passed directly to the Ed25519 sign and verify functions. No external pre-hash is applied.¶

Psi_core = Verify(K_pub, sigma, JCS(M))

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 [RFC8785], 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.¶

4. 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 [RFC8615]). 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:¶

{
  "@context": "https://litzki-systems.com/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 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.¶

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

6. Protocol Execution Sequence

The protocol execution follows a non-interactive sequence to compute Psi_core. SOVP 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 via the SOVP-Identity HTTP header.¶
2. Artifact Retrieval: The Validating Agent or Gateway retrieves the sovp-identity.json from the host's well-known path (/.well-known/sovp-identity.json).¶
3. Integrity Verification: The actor canonicalizes the payload according to [RFC8785] and executes the Verify function using Ed25519 pure mode per [RFC8032].¶
4. 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.¶

7. Security Considerations

This section addresses security considerations per [RFC3552].¶

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

9. IANA Considerations

Author's Address