Ambiguity between inputs and outputs in v1

[trishankatdatadog]

Today with Attestation v1, it’s impossible to objectively tease apart inputs from outputs in a standard, predicate-agnostic way. This is made worse by the fact that it is also unclear whether subjects are inputs and/or outputs.

As such, one unfortunate consequence is that querying attestations by ResourceDescriptors (RDs) can be tricky. Indexing attestations by RDs is straightforward enough¹, so that is not the problem. The problem is that if you don't know which RDs are inputs vs outputs, it is impossible to answer queries such as, "Give me all Build Provenance attestations with this git commit tree as its input."

Another use case where the distinction between inputs and outputs need to be clear is any implementation of ITE-10.

One workaround is for attestation users to hardcode this knowledge per predicate type, but I think it's safe to say that this is clearly inelegant and unscalable. We have few enough standardized predicate types right now that it’s not awful to communicate this knowledge out-of-band to attestation verifiers, but it doesn’t feel right long-term.

This need not be the case. With links as in the in-toto v1 spec, inputs and outputs were clearly and explicitly marked as materials and products respectively.

One obvious constraint to keep in mind is certainly backwards-compatibility: we can’t suddenly be changing the semantics of subjects. So what are some good options going forward?

Footnotes

1. You just need to index all the RDs in the subjects as well as the others you find by recursively walking through individual predicates. ↩

[adityasaky]

I don't think the attestation spec should take a stance on the notion of inputs and outputs. As it stands, the attestation framework says "here's how you communicate a bunch of supply chain related properties about some artifact", where the properties are in the predicate and the artifact is identified in the subject. It just so happens that sometimes (e.g., in build provenance) the attestation is about an artifact that is the product of some supply chain step. I'll also highlight that the attestation framework itself doesn't have a notion of "steps" (maybe I'm wrong?) and that's a concept introduced by a policy engine like an in-toto layout, so I'm not sure it's a good idea to make this an /attestation concern.

but I think it's safe to say that this is clearly inelegant and unscalable.

I do agree (even though I wrote that!), it's definitely inelegant. But I think it may be okay pragmatically, as we don't expect to have to categorize every predicate type, but only those where the subject is the product. Otherwise, the subject is considered to be a material. This is captured in ITE-10 with informational and transformational predicates. Overwhelmingly, we have predicate types that are informational, where the subject is a material. Essentially, we can think of the step (in the layout) as being dedicated to capturing some information by passing in an artifact (e.g., take this input artifact and produce a vuln scan). On the other hand, transformational predicate types are rare; apart from v1 links, I think we only have SLSA provenance? I'm not sure any others have been suggested.

[trishankatdatadog]

@adityasaky I'm also tempted to agree with you. One layer where we can solve this in in-toto v2 spec policies: there, a policy author can explicitly specify which fields within a statement¹ are inputs vs outputs. With reusable policies, the hardcoding problem is largely ameliorated.

However, it still feels like something is wrong. Shouldn't the attestation producers themselves explicitly say what are inputs vs outputs? Yes, policy authors may override them if they so wish, but it seems strange that you can't easily look at an attestation by itself, and say what's what.

Footnotes

1. Yes, I meant statement not predicate because the author needs to be able to select subjects as well. ↩

[matglas]

This is also an interesting case that plays out in the implementation of Witness and Archivista. The subject name in the RD is following a schema to specify the type of RD. For example:

https://witness.dev/attestations/product/v0.1/file:dist/test.txt

https://witness.dev/attestations/git/v0.1/committeremail:foo@example.com

https://witness.dev/attestations/git/v0.1/parenthash:795aeb181626f3a0db8fa71e783cb012177e0c01

https://witness.dev/attestations/git/v0.1/commithash:9ff55704ca367c67646d78eb2cafaaac66858741

In case of Witness this is definitely not just the name of product. But also a reference to some of the material. Or just informational.

Archivista after indexing allows you to query attestations based on subject prefix too. Its a powerful way in that sense to index those relationships between attestations.

The name property in the RD spec does not specify a 'prefix' but leaves the identifier up to the producer. So that might be a more defined way of doing it. It could be something that is explicitly embraced by the spec.

[colek42]

I'd like to keep the definition of the subjects part of the attestor schema. Subjects are how we find related events, the attestation schema creator is in the best position to determine which event identifiers which make sense for their use use.