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...
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.)
Doesn't the nonce the client provides have to be passed through unmodified[0] for the authorization server to be compliant?
> If present in the Authentication Request, Authorization Servers MUST include a nonce Claim in the ID Token with the Claim Value being the nonce value sent in the Authentication Request.
[0]: https://openid.net/specs/openid-connect-core-1_0.html#IDToke...
Just like with HTTPS, we should rethink the centralized trust model and instead condition users to verifying and manually approving trust for entities. Work on better UX for investigating and scrutinizing trust claims. Stop shipping CAs, let the users validate their own stuff. The current status quo is not protecting users the way it claims to, it's just making naive, dumb marks for folks to socially engineer.
I don’t agree with your evaluation of centralized PKIs: to a first approximation, the CA PKI model is the only PKI model that has demonstrated any amount of longevity and misuse resistance. This doesn’t mean it’s good or historically flawless, but that on an empirical level it’s done better than everything else that’s been tried (including expecting end users to establish independent trust relationships).
Expecting people with no technical background to safely bootstrap trust for the services that facilitate their personal information is not only unrealistic on a practical level, but (cynically) unworkable on an expectation level: users will not want their lives made worse because technologists dig their heels into solutions that they consider superior.
Even with a key transparency scheme, a pre-existing key server would effectively be a piece of trusted infrastructure due to “split-world” attacks. The remediation there would be to allow OPK clients to gossip among each other about transparency log state, but now we’re back into the realm of very complicated designs :-)
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).
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
The parent talks about decentralized (or perhaps federated) solutions which I can understand but I don't get why everyone would want to put all their eggs in the KeyBase basket?
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?
This of course expands the attack surface - indirection comes at a cost.
I think this one needs to go back to the drawing board.
