Struct PublishValidator 

pub struct PublishValidator<'a> { /* private fields */ }

Stateless publish request validator.

Runs §2.1 steps 1–5 and the key_id binding of step 6 (structural and hash checks); steps 6–7 (DID resolution + signature) run separately. Steps 8+ (identifier assignment, lineage, supersession, persistence) are registry-implementation concerns.

Implementations

impl<'a> PublishValidator<'a>

pub fn new(caps: &'a CapabilitiesDocument) -> Self

Create a validator without same-registry supersession enforcement.

pub fn for_authority( caps: &'a CapabilitiesDocument, own_authority: &'a str, ) -> Self

Create a validator that rejects cross-registry supersession.

own_authority is the registry’s DNS authority (e.g. registry.example.com). When set, a publish request whose supersedes ctx_id has a different authority will be rejected with AcdpError::SupersededTarget / CrossRegistrySupersessionUnsupported (RFC-ACDP-0006 — v0.1.0 only allows same-registry supersession).

pub fn validate_post_schema( &self, req: &PublishRequest, raw_body_bytes: usize, ) -> Result<ValidatedPublish, AcdpError>

Validate a publish request through the structural / cryptographic steps of RFC-ACDP-0003 §2.1, plus the cross-registry-supersession guard if the validator was built with Self::for_authority.

Mapped steps from RFC-ACDP-0003 §2.1:

• Step 1 (schema validation) — runs acdp_validation::validate_publish_request first, which also enforces step 11’s visibility/audience rule.
• Step 2 (payload size vs limits.max_payload_bytes).
• Step 3 (embedded size vs limits.max_embedded_bytes).
• Step 4 (hash recomputation over ProducerContent).
• Step 5 (signature algorithm vs supported_signature_algorithms).
• Step 6, binding half (key_id DID portion equals agent_id).
• Steps 6–7 (DID resolution + signature verification) — async, handled separately by acdp_verify::verify_publish_request_signature.
• Cross-registry supersession check (RFC-ACDP-0006): when an own-authority is configured, rejects supersedes targets on a different authority.

pub fn validate_post_schema_raw( &self, req: &PublishRequest, raw: &Value, raw_body_bytes: usize, ) -> Result<ValidatedPublish, AcdpError>

Self::validate_post_schema for a front-end that still holds the request JSON as received: step 4 recomputes content_hash over raw (RFC-ACDP-0001 §5.7 “Hash verification over raw JSON”, REQUIRED for registries too) rather than over a typed re-serialization of req. raw MUST be the object req was parsed from; if it no longer describes req, the typed path is used instead (so a post-parse mutation is detected, not masked).

Storage obligation. Accepting a request on the raw path is only sound when the registry also persists and serves the producer-controlled fields exactly as received. A store that keeps the typed PublishRequest (as InMemoryStore does) re-serializes timestamps in the §5.3 canonical form, so a body accepted here under a non-canonical spelling (e.g. a +00:00 offset) would later be served with bytes that no longer match its content_hash. Typed-store registries should use Self::validate_post_schema, which accepts exactly the spellings the typed store reproduces.

pub fn validate_structural( &self, req: &PublishRequest, raw_body_bytes: usize, ) -> Result<ValidatedPublish, AcdpError>

👎Deprecated since 0.1.0:

Use validate_post_schema; this alias no longer skips runtime validation

Deprecated alias — now routes through Self::validate_post_schema.

The previous implementation skipped the schema-level validation (title length, metadata depth, DataRef integrity, did:web check, version coherence, …). Callers using validate_structural directly were silently bypassing those checks. The deprecated alias now runs the full pipeline so existing call sites remain safe; new code should call validate_post_schema explicitly.