New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ERC: Identity #725

Open
frozeman opened this Issue Oct 2, 2017 · 195 comments

Comments

Projects
None yet
@frozeman
Member

frozeman commented Oct 2, 2017

eip: <to be assigned>
title: ERC-725 Identity
author: Fabian Vogelsteller (@frozeman) <fabian@ethereum.org>
discussions-to: https://github.com/ethereum/EIPs/issues/725
status: Draft
type: Standards Track
category: ERC
created: 2017-10-02

NOTE The current DRAFT is merged here: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-725.md, which is the latest state of the document.
All change requests should be made as separate PRs to that document.


Simple Summary

Proxy contract for key management and execution, to establish a Blockchain identity.

Abstract

The following describes standard functions for a unique identity for humans, groups, objects and machines.
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 (#ERC735), as well as a proxy function to act directly on the blockchain.

Motivation

This standardised identity interface will allow Dapps, smart contracts and thirdparties to check the validity of a person, organisation, object or machine through 2 steps as described in the function XXX. Trust is here transfered to the issuers of claims.

The most important functions to verify an identity are: XXX

The most important functions to manage an identity are: XXX

Definitions

  • keys: Keys are public keys from either external accounts, or contract addresses.
  • claim issuer: is another smart contract or external account, which issues claims about this identity. The claim issuer can be an identity contract itself.
  • claim: For details about claims see #ERC735

Specification

Key Management

Keys are cryptographic public keys, or contract addresses associated with this identity.
The structure should be as follows:

  • key: A public key owned by this identity
    • purpose: uint256[] Array of the key types, like 1 = MANAGEMENT, 2 = ACTION, 3 = CLAIM, 4 = ENCRYPTION
    • keyType: The type of key used, which would be a uint256 for different key types. e.g. 1 = ECDSA, 2 = RSA, etc.
    • key: bytes32 The public key. // for non-hex and long keys, its the Keccak256 hash of the key
struct Key {
    uint256[] purposes;
    uint256 keyType;
    bytes32 key;
}

getKey

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

function getKey(bytes32 _key) constant returns(uint256[] purposes, uint256 keyType, bytes32 key);

keyHasPurpose

Returns the TRUE if a key has is present and has the given purpose. If key is not present it returns FALSE.

function keyHasPurpose(bytes32 _key, uint256 purpose) constant returns(bool exists);

getKeysByPurpose

Returns an array of public key bytes32 hold by this identity.

function getKeysByPurpose(uint256 _purpose) constant returns(bytes32[] keys);

addKey

Adds a _key to the identity. The _purpose specifies the purpose of key. Initially we propose four purposes:

  • 1: MANAGEMENT keys, which can manage the identity
  • 2: ACTION keys, which perform actions in this identities name (signing, logins, transactions, etc.)
  • 3: CLAIM signer keys, used to sign claims on other identities which need to be revokable.
  • 4: ENCRYPTION keys, used to encrypt data e.g. hold in claims.

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

Triggers Event: KeyAdded

function addKey(bytes32 _key, uint256 _purpose, uint256 _keyType) returns (bool success)

removeKey

Removes _key from the identity.

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

Triggers Event: KeyRemoved

function removeKey(bytes32 _key, uint256 _purpose) returns (bool success)

Identity usage

execute

Executes an action on other contracts, or itself, or a transfer of ether.
SHOULD require approve to be called with one or more keys of purpose 1 or 2 to approve this execution.

Execute COULD be used as the only accessors for addKey, removeKey and replaceKey and removeClaim.

Returns executionId: SHOULD be send to the approve function, to approve or reject this execution.

Triggers Event: ExecutionRequested
Triggers on direct execution Event: Executed

function execute(address _to, uint256 _value, bytes _data) returns (uint256 executionId)

approve

Approves an execution or claim addition.
This SHOULD require n of m approvals of keys purpose 1, if the _to of the execution is the identity contract itself, to successfull approve an execution.
And COULD require n of m approvals of keys purpose 2, if the _to of the execution is another contract, to successfull approve an execution.

Triggers Event: Approved
Triggers on successfull execution Event: Executed
Triggers on successfull claim addition Event: ClaimAdded

function approve(uint256 _id, bool _approve) returns (bool success)

Identity verification

Requires: ERC 735

The following changes to ERC 735 are REQUIRED:

addClaim

This SHOULD create a pending claim, which SHOULD to be approved or rejected by n of m approve calls from keys of purpose 1.

Only Events:
Triggers if the claim is new Event and approval process exists: ClaimRequested
Triggers if the claim index existed Event: ClaimChanged

removeClaim

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


Events

KeyAdded

MUST be triggered when addKey was successfully called.

event KeyAdded(bytes32 indexed key, uint256 indexed purpose, uint256 indexed keyType)

KeyRemoved

MUST be triggered when removeKey was successfully called.

event KeyRemoved(bytes32 indexed key, uint256 indexed purpose, uint256 indexed keyType)

ExecutionRequested

MUST be triggered when execute was successfully called.

event ExecutionRequested(uint256 indexed executionId, address indexed to, uint256 indexed value, bytes data)

Executed

MUST be triggered when approve was called and the execution was successfully approved.

event Executed(uint256 indexed executionId, address indexed to, uint256 indexed value, bytes data)

Approved

MUST be triggered when approve was successfully called.

event Approved(uint256 indexed executionId, bool approved)
The following changes to ERC 735 are REQUIRED:

ClaimRequested

MUST be triggered when addClaim was successfully called.

ClaimAdded

MUST be triggered when approve was called and the claim was successfully added.

Constraints

  • A claim can only be one type per type per issuer.

Rationale

This specification was chosen to allow most flexibility and experimention around identity. By having each identity in a separate contract it allows for cross idenity compatibility, but at the same time extra and altered functionality for new use cases.

The main critic of this standard is the verification where each identity that issues a claim, also should have a separate CLAIM signing key attached. While #ERC780 uses a standardised registry to assign claims to addresses.
Both systems could work in conjunction and should be explored.
While also off-chain claims using DID verifiable claims and merkle tries can be added as claims and should be explored.

The rationale of this standard is to function as an open and veryf flexible container for idenity.

Implementation

Solidity Interface

pragma solidity ^0.4.18;

contract ERC725 {

    uint256 constant MANAGEMENT_KEY = 1;
    uint256 constant ACTION_KEY = 2;
    uint256 constant CLAIM_SIGNER_KEY = 3;
    uint256 constant ENCRYPTION_KEY = 4;

    event KeyAdded(bytes32 indexed key, uint256 indexed purpose, uint256 indexed keyType);
    event KeyRemoved(bytes32 indexed key, uint256 indexed purpose, uint256 indexed keyType);
    event ExecutionRequested(uint256 indexed executionId, address indexed to, uint256 indexed value, bytes data);
    event Executed(uint256 indexed executionId, address indexed to, uint256 indexed value, bytes data);
    event Approved(uint256 indexed executionId, bool approved);

    struct Key {
        uint256 purpose; //e.g., MANAGEMENT_KEY = 1, ACTION_KEY = 2, etc.
        uint256 keyType; // e.g. 1 = ECDSA, 2 = RSA, etc.
        bytes32 key;
    }

    function getKey(bytes32 _key) public constant returns(uint256[] purposes, uint256 keyType, bytes32 key);
    function keyHasPurpose(bytes32 _key, uint256 purpose) constant returns(bool exists);
    function getKeysByPurpose(uint256 _purpose) public constant returns(bytes32[] keys);
    function addKey(bytes32 _key, uint256 _purpose, uint256 _keyType) public returns (bool success);
    function execute(address _to, uint256 _value, bytes _data) public returns (uint256 executionId);
    function approve(uint256 _id, bool _approve) public returns (bool success);
}

Additional References

Copyright

Copyright and related rights waived via CC0.

@frozeman frozeman added the ERC label Oct 2, 2017

@alexvandesande

This comment has been minimized.

Show comment
Hide comment
@alexvandesande

alexvandesande Oct 2, 2017

Contributor

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

Contributor

alexvandesande commented Oct 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@frozeman

frozeman Oct 2, 2017

Member

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.

Member

frozeman commented Oct 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@alexvandesande

alexvandesande Oct 2, 2017

Contributor

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.

Contributor

alexvandesande commented Oct 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@frozeman

frozeman Oct 2, 2017

Member

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.

Member

frozeman commented Oct 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@MicahZoltu

MicahZoltu Oct 2, 2017

Contributor

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

Contributor

MicahZoltu commented Oct 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@alexvandesande

alexvandesande Oct 2, 2017

Contributor

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

Contributor

alexvandesande commented Oct 2, 2017

@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 comment has been minimized.

Show comment
Hide comment
@frozeman

frozeman Oct 2, 2017

Member

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.

Member

frozeman commented Oct 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@MicahZoltu

MicahZoltu Oct 2, 2017

Contributor

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.

Contributor

MicahZoltu commented Oct 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Oct 3, 2017

Collaborator

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.

Collaborator

Arachnid commented Oct 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@frozeman

frozeman Oct 3, 2017

Member

@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."

Member

frozeman commented Oct 3, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Oct 3, 2017

Collaborator

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.

Collaborator

Arachnid commented Oct 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@frozeman

frozeman Oct 3, 2017

Member

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.

Member

frozeman commented Oct 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@overdrev

overdrev Oct 3, 2017

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.

overdrev commented Oct 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@alexvandesande

alexvandesande Oct 3, 2017

Contributor

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

Contributor

alexvandesande commented Oct 3, 2017

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

@oed

This comment has been minimized.

Show comment
Hide comment
@oed

oed Oct 3, 2017

This is very interesting and it overlaps a bunch with stuff we are doing with uport. Although we have a quite different design I think discussion and standardization around this will be very usefull. I'll give a breif description of our design before I go on.

As the base of our identity we use a very simple proxy contract, see also ERC: Proxy standard. This makes our system very flexible in terms of how you can control an identity.
To control a proxy contract we use a contract we call IdentityManager. The basic idea is that we want a single contract that multiple users can use to control their proxies, mostly to reduce gas cost. Here we have the ability to add multiple users etc, but this is something we want to iterate on in the future.
To issue and lookup claims we have a separate contract uport-registry. The basic idea here is that we want to separate the storing of the claims from the identity itself to a different contract.

I think this ERC touches two very interesting things, transaction execution and claim structures.

Transaction execution

The execute/approve looks promising and definitely something that should be used for high value transactions. e.g. transaction of > 100 eth needs to be aproved by my hardware wallet. But in the case of low value transactions it seems like a bit of overhead, e.g. I need to send two transactions in order to send a tweet on leeroy. Would be interesting to have a system where some execute are automatically approved.

Claims

We've opted for not storing claims in the identity contract itself, this makes it cheeper to depoy identities while claims can still be associated with the identity with the same level of security.
Another thing we have though a lot about is the privacy of claims. Right now there is basically no privacy for claims that are on-chain, which is basically a no-go for a lot of our use cases. Instead we are mostly using off-chain claims which also can be securely linked to the identity (proxy contract in our case). Of course we see the benefits of having on-chain claims as well, and standardization around the format of these is very useful, but they should be decoupled from the identity contract itself. Maybe the claim section could be put into a separate ERC?

oed commented Oct 3, 2017

This is very interesting and it overlaps a bunch with stuff we are doing with uport. Although we have a quite different design I think discussion and standardization around this will be very usefull. I'll give a breif description of our design before I go on.

As the base of our identity we use a very simple proxy contract, see also ERC: Proxy standard. This makes our system very flexible in terms of how you can control an identity.
To control a proxy contract we use a contract we call IdentityManager. The basic idea is that we want a single contract that multiple users can use to control their proxies, mostly to reduce gas cost. Here we have the ability to add multiple users etc, but this is something we want to iterate on in the future.
To issue and lookup claims we have a separate contract uport-registry. The basic idea here is that we want to separate the storing of the claims from the identity itself to a different contract.

I think this ERC touches two very interesting things, transaction execution and claim structures.

Transaction execution

The execute/approve looks promising and definitely something that should be used for high value transactions. e.g. transaction of > 100 eth needs to be aproved by my hardware wallet. But in the case of low value transactions it seems like a bit of overhead, e.g. I need to send two transactions in order to send a tweet on leeroy. Would be interesting to have a system where some execute are automatically approved.

Claims

We've opted for not storing claims in the identity contract itself, this makes it cheeper to depoy identities while claims can still be associated with the identity with the same level of security.
Another thing we have though a lot about is the privacy of claims. Right now there is basically no privacy for claims that are on-chain, which is basically a no-go for a lot of our use cases. Instead we are mostly using off-chain claims which also can be securely linked to the identity (proxy contract in our case). Of course we see the benefits of having on-chain claims as well, and standardization around the format of these is very useful, but they should be decoupled from the identity contract itself. Maybe the claim section could be put into a separate ERC?

@bneiluj

This comment has been minimized.

Show comment
Hide comment
@bneiluj

bneiluj Oct 3, 2017

I agree with @Arachnid - 'keys' should refer to cryptographic key.

@frozeman Great initiative! This is so needed. It's a great step forward a standard for a self sovereign identity but it will not prevent people from creating more than one identity which is a no-go regarding KYC institution requirement process. Except if the identity public address is linked to multiple trustworthy services.

bneiluj commented Oct 3, 2017

I agree with @Arachnid - 'keys' should refer to cryptographic key.

@frozeman Great initiative! This is so needed. It's a great step forward a standard for a self sovereign identity but it will not prevent people from creating more than one identity which is a no-go regarding KYC institution requirement process. Except if the identity public address is linked to multiple trustworthy services.

@frozeman

This comment has been minimized.

Show comment
Hide comment
@frozeman

frozeman Oct 3, 2017

Member

@overdrev I’m not sure if a Claim permission process is needed, except when an entity wants to know the details of the claim, e.g. see the biometric data stored by the issuer. Then of course we need a async process. I have made some thoughts about that, but this is not really part of this ERC and can be a separate standard.

I see it as follows: claim data (referenced by ‘bytes claim’) is double encrypted by the issuer and me, if somebody wants to see the actual data they request it at the issuers ‘bytes _location’ and request the issuers part to be decrypted, then they come to me and ask for decrypting the second part, which i can always decline.

For b. I’m not sure how a single claim proof should look like, but interesting idea.

@oed thanks for participating, you guys should have actually started that standardization process ;)
Concerning your approaches:

Transaction execution: the excite function is mainly to act as your identity on the Blockchain in the least cases this contract should and will be used for storing and sending ether. If you want to move money and what that to be publicly visible and attached to your identity, use a multisig, or a wallet which is controlled by your keys from your identity .

Claim storage: I do understand you wanted to create a system which is cheap in gas, as uport will overtake most transaction costs in the beginning, but I don’t think this applies for a self owned standard, and would be the wrong approach to that. At the same time when a standard is found and a library is deployed, deploying a contract which uses that library is quite cheap.

Claims themself will be added by others, the owner of the identity will only pay for the confirmation. As I think A real used identity won’t attach every new app, or social network as new claim, those claim additions will be rather less. Things like this will be stored in other Reputation systems or uport like systems and can be attached as a self made claim to my identity, this way the identity can be kept rather raw. The “cool” stuff can happen on other experimental systems.

I’d say there are two main reasons why claims should be with the identity contract:

  1. It allows for on chain verifications and in the best case the contract, which wants to verify, only needs to call you identity once. He doesn’t have to go look on another address, or even outside of the BC. This allows for complex automated authentication systems purely running on the Blockchain.
  2. People want the feeling of having their things on one place, as funny as this sounds but it makes people feel more in control. It’s hard for people to acces their identity through registry contracts, if they don’t fully trust the registry. On top of that this standard allow for many different implementations of identities, which will all be able to create claims about each other.

There is probably more reasons, which don’t come to my mind now.

Concerning privacy: as the claim data is only meta data, the only viable information one can retrieve from your identity is: which claim issuer has claims about me (e.g. the German state, or Vitalik claims something about me), and when that data has changed.

This can be an issue, if I don’t want anybody to know I live or are German, but we share a lot more information on social networks daily. Also privacy focused claim provider can pop up, which claim things, like address etc globally, but are trusted by many. Then the only thing it leaks, is that you are privacy focused :)

@bneiluj people will have more than one identity for sure, as we just start to experiment with this, but once your have gone through the effort to get claims about biometric data and address, etc. you will treat this identity as more valueable. As long as you can add new claims of importance to more than one identity, that’s fine too. The person verifying your identity doesn’t need to care, as long as he can trust the claim issuer.

Member

frozeman commented Oct 3, 2017

@overdrev I’m not sure if a Claim permission process is needed, except when an entity wants to know the details of the claim, e.g. see the biometric data stored by the issuer. Then of course we need a async process. I have made some thoughts about that, but this is not really part of this ERC and can be a separate standard.

I see it as follows: claim data (referenced by ‘bytes claim’) is double encrypted by the issuer and me, if somebody wants to see the actual data they request it at the issuers ‘bytes _location’ and request the issuers part to be decrypted, then they come to me and ask for decrypting the second part, which i can always decline.

For b. I’m not sure how a single claim proof should look like, but interesting idea.

@oed thanks for participating, you guys should have actually started that standardization process ;)
Concerning your approaches:

Transaction execution: the excite function is mainly to act as your identity on the Blockchain in the least cases this contract should and will be used for storing and sending ether. If you want to move money and what that to be publicly visible and attached to your identity, use a multisig, or a wallet which is controlled by your keys from your identity .

Claim storage: I do understand you wanted to create a system which is cheap in gas, as uport will overtake most transaction costs in the beginning, but I don’t think this applies for a self owned standard, and would be the wrong approach to that. At the same time when a standard is found and a library is deployed, deploying a contract which uses that library is quite cheap.

Claims themself will be added by others, the owner of the identity will only pay for the confirmation. As I think A real used identity won’t attach every new app, or social network as new claim, those claim additions will be rather less. Things like this will be stored in other Reputation systems or uport like systems and can be attached as a self made claim to my identity, this way the identity can be kept rather raw. The “cool” stuff can happen on other experimental systems.

I’d say there are two main reasons why claims should be with the identity contract:

  1. It allows for on chain verifications and in the best case the contract, which wants to verify, only needs to call you identity once. He doesn’t have to go look on another address, or even outside of the BC. This allows for complex automated authentication systems purely running on the Blockchain.
  2. People want the feeling of having their things on one place, as funny as this sounds but it makes people feel more in control. It’s hard for people to acces their identity through registry contracts, if they don’t fully trust the registry. On top of that this standard allow for many different implementations of identities, which will all be able to create claims about each other.

There is probably more reasons, which don’t come to my mind now.

Concerning privacy: as the claim data is only meta data, the only viable information one can retrieve from your identity is: which claim issuer has claims about me (e.g. the German state, or Vitalik claims something about me), and when that data has changed.

This can be an issue, if I don’t want anybody to know I live or are German, but we share a lot more information on social networks daily. Also privacy focused claim provider can pop up, which claim things, like address etc globally, but are trusted by many. Then the only thing it leaks, is that you are privacy focused :)

@bneiluj people will have more than one identity for sure, as we just start to experiment with this, but once your have gone through the effort to get claims about biometric data and address, etc. you will treat this identity as more valueable. As long as you can add new claims of importance to more than one identity, that’s fine too. The person verifying your identity doesn’t need to care, as long as he can trust the claim issuer.

@frozeman

This comment has been minimized.

Show comment
Hide comment
@frozeman

frozeman Oct 3, 2017

Member

@Arachnid I added a definitions section. I’m still open for better names for keys.

Member

frozeman commented Oct 3, 2017

@Arachnid I added a definitions section. I’m still open for better names for keys.

@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Oct 3, 2017

Collaborator

@frozeman Anything other than keys, really. I'd suggest 'principals', for instance.

It's still not clear to me what goes in this field. The definition says "public keys", but contracts don't have public keys. What would the 'key' for a contract be?

Collaborator

Arachnid commented Oct 3, 2017

@frozeman Anything other than keys, really. I'd suggest 'principals', for instance.

It's still not clear to me what goes in this field. The definition says "public keys", but contracts don't have public keys. What would the 'key' for a contract be?

@alexvandesande

This comment has been minimized.

Show comment
Hide comment
@alexvandesande

alexvandesande Oct 3, 2017

Contributor

@oed

I need to send two transactions in order to send a tweet on leeroy.

Actually I don't think that's how I would recommend. You can sign your tweet with any account, publish and say: "I am tweeting in behalf of foo.eth". Then the tweet app can check either that account is listed in one of these keys. No on-chain transaction required.

Contributor

alexvandesande commented Oct 3, 2017

@oed

I need to send two transactions in order to send a tweet on leeroy.

Actually I don't think that's how I would recommend. You can sign your tweet with any account, publish and say: "I am tweeting in behalf of foo.eth". Then the tweet app can check either that account is listed in one of these keys. No on-chain transaction required.

@jpitts

This comment has been minimized.

Show comment
Hide comment
@jpitts

jpitts Oct 3, 2017

Member
  1. Will the claimTypes enumeration be maintained as part of the standard?

  2. Claim location might be better represented as claim uri, even if it involves a hash. But is a URI scheme involving a hash defined for all cases? I saw a lot of discussions in IPLD / IPFS about URI schemes, and in that community it seems inconclusive.

Example discussion: ipfs/ipfs#227

https://en.wikipedia.org/wiki/Uniform_Resource_Identifier

Member

jpitts commented Oct 3, 2017

  1. Will the claimTypes enumeration be maintained as part of the standard?

  2. Claim location might be better represented as claim uri, even if it involves a hash. But is a URI scheme involving a hash defined for all cases? I saw a lot of discussions in IPLD / IPFS about URI schemes, and in that community it seems inconclusive.

Example discussion: ipfs/ipfs#227

https://en.wikipedia.org/wiki/Uniform_Resource_Identifier

@CDsigma

This comment has been minimized.

Show comment
Hide comment
@CDsigma

CDsigma Oct 3, 2017

Is the plan to allow claimTypes to not only be used to verify an identity but also to verify information about an identity?

claimTypes could be used to confirm accreditations from institutions, attendance at events and place of work. So for example if a decentralized Uber was created and this dApp only wanted drivers who had gone to driving school, then claimTypes could be used to confirm this. If the drivers received the proper claimType from a credible driving school they could be drivers for this decentralized application. So claimTypes if used this way could automate the process of checking the credentials of identities.

CDsigma commented Oct 3, 2017

Is the plan to allow claimTypes to not only be used to verify an identity but also to verify information about an identity?

claimTypes could be used to confirm accreditations from institutions, attendance at events and place of work. So for example if a decentralized Uber was created and this dApp only wanted drivers who had gone to driving school, then claimTypes could be used to confirm this. If the drivers received the proper claimType from a credible driving school they could be drivers for this decentralized application. So claimTypes if used this way could automate the process of checking the credentials of identities.

@MicahZoltu

This comment has been minimized.

Show comment
Hide comment
@MicahZoltu

MicahZoltu Oct 4, 2017

Contributor

I understand that you want to keep the contents of the ERC "just the spec" but reading over all of the comments here I think the lack of a really clear problem statement and really clear and targeted solution is causing confusion. It sounds like there are several different interpretations of what this ERC is about in this discussion and everyone has a different image in their head as to what this will be used for.

@frozeman Can you provide a problem statement or user story as a starting point? Describe the problem that you are trying to solve (without describing the solution as part of the problem). I just tried to think of an example problem statement that requires this system but was unable to come up with one, which is why I'm struggling to understand the value of this being a standard. An example problem statement for a token standard (pre-ERC20) is:

I want to be able to build a smart wallet that can control any token the user desires, including future tokens that don't yet exist. The user needs to be able to transfer tokens into the wallet and out of the wallet without risk of the tokens being trapped in the wallet contract. Currently, each token has a slightly different API so it is not possible to build a wallet without designing it to support each token, and such a wallet would not support future tokens (with as of yet unknown APIs).

Note: Be prepared for me to offer alternative solutions to your problem statement that don't involve a standard. 😉

Contributor

MicahZoltu commented Oct 4, 2017

I understand that you want to keep the contents of the ERC "just the spec" but reading over all of the comments here I think the lack of a really clear problem statement and really clear and targeted solution is causing confusion. It sounds like there are several different interpretations of what this ERC is about in this discussion and everyone has a different image in their head as to what this will be used for.

@frozeman Can you provide a problem statement or user story as a starting point? Describe the problem that you are trying to solve (without describing the solution as part of the problem). I just tried to think of an example problem statement that requires this system but was unable to come up with one, which is why I'm struggling to understand the value of this being a standard. An example problem statement for a token standard (pre-ERC20) is:

I want to be able to build a smart wallet that can control any token the user desires, including future tokens that don't yet exist. The user needs to be able to transfer tokens into the wallet and out of the wallet without risk of the tokens being trapped in the wallet contract. Currently, each token has a slightly different API so it is not possible to build a wallet without designing it to support each token, and such a wallet would not support future tokens (with as of yet unknown APIs).

Note: Be prepared for me to offer alternative solutions to your problem statement that don't involve a standard. 😉

@frozeman

This comment has been minimized.

Show comment
Hide comment
@frozeman

frozeman Oct 4, 2017

Member

@jpitts thanks for sharing.
I would suggest coming up with a set of claimTypes and new standard additions can come up with new ones, that’s why it’s a uint256. We could also leave the type description out of here and make that a totally different standard.

URI makes sense, I will change that and also change it for a string for now.

@CDsigma your use case it exactly right, you can have people and institutions claiming things about you, and you can allow those claims attached to your identity. And yes; you can never verify an identity if you don’t verify claims about it.

@MicahZoltu I agree that it doesn’t seem to catch on right away what the use of this ERC is, though I brought already a few exmpakes which cover your points. But I can try to reformulate:

  • see KYC, currently everybody collects all information about you separately, to make sure they know who you are. E.g. banks, credit services, or any service which needs to have KYC. A standard will help in so far that everybody can auto check certain clams, and therefore don’t need to store your actually details about you anymore, as they - as long as they trust the claim issuer - don’t need to have the actual information. The current overcollecting is because of lack of a better system.
  • 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. Again the trust here is moved to the claim issuer, rather than the person want to prove something about themselves. In large th is can create complex trust graphs.

There are plenty more, and all come down to yourself wanting to prove something in front of others. And the claim model solves that: you can also take a look at https://sovrin.org/wp-content/uploads/2017/06/The-Inevitable-Rise-of-Self-Sovereign-Identity.pdf as they describe a similar system.

So in short the solution the ERC brings:

  1. I want to prove something
  2. Everybody can verify claims, as they know how and where to look - automatically.
  3. This can go as deep as it needs to reach a trusted claim issuer (jumping from issuer to issuer)
  4. Your identity can be taken to any interface which needs an identity, without creating a new one for every app.
  5. Smart contracts can verify claims automatically
  6. You can act outside of the Blockchain and third parties can check your identity on chain.

I am not aware of any system, which doesn’t require a central authority that allows to create a self sovereign identity. And I am unclear how this can be solved without a standard.

The token standard is quite the same. Everybody could have made their own tokens, but only by creating a standard we are able to use them anywhere, and with erc223 we will be able to have those tokens interact. And as you brought up ERC20 a lot, I assume you are aware that I proposed that standard.

Also for this standard, the target is not mainly the UIs, but other identities and smart contracts. Though UIs are as important, to be able to take your identity around.

Member

frozeman commented Oct 4, 2017

@jpitts thanks for sharing.
I would suggest coming up with a set of claimTypes and new standard additions can come up with new ones, that’s why it’s a uint256. We could also leave the type description out of here and make that a totally different standard.

URI makes sense, I will change that and also change it for a string for now.

@CDsigma your use case it exactly right, you can have people and institutions claiming things about you, and you can allow those claims attached to your identity. And yes; you can never verify an identity if you don’t verify claims about it.

@MicahZoltu I agree that it doesn’t seem to catch on right away what the use of this ERC is, though I brought already a few exmpakes which cover your points. But I can try to reformulate:

  • see KYC, currently everybody collects all information about you separately, to make sure they know who you are. E.g. banks, credit services, or any service which needs to have KYC. A standard will help in so far that everybody can auto check certain clams, and therefore don’t need to store your actually details about you anymore, as they - as long as they trust the claim issuer - don’t need to have the actual information. The current overcollecting is because of lack of a better system.
  • 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. Again the trust here is moved to the claim issuer, rather than the person want to prove something about themselves. In large th is can create complex trust graphs.

There are plenty more, and all come down to yourself wanting to prove something in front of others. And the claim model solves that: you can also take a look at https://sovrin.org/wp-content/uploads/2017/06/The-Inevitable-Rise-of-Self-Sovereign-Identity.pdf as they describe a similar system.

So in short the solution the ERC brings:

  1. I want to prove something
  2. Everybody can verify claims, as they know how and where to look - automatically.
  3. This can go as deep as it needs to reach a trusted claim issuer (jumping from issuer to issuer)
  4. Your identity can be taken to any interface which needs an identity, without creating a new one for every app.
  5. Smart contracts can verify claims automatically
  6. You can act outside of the Blockchain and third parties can check your identity on chain.

I am not aware of any system, which doesn’t require a central authority that allows to create a self sovereign identity. And I am unclear how this can be solved without a standard.

The token standard is quite the same. Everybody could have made their own tokens, but only by creating a standard we are able to use them anywhere, and with erc223 we will be able to have those tokens interact. And as you brought up ERC20 a lot, I assume you are aware that I proposed that standard.

Also for this standard, the target is not mainly the UIs, but other identities and smart contracts. Though UIs are as important, to be able to take your identity around.

@oed

This comment has been minimized.

Show comment
Hide comment
@oed

oed Oct 4, 2017

@frozeman
Sorry I think I missunderstood what you are trying to do. Let me see if I understand correctly now.
Transaction execution: So this is more something along the lines of an identitfier for an identity that you can attach accounts to? It would mostly be used to attach claims to and send claims from. Uport are trying to come up with something similar, but without relying as much on on-chain logic to do so. Check out the work of the Decentralized Identity Foundation, in particular the DID spec which uport will be compatible with.

Claim storage: So this will be kind of like a personal registry of claims associated with your identity? If it's only meta data that is being stored on-chain, where would the claim itself be stored?

Right now claims are stored off-chain by the users themself in uport. One of the main reason for putting a claim on-chain would be if it needs to be verified by a smart contract. The smart contract is likely to want to know something about a particular account that it is interacting with, rather than the identity itself. Having the claims in a separate registry makes it possible to make claims on any kind of account. Not just this very specific identity contract. This opens upp for the possiblitity of proving something about an account with a zkp without revelaing which identity owns that account.

As for your two main reasons for keeping it in the identity contract:

  1. I don't really see a problem of having to look at another contract, as long as it's standardized, maybe accessable from a ENS record? Complex automated auth will still be very much possible.
  2. The end user will not know or care about how many contracts are involved. The end user will likely not even know what a smart contract is. The registry would of course be designed so it can be interacted with in a trust-less way.

This being said I can see some benefits of putting claims in an identity contract, but for the reasons I stated above I don't think that's the way to go.

Btw, you should also check out the work being done on verifiable claims

oed commented Oct 4, 2017

@frozeman
Sorry I think I missunderstood what you are trying to do. Let me see if I understand correctly now.
Transaction execution: So this is more something along the lines of an identitfier for an identity that you can attach accounts to? It would mostly be used to attach claims to and send claims from. Uport are trying to come up with something similar, but without relying as much on on-chain logic to do so. Check out the work of the Decentralized Identity Foundation, in particular the DID spec which uport will be compatible with.

Claim storage: So this will be kind of like a personal registry of claims associated with your identity? If it's only meta data that is being stored on-chain, where would the claim itself be stored?

Right now claims are stored off-chain by the users themself in uport. One of the main reason for putting a claim on-chain would be if it needs to be verified by a smart contract. The smart contract is likely to want to know something about a particular account that it is interacting with, rather than the identity itself. Having the claims in a separate registry makes it possible to make claims on any kind of account. Not just this very specific identity contract. This opens upp for the possiblitity of proving something about an account with a zkp without revelaing which identity owns that account.

As for your two main reasons for keeping it in the identity contract:

  1. I don't really see a problem of having to look at another contract, as long as it's standardized, maybe accessable from a ENS record? Complex automated auth will still be very much possible.
  2. The end user will not know or care about how many contracts are involved. The end user will likely not even know what a smart contract is. The registry would of course be designed so it can be interacted with in a trust-less way.

This being said I can see some benefits of putting claims in an identity contract, but for the reasons I stated above I don't think that's the way to go.

Btw, you should also check out the work being done on verifiable claims

@frozeman

This comment has been minimized.

Show comment
Hide comment
@frozeman

frozeman Oct 4, 2017

Member

@oed thanks for the links, that looks very interesting and is very similar to what i am trying to do here as well, but with a purely on chain logic. What i can see every body in this space has come up with, is attributes, or claims and keys as actors. Same as me.

Let me try to break down the contract:

-> keys: public keys, or other owned smart contract address, which can interact in your name

- keys are there to prove identity ownership
- keys can hold money and act on the blockchain, and can be traced back to this identity
- smart contracts owned by this identity can be extension systems to the identity, e.g. reputation systems

-> execute: A function to allow this identity to act directly on other smart contracts, to be an actor "on-chain", including holding and transfer of ether.

-> claims: can be added by others, and verified by others. The claim content is stored off-chain, or onchain, but this is not defined here. Important is that the claim has to a have a proofable piece (which here is the signature) and a link to the claim, as well as the issuer.

- claims can requested to be added by anyone.
- claims can only be approved to be added by the owner of this identity
- claims can be removed at any time by the owner of this identity
- claims can be altered by the issuer, punishment would be removal (OR we add approval from the owner as well)

To compare that to the DID, its similar, just that its all in a smart contract and verifiable on chain.

To compare that with the W3C verifiable claims, its basically the same, though we can try to align them even more.

Also to be clear this is not standardising how claims can look like, how the content is stored, or where. Claims can easily be DDOs for example stored on IPFS. Also how identity verifications are handled off chain, e.g how the message will look like when signing off chain and including your identity address on chain. So there is a lot of defining necessary. This ERC mainly should give a very slick framework to put all those claims and claimtypes and keys inside.

Concerning the registry and the identity object (DID vs. DDOs), there can sure be a registry on top which holds the addresses of many identity contracts, e.g. governments could this way group citizens etc. but i don't see a need for that in the basic identity spec.

I am open for a call, to discuss that in person, as i see some misconceptions, or i myself have some.

Member

frozeman commented Oct 4, 2017

@oed thanks for the links, that looks very interesting and is very similar to what i am trying to do here as well, but with a purely on chain logic. What i can see every body in this space has come up with, is attributes, or claims and keys as actors. Same as me.

Let me try to break down the contract:

-> keys: public keys, or other owned smart contract address, which can interact in your name

- keys are there to prove identity ownership
- keys can hold money and act on the blockchain, and can be traced back to this identity
- smart contracts owned by this identity can be extension systems to the identity, e.g. reputation systems

-> execute: A function to allow this identity to act directly on other smart contracts, to be an actor "on-chain", including holding and transfer of ether.

-> claims: can be added by others, and verified by others. The claim content is stored off-chain, or onchain, but this is not defined here. Important is that the claim has to a have a proofable piece (which here is the signature) and a link to the claim, as well as the issuer.

- claims can requested to be added by anyone.
- claims can only be approved to be added by the owner of this identity
- claims can be removed at any time by the owner of this identity
- claims can be altered by the issuer, punishment would be removal (OR we add approval from the owner as well)

To compare that to the DID, its similar, just that its all in a smart contract and verifiable on chain.

To compare that with the W3C verifiable claims, its basically the same, though we can try to align them even more.

Also to be clear this is not standardising how claims can look like, how the content is stored, or where. Claims can easily be DDOs for example stored on IPFS. Also how identity verifications are handled off chain, e.g how the message will look like when signing off chain and including your identity address on chain. So there is a lot of defining necessary. This ERC mainly should give a very slick framework to put all those claims and claimtypes and keys inside.

Concerning the registry and the identity object (DID vs. DDOs), there can sure be a registry on top which holds the addresses of many identity contracts, e.g. governments could this way group citizens etc. but i don't see a need for that in the basic identity spec.

I am open for a call, to discuss that in person, as i see some misconceptions, or i myself have some.

@lukehedger

This comment has been minimized.

Show comment
Hide comment
@lukehedger

lukehedger Oct 4, 2017

We've been researching and prototyping a solution for identity in the META Network for the last few months and make use of a lot of the same primitives in this proposal and other projects. Our current implementation uses the ENS to register a subdomain to an identity owner's public address, which resolves to a content-addressed object (eg. stored in Swarm, IPFS) where the identity's metadata (or claims) can be retrieved and verified against signatures on that data. This way we utilise an existing standard and minimise what is stored on-chain.

Given how much of an essential component identity is to a system or network, it would be great to see a flexible standard that developers could build on - we know first-hand how complex this can be! If it can incorporate/accommodate other efforts (like W3C standards) then all the better.

lukehedger commented Oct 4, 2017

We've been researching and prototyping a solution for identity in the META Network for the last few months and make use of a lot of the same primitives in this proposal and other projects. Our current implementation uses the ENS to register a subdomain to an identity owner's public address, which resolves to a content-addressed object (eg. stored in Swarm, IPFS) where the identity's metadata (or claims) can be retrieved and verified against signatures on that data. This way we utilise an existing standard and minimise what is stored on-chain.

Given how much of an essential component identity is to a system or network, it would be great to see a flexible standard that developers could build on - we know first-hand how complex this can be! If it can incorporate/accommodate other efforts (like W3C standards) then all the better.

@frozeman

This comment has been minimized.

Show comment
Hide comment
@frozeman

frozeman Oct 5, 2017

Member

@lukehedger looking forward to contributions.

I just had a fruitful in person discussion with @oed and we came upon with a few small alterations:

  • I removed the changeClaim, as addClaim will do the same, and SHOULD trigger already the approval process.
  • i added getKeyType function and getKeysByType, as well as getClaim and getClaimsByType to allow easy retrieval.
  • I added more key types 3: claim signer, 4: encryption key, which we can debate to change them or add more.
  • i added the bytes claim to the signature of the claim, so that it can't be altered by the claim holder.
  • We were thinking how this idenities could be converted to DDOs (DID descriptor objects), see https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/draft-documents/DID-Spec-Implementers-Draft-01.pdf for examples of DDOs
  • We were talking if its best to move the claim holder part (Identity verification in the spec), to a separate spec, which this spec then inherits. The reasoning is that there can be claim holders, which aren't themselves identities. E.g. a smart contract about which a validity claim is issued.

It would be really good if work on the holder spec is done first, so that its a good basis, for #725. I will create an issue to discuss this spec part in the coming days.

Member

frozeman commented Oct 5, 2017

@lukehedger looking forward to contributions.

I just had a fruitful in person discussion with @oed and we came upon with a few small alterations:

  • I removed the changeClaim, as addClaim will do the same, and SHOULD trigger already the approval process.
  • i added getKeyType function and getKeysByType, as well as getClaim and getClaimsByType to allow easy retrieval.
  • I added more key types 3: claim signer, 4: encryption key, which we can debate to change them or add more.
  • i added the bytes claim to the signature of the claim, so that it can't be altered by the claim holder.
  • We were thinking how this idenities could be converted to DDOs (DID descriptor objects), see https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/draft-documents/DID-Spec-Implementers-Draft-01.pdf for examples of DDOs
  • We were talking if its best to move the claim holder part (Identity verification in the spec), to a separate spec, which this spec then inherits. The reasoning is that there can be claim holders, which aren't themselves identities. E.g. a smart contract about which a validity claim is issued.

It would be really good if work on the holder spec is done first, so that its a good basis, for #725. I will create an issue to discuss this spec part in the coming days.

@m-schmoock

This comment has been minimized.

Show comment
Hide comment
@m-schmoock

m-schmoock Oct 5, 2017

@frozeman
I like the proposal, also, as already pointed out in this discussion, I would see the need to define a standard set of claimTypes. This can be done by defining a low-range of well known types: i.e. 0 - arbitrary_number also to be defined in this ERC). As the number 256 Bit number is big enough, we could also think about using a bit-mask to organize topics and sub-types or even claim multiple types as once... just a thought.

I also think some details are missing regarding the claim (bytes) storage and access.

... Also a question for a better undestanding:
Regarding the approve function, can you hint out what do you mean by "Triggers on successfull claim addition Event"

Does it mean that if the approve was called by the identity itself or a type 1/2 key, the approve function is automatically called by the Contract, as a self verified claims do not need to be approved? If so, please point that out.

m-schmoock commented Oct 5, 2017

@frozeman
I like the proposal, also, as already pointed out in this discussion, I would see the need to define a standard set of claimTypes. This can be done by defining a low-range of well known types: i.e. 0 - arbitrary_number also to be defined in this ERC). As the number 256 Bit number is big enough, we could also think about using a bit-mask to organize topics and sub-types or even claim multiple types as once... just a thought.

I also think some details are missing regarding the claim (bytes) storage and access.

... Also a question for a better undestanding:
Regarding the approve function, can you hint out what do you mean by "Triggers on successfull claim addition Event"

Does it mean that if the approve was called by the identity itself or a type 1/2 key, the approve function is automatically called by the Contract, as a self verified claims do not need to be approved? If so, please point that out.

@juliosantos

This comment has been minimized.

Show comment
Hide comment
@juliosantos

juliosantos Jun 20, 2018

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.

juliosantos commented Jun 20, 2018

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

This comment has been minimized.

Show comment
Hide comment
@jllaw

jllaw Jun 23, 2018

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

jllaw commented Jun 23, 2018

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

This comment has been minimized.

Show comment
Hide comment
@frozeman

frozeman Jun 27, 2018

Member

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

Member

frozeman commented Jun 27, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@juliosantos

juliosantos Jun 27, 2018

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

juliosantos commented Jun 27, 2018

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

@cbruguera

This comment has been minimized.

Show comment
Hide comment
@cbruguera

cbruguera Jul 2, 2018

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

cbruguera commented Jul 2, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@nick

nick Jul 2, 2018

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

nick commented Jul 2, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@conejoninja

conejoninja Jul 2, 2018

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?

conejoninja commented Jul 2, 2018

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

This comment has been minimized.

Show comment
Hide comment
@nick

nick Jul 2, 2018

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.

nick commented Jul 2, 2018

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

This comment has been minimized.

Show comment
Hide comment
@conejoninja

conejoninja Jul 2, 2018

@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

conejoninja commented Jul 2, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@jllaw

jllaw Jul 3, 2018

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?

jllaw commented Jul 3, 2018

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

This comment has been minimized.

Show comment
Hide comment
@tyleryasaka

tyleryasaka Jul 3, 2018

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

tyleryasaka commented Jul 3, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@jllaw

jllaw Jul 3, 2018

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.

jllaw commented Jul 3, 2018

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

This comment has been minimized.

Show comment
Hide comment
@m-schmoock

m-schmoock Jul 4, 2018

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

m-schmoock commented Jul 4, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@jllaw

jllaw Jul 4, 2018

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

jllaw commented Jul 4, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@nathanawmk

nathanawmk Aug 9, 2018

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

Nathan Aw (Singapore)

nathanawmk commented Aug 9, 2018

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

Nathan Aw (Singapore)

@conejoninja

This comment has been minimized.

Show comment
Hide comment
@conejoninja

conejoninja commented Aug 9, 2018

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

@m-schmoock

This comment has been minimized.

Show comment
Hide comment
@m-schmoock

m-schmoock Aug 9, 2018

@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                                                
   })

m-schmoock commented Aug 9, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@nathanawmk

nathanawmk Aug 31, 2018

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 w3c-ccg/did-spec#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

nathanawmk commented Aug 31, 2018

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 w3c-ccg/did-spec#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

This comment has been minimized.

Show comment
Hide comment
@frozeman

frozeman Aug 31, 2018

Member
Member

frozeman commented Aug 31, 2018

@nathanawmk

This comment has been minimized.

Show comment
Hide comment
@nathanawmk

nathanawmk Aug 31, 2018

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 commented Aug 31, 2018

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

This comment has been minimized.

Show comment
Hide comment
@nathanawmk

nathanawmk Aug 31, 2018

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 commented Aug 31, 2018

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

This comment has been minimized.

Show comment
Hide comment
@nathanawmk

nathanawmk Sep 3, 2018

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

nathanawmk commented Sep 3, 2018

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

This comment has been minimized.

Show comment
Hide comment
@drewstone

drewstone Sep 12, 2018

@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?

drewstone commented Sep 12, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@tyleryasaka

tyleryasaka Sep 12, 2018

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

tyleryasaka commented Sep 12, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@kameir

kameir Sep 13, 2018

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

kameir commented Sep 13, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment