FEP-fe34: Origin-based security model

[silverpill]

Another update: #593 - FEP-fe34: Reciprocal claims - fediverse/fep - Codeberg.org

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.

[trwnh]

@silverpill

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.

[silverpill]

@trwnh

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.

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.

@trwnh

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.

This FEP is developed in parallel with FEP-ef61 (Portable objects), where same-origin policy applies to DID-based identifiers.

A single DID authority may manage multiple actors.

@trwnh

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.

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.