[Discussion] Identity between DAPPs

[Kyrrui]

With web browser based storage we do not have the ability to save identity credentials between DAPPs. This seems like a big limitation because it would become costly and cumbersome for a user to add credential keys for every DAPP website they visit. Perhaps we should consider creating a browser plugin that can store and deliver the credentials to a DAPP?

[alexvandesande]

Not sure I understand what you meant. Do you mean that it would share credential information between all the apps I visit? That sounds like a terrible security nightmare! I prefer have specific authorizations per app, so that I am sure the app cannot steal my money.

[Kyrrui]

I'm not sure what the best solution is, but I don't see people who interact with 10 different DAPPs wanting to do 2 factor authentication for each one, especially on the same device.

[alexvandesande]

One solution would be to have a flow similar to oauth:

1) User creates wallet at mywallet.com 2) User goes to mycoolgame.net and asks to login 3) mycoolgame.net makes the standard request, but while they wait, they redirect the user to mywallet.com/request?1234 4) user sees a mywallet.com confirmation that asks them to authorize mycoolgame.net and clicks "ok" 5) user is back at mycoolgame.net with working thing

In order to do this we need:

1) A way to detect the user's "default" wallet 2) a standard url request for that process

Seems better than a browser add-on.

[Kyrrui]

Any ideas on how we would detect their default wallet?

[alexvandesande]

I think it's inevitable that we'll need some ways to have public information associated with each account, maybe through 3box or not.

But honestly, considering that in the beginning there would be very few providers, a good UX could be simply:

1. App makes a connection request in the background to the relayers
2. While waiting, the app shows the user a selection of most popular wallets and asks them to select one to use for confirmation
3. User clicks on their preferred wallet, the app knows how each one handles requests and forwards it

Thinking about that, here's what I suggest a very small change we can do in the current app: in the PendingAuthorization view, we should also to pass information via the url to make a new request. That would be something like

localhost:1234/?request=0x123456&terms=0xffbbaacc&callback=mywallet.com/authorization 

Or whatever fits better with existing standard like oauth

[alexvandesande]

Here's how the connection request could look like:

Or it could be a single button with a dropdown. But these can only be built after it wallets work

[Kyrrui]

I think conceptually these should be called "Identity Providers" and not "Wallet Providers" - thoughts?

[alexvandesande]

Makes sense. “Primary login service”?

On 21 Oct 2018, at 04:30, Kyle Bryant notifications@github.com wrote:

I think conceptually these should be called "Identity Providers" and not "Wallet Providers" - thoughts?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[Kyrrui]

I think 'Identity Provider' should be the name, because these services will encapsulate more than just your primary login - they also distributed your identity to you in the first place, for example with Boomerang, Skedaddle will be our 'Identity Provider' for new users wanting to use Boomerang at first of course the user could have already created an identity previously through another 'Identity Provider'

[marekkirejczyk]

I would argue it is reasonable to have 10 keys for 10 different dapps, as each I would be granting different access level and each I can connect or disconnect separately.

E.g. I have one key for 0x that I trust completely and can do transactions alone, while dharma key has daily limit 1000 and monthly limit 10000, above that I need to another key to confirm.

[Kyrrui]

I would argue it is reasonable to have 10 keys for 10 different dapps, as each I would be granting different access level and each I can connect or disconnect separately.

E.g. I have one key for 0x that I trust completely and can do transactions alone, while dharma key has daily limit 1000 and monthly limit 10000, above that I need to another key to confirm.

@marekkirejczyk I agree long term this should be the use case, but every add key will have an associated gas cost, so while using the network is still relatively expensive I don't think adding a key per dapp is the ultimate solution. I'm now working on a project that uses a implementation of shamir's secret sharing to allow you to retrieve a private key from a google sign in. This could perhaps be a good short term solution for Universal Logins.

This means that you don't need to trust a central authority to have access to your identity for identity recovery (although you are still trusting your google account to provide OAuth token to the network)