Add ephemeral clients as a core scenario

[SteveLasker]

In a serverless world, where clouds are moving to on-demand instancing of workloads, we need to account for nodes that are delivered to users on-demand.
This means the client has no historical, trusted reference point.
If we don't trust a single endpoint ( the registry) then we must account for how a client is configured quickly as clouds are striving for sub second instancing of a container on ephemeral nodes.

[sudo-bmitch]

I'd say this applies not only to clients verifying signatures, but also to ephemeral CI build nodes that are signing images. At least some users will perform the signing as part of their CI pipeline and inject a delegated signing key for the task. This would mean that no stateful data can be required on the signing node, e.g. we can't rely on the build node to know the state of all the other signatures in the repository (this could impact the options a potential TUF implementation has to managing the targets metadata).

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.