Documentation or Examples about proxyUrl, provideClientKey and signClientKey endpoints?

There is minimal documentation about these 3 endpoints in the AP specs:

proxyUrl
Endpoint URI so this actor’s clients may access remote ActivityStreams objects which require authentication to access. To use this endpoint, the client posts an x-www-form-urlencoded id parameter with the value being the id of the requested ActivityStreams object.

provideClientKey
If Linked Data Signatures and HTTP Signatures are being used for authentication and authorization, this endpoint specifies a URI at which browser-authenticated users may authorize a client’s public key for client to server interactions.

signClientKey
If Linked Data Signatures and HTTP Signatures are being used for authentication and authorization, this endpoint specifies a URI at which a client key may be signed by the actor’s key for a time window to act on behalf of the actor in interacting with foreign servers.

They however seem fundamental pieces for a proper Client-to-Server AP implementation. Does anyone have more informations about this, like examples of what these endpoints are supposed to accept and what they should return ? I could not find any specs about that.

For the proxyUrl endpoint, if the URI to be requested is provided via x-www-form-urlencoded, does it mean it only works for GET operations ? We would need it for POST, PATCH, PUT, DELETE operations as well, as we have implemented the Linked Data Plateform (LDP) protocol which allow all of them.

Thanks !

1 Like

For information I have implemented a basic proxy service in the SemApps code base:

It’s working fine, and being used actively in the ActivityPods project. Each user gets his own proxy endpoint, and he can GET remote data through it using HTTP signatures. It’s really a way to “act as the ActivityPub actor”.

I’m thinking about extending its use to allow other HTTP methods (POST, PUT, DELETE…). Looking on the Internet, it seems there is standard way to define proxy servers, defined in the HTTP protocol, where you use the full URL instead of the path in the request.

I would still be interested to have informations about what was intended in the ActivityPub specs.

1 Like

Can’t help you myself, but maybe point to AndStatus by @yvolk having most complete C2S client implementation to maybe test against.

Thanks @aschrijver, but I found nothing on the AndStatus repo about the proxyUrl, provideClientKey or signClientKey endpoints.

Maybe @cwebber, as the co-editor of the AP specs, has some insights about this part of the specs, or maybe they can give us some directions about who to ask to have more informations ?

I will just warn about the security aspects of signClientKey. If you have an endpoint where your site will sign arbitrary data, it could be used maliciously to sign HTTP requests and other stuff for misuse by bad actors. One would need to analyse the data and verify the source for acceptable use cases prior to returning a signature.

Looks like there has been recent discussions about the provideClientKey and signClientKey endpoints:

For ActivityPods, we have now extended the proxyUrl endpoint to accept non-GET requests. It is documented here:

Could you elaborate a bit?

The link to " ActivityPub proxy endpoint" page gives 404.