If some fields cannot be verified because they are not present in the cert, I'm tempted to say we should remove them from the provenance that --print-provenance prints. This requires some more discussions.
pros: only trust what can be verified
cons: someone how verifies their own package know that they have not altered with the content and may want to trust it anyway. Arguably they should be using a different builder if they want this level of guarantees

/cc @ianlewis @asraa

If some fields cannot be verified because they are not present in the cert, I'm tempted to say we should remove them from the provenance that --print-provenance prints.

I agree but, even better, we should ask npm to remove them from the provenance they generate. We can create an issue on their repo to have them removed if we find any. We discussed this earlier and agreed in principle with the GitHub folks on this.

Good idea. Please link the issue once you have created one on their repo

I linked to here from the issue in their repo. Anyone who has access should see it above.

Example of claims and change in parsing sigstore/fulcio#754 (comment)

Done in #572. Closing

reopening, since (n *Npm) verifiedProvenanceBytes() is not yet implemented.