Currently, the Signer interface does not prescribe the internal data structure of a signer implementation. This is because a signer is responsible for one thing only -- signing, and can be completely decoupled from private key data, and mostly decoupled from public key data.

The latter actually is part of the interface method from_priv_key_uri, which is the canonical way of loading signers, and is usually based on information from the public key (e.g. keytype/scheme).

While signers don't necessarily require the full public key object once loaded, all current implementations ¹ do cache and use it for signing, usually to dispatch on scheme, and assign keyid to the resulting signature.

If we add the de-facto interface field public_key: Key indeed to the interface, signers could also be used to verify their signatures, for which use cases exist ².

The alternative to this proposed change would be to introduce a container format for "signer, public key"-tuples. Although, this seems unnecessary, if most signer already contain the public key.