ERC1386 - Managing issuers of cryptographic attestations

[bitcoinwarrior1]

Introduction

Very often, we will need to use Attestations like "Alice lives in Australia" on the blockchain; that is issued by a valid issuer off chain for privacy reasons and is revokable inside a smart contract.

An issuer can create a smart contract where he revokes multiple attestations in one go by building a bloom filter of all the hashes of the revoked attestations.

An issuer can also put the validation method in their smart contract that can be called by other smart contracts who need to validate attestations issued by them. This allows each attestor to update their attestation format separately.

Purpose

This ERC provides an interface for attestation issuers to manage their attestation signing keys and the attestations that are issued off chain for actions such as revocation and validation.

In our draft implementation we include functions to hold cryptographic attestations, change the issuing contracts of attestations, revoke attestations and verify the authenticity of a cryptographic attestation.

Example use cases

Let's say that our friend, Alice, wants to buy a bottle of wine to consume with her friends. She wants to do the order online and have it delivered to her home address whilst paying for it with Ether.

Alice has a cryptographic attestation from her local road and maritime services who attests to her age, date of birth, country of residence and ability to drive.

Alice is able to split up this attestation (see merkle tree attestations ERC here) and provides only the leaf that states she is over the age of 21.

Alice goes to buy the wine through the wine vendors smart contract and feeds in the merkle tree attestation proving that she is above 21 and can thus buy the wine, whilst attaching the appropriate amount of ether to complete the purchase.

The issuer smart contract is able to validate her attestation, check that the issuer contract is valid and capable of performing such an attestation to her age. In this case it would have to be from someone like a driver's licence authority, as attestations to age from a school ID are not of a high enough capacity.

The wine vendors smart contract validates the attestation, checks the payment amount is correct and credits Alice with the wine tokens she needs to complete the sale and deliver the wine.

When the wine vendor shows up to her apartment with the wine, there is no need to prove her age again.

Draft interface

/* each attestation issuer should provide their own verify() for the
 * attestations they issued. There are two reasons for this. First, we
 * need to leave room for new attestation methods other than the
 * Merkle Tree format we are recommending. Second, the validity of the
 * attestation may depend on the context that only the attestor
 * knows. For example, a ticket as an attestation issued on a
 * successful redemption of an American Express credit */

contract Issuer {
  struct Attestation
    {
        bytes32[] merklePath;
        bool valid;
        uint8 v;
        bytes32 r;
        bytes32 s;
        address attestor;
        address recipient;
        bytes32 salt;
        bytes32 key;
        bytes32 val;
    }`
  /* Verify the authenticity of an attestation */
  function verify(Attestation attestation);
  function addattestorKey(address newAttestor, string capacity, uint expiry);

  /* this should call the revoke first */
  function replaceKey(address attestorToReplace, string capacity, uint expiry, address newAttestor);

  /* this revokes a single key */
  function removeKey(address attestor);

  /* if the key exists with such capacity and isn't revoked or expired */
  function validateKey(address attestor, string capacity) returns (bool);

  /* revoke an attestation by replace the bloom filter, this helps preserve privacy */
  function revokeAttestations(Bloomfilter b);

}

Please click here to see a draft implementation of this interface

Related ERC's

#1388 #1387

[axic]

@James-Sangalli this EIP doesn't have a copyright statement. Can you please add one? EIP-1 suggests CC0 - see the eip-x.md template.

[xinbenlv]

Could you elaborate its relationship with EIP-735 (#735), EIP-734(#734)?

[bitcoinwarrior1]

@xinbenlv we have similar goals but differ on implementation. We firmly believe that privacy should be preserved with the use of a salted merkle tree which enables you to reveal a small piece of that claim without revealing anything else e.g. I am above 18 rather than giving away your passport.

Furthermore, salted merkle trees enable link-ability to the original source, e.g. Australian drivers licence -> DOB -> above 18 true/false. Many claim checkers will require that the source be something solid, like a government issued ID, rather than a looser form. Many authorities provide both solid and weak forms of identity so there needs to be a linkable source to verify this.

We are not actively working on this EIP right now due to other priorities and it may be a while since we look at it again.

[xinbenlv]

Thanks.

we have similar goals but differ on implementation.

I'd suggest adding reference to mention them

We are not actively working on this EIP right now

I think we can mark this EIP as "Deferred" then?

Furthermore, salted merkle trees enable link-ability to the original source

Link-ability -> One-way link-ability, right? I like this idea.

[bitcoinwarrior1]

Thanks.

we have similar goals but differ on implementation.

I'd suggest adding reference to mention them

Ok, but you mean just in the eip doc itself?

We are not actively working on this EIP right now

I think we can mark this EIP as "Deferred" then?

Probably should, let me get back to you on that.

Furthermore, salted merkle trees enable link-ability to the original source

Link-ability -> One-way link-ability, right? I like this idea.

Basically yes. The idea being one salted merkle for each claim e.g. age above or located in a particular state.

That way it is impossible to do a dictionary attack and privacy is preserved as only the relevant attribute is exposed.

I think that we are a long way away til this becomes an industrial standard but one day I hope to see smart contracts which allow you to, for example, participate in an ICO by proving your residency/citizenship. It will allow for a much smoother and integrity preserving process.

[xinbenlv]

Ok, but you mean just in the eip doc itself?

Yes, for an EIP to be proposed, it's ideal that it reference and discuss previous related work just like a typical academic paper Background section / or at least in a Reference section. It shall discuss one of the reason why this EIP is not a duplicate and a valuable one to stay: such as

• why this EIP different from the previous EIP, if addressing different scope
• why this EIP take the different approach, if same problem but different approach, rationale
• why this EIP improves from or based at the previous EIP

That way it is impossible to do a dictionary attack and privacy is preserved as only the relevant attribute is exposed.

I like it. This seems to be discussed in #735 (comment) and not being addressed by #735. so I think your idea is good. Kudos~

[axic]

@James-Sangalli this EIP doesn't have a copyright statement. Can you please add one? EIP-1 suggests CC0 - see the eip-x.md template.

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