Specifies if the overall rating of the dependency is positive or negative.

Maybe there's a reason for it, but in crev there's more results. IIRC "harmful", "terrible, but probably just accidentally", neutral, "good enough", "very good", kind of things.

Does in-toto do it for more things already? Just tries to aggregate all "attestation/signed-like things" to let someone enforce some policies somewhere on them?

The original in-toto v1.0 wasn't semantically aware of "this is a code review step" and "this is a test step"

Maybe there's a reason for it, but in crev there's more results. IIRC "harmful", "terrible, but probably just accidentally", neutral, "good enough", "very good", kind of things.

I was trying to enumerate as enums the different possible values, happy to add these as well.

Okay I think I better understand the question now, thanks for clarifying.

in-toto doesn't tell you specific policies. It provides the mechanisms to define the policies you want to enforce and a standardized framework for the claims you want to enforce the policy on. These claims are what's captured as attestations.

Taking a step back, if the only policy you want to apply is crev dependency reviews, you don't need in-toto. in-toto shines when you have more than dependency reviews and you want to consider a variety of claims.An attestation can be of several types. It can record various aspects of your build process (https://github.com/in-toto/attestation/blob/main/spec/predicates/provenance.md), capture the results of test runs (https://github.com/in-toto/attestation/blob/main/spec/predicates/test-result.md), or as I'm now trying, it can capture a crev review of some dependency.

Who attests what in this situation?

The what depends on the type of attestation (and transitively the type of operation being performed). The who depends on the specific instance. Your CI system may be creating the build-specific attestation, the crev attestation may be signed by humans you work with who reviewed the attestation.

So what in-toto allows is unifying all of these different types of attestations for a software supply chain. Your policy would specify not just the set of users who you trust for crev attestations but also which keys can sign your build attestations, etc. in-toto defines a format for multi-step policies called a layout. The layout lets you enumerate the steps in your supply chain and the attestations / signers expected for each. Other policy efforts / engines also support verifying certain attestation types (eg:

Okay I think I better understand the question now, thanks for clarifying.

in-toto doesn't tell you specific policies. It provides the mechanisms to define the policies you want to enforce and a standardized framework for the claims you want to enforce the policy on. These claims are what's captured as attestations.

Taking a step back, if the only policy you want to apply is crev dependency reviews, you don't need in-toto. in-toto shines when you have more than dependency reviews and you want to consider a variety of claims. An attestation can be of several types. It can record various aspects of your build process (https://github.com/in-toto/attestation/blob/main/spec/predicates/provenance.md), capture the results of test runs (https://github.com/in-toto/attestation/blob/main/spec/predicates/test-result.md), or as I'm now trying, it can capture a crev review of some dependency.

Who attests what in this situation?

The what depends on the type of attestation (and transitively the type of operation being performed). The who depends on the specific instance. Your CI system may be creating the build-specific attestation, the crev attestation may be signed by humans you work with who reviewed the attestation.

So what in-toto allows is unifying all of these different types of attestations for a software supply chain. Your policy would specify not just the set of users who you trust for crev attestations but also which keys can sign your build attestations, etc. in-toto defines a format for multi-step policies called a layout. The layout lets you enumerate the steps in your supply chain and the attestations / signers expected for each. Other policy efforts / engines also support verifying certain attestation types (eg:

Okay I think I better understand the question now, thanks for clarifying.

in-toto doesn't tell you specific policies. It provides the mechanisms to define the policies you want to enforce and a standardized framework for the claims you want to enforce the policy on. These claims are what's captured as attestations.

Taking a step back, if the only policy you want to apply is crev dependency reviews, you don't need in-toto. in-toto shines when you have more than dependency reviews and you want to consider a variety of claims. An attestation can be of several types. It can record various aspects of your build process (https://github.com/in-toto/attestation/blob/main/spec/predicates/provenance.md), capture the results of test runs (https://github.com/in-toto/attestation/blob/main/spec/predicates/test-result.md), or as I'm now trying, it can capture a crev review of some dependency.

Who attests what in this situation?

The what depends on the type of attestation (and transitively the type of operation being performed). The who depends on the specific instance. Your CI system may be creating the build-specific attestation, the crev attestation may be signed by humans you work with who reviewed the attestation.

So what in-toto allows is unifying all of these different types of attestations for a software supply chain. Your policy would specify not just the set of users who you trust for crev attestations but also which keys can sign your build attestations, etc. in-toto defines a format for multi-step policies called a layout. The layout lets you enumerate the steps in your supply chain and the attestations / signers expected for each. Other policy efforts / engines also support verifying certain attestation types (eg: https://github.com/sigstore/policy-controller, https://docs.seedwing.io/seedwing/index.html, https://github.com/enterprise-contract).

So there is a tool somewhere into which you feed:

• a policy document, expressed in some machine-readable format containing predicates
• attestations, which are some cryptographic things generated by components and signed by the component's key
• possibly (I assume) some artifact

and then the tool checks whether the artifact is valid as per your policy?