Wallet Binding
A one-time interaction to map your game player profile to your blockchain wallet.
Last updated
Was this helpful?
A one-time interaction to map your game player profile to your blockchain wallet.
Last updated
Was this helpful?
The player must have an , and a browser wallet extension (like ).
The game must host a and be registered with Craftware as a member to interact with the ecosystem.
The game must for the users to access.
The player must have a valid and activated game account with the game of choice.
After logging into the Craftware webapp, the user must press the + button in the side bar to add the game.
The user will enter the user ID for the game.
The wallet extension will prompt the user to approve a signature for the authentication request. The message to be signed will have information similar to the following:
Then, the player will be redirected to the login screen hosted on the game craftware endpoint of choice (by default <game endpoint>/api/login)
The user enters the credentials.
If the credentials are correct, the game now have the two bits of information it needs to securly verify that:
The webapp user is indeed the player because he demonstrated knowledge of the credentials or any authentication system
The webapp user owns the wallet they claim to own
The webapp user intended to bind this wallet to this game account because of the presence of the USER_ID in the signed message.
By the end of this, the user is brought back to the craftware webapp, while the game backend stores the signature, wallet address, and user ID in a table.
After this is completed, the Craftware SDK will keep track and map the user ID to this wallet for any future request.
Why is this secure? The answer relies in the signatures we mention above. A cryptographic signature is used by receiver of a message to insure that the author of the message could not be anyone other than the designated author they are communicating with.
To sign a message, the user runs computations on the message using their private key. Then, a verifier reverses the computations with the public key of the author. If the message was authored by a third party, when the verifier tries to reverse the computations, they will not get a result that aligns with the original message.
In our scheme, the player needs to verify two attributes of their identity:
Ownership of the private key of the wallet
Ownership of the game account
The latter is a matter of memorizing credentials, a rather traditional outlook on ownership. But to ensure the former, we must be able to sign any message or "challenge" some party requires to make sure we are authentic.
Nonetheless, the game manager cannot add any wallet to your account because they need to store the signature of the authentication request which they can never possess without your approval.
Not at all. In fact, the game manager and the player must both consent on unbinding the wallet from any blockchain endpoint of the system (like the ). But when it comes to the in-game mapping, the game manager can easily remove it.