Add a ResourceDescriptor predicate
marcelamelara opened this issue · comments
There are some use cases that need to communicate that a document or artifact exists and don't necessarily need to reference it from within some pre-existing in-toto statement (per #117 (comment)).
The ResourceDescriptor is designed for describing and pointing to other artifacts within an in-toto attestation, so it can be used to implement this attestation predicate. The main usage of this predicate type is to have a signature over the referenced document or artifact without having to sign the entire document directly.
Tasks:
- Write a resource descriptor attestation predicate definition (following the new predicate guidelines)
- Update the spec/predicates/README.md
- Write a protobuf definition for the predicate
- Add a test for this predicate to the test suite for at least one of the supported language bindings (Go, Python, Java, Rust)
I think this may overlap with #124. I am a bit worried about fragmentation though.
I think this may overlap with #124. I am a bit worried about fragmentation though.
Can you elaborate what you mean? I'm not immediately seeing the overlap.
So the other thread is about a "source" attestation recording artifact sources. Each source is then going to be a resource descriptor. As it's proposed, I think we're essentially talking there about the link predicate. But if we do want to carve out a subset predicate that describes sources, cutting other information like environment and so on out, I think we end up with 1+ resource descriptors. This is for just the one RD instance. The question is how different are all of these predicate options and should be we collect them as one predicate type? If we have a single RD type and a source predicate type, I imagine either would be usable in single-source scenarios.
Ah, thanks for clarifying. I guess there are two schemas in that issue, and you're right that the schema proposed by @trishankatdatadog and this RD predicate do have significant overlap. I was looking at the schema that @colek42 had posted, and that one contains a lot more info than just a list of RDs. I tend to agree that if source and RD predicates will mostly be the same, we should develop a single predicate that can meet the needs of both use cases.
I should also add that the motivation for this RD predicate was attesting to an SBOM without including the full SBOM in the attestation, but I can also imagine using a SCAI predicate for this where the attribute field is "HAS_SBOM" and the evidence field contains an RD to the SBOM. So, I don't think it's immediately clear if the super generic RD predicate adds much in this use case.
Please let me know how we decide to record source trees (my biggest use case).
P.S. The link to the ResourceDescriptor seems to be broken: this seems to be the correct one.
There's also https://github.com/testifysec/witness/blob/main/docs/attestors/material.md to consider. cc @colek42 @mikhailswift
Would something like this work?
{
"_type": "https://in-toto.io/Statement/v1",
"subject": [
{
"name": "foo.jar",
"digest": {"sha256": "fe4fe40ac7250263c5dbe1cf3138912f3f416140aa248637a60d65fe22c47da4"}
}
],
// Predicate:
"predicateType": "https://in-toto.io/attestation/reference/v0.1",
"predicate": {
"referrer": {
"id": "http://example.com/sbom_generator"
},
"references": [ // Array of ResourceDescriptors
{
"digest": "abc123",
"downloadLocation": "http://example.com/sbom_storage/abc123.spdx.json",
"mediaType": ...
...
}
]
}
...
} Would it make any sense to rename this issue to 'Add a reference predicate' with the goal of "allowing an attestor to point to out-of-band data" or something like that?
(At the very least that's what we're looking for, not sure if that conflicts with any other goals)