SLSA verifier as a service

[laurentsimon]

To make the verifier accessible to everyone easily, we could have a REST/gRPC API to verify as a service.
Possible use cases:

• OSSF or another org runs a verifier as a service. Note that this requires more thoughts w.r.t authenticity of the results. TLS interception does happen, so we ought to think about signing the results. This quickly becomes complicated if we want to support key rotation.
• Someone wants to deploy a service on their k8 cluster. Same question here around authenticity of the results. May need some sort of workload identity support
• Someone wants to deploy a service on their own infra, using a container image

[asraa]

It would also be beneficial for a service to have a configuration of options: e.g. if we have a stable service, we can more easily pin a trust root for the sigstore signing service (e.g. a hosted sigstore ecosystem).

Moreover, we can do things like enforce certain properties of builds with a service configuration rather than CLI options

[laurentsimon]

yep I agree having option will be useful. I was thinking it could even be aligned with #158?

Do you see use cases where the service and the CLI would significantly differ? I was thinking we could try to have them be more-or-less the same interface. That improves usability for a user who first tries the service, then wants to use the CLI and vice-versa. I would not say this is a hard constraint, though, but it'd be nice.

Was that the sort of configuration you had in mind; or something different?

[ianlewis]

If we actually go through with creating a service, I wonder if it would make sense to define the service using grpc and expose it as a JSON service through grpc-gateway.