Expose API to sign arbitrary data

[austinabell]

Is your feature request related to a problem? Please describe.
Currently, to prove that you have the private key that matches a certain public key/account, you need to perform an operation on-chain. This is unfortunate because you should be able to sign arbitrary data to allow for dApps to prove you have a private key.

Take the use case of liking an image on an NFT marketplace. In the case of OpenSea, you just need to sign some data they provide to prove you own an account before tallying a like. In the case on NEAR, I've seen on Paras that it generates a function call access key just to prove the account, which is unnecessary and costs NEAR to perform the on-chain action.

This is a pretty trivial pattern that enables things like signing in to dApps off-chain, signing data that will be verified within a function call (maybe you wanted to ensure an action was signed by multiple parties without requiring all to pay the gas fee to sign a multi-sig and send the cross-contract call), or signing a transaction

Describe the solution you'd like

• Expose a method to sign arbitrary data from wallets that have that functionality

Describe alternatives you've considered
(not really another option I can think of)

Acceptance criteria

• You can sign arbitrary data with wallets that support it using wallet selector

Additional context
Not needed for anything we are doing now, just pointing out for future benefit and enabling developers to build cool things

[janewang]

This is already addressed in this PR. #391

[austinabell]

re-opening just to track this functionality. It definitely is not addressed in #391

[exalate-issue-sync]

Trentin Bergeron commented:

Solved by NEP → near/NEPs#413

[austinabell]

nope, that proposal does not solve this issue. Even if that proposal did, this issue tracks the implementation within wallet-selector

[antonio-ivanovski]

The current state of the NEP-413 doesn't tackle signing of arbitrary data. Current proposal is to sign application defined domain and nonce. Previous state of the proposal had property message that indeed could be used to sign arbitrary data.

@austinabell maybe you can comment on NEP-413 and show your support for extending the method to be able to sign arbitrary data. I am also for having that option to sign application defined data, will post feedback soon on that PR.

[austinabell]

The current state of the NEP-413 doesn't tackle signing of arbitrary data. Current proposal is to sign application defined domain and nonce. Previous state of the proposal had property message that indeed could be used to sign arbitrary data.

@austinabell maybe you can comment on NEP-413 and show your support for extending the method to be able to sign arbitrary data. I am also for having that option to sign application defined data, will post feedback soon on that PR.

I likely won't. I haven't dug deep enough to share a helpful opinion, and my low-confidence stance on this is that this seems like an unhelpful standard, as the format of data to be signed to verify an account should probably be specific to the application. Doesn't feel like a "one size fits all" approach is helpful in the long-term as you'd need this standard and also a more general one to handle cases like this issue, and that feels redundant.

Putting things like nonce and a domain string also seems like very specific use cases that do not generally apply, and for cases where more custom data is needed, applications would be forced to jam it into those fields, which feels janky.

[kujtimprenkuSQA]

Based on previous meetings/discussions with Daryl it was mentioned that this feature can be risky because users could sign real transactions instead of a simple message by signing arbitrary data.

The signMessage covers most of the use cases which is supported since this PR was merged #779