search

fission-codes / auth-lobby

The authentication service that Fission services run.
https://auth.fission.codes
GNU Affero General Public License v3.0
12 stars 1 forks source link

Account recovery slice 1 auth lobby #65

Closed expede closed 1 year ago

matheus23 commented 3 years ago

I think in https://talk.fission.codes/t/account-recovery-plan/1704 we worked out that we don't actually need changes to the auth lobby in the first slice.

So I think this might fit better into the dashboard repo.

To elaborate: I think the first slice only needs two crucial pieces:

  1. A page that gives human-usable access to the read key for the user (that can live in the dashboard under https://dashboard.fisison.codes/#backup)
  2. A server route that will allow changing a user's DID to something new and will send an email challenge + another route to verify that challenge and complete the process. The idea is that all of that can be handled by some small app that lives under https://dashboard.fission.codes/recover (separate codebase - no fission authentication, smaller attack surface area) and that this recovery app will be able to link the account with an actual auth lobby (hook into existing linking capabilities - no code change needed?)

At least that's my plans for now. I'd love for someone to confirm that linking accounts this way actually works. There's one thing I'm not 100% sure of: Can one transfer the root UCAN over the wss linking protocol? If so, then I think there's nothing stopping us from implementing it like this.

The upside of putting the recovery into a separate app is: We keep the auth lobby as slim as possible. The downside is: The account recovery flow is slightly more complex: It includes a linking process to the auth lobby.

icidasset commented 3 years ago

Can one transfer the root UCAN over the wss linking protocol?

There's not really a root UCAN. For example, when you sign up in the browser, that device won't have a UCAN stored in the lobby (ie. no ucan in localforage.getItem("ucan")). A UCAN is created when linking to another device. That new device, let's call it device 2, is then granted access through the UCAN. If you then link another device, from the one that just received a UCAN (device 2), it'll create another UCAN and set that UCAN from device 2 as the proof prf.

Does that make sense?