Sovereign Validation Protocol (SOVP)
draft-litzki-sovp-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Thorsten Litzki | ||
| Last updated | 2026-06-09 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
Additional Web Page |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-litzki-sovp-03
Network Working Group T. Litzki
Internet-Draft Litzki Systems LLC
Intended status: Informational 9 June 2026
Expires: 11 December 2026
Sovereign Validation Protocol (SOVP)
draft-litzki-sovp-03
Abstract
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, DNS TXT resolution, and HTTP retrieval of identity
documents. Full gateway enforcement behavior is implementation-
defined.
Implementation Status
A reference implementation of the protocol described in this document
is available as open-source software under the Apache License 2.0 at
https://github.com/litzki-systems/sovp-python. The implementation
(v1.0.3) provides signing and verification primitives, DNS TXT
resolution, HTTP retrieval, full pipeline validation, RFC conformance
test vectors, and a Cloudflare Worker reference deployment. See
Appendix A for full implementation status.
Litzki Expires 11 December 2026 [Page 1]
Internet-Draft SOVP June 2026
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 11 December 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Relationship to Existing Mechanisms . . . . . . . . . . . . . 5
3.1. TLS and Transport Security . . . . . . . . . . . . . . . 5
3.2. Verifiable Credentials . . . . . . . . . . . . . . . . . 5
3.3. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. DKIM . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5. Trust Frameworks and Federation Architectures . . . . . . 6
4. Validation Function: Psi_core . . . . . . . . . . . . . . . . 6
5. Technical Specification: The sovp-identity.json Structure . . 7
6. Signature Mismatch and Verification Failure . . . . . . . . . 9
7. Protocol Execution Sequence . . . . . . . . . . . . . . . . . 10
7.1. Mode B Rejection Policy . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8.1. Key Revocation and DNS TTL . . . . . . . . . . . . . . . 11
8.2. Replay Protection . . . . . . . . . . . . . . . . . . . . 11
8.3. Origin Binding . . . . . . . . . . . . . . . . . . . . . 12
8.4. DNS Security (DNSSEC) . . . . . . . . . . . . . . . . . . 12
Litzki Expires 11 December 2026 [Page 2]
Internet-Draft SOVP June 2026
8.5. Canonicalization Security . . . . . . . . . . . . . . . . 12
8.6. Deployment Signing Correctness . . . . . . . . . . . . . 13
9. Deployment Architecture: Ingestion Boundary Positioning . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10.1. Underscored and Globally Scoped DNS Node Names . . . . . 13
10.2. Permanent Message Header Field Names . . . . . . . . . . 14
10.3. Public Key Distribution . . . . . . . . . . . . . . . . 14
11. Normative References . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Implementation Status . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. 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.
Litzki Expires 11 December 2026 [Page 3]
Internet-Draft SOVP June 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 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, DNS TXT resolution, and HTTP retrieval of identity
documents. Full protocol execution including 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 [RFC2119] and [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, 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.
Litzki Expires 11 December 2026 [Page 4]
Internet-Draft SOVP June 2026
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.
3. Relationship to Existing Mechanisms
SOVP is designed to be composable with existing trust and identity
mechanisms. It is not intended to replace them.
3.1. 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.
3.2. 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.
3.3. 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.
3.4. 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.
Litzki Expires 11 December 2026 [Page 5]
Internet-Draft SOVP June 2026
3.5. 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.
4. 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.
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 [RFC8785]. Non-compliant
canonicalization libraries MUST NOT be used.
Ed25519 in pure mode, as specified in [RFC8032] 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.
Psi_core = Verify(K_pub, sigma, JCS(M))
Where:
Litzki Expires 11 December 2026 [Page 6]
Internet-Draft SOVP June 2026
* 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
[RFC4648] 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 [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.
5. 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).
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:
Litzki Expires 11 December 2026 [Page 7]
Internet-Draft SOVP June 2026
{
"@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 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.
As a non-normative example, a deployment MAY include a "scan"
extension object outside the signed scope to convey application-
specific metadata such as validation scores, verdicts, or readiness
indicators. The following illustrates this pattern:
Litzki Expires 11 December 2026 [Page 8]
Internet-Draft SOVP June 2026
{
"@context": "https://litzki-systems.com/protocol/v1.4",
"@type": "SovereignIdentity",
"entity": {
"uid": "urn:sovp:example.com",
"canonical_url": "https://example.com",
"verification_method": "Ed25519"
},
"integrity_proof": {
"signature": "z58D...v9A",
"created": "2026-06-09T00:00:00Z",
"public_key_ref": "dns:txt:_sovp.example.com",
"nonce": "optional-unique-string-123"
},
"scan": {
"verdict": "CERTIFIED",
"parameterCount": 268,
"spec_url": "https://datatracker.ietf.org/doc/draft-litzki-sovp/"
}
}
The "scan" object in the above example is excluded from the signed
scope and MUST NOT influence Psi_core. Its presence or absence does
not affect protocol conformance.
6. 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 Section 8.3.
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.
Litzki Expires 11 December 2026 [Page 9]
Internet-Draft SOVP June 2026
Deployments operating in enforcement mode MAY reject the associated
resource or transaction prior to further processing.
7. 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
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.
Litzki Expires 11 December 2026 [Page 10]
Internet-Draft SOVP June 2026
4. Integrity Verification: The actor canonicalizes the payload
according to [RFC8785] and executes the Verify function using
Ed25519 pure mode per [RFC8032].
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.
7.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 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, DNS TXT resolution, and HTTP retrieval. Gateway
enforcement behavior and distributed deployment models are
implementation-defined and outside the scope of the reference
implementation.
8. Security Considerations
This section addresses security considerations per [RFC3552].
8.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.
8.2. 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.
Litzki Expires 11 December 2026 [Page 11]
Internet-Draft SOVP June 2026
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.
8.3. 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.
8.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.
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.
8.5. 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.
Litzki Expires 11 December 2026 [Page 12]
Internet-Draft SOVP June 2026
8.6. Deployment Signing Correctness
Implementations that generate sovp-identity.json documents MUST
compute the Ed25519 signature over the JCS-canonicalized non-proof
fields of the document, as specified in Section 4. Specifically, the
signed scope MUST consist of the document fields excluding the
integrity_proof object and any vendor extension objects.
A common deployment error is computing the signature over a different
payload — such as a certification token, a JSON.stringify
representation, or any payload that differs from the JCS-
canonicalized non-proof fields. Such documents will produce Psi_core
= 0 when verified by a conformant Validating Agent, even if the
Ed25519 key pair is otherwise correct.
Implementations SHOULD verify their signing pipeline using the RFC
conformance test vectors provided in the reference implementation
prior to production deployment.
9. 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, DNS TXT resolution, and HTTP retrieval of identity
documents. Gateway deployment, caching behavior, and distributed
validation architectures are implementation-defined.
10. IANA Considerations
10.1. Underscored and Globally Scoped DNS Node Names
Per [RFC8552], the following entry is to be added to the IANA
Underscored and Globally Scoped DNS Node Names registry:
Litzki Expires 11 December 2026 [Page 13]
Internet-Draft SOVP June 2026
* 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 [RFC4648] Section 4 and MUST represent exactly 32 bytes of
raw Ed25519 public key material.
10.2. 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 [RFC4648] Section 4 and MUST represent exactly 32
bytes of raw Ed25519 public key material.
SOVP-Identity: MCowBQYDK2VwAyEA3w7gP0g7vM3...
10.3. 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 [RFC4648]
Section 4. The encoded value MUST represent exactly 32 bytes of raw
Ed25519 public key material.
11. Normative References
Litzki Expires 11 December 2026 [Page 14]
Internet-Draft SOVP June 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>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987,
<https://www.rfc-editor.org/info/rfc1035>.
Appendix A. Implementation Status
A reference implementation is available under the Apache 2.0 license:
https://github.com/litzki-systems/sovp-python
Litzki Expires 11 December 2026 [Page 15]
Internet-Draft SOVP June 2026
The current implementation (v1.0.3) provides the following
capabilities:
* Signing and verification primitives: generate_keypair(),
sign_identity(), verify_identity() using Ed25519 (RFC 8032) and
JCS (RFC 8785).
* Document generation: generate_identity_document() builds complete
sovp-identity.json artifacts including integrity_proof.
* DNS resolution: resolve_dns_pubkey() resolves _sovp.{domain} TXT
records and parses the v=SOVP1; k=<base64> format.
* HTTP retrieval: fetch_identity_document() retrieves /.well-known/
sovp-identity.json with fallback path support.
* Full pipeline: validate_domain() executes DNS resolution, HTTP
retrieval, and Ed25519 verification in a single call.
* CLI tooling: sovp generate-keypair, sovp sign, sovp verify.
* Replay protection: timestamp validation via check_timestamp
parameter (600 second window).
* RFC conformance test vectors: six deterministic test vectors
covering valid verification, tamper detection, wrong key
rejection, and timestamp validation, all passing.
* Cloudflare Worker reference deployment: workers/sovp-identity/
provides a complete example of serving a spec-compliant sovp-
identity.json endpoint.
Known limitations: nonce-based replay protection is not yet
implemented. SOVP Gateway (Mode B) enforcement behavior is
implementation-defined and not provided by the reference
implementation.
Production deployments using this specification include:
* litzki-systems.com: the protocol author's infrastructure domain,
operating as the first SOVP-certified deployment. End-to-end
verification (DNS TXT resolution, HTTP retrieval, Ed25519
verification) produces Psi_core = 1 against the live endpoint.
* CERTavia (certavia.org): a compliance certification product built
on SOVP that issues machine-verifiable EU AI Act infrastructure
compliance assessments. CERTavia uses SOVP validation as a core
component of its certification pipeline.
Litzki Expires 11 December 2026 [Page 16]
Internet-Draft SOVP June 2026
Both deployments are operated by Litzki Systems LLC. No external
implementations have been reported at the time of this writing.
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 11 December 2026 [Page 17]