> Yeah, that problem still remains, of course. But you could align the package update cadence to the rotation cadence. If in practice this happens to be a anything beyond a few weeks, I'd say that's not a bad tradeoff.
Whose rotation cadence? GitHub's is going to be different from Azure's, Google's, etc. JWKS itself doesn't include any expiry or rotation metadata[1] (example here[2]), so it's not clear how OKP (or any scheme) can establish a cadence policy around multiple IdPs without getting their explicit cooperation (which they'll be unlikely to offer, given that it artificially constrains their ability to revoke potentially compromised key material in service of an unintended use case).
> You go from trusting a central signing server, to somewhat auditable (and probably reproducible) package publishing infrastructure.
Again sorry if I'm misunderstanding what you mean, but Sigstore doesn't involve trusting a central signing server. The primary trust members in Sigstore are (1) a free CA, and (2) transparency services for certificates and signatures. Signatures themselves look very similar to what OKP does (ephemeral, client-side keys) but with the OIDC impermanence problem solved by a managed, transparent PKI. This is ugly and complicated, but it is sound; I don't think the same can be said for OKP's current design.
That's all to say that I'm happy if they succeed, and I'll also be happy to be wrong here. But I'm going to be a little miffed if they go through the process of building a "smaller" Sigstore, only to realize that (1) OIDC IdPs aren't going to encourage weird uses of their tokens, and (2) they need an online transparency service anyways :-)
Whose rotation cadence? GitHub's is going to be different from Azure's, Google's, etc. JWKS itself doesn't include any expiry or rotation metadata[1] (example here[2]), so it's not clear how OKP (or any scheme) can establish a cadence policy around multiple IdPs without getting their explicit cooperation (which they'll be unlikely to offer, given that it artificially constrains their ability to revoke potentially compromised key material in service of an unintended use case).
> You go from trusting a central signing server, to somewhat auditable (and probably reproducible) package publishing infrastructure.
Again sorry if I'm misunderstanding what you mean, but Sigstore doesn't involve trusting a central signing server. The primary trust members in Sigstore are (1) a free CA, and (2) transparency services for certificates and signatures. Signatures themselves look very similar to what OKP does (ephemeral, client-side keys) but with the OIDC impermanence problem solved by a managed, transparent PKI. This is ugly and complicated, but it is sound; I don't think the same can be said for OKP's current design.
That's all to say that I'm happy if they succeed, and I'll also be happy to be wrong here. But I'm going to be a little miffed if they go through the process of building a "smaller" Sigstore, only to realize that (1) OIDC IdPs aren't going to encourage weird uses of their tokens, and (2) they need an online transparency service anyways :-)
[1]: https://auth0.com/docs/secure/tokens/json-web-tokens/json-we...
[2]: https://token.actions.githubusercontent.com/.well-known/jwks