Add definitions for in-toto statements?

[woodruffw]

Not sure if this is a good idea, or expands the focus of this repo too much; opening for discussion.

Context:

• Sigstore bundles support DSSE envelopes (Bundle.dsse_envelope), and fully exposes the structure of that envelope through messages defined in envelope.proto
• The only payload actually supported by Sigstore in DSSE envelopes is in-toto statements; anything else is rejected by Rekor
• The in-toto statements and associated types are expressed as Protobufs externally here, and have their own pre-generated language bindings

So, my thought: why not embed the in-toto types here, similar to what we've done for the DSSE envelope? This will simplify the dependency graph for Sigstore clients a bit, and (for Python in particular) will eliminate the stacking of different Protobuf library implementations (protobuf vs. betterproto).

See also: in-toto/attestation#291

cc @adityasaky @haydentherapper @kommendorkapten

[adityasaky]

cc @marcelamelara @TomHennen @pxp928 @joshuagl @mikhailswift

[kommendorkapten]

Is the idea to just have a single dependency to depend on for being able to unmarshal a work with a bundle?

I might be wrong here, haven't thought this through in detail, but a client would still need to perform two JSON unmarshal passes.

The DSSE envelope captuers the payload as a byte stream, which means that we can't rely on a single run of protojson unmarshal, as the final struct will contain a byte array, that has to be JSON parsed again to get the in-toto statement.

[woodruffw]

Is the idea to just have a single dependency to depend on for being able to unmarshal a work with a bundle?

That, plus flattening the subdependencies here: if a dependant includes both sigstore-protobuf-specs and in-toto-attestation in Python, then they'll end up with two different Protobuf runtimes (betterproto and protobuf, respectively). This arguably isn't a big deal at all but it set off my "ick" alarm 🙂

I might be wrong here, haven't thought this through in detail, but a client would still need to perform two JSON unmarshal passes.

Correct -- I believe the main value here is not in having the two unmarshal as part of the same "pass," but just in having the data models collected together.