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

Fix typos #244

Closed
wants to merge 2 commits into from
Closed

Fix typos #244

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
07b6f08
fix typos
omahs May 18, 2024
4ee0147
fix typos
omahs May 18, 2024
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
18 changes: 9 additions & 9 deletions docs/ensip/13.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -55,7 +55,7 @@ Rather than 're-invent the wheel', this proposal aims to use the widely adopted
From there, the benefits are twofold. This EIP gives users increased security via outsourcing potentially malicious signing operations to wallets that are more accessible (hot wallets), while being able to maintain the intended security assumptions of wallets that are not frequently used for signing operations.

#### Improving dApp Interaction Security
Many dApps requires one to prove control of a wallet to gain access. At the moment, this means that you must interact with the dApp using the wallet itself. This is a security issue, as malicious dApps or phishing sites can lead to the assets of the wallet being compromised by having them sign malicious payloads.
Many dApps require one to prove control of a wallet to gain access. At the moment, this means that you must interact with the dApp using the wallet itself. This is a security issue, as malicious dApps or phishing sites can lead to the assets of the wallet being compromised by having them sign malicious payloads.

However, this risk would be mitigated if one were to use a secondary wallet for these interactions. Malicious interactions would be isolated to the assets held in the secondary wallet, which can be set up to contain little to nothing of value.

Expand All @@ -67,10 +67,10 @@ Instead, each device can have its own unique wallet that is an authorized second
Further, wallet authentication can be matokenUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Let:
- `mainAddress` represent the wallet address we are trying to authenticate or prove asset ownership for.
- `mainENS` represent the reverse lookup ENS string for `mainAddress`.
- `authAddress` represent the address we want to use for signing in lieu of `mainAddress`.
- `authENS` represent the reverse lookup ENS string for `authAddress`.
- `mainAddress` represents the wallet address we are trying to authenticate or prove asset ownership for.
- `mainENS` represents the reverse lookup ENS string for `mainAddress`.
- `authAddress` represents the address we want to use for signing in lieu of `mainAddress`.
- `authENS` represents the reverse lookup ENS string for `authAddress`.
- `authKey` represents a string in the format `[0-9A-Za-z]+`.

Control of `mainAddress` and ownership of `mainAddress` assets by `authAddress` is proven if all the following conditions are met:
Expand All @@ -87,7 +87,7 @@ In order to automatically discover the linked account, the `authAddress` SHOULD
2. Set a TEXT record `eip5131:<authKey>` on `mainENS`, with the value set to the desired `authAddress`.
3. Set a TEXT record `eip5131:vault` on `authENS`, with the value set to the `<authKey>:mainAddress`.

Currently this EIP does not enforce an upper-bound on the number of `authAddress` entries you can include. Users can repeat this process with as many address as they like.
Currently this EIP does not enforce an upper-bound on the number of `authAddress` entries you can include. Users can repeat this process with as many addresses as they like.

### Authenticating `mainAddress` via `authAddress`
Control of `mainAddress` and ownership of `mainAddress` assets is proven if any associated `authAddress` is the `msg.sender` or has signed the message.
Expand All @@ -108,7 +108,7 @@ To revoke permission of `authAddress`, delete the `eip5131:<authKey>` TEXT recor
## Rationale

### Usage of EIP-137
The proposed specification makes use of EIP-137 rather than introduce another registry paradigm. The reason for this is due to the existing wide adoption of EIP-137 and ENS.
The proposed specification makes use of EIP-137 rather than introducing another registry paradigm. The reason for this is due to the existing wide adoption of EIP-137 and ENS.

However, the drawback to EIP-137 is that any linked `authAddress` must contain some ETH in order to set the `authENS` reverse record as well as the `eip5131:vault` TEXT record. This can be solved by a separate reverse lookup registry that enables `mainAddress` to set the reverse record and TEXT record with a message signed by `authAddress`.

Expand Down Expand Up @@ -174,7 +174,7 @@ export async function getLinkedAddress(

#### With a backend

If your application operates a secure backend server, you could run the client/server code above, then use the result in conjunction with specs like [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) : `Standard Signature Validation Method for Contracts` for a cheap and secure way to validate that the the message signer is indeed authenticated for the main address.
If your application operates a secure backend server, you could run the client/server code above, then use the result in conjunction with specs like [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) : `Standard Signature Validation Method for Contracts` for a cheap and secure way to validate that the message signer is indeed authenticated for the main address.

#### Without a backend (JavaScript only)

Expand Down Expand Up @@ -204,7 +204,7 @@ interface Resolver {
}

/**
* Validate a signing address is associtaed with a linked address
* Validate a signing address is associated with a linked address
*/
library LinkedAddress {
/**
Expand Down
6 changes: 3 additions & 3 deletions docs/faq.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ Simply visit the [ENS Manager App](https://ens.app/) and update the appropriate

Yes. You can create whatever subdomains you wish and assign ownership of them to other people if you desire. You can even set up your own registrar for your domain.

Some resolvers might provide even more advances features, read more [about Resolvers](/resolvers/quickstart).
Some resolvers might provide even more advanced features, read more [about Resolvers](/resolvers/quickstart).

## Can I change the address my name points to after I've bought it?

Expand Down Expand Up @@ -74,7 +74,7 @@ The released name continues to resolve your ETH address until the new owner over
### In what way could I lose access to my name?

The .eth registrar is built to ensure once issued, a name cannot be revoked or taken away from its owner.
Potential loss can occur if the owner losses access to their private key, or if the owner forgets to renew their name.
Potential loss can occur if the owner loses access to their private key, or if the owner forgets to renew their name.

## Root Registry

Expand All @@ -95,7 +95,7 @@ Yes and No, We consider ENS to be part of the 'global namespace' in co-existence
ENS-specific TLDs are restricted to only '.eth' on Mainnet Ethereum, or .eth and .test on testnets.

By default ENS allows users to [import their DNS name](/learn/dns) through the use of the [DNS Registrar](/registry/dns).
Existing DNS TLDs can [reachout to us](mailto:[email protected]) to take control of their TLD.
Existing DNS TLDs can [reach out to us](mailto:[email protected]) to take control of their TLD.

## What are the differences between ENS and other naming services such as Namecoin or Handshake?

Expand Down
Loading