Add ERC: Tamperproof Web Immutable Transaction (TWIT) #585
Conversation
Signed-off-by: Guillaume Grosbois <[email protected]>
Change to RPC method, various edits
|
✅ All reviewers have approved. |
eip-review-bot
changed the title
ERCS/erc-XXXX.md
Outdated
| @@ -0,0 +1,254 @@ | |||
| --- | |||
| eip: XXXX | |||
There was a problem hiding this comment.
| eip: XXXX | |
| eip: 7754 |
Assigning next sequential EIP/ERC/RIP number.
Please also update the filename.
ERCS/erc-XXXX.md
Outdated
| title: Tamperproof Web Immutable Transaction (TWIT) | ||
| description: Provides a mechanism for DAP to use the API defined in EIP-1193 in a tamperproof way | ||
| author: Erik Marks, Guillaume Grosbois | ||
| discussions-to: TODO |
There was a problem hiding this comment.
Please create a topic in Eth Magicians. https://ethereum-magicians.org/
It can just contain a link to this PR.
Co-authored-by: Andrew B Coathup <[email protected]>
Signed-off-by: Guillaume Grosbois <[email protected]>
uni-guillaume
force-pushed
the
twit
branch
2 times, most recently
from
e4b9b2c
to
a16db1b
Compare
uni-guillaume
force-pushed
the
twit
branch
2 times, most recently
from
0997e19
to
8468f09
Compare
|
The commit 4467b47 (as a parent of 49b3f55) contains errors. |
Signed-off-by: Guillaume Grosbois <[email protected]>
|
@abcoathup @petvaizAkhtar : is the PR good enough to be merged ? |
ERCS/erc-7754.md
Outdated
|
|
||
| 1. The user's browser verifies the domain certificate and displays appropriate warnings if overtaken | ||
| 2. The DNS record of the dapp hosts a TXT field pointing to a URL where a JSON manifest is hosted | ||
| - This file SHOULD be at a well known address such as `https://domain.com/.well-known/twit.json` |
There was a problem hiding this comment.
| - This file SHOULD be at a well known address such as `https://domain.com/.well-known/twit.json` | |
| - This file SHOULD be at a well known address such as `https://example.com/.well-known/twit.json` |
ERCS/erc-7754.md
Outdated
|
|
||
| Attested public keys are necessary for the chain of trust to be established. | ||
| Since this is traditionally done via DNS certificates, we propose the addition of a DNS record containing the public keys. | ||
| This is similar to DKIM, but the use of a manifest file provides more flexibility for future improvements, as well as support for multiple algorithm and key pairs. |
There was a problem hiding this comment.
Readers might not be familiar with DKIM. You could do something like:
| This is similar to DKIM, but the use of a manifest file provides more flexibility for future improvements, as well as support for multiple algorithm and key pairs. | |
| This is similar to [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.html)'s DKIM, but the use of a manifest file provides more flexibility for future improvements, as well as support for multiple algorithm and key pairs. |
ERCS/erc-7754.md
Outdated
| To mitigate this, wallets SHOULD NOT cache dapp public keys for more than 2 hours. | ||
| This practice establishes a relatively short vulnerability window, and manageable overhead for both wallet and dapp maintainers. | ||
|
|
||
| Example DNS record for `my-crypto-dapp.org`: |
There was a problem hiding this comment.
| Example DNS record for `my-crypto-dapp.org`: | |
| Example DNS record for `my-crypto-dapp.invalid`: |
I'd suggest using reserved domain names (like example.com, foo.invalid, etc.) for your examples.
ERCS/erc-7754.md
Outdated
| Since this is traditionally done via DNS certificates, we propose the addition of a DNS record containing the public keys. | ||
| This is similar to DKIM, but the use of a manifest file provides more flexibility for future improvements, as well as support for multiple algorithm and key pairs. | ||
|
|
||
| Similarly to standard JWT practices, the wallet could eagerly cache dapp keys. |
There was a problem hiding this comment.
Similar comment here about JWT. Either expand the abbreviation or link to a definition.
ERCS/erc-7754.md
Outdated
|
|
||
| type SignedRequestParameters<Params> = [ | ||
| requestPayload: RequestPayload<Params>, | ||
| signature: `0x${string}`, // TODO: Is this the format we want? |
There was a problem hiding this comment.
If you use HTML-style comments (outside the code fence), the linter will make sure you deal with them before moving into Review (eg. <!-- TODO -->.)
| ii. If the user opts to cancel, then the wallet MUST cancel the call | ||
| e. If the signature is valid, the wallet MUST call `request` with the argument `requestPayload` | ||
|
|
||
| #### Example method implementation (wallet) |
There was a problem hiding this comment.
Should probably move this to the Reference Implementation section and link to it there from here.
There was a problem hiding this comment.
because of the use of dohjs library, it is more an example than a reference implementation. Happy to move it if you think that is ok.
There was a problem hiding this comment.
It's up to you. It's short enough that it's probably fine to stay where it is.
Signed-off-by: Guillaume Grosbois <[email protected]>
This EIP written in close collaboration with @remarks propose a new security mechanism to guarantee data integrity between dapps and wallets.
It introduces a new RPC method to be implemented by wallets,
wallet_signedRequest, thatenables dapps to interact with wallets in a tamperproof manner via "signed requests". The
dapp associates a public key with its DNS record and uses the corresponding private key to
sign payloads sent to the wallet via
wallet_signedRequest. Wallets can then use use thepublic key in the DNS record to validate the integrity of the payload.
The wallet can subsequently confirm data integrity to their users