How to identify the person behind the user for permission purposes


#1

On the social web fediverse, generally you post stuff to your homeserver, and if you ever edit stuff, it’s on your homeserver. But in my use case, it’s possible there’s a collaborative document on another server, and you’re granted permission to send edits to the document, and that other server needs to identify you, to know you’re the same person from earlier before it applies your edits.

Suppose a user joe on server A wishes to edit some resource on server B. Suppose server B grants them permission to do so. Now, server A shuts down, and a new server is launched on the same domain name, and it has a user joe but it’s a different person. Suppose this new joe wants again to edit a resource on server A. How does server B know that this joe is a different person despite having the same actor ID and a valid HTTP signature?

Ideas:

  • Can the HTTP sig be treated as permanent? i.e. if the sig is invalid and we re-download the actor and it has a new key, do we assume it’s a different person? Do Mastodon, Pleroma, etc. do that or do they just silently re-download the new key and otherwise DB and UI treats it as the same user joe?
  • If we don’t use HTTP sig for this:
    • Server keeps a permanent private key, if it changes we assume a new instance launched and all users are assumed to possibly be new people, we reject edit permission
    • Same, except the server periodically generates a new key to avoid crypto linking all the published stuff forever. Is that even possible, does it help?
    • Server keeps permanent private key separately for each user
    • Same, except private key is on user’s laptop, they sign their POSTs and their home server just delivers the signature to other servers, so that private key remains in user’s hands

I’m wondering which one to choose! Any advice and insight highly appreciated :slight_smile:


#2

Hi there!

There is maybe an easier way to handle this case using Object Capabilities. Basically, you could craft a unique URL giving access (read, write or both, based on your needs) to the shared resource.

Joe’s server would store this URL, granting Joe access to the resource. Then, if Joe’s server is reinstalled and the database cleaned, the unique link is not available anymore, so Joe loose their access (like when you loose you house keys). You could also revoke the link on the resource server (same as changing the house locks).


#3

@eliotberriot thank you so much for the feedback! Its a great idea. But I’d like to read about it to figure out exactly how it works. I assume the capability URI can’t be freely copied, given by Joe to his friends, so there is still some form of authentication. I’ll read about it :slight_smile:


#4

Just in case anyone is curious,

I read about object capabilities and figured out a way to implement my use case with them. They fit the use case very well. The alternative was basically to use sort of ACLs, and having to be able to identify the person who sends the activity. Instead, with OCAPs the resource sends the actor a signed document, which the actor sends back to the resource when they want to access the it. And the resource verifies its own signature on the document.

This allows, at least under some sane assumptions (these may exclude cases where you require editors to GPG-sign their work with a known key that can’t freely rotate, but this has a solution too: simply use that key to sign the activity instead of a rotating server-generated key), to authorize remote edits using the existing possibly-rotating keys used for HTTPSigs and LDS on the Fediverse, given that the actor’s server is able to store capability documents for later use (or take them from the client program the user runs). And it gives security and flexibility benefits over managing ACLs.


#5

You may want to have a look at https://blog.dereferenced.org/what-would-activitypub-look-like-with-capability-based-security-anyway too, it’s a blog entry by one of Pleroma’s maintainer that cover this topic :slight_smile: