[deathanatos]

Which, unless I'm missing something, undercuts the entire article? The private key, in the generated keypair, is the thing that you can then never commit to your VCS.

When you "register" the public key with whatever the relying party is, you're also likely going to bind it to some form of identity, so you can't leak this private key to others, either. (And I'm curious, of course, how the relying party comes to trust the public key. That call would seem to require its own form of auth, though we can punt that same as it would be punted for an API key you might download.)

[kennywinker]

Sorry, are you expecting some way to authenticate without any secrets?

Could you describe how that would work? If two people have the same info, how on earth do you tell which is which?

The post is talking about simplifying things by eliminating all the back and forth. It’s not pretending to invent a secret-less auth system.

[deathanatos]

> Sorry, are you expecting some way to authenticate without any secrets?

I'm not. "It’s truly wild to me what some of y’all will tolerate." What, exactly, are we tolerating that is solved by asymmetric key pairs?

> The post is talking about simplifying things by eliminating all the back and forth. It’s not pretending to invent a secret-less auth system.

Well, then, I'm lost. What back & forth was eliminated?

In one system, we download an API key. In this system, we upload a public key. In both, we have a transfer; the direction doesn't really matter. Someone has to generate some secret somewhere, and bind it to the identity, which is what I was saying above, and is apparently the wildness that I'm tolerating.

[actinium226]

Yes but when you have to do this 13 times, it gets really annoying to manage all those API keys. Especially if you need them in different processing contexts. If I could just have a single public/private key pair for my app it would simplify managing all the extra services I use.

[deathanatos]

Thank you! I suppose yes, that it would amortize a few steps. (But as I mention in another comment, that only amortizes the management of the secret portions, which is a small portion of the objected to "insanity".)

[kennywinker]

> Visit our website. Create an account. Verify your email. Create a project. Add your credit card. Go to settings. Create an API key. Add it to your password manager. Drop it in your .env file. Download our SDK. Import it. Pass your env var in.

This is the pitch. But it seems like you fixated on the next part of the paragraph where it talks about api keys in version control.

I’ll agree with you in as much as this isn’t a massive change - but i like the approach for being an incremental improvement - and for challenging the status quo

[deathanatos]

My point is you're still doing all that.

Let's say instead of downloading API keys, everyone on the Internet permits uploading a public key to represent a service. Now it's: Visit our website. Create an account. Verify your email. Create a project. Add your credit card. Go to settings. Upload an API pubkey. Download our SDK. Import it.

All of that seems unchanged by using a pubkey to represent programmatic access.

(And as a sibling comment more constructively notes, you might be able to combine pubkeys, so, "Add it to your password manager. Drop it in your .env file. […] Pass your env var in.", but potentially only once. So we can omit that part here, I suppose.)

[hinkley]

In theory, I as the service provider know when my key database has been compromised. In theory. In practice, I will never know if a customer has been compromised, however up to a point a compromised user box can forward tokens to an attacker. So pending on whether you ever rotat the private keys, it’s a matter of ho long an attacker can retreat to a server they own to continue the attack.

In a way this reminds me a bit of SRP, which was an attempt to handle login without the server ever having your password. Which makes me think this is something to be integrated with password managers.