Forem: Gui Bibeau

Signing data with MetaMask

Gui Bibeau — Wed, 01 Feb 2023 01:38:11 +0000

Signing is an act that carries a big responsibility. You sign things like contracts, cheques, and legal documents. If you create an application for signing things, chances are that any mediumly tech-savvy person will be able to use it. But in the blockchain world, what does signing mean?

This question you should take lightly, especially when it comes to your users and presenting them with transactions, messages, and data to be signed. Establishing trust with your users is critical and will be the tutorial's focus. In the following few paragraphs, we will put our dual UX and blockchain hats on and sign a message with Metamask.

Signing a message

First, Let's demystify what signing means in the world of crypto. In the physical world, your identity is proven with an identification card or, in some contexts, a written signature. This validity is typically ensured because they are verified by a trusted entity such as a notary or a governmental organization.

Trust in a blockchain comes from nodes in the network agreeing on the validity of transactions between two parties. It is to these transactions that the term signing is most often applied. Signing a transaction on Ethereum means using a private key to authorize a transfer of Ether or interaction with a smart contract on the Ethereum blockchain. It proves the ownership of the Ethereum address associated with the private key and allows the transaction to be added to the blockchain.

But signing goes beyond this. It can also be used for other purposes. For example, signing a message can be used to proven to come from a specific address. This is useful for many use cases like authentication, authorizations, and even exchanges of information. MetaMask, a fully featured wallet, can be used to sign messages and data. We will see popular methods and even explore cutting-edge Dapp architectures built on top of it.

Signing a message with MetaMask

MetaMask always does its best to make sure standards are followed and that the user is in control of their information. The methods we'll discuss today are the ones we recommend to be implemented by Dapps. We'll discuss signing simple messages and signing typed data. The respective methods are eth_sign and eth_signTypedData and can be submitted through the window.ethereum.request JSON-RPC API.

Signing a simple message

In some cases, if you want to have users approve or sign a message and don't intend to use the message on a chain, you can use the personnal_sign method, defined in EIP-191. This method is also relatively simple to implement in your code:

// the message to be signed
const message = 'I like tacos and I approved of this message'
const from = '0x...' //* pass in the user's address here
window.ethereum.request({
      method: 'personal_sign',
      params: [mesasge, from],
})

The advantage of this method is by far its simplicity and readability for users; they will be prompted by the MetaMask extension and will have a similar user experience to signing a document or a simple contract. A well-known use case is "Sign In With Ethereum," abbreviated as SIWE, defined in EIP-4361, where users approve connecting to an application and this signature is validated before a session is created in the server.

Even if we see that 95% of users typically will approve a request for signature, one of the limits with personnal_sign is around using it inside smart contracts. While we can use the string value of the message inside a smart contract, a string is expensive to parse into more complicated data formats.

This is where eth_signTypedData_v4 comes in!

Signing typed data.

JSON or JavaScript Object Notation is a famous data format used in web applications. However, JSON support is limited in the world of smart contracts, where performance means increasing user costs. Luckily EIP-712 is a proposed standard that allows users to sign data that smart contracts can understand.

Its usage is fairly similar to personal_sign, instead you simply have to pass a request of type eth_signTypedData_v4 and specify the Solidity types and details about the smart contract verifying the message:

// The message will be parsed in 
const message = JSON.stringify({
    domain: {
      chainId,
      name: "Example App",
      verifyingContract: "0xCcCCccccCCCCcCCCCCCcCcCccCcCCCcCcccccccC",
      version: "1",
    },
    // should implement the top level type
    message: {
      prompt: "Are Doritos tacos any good?",
      answer: `YES THEY ARE!`,
    },
    // Top level type
    primaryType: 'QA',
    types: {
      EIP712Domain: [
        { name: 'name', type: 'string' },
        { name: 'version', type: 'string' },
        { name: 'chainId', type: 'uint256' },
        { name: 'verifyingContract', type: 'address' },
      ],
     // defining the top level type here. types refer to Solidity types    
      QA: [
        { name: 'prompt', type: 'string' },
        { name: 'answer', type: 'string' },
      ],
    },
  });
const from = '0x...' 
window.ethereum.request({ 
    method: 'eth_signTypedData_v4',
     params: [from, message]
})

The lift for front-end developers is a bit higher, but the most significant advantage of this signing method is that it opens up a world of possibilities for smart contracts! It also helps that we witness upwards of 97% approval of these messages in MetaMask! Now let's explore what kind of robust architectures you can unlock with eth_signTypedData_v4

A New Generation of Dapps!

In a world where malicious actors abound, moving approvals on-chain has a considerable amount of benefits:

auditable code
ability to create authorization layers that live on-chain directly without requiring user approvals on each action.

The last benefit is one I want to explore more. Since typed data is easy to understand for smart contracts, we can use it to hold long-lived user approvals on-chain. Take this example, a smart-contract implementing a paycheck every two weeks. The steps would happen as follows:

An employer deposits a 10,000$ amount in a smart contract for the next ten weeks of paychecks
The employer signs an authorization using eth_signTypedData_v4 that approves 1000$ per week for an employee
The employee, on his own, will claim the salary each week
The smart contract will verify if the authorization is valid and allow the disbursement
The employer can revoke his authorization at any time if they terminate the contract

This kind of scenario is the user experience you can implement if you integrate eth_signTypedData_v4. It would help if you worked towards a user interface that communicates what happens and educates users about your smart contract when implementing such an authorization layer.

Conclusion

We saw a lot of advanced concepts today, but understanding signatures is a great way to build sustainable and user-friendly Dapps. After the initial learning curve of communicating between wallet, smart contracts, and users, we are empowered to make better, more sustainable apps.

Digital Identity and SIWE

Gui Bibeau — Wed, 25 Jan 2023 15:41:07 +0000

Introduction

Everywhere you go, you have a digital identity. This identity is the collection of data that represents your activity online. It is challenging to stay truly anonymous online in this era of social media.

If you are present on a social like Facebook or TikTok, you probably have seen disturbing advertisements after visiting a website seemingly unrelated to those platforms. These advertisements are possible because websites implement a variety of cross-site tracking technologies, identifying you across the Internet.

An Overview of Digital Identity In Present-Day Earth, 2023

"Digital Identity" refers to a person or entity's identity existing in the digital world. It encompasses the information, attributes, and characteristics associated with a person or entity. You can use identity for various purposes, such as authentication, authorization, and access control. In tech jargon, a digital identity is an online or networked identity adopted or claimed in cyberspace by an individual, organization, or electronic device.

Digital identities can be centralized or decentralized, depending on how they are created and managed. A single entity, such as a government or a corporation, controls centralized digital identities, while the individual or entity they represent controls decentralized digital identities.

A user's digital identity can have simple attributes like:

Name
Address
Username and password
Date of birth

Or complex attributes such as:

Online search activities, like electronic transactions
Social security number
Medical history
Purchasing history or behavior
Biometric data
Digital certificates

In multiple industries, we see use cases for digital identities, such as finance, healthcare, and e-commerce, and uses, such as online banking, secure messaging, and personal data management.

A widespread issue plaguing digital identity on the Internet is Identity theft, so the subject of digital identity authentication and validation measures are critical to ensuring Web and network infrastructure security in the public and private sectors. Admittedly, there has been a lot of talk about authentication. With the advent of blockchain technology, we are seeing the use of digital identities in decentralized applications and platforms built on the blockchain. Recently, the Web3 community has become fragmented around multiple wallets and authentication methods.

Web3 developers are digital self-sovereignty advocates, so let's look at what the concept of digital identity means in web3.

Identity in Web3 and Its Implementation

Identity in web3 refers to self-sovereign identity, allowing individuals to own and control their digital identity. Centralized entities such as governments and corporations control Identities in traditional web2 systems. In web3, individuals can create and manage their digital identities using blockchain technology.

There are several methods of implementing identity in web3, with popular ones such as Decentralized Identity Protocols(DID) and Smart Contract-based Identity Protocols, and others like Self-sovereign identity (SSI) systems, Public Key Infrastructure (PKI) based systems and Biometric-based Identity as well.

Decentralized Identity (DID): These protocols allow users to create and manage their own digital identities on the blockchain. DIDs are unique identifiers registered on a blockchain and can be used to authenticate and authorize individuals on the web3 network. Then be used to link different identities, such as social media and email, to a single blockchain-based identity.
Smart Contract-based Identity: These protocols use smart contracts to store and manage user identities on the blockchain. Users can create and manage their identities using smart contracts and authenticate and authorize users on web3 applications.
Self-sovereign identity (SSI): Systems based on the same principles of DIDs, allowing the user to hold and control their identity data without needing a centralized entity.
Public Key Infrastructure (PKI): PKI-based systems use digital certificates and public and private keys to authenticate and authorize users on web3 applications. Similar to traditional web2 systems.
Biometric-based Identity: With biometrics, we can create and authenticate digital identities in web3 using fingerprints and facial and voice recognition. With web3, individuals can exert control over their data and identity, allowing them to share it selectively and, at any time, revoke that access. We can also connect multiple identities to prove our identity as a user.

It's pertinent to remember that the implementation of some of these methods is in its early stages, and research and development are ongoing to improve user experience and adoption.

Blockchain developers have long talked about developing "decentralized" identity standards to save users from the dangers of "Big Login," and this birthed: Sign-in With Ethereum proposal, a digital identity standard that was built by the community with direct support from the Ethereum Foundation and ENS, with Spruce Systems tapped to lead the charge.

How the Sign-In With Ethereum Proposal Affects Digital Identity

The Sign In With Ethereum(SIWE) proposal was a proposed standard for using Ethereum to authenticate and authorize users on web3 applications. It aimed to provide a standard way for users to sign in to web3 applications using their Ethereum address and private key, similar to how users currently sign in to web2 applications using their email and password. It uses a private key to authenticate a user's identity on the Ethereum blockchain. A private key is a unique string of characters associated with an Ethereum address and is used to sign digital transactions. When a user signs in with Ethereum, they provide a digital signature using their private key to prove that they are the owner of the Ethereum address. This proposal allows them to access their account and perform actions such as sending and receiving Ether, interacting with smart contracts, and more.

With SIWE, users would create an Ethereum address and private key specifically for signing in to web3 applications. When they want to sign in to a web3 application, they will use their private key to sign a message proving they are the owner of the Ethereum address. The web3 application would then verify the signature and authenticate the user.

SIWE affects digital identity by:

Allowing individuals to use their Ethereum address as a way to authenticate on web3 applications
Eliminating the need for complex passwords and usernames
Allowing users to use their Ethereum address as a decentralized identity across different web3 applications
Enabling web3 applications to authenticate and authorize users without the need for centralized identity providers
- such as social media login or email and password, which could lead to more privacy and security for the user

The proposal aims to standardize how you authenticate with a digital identity. The following are the steps:

A server creates a Nonce (unique number) for each user that will sign-in
A user requests to connect a site with their wallet
The user is presented with a unique message containing the Nonce and information about the website
The user signs in with their wallet
The user is then authenticated or approved
Access to data for this user is given to the website

MetaMask is a popular tool and a browser extension that allows users to interact with the Ethereum blockchain and can be used to implement digital identity and SIWE. With it, we can create and manage Ethereum addresses and use them as digital identities on Web3 platforms and dApps.

For your users, the experience is simple, but multiple steps are happening behind the scenes.

How to Implement Sign-In With Ethereum

As mentioned above, we will need to generate a unique number called a Nonce; since this should be done on a server, we will be working with Next.js, the most popular React framework for building server-side rendered applications.

We will be starting from a basic Next.js application created with create-next-app, and we will use the following
libraries:

@metamask/providers - A library for interacting containing TypeScript types for the MetaMask provider API
ethers - A library containing different utilities for interacting with the Ethereum blockchain
siwe - A library containing utilities for implementing Sign In With Ethereum
iron-session - A library for implementing session management in Next.js applications

N.B. The complete code is available here.

A Dance Between the Client and the Server

With these libraries, we can lay down the architecture for implementing SIWE. To connect users, we will want to implement the following:

Generate a Nonce inside getServerSideProps
Pass the Nonce to the client
Connect to a user's wallet
Make the user sign a message containing the Nonce
Verify the signature
Store the signature in a session

Generate a Nonce Inside `getServerSideProps`

Our first step is to generate a Nonce inside getServerSideProps of our login page, located on the pages/login.tsx.

Generating the Nonce inside getServerSideProps is crucial because execution happens on the server, and we can pass it to the client, which is faster than fetching it from an API route like in other implementations.

export const getServerSideProps = () => {
  const nonce = generateNonce();

  return {
    props: {
      nonce,
    },
  };
};

With this, we can now pass the Nonce to the client.

Passing Our Nonce to the Client

Next, we will pass the Nonce to the client. We do this by defining a default export for the login page, a React component, that will receive the Nonce as a prop.

type Props = { nonce: string }

export default function Login({ nonce }: Props) {
    // ...rest of the component

Connect to a users wallet and sign a message

Now we go to the core of our implementation, connecting to a user's wallet. We do this inside a connect function which gets called when the user clicks the connect button.

See the full function

Our function will work as follows:

Request the user to connect to their wallet with window.ethereum.request({ method: 'eth_requestAccounts' })
Grab the current network with window.ethereum.request({ method: 'eth_chainId' })
Create a message to sign

const siweInstance = new SiweMessage({
  // this will let the user validate the domain they are logging in to
  domain: window.location.host,
  // this will let the user validate the origin they are logging in to
  uri: window.location.origin,
  address: address,
  statement: 'I am logging in to the SIWE demo',
  version: '1',
  chainId: Number(chainId),
  nonce,
})

Sign the message with

window.ethereum.request({
  method: 'personal_sign',
  params: [message, address],
})

Post the signature to the server

const res = await fetch('/api/login', {
  method: 'POST',
  body: JSON.stringify({ message, signature, address }),
})
const data = await res.json()

Verify the signature

Then we can move to the server and verify the signature. This verification happens inside the api/login route, which gets called when the user clicks the connect button.

See the full API route

In this API route, we'll focus on the following steps:

Verify the signature
Ensure the signature is sent from the correct address
Store the signature in a session

With this done, you now have full access to the user's signature and can use it to authenticate the user on your web3 platform or dApp. The interesting part is that you now also have a session containing the user's address.

This address is helpful for prefetching data about the user; for example, you can use the address to fetch data related to the user's address, all while keeping the user's privacy intact.

If done well, digital identity in Web3 can provide a more secure and private way to handle user identities while providing a great user experience.

Conclusion

In conclusion, digital identity in Web3 is a critical topic that is gaining more and more attention as the decentralized Web continues to grow. Implementing digital identity in Web3 can be done using various methods, including DIDs, smart contract-based identity protocols, and Metamask and Next.js. By using these tools and techniques, individuals can take control of their digital identity and use it to authenticate and authorize themselves on web3 platforms and dApps.

For digital identity in Web3 to be successful, individuals, developers, and businesses need to continue to educate themselves on the benefits and best practices for implementing digital identity in a secure and decentralized manner. With the right tools and knowledge, digital identity in Web3 can provide a more secure and private way to handle user identities.

Forem: Gui Bibeau

Signing data with MetaMask

Signing a message

Signing a message with MetaMask

Signing a simple message

Signing typed data.

A New Generation of Dapps!

Conclusion

Digital Identity and SIWE

Introduction

An Overview of Digital Identity In Present-Day Earth, 2023

Identity in Web3 and Its Implementation

How the Sign-In With Ethereum Proposal Affects Digital Identity

How to Implement Sign-In With Ethereum

A Dance Between the Client and the Server

Generate a Nonce Inside getServerSideProps

Passing Our Nonce to the Client

Connect to a users wallet and sign a message

Verify the signature

Conclusion

Generate a Nonce Inside `getServerSideProps`