In order to understand why FEP-fe34: Origin-based security model is true, we need to derive it from the first principles. Let's try.

#ActivityPub objects are JSON documents with a special id property. This property is an URI indicating the location of a document, and we can authenticate a document by fetching its id. If the document exists at the specified location, and has the same ID, we conclude that it is valid.

This has several important corollaries:

1. The server of origin is the only authority. Other servers must not be trusted.
2. ActivityPub is fundamentally a "pull" protocol, not "push".
3. The type of a document is not relevant for authentication. Actor documents are not special.

However, fetching documents is not always practical, and developers may want to push data to other nodes. How documents can be authenticated without making an HTTP request? Digital signatures.

The server publishes a JSON document containing a public key, and then starts signing other documents with a corresponding secret key.

Upon receiving a signed document (such as activity), we determine the ID of a public key document, retrieve the document and verify the signature. If the public key document has the same server of origin as the signed document, and the signature is valid, we conclude that the signed document is valid too, because a chain of trust has been established: received document -> public key document -> server.

The public key document doesn't change often, so now we can verify many signed documents without re-fetching the public key.

This also has important corollaries:

1. Once again, the type of a signed document is not relevant for authentication.
2. Public keys do not need to be attached to actor documents.
3. One key per server is enough.

Developers are constantly being told that ActivityPub is an actor-centric "push" protocol, and that each actor must have its own key. But those ideas are wrong and it is time to put them to rest.

#fep_fe34