The keypair is bound to a public identity via OIDC. That’s where the authenticity comes from; modulo a breach in GitHub’s IdP, you can be confident that the keypair corresponds to a signing action performed by the GitHub identity (either username or repository).
> The keypair is bound to a public identity via OIDC
It is not "bound" to anything cryptographically. Sigstore checks that you own the OIDC account, and if yes, it signs your public key and puts it in the log. Why not just sign your software's hash and put it in the log, "binding" it as you say?
This is true, but only because a cryptographic binding to the OIDC JWT would be meaningless. Fulcio could conceivably hash the JWT and add it as another certificate extension, but I don't see why it would (since nobody is expected to "burn" the JWT by publishing it after expiry).
> Why not just sign your software's hash and put it in the log, "binding" it as you say?
That's exactly what it's doing. Is the objection you have solely to the fact that it can be done with short-lived keys?
