Centralised recovery option about unilogin HOT 5 OPEN

Hi,

That is something I would like to see on the roadmap.
Things to consider:

• I would call it "trusted 3rd party recovery"
• I would at least partially implement it in the relayer
• I would make it a factor of authentication rather than just recovery option.
  So that if I lose all of my devices, I still need two factors to recover: e.g printed code + trusted 3rd party or friends + trusted 3rd party.

from unilogin.

I am all for experimenting with "trusted third party recovery" as long as:

• If the trusted third party is hacked, then it cannot overtake on its own, all users funds
• The user must understand the system and consent to it
• The user should offered how to remove or change the trusted third party, specially if it starts to hold too much on the contract

from unilogin.

I agree, we’re going to implement this in Boomerang. It might be beyond the scope of this example project, because it requires a third party verification process ( database with emails, passwords and such), but it’s simple as adding the central recovery key to the Identity on contract creation, having the third party verify by some means you own that account, and them adding your key.

from unilogin.

This isn't in the scope of this example project, but at Boomerang we're going to deploy identity contracts pre-loaded with tokens through our first integrated business, Skedaddle, who will be the key holder of these contracts.

The user is prompted after completing a review to claim a reward (their identity + tokens), we will give them their ENS username and a recovery key. In our UI we will have a 'Identity Provider' screen on first login which will prompt the user wether they would like to keep or remove management rights by the 'Identity Provider'(Skedaddle), likely a pros and cons list.

Skedaddle already has a login flow, so they will be able to do a verification with the users email, generate a new access key.

In addition to this we will have a screen where it will prompt the user to delete the access key and generate a new one before entering into their account.

Just wanted to add this to the discussion.

from unilogin.

A centralized recovery is not that hard, all you need to do is add by default one management key that is controlled by the app provider. The problem is that this key becomes a central point of failure in which if that server is hacked, every user who logged in via that service and didn't add extra security features will be doomed also. In order to prevent that I'd like that key to have some sort of limitations on what they can do: for instance maybe they can only do recoveries if you haven't used your other keys in a while, or maybe it has a 24h wait period before it can reset keys, or maybe that key can only do a few actions.

You can do it by making that central key a contract, but I'd prefer to have the a general authorization standard in place.

I do agree with Kyrrui that this is out of scope for this particular project, but it's the sort of expansion that I encourage to be built.

from unilogin.