Skip to content

Commit

Permalink
2255: Add external images to assets folder (#2649)
Browse files Browse the repository at this point in the history
Add externally linked images to `assets/eip-2255` per: #2648 (comment)

Link to file: https://github.com/rekmarks/EIPs/blob/2255-fix-assets/EIPS/eip-2255.md
rekmarks authored Sep 6, 2020
1 parent 8f9b576 commit 4a8fb2a
Showing 4 changed files with 18 additions and 10 deletions.
28 changes: 18 additions & 10 deletions EIPS/eip-2255.md
Original file line number Diff line number Diff line change
@@ -11,26 +11,32 @@ requires: 1474
---

![Sample prompt screenshot](../assets/eip-2255/permissions.png)
<!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.-->

## Simple Summary
<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->

A proposed standard interface for restricting and permitting access to security-sensitive methods within a restricted web3 context like a website or "dapp".

## Abstract
<!--A short (~200 word) description of the technical issue being addressed.-->

Web3 JavaScript wallet browsers may implement `wallet_getPermissions` and `wallet_requestPermissions`. This provides a standard interface for requesting permissions and checking a domain's current permissions status.

## Motivation

Web3 Wallets are built around the responsibility of mediating the interactions between untrusted applications and a user's keys on their computer, getting appropriate consent from the user.

Today web3 browsers like MetaMask always prompt on a per-action basis. This provides security at the cost of substantial user friction. We believe that a single permissions request can achieve the same level of security with vastly improved UX.

The pattern of permissions requests is common around the web, from login with Facebook, Twitter, GitHub, and even Apple, making it a very familiar pattern.

![facebook permissions](https://proxy.duckduckgo.com/iu/?u=https%3A%2F%2Fi.stack.imgur.com%2FG7dRV.png&f=1)
<details>
<summary>Facebook Permissions</summary>
<img src="../assets/eip-2255/facebook_permissions.png" alt="Facebook Permissions" />
</details>

![log in with apple](https://forum.level1techs.com/uploads/default/original/3X/e/0/e0d20c0faec92acec3e591c957612fd482d9d01a.jpeg)
<details>
<summary>Log in With Apple</summary>
<img src="../assets/eip-2255/log_in_with_apple.jpeg" alt="Log in With Apple" />
</details>

Many web3 applications today begin their sessions with a series of repetitive requests:

@@ -45,7 +51,7 @@ Many of these (and possibly all), and many more (like decryption), could be gene
On the user's end, each of these permissions could be individually rejected (unchecked), or even _attenuated_, or adjusted to meet the user's terms (for example, a sign-in request could have a user-added expiration date, and a token allowance could be adjusted by the user when it is requested), making the web3 login a sort of user-revisable terms of use.

## Specification
<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->

This proposal adds two new methods to a wallet's web3 provider API:

- `wallet_getPermissions`
@@ -77,6 +83,7 @@ const response = await provider.send({
method: 'wallet_getPermissions'
})
```

Would return a value something like this:

```json
@@ -103,7 +110,7 @@ The `caveats` array represents the specific restrictions applied to the permitte
You can see above how internally the user-selected account is transformed into a [`caveat`](https://github.com/MetaMask/json-rpc-capabilities-middleware/blob/master/src/%40types/ocap-ld.d.ts#L28-L33), which is a restriction on the response values, in this case ensuring the page can only be notified of approved accounts. This also means this permissions system is forward-extensible to support logging into a page with multiple accounts.

## Rationale
<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->

While the current model of getting user consent on a per-action basis has high security, there are huge usability gains to be had bo getting more general user consent which can cover broad categories of usage, which can be expressed in a more human-readable way. This pattern has a variety of benefits to offer different functions within a web3 wallet.

The `eth_sendTransaction` method itself could be a restricted method (requested by default with the `provider.enable()` method), and the user could at sign-in time decide whether they wanted to require confirmations, approve all transactions, or only approve transactions to a certain contract, or up to a certain token limit, for example. By restricting this method by default, wallets could prevent sites from spamming the user with popups.
@@ -126,12 +133,13 @@ provider.send({
]
})
```

That type of API will also be up for discussion on [The MetaMask repository](https://github.com/MetaMask/metamask-extension/issues/6994).

This would allow the wallet to limit the user's options to valid ones, and allows dapps to ensure selected accounts are compatible with their service, while preserving the user's privacy regarding how they are storing their keys.

## Implementation
<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->

We have [a branch of MetaMask available now](https://github.com/MetaMask/metamask-extension/tree/LoginPerSite) which adds these methods via an [rpc-engine](https://github.com/MetaMask/json-rpc-engine) middleware called [json-rpc-capabilities-middleware](https://github.com/MetaMask/json-rpc-capabilities-middleware) (or often `RpcCap` internally, for short).

The latest build of this branch of MetaMask can be downloaded from [the draft pull request](https://github.com/MetaMask/metamask-extension/pull/7004) (look for the latest post by `@MetaMaskBot`). A guide to adding a custom build of MetaMask to Chrome can be found [here](https://github.com/MetaMask/metamask-extension/blob/develop/docs/add-to-chrome.md).
@@ -142,7 +150,7 @@ This branch of MetaMask can be used with [this sample site](https://metamask.git
- `writeToYourProfile`: This permission allows the requesting app to freely update/edit the user's profile.
- `sendEther`: A permission allowing the sending of transactions.

![sample dapp](https://miro.medium.com/max/1400/0*JE9gDZR7fqo2Ewfw.gif)
![sample dapp](../assets/eip-2255/permissions_adventure.gif)

It is notable that this branch is the first version of MetaMask that allows you to be connected to each site with a different account, which persists on that site, along with any other permissions granted to the site.

@@ -151,5 +159,5 @@ You can get more detailed API and type information [on the RpcCap repository's r
New hypothetical and proposed permissions can be easily added to [the `restrictedMethods` hash in the MetaMask permissions controller](https://github.com/MetaMask/metamask-extension/blob/774d931cb9f16a8f2df8c6deee1dd553b40d5ad5/app/scripts/controllers/permissions.js#L187) or proposed for discussion on the [MetaMask/wallet-permissions-spec](https://github.com/MetaMask/wallet-permissions-spec) repository.

## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
Binary file added assets/eip-2255/facebook_permissions.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added assets/eip-2255/log_in_with_apple.jpeg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added assets/eip-2255/permissions_adventure.gif
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit 4a8fb2a

Please sign in to comment.