Sign/verify message implementation/plugin
aaroncox opened this issue · comments
Not entirely sure where this fits, but we should have a method somewhere that you can trigger to signing request to a user to have them prove their identity. It could even just be an identity proof request. It should have something unique that the developer could specify though, e.g.
session.signMessage('Hello! 12345')
It would return a signature which could validate that specific account proved that request.
This in the backend could template an identity request transaction and issue it to the wallet plugin for signing. An associated verifyMessage()
could also be added to simplify verifying that the signature returned was valid.
This is already possible today just by manually assembling the transaction and having it signed, but often developers don't know how to do this and have troubles implementing it themselves. One common path we can all share through Wharf sessions would cut down on developers having to solve this themselves.
Hello there,
can I please ask you to explain to us how to do this manually without these methods?
Thanks
Hello @aaroncox, first of all, thanks for your work on the Kit!
We are developing a game on WAX blockchain and need, as you mentioned, an identity proof request or a method for a user to have them prove their identity.
Could you please help me understand what you mean by "This is already possible today just by manually assembling the transaction and having it signed"?
I think a manual process could be a great temporary solution for us, so I wanted to ask you if you can cast some light on it!
Thanks 😎
Sorry for the delayed response, my GitHub notifications are a bit out of control.
Yeah I think we can come up with some example code of how to manually do this. I'll set a reminder to take a look.
Alright, I wrote a unit test and put it in a branch that actually walks through the code to serve as an example.
Lines 497 to 539 in 686537c
This wasn't as easy as I assumed it would be and requires some manual steps. What's happening here is we're creating a new transaction that's a type of "identity", which isn't valid to broadcast to the chain but is still capable of being signed by most (hopefully all) wallets.
It's then being passed to the transact
method and telling the Session Kit not to broadcast it, since we just want the signature back.
Then it's walking through loading the account from the chain and comparing its authorities against the signature the wallet returned, as well as making sure it's a transaction that isn't expired.
This is the basis of what Anchor does on every login, and what a future wallet plugin could do to prove an account logging in is who they say they are.
I hope this helps!