Client signing client version of an object VERSUS Server signing server version of an object

[bumblefudge]

on today's call, @trwnh mentioned that client versions of activities and server versions often differ in two main ways:

1. id are optional and often assigned by the server in many of today's implementations
2. bcc gets dropped from the version server sends to the to recipients

so client-signatures being checked at time of import would maybe be slightly different? should [ideal future] servers keep the "private", client-signed copy of all activities (analogous to the copy in an email "sent" folder, now that i think about it!)

[trwnh]

Essentially the issue here is that the client activity and the server are not the same activity, yes -- we see this in the following points:

1. id is Server-generated in the AP spec; Client-generated id MUST be ignored
2. bto/bcc gets stripped by the server
3. Client Update is partial patch while Server Update is full replace Section 6.3.1 C2S Partial Update property deletion behavior is impossible and should be deprecated w3c/activitypub#477 (comment)

We therefore conclude that:

4. The Client's Activity is actually a blank node in an RDF sense
5. The Client's Activity is at most considered the input that the Server uses to generate the canonical version of the activity (as performed by the actor which lives on that server and is only being controlled by the Client)

And we additionally note that:

6. The Client cannot sign what the Server generates before-the-fact; it can at most sign the generated Activity after generation, or it can sign its own input; the Server must then support a mechanism for either allowing arbitrary clients to add their signatures to server-side activities, or otherwise preserve the client input somehow (possibly via an extension property, but this can get really complicated because:
7. Oftentimes an agent does not actually want to expose every single property from the client's input, but withholding these private properties from the served representation will invalidate the signed proof, because the signed proof covers information that a public consumer will not have. Therefore,
8. We would require a consistent algorithm for canonicalizing objects to account for all of the above points, or otherwise utilize a signature suite that allows us to only sign certain properties.

[bumblefudge]

Client-generated id MUST be ignored

So what you're saying is that... an FEP-e3e9: Actor-Relative URLs id applied and signed by the client would already have to be replaced by the currently-hosting server that that URL redirects to? That's neat, now the server already knows what the "permalink" will be for its version of the URL 😎

the tricky part is maybe figuring out how the SERVER returns to the CLIENT the "temporary URL" for that the id prop it creates (so that the client can update the forwarding table at the permalink service).

[bumblefudge]

(bonus-- an importing server that doesn't want to verify (or trust) those per-Activity signatures would at least have the Actor-Relative URL for each Activity, since that's the version signed by the client and exported... which combined with a DNS proof-of-control for that domain apex... see where I'm going here?)