[feature][BYOB] Allow TRW to generate predicate values

[ianlewis]

For some ecosystems we will need to give the TRW the ability the affect the structure of the created SLSA predicate.
This is blocking SLSA v1.0 support for the Node.js builder (#2499)

This is how it works currently:

1. The setup-generic actions creates a SLSA token in the context of the TRW
2. The delegator workflow calls the verify-token action and this creates a SLSA predicate based on the token. it also returns a verified version of the SLSA token
3. The generate-attestations action combines
   1. the predicate type (derived by the delegator workflow from the SLSA version set on the verified token)
   2. SLSA predicate created by verify-token
   3. subjects based on the layout returned by the Tool Callback Action (TCA)
4. The sign-attestations actions takes the attestations returned by generate-attestations and signs each using sigstore.

Some potential solutions:

1. TRWs can hook the generate-attestations step with their own implementation to alter the predicate created by verify-token before signing.
   • TRWs need to know how to generate the right layout from the generate-attestations step.
2. A new optional step (update-attestation) is added between verify-token and generate-attestations that allows TRWs modify the predicate before signing. It takes the predicate from verify-token and outputs a new predicate.
   • Fairly straightforward for TRWs to implement.
   • Requires that the predicate generated by verify-token to be somewhat stable.
3. verify-token doesn't generate a predicate but just outputs a verified SLSA token. A separate step is added to generate the predicate (generate-predicate) and TRWs can hook this action to generate their own predicate/buildType.
   • Fairly straightforward for TRWs to implement.
   • Requires that the verified SLSA token returned by verify-token to be somewhat stable.

[ianlewis]

I'm kind of partial to 3 since that seems like the cleanest design and we can manage compatibility/stability of the token with the token version. Though I realize it would add some overhead to changes in the SLSA token that forces us to bump the version (and maybe do a full major version bump for the whole project) if the SLSA token version changes.

[ramonpetgrave64]

Since it's only the npm ecosystem that needs the customization, I think I prefer option 2. It seems like it would need the least amount of potentially disruptive changes.

[ianlewis]

Since it's only the npm ecosystem that needs the customization, I think I prefer option 2. It seems like it would need the least amount of potentially disruptive changes.

Yeah, It's probably the least disruptive initially, but exposes the predicate to TRWs so making changes to the predicate could potentially break TRWs if they hook update-attestations since they might get it in a format they don't expect.