ping @dmp42 @jlhawn @shykes @stevvooe

The docker login command can be used to register public keys with
the trust system. By default every client and daemon instance of
Docker will generate a public key and using docker login will
register that public key with the credentials provided on login.

So if I run:

$ docker login

am I registering my client's key, my daemon/engine's key, or both?
I'm not sure how this auth is going to work where serveral users use
their clients to talk to the same daemon, and that daemon talks to the
hub. Will the daemon just proxy the auth handshakes between the
client and the hub? In that case, why would the daemon need a key?
But that means you'll need a long-duration token (which the daemon can
cache) if you want the daemon to keep uploading/downloading layers
to/from the hub on your behalf after the client has disconnected.
Long-duration tokens sound like the registry's native auth target
anyway 1.

docker login will only register the client's key. The daemon's key is not relevant in the trust system for provenance or the V2 registry, but it may be in the future for other features. Authentication requests will need to originate on the client, or in the future will be able to proxy through the daemon using identity auth described in #8265 to verify the client has authorized the daemon on their behalf. You are right though that the client will need to pass the long token to the daemon if multiple actions over time are required from a single client interaction.

@SvenDowideit reformatted

nice :) - i just remembered - for your document to be included in docs.docker.com, you also need to add a line to the docs/mkdocs.yml - again, not urgent until feature merge :)

Ping @dmp42 @jlhawn

Made significant updates to the documentation to incorporate key and grant management responsibility to the trust server. This has the effect of reducing the role of the x509 certificate to linking keys and giving the users authority over their own grants. Please review.

Considering that:

• This has been opened for quite some time
• Trust is (currently) assumed to be owned by distribution
• Distribution has its own repo

Does it make sens to close this, and have you submit the documentation on the other repo? Ping @dmp42 @dmcgowan!

Makes sense. Let's close it for now and have it out of your way - will re-open later when "trust" is updated.