Ethereum Verifiable Claims

[pelle]

Simple Summary

Reuseable Verifiable Claims using EIP 712 Signed Typed Data.

Abstract

A new method for Off-Chain Verifiable Claims built on EIP 712. These Claims can be issued by any user with a EIP 712 compatible web3 provider. Claims can be stored off chain and verified on-chain by Solidity Smart Contracts, State Channel Implementations or off-chain libraries.

Motivation

Reusable Off-Chain Verifiable Claims provide an important piece of integrating smart contracts with real world organizational requirements such as meeting regulatory requirements such as KYC, GDPR, Accredited Investor rules etc.

ERC 735 and ERC 780 provide methods of making claims that live on chain. This is useful for some particular use cases, where some claim about an address must be verified on chain.

In most cases, though it is both dangerous and in some cases illegal (according to EU GDPR rules for example) to record Identity Claims containing Personal Identifying Information (PII) on an immutable public database such as the Ethereum blockchain.

The W3C Verifiable Claims Data Model and Representations as well as uPorts Verification Message Spec are proposed off-chain solutions.

While built on industry standards such as JSON-LD and JWT neither of them are easy to integrate with the Ethereum ecosystem.

EIP 712 introduces a new method of signing off chain Identity data. This provides both a data format based on Solidity ABI encoding that can easily be parsed on-chain an a new JSON-RPC call that is easily supported by existing Ethereum wallets and Web3 clients.

This format allows reusable off-chain Verifiable Claims to be cheaply issued to users, who can present them when needed.

[mrtomnguyen]

is there an updated ERC for this yet?

[ipatka]

This is a cool way to validate Verifiable Claims from within a smart contract. Thanks for including the warnings regarding GDPR on the value and hash claims. I don’t see a use case where you could legally use those except maybe a private side chain.

The binary claims seem very useful though. ‘KYC verified’, ‘Located in country X’, etc. Not sure how detailed the binary claims can get until you’re back into GDPR territory though.

[ipatka]

For revocation the claim should probably include the address of the revocation registry the verified should use to check for revocation. There will probably be multiple revocation registries deployed so the issuer should declare which one they will use up front.

[nicksavers]

@pelle Could you add the Solidity version for the implementation examples?

[mrtomnguyen]

This is a cool way to validate Verifiable Claims from within a smart contract. Thanks for including the warnings regarding GDPR on the value and hash claims. I don’t see a use case where you could legally use those except maybe a private side chain.

The binary claims seem very useful though. ‘KYC verified’, ‘Located in country X’, etc. Not sure how detailed the binary claims can get until you’re back into GDPR territory though.

agreed with the on-chain true/false claims as systems become more Decentralized with more Smart Contracts interactions. Off-chain verifications will have intermediary etc. I've been back and forth on this one too related to GDPR. Perhaps a new DID created for each on-chain claims to make it harder for correlation? in the end, the Person has to make this decision and GDPR has no say in that if it's self-sovereign and decentralized right?

[ipatka]

Yes I think single use keys or dids would help a lot with preventing correlation attacks.

Self sovereign identity & GDPR is definitely tricky. One could argue the issuer of the claim has to comply with ‘right to be forgotten’ requests. If they issue a claim on chain in plaintext they are probably not compliant. But if they issue a claim off chain and the subject of the verification submits it on chain somehow it may be ok.

[mrtomnguyen]

Yes I think single use keys or dids would help a lot with preventing correlation attacks.

Self sovereign identity & GDPR is definitely tricky. One could argue the issuer of the claim has to comply with ‘right to be forgotten’ requests. If they issue a claim on chain in plaintext they are probably not compliant. But if they issue a claim off chain and the subject of the verification submits it on chain somehow it may be ok.

forgot to mention ZkSnarks to mitigate binary on-chain claims. this could work.
on the issue of "right to be forgotten", I have not seen an "Erasure Registry" for Person revoking use / demanding erasure from a Service eg. I quit Facebook. any plan for this?

[dltxio]

Seems to be alot of synergy with my EIP 1753 https://github.com/ethereum/EIPs/blob/fa8855c9fe6dffd209ab53bb4c425f7703ca288f/EIPS/eip-1753.md