Module rotation 

RFC 0001 — the signed key-rotation attestation (spec/aph-0.2.md).

One claim, made by the CURRENT key: this named successor is mine. What it buys: a verifier can check that a successor was named BY ITS PREDECESSOR rather than merely served from the same origin — §8.4.7’s bare overlap upgraded to a chain a stranger can walk. What it cannot buy, per the RFC’s own §5 and repeated here so no caller oversells it: a stolen current key signs a rotation too; a verifier meeting an identity for the first time has nothing to chain from (continuity, not genesis); and it is no recovery from key LOSS, because the lost key can no longer speak.

Zero new cryptography (RFC 0001 §2.3): the statement is signed exactly as a lone-proof envelope is — RFC 8785 JCS over the object with proof.proofValue PRESENT AND EMPTIED (never removed; §8.2 records the draft era that got that wrong), eddsa-jcs-2022, multibase proof value. Publication (RFC 0001 §3.1): the DID Document property DID_DOC_ROTATION_PROPERTY, full-URI keyed so JSON-LD expansion cannot drop it, atomic with the successor key’s own entry.

Structs

RotationAttestation

RFC 0001 §2.1’s statement, byte-for-byte the published shape. Every member is inside the signed bytes for the reason its §2.2 table states.

RotationSuccessor

The successor a rotation attestation names: the key, its fragment, and its activation bounds.

Constants

DID_DOC_ROTATION_PROPERTY

The DID Document property carrying attestations (RFC 0001 §3.1): an array of statements, keyed by full URI so a JSON-LD-processing resolver survives expansion without a context definition APH does not serve.

ROTATION_ATTESTATION_TYPE

The statement’s type literal. A verifier refuses any other value: this object is not a VC on purpose (RFC 0001 §2.4 — a VC invites credentialStatus, whose freshness bound is the opposite of what a rotation attestation needs).

Functions

sign_rotation_attestation

Signs an attestation in place: proof.proofValue is computed over the lone-proof base and written back multibase. Exists for the committed test vectors and for operators minting real statements through the reference; it accepts a caller-held signing key and never touches key storage.

verify_rotation_attestation

Verifies a rotation attestation against the PREDECESSOR’s public key — the key the verifier already trusts, resolved through §8.4 or remembered from prior contact. Everything checkable is checked before the signature, and every refusal is APH_E024 carrying the specific defect, because “the attestation is invalid” with no reason teaches an operator nothing.