Litzki Systems LLC

7901 4th St N, #32272 St. Petersburg FL 33702 USA ietf@litzki-systems.com

Infrastructure Verification Origin Binding Federated Trust Ingestion Boundary Cryptographic Attestation Machine-Readable Evidence DNS-Anchored Keys Digital Sovereignty This document specifies the Sovereign Validation Protocol (SOVP), a protocol for cryptographic verification of publisher-provided identity metadata bound to DNS-anchored Ed25519 public keys. SOVP enables consuming agents, gateways, and federated infrastructure components to verify the origin and integrity of machine-readable declarations published by a domain prior to ingestion, allowing deployments to reject unauthenticated data before application-level processing occurs. SOVP is designed to operate as a verification layer beneath existing trust frameworks, federation architectures, and governance systems. It does not replace these systems. It provides the cryptographic infrastructure evidence upon which higher-layer trust decisions may be grounded. SOVP defines a deterministic verification procedure based on RFC 8785 JSON Canonicalization Scheme (JCS), Ed25519 signatures, DNS-based key publication, and optional HTTP transport mechanisms. The protocol defines data structures, cryptographic procedures, operational modes, and associated DNS and HTTP mechanisms. The reference implementation provides signing and verification primitives only. Full protocol execution including DNS resolution, HTTP retrieval, and gateway enforcement behavior is implementation-defined. A reference implementation of the signing and verification primitives described in this document is available as open-source software under the Apache License 2.0 at https://github.com/litzki-systems/sovp-python.

Introduction Federated digital ecosystems, trust frameworks, and automated infrastructure components increasingly rely on machine-readable declarations to establish and propagate trust across organizational boundaries. These systems define governance rules, credential formats, and policy frameworks for trusted interaction. However, a common mechanism for independently verifying that a machine-readable declaration retrieved from a domain is cryptographically bound to the domain owner at the moment of ingestion does not currently exist. Existing transport-layer mechanisms such as TLS provide channel security but do not verify that the content delivered over that channel remains bound to the domain owner's intended identity after delivery. Verifiable Credential frameworks operate at the application layer and typically assume that the infrastructure serving the credential is already trusted. Federation Architecture Patterns define how systems interact but do not specify how the technical state of participating infrastructure is verified prior to interaction. 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, gateway, or federated infrastructure component (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 application-level processing occurs. The term "sovereign" in the protocol name reflects the design principle that verification does not depend on a third-party certificate authority or centralized trust registry. The public key is anchored in DNS under the publisher's own domain, and verification requires only access to that domain's DNS records and the associated SOVP identity document. 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 externally supplied machine-readable data prior to application-level processing. SOVP is intended as a cryptographic infrastructure verification mechanism. It does not evaluate the semantic accuracy, truthfulness, regulatory compliance, or trustworthiness of published content. Such assessments remain the responsibility of higher-layer systems. The protocol is designed to operate independently of specific AI frameworks, agent protocols, cloud providers, trust frameworks, or compliance regimes. It is intended to be composable with such systems as a lower-layer verification primitive. The reference implementation provides signing and verification primitives only. Full protocol execution, including DNS resolution, HTTP retrieval, and Mode B gateway enforcement behavior, is implementation-defined and outside the scope of the reference implementation. 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 and 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, truthfulness, completeness, regulatory compliance, or trustworthiness of the published content. It does not replace downstream fact-checking, policy evaluation, risk assessment, or content analysis. SOVP does not establish legal identity and does not provide legal non-repudiation. SOVP does not provide a governance framework, credential schema, or compliance assessment. These remain the responsibility of higher-layer systems. SOVP provides cryptographic origin binding and integrity verification at the infrastructure layer. It does not provide content truth.

Relationship to Existing Mechanisms SOVP is designed to be composable with existing trust and identity mechanisms. It is not intended to replace them.

TLS and Transport Security TLS provides channel confidentiality and server authentication at the transport layer. SOVP operates above the transport layer and addresses a complementary concern: whether the content delivered over a TLS-secured channel is cryptographically bound to the domain owner's intended identity at the time of publication. TLS and SOVP MAY be used together.

Verifiable Credentials Verifiable Credentials (W3C VC) provide a framework for issuing, holding, and verifying application-layer claims about subjects. SOVP provides a lower-layer mechanism for verifying that the infrastructure serving such credentials or identity declarations is controlled by the claimed domain owner. SOVP verification MAY serve as a precondition for accepting Verifiable Credentials from a given domain.

DANE DNS-Based Authentication of Named Entities (DANE, RFC 6698) binds TLS certificates to DNS. SOVP similarly uses DNS as a trust anchor but binds application-layer identity metadata rather than TLS certificates. The two mechanisms address different layers and MAY coexist.

DKIM DomainKeys Identified Mail (DKIM, RFC 6376) uses DNS-published public keys to verify email message signatures. SOVP applies a structurally similar DNS-anchored signature model to machine-readable identity documents published at well-known HTTP paths. SOVP is not specific to email or any single transport.

Trust Frameworks and Federation Architectures Trust frameworks such as Gaia-X and federation architectures define governance rules, participant onboarding criteria, and credential issuance procedures for federated digital ecosystems. These frameworks define who may issue attestations and under what conditions. They typically assume that the technical infrastructure of participating entities meets certain properties but do not specify a mechanism for independently verifying those properties at the infrastructure level. SOVP is designed to operate beneath such frameworks as a verification primitive. A federation participant's SOVP identity document MAY be verified prior to accepting credentials from or initiating interactions with that participant. SOVP verification does not replace framework-level compliance assessments; it provides a cryptographic infrastructure evidence layer that such assessments may reference.

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. Implementations MUST use an RFC 8785-compliant JSON Canonicalization Scheme (JCS) library. Floating-point values MUST be serialized according to Section 3.2.2 of . Non-compliant canonicalization libraries MUST NOT be used. Ed25519 in pure mode, as specified in Section 5.1, applies SHA-512 internally as part of the signature algorithm. Implementations MUST NOT apply any external hash function to JCS(M) before passing the canonicalized message to the Ed25519 sign or verify operation. Where:

• K_pub is the Ed25519 public key retrieved via a DNS TXT record or the SOVP-Identity header. When represented in DNS or HTTP, the key MUST be encoded using standard Base64 as specified in Section 4. The encoded value MUST represent exactly 32 bytes of raw Ed25519 public key material.
• 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). The @context value "https://litzki-systems.com/protocol/v1.4" is the canonical context identifier for this version of the specification. Implementations claiming conformance to this specification MUST use the v1.4 context identifier. Proposed Schema for sovp-identity.json: The parameters object and its attributes are optional and application-specific. They are included within the signed scope and therefore protected against modification. However, this specification does not define semantics for any parameter values. Validating Agents MUST NOT derive trust decisions solely from parameter values unless explicitly defined by a separate profile or extension specification. Implementations MAY include additional vendor-specific extension objects within the sovp-identity.json document. Such objects MUST NOT be included in the signed scope and MUST NOT be used as a basis for trust decisions by Validating Agents.

Signature Mismatch and Verification Failure A verification failure (Psi_core = 0) occurs when a Validating Agent is unable to successfully verify the Ed25519 signature associated with a retrieved sovp-identity.json document. Verification failure MAY result from, but is not limited to:

• Modification of signed content after signature creation.
• Use of an incorrect public key.
• Malformed or invalid signature encoding.
• Failure to produce a valid RFC 8785 canonical representation of the signed content.
• Violation of origin binding requirements specified in .

When Psi_core = 0, a Validating Agent or SOVP Gateway MUST treat the identity declaration as invalid and MUST NOT rely on the associated SOVP assertion for trust establishment. Deployments operating in enforcement mode MAY reject the associated resource or transaction prior to further processing.

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.

Implementations MAY offer a managed-signing mode in which key generation and signing operations are performed by a trusted service provider on behalf of the publisher. In such deployments, the publisher receives the public key for DNS publication and the signed sovp-identity.json artifact for deployment. The cryptographic verification procedure for Validating Agents remains identical. Operators SHOULD document whether their deployment uses self-managed or provider-managed key custody. Execution Sequence:

1. Public Key Exposure: The entity publishes its Ed25519 public key in a DNS TXT record located at _sovp. The TXT record MUST use the format: v=SOVP1; k=<base64-encoded-ed25519-public-key> where k contains the RFC 4648 base64 encoding of the raw 32-byte Ed25519 public key.
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. Origin Binding Verification: The Validating Agent MUST verify that the domain serving the sovp-identity.json artifact matches the domain from which the corresponding public key was retrieved. Mismatched domains MUST result in Psi_core = 0.
4. Integrity Verification: The actor canonicalizes the payload according to and executes the Verify function using Ed25519 pure mode per .
5. Verification Result: Psi_core = 1 only if all protocol checks succeed, including origin binding, canonicalization, signature verification, and any locally configured freshness validation requirements. 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 is 422 (Unprocessable Content). Implementations MAY use alternative status codes consistent with local policy. 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.

The reference implementation provides signing and verification primitives only. DNS resolution, HTTP retrieval, gateway behavior, and distributed deployment models are implementation-defined and outside the scope of the reference implementation.

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 whose created timestamp falls outside a locally configured validity window. A default window of 600 seconds is RECOMMENDED. Timestamp validation is implemented in the reference implementation via the check_timestamp parameter of verify_identity(). For high-frequency environments, implementations SHOULD additionally perform nonce-based deduplication within the validity window to mitigate replay attacks. Nonce-based deduplication is not currently implemented in the reference implementation and remains a future work item.

Origin Binding SOVP binds signed identity metadata to the Ed25519 key pair whose public component is published in DNS. A Validating Agent performing full protocol execution MUST verify that the domain serving the sovp-identity.json artifact matches the domain from which the corresponding public key was retrieved. Mismatched domains MUST result in Psi_core = 0. Successful verification demonstrates control over the corresponding private key and the associated DNS namespace. It does not establish legal identity and does not provide legal non-repudiation.

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. DNSSEC is RECOMMENDED because compromise of the DNS resolution path may permit substitution of the published SOVP public key and thereby invalidate the trust model.

Canonicalization Security SOVP relies on RFC 8785 JSON Canonicalization Scheme (JCS) for deterministic message representation. Implementations MUST use an RFC 8785-compliant canonicalization library. Non-compliant canonicalization algorithms MUST NOT be used. In particular, floating-point values MUST be serialized according to RFC 8785 Section 3.2.2.

Deployment Architecture: Ingestion Boundary Positioning SOVP is designed to operate at the ingestion boundary, defined as the point at which a consuming system decides whether externally obtained data is admitted into a processing pipeline. In Mode A, verification is performed by the Validating Agent before data is committed to memory, storage, or further processing. In Mode B, verification is performed by a SOVP Gateway positioned in front of protected services. The gateway evaluates the SOVP identity artifact and associated cryptographic proof before forwarding requests to downstream systems. DNS serves as the trust anchor for distribution of the SOVP public key. Operators SHOULD deploy DNSSEC to provide origin authentication and integrity protection for SOVP public key records. The reference implementation provides signing and verification primitives only. DNS resolution, HTTP retrieval, gateway deployment, caching behavior, and distributed validation architectures are implementation-defined.

IANA Considerations

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

• RR Type: TXT
• Node Name: _sovp
• Reference: This document

A DNS TXT record associated with the _sovp label MUST use the following syntax: v=SOVP1; k=<base64-ed25519-public-key> The value of the k parameter MUST be the standard Base64 encoding defined in Section 4 and MUST represent exactly 32 bytes of raw Ed25519 public key material.

Permanent Message Header Field Names The following HTTP header field is requested for registration.

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

The value of the SOVP-Identity header MUST be the standard Base64 encoding defined in Section 4 and MUST represent exactly 32 bytes of raw Ed25519 public key material. SOVP-Identity: MCowBQYDK2VwAyEA3w7gP0g7vM3...

Public Key Distribution SOVP public keys MAY be distributed through DNS TXT records or through the SOVP-Identity HTTP header field. When represented in DNS TXT records or HTTP headers, Ed25519 public keys MUST be encoded using standard Base64 as defined in Section 4. The encoded value MUST represent exactly 32 bytes of raw Ed25519 public key material.

Normative References

Implementation Status A reference implementation is available under the Apache 2.0 license: https://github.com/litzki-systems/sovp-python The current implementation provides signing and verification primitives, document generation, and CLI tooling. Timestamp validation is implemented via the check_timestamp parameter of verify_identity(). DNS resolution, HTTP retrieval, nonce-based replay protection, and gateway deployment functions are outside the scope of the reference implementation.