I am curious now regarding the content that lead to bearcaps and it’s suggested usage in AP / AS / JSON-LD.
I am looking at it right now from a perspective where the nodes in the federation are the lowest level of trust. (like, S2S only, leaving out C2S for the moment.)
Given the use-case that it should be enforceable to stop objects from spreading outside of the follower-followed relationship boundary, e.g. when I post a note to my followers them, and only them, should be able to read the note. For the moment I would like to exclude Announce.
The naive way would be that when I compose the note and my server federates it via S2S, it will be sent to the servers of my followers. The receiving server will add the note to it’s internal storage and I trust the receiving server to show this note only to the users it was addressed to.
To ensure on our side that the note not (accidentally) is readable from the outside, we would protect it by authentication.
This then is it.
Because we trust the remote server not showing the note to people that are not the recipients, we can just give it the full note (Create
?) , object
being embedded and not a reference. Because the note is embedded the remote server does not need to care about that it cannot dereference the ID; it has everything it needs.
Now bringing in Announce
, Announce
and private note somehow are incompatible. Unless you Announce it just to the followers that are allowed to see the note. This announce then would only include an object
reference, because I think one can assume the receiving user’s servers already have the note. (More about what not later.)
Now reading the public outbox of the followed, the private note won’t be included there, because it’s the public outbox and private notes are inherently incompatible with public outboxes. Unless you are somehow authenticated and authorized. C2S could be impacted by this.
Thinking about authorization, only followers are allowed to see the note. So, for authentication it would be enough to prove I am a follower. The first thing that comes to my mind here is to prove it by signing the request using http signatures and (one of) my keys from my profile.
Now, authentication now can also happen via Authorization: Bearer ...
header, which is where a bearcap
could come into play. But this would mean that I somehow need a token from remote server, me the user, not my instance. The remote instance could give my instance a token and my instance could give the token to me. But it’s the stil the token of my instance.
This sounds strange to me. Why impersonating my instance when I also can prove that I am a follower / recipient?
Coming back to what happens if the sever receiving the Announce
does not have the object.
It will try dereferencing it and will fail with 403 or 404, due to missing authentication.
Knowing that private objects can exists, the server can retry with authentication.
But which? Above, for C2S proving to be a follower. Now, for S2S, the server is not a follower, but proving that it is the instance it says it is (via http signature) the remote server can authorize the server based on whether there are recipients on that instance.
Authentication could be via bearcap
again, but why use a token when I can prove who I am fine without a token?
Looking back at the Mastodon example it seems like the note has the recipients, if that’s wrong my argumentation will fall. (Because then I have no idea how the authentication who is allowed to see the note would work.)
So, if this is a use-case for bearcap
, why using bearcap
here?
This is out of curiosity, trying to understand the background, not really saying it’s all wrong how it’s done.
For me it’s easier to think about it when trying to solve the problem myself.