User communication concepts and naming

ricardo3 · April 23, 2019, 3:49pm

StatusAccount indeed is not really explainful, and actually those accounts are all user-owned, they are standard ethereum identities.

What you could have is “Status-compatible Public Profile” or other derivates, however the Account which controls this public profile is not related to Status. StatusIM only provide the interface to certain standards.

ricardo3 · April 23, 2019, 3:49pm

Our main privacy concern is that we use the wallet key to directly derive the chat identity as the wallet public key.
As feature and privacy concern we have that any chat identity can derive the wallet of user.

We had the discussion of having one identity per dapp, this might be done with Identity, which new dapps could have its own key to access funds from an Self Sovereign Identity. This still don’t fixes privacy, as we always need to fund the key from somewhere.

For Dapps which don’t require inchain transactions, but requires an Identity, it would be possible to add the dapp-specific public key hashed in keccak256 listed in the Self Sovereign Identity.
As example, Status Chat could read a message signed from a key, and this message could contain in its payload the user-public-identity, where clients could query in the smart contract to check if key is listed as a key. For Messages that pay the network, this key could be allowed to sign payments.

Currently most of in-chain actions are “pull based”, users pull the transaction to queue and incentivize the mining by posting a gas fee. With Identity contract it’s possible to have a “push based”, where transactions are authorized in a smart contract action key, which could control subscription rules.
Instead of using a regular external owned account as key, the User would set an smart contract as key, which would contain the rules for the subscription, where subscriber could push funds based on those rules.

ricardo3 · April 23, 2019, 5:02pm

We also need to define a standard way of displaying Identities. There is a proposal of standard here Feedback on "ETH Avatar Standard" Direction · Issue #928 · ethereum/EIPs · GitHub

We can propose our own standard, but what is important is that in all Status related stuff this is coherent. I’m doing some experiments in how to display addresses data in a more human way, such as using colors.

This should build an “Identity Input” component, which could support both public key or address, but might require public key in some cases (Contact Code needs full public key, transactions only need address).
Within this Identity Input we can also support universally the ENS resolver, and public avatars, such as suggested in ERC 928.
Identity Component would intelligently query the Identity for needed information regarding the it’s value, where if it’s a contract, it could support ERC780, former ERC725 and ERC735 ABI to badge with known claims/signers, e.g. Status GMBH badge/unbadge addresses to get a “support team”, “core dev”, “etc” badges to some identities which are “certified as trustful” to the badge they hold.

github.com/ethereum/EIPs

ERC: Claim Holder

opened 10:53AM - 09 Oct 17 UTC

closed 09:11AM - 16 Jan 22 UTC

frozeman

stale

``` EIP: 735 Title: Claim Holder Author: Fabian Vogelsteller (@frozeman) Typ…e: Standard Category: ERC Status: Discussion Created: 2017-10-09 ``` **NOTE: Due to the changes in [ERC725](https://github.com/ethereum/EIPs/issues/725), this spec is not fully compatible with the current ERC725v2. If you're interested in adopting this spec to work with 725v2, please comment below, or send a gist with changes.** # Abstract The following describes standard functions for adding, removing and holding of claims. These claims can attested from third parties (issuers) or self attested. # Motivation This standardised claim holder interface will allow Dapps and smart contracts to check the claims about a claim holder. Trust is here transfered to the issuers of claims. # Definitions - `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`: A claim is an information an issuer has about the identity holder. This contains the following: - `topic`: A `uint256` number which represents the topic of the claim. (e.g. 1 biometric, 2 residence (ToBeDefined: number schemes, sub topics based on number ranges??)) - `scheme `: The scheme with which this claim SHOULD be verified or how it should be processed. Its a `uint256` for different schemes. E.g. could `3` mean contract verification, where the `data` will be call data, and the `issuer` a contract address to call (ToBeDefined). Those can also mean different key types e.g. 1 = ECDSA, 2 = RSA, etc. (ToBeDefined) - `issuer`: The issuers identity contract address, or the address used to sign the above signature. If an identity contract, it should hold the key with which the above message was signed, if the key is not present anymore, the claim SHOULD be treated as invalid. The issuer can also be a contract address itself, at which the claim can be verified using the call `data`. - `signature`: Signature which is the proof that the claim issuer issued a claim of `topic ` for this identity. it MUST be a signed message of the following structure: `keccak256(address identityHolder_address, uint256 _ topic, bytes data)` // or `keccak256(abi.encode(identityHolder_address, topic, data))` ? - `data`: The hash of the claim data, sitting in another location, a bit-mask, call data, or actual data based on the claim scheme. - `uri`: The location of the claim, this can be HTTP links, swarm hashes, IPFS hashes, and such. # Specification ## Claim Holder #### claim structure The claims issued to the identity. Returns the claim properties. ``` js struct Claim { uint256 topic; uint256 scheme; address issuer; // msg.sender bytes signature; // this.address + topic + data bytes data; string uri; } ``` #### getClaim Returns a claim by ID. ```js function getClaim(bytes32 _claimId) constant returns(uint256 topic, uint256 scheme, address issuer, bytes signature, bytes data, string uri); ``` #### getClaimIdsByTopic Returns an array of claim IDs by topic. ```js function getClaimIdsByTopic(uint256 _topic) constant returns(bytes32[] claimIds); ``` #### addClaim Requests the ADDITION or the CHANGE of a claim from an `issuer`. Claims can requested to be added by anybody, including the claim holder itself (self issued). `_signature` is a signed message of the following structure: `keccak256(address identityHolder_address, uint256 topic, bytes data)`. Claim IDs are generated using `keccak256(address issuer_address + uint256 topic)`. This COULD implement an approval process for pending claims, or add them right away. Possible claim topics: - `1`: Biometric data - `2`: Permanent address (TODO: add more in the initial standard? `3`: Claim registry?) **Returns `claimRequestId`:** COULD be send to the `approve` function, to approve or reject this claim. **Triggers if the claim is new Event and approval process exists:** [ClaimRequested](#claimrequested) **Triggers if the claim is new Event and is added:** [ClaimAdded](#claimadded) **Triggers if the claim index existed Event:** [ClaimChanged](#claimchanged) ``` js function addClaim(uint256 _topic, uint256 _scheme, address _issuer, bytes _signature, bytes _data, string _uri) returns (uint256 claimRequestId) ``` #### removeClaim Removes a claim. Can only be removed by the claim issuer, or the claim holder itself. Triggers Event: [ClaimRemoved](#claimremoved) ``` js function removeClaim(bytes32 _claimId) returns (bool success) ``` -------------------------------------------------------- ### Events #### ClaimRequested COULD be triggered when `addClaim` was successfully called. ``` js event ClaimRequested(uint256 indexed claimRequestId, uint256 indexed topic, uint256 scheme, address indexed issuer, bytes signature, bytes data, string uri) ``` #### ClaimAdded MUST be triggered when a claim was successfully added. ``` js event ClaimAdded(bytes32 indexed claimId, uint256 indexed topic, uint256 scheme, address indexed issuer, bytes signature, bytes data, string uri)) ``` #### ClaimRemoved MUST be triggered when `removeClaim` was successfully called. ``` js event ClaimRemoved(bytes32 indexed claimId, uint256 indexed topic, uint256 scheme, address indexed issuer, bytes signature, bytes data, string uri)) ``` #### ClaimChanged MUST be triggered when `changeClaim` was successfully called. ``` js event ClaimChanged(bytes32 indexed claimId, uint256 indexed topic, uint256 scheme, address indexed issuer, bytes signature, bytes data, string uri) ``` ## Solidity Interface ```js pragma solidity ^0.4.18; contract ERC735 { event ClaimRequested(uint256 indexed claimRequestId, uint256 indexed topic, uint256 scheme, address indexed issuer, bytes signature, bytes data, string uri); event ClaimAdded(bytes32 indexed claimId, uint256 indexed topic, uint256 scheme, address indexed issuer, bytes signature, bytes data, string uri); event ClaimRemoved(bytes32 indexed claimId, uint256 indexed topic, uint256 scheme, address indexed issuer, bytes signature, bytes data, string uri); event ClaimChanged(bytes32 indexed claimId, uint256 indexed topic, uint256 scheme, address indexed issuer, bytes signature, bytes data, string uri); struct Claim { uint256 topic; uint256 scheme; address issuer; // msg.sender bytes signature; // this.address + topic + data bytes data; string uri; } function getClaim(bytes32 _claimId) public constant returns(uint256 topic, uint256 scheme, address issuer, bytes signature, bytes data, string uri); function getClaimIdsByTopic(uint256 _ topic) public constant returns(bytes32[] claimIds); function addClaim(uint256 _topic, uint256 _scheme, address _issuer, bytes _signature, bytes _data, string _uri) public returns (uint256 claimRequestId); changeClaim(bytes32 _claimId, uint256 _topic, uint256 _scheme, address _issuer, bytes _signature, bytes _data, string _uri) returns (bool success); function removeClaim(bytes32 _claimId) public returns (bool success); } ``` ## Constraints - A claim can only be one per topic per issuer. ## Additional References - [Slides of the ERC Identity presentation](https://www.slideshare.net/FabianVogelsteller/erc-725-identity) - [W3C Verifiable Claims Use Cases](https://w3c.github.io/vc-use-cases/) - [Identity related reports](http://www.weboftrust.info/specs.html) - [Claim Holder Registry ERC780](https://github.com/ethereum/EIPs/issues/780)

github.com/ethereum/EIPs

ERC: Ethereum Claims Registry

opened 04:44PM - 29 Nov 17 UTC

closed 08:14AM - 02 Jan 22 UTC

oed

stale

``` EIP: <to be assigned> Title: ERC: Ethereum Claims Registry Author: Joel T…orstensson <[email protected]> Type: Standard Category: ERC Status: Discussion Created: 2017-11-29 ``` # Abstract This text describes a proposal for an **Ethereum Claims Registry** (**ECR**) which allows persons, smart contracts, and machines to issue claims about each other, as well as self issued claims. The registry provides a flexible approach for claims that makes no distinction between different types of Ethereum accounts. The goal of the registry is to provide a central point of reference for on-chain claims on Ethereum. # Motivation On-chain claims is becoming increasingly relevant as lots of different smart contracts might want to verify certain attributes about its users. However that is only one out of a very large space of use cases for on-chain claims. By providing a central repository for claims, developers are equipped with a common ground for experimentation. A standardized registry also makes claim lookup simple and gas efficient. Third party contracts only need to make one external call, no need for adding logic for verifying signatures, lookup identity signing keys, etc. # Specification The ECR is a contract that is deployed once and can then be commonly used by everyone. Therefore it's important that the code of the registry has been reviewed by lots of people with different use cases in mind. The ECR provides an interface for adding, getting, and removing claims. Claims are issued from an `issuer` to a `subject` with a `key`, which is of type ``bytes32``. The claims data is stored as type `bytes32`. ## Claim types The `key` parameter is used to indicate the type of claim that is being made. There are three ways that are encuraged for use in the ECR: * Standardised claim types use syntax borrowed from HTTP and do not start with `X-`. The key is the hash of the claim type (eg, `keccak256('Owner-Address')`) * Private types not intended for interchange use the same syntax, but with X- prefix. The key is the hash of the claim type (eg, `keccak256('X-My-Thing')`) * Ad-hoc types use 32 random bytes for the key, enabling allocation of new globally used keys without the need for standardisation first. ### Standard claim types New claim types can be added by making a PR to modify this table. | Claim type | Description | | -- | -- | | `ERC780Example` | This is an example | ## Registry specification The ECR provides the following functions: **setClaim** Used by an `issuer` to set the claim `value` with the `key` about the `subject`. ```js function setClaim(address subject, bytes32 key, bytes32 value) public; ``` **setSelfClaim** Convenience function for an `issuer` to set a claim about themself. ```js function setSelfClaim(bytes32 key, bytes32 value) public; ``` **getClaim** Used by anyone to get a specific claim. ```js function getClaim(address issuer, address subject, bytes32 key) public constant returns(bytes32); ``` **removeClaim** Used by an `issuer` to remove a claim it has made. ```js function removeClaim(address issuer, address subject, bytes32 key) public; ``` ### Type conversions The `value` parameter was choosen to have the type `bytes32`. This in order to make the registry entries as general as possible while maintaining a very simple code base. However it is likely that usecases where other types such as `address` and `uint` etc. will emerge. Support for this can be added in various ways. We suggest that a library is implemented that can covert between various solidity types. This means that the registry itself keeps its simplicity. Contracts that need specific types can use such a library to convert the `bytes32` into their desired type and back. ### Deployment After some discussion on the design of the registry contract it will be deployed and its address should be written in this document. This should include the addresses for the ropsten, rinkeby, and kovan testnets as well. ### Updates and governance In the future there might be new features needed in the registry. In order for such an event to be as transparent as possible the new features should be proposed and approved in a new EIP that contains the new contract code as well as a way of migrating any old claims if deemed necessary. ## Appendix: Registry implementation ```js contract EthereumClaimsRegistry { mapping(address => mapping(address => mapping(bytes32 => bytes32))) public registry; event ClaimSet( address indexed issuer, address indexed subject, bytes32 indexed key, bytes32 value, uint updatedAt); event ClaimRemoved( address indexed issuer, address indexed subject, bytes32 indexed key, uint removedAt); // create or update clams function setClaim(address subject, bytes32 key, bytes32 value) public { registry[msg.sender][subject][key] = value; emit ClaimSet(msg.sender, subject, key, value, now); } function setSelfClaim(bytes32 key, bytes32 value) public { setClaim(msg.sender, key, value); } function getClaim(address issuer, address subject, bytes32 key) public view returns(bytes32) { return registry[issuer][subject][key]; } function removeClaim(address issuer, address subject, bytes32 key) public { require(msg.sender == issuer); delete registry[issuer][subject][key]; emit ClaimRemoved(msg.sender, subject, key, now); } } ```