Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update ERC-7754: Fix typos #651

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update ERC-7754: Fix typos #651

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions ERCS/erc-7754.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ requires: 1193
Introduces a new RPC method to be implemented by wallets, `wallet_signedRequest`, that
enables 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 the
sign payloads sent to the wallet via `wallet_signedRequest`. Wallets can then use the
public key in the DNS record to validate the integrity of the payload.

## Motivation
Expand Down Expand Up @@ -66,7 +66,7 @@ We propose to use the dapp's domain certificate of a root of trust to establish

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 [RFC-6636](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.
This is similar to [RFC-6636](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 algorithms and key pairs.

Similarly to standard [RFC-7519](https://www.rfc-editor.org/rfc/rfc7519.html)'s JWT practices, the wallet could eagerly cache dapp keys.
However, in the absence of a revocation mechanism, a compromised key could still be used until caches have expired.
Expand Down Expand Up @@ -155,7 +155,7 @@ const result = await ethereum.request({

#### Signature verification

1. Upon receiving an [EIP-1193](./eip-1193.md) call, the wallet MUST check of the existence of the TWIT manifest for the `sender.tab.url` domain
1. Upon receiving an [EIP-1193](./eip-1193.md) call, the wallet MUST check for the existence of the TWIT manifest for the `sender.tab.url` domain
a. The wallet MUST verify that the manifest is hosted on the `sender.tab.url` domain
b. The wallet SHOULD find the DNS TXT record to find the manifest location
b. The wallet MAY first try the `/.well-known/twit.json` location
Expand Down Expand Up @@ -199,7 +199,7 @@ async function signedRequest(
break;
}

// 3. Parse the manifest and get they key and algo based on `keyId`
// 3. Parse the manifest and get the key and algo based on `keyId`
const manifestReq = await fetch(manifestPath);
const manifest = await manifestReq.json();
const keyData = manifest.publicKeys.filter((x) => x.id == keyId);
Expand Down Expand Up @@ -231,7 +231,7 @@ not block: an eloquently worded warning will increase the transparency enough th

The proposed implementation does not modify any of the existing functionalities offered by [EIP-712](./eip-712.md) and [EIP-1193](./eip-1193.md). Its additive
nature makes it inherently backward compatible. Its core design is modeled after existing solutions to existing problems (such as DKIM). As a result the proposed specification will be non disruptive, easy to
implements for both wallets and dapps, with a predictable threat model.
implement for both wallets and dapps, with a predictable threat model.

## Security Considerations

Expand All @@ -248,7 +248,7 @@ Cross chain replay can be prevented by leveraging the [EIP-712](./eip-712.md) `s
Replay attack would still be possible on any method that is not protected by either: this affects effectively all the "readonly" methods
which are of very limited value for an attacker.

For these reason, we do not recommend a specific replay protection mechanism at this time. If/when the need arise, the extensibility of
For these reasons, we do not recommend a specific replay protection mechanism at this time. If/when the need arises, the extensibility of
the manifest will provide the necessary room to enforce a replay protection envelope (eg:JWT) for affected dapp.

## Copyright
Expand Down
Loading