



Network Working Group                                          T. Litzki
Internet-Draft                                        Litzki Systems LLC
Intended status: Informational                               14 May 2026
Expires: 15 November 2026


                  Sovereign Validation Protocol (SOVP)
                          draft-litzki-sovp-01

Abstract

   This document specifies the Sovereign Validation Protocol (SOVP), a
   protocol for cryptographic verification of publisher-provided
   identity metadata bound to DNS-anchored public keys.  SOVP enables
   consuming agents and gateways to verify the origin and integrity of
   machine-readable data published at a domain prior to ingestion,
   allowing early rejection of unauthenticated data before body parsing
   occurs.  The protocol defines data structures, cryptographic
   procedures, operational modes, and associated DNS and HTTP
   mechanisms.

Note

   This document describes work by Litzki Systems LLC.

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.





Litzki                  Expires 15 November 2026                [Page 1]

Internet-Draft                    SOVP                          May 2026


   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.  Validation Function: Psi_core . . . . . . . . . . . . . . . .   3
   4.  Technical Specification: The sovp-identity.json Structure . .   4
   5.  Signature Mismatch and Verification Failure . . . . . . . . .   5
   6.  Protocol Execution Sequence . . . . . . . . . . . . . . . . .   5
     6.1.  Mode B Rejection Policy . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     7.1.  Key Revocation and DNS TTL  . . . . . . . . . . . . . . .   6
     7.2.  Replay Protection . . . . . . . . . . . . . . . . . . . .   6
     7.3.  Origin Binding  . . . . . . . . . . . . . . . . . . . . .   6
     7.4.  DNS Security (DNSSEC) . . . . . . . . . . . . . . . . . .   7
   8.  Deployment Architecture: Ingestion Boundary Positioning . . .   7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Underscored and Globally Scoped DNS Node Names  . . . . .   7
     9.2.  Permanent Message Header Field Names  . . . . . . . . . .   7
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

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.







Litzki                  Expires 15 November 2026                [Page 2]

Internet-Draft                    SOVP                          May 2026


   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.



Litzki                  Expires 15 November 2026                [Page 3]

Internet-Draft                    SOVP                          May 2026


   *  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
     }
   }









Litzki                  Expires 15 November 2026                [Page 4]

Internet-Draft                    SOVP                          May 2026


   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:

    +======+================+=========================================+
    | Mode | Actor          | Description                             |
    +======+================+=========================================+
    | Mode | Validating     | The agent performs verification locally |
    | A    | Agent (Client) | before committing data to memory.       |
    +------+----------------+-----------------------------------------+
    | Mode | SOVP Gateway   | An infrastructure-level gateway         |
    | B    | (Server)       | validates requests on behalf of a       |
    |      |                | 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 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].



Litzki                  Expires 15 November 2026                [Page 5]

Internet-Draft                    SOVP                          May 2026


   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.

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

7.  Security Considerations

   This section addresses security considerations per [RFC3552].

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

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




Litzki                  Expires 15 November 2026                [Page 6]

Internet-Draft                    SOVP                          May 2026


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

9.1.  Underscored and Globally Scoped DNS Node Names

   Per [RFC8552], the following entry is to be added to the IANA
   registry:

   *  Label: _sovp

   *  Protocol: SOVP

   *  Reference: This document (Section 9.1)

9.2.  Permanent Message Header Field Names

   Per [RFC3864] and [RFC6648], the following header is to be
   registered.  The SOVP-Identity header name does not use the
   deprecated "X-" prefix per [RFC6648]:

   *  Header field name: SOVP-Identity

   *  Applicable protocol: HTTP

   *  Status: Experimental

   *  Author/Change controller: Litzki Systems LLC

   *  Specification document: This document (Section 9.2)

10.  Normative References



Litzki                  Expires 15 November 2026                [Page 7]

Internet-Draft                    SOVP                          May 2026


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8552]  Crocker, S., "Scoped DNS Node Names", RFC 8552, March
              2019, <https://www.rfc-editor.org/info/rfc8552>.

   [RFC3864]  Klyne, G., "Registration Procedures for Message Header
              Fields", RFC 3864, September 2004,
              <https://www.rfc-editor.org/info/rfc3864>.

   [RFC8785]  Rundgren, A., "JSON Canonicalization Scheme (JCS)",
              RFC 8785, June 2020,
              <https://www.rfc-editor.org/info/rfc8785>.

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, May 2019,
              <https://www.rfc-editor.org/info/rfc8615>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

   [RFC6648]  Saint-Andre, P., Crocker, D., and M. Nottingham,
              "Deprecating the "X-" Prefix and Similar Constructs in
              Application Protocols", BCP 178, RFC 6648, June 2012,
              <https://www.rfc-editor.org/info/rfc6648>.

   [RFC3552]  Rescorla, E., "Guidelines for Writing RFC Text on Security
              Considerations", RFC 3552, July 2003,
              <https://www.rfc-editor.org/info/rfc3552>.

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 15 November 2026                [Page 8]
