Federation: Backlinks Authentication

changed milestone to %0.7

mentioned in issue management/core-team#3

mentioned in issue #235

mentioned in issue #232

mentioned in issue #254

Ping @calummackervoy our best bet there would be to follow the proposals here: https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization

Which are to implement either HTTP Signatures or Linked Data Signatures.

Djangoldp_activitypub actually signs the requests with HTTP Signatures: https://git.startinblox.com/djangoldp-packages/djangoldp-activitypub/blob/master/djangoldp_activitypub/security/signing.py

Thanks this is great! I suppose the only thing missing is, which server's signatures do I trust?

A system for now

with the signing key from the actor's publicKey field

At the moment the actor in the backlinks request is the "Backlinks Service", because it's not possible to tell from signals such as post_save, post_delete, m2m_changed, who performed the action. When I join a circle in Nantes it's also technically my backlinked Nantes user which joined the circle, and so Nantes will not be able to sign the request using my Parisian public key

Because of this, to start with at least, the server's themselves will need to have a key which they sign the activities with. The receiver servers will then need to keep a list of servers and public keys whom they trust. This could be done with a model, updated from the admin panel. This is possibly not the easiest/most automated UX, even doing it via a script would take time to collect the public keys and actor information for each server in a network

I've estimated 2 days to set this up

A system for later

Ideally it should be up to the user if they want to join a circle from Nantes. In Mastodon, the user decides if they trust a server by following an account from that server

The first step to realising this is to have the user be the actor of a backlink, which will require us to think about how the user joins the Nanteais circle

@balessan I'm not sure I'm still happy with the specification I wrote here

The receiver servers will keep a list of servers and public keys whom they trust

This is a bit like the problem we were discussing the other day with the Solid app permissions, it's giving total trust to the server or nothing

The main issue in the short term though is that it will be a pain to add new servers to the federation

It should be up to the user if they want to join a circle from Nantes

True, but again I think it's related to the discussion about client app permissions... it's about fine-grained (data-based) server-to-server permissions pivoting around the agent involved in the action... makes your head spin

In Mastodon, the user decides if they trust a server by following an account from that server

the main difference is that Mastodon can design it just for Followers and Toots, because it's an application. Our need is for a system which works with any model, not just Circle, which is a lot more complex

The receiver servers will keep a list of servers and public keys whom they trust

@jbpasquier for this (the short term).. is it possible to base the list of servers who I trust from LDPSource, or is this a subset ?

The long-term I think will become more clear after we've made progress with DPoP and the Solid permissions tasks... in general we know we're heading towards:

authenticating the agent of the activity, via the server which sends it
authorising the agent, probably using LDPBasePermission.has_container_permission and LDPBasePermission.has_object_permission from !193 (merged) , notwithstanding changes incurred by the specification we discussed last week

it's giving total trust to the server or nothing

Actually if we are able to send the correct agent with the backlink and authorise them then we resolve this criticism. Currently the agent is the backlinks service of the sender so we would need to replace this first

Are you following ? if all is well with this proposed change then I'll rewrite a better spec