Add a simple public-key-based authenticator

[TheBlueMatt]

JWT-based authentication is currently largely the default due to
its integration in `ldk-node` indirectly via LNURL-auth. This is
great, but massively over-engineered (and requiring yet another
service devs have to set up and maintain) for just authenticating
to a storage service (and maybe an LSP).

Here we add a much simpler authentication scheme, based simply on
proof-of-knowledge of a private key. This allows for a simple VSS
install without requiring any additional services. It relies on
some higher-level authentication to limit new account registration,
but that can be accomplished through more traditional anti-DoS
systems like Apple DeviceCheck.

[ldk-reviews-bot]

👋 I see @valentinewallace was un-assigned.
If you'd like another reviewer assignment, please click here.

[tnull]

Here we add a much simpler authentication scheme, based simply on
proof-of-knowledge of a private key.

I'm a bit skeptical of this approach right now. Generally there is no harm in supporting different authentication schemes, but we so far failed to establish a single standard authentication mechanism.

For that reason I'm afraid that adding more different authentication schemes could result in an even more complicated/confusion support matrix for users.

Any thoughts on that? Wouldn't it be preferable to commit to one scheme for now to finally establish a standard? Could you expand on why you couldn't just use the existing JWT auth for your usecase?

[ldk-reviews-bot]

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[TheBlueMatt]

we so far failed to establish a single standard authentication mechanism

Isn't this mostly/almost entirely because we failed to ever actually offer any authentication mechanisms? The only auth mechanism currently implemented on the server-side (which was only recently added) is LNURL-Auth, which isn't even freestanding - it requires a second server somewhere that we don't provide. On the client side we allow for a "just give us the header" implementation to do fully-custom things, but that doens't help all that much either.

If we'd provided a standard way to do authentication from day one, I have to assume people would have used it.

Could you expand on why you couldn't just use the existing JWT auth for your usecase?

The authentication scheme here is totally different from what already exists - instead of having the wallet contact a server and ask for the server to sign off on the client accessing data for its user-id, this just allows the client to access its data by signing a message. This sidesteps having to implement a second server entirely, not to mention reduces complexity and dependencies.

[tnull]

Isn't this mostly/almost entirely because we failed to ever actually offer any authentication mechanisms?

Well, no, at the time there was some push-back to the idea of featuring a particular default/preferred authentication scheme, as some people were of the opinion that that should be completely left to the user as they would want to integrate with whatever authentication infrastructure they'd already have in place.

The only auth mechanism currently implemented on the server-side (which was only recently added) is LNURL-Auth

Also not quite accurate, as we have users that have been running their LNURL-auth implementation for quite some time. But yes, we only recently finally made progress to add support to vss-server itself.

it requires a second server somewhere that we don't provide

I was under the impression that we concluded to finally change that and provide a default implementation?

If we'd provided a standard way to do authentication from day one, I have to assume people would have used it.

Yeah, see above, I had always considered us not providing a default auth mechanism a failure on our end that unnecessarily risks protocol fragmentation. So fully agree we should close that gap.

The authentication scheme here is totally different from what already exists - instead of having the wallet contact a server and ask for the server to sign off on the client accessing data for its user-id,

Not sure I'm completely following, AFAICT the hand-rolled signature scheme is close to what the JWT token would already do?

this just allows the client to access its data by signing a message.

AFAICT we still don't couple store_id to any particular user ID though? So we'd currently only check that a user is authenticated, not what exactly it is authenticated for?

This sidesteps having to implement a second server entirely, not to mention reduces complexity and dependencies.

I had previously understood that the current idea is that we'd add issuance as part of the Rust codebase?