Sovereign Validation Protocol (SOVP)

5.1. Content Address Scope

contentAddress, when present, is an object with the fields alg and digest. digest is the SHA-256 hash, encoded as lowercase hexadecimal, of exactly the same byte sequence that forms JCS(M), the signed scope defined in Section 5.2 below, i.e. it is computed by applying the identical three-key exclusion algorithm (removing integrity_proof, contentAddress, and scan, and nothing else) and the identical JCS canonicalization step, then hashing the result. It is computed after signing and is itself unsigned. Its purpose is to let an external consumer (for example, a catalog or index that references this document by its content hash) pin and verify the exact content of the identity claim without re-running Ed25519 verification; such a consumer recomputes the digest over the received document, using the same exclusion algorithm, and compares it to the referenced value.¶

contentAddress is unauthenticated. It is not covered by the Ed25519 signature (in this design it is computed after signing and is not part of the signed scope) and an attacker who can modify or replace the served document can freely remove, alter, or fabricate a contentAddress object without invalidating Psi_core, because contentAddress is one of the three keys stripped before signature verification. contentAddress therefore provides content-identity (consistency/indexing) verification only. It MUST NOT be treated as evidence of authenticity, integrity against tampering, or non-repudiation; those guarantees are established exclusively by a successful Psi_core verification of integrity_proof.signature. A Validating Agent or Sovereign Gateway MUST NOT base any trust decision, including partial or conditional acceptance of a document, on the presence, absence, or matching of contentAddress.¶

5.2. Deployment Signing Correctness

Implementations MUST canonicalize and sign only the fields inside the signed scope defined above; canonicalizing the full document including integrity_proof would make signing self-referential and is invalid. The exclusion set is exactly { integrity_proof, contentAddress, scan }; no other field is ever excluded on the basis of being an "extension" or being unrecognized. Verifiers MUST apply the identical three-key exclusion set before recomputing JCS(M) against the received signature; a verifier that excludes a field beyond this set, or fails to exclude one of these three, will report some or all genuinely valid documents as invalid.¶

6.1. Retrieval and Fallback

Retrieval path fallback: the verifier falls back from /.well-known/sovp-identity.json to /sovp-identity.json if and only if the well-known path returned HTTP status 404 (Not Found). Any other outcome on the well-known path (a 5xx server error, a connection timeout, a TLS handshake failure, or a connection reset) MUST cause the verifier to fail the verification for that request outright; it MUST NOT fall back to the root path in these cases. This restriction exists because an attacker who can selectively disrupt one retrieval path (for example, by causing 5xx responses or timeouts on /.well-known/ while serving a forged document at the root path) would otherwise be able to force a verifier onto a fallback path of the attacker's choosing.¶

If the host does not support SOVP, provides no sovp-identity.json at either retrieval path (the well-known path returns 404 and the root path returns no document), the outcome is evidence_missing. A Sovereign Gateway then acts as follows, as it does for every other outcome except verified and accepted:¶

• Standard action: the request is rejected per Section 6.3.¶
• Exception: Local allow-lists MAY be defined for legacy systems, though these bypass the Layer 0 integrity guarantee.¶

6.2. Verification Order and Outcomes

A verifier applies the following steps in this order and returns the outcome of the first step that fails. Steps marked (B) apply to a verifier that claims instance binding conformance (see Section 8); other verifiers skip them. The retrieval host is the host component of the URL from which the document was retrieved, in lowercase A-label form [RFC5890] without port or trailing dot. A verifier MUST NOT verify a document retrieved from a host given as an IP literal.¶

1. Retrieval and input limits: if no document is obtained, the outcome is evidence_missing. If the document violates the limits of Section 9.8, is not a JSON object, or declares a @context, @type, or entity.verification_method that the verifier does not support, the outcome is document_invalid. A verifier claiming instance binding conformance supports only the @context value https://litzki-systems.com/protocol/v2.0, the @type "SovereignIdentity", and the verification_method "Ed25519", and a document that declares an earlier schema version MUST NOT yield accepted. Other verifiers MAY support earlier schema versions as described in Section 9.4.¶
2. (B) Authorization availability: if the verifier has no authorization path (see Section 8.2) for the retrieval host, the outcome is authorization_undetermined.¶
3. Host binding: if the host of entity.canonical_url, normalized in the same way, differs from the retrieval host, the outcome is host_mismatch.¶
4. Key resolution: the verifier resolves the key set as specified in Section 7. If resolution fails or yields no valid key, the outcome is key_unresolved.¶
5. Signature: the verifier evaluates Psi_core under each key of the set. If none verifies, the outcome is invalid_signature. The key under which the signature verifies is the verifying key.¶
6. (B) Anchor authorization: if the authorization path does not authorize the verifying key for the pair (retrieval host, entity.uid), the outcome is anchor_untrusted.¶
7. Freshness: the verifier applies the checks of Section 9.4. A missing, malformed, or inconsistent freshness member (items 1 and 2 there) yields document_invalid. A failure of the issuance window or of the expiry (items 3 and 4 there) yields stale. A verifier claiming instance binding conformance MUST apply the issuance window with a configured W.¶
8. (B) Instance member: if the document has no instance member, the outcome is instance_missing.¶
9. (B) Binding: if the checks of Section 8.1 fail, the outcome is instance_mismatch.¶
10. Otherwise the outcome is accepted for a verifier claiming instance binding conformance and verified for any other verifier.¶

verified means that the document was produced by the current holder of a key published for the retrieval host. It does not mean that the holder is authorized to attest anything about the host or about an instance (see Section 8.2). The fixed order makes each outcome deterministic for a given input, which allows independent implementations to be compared test case by test case (see Appendix A).¶

6.3. Rejection Status Codes

A Sovereign Gateway that rejects a request at Layer 0 MUST respond with status code 403 (Forbidden) Section 15.5.4 of [RFC9110]. This applies to every outcome other than verified and accepted. Status code 401 is not used: Section 15.5.2 of [RFC9110] requires a 401 response to carry a WWW-Authenticate challenge, and this document defines no HTTP authentication scheme. Status code 422 is not used either, because [RFC9110] ties it to a well-formed request that is semantically erroneous at the application layer, which does not describe a Layer 0 credential failure. A gateway MAY include a problem details object [RFC9457] that distinguishes the outcomes; this document defines no problem types.¶

8.1. The instance Object

"instance": {
  "id": "0192f5c4-7e1a-7c3b-9d2e-5a4b6c7d8e9f",
  "descriptor_digest": {
    "alg": "sha256",
    "digest": "<lowercase hex SHA-256 digest>"
  }
}

• id (REQUIRED): the identifier of the deployment instance, exactly as assigned by the deployment description in use. Verifiers MUST compare it as an opaque string and MUST NOT parse it or infer structure from it. Where the deployment is governed by an Agent Manifest [AGENT-MANIFEST] that declares agent_instance_id, instance.id SHOULD equal that value. Where an ARD catalog entry [ARD] names the instance, instance.id SHOULD equal that name; a proposal to add an instances array with an instanceId member to ARD is under discussion [ARD-INSTANCES], and this document makes no assumption about its outcome.¶
• descriptor_digest (OPTIONAL): {alg, digest} over the deployment descriptor the issuer evaluated. If the descriptor is a JSON value, the digest is computed over its JCS canonicalization; otherwise it is computed over the exact octets of the descriptor as retrieved, unless the descriptor format defines otherwise. This document defines no descriptor format.¶

The verifier obtains the expected instance identifier, and the descriptor if it holds one, from its own context, for example from the manifest or deployment record it is evaluating. It MUST NOT take an expected value from the document under test. The outcome is instance_mismatch if instance.id differs from the expected identifier, or if the verifier holds a descriptor and the document either lacks descriptor_digest or carries a digest that differs from the one computed over that descriptor.¶

8.2. Anchor Authorization

A successful Psi_core establishes that the signature was produced by whoever controls the private key matching a K_pub published in DNS for the retrieval host (see Section 9.5). That DNS name is normally controlled by the party that operates the deployment under evaluation. Control of a key is therefore not authorization of that key.¶

A verifier claiming instance binding conformance MUST resolve the verifying key through an authorization path, and MUST confirm that the path authorizes that key for the pair (retrieval host, entity.uid). The path MUST be external to the SOVP document and MUST NOT be derived from any identifier the attested subject controls, including the DNS record that publishes the key. Examples are a verifier-configured list of trusted issuers, a key pinned by the verifier's operator, and an issuer registry maintained by a party other than the subject. The mechanism is deployment policy, and this document defines no registry. This follows the principle stated in Section 5.3.3 of [AGENT-MANIFEST]: a key identifier identifies a key and does not authorize one.¶

Issuer and subject MAY be the same organization. A self-attesting subject reaches accepted only if the verifier's operator has pinned its key through a path of the kind above; otherwise the outcome is authorization_undetermined or anchor_untrusted.¶

8.3. Layer Boundaries

A SOVP identity document, with or without the instance member, is a signed claim about who controls a key for a host and, with this extension, which deployment instance the claim refers to. Its signed scope contains no measurement of the execution environment. Scanner output carried in the scan member lies outside the signed scope (see Section 5) and receives no assurance from Psi_core. Assessment results such as verdicts or scores require a separate signed document, issued under a key that the verifier resolves independently (see Section 8.2); the format of such a document is out of scope here.¶

A SOVP document makes no claim about permitted actions, runtime behavior, or the content of an Agent Manifest. A consumer that composes SOVP documents with Agent Manifest or TRACE records MUST treat each as a separate claim, MUST join them only through the declared instance identifier, and MUST NOT infer the validity of one layer from the validity of another.¶

9.1. Threat Model

SOVP considers an attacker who can observe and modify network traffic to a verifier, who can publish content on hosts and DNS zones the attacker controls, and who can copy any public SOVP document. The protocol detects modification of a document after signing, replacement of a document by a party that holds no key published for the retrieval host, and presentation of a document under a host other than the one it names. It does not protect against compromise of the signing key, of the zone that publishes the key, or of the host that serves the document.¶

Compared with relying on the TLS session alone, a signature checked against a DNS-published key can be re-verified from a stored copy and does not depend on the TLS terminator or a content delivery network. Related designs are DKIM [RFC6376], which publishes signing keys in TXT records under an underscored label, DANE [RFC6698], which binds keys to TLS endpoints through DNS, and HTTP Message Signatures [RFC9421], which sign individual messages. SOVP signs a standing document and not a message.¶

9.2. Requester Is Not Authenticated

A SOVP document is public. A party that copies it can present it, and verification of that document says nothing about who sent a request. A Sovereign Gateway therefore authenticates a host's document and not the sender. Deployments that need to tie a request to a host need another mechanism, for example HTTP Message Signatures [RFC9421] made with a key that is bound to the host. This document defines no such binding.¶

9.3. 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. Because a signature is accepted if it verifies under any key in the published set (see Section 7), a compromised key remains acceptable to a verifier until its record has expired from that verifier's resolver caches, and a rotation is complete only after the record of the retired key has been removed. A verifier that caches documents or keys extends this window by the cache lifetime and SHOULD NOT cache beyond the DNS TTL of the key record.¶

9.4. Replay Protection

Freshness uses the freshness object (created, nonce, expiresAt), which is part of the Ed25519-signed scope (see Section 5.2). Because freshness is covered by the signature, none of its fields can be altered, including being pushed further into the future, without invalidating Psi_core. A verifier applies the following checks, in order, to every document whose signature has already passed Psi_core verification:¶

1. Both freshness.created and freshness.expiresAt MUST be present and MUST be formatted as UTC timestamps as specified for the freshness member in Section 5 (for example 2026-06-01T12:00:00Z). A document failing this check MUST be rejected.¶
2. freshness.expiresAt MUST be strictly later than freshness.created. A document where expiresAt is equal to or earlier than created MUST be rejected.¶
3. Issuance window: let now be the verifier's current time. A verifier SHOULD reject a document unless now - W <= created <= now + N, where W is the maximum accepted age and N is the allowance for clock skew between signer and verifier. The default value of W is 600 seconds; a verifier MAY use a longer W by local policy. N = 60 seconds is RECOMMENDED. A verifier claiming instance binding conformance MUST apply this check.¶
4. Expiry: if now > freshness.expiresAt, the document MUST be rejected as expired. This check has no numeric bound of its own: expiresAt is chosen by the signer and bounds overall document validity, analogous to the notAfter field of a certificate.¶

The issuance window and the expiry check serve different purposes. The window bounds how long ago the document was issued and is evaluated against created only. A signer that serves a pre-signed document therefore needs to re-sign it at an interval shorter than W for the document to pass a verifier that uses the default window. This keeps the signing key on a system that is online at that interval, and operators should weigh that exposure; a longer W by local policy trades freshness for key isolation. The expiry check bounds how long a document remains valid at all.¶

Replay of a document within W is not prevented: a verifier has no challenge to bind the document to a request, and a copy of a fresh document is as fresh as the original. nonce is intended to support deduplication of high-frequency requests, but a verifier MUST NOT treat the presence of a nonce alone as a deduplication guarantee, because replay detection requires the verifier to remember nonces it has seen, which this document does not specify.¶

For documents whose @context declares a schema version earlier than 2.0, the equivalent created and expiresAt fields were carried in integrity_proof, which lies outside the signed scope; any change to them is undetectable by Psi_core. A verifier that supports such documents MAY apply the checks above as a best-effort heuristic and MUST NOT treat the result as cryptographically guaranteed.¶

9.5. Attribution

SOVP attributes the signed metadata to the party that holds the private key matching a K_pub published for the retrieval host when the verifier resolves it. This is attribution to the current key holder and is not non-repudiation in a legal or historical sense: DNS records can be changed or removed, and a verifier that did not record the key at the time cannot later show who held it. Attribution does not establish the signer's legal or real-world identity (see Section 3): SOVP makes no claim about who controls a domain, only that the party that published K_pub produced the signature. SOVP itself defines no reputation system and makes no claim about whether, or by what mechanism, a domain's signing history could be used by a third party to identify or block that domain in the future.¶

9.6. DNS Security (DNSSEC)

Because the trust anchor is a DNS TXT record, protection against DNS spoofing is critical. DNSSEC [RFC4033] is RECOMMENDED for the zone that hosts the _sovp record. A verifier SHOULD resolve the record through a validating resolver and SHOULD treat a DNSSEC validation failure as a resolution failure. Without DNSSEC, the integrity of the resolved key depends entirely on the DNS resolution path (cache integrity of intermediate resolvers, absence of on-path spoofing, and the transport used to reach the resolver), a path that SOVP does not protect and cannot monitor. Operators who need a trust anchor stronger than that resolution path need DNSSEC; SOVP offers no alternative mechanism.¶

9.7. Public Key Source Authority

A verifier MUST NOT determine K_pub from any source other than the DNS TXT record for the retrieval host. In particular it MUST NOT use an HTTP header field or any value in the document, including integrity_proof.public_key_ref and entity.canonical_url, for that purpose: a verifier that did so would learn only that the document is consistent with itself.¶

9.8. Resource Limits for Unverified Documents

A verifier parses the document before Psi_core is known, so the document is attacker-controlled input at that point. Before canonicalization, a verifier MUST reject a document, with the outcome document_invalid, that is larger than 65536 octets, that contains JSON values nested deeper than 16 levels (the top-level object is at level 1), or that contains a duplicate member name in any object. The size limit applies to the octets of the document after any HTTP content decoding. Duplicate member names are rejected because JSON parsers differ in which value they keep (see [RFC8259]), so a document could be read differently by a verifier and by a consumer of the same bytes. A verifier MUST NOT canonicalize or otherwise process a document before these checks have passed.¶

9.9. Retrieval Considerations

Retrieving the document and resolving the key consume a verifier's resources on behalf of whoever caused the request. A verifier SHOULD bound the time spent on each retrieval and each DNS query, and SHOULD limit the rate of retrievals per source. A verifier that derives the host to retrieve from untrusted input MUST NOT retrieve from addresses that are not meant to be publicly reachable (for example loopback, link-local, and private ranges), and MUST check the address after name resolution, to avoid server-side request forgery and DNS rebinding.¶

A verifier SHOULD NOT follow HTTP redirects when retrieving the document. A verifier that follows them MUST still derive the DNS name from the host of the original request URL (see Section 7) and MUST NOT follow a redirect to a URL that does not use the https scheme.¶

9.10. Privacy Considerations

Each retrieval and each DNS query tells the publisher of the document and the operators of the resolvers that a verifier is interested in a host. A gateway that verifies on behalf of many requesters can reveal request patterns this way. This document defines no mitigation.¶

9.11. Self-Published Trust Anchor and Instance Labels

The DNS TXT record that anchors K_pub lies under the control of the entity that serves the document. Without the external authorization step in Section 8.2, a verifier learns that the document and the key come from one party and learns nothing about whether that party may attest for the instance. An attacker who controls a host can sign any instance identifier for it. Verifiers MUST therefore take the expected instance identifier from their own context, as required in Section 8.1, and MUST NOT treat a matching instance.id alone as evidence of authenticity.¶

Because instance is inside the signed scope, a party that does not hold the signing key cannot retarget a signed document to a different instance without invalidating Psi_core. This protects against retargeting after the fact and does not protect against an issuer that signs a false claim.¶

11.1. Underscored and Globally Scoped DNS Node Names

Per [RFC8552], IANA is requested to add the following entry to the Section 11.1 registry:¶

11.2. Well-Known URI: sovp-identity.json

Per [RFC8615], the following entry is to be added to the "Well-Known URIs" registry:¶

• URI suffix: sovp-identity.json¶
• Change controller: IETF¶
• Specification document(s): This document (Section 5)¶
• Status: provisional¶
• Related information: none¶

A.1. Base Vector (Schema v2.0)

Document A.1:¶

NOTE: '\' line wrapping per RFC 8792

{
  "@context": "https://litzki-systems.com/protocol/v2.0",
  "@type": "SovereignIdentity",
  "entity": {
    "uid": "urn:sovp:test-entity-2",
    "canonical_url": "https://example.org",
    "verification_method": "Ed25519"
  },
  "freshness": {
    "created": "2026-06-01T12:00:00Z",
    "nonce": "fixed-test-nonce-v2-0001",
    "expiresAt": "2026-12-01T00:00:00Z"
  },
  "contentAddress": {
    "alg": "sha256",
    "digest": "d00c6db5124803dd67495b0551dc0249994fd6f818509724202\
6e28a4d30b460"
  },
  "integrity_proof": {
    "signature": "Th2wr122ikRicemrC5bITXHri5glqNqfkPosCjLBjXLIdO2U\
StZm5j7SmJ0j1xuEYAPOc9WtJW4blsceuCVCBg==",
    "public_key_ref": "dns:txt:_sovp.example.org"
  }
}

JCS(M), the canonicalized signed scope (312 octets), whose SHA-256 digest equals contentAddress.digest above:¶

NOTE: '\' line wrapping per RFC 8792

{"@context":"https://litzki-systems.com/protocol/v2.0","@type":"\
SovereignIdentity","entity":{"canonical_url":"https://example.or\
g","uid":"urn:sovp:test-entity-2","verification_method":"Ed25519\
"},"freshness":{"created":"2026-06-01T12:00:00Z","expiresAt":"20\
26-12-01T00:00:00Z","nonce":"fixed-test-nonce-v2-0001"}}

A.2. Instance-Bound Vector

The same key and entity with an instance member. The descriptor is the following JSON text, which is already in JCS form, and descriptor_digest.digest is the SHA-256 digest of its UTF-8 octets:¶

NOTE: '\' line wrapping per RFC 8792

{"instanceId":"0192f5c4-7e1a-7c3b-9d2e-5a4b6c7d8e9f","url":"http\
s://example.org/agent"}

Document A.2:¶

NOTE: '\' line wrapping per RFC 8792

{
  "@context": "https://litzki-systems.com/protocol/v2.0",
  "@type": "SovereignIdentity",
  "entity": {
    "uid": "urn:sovp:test-entity-2",
    "canonical_url": "https://example.org",
    "verification_method": "Ed25519"
  },
  "freshness": {
    "created": "2026-06-01T12:00:00Z",
    "nonce": "fixed-test-nonce-v2-0001",
    "expiresAt": "2026-12-01T00:00:00Z"
  },
  "instance": {
    "id": "0192f5c4-7e1a-7c3b-9d2e-5a4b6c7d8e9f",
    "descriptor_digest": {
      "alg": "sha256",
      "digest": "d9714591fa2a1ef5b07331bd3437d4f5a79f9321b26009293\
6decf8fbab3848d"
    }
  },
  "contentAddress": {
    "alg": "sha256",
    "digest": "7ddd289e0e3dd81df253a9fdbeb18760aa94ae87286c6eca676\
eeb11a7619140"
  },
  "integrity_proof": {
    "signature": "+ey/Rr3G/Qeu+VSsyA8fPI66qSy+V0T6YBxJsoxtcEK77YoH\
wH2cLd6mZnNROnCYMHgoTpakAIBDoC9mbFY/Dg==",
    "public_key_ref": "dns:txt:_sovp.example.org"
  }
}

JCS(M) (482 octets):¶

NOTE: '\' line wrapping per RFC 8792

{"@context":"https://litzki-systems.com/protocol/v2.0","@type":"\
SovereignIdentity","entity":{"canonical_url":"https://example.or\
g","uid":"urn:sovp:test-entity-2","verification_method":"Ed25519\
"},"freshness":{"created":"2026-06-01T12:00:00Z","expiresAt":"20\
26-12-01T00:00:00Z","nonce":"fixed-test-nonce-v2-0001"},"instanc\
e":{"descriptor_digest":{"alg":"sha256","digest":"d9714591fa2a1e\
f5b07331bd3437d4f5a79f9321b260092936decf8fbab3848d"},"id":"0192f\
5c4-7e1a-7c3b-9d2e-5a4b6c7d8e9f"}}

A.3. Outcome Vectors

Unless a row states otherwise, the verifier context is: retrieval host = example.org; DNS publishes the key of A.1 (K) only; the authorization path authorizes K for (example.org, urn:sovp:test-entity-2); now = 2026-06-01T12:05:00Z; expected instance identifier = 0192f5c4-7e1a-7c3b-9d2e-5a4b6c7d8e9f; expected descriptor digest = d9714591fa2a1ef5b07331bd3437d4f5a79f9321b260092936decf8fbab3848d; the issuance window W is 600 seconds with N = 60 seconds. K' denotes the key RYVkYPO0CymHmHNYfjw3a9baEyWH40fnEzrgY/rMA5M=, which does not correspond to the test key. The verifier claims instance binding conformance.¶