Hayden B

> These pseudonyms would be public (which has its own downsides—metadata can link packages written by the same pseudonymous author), so changes could be detected (possibly using a transparency log...

I think where I'm getting stuck on is that initial step of an identity delegating trust to a pseudonym. Without an authentication mechanism (e.g. OIDC), it'll be hard to associate...

> My intuition was then that Sigstore "guaranteed" that property by only trusting a handful of "high-quality" OIDC providers that actually preserve that property, e.g. Google, MS, and GitHub. Yep,...

@znewman01 wrote about DIDs in https://blog.sigstore.dev/privacy-in-sigstore-57cac15af0d0 It's something we could consider at some point, but for ease of use with the current infrastructure, OIDC is the best that we've got...

This has some up before - https://github.com/sigstore/cosign/issues/1313 There's some questions around how best to represent a subject. I haven't given a lot of thought to the UX side of this,...

`cert-san` reveals unnecessary details of X.509 in my opinion, where the subject is in the certificate is just an implementation detail. We need to consider that the subject may not...

I believe https://github.com/sigstore/cosign/issues/1554 should address this.

I’m going to review 1921 today. i would prefer we not submit 1932 without more discussion.

cc @asraa about TUF There's so much we should move to sigstore/sigstore. The TUF client should be moved too at some point. I'm fine with having this moved out to...

> Maybe if there was a Sigstore-TUF client struct that had this configurable, and it had a default constructor that pulled from an environment variable? +1, that's how I'd prefer...