Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multidevice use case #7

Open
Gozala opened this issue Jul 2, 2020 · 2 comments
Open

Multidevice use case #7

Gozala opened this issue Jul 2, 2020 · 2 comments
Labels
topic/authorization Issues related to access control

Comments

@Gozala
Copy link
Collaborator

Gozala commented Jul 2, 2020

From what I understand currently API user token is going to be used to identify who requested a pin. However user may have multiple devices and sharing same token across those has few problems:

  1. Pins could be added removed from different devices and who wins is unclear:

    • Device A pins CID-A.
    • Device B pins CID-A.
    • Device A unpins CID-A.

    Does that mean CID-A should be removed or does that mean it should not because device B still holds a pin ?

  2. If access token is shared across multiple devices it would be impossible to audit which device added / removed pins or revoke access to that specific device.

For above reason I think it would be vice to move away from manual endpoint + token entry and instead perform device link / unlink flow similar to how e.g keybase does this. While under the hood that could still use tokens (although signing requests would be better option IMO) it could provide a better solution for above listed problems and provide better UX as described below:

  1. If each device pins / unpins with unique token / key associated with it then pinning service could keep pin as long as one authorized service still has active pin. While service could still choose to provide alternative policy, it would have enough information to implement the other policy.
  2. Since each device will have unique token / key it would be possible to audit all the API calls and identify which device those came from. Additionally revoking access from lost or compromised device would not require re-authorizing all other devices.
  3. Authorizing device could have much better UX that doesn't involve copy & pasting things in webui (at least). Device authorization could be performed e.g. via custom protocol handler that webui could react to.
@Gozala
Copy link
Collaborator Author

Gozala commented Jul 2, 2020

One extra thought that would go along with a general sentiment here:

  • Each node already has a peer ID backed by PKI.
  • Devices have unique IPFS nodes (two devices won't share same peer id or will run into problems).

It might be vice to embrace existing PKI and sign API requests with the peer key. That would remove need for secret tokens (that users need to enter), although users would need to authorize specific IPFS node with a pinning service. Although that could be fairly simple, webui or cli would just have to pass peer id to the pinning service endpoint, where pinning service could perform necessary authorization (if necessary) onboarding etc...

This was referenced Jul 2, 2020
@Gozala
Copy link
Collaborator Author

Gozala commented Jul 2, 2020

I think there is yet another reason to prefer device level granularity over user level. When you query for all user pins it would be useful to:

  1. To query for pins for this device or pins for other / all devices.
  2. In the web UI it would be useful to differentiate pins on my laptop vs pins on my phone (e.g. Dropbox already does something along those lines although semantics are different there).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic/authorization Issues related to access control
Projects
None yet
Development

No branches or pull requests

2 participants