Hayden B

> I think we should document this, that clients using public keys are expected to bring their own keyring, manage a selection interface that may depend on the provided key...

As you linked in the other thread on sigstore-go, https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_verification.proto#L92 is what I'm looking for in terms of a struct. Part of my motivation for raising this was after looking...

Yes, that sounds great! We can also link each file to steps in the client specification.

> As a side-note: if we want to be even more structured here, we could use [issue forms](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms) instead of templates. Oh neat! I'll take a look at that.

Oh this might be more than just Rust, I see when I run `make clean`, I get permission denied errors for all generated files. I assume this is because the...

> Another thing which occurs to me is that it might be helpful for the VerificationResult to surface the Fulcio certificate extensions (in the case where the verification is successful)....

That’s good with me. We will use it in fulcio too, since we have to compile proto for grpc.

We wouldn't be able to remove it entirely unfortunately, since it's still used as a signed timestamp from Rekor, but it could be moved under `TimestampVerificationData`. Verification then will require...

Are we using https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_verification.proto? One question is if we want a 1.0 release for everything or just the bundle format. I think the verification options are still a WIP. Do...

Agreed, enums are definitely preferred over strings, less need for validation