Ramon Petgrave

I was on vacation for the past month, but I'll be taking another look at this PR again next week.

@aliahmed58 Yes, please feel free!

@AaronAtDuo Thanks for the reply. Alright. In the mean time, you could introduce an optional switch, like `use_proxy_env_variable`.

I think I mostly agree with what's there now: 1. This part should be removed from the intro "... by evaluating the artifact and a bundle of attestations against some...

@joshuagl I meant to say that `verifiedLevels` should be optional. Thanks for checking. @jeffvaughan-google As far as slsa-verifier's ability to verify policy, it can only be as far as matching...

@TomHennen For verification, yes. And that's the current implementation in the [pending](https://github.com/slsa-framework/slsa-verifier/pull/777/files#diff-ec799f1a02a9799f96a78f9f1c1c4ac74b3e6bcfac6b8dc1ad5646661dca9b23R31-R44) VSA support in slsa-verifier. But I believe the user should still have the field in lieu for situations...

> I totally agree having SLSA_BUILD_L0 won't inspire too much trust for users who see the VSA. But I think that is exactly working as intended -- it basically conveys...

I would definitely entertain it. Personally, I wouldn't tie the SLSA ladder to VSAs in that way, but I think the decision is up to a committee.

For the SLSA-track definitions, I think it appropriate to keep the N -> N-1 implication, but other tracks should be left open for more flexibility when implemented in a verifier...

Since the VSAs have a section for `inputAttestations`, I don't think it particularly needs to be a jsonl. As for slsa-verifier, we have a [draft](https://github.com/slsa-framework/slsa-verifier/pull/777/files#diff-3f17c2e62c00d3062cc3c7baf9addd0442803925705c86fa48f54a0105176ff6R1) implementation of verifying VSAs: it's...