Web3 Login Permissions

[wighawag]

@danfinlay

I don’t think it makes sense to require a feature that is not required for all use cases, and since some use cases cannot provide signatures, I would not want to make them a requirement, especially when adding the feature as an extra permission is so trivially easy.

I would instead ask, is there a good reason that all accounts must sign when connecting to an application?

You are right! I now agree that the best way is to make auto signature (or maybe simply a single signature challenge) another permission for those that need it

[danfinlay]

I’ve cross posted this to the EIP repository:

Issue: EIP-xxx: Web3 Wallet Permissions

[MicahZoltu]

I don’t feel like the dapp should be involved in the process of deciding whether the signer auto-signs or not. In fact, I think the dapp should not know whether the signer is auto-signing or not (though, this is difficult to prevent due to timing attacks).

I’m a big fan of a dapp requesting permissions from a user, including the ability to prompt for signing. I’m not a fan of the dapp being able to request auto-signing, but I am a big fan of users being able to enable auto-signing.

One can imagine a dapp requesting signing permission from the signer, and then the signer popping up a dialog that asks the user if they want to allow the dapp to prompt for signing. The dialog would have an option the user could optionally select (off by default) that would auto-sign transactions from that dapp.

I think if you have a permission for “auto-sign”, every dapp that needs to sign things would ask for it, because there is no reason not to ask for it. If every dapp asks for a thing, why is it part of a protocol?

---

On the topic of constraining permissions, I am a big fan of pushing forward on the IPFS front, or other mechanisms for detecting page changes. I would be in favor of saying that these permissions only work in cases where we can guarantee that a page hasn’t changed compared to when the permission was granted. You could have things like, “we noticed this page has changed since you last granted permissions, would you like to grant the same permissions as before” when you have information like domain name to identify similar pages.

The place where this is problematic is when you have a page that is receiving dynamic data from an external source. Do you only hash the root page? The root page plus all JS? What about GET requests that mutate the page?

---

For permissions like send_token and similar, should the dapp be able request constraints on those? For example, send_token: DAI,REP,MKR vs send_token: * which would cause the prompt to list the tokens the dapp wants to be able to send instead of prompting for the ability to send any token.

[danfinlay]

@MicahZoltu

I don’t feel like the dapp should be involved in the process of deciding whether the signer auto-signs or not. In fact, I think the dapp should not know whether the signer is auto-signing or not (though, this is difficult to prevent due to timing attacks).

This is fine, and makes sense, but I’d like to point out it is slightly outside the scope of this proposal. This proposal does not include an auto-signing permission, just presents one as a hypothetical permission. For that discussion, it might be more useful to take the concerns to the app keys proposal, for example.

That said, there are several hypothetical signing permissions that have been presented in this thread, so I would suggest people make sure they specify which they are referring to:

1. A domain-locked app key
2. A domain-locked permission to sign challenges within a constrained EIP-712 domain
3. A domain-locked permission to send transactions (possibly with limitations on gas, recipient, etc).

I felt like you touched on a few of those as if they were a common permission.

For example, re: item 3 above, “don’t ask for confirmations on this domain” could easily be added to the normal transaction confirmation window, and the site would never need to know that it was granted this privilege.

But that’s a little distinct from the timing-attacks issue you raised, which seems more related to item 2 above, and should be addressed in any auto-sign proposal.

@MicahZoltu

You could have things like, “we noticed this page has changed since you last granted permissions, would you like to grant the same permissions as before” when you have information like domain name to identify similar pages.

The place where this is problematic is when you have a page that is receiving dynamic data from an external source. Do you only hash the root page? The root page plus all JS? What about GET requests that mutate the page?

I think that warning is a very nice idea, and is a good compromise between the “support the web as it is” and “only support the most secure options” camps. Long term it would be great to be able to make any fetch or ajax calls explicit permissions themselves, and so by default sites would have no special permissions besides rendering themselves on screen.

In the meanwhile, for the sake of allowing the best we can provide today, we probably don’t have a huge choice but to support normal http and https loaded sites, along with all the default browser APIs, but as more permissions are proposed, maybe we should seriously limit some permissions to some more secure transport types, or at least present warnings of the concerns with those lower-security types.

I’d hate to not be able to use http for local development, for example, but I can tolerate a warning in development, even one that might scare away users in production.

@MicahZoltu

For permissions like send_token and similar, should the dapp be able request constraints on those? For example, send_token: DAI,REP,MKR vs send_token: * which would cause the prompt to list the tokens the dapp wants to be able to send instead of prompting for the ability to send any token.

I think we should support dapp-provided constraints, because dapps know what they require to operate. Users should be able to customize the approved parameters within those constraints, or reject the entire request.

There are lots of examples of this, like when signing into a site, it may know it requires an allowance of up to $5 to begin viewing, and it can specify that, but you can still specify over their minimum request if you want.

We’ve also had requests from developers to be able to specify valid gas values for a transaction, because some smart contracts use gas price and gas limit to encode additional data, and so they need to be able to constrain those values.

[MicahZoltu]

@danfinlay

We’ve also had requests from developers to be able to specify valid gas values for a transaction, because some smart contracts use gas price and gas limit to encode additional data, and so they need to be able to constrain those values.

I’m pretty against supporting this sort of thing in any way. At best, it is an attempt to exploit inappropriate gas pricing of operations. It is a strategy that is also likely to break as gas costs change over time (see Istanbul and Constantinople). There may be other legitimate reasons to allow dapps to specify gas amounts and gas prices, but so far the only reasons I have seen are really terrible reasons that should not be supported by signing tools and should be actively discouraged by the development community.

[danfinlay]

@MicahZoltu

r the only reasons I have seen are really terrible reasons that should not be supported by signing tools and should be actively discouraged by the development community.

One was so that a market with limited-time order offers could mandate minimum gas prices, to help ensure the buy orders would be mined soon enough to be successful.

[MicahZoltu]

That decision should not be up to the dapp, that is a decision for signing tool. The user should tell the signing tool how time sensitive the transaction is and the signing tool should then set gas price accordingly.

I could see an argument that the dapp should tell the signing tool the time sensitivity of the transaction directly, so the signing tool can set gas prices appropriately, but I don’t think that setting the gas price is the dapp is the right solution to that problem.

[danfinlay]

@MicahZoltu

That decision should not be up to the dapp, that is a decision for signing tool.

You should take that here:

EIP-2250: Gas Price Range

Wouldn’t it make sense to decouple this entirely from a given transaction? If you want to include a transaction in a given number of blocks, and assume that the next n blocks will look roughly the same as the last n blocks, then you should be able to provide (gas, n) to an RPC method and receive gas price in return. It would then be up to the wallet to provide this to the user, worry about if it fell within the acceptable bounds the user has specified, etc.

[danfinlay]

This proposal has been submitted as EIP 2255, a very symmetrical EIP.

EIP 2255: Web3 Wallet Permissions System

[kdenhartog]

@coryhardman had a good suggestion here: https://github.com/ethereum/EIPs/pull/5593#discussion_r966492680

Seems like it’s better related to this EIP instead. What do others think?

[agostbiro]

I’m wondering, what’s the status of this EIP? I see that the GitHub - MetaMask/wallet-permissions-spec: A repo for describing the permissions exposed by the web3 wallet protocol. repo has been archived. Is there a follow up to that?