ERC-1757: Reputation Mechanism to Claim Issuers

[yujisuga]

eip: 1757
title: ERC: Reputation Mechanism to Claim Issuers
author: Yuji Suga (@yujisuga)
discussions-to: to-be-assigned
status: Discussion
type: Standard
category: ERC
created: 2019-02-17
requires: ERC725, ERC735

Simple Summary

A proposal of reputation mechanism to evaluate claim issuers.

Abstract

This specification defines a profile for ERC735.Claim.data. A proposal enables detections of fake claim issuers via reputation system in identity verification (via ERC725 and ERC735) context.

Motivation

The claim format defined in ERC735 and the mechanism of Identity verification defined in ERC725 made it possible to bind any attributes and qualified information to the entity identified by Ethereum address. For example there is a demonstration website that can be associated with various SNS accounts based on identity verification process using OAuth. ERC735-claims can distribute by themselves, and as long as the Ethereum network is operating with blockchain technology, the certainty of the information written within claims are guaranteed semipermanently. However, because the claim issuers could be anyone, claims can be issued by public agencies, on the other hand claims are also issued from fake organizations with similar organization names. Although it is possible to solve this problem by operating a registrar agency based on the idea of centralization, this direction may be a contradiction to the blockchain community. Therefore, we propose a reputation mechanism of evaluate claim issuers.

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. A claim includes topic, scheme, issuer, signature, data and uri. data has the hash of the claim data, sitting in another location, a bit-mask, call data, or actual data based on the claim scheme. Note that uri is NOT to be signed data. For details about claims see #ERC735

Specification

Reputation Holder

reputation structure

struct Reputation {
    address toBeEvaluated; // a reputator evaluate `toBeEvaluated`.
    uint256 repValue; // 0 worst ... 255 best, 128 is the medium.
    string uri; // optional. uri is the evidence of repValue.
}

addReputation

Requests the ADDITION of a reputation from an issuer of genarator of ERC735.Claim.
Reputations can requested to be added by anybody, however the reputation holder MUST NOT be issuer.

uri is optional. This specification recommend that uri SHOULD be a pointer of an issued claim by the entity toBeEvaluated.

Reptation IDs are generated using keccak256(address toBeEvaluated + uint256 repValue + string uri).

function addClaim(address _toBeEvaluated, uint256 repValue, string _uri) returns (uint256 repId)

Note that the operations such as get, remove, getID, searchByID are NOT defined, because ERC735 defined such kind of operations including getClaim, ClaimRemoved getClaimIdsByTopic, so only addClaim is defined in this specification. Reputation strucure is used as the data ERC735.Claim.data.

Events

ReputationAdded

MUST be triggered when a reputation was successfully added.

event ReputationAdded(bytes32 indexed repId, address indexed issuer, uint256 repValue, string uri)

Solidity Interface

pragma solidity ^0.4.18;

contract ERC1757 {

    event ReputationAdded(bytes32 indexed repId, address indexed issuer, uint256 repValue, string uri);

    struct Reputation {
        address toBeEvaluated;  // a reputator evaluates `toBeEvaluated`.
        uint256 repValue; // 0 worst ... 255 best, 128 is the medium.
        string uri; // optional. uri is the evidence of repValue.
    }

    function addReputation(address toBeEvaluated, uint256 repValue, string uri) public returns (uint256 repRequestId);

}

Additional References

• Slides of the ERC Identity presentation
• ERC 725 Demo implementation by ORIGIN
• A Next-Generation Smart Contract and Decentralized Application Platform
• The GNU Privacy Handbook: Validating other keys on your public keyring

Copyright

Copyright and related rights waived via CC0.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.