Skip to content

Latest commit

 

History

History
81 lines (68 loc) · 5.07 KB

3ip-5.md

File metadata and controls

81 lines (68 loc) · 5.07 KB
3ip title author discussions-to status created
5
Address Linking
oed@3box.io
Draft
2019-05-09

Simple Summary

Address linking is the process that describes how to link an ethereum address to a 3Box identifier. This 3IP describes how to do this for contract wallets and Externally Owned Accounts (EOA).

Abstract

Currently 3Box supports linking EOAs. This is done by signing a message containing the DID of the user with their EOA. This signed message serves as a proof that the users EOA is linked to their 3Box account. With Contract wallets it's not possible to use the same mechanism because a contract has no private key. Instead we use EIP 1271 which allows a contract to approve of some external signature. This 3IP describes how and where such a EIP 1271 proof should be stored to link a contract wallet to a 3Box account. It also describes how to update the current EOA links.

Motivation

Many wallet projects in the ethereum ecosystem are moving to contract based wallets which provide more security and flexibility to end users. In order for 3Box to be used with all types of ethereum accounts there needs to be a way to link a contract wallet to a 3Box account. The current linking procedure also lacks a timestamp, which makes it impossible to determine which proof is the latest one if there is a conflict.

Specification

Currently links are stored under the key ethereum_proof in a users public store. From now on we will refer to these proofs as version 0. The new version 1 of link proofs has these common properties:

{
  version: 1,
  type: <the type>
  message: <the message that is being signed (should contain the users DID, and the timestamp)>,
  timestamp: <the unix time when the message is signed>,
  signature: <hex encoded signature>
}

The message should look like this:

Create a new 3Box profile

-
Your unique profile ID is <did>
Timestamp: <timestamp>

The message should be signed with personal_sign. It is crucial that the message contains both the users DID as well as the current timestamp, in order to ensure the verifiability of the linking.

EOA proofs

A proof for an EOA simply follows the specification above and has the type 'ethereum-eoa'

Contract proofs

ERC 1271 defines a method isValidSignature which takes two arguments _data and _signature, both of which are of the type bytes. We can represent these arguments as string. This proof would thus have the form:

{
  version: 1,
  type: 'erc1271'
  chainId: <the ID of the EVM based chain>,
  address: <the hex address of the contract>,
  message: <the message that is being signed (should contain the users DID, and the timestamp)>,
  timestamp: <the unix time when the message is signed>,
  signature: <hex encoded _signature>
}

The format of the _signature would depend on the contract wallet implementation, but it's always verifiable by calling isValidSignature on the contract.

Storing the proof

Version 1 of the link proofs should be stored as an IPFS object the hash of which is then stored in the root-store. The entry in the root-store is formated as follows:

{
  type: 'address-link',
  data: <CID>
}

This allows us to store links to multiple addresses on different chains etc.

Linking procedure

From a UX perspective the linking procedure should be simple. 3Box would simply request a signature of message from the contract wallet software. The resulting signature would be stored under signature.

Rationale

The specification above solves a few different problems. We can now store multiple links to different EOAs and contract wallets since the proofs are now stored in the root-store. We added a version property to the proof object to easily distinguish between different proof formats. Contract wallets, as opposed to EOAs, usually only live on one blockchain. Therefore we introduced the chainId property which specifies which EVM compliant chain the contract lives on. This means that in theory 3Box would support linking to any EVM based chain. However support for each chain would need to be individually implemented in 3Box clients. Version 0 of the proofs didn't need to include the address that is being linked. This is because from the signature it is possible to derive the address. For contract wallets this is not true, so the address property is now needed. The timestamp is added as a measure to ensure that the user can change which DID the ethereum address points to, because it can be used as a way to decide the latest link in case there are multiple.

Backwards Compatibility

Currently the version 0 proofs are stored under the ethereum_proof key in the public store. This proof is verified when the Box.getVerifiedAccounts function is called. This function is called with a profile object that is returned from the getProfile rest API. We can add the link proofs to this call when needed.

Implementation

No implementation is yet available for this 3IP.

Copyright

Copyright and related rights waived via CC0.