ERC: Proxy Account

[frozeman]

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

This issue exists as an archive only.

Original Text

``` eip: title: ERC-725 Smart Contract Based Account author: Fabian Vogelsteller , 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](https://github.com/ethereum/EIPs/blob/ede8c26a77eb1ac8fa2d01d8743a8cf259d8d45b/EIPS/eip-725.md). 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. ```js 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](#contractcreated) if a contract was created ### Events #### ContractCreated MUST be triggered when `execute` creates a new contract using the `_operationType` `1`. ```js event ContractCreated(address indexed contractAddress) ``` ### ERC725Y ERC165 identifier: `0x2bd57b73` #### getData Returns the data at the specified key. ```js 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](#datachanged) ```js function setData(bytes32 _key, bytes memory _value) external ``` ### Events #### DataChanged MUST be triggered when `setData` was successfully called. ```js 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](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-173.md) 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](https://github.com/ERC725Alliance/ERC725/tree/master/implementations/contracts). ## 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](https://github.com/ERC725Alliance/ERC725/tree/master/implementations/contracts) ### Solidity Interfaces ```solidity // 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](https://www.slideshare.net/FabianVogelsteller/erc-725-identity) - [In-contract claim VS claim registry](https://github.com/ethereum/wiki/wiki/ERC-735:-Claim-Holder-Registry-vs.-in-contract) - [Identity related reports](https://www.weboftrust.info/specs.html) - [W3C Verifiable Claims Use Cases](https://w3c.github.io/vc-use-cases/) - [Decentralised Identity Foundation](https://identity.foundation) - [Sovrin Foundation Self Sovereign Identity](https://sovrin.org/wp-content/uploads/2017/06/The-Inevitable-Rise-of-Self-Sovereign-Identity.pdf) ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

[tuxxy]

keyType: The type of key used, which would be a uint256 for different key types. e.g. 1 = ECDSA, 2 = RSA, etc.

This is great, but you can't fit a secure RSA key in 256-bits. In the addKey function, I also see you're using the key as a bytes32 which also doesn't fit an RSA key.

This only works with keys on 256-bit elliptic curves.

[frozeman]

The idea is to only store the hash of keys if they are > 32 bytes, as stated in the key structure.

O

[tuxxy]

Ah, my apologies. My eyes skipped right over.

Is your intention for all of your ECDSA public keys to be stored as a hash? Because a 256-bit integer isn't enough to store a public key. For 256-bit curves, you need 33 (or 64) bytes to store public keys. Essentially, the 33rd byte (which is prepended to the key) determines the y-coordinate. The 32 bytes are only the x-coordinate in compressed keys and there are two points for every x-coordinate that can be used on a curve.

[collincusce]

@tuxxy I see your point and I think you're correct. From what I glean from the spec is that you can store the hash of the public key instead and then use that hash to reference some other lookup table for the full key. The problem with this is that it will require some knowledge of that mechanism which is not currently present in this spec. One way around this is an optional "address" with a lookup contract for a public key store and as standardized getter, but there might be a more slick way I'm not seeing.

[tuxxy]

Well, I can see one utility:

1. Alice receives an ECDSA signature.
2. Alice pulls the public key from the signature and hashes it with Keccak-256.
3. Alice checks whether or not the given hash is on the contract.

If this is the intention, then this is fine. However, if the intention is to actually store the key data, the structure is not large enough. To resolve, you store the "y-flag" as another integer in the key structure.

For more information on this, see this bitcointalk thread: https://bitcointalk.org/index.php?topic=237260.0 and this Crypto StackExchange post: https://crypto.stackexchange.com/questions/8914/ecdsa-compressed-public-key-point-back-to-uncompressed-public-key-point

[sativ01]

Hi guys, trying to implement new version of 725 and 735. I ran into issue, and not sure how to proceed: When I add a key to an identity, I store the value in a Key structure, with a value stored in a variable bytes32 key. So in order to have a key of type CLAIM, I'd need to get a public key of that identity and store it in that key variable. Is that correct?

So the problem that I'm facing is that there's no way to get a public key from an Ethereum address and then to link it back to that Ethereum address when I need to validate a Claim. And I assume I need it, because in ERC735 Claim holds a data about an issuer: address issuer; rather then the key. So how do I link an issuer to a Key to verify Claim?

Thanks!

[bharathrao]

Good work and great to see one implementation already.

Im late to the party but I suspect the lack of clarity is because this is solving the wrong problem. The right problem to solve is sybil resistant decentralized claims. Since no one has solved it yet, this seems to be an attempt to take centralized claims and put it on the blockchain.

Any identity that requires some authority (ie govt) to define and bless claims cannot be called self-sovereign identity. All that's happening here is that data that would be stored by someone like complyadvantage in a database is now stored on the blockchain so that its contract accessible.

Even so, I don't understand how this approach is feasible:

getKey Returns the full key data, if present in the identity.

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.

and checks that the public key k is in fact still hold by issuer V

How do I verify public key k from the German state? Is there a private key everyone in German government shares? If the German state signs via a smart contract, would every official have their own key that needs to be coded into their issuer contract? Even if we give every official a different key when they join and mark their valid dates, are we going to store tens of thousands of public keys on the blockchain?

What happens if we learn that one of the official's keys was compromised for the last three months? Scale this issue to all jurisdictions

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.

imagine you want to prove you are over eighteen. A trusted entity can add a bit ask as claim, which contains a bit that states that’s you are over eigtheen without revealing your age.

Unfortunately, this is unworkable for several reasons.

Regulations require in-person verification for validity AND possession of identity documents for the following reasons:

1. Other than someone's birthday, nearly everything else can change including name, gender, address, citizenship, marital status and so on.
2. Identity documents/numbers can be lost, revoked or stolen
3. Trust is not transitive. You can't assume that just because Bank A has verified someones claim means Bank B doesn't need to. (ie W3C Verifiable Claims Use Cases is BS)

[chrismessina]

Small typo in Rationale section: "cross idenity compatibility".

[wanderingstan]

At Origin we just released a new version of our DApp that includes ERC725 for identity. It will deploy the user's identity contract, and submit verified claims for email, phone, Facebook, and Twitter. @nick extended his Identity Playground code and the rest of our team built out the attestations and UI/UX.

The DApp is live at demo.originprotocol.com or via IPFS. (ERC725 profile page)

• DApp GitHub repo
• Origin-js repo (Contains ERC725 contracts)
• Blog Post

Please give it a try and give feedback. We're happy to help others build ERC725 into their projects!

[pet3r-pan]

Is there a reason that the struct:

struct Key { uint256[] purposes; uint256 keyType; bytes32 key; }

Doesn't have a nonce or a unique identifier? Won't there be inefficiencies if you had 100 keys in the identity contract and you had to validate signed data by go through all the keys? This is possible scenario - my google auth used to have 150+ connected apps

[conejoninja]

@pet3r-pan the key itself should be your unique identifier, and you could use a mapping for direct access.

@wanderingstan wow, really nice, I'd like to see and example of not only claiming that "i have an email", but "this xxx@xxx.xxx is my email". Are you working on something similar?

[wanderingstan]

@conejoninja - We're treading carefully on how/if to store and represent personal data that has been verified. @nick can give a better idea, but our working plan now would be to store hashes of the data. That way an email (or phone, address, etc) can be verified by future parties without publishing it on blockchain/ipfs. Or cross referenced, e.g. you can prove that the email you verified is the same one verified by Facebook.

[bharathrao]

@wanderingstan Its trivial to hash known emails and associate known emails to blockchain identities.

How do you deal with the fact that phone numbers and emails can change owners or be hijacked and the blockchain may not be notified? How do I actually trust that the verifier has correctly verified any of the attributes?

Another question is why do even hashes need to be stored on the blockchain at all? If you need to, then I suggest you add a salt that is not stored on the blockchain. This is not perfect because once disclosed, the salt/data can leak but better than simple storage.

[conejoninja]

@wanderingstan I understand we are interested in some feedback and ideas how to do it, and/if this standard is suitable for it. Let's imagine an user is buying something online, the seller will want to know the user's verified address, the user could have one verified address and give the seller a different one, so the seller needs to check it's the one which was verified. You either store the address (in user's identity or maybe the issuer's contract), or the hash, storing only the hash, the user must re-type the information each time, which is prone to errors (or use an off-chain solution, app to manage it).

We see a lot of value in the case I've described. It's ok to know that the user have a verified phone or email, address, whatever... , but I need to know which one is to be able to interact with him.

[wanderingstan]

...the user must re-type the information each time, which is prone to errors (or use an off-chain solution, app to manage it).

@conejoninja, we're thinking along the same lines. The data to be verified (postal address in your example) could be kept in a local store (e.g. a mobile app, a wallet). Another solution would be to encrypt it and keep in a distributed store (e.g. IPFS).

In either case, the data would be shared with the seller, who could check the corresponding ERC725 claim to see that it is the same data (postal address) that was verified by the claim issuer. The seller can then mail the package with confidence.

[coleman415]

I'm gathering a list of projects and developers that are interested in adopting this standard. ERC 725 is great on its merits but also because its not "owned" by any one developer or group unlike many other competing identity protocols and standards. Feel free to email me at coleman@originprotocol.com.

[tuxxy]

I would like to bump my concerns with bytes32 being used for the key storage.

This standard does not store ECDSA keys, it stores the hashes of them. If the intention is to store the actual key, it needs to store a boolean value indicating which ECDSA key to use from the compressed x-coordinate.

[m-schmoock]

@frozeman Hey, in the KeyManagement specification you write that: Execute COULD be used as the only accessors for addKey, removeKey and replaceKey and removeClaim.

Does this also supply to addClaim or is it left out intentionally? The way I understand it a claim issuer will perform an execution request on my ERC725 using addClaim as execution request data, or am I wrong here? At least it looks like when reading the origin example code: https://github.com/OriginProtocol/identity-playground/tree/master/contracts

[juliosantos]

Does anyone have any thoughts on how to facilitate the transfer of ether through execute? All it takes is making it payable, but that's not what the standard says. Alternatively, I could implement any other payable function and add to the contract balance before executing.

Did I miss something?

[frozeman]

That’s a good point. I think it should be payable. Anybody with concerns? On 20. Jun

[juliosantos]

In that case, it might also make sense to also remove the value argument on execute and just store msg.value. I don't see a reason you'd want a value different than msg.value, but if there's such cases then a separate payable deposit function would make more sense.

[jllaw]

Pardon this question if is completely missing the point or missing what is obvious, but I'm not technical at all (a law/finance guy here) and wasn't sure from 725 and 735, can a claim be used not only to validate an identity but to also invalidate an identity? As you might see from my notes above, I struggled with the idea that regulators would want the identity of the person to be verified and one could never really guarantee that an ethereum address always represented that same person. However, I could image that if many claims from multiple third parties were made (esp if some of them were very reputable) attesting to identity for a particular address, one might be able to make the argument that it was reasonable to assume that address belonged to a particular identity. I would think that it would be important, however, to also allow claims that invalidate an identity (and I suppose one could see if there were claims tying different identities to the same address which would create the same doubt).

[frozeman]

@juliosantos the idea is that the identity can hold funds itself, function like a wallet, then you need to be able to send an amount, even if its not given via the execute function.

@jllaw self sovereign identity should always be controlled by the owner, so attaching claims that the owner doesn't agree to shouldn't be possible (though one could build that even with this spec).

What youre talking about is a reputation system, which probably should work a bit different.

[juliosantos]

Gotcha, that makes sense. No point in narrowing down on implementation possibilities.

[cbruguera]

@frozeman I'm working on an implementation of this standard, yet I'm having a problem trying to figure out what is the purpose of making a call to the approve method with _approve == false. Given that a task approved status would be already false by default, what sense does it make to spend a call to this method while making no effect whatsoever? Any views on this?

Note: I'm basing myself on the OriginProtocol implementation as a reference, yet I understand other implementations MIGHT make better use of this parameter, however, I still don't see how at the level of this standard such parameter is justified.

[nick]

@cbruguera it could be useful when implementing a multisig identity where parties must cast an explicit yes/no vote. I believe @mirceapasoi's implementation has support for that.

[conejoninja]

I have a doubt, as an issuer, the way to remove a claim made on another identity, is to remove the key that signed such claim, right? so each claim should be made with a different key so it has control to revoke specific claims (the verification will fail). Is this right?

[nick]

Yes although that's probably not very efficient if you're planning to revoke claims frequently. Check the description in ERC 735 for an alternative where the claim issuer is itself a contract called with the data stored in the original claim. That contract can return true or false depending on whether the claim is currently valid based on other data stored on-chain.

[conejoninja]

@nick Thanks, I don't plan to do it frequently but maybe you close a bank account you have previously verified... If the bank used the same key for all its customers all their customers has to re-claim they have a bank account or ask you nicely to remove the claim. Just wanted to check I understood it correctly. Some issuers will need a different scheme as described in 735, thanks for the info

[jllaw]

Thanks @frozeman. It makes sense that in a pure self-sovereign, the identity owner would control everything. Without a reputation feature, I wonder if self-sovereign identity on Ethereum is limited though. Because of the nature of the addresses, even though one might take comfort in knowing that many reputable parties have made positive claims that the self-sovereign accepts, there's no protection if that address is compromised or attempted to be used for another identity. Is there a way, at least, to see all the claims that are made (even if they are not accepted by the identity owner) so that I could have some logic on my end that says something like if 5+ people make claim of the same nature, then I trust it, but if even one person makes a claim that is not matching the others, then I don't automatically trust it?

[tyleryasaka]

@jllaw I think there is certainly a need for decentralized reputation, but that is outside the scope of this proposal. ERC725 is a base identity layer, agnostic about how it might be used in something such as a reputation system. I am certainly interested in reputation standards that could be built on top of ERC725.

What you described is possible, but it would be an alternative to ERC735. It is also vulnerable to sybil attacks. Until you have some on-chain method of verifying uniqueness of an individual (which is very much an open problem at this time), there is nothing to prevent one person from creating 5 ERC725 identities and issuing 5 different claims with them.

[jllaw]

Thanks @tyleryasaka! Very, very helpful. I agree that there isn't currently an on-chain method of verifying uniqueness (it's a problem I've dealt with because on a weekly basis, I'm asked (including by many blockchain experts and attorneys) if one can do aml/kyc or other verifications just off an Ethereum address, and I have to explain why we can't). You guys have been so understanding and great as a community. These github discussion are a bit challenging for me as I hardly have any development/engineering background, and as there's a lot of that embedded within the initial writeup and subsequent conversations. I know I'm asking some ignorant questions, and all of your responses have really been courteous and educational.

Building on top of ERC725 might be the way to go; I'll take a look to try to understand ERC735 as best as I can, in particular to understand why what I described is an alternative to ERC735. No sense recreating the wheel if something else works. I don't know how to get around the Sybil attacks yet - I suppose a bad actor could always cause problems.

[m-schmoock]

@jllaw I think it is possible to see if there are unconfirmed claims by checking the execution request array of the corresponding ERC725 contract. The way I understand the proposals, a claim has to be made by making an execution request on the ERC725 that will later call the "addClaim" function of the ERC735 once approved by the owner. So you can 'simply' parse the execution requests functionhash and arguments to see if others want to make certain (yet unconfirmed) claims about somebody else...

So as a prequisite for that you need to know the ERC725 address of the identity...

Disclaimer: I was not fully able to verify my assumption, but by looking at implementations and actually implenting it myself, it at least looks like that to me.

[jllaw]

@m-schmoock, thanks. Having the knowledge of unconfirmed claims is useful information as well. Basically, I'm curious if an address has ever seemed to be used for a different identity, which would imply that maybe the original identity (even with all the positive claims) might not be reliable any longer and at least require further diligence.

[nathanawmk]

Are there any ERC725-based smart contracts samples that one could leverage on?

Nathan Aw (Singapore)

[conejoninja]

@nathanawmk In the Implementation section there are a few examples : https://github.com/ethereum/EIPs/blob/master/EIPS/eip-725.md#implementation

[m-schmoock]

@nathanawmk we started working on https://github.com/OriginProtocol/identity-playground/tree/master/contracts which is a good base. However their implementation suggest to use executionRequests also for ERC735.addClaim() which confused a bit. This can be done, but the executionRequests is not meant to be used for a inter-system protocol chat function ;)

See src/actions/Identity.js 306ff

   var abi = await UserIdentity.methods                                           
      .addClaim(claimType, scheme, claimIssuer, signature, hexedData, uri)         
      .encodeABI()                                                                 

    var tx = UserIdentity.methods.execute(targetIdentity, 0, abi).send({           
      gas: 4612388,                                                                
      from: web3.eth.defaultAccount                                                
    })

[nathanawmk]

Hey all, am looking to extend DIDs for devices/machines and to be incorporated as specs. One could sort of piggyback existing supply chain standards for it. Please refer to https://github.com/w3c-ccg/did-spec/issues/100

Would be keen to work with anyone who is keen. Self-sovereign identity for devices/machines for a decentralized, trustworthy and transparent supply chain.

Nathan Aw

[frozeman]

There is now a erc725 alliance, maybe this is something to be worked on in there: https://erc725alliance.org/

Kind regards, Fabian On 31. Aug 2018, 12:55 +0200, Nathan Aw <

[nathanawmk]

Hi fabian, am keen to build on the great work you and your team have already done. I am based out of Asia, specifically, Singapore, a financial hub known for innovation. Am looking at extending erc725 with a focus on a range of attestation techniques bridging the enteprise space with private etherum space such as quorum. I made a pull request. Hope to have the pull request accepted.

https://ethereum.stackexchange.com/questions/57800/deploying-erc-725-blockchain-identity-ids-on-quorum

[nathanawmk]

Like the ERC20 standards, which is a great, great standard, I am imagining a future where there will be full of erc725 based token/identities. One's identity can be on multiple different addresses as one's identity could be stored on ERC725 based contract 1,2,3,4,5.... For decentralized identities to be unique, is there some way to adopt and leverage ERC721 for its non-fungible attributes? e.g., just one unique DID on the entire Ethereum blockchain, similar to our nation issued identifier.

Nathan Aw

https://ethereum.stackexchange.com/questions/57856/erc725-adopting-extending-erc721-non-fungibility-attribute-for-unique-decentrali

[nathanawmk]

does ERC725 uint256 keyType differentiates between ECDSA and ED25519? If so, what is the enumeration value for an ed25519 public key? Thank you.

https://ethereum.stackexchange.com/questions/57994/erc725-keytype-differentiates-between-ecdsa-and-ed25519

[drewstone]

@tyleryasaka I'm curious since I see Origin moving forward with this standard.. what is the eligibility of this from the user's perspective? At first glance, the gas costs for deploying an individual identity contract are nearly $3-$5. What incentive do users have to spend that much to set up a contract that manages keys in this way?

[tyleryasaka]

@drewstone Yes gas costs are possibly the biggest concern right now. One thing that I did was move as much code as possible into libraries (see KeyHolderLibrary and ClaimHolderLibrary), so that the logic does not need to be re-deployed with each contract.

There is also one engineer at Origin experimenting with ways that gas can be paid on end users' behalf.

On top of these things, we're hoping that Ethereum scaling solutions will make gas costs more reasonable in the not-too-distant future.

There certainly won't be mass adoption of this standard until the gas problem has been dealt with.

[kameir]

It would seem important to make room for the distinction between 'ephemeral' and 'permanent' and potentially levels in between. In particular: human beings and other living things have creation and 'expiration' dates, whereas other things (i.e. places) are not subject to it. So, structures should flow from the fixed to the fluid. - Hopefully, this is not too esoteric ..

[tyleryasaka]

I've been doing a lot of research and thinking around ERC725/ERC735 lately, and I have some criticisms of the current standards along with 2 proposed changes to address them. Curious if these thoughts resonate with anyone here? Would appreciate any feedback. (My background is that I'm one of the engineers at Origin that has been integrating these standards into a javascript library and Dapp.)

My proposals and criticisms: https://medium.com/@tyleryasaka/erc725-proposed-changes-ea2dc221136e

Example contracts that implement my proposals: https://github.com/tyleryasaka/identity-proposals

[conejoninja]

@tyleryasaka I liked the first part of decoupling key management, we run into the same issue trying to use multisign for execution. On the second part I doesn't agree that much, that looks more like a reputation system and not the identity. It's possible to create a virtually infinite number of negative claims about a third party/identity, adding to much noise to their identity, not sure how this will affect the identity/reputation. At EU there's also the "right-to-be-forgotten" which will not sit well with ERC780 approach (almost every organization we've talked to asked about it)

[tyleryasaka]

@conejoninja I share those concerns. However, I don't think ERC735 addresses them. Anything written to the blockchain is permanent, even if you "delete" the data. You should never write anything to the blockchain if you want to be able to remove it later.

ERC780 was posted by the uPort team, and they are very concerned about privacy, user-controlled data, and the right to be forgotten. Check out this post where they outline the way they plan to use ERC780: https://medium.com/uport/erc1056-erc780-an-open-identity-and-claims-protocol-for-ethereum-aef7207bc744

Based on the concerns you mentioned (which I think are well-founded), I think you may want to look at off-chain claims solutions.

[frozeman]

@tyleryasaka thanks for your extensive blog post. I do think those are good ideas. Concerning the first point of separating keys from execution. That is certainly useful. The standard as it is right now can also only have one two keys (management and execution) and both could be a smart contract (and even the same). I added it here already so that interfaces also think about interacting with identities properly and not make it a one-key-controls-it-all system. But making this separate makes a lot of sense and I agree with your argumentation here.

Regarding the second point of #780 over #735: 735 tries to standardize more how claims look like and how you can interact with those. While 780 is simple a key value store. My idea behind 735 is that it is for claims you wa t to control (allow) and you deem them permanent. In fact all 725 identities have to be seen as permanent and public indentities. Für any private identity offchain identifiers and claims are better. 735 could be for you academic certifications or your esport trophy. Something you carry long around with you. While simple claims that are temporary or many should rather be off chain or on 780. I do see usefulness for both standard to be used in conjunction. Concerning my argument for “all in one place”: it’s more about control. A registry could become outdated or even removed (if it’s owned). You own claim contract can contain extra logic which you as a company or institution want or need. But other contracts and interfaces are able to read and interact with them. I wanted to encourage experimentation around claims, while having a basic structure. It’s certainly not the slimmest or action less standard, that’s true.

I am happy to see either, or both being adopted. The goal is to get the best and most useful standards to use. No hard feelings :)

[tyleryasaka]

@frozeman Thanks for reading and responding.

735 could be for you academic certifications or your esport trophy. Something you carry long around with you. While simple claims that are temporary or many should rather be off chain or on 780. I do see usefulness for both standard to be used in conjunction.

I guess for me, I'm still not sure why an academic certification or an esport trophy could not simply be issued as a 780 claim. To me that would make it a lot simpler and easier to reason about. Also, the revocation path is straightforward, in case the issuer ever decides to revoke the claim. (I realize ERC735 can be structured to allow individual revocations, but to me it seems unnecessarily cumbersome). But sure I agree, it's up to people implementing to decide what works best for them. I don't personally find the current ERC735 structure to be particularly useful, but that's just me. I like to be opinionated. 😃

Concerning my argument for “all in one place”: it’s more about control. A registry could become outdated or even removed (if it’s owned). You own claim contract can contain extra logic which you as a company or institution want or need. But other contracts and interfaces are able to read and interact with them. I wanted to encourage experimentation around claims, while having a basic structure. It’s certainly not the slimmest or action less standard, that’s true.

Yeah after writing that post I thought more about this. I actually agree that having one centralized registry architecture has limitations. The logic can't be extended or customized in any way. I have been experimenting with a possible claims standard that would allow issuers to deploy their own "Claim Manager" contracts which could contain their own custom logic around claims, as long as they support the interface. (Discovery of these contracts would occur through a "Claim Issuer Registry" that includes a getClaim method that is backwards compatible with ER780.) This standard would have all of the flexibility of ERC735 while being simpler and more compatible with ERC780. Would be curious if anyone has any thoughts about this approach. https://github.com/tyleryasaka/identity-proposals#ercxxxx_claimmanager

All this said, I've been working with others in the space that are trying to implement their own standards. I'm doing active research in the repo linked in the above paragraph. I'd love to keep the dialog going. 😃