FEP-ae97: Client-side activity signing

Standards Fediverse Enhancement Proposals
, ,
21

Updates:

22

Reverting back to C2S authentication based on actor keys: #618 - FEP-ae97: Main actor key - fediverse/fep - Codeberg.org

23

Yet another update, Media API: #682 - FEP-ae97: Update proposal - fediverse/fep - Codeberg.org

24

I’m a -1 on that form of the media upload API, rather than trying to use a .well-known URI that would need to be registered with IANA, we should instead use the uploadMedia endpoint in the Actor document.

This endpoint is defined here: SocialCG/ActivityPub/MediaUpload - W3C Wiki

Though it should be possible to upload media without an associated Object payload, and also be possible to delete uploaded media (erroring if it’s attached to a published object)

1 Like
25

FEP-ae97 deals with portable actors that are managed by clients. These actor documents may be served by multiple servers (gateways) and there is no single endpoint that a client could add to the endpoints mapping.

But I agree that introducing yet another well-known URI is not optimal. Maybe there should be a single discovery endpoint similar to /.well-known/oauth-authorization-server from RFC-8414.

Good point about deleting media. I will probably use DELETE /.well-known/apgateway-media/{hashlink} for that.

1 Like
26

I just noticed.

The example in:

should have an id.

At least if you want to be compatible to

1 Like
27

This is not intended to be a valid controller document. Just an ephemeral JSON document with similar fields.

28

Another update: #691 - FEP-ae97: Delete media - fediverse/fep - Codeberg.org

  • Added GET /.well-known/apgateway endpoint for detecting whether the server supports FEP-ae97 clients or not. Thanks @MediaFormat for suggestion!
  • Added DELETE /.well-known/apgateway-media/{hashlink} endpoint for deleting media. Thanks @thisismissem for suggestion!
1 Like
29

Update: #813 - FEP-ae97: Update proposal - fediverse/fep - Codeberg.org

There is now a sequence diagram explaining the registration process: https://codeberg.org/fediverse/fep/src/branch/main/fep/ae97/fep-ae97.md#registering-an-actor

New implementations:

  • fep-ae97-web-client - proof of concept web client (WASM).
  • Mitra Mini - a new feature-complete client for Linux. This is where most of the development will happen going forward.
30

Is there a reason why this only supports RSA keys?

31

The key returned by a server will be used for creating HTTP signatures. At present, only RSA signatures are supported in the Fediverse, so we have to use RSA keys.

However, a server may include additional keys in its response:

If the server’s response contains other keys, they SHOULD be added to the assertionMethod array as well.

1 Like
32

I think it’s understandable to have to use RSA keys currently. However, the way this FEP is written, it seems like RSA keys will always have to be used.

If the server’s response contains other keys, they SHOULD be added to the assertionMethod array as well.

And that makes it seem like these are just in addition to the mandatory RSA key.

1 Like
33

I think RSA keys will be required for federation in the foreseeable future, but I don’t want it to sound like they will always be required.

How would you amend the text?

34

@teohhanhui I updated the FEP with a clarification: https://codeberg.org/fediverse/fep/pulls/873

At a minimum, the server SHOULD provide an RSA key, because other signature types are not widely supported in Fediverse.

1 Like