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 continui…
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…
OpenPubKey and Sigstore
11–20 of 29 posts
Re: OpenPubKey and Sigstore
#12Earlier quoted context omitted.
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…
I wanted things like that from Keybase too. What happened to them?
Re: OpenPubKey and Sigstore
#13I 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`…
> 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 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…
Re: OpenPubKey and Sigstore
#14As 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 continui…
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…
Re: OpenPubKey and Sigstore
#15I 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`…
It doesn’t have to be a trusted infrastructure, just a trusted package (Google-OIDC-keys) that can be updated or keys published to an existing Key Server and cross signed by OpenPubKey.
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 :-)
Re: OpenPubKey and Sigstore
#16Earlier quoted context omitted.
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…
I wanted things like that from Keybase too. What happened to them?
They added a wallet with Stellar Lumens when that should have been entirely separate. Git repo hosting that should have been left to Github/Gitlab. etc etc.
My opinion is that they should have focused on integration with 3rd parties like github. Plus working on tech debt and UX issues. Created lots of docs on integrating KeyBase with your internal tooling, stuff like that.
Re: OpenPubKey and Sigstore
#17I 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`…
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.
Re: OpenPubKey and Sigstore
#18As 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 continui…
This of course expands the attack surface - indirection comes at a cost.
Re: OpenPubKey and Sigstore
#19I 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`…
Stuffing the nonce is the kind of "clever" shit that always comes back to bite you in the ass. 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…
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.
Re: OpenPubKey and Sigstore
#20Earlier quoted context omitted.
I wanted things like that from Keybase too. What happened to them?
Their leadership didn't seem to know what to do and chased a few passing fads for new features, and didn't address the tech debt they had to improve the UX of their tool. They added a wallet with Stellar Lumens when that should have been entirely separate. Git repo hosting that should have been left to Github/Gitlab. etc etc. My opinion is that they should have focused on integration with 3rd parties like github. Plu…