FEP-ae97: Client-side activity signing

Warning

このFEPはまだ翻訳されていません。

ここから翻訳に協力することができます。

Summary

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.

History

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.

Requirements

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.

Registering an actor

Client creates portable actor objects according to FEP-ef61 and stores them.

Before registering a portable actor on the server, the client MUST generate an RSA key and attach it to actor object via publicKey property, and also add it to the assertionMethod array as described in FEP-521a. Then it MUST add the server URL to the gateways array of the actor object.

To register the actor, the client MUST send an HTTP POST request to the gateway endpoint at /.well-known/apgateway path. The body of the request MUST be an actor object. The request MUST have an X-Rsa-Secret-Key header containing the previously generated RSA secret key in secretKeyMultibase format described in section 2.3.1.2 Multikey of Data Integrity specification.

If the server accepts registration request, its response MUST have 201 Created status code.

Sending activities

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 activity. Instead of assigning a new ID, the server MUST verify that provided ID has not been used before. If activity ID is in compatible format (HTTP(S) URI), the server MUST check that its origin is the same as the server's origin. 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.

Receiving activities

Client receives activities by polling the actor's inbox.

Requests to inbox endpoint MUST have an HTTP signature created using the RSA secret key generated during registration.

実装

参考文献

著作権

CC0 1.0 ユニバーサル (CC0 1.0) パブリック ドメイン

法律で認められる範囲において、この Fediverse 拡張提案の著者は、この作品に対するすべての著作権および関連する権利または隣接する権利を放棄しています。