FEP-db0e: Authentication mechanism for non-public groups

Hello!

This is a discussion thread for the proposed FEP-db0e: Authentication mechanism for non-public groups.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.

Summary

This proposal addresses the problem of authenticating access to the content of non-public groups. It is mostly intended to supplement [FEP-400e].

Only the server that hosts the Group actor knows for sure who can and can not access the content in the group. However, due to each object being hosted on the server of the actor that created it, it is not ordinarily possible for those other servers to restrict access to that object only to those actors who have the permission to see it.

This FEP defines an authentication mechanism, “actor tokens”, that allows an actor to issue tokens that serve as a temporary proof of group membership for other servers.

1 Like

Why not simply use HTTP signature ? Thanks to the proxyUrl endpoint, it’s easy for a user to authenticate to a remote server.

I didn’t write this FEP (it was published by @grishka), but I think the described mechanism could be used when the list of group participants is hidden.

When a group server Adds a Note to a group feed, and that Note originates from a different server, participants need to authenticate it by fetching it from the server of origin. The server of origin may not know which actors are members of the group - “actor token” provides that information.

That endpoint seems like it’s intended for C2S ActivityPub and it doesn’t even do what I want.

I want to have federated privacy. The token is a proof that this actor is a member of this group and can thus see this object.

2 Likes

Thanks for this FEP, it made me realize that this case wasnt handled properly in Lemmy’s private group implementation (not released yet). However I came up with an easier solution which doesnt require any complicated token. Basically its like this:

  • Private group hosted on alpha
  • User on beta follows the group and makes a post
  • User on gamma follows the group and attempts to fetch post from beta
  • This would normally fail as beta has no way to know if gamma user is a member of the private group
  • Instead beta makes an http request to alpha with /c/{name}/followers?is_follower={gamma user id}
  • If this returns status 200, gamma is confirmed as follower and beta can return the post.

This will also work, but it has the chance to ddos the “alpha” server if someone is fetching many objects all at once from different servers. The idea with my approach is that only one request to that server is made, and then the token can be verified autonomously by any other server during its validity period.

1 Like

In Lemmy this case of fetching an object happens very infrequently, basically only when a user directly searches the url. So I dont expect any performance problems.

In Smithereen I would fetch the entire wall and all photos in all albums when someone joins a group. So it’s not frequent, but it’s a lot of data loaded at once from possibly many different sources.

1 Like

A way to advertise collection membership endpoint was proposed by @evan in membership endpoint · Issue #462 · w3c/activitypub · GitHub

However,

What if the post has an integrity proof (FEP-8b32)? Then gamma wouldn’t need to fetch it.

Yes its basically the same thing.

What if the post has an integrity proof (FEP-8b32)? Then gamma wouldn’t need to fetch it.

This mechanism is only used when a user explicitly pastes the url of a post into the search bar in order to fetch it. Its not used for handling incoming activities.

1 Like