In SLSA v1 provenance, why does a verifier care more about externalParameters than internalParameters?

## The distinction the spec draws A SLSA v1 build is modelled as a function. The `buildType` names the function, `externalParameters` are the arguments the caller supplied, and `internalParameters` are the arguments the build platform supplied on its own. Together they are meant to fully determine what the build did. That modelling is what makes the split security-relevant. **`externalParameters` is the attack surface of the request.** Every value in it was chosen by whoever triggered the build — which, in a repository that accepts contributions, includes people with far less privilege than the release owner. **`internalParameters` is inside the trust boundary you already accepted** when you decided the `builder.id` was one you trust. You cannot meaningfully audit a platform's internal choices from the outside; you either trust the platform or you do not. ## An accurate field is not a passing check Consider a library build for a package feed where the branch to build arrives as an external parameter. A contributor with only push rights to their own branch triggers a build of `refs/heads/fix-nuget-pack`. The provenance produced is completely honest: it records that exact ref, and `builder.id` is the same trusted platform that produces the real releases. Nothing is forged. And yet the artifact must not be published as a release. The provenance is *accurate* and *worthless as a trust signal on its own*, because accuracy is not authorization. This is the single most common failure in real verification setups: teams wire up signature checking, see it pass, and conclude the artifact is good — having never compared the recorded inputs against what they expected those inputs to be. Verification is a comparison, not a parse. The expectation might be "repository is exactly this one, ref matches `refs/tags/v*`, config path is the one in the release process". ## Why unrecognized fields must fail Suppose your check is "repository and ref match expectations". That check is only sound if repository and ref, together with the `buildType`, determine the build. If the platform also accepts a parameter you have never heard of — an extra script to run, an alternate registry, an override of the entry point — then an attacker who cannot change the ref can still change the artifact through the field you are not looking at. So the discipline is to enumerate the parameters you accept and reject anything else. A new field appearing is usually not an attack; it is more often the platform shipping a feature. But it means your checked fields no longer pin the result, and the correct response is to fail, read the `buildType` documentation, and then extend the expectation deliberately. ## What emptiness means on the internal side `internalParameters` is optional and is frequently omitted entirely. An absent or empty `internalParameters` does **not** mean the platform applied no settings of its own — every build runs on some image with some toolchain. It means the platform chose not to state them. Whatever assurance you have about those values comes from trusting the platform, not from reading the field. Treating an empty object as a positive claim is a design error in a verification rule. ## The reviewer's reading order A useful habit when handed a provenance document: read `buildType` first so you know what the parameter names mean, then read `externalParameters` and ask of each field, *could someone I do not fully trust have chosen this value, and does my expectation constrain it?* Anything you cannot answer is a gap, whether the field is malicious or merely undocumented. Only then look at `builder.id`, and treat `internalParameters` as background — informative for debugging a build difference, not load-bearing for the accept-or-reject decision.