feat: Add Support for verifyOwner

[kujtimprenkuSQA]

Description

• Added support for verifyOwner to the API of all wallet integrations.
  • On MyNearWallet this feature is only supported on testnet
  • On Sender this feature works only when Sender is unlocked.
  • Other wallets throw a "Method not supported" error.

Note

The work for this PR initially started here: #320, there were some build issues that I was unable to solve quickly, I copied everything from there and addressed requested changes here in separate commits.

Closes #318.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings

Type of change. This type of change is the main reason for the PR.

• FIX - a PR of this type patches a bug.
• FEATURE - a PR of this type introduces a new feature.
• BUILD - a PR of this type introduces build changes.
• CI - a PR of this type introduces CI changes.
• DOCS - a PR of this type introduces DOCS improvement.
• STYLE - a PR of this type introduces style changes.
• REFACTOR - a PR of this type introduces refactoring.
• PERFORMANCE - a PR of this type introduces performance changes.
• TEST - a PR of this type adds more tests.
• CHORE - a PR introduces other changes than the specified above.

Breaking changes

• BREAKING CHANGE - SPECIFY: _______
• NO BREAKING CHANGE - this PR doesn't contain any breaking changes and it's backwards compatible

[MaximusHaximus]

@AmmarHumackicSQA @kujtimprenkuSQA I pushed a commit that made some tweaks to the signatures of the verifyOwner functions and types. In particular, message needed to be always required, no defaults should be passed in to avoid someone accidentally signing an 'empty' or default payload due to a coding error or other issue, and signerId and publicKey must be provided by the wallet who is signing the request (should not be provided as an argument). I think we're ready to land this unless you have any concerns about the final commit I added 👍

[lostpebble]

Hi @kujtimprenkuSQA @MaximusHaximus ,

Is there some place where wallet developers can be notified of new APIs like this? We are only seeing this now (Meteor Wallet), and some integrators are asking us why we haven't implemented this. It would be great if there was some way to communicate these upcoming API changes that require updates from our side, as we'd really like to be ready for whatever direction the ecosystem is heading.

[AmmarHumackicSQA]

Hi @lostpebble , right now you can track the releases, and also check the Developer tools updates (the latest one).

Maybe @janewang could give you more info about how upcoming changes like this will be communicated going forward. Thanks!

[janewang]

@MaximusHaximus Could we please raise a NEP on this for the community, thanks! @lostpebble We will notify in the Wallet Vision Group as well as recordings of Wallet Standard Group.

[lostpebble]

Hi @lostpebble , right now you can track the releases, and also check the Developer tools updates (the latest one).

Maybe @janewang could give you more info about how upcoming changes like this will be communicated going forward. Thanks!

Thanks, appreciate the links, but those updates are already too late- as those are releases of the Wallet Selector that we would need to have the functionality already built in from our side to be a part of.

@MaximusHaximus Could we please raise a NEP on this for the community, thanks! @lostpebble We will notify in the Wallet Vision Group as well as recordings of Wallet Standard Group.

Appreciate that. Understandably a lot of this is all new so it will take time for the processes to come into play. We are apart of the Wallet Vision Group, so will be keeping an eye out there. A project board of future functionality or something of the like might also go a long way.

[Cameron-Banyan]

As a working group member, I lean toward approving this proposal (NEP413) because it will

• Speed up the performance of dApps by signing messages off-chain and creating flexible interactions between wallets and dApps
• Enable authentication of any type of data through String “message”
• Enable authentication without increasing storage costs of adding additional access keys
• Increase room for web2 authentications like JWT tokens