How it works in AgenID
A verification authority is named agenid:authority:<node>. Its key document declares role authority with the authority as controller, and is discoverable at the authority's own /.well-known/agenid/keys.json. A verifier checks a verification assertion against that key and must also decide whether it recognizes the authority; a valid signature from an unrecognized authority is authority_untrusted, not VERIFIED. The registry refuses an authority-role key at agent registration.
Every assertion names the key_id that signed it, and an authority key follows the same lifecycle rules as an operator key: its own ULID, a status field, and resolvability for as long as signatures made with it need checking.
Why it matters
Separate roles stop self-verification. If one key could sign both the declaration and the check, an operator could vouch for itself. The model also admits authorities other than AgenID's own without a protocol change, so verification need not depend on a single vendor.
What it does not mean today
The reference deployment issues nothing above L1_REGISTERED. L2 and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet, so L2, L3 and L4 describe the model rather than anything obtainable. Even when assertions exist, an authority's signature covers one claim in one scope; it says nothing about what the agent is allowed to do.