https://datatracker.ietf.org/doc/rfc7239/
-
@tedu i guess that's true for objects but not really for activities. if you signed only the digest for activities, then you could intercept and record a Create activity and replay it even after they send out a Delete. the next counterstep would be to include/require a timestamp within every activity, i guess. which... it's probably "enough" to include the timestamp anywhere, really? in the activity, in the http request, in the ld sig, whatever.
-
@trwnh yeah, so I think if we can get everyone to agree to relax sig checking to only date and digest, it would allow forwarding without the complication of ld sig. so, uh, good luck.
For something like Create, we could also use the published time in the activity, and if it looks old, reverify by fetching.
-
@tedu i think that wont work for private messages
the initial conceit was, we could still get rid of ld sigs and even keep replay prevention by forwarding the original signature using the Forwarded: header. this requires storing no additional info, just verifying the forwarded signature (and verifying the same-origin policy, which is the real underpinning here). this assumes we don't care to authenticate the forwarder... which we might care, for example to prevent spam forwards.
-
@tedu worst case scenario, we verify two http sigs, but in return we do away with ld sigs entirely.
-
@trwnh I always thought giving everything an ID and just forwarding the URL was the best solution...
-
@trwnh that's still fine? The fetch the receiver does will be authenticated
-
@erincandescent what if it’s private
-
-
@trwnh isn't this a problem we have with fetching posts today?
-
@erincandescent how do you know the actor is authorized
-
@erincandescent not necessarily, it’s a bigger problem with inbox forwarding because you don’t actually know the recipients, you just know the collection id. and we’re trying to preserve the “single delivery” aspect of activitypub so that you *don’t* have to fetch anything
-
@erincandescent also the problem with fetching posts today is a lack of standardization of cross-domain authentication/authorization. you can do Authorization: Bearer or Authorization: Signature (with the finalized version of http message sigs) or you can authenticate directly at the remote site with IndieAuth or OIDC or OpenWebAuth or whatever. The hard part is picking one that everyone should support