search

opencap / protocol

OpenCAP: Making Crypto Convenient
33 stars 6 forks source link

Nano aliases breaking specs #2

Closed FrilledShark closed 6 years ago

FrilledShark commented 6 years ago

commit https://github.com/lane-c-wagner/ccap/commit/f02024cf6194a133e6d6e6a8804143e29b36e7a6

The POST /ccap/address endpoint will only CREATE addresses in regards to Nano, it will not UPDATE.

I believe this will cause more trouble, as it will be noticeably harder for the user to move between wallets. If the person loses their wallet, they will also lose access to the alias.

Nano should not break the required endpoints, just for security.

wagslane commented 6 years ago

If a server wants to add UPDATE functionality it must be through some other method, and should use further security options like 2FA.

This part specifies that is will still be possible to update, it can just be done in a more secure fashion via a webportal with 2FA. Do you think it requires more than that?

FrilledShark commented 6 years ago

Do you think it requires more than that?

It seems like an oversight that it is possible to create an alias from the wallet, but it is not possible to update the alias when one is changing wallets. If 2FA should be used for updating, it should be used for all currencies and the 2FA implementation should be included in the protocol.

This could be done by requiring an endpoint for update, which requires a JWT token along with whatever second factor security is decided.

If this is not included in the spec, I do not believe Nano should be treated differently to other cryptocurrencies and it should be possible to update with POST /ccap/address. The specs should not be broken just because the current way to use Nano addresses is by reuse.

wagslane commented 6 years ago

That makes sense. Want to submit a PR to blank out the nano file?

shilch commented 6 years ago

I don't think that create, update and delete operations should be components of this protocol. It should rather focus on doing one thing very well, that is responding to alias requests with the corresponding address.
Somebody might want to use CCAP for their service but use a different way of managing the data, e.g. a cryptobank does not want the CUD operations offered by the protocol. I believe that this should be a separate protocol that the reference implementation server uses.