Existing Fediverse servers manage signing keys on behalf of their users. This proposal describes a new kind of ActivityPub client that lets users sign activities with their own keys, and a server that can distribute client-signed activities to other servers.
Initial version of this proposal relied on linking of cryptographic identities to actor objects via FEP-c390 identity proofs. That mechanism was superseded by FEP-ef61 which achieves full data portability.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC-2119.
Client creates portable actor objects according to FEP-ef61 and stores them. When a portable actor is created, the client MUST create a key for signing requests (the main actor key) and add a Multikey representation of it to the assertionMethod array as described in FEP-521a. The identifier of that key MUST NOT be a compatible identifier.
Before registering a portable actor on the server, the client MUST add the server URL to the gateways array of the actor object.
To register the actor, the client sends an HTTP POST request to the gateway endpoint at /.well-known/apgateway path. The body of the request MUST be an actor object.
The server SHOULD limit registrations (for example, by requiring an invite code). If the server accepts the registration request, it generates an RSA key and returns it in a response. The response MUST have the 201 Created status code. The body of the response is a JSON object with an assertionMethod property. The value of this property is an array containing the RSA public key generated by the server in the Multikey format.
Example:
{
"assertionMethod": [
{
"type": "Multikey",
"publicKeyMultibase": "z4MXj1wBzi9jUstyPMS4jQqB6KdJaiatPkAtVtGc6bQEQEEsKTic4G7Rou3iBf9vPmT5dbkm9qsZsuVNjq8HCuW1w24nhBFGkRE4cd2Uf2tfrB3N7h4mnyPp1BF3ZttHTYv3DLUPi1zMdkULiow3M1GfXkoC6DoxDUm1jmN6GBj22SjVsr6dxezRVQc7aj9TxE7JLbMH1wh5X3kA58H3DFW8rnYMakFGbca5CB2Jf6CnGQZmL7o5uJAdTwXfy2iiiyPxXEGerMhHwhjTA1mKYobyk2CpeEcmvynADfNZ5MBvcCS7m3XkFCMNUYBS9NQ3fze6vMSUPsNa6GVYmKx2x6JrdEjCk3qRMMmyjnjCMfR4pXbRMZa3i"
}
]
}
The client MUST attach the RSA key to the actor object via publicKey property, and also add it to the assertionMethod array as described in FEP-521a. If the server’s response contains other keys, they SHOULD be added to the assertionMethod array as well.
If the client uses compatible identifiers, then key identifiers MUST be generated with the server’s origin.
After updating the actor object, the client MUST publish an Update activity for it.
The client submits signed FEP-ef61 activities to actor’s outbox. Contrary to what ActivityPub specification prescribes in section 6. Client to Server Interactions, the server MUST NOT overwrite the ID of an activity. Instead of assigning a new ID, the server MUST verify that provided ID has not been used before. If the server accepts activity, its response MUST have 202 Accepted status code.
If activity contains a wrapped object (as in Create and Update activities), it MUST be a portable object created according to FEP-ef61. The server MUST validate object IDs in the same way it validates activity IDs.
The server MUST deliver activities to their indended audiences without altering them. When signing HTTP requests, the server uses the RSA key generated during the registration.
Client receives activities by polling the actor’s inbox.
Requests to inbox endpoint MUST have an HTTP signature created using the main actor key (the one generated by the client, not a server-generated key).
If the server accepts portable objects with compatible identifiers, it MUST ensure that all objects served by the gateway are valid and that registered actors are sufficiently isolated from each other. Specifically, the server MUST verify that actors and activities generated by the client do not violate the assumptions of the origin-based security model:
Precautions need also be taken when objects with compatible IDs are delivered to inboxes or fetched from remote servers.
CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
To the extent possible under law, the authors of this Fediverse Enhancement Proposal have waived all copyright and related or neighboring rights to this work.