# New Work Item Proposal

See [W3C-CCG New Work Item Process](https://w3c-ccg.github.io/workitem-process/)

## Include Link to Abstract or Draft

## 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)

Other owners:
- Wayne Chang (Spruce)
- Mircea Nistor (ConsenSys Mesh)
- Charles E. Lehner (Spruce)

## 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](https://eips.ethereum.org/EIPS/eip-712) 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](https://eips.ethereum.org/EIPS/eip-712). 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.**