Add match_payload method to Envelope

[PradyumnaKrishna]

Description of the changes being introduced by the pull request:

match_payload method checks for the payoad if deserializes into
the provided class type. This method is essential in order to
add DSSE compatibility in in_toto.

This method will provide interface similar to current in_toto's
Metablock property _type. Which is used at various places in
in_toto project to identify type of the payload.

Please verify and check that the pull request fulfils the following requirements:

• The code follows the Code Style Guidelines
• Tests have been added for the bug fix or new feature
• Docs have been added for the bug fix or new feature

[lukpueh]

Why not look at self.payload_type to know which class to deserialize into?

[PradyumnaKrishna]

ITE-5 suggests that in-toto will have metadata with payload_type=application/vnd.in-toto+json and in-toto has payloads that can further classified into two types, Link and Layout.

Also, This method is common with in-toto Metablock which has only two types either link or layout.

[lukpueh]

Oh, right, thanks for the reminder. Still, it seems unnecessary to fully deserialize the payload twice, given that we know exactly what we expect.

[PradyumnaKrishna]

Oh, right, thanks for the reminder. Still, it seems unnecessary to fully deserialize the payload twice, given that we know exactly what we expect.

I am open to other solution to this problem. There is only one case where payload was deserialized twice in a row.

[lukpueh]

There is only one case where payload was deserialized twice in a row.

We still deserialize the full object to extract a single field, and then throw away the object even if we still need it.

I am open to other solution to this problem.

I'd like to use a similar pattern as in Metablock.from_dict. It also doesn't need to be passed a Layout or Link class in order to deserialize the passed data into its signed field, because it knows that the passed data must have a _type field, whose value must be either link or layout, so it can during deserialization just call Link.from_dict or Layout.from_dict.

And the exact same thing applies to an Envelope when in the in-toto context. The problem is that Envelope does not only exist in the in-toto context. So we need to find a way to register an in-toto specific payload parsing for a generic Envelope class. I have to think about how to best do this.

[lukpueh]

match_payload will not be upstreamed, see corresponding note in secure-systems-lab#370 (comment). Thanks for the efforts, @PradyumnaKrishna, this work was helpful for path finding!