How it works in AgenID
The payload carries $schema, proof_type (always manifest_self_declaration), agent_id, manifest_version, manifest_digest, key_id, created_at and expires_at. The signing input is the RFC 8785 canonical bytes of that payload without signature, $schema included, signed with pure Ed25519 and carried as base64url.
A verifier recomputes the manifest digest first, then resolves key_id, requires role operator with controller equal to the agent, checks the time window, and only then checks the signature.
Why it matters
Because anyone can verify the proof, the registry that stores it cannot alter it unnoticed. Registration at /issue rejects a tampered manifest, a wrong key, an authority-role key and a replay before anything is stored.
The time window matters too. expires_at is checked independently of the key's status, so an old proof cannot be presented indefinitely, and the registry bounds how far into the future a new proof's created_at may sit. Everything is re-derivable from the signed object, the manifest and the key document, so a verifier needs nothing from AgenID's database.
What it does not mean
A valid ManifestProof shows who signed and what they declared. It does not make any statement true, and it cannot produce VERIFIED; that needs an authority. Nor does it say what the agent is allowed to do: AUTHORIZED has no signed object in v1.1.1.