I’ve added a new section titled “Reciprocal claims”. This is about bi-directional verification that we discussed earlier, the mechanism that enables trusted relationships across origins.
The description of the same-origin policy has been improved too:
Different origins are considered potentially hostile and are isolated from each other to varying degrees. Actors sharing an origin are assumed to trust each other because all their interactions are mediated by a single piece of software operated by a single person or an organization.
This part is still not universally true — multiple softwares can run on subdirectories of the same origin, where each prefix represents a trust boundary. Two actors on the same origin do not automatically authorize each other to perform actions against the other actor. The missing bit is that you can’t authenticate such identities without something like CIDs or DIDs — the TLS certificate is only valid for the origin. Similarly, another missing piece is that you should be able to make claims about prefixes and subresources.
I really feel like there should be guidance that basically taken to its logical conclusion, actors SHOULD have their own origins. Otherwise the security assumptions are invalid.
I agree, there are many ways to deploy and operate a server, and security boundaries dictated by the same-origin policy are somewhat arbitrary. But they are easy to enforce (because comparing origins is easy), and developers have a lot of experience with navigating them on the Web.
A single DID authority may manage multiple actors.
Giving every actor an origin would be nice, but why assumptions are invalid otherwise? They can be invalid only if there exists an ActivityPub server that works differently. If that software product is important enough to make life harder for everyone else, then we can discuss how to change the requirements in the FEP.
But, as far as I know, the only software where actors can create arbitrary objects on the server is the one I am developing, and it does not invalidate the assumptions of the origin-based security model.
If the server allows clients to upload arbitrary files, it MUST serve media from a different origin (e.g. from a different subdomain).
This is an improvement that should limit the damage of same-origin assumption.
In some cases ownership might be implicit. Examples:
Inbox and outbox collections are expected to be owned by the actor to which they are attached.
A replies collection is owned by the actor to which the post is attributed.
All pages of a collection are expected to be owned by the same actor.
I think this is somewhat ambiguous because it could be argued that the server owns those collections, not the actor. There is some association between those collections, but it is not exactly “ownership”. Relatedly, FEP-5711 attempts to define “inverse properties” linking back to the actor or object without having to claim a direct attributedTo relationship. I am not completely sure if this is the best approach, but it does at least avoid the “ownership” ambiguity.
In any case, if this is to be called out in FEP-fe34, then probably it makes sense to call out the other collections (likes, shares, followers, following, liked) and not just replies.