ERC: Proxy Account

[frozeman]

This proposal has moved to ERC-725 (source).

This issue exists as an archive only.

Original Text

eip: <to be assigned>
title: ERC-725 Smart Contract Based Account
author: Fabian Vogelsteller <fabian@lukso.network>, Tyler Yasaka (@tyleryasaka)
discussions-to: https://github.com/ethereum/EIPs/issues/725
status: Draft
type: Standards Track
category: ERC
requires: ERC165, ERC173, ERC1271 (optional)
created: 2017-10-02
updated: 2020-07-02

This is the new 725 v2 standard, that is radically different from ERC 725 v1. ERC 725 v1 is be moved to #734 as a new key manager standard.

Simple Summary

A standard interface for a smart contract based account with attachable key value store.

Abstract

The following describes standard functions for a unique smart contract based account that can be used by humans,
groups, organisations, objects and machines.

The standard is divided into two sub standards:

ERC725X:
Can execute arbitrary smart contracts using and deploy other smart contracts.

ERC725Y:
Can hold arbitrary data through a generic key/value store.

Motivation

Standardizing a minimal interface for a smart contract based account allows any interface to operate through these account types.
Smart contact based accounts following this standard have the following advantages:

• can hold any asset (native token, e.g. ERC20 like tokens)
• can execute any smart contract and deploy smart contracts
• have upgradeable security (through owner change, e.g. to a gnosis safe)
• are basic enough to work for for a long time
• are extensible though additional standardisation of the key/value data.
• can function as an owner/controller or proxy of other smart contracts

Specification

ERC725X

ERC165 identifier: 0x44c028fe

execute

Executes a call on any other smart contracts, transfers the blockchains native token, or deploys a new smart contract.
MUST only be called by the current owner of the contract.

function execute(uint256 operationType, address to, uint256 value, bytes data)

The operationType can execute the following operations:

• 0 for call
• 1 for delegatecall
• 2 for create2
• 3 for create

Others may be added in the future.

Triggers Event: ContractCreated if a contract was created

Events

ContractCreated

MUST be triggered when execute creates a new contract using the _operationType 1.

event ContractCreated(address indexed contractAddress)

ERC725Y

ERC165 identifier: 0x2bd57b73

getData

Returns the data at the specified key.

function getData(bytes32 key) external view returns(bytes value)

setData

Sets the data at a specific key. MUST only be called by the current owner of the contract.

Triggers Event: DataChanged

function setData(bytes32 _key, bytes memory _value) external

Events

DataChanged

MUST be triggered when setData was successfully called.

event DataChanged(bytes32 indexed key, bytes value)

Ownership

This contract is controlled by an owner. The owner can be a smart contract or an external account.
This standard requires ERC173 and should implement the functions:

• owner() view
• transferOwnership(address newOwner)
• and the Event event OwnershipTransferred(address indexed previousOwner, address indexed newOwner)

Data keys

Data keys, should be the keccak256 hash of a type name.
e.g. keccak256('ERCXXXMyNewKeyType') is 0x6935a24ea384927f250ee0b954ed498cd9203fc5d2bf95c735e52e6ca675e047

Multiple keys of the same type

If you require multiple keys of the same key type they MUST be defined as follows:

• The keytype name MUST have a [] add and then hashed
• The key hash MUST contain the number of all elements, and is required to be updated when a new key element is added.

For all other elements:

• The first 16 bytes are the first 16 bytes of the key hash
• The second 16 bytes is a uint128 of the number of the element
• Elements start at number 0

Example

This would looks as follows for ERCXXXMyNewKeyType[] (keccak256: 0x4f876465dbe22c8495f4e4f823d846957ddb8ce6006afe66ddc5bac4f0626767):

• element number: key: 0x4f876465dbe22c8495f4e4f823d846957ddb8ce6006afe66ddc5bac4f0626767, value: 0x0000000000000000000000000000000000000000000000000000000000000002 (2 elements)
• element 1: key: 0x4f876465dbe22c8495f4e4f823d8469500000000000000000000000000000000, value: 0x123... (element 0)
• element 2: key: 0x4f876465dbe22c8495f4e4f823d8469500000000000000000000000000000001, value: 0x321... (element 1)
  ...

Default key values

ERC725 key standards need to be defined within new standards, we suggest the following defaults:

Name	Description	Key	value
SupportedStandards	Allows to determine standards supported by this contract	0xeafec4d89fa9619884b6b89135626455000000000000000000000000xxxxxxxx, where xxxxxxxx is the 4 bytes identifier of the standard supported	Value can be defined by the standard, by default it should be the 4 bytes identifier e.g. 0x7a30e6fc
SupportedStandards > ERC725Account	Allows to determine standards supported by this contract	0xeafec4d89fa9619884b6b89135626455000000000000000000000000afdeb5d6, where afdeb5d6 is the 4 bytes part of the hash of keccak256('ERC725Account')	Value is the 4 bytes identifier 0xafdeb5d6

ERC725Account

An ERC725Account is an ERC725 smart contract based account for storing of assets and execution of other smart contracts.

• ERC173 to be controllable by an owner, that could be am external account, or smart contract
• ERC725X to interact with other smart contracts
• ERC725Y to attach data to the account for future extensibility
• COULD have ERC1271 to be able to verify signatures from owners.
• Should fire the event ValueReceived(address indexed sender, uint256 indexed value) if ETH is received.

A full implementation of an ERC725Account can be found found here.

Rationale

The purpose of an smart contract account is to allow an entity to exist as a first-class citizen with the ability to execute arbitrary contract calls.

Implementation

• Latest implementation

Solidity Interfaces

// SPDX-License-Identifier: CC0-1.0
pragma solidity >=0.5.0 <0.7.0;

//ERC165 identifier: `0x44c028fe`
interface IERC725X  /* is ERC165, ERC173 */ {
    event ContractCreated(address indexed contractAddress);
    event Executed(uint256 indexed operation, address indexed to, uint256 indexed  value, bytes data);

    function execute(uint256 operationType, address to, uint256 value, bytes memory data) external;
}

//ERC165 identifier: `0x2bd57b73`
interface IERC725Y /* is ERC165, ERC173 */ {
    event DataChanged(bytes32 indexed key, bytes value);

    function getData(bytes32 key) external view returns (bytes memory value);
    function setData(bytes32 key, bytes memory value) external;
}

interface IERC725 /* is IERC725X, IERC725Y */ {

}

interface IERC725Account /* is IERC725, IERC725Y, IERC1271 */ {
    event ValueReceived(address indexed sender, uint256 indexed value);
}

Flow chart

Additional References

• Slides of the ERC Identity presentation
• In-contract claim VS claim registry
• Identity related reports
• W3C Verifiable Claims Use Cases
• Decentralised Identity Foundation
• Sovrin Foundation Self Sovereign Identity

Copyright

Copyright and related rights waived via CC0.

[alexvandesande]

This is a very useful ERC. I would remove all the Must and Should comments regarding types of keys as it should really be left up to the implementation of the contract.

Some contract types might want to have the admin functions, like claim or addKey be made by some types of admin keys, some might want to make those available to different types of keys, some might want to make the process to addKeys to go through the same process as any execute call will go to. This actually doesn't add much complexity: if you want a contract like that, just make so that only the contract itself can call some functions, and then make functions like addKey be actually just a proxy that creates a proper request to execute them, via whatever mechanism execute needs to go.

---

function approve(uint256 _id) returns (bool success)

you should either add a second boolean parameter to say either you approve or not, or add a second function called reject

[frozeman]

I added the bool to the approve, just forgot that.

Concerning the flexibility of key addition/removals, i added:
"MUST only be done by keys of type 1, or the identity itself. If its the identity itself, the approval process will determine its approval."

Which includes either using key type 1, or the identity itself, e.g. then only the identity contract itself can call those function, and they always go through the approval process.

[alexvandesande]

It's just that I don't believe defining key types should be in the scope of this ERC. For some cases, like a democracy, the strings can represent different types of agents: voters, election officials, ID validators, those who can propose new stuff, etc. For a more hierarchical organization, type can be a number representing their rank: for some smaller is more important, for others, bigger is more important.

[frozeman]

The reason to add key types, is to prevent people from running around with keys, which can overtake their identity, but rather only use they action keys on a daily basis. Those wont have the ability to remove or change keys, which reduces the risk to loose your identity all together.

The other advantage is that it allows to define purposes to keys, which other entities or contracts can then use to derive the purpose of a user action on their system. E.g. if key type 23 means award collector, then a game interface knows which one to assign awards to.

[MicahZoltu]

I would like to see some details/arguments as to why this benefits from being a standard. In what ways do we gain interoperability benefits from having this standardized? What types of general purpose tooling are we expecting people to build that will need to work with unknown future implementations of this?

Looking over the methods, it seems like a large number of them would qualify as "implementation details" and are not relevant to creating an generic identity management standard. For example, how a particular identity provider does key management is not something that needs to work with many tools, it just needs to work with the identity provider's tool suite. Even some contract that supports 10 identity providers and wants to interface with them all presumably needs to trust those providers in advance, meaning they don't need to build their contract to support arbitrary future providers.

Given the current motivation section, I would recommend that this not be a standard and instead just be a contract/dApp that anyone can write and deploy. 😄

[alexvandesande]

@MicahZoltu I disagree there. If I'd like to be able to use an identity in Mist, it means that I want to create an account, allow that account do things on behalf of others. What I mostly need to be standardized is the addKey, execute and approve. We can use our own private contract, but I think it's nice to try to work together with others.

[frozeman]

This needs to be standardized so that other contracts can interact with real world identities, automatically check and verify them. It’s not mainly necessary for interfaces alone. Also this contract represents ONE identity. The addition of claims need to be standardized, so that other identities can issue claims about each other.

Verifying an identity would happen in the following ways:

• either The calling contract knows the claimtype (are not defined yet, but would be things like address, biometric data etc) and issuer it trusts. Then he simply needs to retrieve that claim and verify that it’s signature contains the address of the identity and the claim number. And checks that this signing address belongs to the issuers identity.
• or he will retrieve claim by type and then goes and checks the issuers identity claims. This can be done down as many ways as necessary to end up at an trusted claim.

But I assume over time known and trusted issuers will appear so only one check needs to be done.

I might write an extra document to explain all the ways of how one can interact with this contract. But I would like to keep that apart from the ERC itself to keep it easy to read.

[MicahZoltu]

In order for there to be value in a standard there needs to be interoperability concerns that are being addressed. We don't need a standard for prediction markets, or a standard for exchanges or a standard for gambling games unless there is a compelling argument as to how one of these things would be better if they were interoperable. There isn't significant value in making it so all gambling games have the same interface, since users will interact with each gambling game via a dApp custom built for that gambling game.

A good example of useful standardization is token contracts. There is value in standardizing tokens so that an application (e.g., Wallet, exchange, etc.) can interact with any token the user provides without needing to know about it in advance or write custom integrations for each token. However, there is little to no value in standardizing how tokens come into existence because there isn't a strong need for a general purpose UI for token management. Each token author can build a token management UI just for their token, end users won't be using this so it doesn't even need to have a familiar interface.

@alexvandesande You have indicated that you want addKey, execute and approve standardized. How would standardizing those add value to the ecosystem? What can you do with those things standardized across many implementations that you wouldn't be able to do if they were not standardized?

@frozeman It sounds like you have a grand vision in your head that isn't expressed clearly in this EIP or discussion. I would love to hear more about it.

As a dApp developer who wants to verify the identity of someone interacting with my contract, I need to go to an identity provider that I trust and and say, "account X claims to be UUID Y, please verify" (or similar) and they would then return true or false. This is certainly useful, but I do not see where in this process a standard adds value. Since I need a pre-existing trust relationship with the identity provider, my dApp won't be accepting any random identity provider that a user gives me. I must integrate my dApp with specific identity providers, and in almost all situations I can think of I will pick one (and only one).

To be really clear, I'm not arguing that Identity Providers are bad. I'm arguing that creating a "standard" (and going through the RFC process) for every useful contract someone can think of is bad. There may be value in this being standardized, but it is not immediately apparent to me and I want you to convince me that standardization adds value.

Edit: In case it isn't clear exactly what I'm looking for, I would like to see a problem statement that shows some problem that can't be solved without a standard. Right now this EIP is missing a problem statement.

[Arachnid]

Some upfront definitions would be good. What are keys? Are they cryptographic identities? Why not addresses? What is a claim for, and how does it work?

Interface definitions probably shouldn't contain Solidity-specific types (eg, mapping(foo=>bar) baz), but instead the interfaces they generate (eg, function baz(foo) returns(bar);). How it's implemented is an implementation detail for the contract.

I agree with @alexvandesande that principal types should be left up to the implementation. Role accounts are a good thing and should be encouraged, but there's no need for the spec to mandate what roles exist and what privileges they have.

@MicahZoltu I believe the purpose of standardising this is to allow multiple clients (eg, wallets) to interact with multiple implementations of identity providers (Eg, multisigs, etc). Without a standard, you have the current situation, where Mist has native UI for multisigs, but only for its own API, Parity has another, and so forth.

[frozeman]

@MicahZoltu i see this needs a lot more explanation. I kept the standard description concise to make it readable, but many of the concepts i introduce here are not apparent right from the start. I will address each of these points here in the discussion, but also keep in mind, as i wrote above; the ERC draft is not finished yet.
I will be giving a talk at the london meet up on the october 11th, where i will lay out my vision for that standard in more detail. This will be recorded and i will post the video here.

First of this is a standard for a self sovereign identity; This means the owner controls its identity and he allows claims about himself to be attached to his identity. There are no identity providers, but claim issuer (or certifiers). Those simply say: "I saw him in person, stored his biometric data, and attached a link on his identity". People who want to verify that they are dealing with a person, either in their contracts, or dapps, websites, etc. can then check on their identity - given they got a signed message from one of its keys - and look for a claim they trust.

But to answer you questions:

• Why i think this needs to be standardised:
  Standardising this allows other contracts in the future to auto verify users, and implement permission models right in their contract. Standardising also allows other identities, or claim issuers to add claims to an identity. The less important part is standardisation for UI interfaces; But also here we gain the ability to take your identity and make it useful and accessible in Mist, MetaMask, Browsers, Government UIs, border control, community tools and what not... Once an identity is created, it is meant to be used for a long time and over many platforms and UIs, otherwise it can't function as your identity over time.

Do i think all of the current proposed functions need to be standardised? No; i just wanted to give a more or less complete set of functions, which make clear how they interact together.

• What is an example use case
  Imagine the following: You want to interact with an smart contract of a bank to create an account. They need to make KYC on you. In the openAccount call from your identity, the bank contract can see this call is coming from an identity, so he will:
  -> look for claim type 1:biometric and 2:homeAddress and for a claim issuer they know they trust, like the German state for 1 and the Deutsche Post for 2. As they know their identity contract addresses, they simply do: keccak256(issuer address + claimTypeNumber) and get the index of the claim in YOUR identity.
  -> they retrieve the claim, check that the signed data matches keccak256(YOUR identity address + claimTypeNumber)
  -> Now they check that the key which this data was signed, is still hold by the issuers identity contract.
  -> They got their proof - without that they need to actually see the biometric data, nor the address, as they trust the issuer - and they can proceed in opening an account.

The whole example above, won't work automated and with unknown parties, if these processes and functions aren't standardised.

Another extension of this could be that you have to hop through multiple claim issuers, to reach one you trust, which in return makes you trust all the others, including the one you verify the identity of.

Also every claim issuer, needs to implement this identity interface himself, to make sure he is verifiable himself (and keys can be checked).

@Arachnid concerning key types: If we standardise them we allow many upcoming use cases for keys, as described in my previous comment. Currently i only propose two types: 1 management keys, and 2 action keys. The former is for manage your identity and they should stay safe. There can be n of m required for any change. The latter is for actions in the world, keys which can act in the name of your identity. Those are replaceable, and for everybody who wants to interact with you, should always check of you still hold those keys in your identity.

Claim types in return need to be predefined, to allow somebody who wants to verify you to look for what he want a proof about you.

I choose the word keys, over addresses as this is better understandable in the "off-chain" world. Keys are something we use on a daily basis to get into houses and objects, and the term is used in cryptography as well. Addresses is very blockchain specific. Though your identity contract address - i would call "address".

The current draft allows for all kind of different key management implementations, it doesn't force any, expect that there have to be at least one second step of approval to execute, as stated in the draft, some functions..:

"MUST only be done by keys of type 1, or the identity itself. If its the identity itself, the approval process will determine its approval."

(There is certainly a lot of improvement potential here, and when we think of compatible UIs, we will need to revise that)

Many of the above concepts may not be clear yet, but they are in the description of the ERC as a very concise sentence:

"This identity can hold keys to sign actions (transactions, documents, logins, access, etc), and claims, which are attested from third parties (issuers) and self attested, as well as a proxy function to act directly on the blockchain."

[Arachnid]

I choose the word keys, over addresses, as this is better understandable in the "off-chain" world. Keys are something we use on a daily basis to get into houses and objects, and the term used in cryptography as well. Addresses is very blockchain specific. Though you identity contract address, i would call "address".

The problem is, 'keys' has a specific use in cryptography, and you're using them to refer to something that isn't a cryptographic key, or necessarily controlled by one. I'd really suggest choosing a different term.

In either case, the EIP definitely needs a definitions section.

[frozeman]

I agree we should add a definition section.

Short answer to the above. keys are public keys: Those keys are you hands in the real world, you sign things, you make transactions etc.
Through these keys and a pointer to your identity, others can go check that its really you.
If they want to know things about you: e.g. are you a human, or have an address, then they look on the claims about you by others.

‘Keys’ here can be public keys or other contract, like multisigs and reputation systems. If anybody has a better word for them, I’m happy to change that.

[overdrev]

claims :
a.I would suggest a logic that permits explicit approval of claim by issuer - perhaps requiring an asynchronous process.
b. Do we cover a single usage access method such that a third party can prove my info, but only once. Maybe time limited.

[alexvandesande]

@MicahZoltu

There is value in standardizing tokens so that an application (e.g., Wallet, exchange, etc.) can interact with any token the user provides without needing to know about it in advance or write custom integrations for each token.

Exactly. I'd like to be able to login with my uPort identity into Mist, use my Mist identity in Status, or log in with my Status identity on a ether play game or post a blog post in Steemit from my Aragon Company identity. Each one can be implemented differently, just keep some common interfaces.