Expose publisher account and signing identity per tag via Docker Hub API

[zeitlinger]

For security tooling that verifies the publisher and integrity of a container image, the OCI image manifest exposes only publisher-set labels (org.opencontainers.image.authors, etc.), which are attacker-controllable. The registry-verified signals — who actually pushed the tag, and what's been signed — aren't currently surfaced on the public Docker Hub tag endpoints, so consumers have to do separate auth lookups and referrers walks to discover them.

What we'd actually want (lead ask)

Registry-verified publisher account + signing-key fingerprint per tag — which Docker Hub account ran docker push for this tag, and (if Docker Content Trust / a stable signing key is associated) the key fingerprint. This is the registry-verified-publisher equivalent of npm's _npmUser / NuGet's owners / crates.io's /owners. It's the broadly-available signal today across all of Docker Hub.

For comparison:

• GHCR exposes the publishing GitHub identity via the GitHub Packages API.
• npm surfaces _npmUser (and hasAttestation).
• NuGet, crates.io expose registry-verified publisher accounts (owners).
• Docker Hub doesn't expose the publishing account on the tag-info endpoint.

Use case

Third-party PR auto-approval and supply-chain monitoring tools want to, for each pulled tag:

• Verify the publishing account is on a trusted-publishers allowlist (e.g. "the official library/ namespace", "the grafana org account").
• Detect account changes between versions of the same image (transfer-of-ownership / credential-compromise indicators).

Both are possible today via custom auth lookups, but it's heavy for what should be a routine read.

What would help

Add to the /v2/repositories/<namespace>/<repo>/tags/<tag>/ response, or a peer endpoint:

• published_by: "<docker-hub-account-login>" (or null for anonymous)
• signing_key_fingerprint: "..." (where DCT or similar is in use)

Authentication shouldn't be required for public repositories — analogous to npm and NuGet.

Stronger follow-up signal (defense-in-depth)

Once the publisher account is exposed, a natural phase-2 ask is cosign / sigstore signature presence + signing identity per tag. Docker Hub already stores these via the OCI v1.1 referrers API — surfacing "this tag has a verified cosign signature, signed by https://github.com/<org>/<repo>/.github/workflows/release.yml@refs/tags/<ver> (sigstore keyless identity)" on the tag-info response would let consumers cheaply decide whether to verify, without a separate referrers walk for every tag they look at. Same argument applies to SLSA provenance attestations and their builder identity.

Analogous to NuGet's gap where Authenticode signatures exist server-side but aren't exposed via the gallery API — see NuGet/NuGetGallery#10542. Docker Hub has the same shape of gap for cosign/sigstore data.

Concrete test target consumers could verify against once this is exposed: martincostello/eurovision-hue publishes a sigstore-signed + attested GHCR image — a known-good fixture for validating that the exposed signing identity matches the source workflow.

Happy to discuss scope, refile against a different repo if this isn't the right home, or contribute if appropriate.

[github-actions]

Thank you for your feedback 👍.

Our team will review your issue shortly.
In the meantime, feel free to provide as many details as possible, as this will speed up the resolution.

If you need assistance rather than providing feedback, please contact the Docker support team via https://hub.docker.com/support/contact for a prompt response, and close this issue.