ipfs / pinning-services-api-spec

Standalone, vendor-agnostic Pinning Service API for IPFS ecosystem
https://ipfs.github.io/pinning-services-api-spec/
Creative Commons Zero v1.0 Universal
100 stars 27 forks source link

Multidevice use case #7

Open Gozala opened 4 years ago

Gozala commented 4 years ago

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 commented 4 years ago

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

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...

Gozala commented 4 years ago

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).