Module proof_base 

Per-proof canonicalization bases — spec §7.2.1.

A proof is a signature over bytes, and this module is the single place that decides which bytes. Nothing else in the crate may derive a signing base: signer and verifier must agree exactly, and two code paths that agree today drift tomorrow.

Each proof covers what precedes it, and nothing after it

These are W3C Data Integrity proof-chain semantics, and they are forced: a signer cannot sign bytes that do not exist yet, so a base that included a later proof would be unconstructible. Concretely (§7.2.1):

Role	proof member of the working copy
Lone notary proof	the proof object alone, its proofValue emptied
Principal proof of a chain	a one-element array holding the principal proof, its proofValue emptied — the notary proof is DISCARDED, not blanked
Notary countersignature	the two-element array, the principal’s proofValue COMPLETE and the notary’s emptied

Why the principal’s base keeps the array form

"proof": [{…}] and "proof": {…} canonicalize to different bytes, and that difference domain-separates a principal proof from a lone notary proof. Were the object form used for a one-proof base, an intermediary could strip the notary proof from a PrincipalSigned envelope and re-present the remainder as a valid single-proof envelope: the signature would still verify, and the recipient would read the human’s own proof as a mere notary attestation. With the array form the stripped envelope is a one-element chain, which §7.1.11 rejects outright.

This is not a redundant wrapper waiting to be simplified away. Removing it is a security regression, and stripping_the_notary_proof_... in crate::crypto::eddsa_jcs fails if anyone tries.

Empty, never absent

In every envelope base the covered field is set to the EMPTY STRING, not removed: JCS over an object with proofValue absent and JCS over the same object with proofValue empty are different byte strings, so signer and verifier must make the same choice. §7.2.1 settles it as the empty string. Mandate bases are the documented exception — see mandate_signing_base.

Enums

ProofRole

Which signature’s base is being built (spec §7.2.1).

Constants

DATA_INTEGRITY_PROOF_TYPE

proof.type of the Data Integrity carriage — the value both JCS cryptosuites (eddsa-jcs-2022, ecdsa-jcs-2019) declare (§7.1.11).

Functions

mandate_signing_base

The base a Delegation Mandate signature covers (spec §6.1, §7.2.1).

signing_base

Builds the JCS-canonical signing base for one proof of an envelope.