FEP-3b86: Activity Intents

Standards Fediverse Enhancement Proposals
, ,
1

Hello!

This is a discussion thread for the proposed FEP-3b86: Activity Intents.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.

Summary

Activity Intents extend the capabilities of an ActivityPub server beyond a user’s inbox, and simplify the process of interacting with content on the wider social web. They do this by publishing a machine-readable list of public URLs where users can perform key activities (such as Follow, Like, or Announce) allowing other websites to easily initiate remote social interactions.

1 Like
2

@benpate what happens if the object isn’t found, does the server automatically redirect back to on-cancel? That sounds like it’d be an open-redirect vulnerability, in which case, if the object doesn’t exist it should probably return a 404.

3

Also, why hyphen case for on-cancel and on-success ? Shouldn’t these be onCancel and onSuccess ?

4

I hadn’t considered what would happen if there was an error on the home-server side. It makes sense that it would just display an error page, which should prevent the “open-redirect” issue. I can update the FEP to mention this.

5

I don’t have a very strong case for one way or the other. I do think these should be distinct from ActivityPub activities and properties so that they stand out as different, for a different purpose.

I’m open to suggestions on how to accomplish this better.

6

I think consistency is probably important. Probably also add language that implementations should (or even must) allow the user to choose to continue to the return URL, I’m not sure an automatic redirect is desirable here, and it lacks the security properties that OAuth’s redirect URIs have, since those need to be preregistered, such that you can’t just be taken off to any random place.

An “open redirector” is an endpoint on a web server that forwards a user’s browser to an arbitrary URI obtained from a query parameter. — OAuth 2.0 Security Best Current Practice § 1.2

In the current security best practices, it’s recommended that you even display the redirect URI before the user approves the authorization request: OAuth 2.0 Security Best Current Practice § 4.11. Open Redirection.

You could perhaps also borrow a leaf from OAuth 2 where you have a single redirect_uri which has query parameters indicating success or failure. e.g., you could redirect back with the new object ID on success, and on failure redirect with an error code and description. Those errors could then be more concretely defined.

I’m not sure how one would otherwise prevent an open redirect attack.