[PROPOSED WORK ITEM] Eip712Signature2021

[awoie]

New Work Item Proposal

See W3C-CCG New Work Item Process

Include Link to Abstract or Draft

• https://uport-project.github.io/ethereum-eip712-signature-2021-spec/
• https://github.com/uport-project/ethereum-eip712-signature-2021-spec/

Describes an Ethereum EIP712 Signature Suite created in 2021 for the Linked Data Proof specification. The Signature Suite utilizes EIP712 signatures.

List Owners

Identify 1 lead (person responsible for advancing the work item) and at least 1 other owner. Ideally, include their github usernames

Lead:

• Oliver Terbu (ConsenSys Mesh), @awoie

Other owners:

• Wayne Chang (Spruce), @wyc
• Mircea Nistor (ConsenSys Mesh), @mirceanis
• Charles E. Lehner (Spruce), @clehner

Work Item Questions

Answer the following questions in order to document how you are meeting the requirements for a new work item at the W3C Credentials Community Group. Please note if this work item supports the Silicon Valley Innovation program or another government or private sector project.

1. Explain what you are trying to do using no jargon or acronyms.

General goal is to foster SSI adoption. Ethereum wallets are used by a large community, e.g., >5M MetaMask users. Ethereum wallets are different from SSI wallets, but they can be used for secure key management and expose certain JSON RPC APIs.

A typial flow is, a wallet injects as certain JS object (web3 provider) into the DOM tree, and the website invokes JSON RPC calls on that object. The object can be implemented in various ways without vendor lock-in.

Changing JSON RPC APIs of Ethereum wallets would require a lot of work and is not an option. However, Ethereum wallets implement EIP712 which is a way to sign over human-readable data.

The idea is to use Ethereum wallets for signing LD-Proofs using the signature algorithm that is proposed in EIP712. The signature algorithm is based on Secp256k1 but requires some data transformation. For this reason, exisintg LD-Proof Suites cannot be used. This proposal is about introducing a new LD-Proof Suite that allows Ethereum wallets to sign over human-readable data through EIP712.

Those LD-Proofs can then be used for ZCap-LD, Verifiable Credentials and Presentations. Verifiers won't necessarily need access to Ethereum to verify those signatures.

2. How is it done today, and what are the limits of the current practice?

Today, SSI wallet implementations require either an internal KMS or an external KMS (hosted as a service). For fully backend-less applications, access to external KMS' might not be an option. Some applications, e.g., decentralized applications with no backend (e.g., in the browser) don't have access to a secure data (key) storage. External KMS' also introduce an adoption barrier in certain communities.

Ethereum Wallets are in production and are available to address those needs for a larger community.

3. What is new in your approach and why do you think it will be successful?

Ethereum wallets will be able issue and present Verifiable Credentials, create ZCaps or more generally, sign over human-readable data that is compatible with the W3C (CCG) specification stack.

NOTE: for those people who use DIDs, there is no requirement for a certain DID method.

[wyc]

I'd like to sign up as a co-owner of this work item if that's okay @awoie. I will therefore recuse myself of evaluating the merits of this work item and defer to @vsnt. Thanks!

[msporny]

Digital Bazaar is supportive of this work item for at least the following reasons:

• It's a well-written preliminary/draft specification.
• It chooses a non-RDF Canonicalization mechanism (JCS).
• It uses Keccak-256 and ECDSA K-256 as digest and signing functions.
• It has useful test vectors.

In short, it's a model specification that innovates on top of the Linked Data Signature work in interesting ways.

[awoie]

I'd like to sign up as a co-owner of this work item if that's okay @awoie. I will therefore recuse myself of evaluating the merits of this work item and defer to @vsnt. Thanks!

Happy to make you a co-owner @wyc

[vsnt]

Sounds like an interesting project. @wyc can you add it to the CCG agenda for Tuesday for discussion, community feedback and next steps? Thanks.

[wyc]

Sure thing, will do.

[wyc]

@vsnt are we okay to proceed with this work item? Can open an issue to add an informative README to the new repo.

[clehner]

Spruce is implementing this signature suite in Rust: spruceid/ssi#213

[vsnt]

Ok to proceed, please include detailed information in a readme, as requested in the CCG call.

[wyc]

Opened https://github.com/w3c-ccg/ethereum-eip712-signature-2021-spec with related issues including README update, added to registry on the community page via #199.

[wyc]

Reopening to communicate to everyone the series of non-material actions here:

• @clehner asked @mirceanis if a transfer of the repository was more appropriate vs. a clone, as is the case today.
• @mirceanis agreed, and is ready to transfer.
• I will rename the repo ethereum-eip712-signature-2021-spec to ethereum-eip712-signature-2021-spec-old
• Accept the transfer of the repository with the same name, and archive it after the transfer.
• Move over old issues to the newly imported repo.

[wyc]

This has been completed.