Wallet Binding

A one-time interaction to map your game player profile to your blockchain wallet.

Prerequisites

• The player must have an Ethereum wallet, and a browser wallet extension (like Metamask).

• The game must host a Craftware SDK and be registered with Craftware as a member to interact with the ecosystem.

• The game must set up the wallet authentication endpoint for the users to access.

• The player must have a valid and activated game account with the game of choice.

Steps

1. After logging into the Craftware webapp, the user must press the + button in the side bar to add the game.

2. The user will enter the user ID for the game.

3. 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:

ETHEREUM SIGNED MESSAGE:
GAME_ENDPOINT:     111.222.333.444:5300
USER_ID:           'user-1'
WALLET:            0X123...
TIMESTAMP:         01/01/2023T12:00
NONCE:             123
...

3. Then, the player will be redirected to the login screen hosted on the game craftware endpoint of choice (by default <game endpoint>/api/login)

4. 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:

1. The webapp user is indeed the player because he demonstrated knowledge of the credentials or any authentication system

2. The webapp user owns the wallet they claim to own

3. 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.

More about signatures

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.

Will my account be bound forever to this wallet?

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 Port). But when it comes to the in-game mapping, the game manager can easily remove it.

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.