[WIP] Feature/api login - requesting feedback

[xeroc]

(paging @Dimfred)

This feature enables to "login" to the RPC endpoint by using a signed transaction containing a transfer operation.

The reason is that we would like to offer a way to provide a premium endpoint to users iff
the fulfill certain conditions, such as:

• required_lifetime_member
• required_registrar
• required_referrer
• and potentially more going forward

This is work in progress, but feedback is very welcome.

Please, could someone page Crypto Clara as I had an extended discussion about this feature with her in Shanghai

[ryanRfox]

@manikey123 please have a look into this PR. You should find it relevant to prior conversations with @xeroc

[abitmore]

I didn't get why it need a transfer. I think, to prevent replay attack, the login should use a hand-shaking model:

• server->client: my memo key is XYZ
• server->client: what's your username?
• client->server: my name is abc
• server get abc's memo key which is UVW
• server generates a string STR, encrypt it using sign_memo with UVW and XYZ's private key
• server->client: the encrypted_memo is ENCRYPTED_STR, what does it contain?
• client->server: STR
• server->client: validated

[manikey123]

@XeroX Extended information is captured under #1882.
Look forward towards your feedback.

[sschiessl-bcp]

We are also working to add the login possibility of having a withdrawal permission set to the node operators account. Use case implicit.

[xeroc]

I didn't get why it need a transfer. I think, to prevent replay attack, the login should use a hand-shaking model

The motivation here was to reduce number of round trips for communication.
A transfer (or any other operation that comes with a fee_payer() - all) could be used but we limited the code for transfer_operation. Open for suggestions to make this more modular.

Also, you made a great comment on the other issue. Let me quote:

About implementation, the PR added a login_signed API. Alternatively, due to the optional parameter support (bitshares/bitshares-fc#126), we can extend current login API, keep the status that currently the login API is the entry point of the authentication process. For example, extend login API from login(user,pass_string) to login(user,auth_string,optional_auth_method). There are reasons for this. For example, currently we support Basic HTTP Authentication for clients, it's best if the new authentication method has similar support.

I think this makes sense. We could (later) add other authentication schemes to the login-api (such as Bearer) and even maybe connect an sqlite database to the backend to make changes to authentications easier (just thinking).

Would it make sense (if it even works) to extract that code into a plugin and add sqlite support for that plugin specifically? The plugin would either extend or overwrite the login api and allow authentication via sqlite schema, or other means - like SASL as you proposed in the other thread?

[pmconrad]

We are also working to add the login possibility of having a withdrawal permission set to the node operators account.

This sounds like payment channels would be a better solution.

[sschiessl-bcp]

Where do you see the downside of using recurring payments, and where do you see benefits in using a payment channel?

[pmconrad]

A payment channel is better for a series of off-chain micropayments, e. g. pay-per-minute or maybe even pay-per-API-call.
Recurring payments requires an on-chain transaction for each payment and is thus more suitable for a daily/weekly/monthly fixed fee.

[xeroc]

Recurring payments requires an on-chain transaction for each payment and is thus more suitable for a daily/weekly/monthly fixed fee.

We were thinking a monthly subscription fee.