So clients are responsible for monitoring for leaks [1] and revoking affected keys themselves. What a disastrous architecture: centralized trust in potentially (provably... [1, 2]) negligent IdPs, yet substantial, distributed burden on each client to "do the right thing". That's going to go wrong.

Also, abusing OIDC: if this takes off, the hack will be ossified as effectively part of the standard, blocking its further development and adjustment, as to not break OpenPubKey.

1: https://www.wiz.io/blog/storm-0558-compromised-microsoft-key...

2: https://infosec.exchange/@briankrebs/110820474957163710

I haven't read too much about it yet, but some standing points of confusion I have with OpenPubKey:

1. OpenPubKey states that it uses the OIDC `nonce` claim as its public key stuffing mechanism, but I'm not aware of many (any?) popular OIDC IdPs that allow the user to control the nonce in such a way (for misuse resistance reasons). The closest thing that I'm aware of is some IdPs' ability to configure a custom `aud` claim, but this typically comes with substantial restrictions (such as a preset allowlist of audiences, or significant length limits).

2. OpenPubKey appears to wave away the problem of key rotation on OIDC IdPs, which is actually a pretty serious one: Google or Microsoft could decide tomorrow to arbitrarily change their rotation periods, which would impact the reliability of any system that relies on OPK signatures. Sigstore essentially dodges this problem by introducing a trusted CA and transparency log; I think OPK could similarly dodge it by introducing a key transparency scheme for keys observed from public IdPs. But doing so would involve running trusted infrastructure, in turn diminishing the value proposition vs. Sigstore.

(I also agree with the privacy concerns: JWTs really aren't meant to be used in this way, and treating them as a disclosable token has potential privacy and security implications that need to be evaluated. Sigstore has similar privacy problems because of how it embeds OIDC claims, but it doesn't leak the JWTs themselves.)

As far as I can tell, you're relying on Google, or Microsoft, etc to verify your identity. Lose your relationship with them, and you lose control of everything. You have to remain in their good graces, or lose your identity for a diverse set of transactions where those big players would otherwise have no sway.

Would much rather have a truly decentralized identity where you can change providers without losing continuity of your identity. Where your identity provider has to keep you happy, or you transparently move your identity to a new provider.

This seems very poorly thought through. Everything from abusing the nonce as a data channel (and re-using a predictable value in a field that is short for Number used Once), to rejection of transparency for an inherently public value, misunderstanding the threat models here, and putting the responsibility for revocation on to the client (one of the most complicated things to do correctly in a potentially already compromised environment...).

I think this one needs to go back to the drawing board.

Why does the Linux Foundation sign up projects like this with what appears to be so little duediligence

Given the many fair criticisms around here, what are some better alternatives?

Aren't we all trusting Fulcio and the other Sigstore infra in the same way? This reads like a belittling cope to me

> Would much rather have a truly decentralized identity where you can change providers without losing continuity of your identity. Where your identity provider has to keep you happy, or you transparently move your identity to a new provider.

This sounds like my dreams. Is there anything that exist now that does this?

For Azure, could you use a 1:1 mapping of Managed Identities and use Federated Credentials? (OIDC).

We need a few popular OIDC providers that will allow you to bring your own email address. That way you can use a custom domain if desired, and achieve the portability you're talking about.

I really wanted KeyBase to be an open identity source.

I had a daydream about bob@bobhome being hired at alicecorp. Instead of a new ID bob@alicecorp being created, bob@bobhome is invited to the project-devs@alicecorp. Once a member, that user ID is automatically granted access to jira/git/artifactory/AWS/etc etc

Your ID becomes part of your resume, with a record of who bob@bobhome has worked for, with crypto signed endorsements from team leads etc

I struggling to understand the concept of a decentralized identity. You are basically exposing the concept of identity to partitioning problems, at that point. Right?

That is, I don't disagree with the idea that the system we have now ties you to a company. But indirection and decentralization only works to a point. As an example, how do you manage disputes of your identity? Assume whatever system you have can be spoofed successfully somehow. What is the procedure to clarify the factually intended identity of someone?

Another layer of indirection often solves things in software engineering. You need a key store that allows use control via multiple identity sources so a backup path can add remove or update allowed sources. If google locks a particular account, drop it as an allowed source, add a different one.

This of course expands the attack surface - indirection comes at a cost.