Web3 Login Permissions

[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.