[bug] Standard discrepancy: `buildInvocationId` versus `buildInvocationID`

[woodruffw]

My colleague @facutuesca observed this bug with the generator_generic_slsa3.yml action.

Describe the bug

In SLSA 0.1 and 0.2, buildInvocationId is spelled with a lowercase "d":

Similarly, it's spelled with a lowercase "d" in 1.0, where it's renamed to invocationId:

However, [email protected] appears to generate 0.2 provenance objects with buildInvocationID (capital 'D') instead.

An example of this can be seen in sigstore-python's release artifacts, e.g. our intoto provenance for v3.2.0:

https://github.com/sigstore/sigstore-python/releases/download/v3.2.0/provenance-sigstore-v3.2.0.intoto.jsonl

when the payload is decoded, we can see that it's a v0.2 Provenance with the mis-spelled metadata.buildInvocationID. Excerpted below:

"metadata": {
    "buildInvocationID": "10457864437-1",
    "completeness": {
        "parameters": true,
        "environment": false,
        "materials": false
    },
    "reproducible": false
}

I've also attached the full SLSA provenance as a file to this report: slsa.json

To Reproduce

To reproduce, use the latest version of generator_generic_slsa3.yml (2.0.0) in a workflow, like so:

  generate-provenance:
    needs: [build]
    name: Generate build provenance
    permissions:
      actions: read # To read the workflow path.
      id-token: write # To sign the provenance.
      contents: write # To add assets to a release.
    # Currently this action needs to be referred by tag. More details at:
    # https://github.com/slsa-framework/slsa-github-generator#verification-of-provenance
    uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]
    with:
      provenance-name: provenance-sigstore-${{ github.event.release.tag_name }}.intoto.jsonl
      base64-subjects: "${{ needs.build.outputs.hashes }}"
      upload-assets: true

(Not all of these options may be necessary; that's exactly how they appear in sigstore-python's CI, which observed this behavior.)

Expected behavior

I expected buildInvocationID to be spelled as buildInvocationId, for consistency with the SLSA provenance spec.

Additional context

None!