Web3 Login Permissions

[danfinlay]

The proposal need to spec out exactly what/who these permissions are given to.

Excellent point, I am surprised I didn’t include this.

Initially, as MetaMask can connect to normal DNS websites, I would use the same origin identifier, which should include a prefix of the protocol (i.e. https://dapps.metamask.io, ens://danfinlay.eth, or ipfs://IPFSHASH).

I do agree that we could use this opportunity to push developers towards more decentralized protocols, so at MetaMask we are improving the origin detection of our IPFS resolution.

That said, I think loading over an eth address or ENS name would be a powerful tool, because it allows the creation of on-chain update logic.

I can even see the possible benefits of locking permissions to the hash of a page, so that any page update requires a re-authentication. That’s a big usability tradeoff, but has some pretty great security benefits.

Alternatively, if this could be possible, the web3 browser could generate an hash of the content and linked content to create the origin itself. DNS would then be simply used as a redirection mechanism.
But this would not work for any application that request data dynamically from non-hashed based data source.

Agreed, I’m not sure it’s even possible for us to dynamically check the hash of a page that is loaded, we’ll have to check that out. Some of these goals are very ideal, but may be less practical in the short term, where we’re still building largely on web 2.0 infrastructure.

Regarding the “eth_accounts” request, as I proposed in 1102 proposal, Giving permissions to eth_accounts should return a signed request so that the application can be sure the wallet is indeed in possession of the private key without having to make yet another request.

I don’t think all applications require cryptographic proof of key holding, nor do all accounts have a single key that controls them (contract accounts would be unable to sign in under this model!). We’re currently working on a proposal to integrate your Automatic Authentication Signature proposal into an additional, optional permission that a dapp could request at its discretion, for when it truly needs to verify a key’s possession.

[danfinlay]

@Ethernian

I would put possible UseCases in focus (like gas payments) to check the applicability of the permission paradigm to it.

Could you expand on this example use case?

@Ethernian

I am not sure, wallet will be able to identify “dangerous permissions” in generic manner because the value of the permitted transaction may be external to the blockchain (like a transfer of a real-world asset).

I don’t think we need to do it generically: Some permissions (like sendTransaction) are clearly security critical, and probably far too open-ended for most normal usage, and so it should be rendered with an extreme warning. Only if the requested permission is constrained to an extent that we can coherently render it should we laxen our warning. For example, an allowance of a known asset type.

@Ethernian

If some transaction get signed because of some permission is active, than for the transaction itself the user confirmation is implicit (implied) and not the explicit one. Right?
I see the security risk increasing here (because this implication may be correct or not) and do not understand how you don’t.

Just to re-ground the discussion, this proposal at large is not presenting any “freely send transactions” permission, so it might be best to separate that into a future hypothetical discussion, so we don’t throw out this entire platform just because it could be extended in a dangerous way.

@Ethernian

One more concern:
This protocol assumes bidirectional communication changing its direction many times.
For high security wallets like AirGap utilizing two separate uni-directional channels (Camera + Display) it will not be easy to implement it,

This is fair. Signing in with different types of wallets will have different features, so Dapps may need to do some feature detection, and some dapps may only be able to work in some contexts. If an application requires streaming communication (for decryption, for example), it might mean that either it requires a web3 browser or that the wallet phone stays on during the connection.

I think this is an important consideration, and maybe we should add a permissions-feature-detecting API also, so Dapps could ask what permissions are even available. Or maybe feature-detection could be implicit, wherein a response to wallet_requestPermissions returns only approved (and available) permissions, which also improves user privacy by never exposing a list of available APIs.

[Ethernian]

@danfinlay

I would put possible UseCases in focus (like gas payments) to check the applicability of the permission paradigm to it.

Could you expand on this example use case?

Sorry for using uncommon terms.
I used “gas payments” for per-Tx micro payments for tool and infrastructure usage made in protocol tokens or other non-ETH assets. It could be a per Tx micro payment for using MetaMask, WalletConnect etc. These properties are:

• micro payments, maybe paychannel or other meta Tx.
• related to main Tx

I can imagine a permission for this Use Case. But note, that this permission is use case specific and not generic.

[danfinlay]

Hi @loredanacirstea, thanks for reading!

I like the idea of strongly-typing the method parameters, but am unclear by what API the wallet would make these available. Maybe that belongs in an additional method? Or should the inputs be returned as part of the wallet_getPermissions response?

I think the required, customizable parameters are excellent ideas, and is similar to a use case suggested just yesterday by @tomhschmidt.

The selection parameter could be encoded as a type of caveat, which I think gives us a more open-ended model for defining the constraints on a permission.

One difference in your proposed examples and mine are the use of an array vs an object for defining the requested permissions. My reasoning had been that if permissions have unique names, then no array (or label key) is needed, we can iterate unique keys. Is there a particular benefit you see to submitting the requested permissions as an array?

[danfinlay]

One method that would benefit from a permissions system like this would be encryption/decryption, like @topealabi proposed with EIP 1024.

At the time, I had some concerns about how to securely expose such a method, but I think this permissions framework gives us a pretty prescriptive path for adding such a method.

[danfinlay]

@wighawag

On the other hand, such permission should not be given if the origin is a DNS domain pointing to a backend url without hash. Similary this permission should not be given to an ENS name, instead it should be given to the ipfs hash the ENS name points to (this way if the ENS name owner change the content, the user are protected)

Maybe this could be a login option:

- Log me out after X minutes.
- Log me out if this site is updated.

[loredanacirstea]

@danfinlay,

I like the idea of strongly-typing the method parameters, but am unclear by what API the wallet would make these available. Maybe that belongs in an additional method? Or should the inputs be returned as part of the wallet_getPermissions response?

These types should not be controlled by an implementation, but agreed on as a standard and kept in a globally available scope. Libraries for transforming them into language-specific types can be built. I suggest using such a system.

For the purpose of defining immutable types that are reused across standards, I started dType.

The selection parameter could be encoded as a type of caveat, which I think gives us a more open-ended model for defining the constraints on a permission.

I don’t have anything against this.

One difference in your proposed examples and mine are the use of an array vs an object for defining the requested permissions.

An object with keys is good, for the reasons that you mention.

[wighawag]

@danfinlay

I can even see the possible benefits of locking permissions to the hash of a page, so that any page update requires a re-authentication. That’s a big usability tradeoff, but has some pretty great security benefits.

That’s exactly where I think this should go. Giving permissions (at least the dangerous one like eth_sendTransaction) to anything else could come with a BIG warning to the users but I actually believe we should not even let such applications request it. This is too much risk for the users and too much responsibility for the application owner.

@danfinlay

Maybe this could be a login option:

- Log me out after X minutes.
- Log me out if this site is updated.

if this was the default and any different permission requests was acompagnied with a big warning, this could be an option. At the same time, it is easy to imagine users starting to accept such permission request blindly.

I think as stated aboive some permissions should simply never be allowed on origin that do not encode the full content.

Also if the result of a change was simply being logged out, the user might think they have been logged out for other reason (time based for example). As such we will still need to differentiate between the 2 so users are aware that the content change and that they might be better off waiting before trusting the new content.

@danfinlay

I don’t think all applications require cryptographic proof of key holding, nor do all accounts have a single key that controls them (contract accounts would be unable to sign in under this model!). We’re currently working on a proposal to integrate your Automatic Authentication Signature proposal into an additional, optional permission that a dapp could request at its discretion, for when it truly needs to verify a key’s possession.

Ok, having automatic signature as a permission would work but I still feel that giving the application access to the ethereum address without proving key ownership is potentially misleading.

Obviously for application that only display content associated to an address, there is no need to verify the address is indeed own by that wallet. But at the same time, what would be the risk to let application know that the wallet own the private key by giving out a signed message ?

Actually thinking about it, maybe it is privacy ? Like if wallet allow any user to display themselves as any address, they could potentially be able to see their data without necessarely giving out their address. But I guess some statistical analysis would reveal it in the end (how much time they spend on a specific address?)

Any other reasons ?

[danfinlay]

@wighawag

But at the same time, what would be the risk to let application know that the wallet own the private key by giving out a signed message ?

Actually thinking about it, maybe it is privacy ? Like if wallet allow any user to display themselves as any address, they could potentially be able to see their data without necessarely giving out their address. But I guess some statistical analysis would reveal it in the end (how much time they spend on a specific address?)

Any other reasons ?

1. Supporting contract accounts, which may not have a single signer empowered to represent them.
2. Support viewing pages in “read-only” mode, maybe viewing from the “perspective” of a cold wallet, with an offline signer.
3. Privacy, plausible deniability, that all makes sense to me.

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?

@loredanacirstea

These types should not be controlled by an implementation, but agreed on as a standard and kept in a globally available scope. Libraries for transforming them into language-specific types can be built. I suggest using such a system.

For the purpose of defining immutable types that are reused across standards, I started dType.

Maybe we could encode the ethereum provider as a dType. I’ll look closer at that soon!

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