EIP-1102: Opt-in provider access

EIPs
62

Are there any plans to move this to Last Call and eventually final? I’m writing a browser extension provider and would like to follow the latest standards, but I’m pretty against coding against draft specifications.

63

If it is going to move to Last Call, it probably should be updated to match changes in stuff like EIP-1193 (no more .send, instead it is .request). Was .enable ever part of a spec that made it to final? If not, then consider removing the whole section on Provider#enable as it is just deprecating a thing that never technically existed (as far as specs are concerned).

1 Like
64

In trying to implement this, I have realized that the lack of explicit error messaging makes it impossible to reliably implement a dapp that uses this while supporting older Ethereum browsers. If you are working with a browser that does not implement this, then you will be unable to differentiate between “this method failed because it doesn’t exist” and “this method failed because the user denied access”.

I think without the ability to ask the provider for capabilities, we cannot have methods that act as gatekeepers unless we start prescribing error results (e.g., assert in the spec that an error for not approved is shaped exactly like X).

Perhaps “unapproved” should return an empty array instead? This way if the method doesn’t exist it will hard fail and the dapp can fallback to eth_accounts or ethereum.enable and assume that the provider doesn’t implement this specification, and if it does exist and returns an empty array then it will let the dapp know “the provider supports this method but has returned no accounts that the dapp has access to” and the dapp can then behave appropriately in that situation.

(added below because Discorse won’t let me reply 3 times in a row)

I think this specification is overly prescriptive. One can easily imagine a provider that does want to give access to the blockchain (e.g., eth_getBlockByNumber) but doesn’t want to give access to the user’s account. Such a provider may even support eth_sendTransaction and eth_call by injecting the user’s account into the requests before forwarding them on to the signer or backing Ethereum client so the user’s address may never be exposed to the dapp (some dapps can work without ever knowing the user’s account, and it will be up to the dapp to decide if it can function without that information).

In general, I think that provider specifications should not specify provider behavior and instead should focus on specifying the interactions between dapp and provider. In this case, the specification for eth_requestAccounts can describe the shape of the request and response but I don’t think we should be specifying what the provider may be doing behind the scenes.

1 Like
65

Thanks for the feedback on this Micah. I recently became co-author of this EIP since bitpshr is no longer actively working on it. Your points are well taken, and you can expect many of them to be incorporated in a forthcoming significant update of 1102.

I can already note that:

  • eth_requestAccounts is staying; ethereum.enable will be removed from 1102 entirely, albeit perhaps mentioned in a comment for historical context.
  • 1102 will require 1193
  • 1102 will specify that the 4001 - User Rejected Request error should be returned if the user rejects the request. That error is defined in 1193.
66

FYI: I’m going to try to finalize 1102 sometime soon. It’s unlikely to change in any material way except as noted in my previous comment.

Since most EIP discussion now takes place in issues on the EIP repo, please pursue further discussion using this issue: https://github.com/ethereum/EIPs/issues/3257

67

I was wrong about where discussions are supposed to take place, so we’re just going to keep it here :man_facepalming:

68

HI all, there is currently some work being carried on establishing a much needed standard for “sign-in with ethereum” : https://login.xyz/

It overlap with 1102 and the current spec add an extra layer of confirmation for the user degrading the experience.

It would be great to make 1102 the main integration point so user can sign-in in one approval (See comment EIP-1102: Opt-in provider access - #58 by wighawag), instead of having to “connect” with 1102 and then again “sign-ing”

For those interested in ensuring the best user experience, I invite you to participate in the discussion and the community:

discord : Spruce
current draft spec : EIPs/eip-4361.md at 9a9c5d0abdaf5ce5c5dd6dc88c6d8db1b130e95b · ethereum/EIPs · GitHub
website : https://login.xyz/

1 Like