@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
Posts
-
https://datatracker.ietf.org/doc/rfc7239/ -
https://datatracker.ietf.org/doc/rfc7239/@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
-
https://datatracker.ietf.org/doc/rfc7239/@erincandescent how do you know the actor is authorized
-
https://datatracker.ietf.org/doc/rfc7239/@erincandescent what if it’s private
-
Hmm... Terrible Comment.Hmm... Terrible Comment.
-
https://datatracker.ietf.org/doc/rfc7239/@tedu worst case scenario, we verify two http sigs, but in return we do away with ld sigs entirely.
-
https://datatracker.ietf.org/doc/rfc7239/@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.
-
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.
-
https://datatracker.ietf.org/doc/rfc7239/@tedu we're basically saying that for POST requests, not only do you need to verify that the content was unmodified, but also you want the signature to only apply to the POST /inbox request made at a certain Date to a certain Host. this prevents replay.
-
https://datatracker.ietf.org/doc/rfc7239/@tedu like, if you signed only the digest then would that be "enough"? these kinds of security decisions aren't really documented anywhere
-
https://datatracker.ietf.org/doc/rfc7239/@tedu arguably if it doesn't matter then it shouldn't be signed, but this whole thing is fucked six ways to sunday so whatever i guess
-
https://datatracker.ietf.org/doc/rfc7239/@tedu i don't know why the destination would accept it, or on which grounds. typically the signature contains "(request-target) Host Date Digest" and all of those have to be faithfully reproduced or else the initial signature won't validate. the authoring server cannot know the request-target or host ahead-of-time, since that information is only known by the forwarding server.
-
https://datatracker.ietf.org/doc/rfc7239/@tedu actually, wouldn't the Host and (request-target) mismatch too?
-
https://datatracker.ietf.org/doc/rfc7239/@tedu wouldn't the Date header mismatch?
-
https://datatracker.ietf.org/doc/rfc7239/POST /inbox HTTP/1.1
Host: mastodon.example
Signature: ...
Forwarded: Signature=""could this work? anyone interested in collaborating with me on a FEP for this? potential review/adoption by implementers? right now, inbox forwarding is pretty neglected as it depends on LD Signatures which are out-of-standard. @ me if you have any input!
-
https://datatracker.ietf.org/doc/rfc7239/https://datatracker.ietf.org/doc/rfc7239/
Maybe useful for inbox forwarding when combined with HTTP Signatures? The parameters of the original HTTP Signature could be included in the POST for the forwarded activity...
-
Updated to ios 17.5.@tedu bono must be sad
-
Do you say "Fediverse" or "Social Web"?@evan the concept predates the working group, so i’d say the Social Web Working Group was named after the thing it tried to write specs for, not the other way around
-
@terrain @evan non-web protocols being part of the social web is a bit of a stretch imo -
Do you say "Fediverse" or "Social Web"?@evan they've got different meanings to me. fediverse is specifically the federated parts, activitypub et al. social web can mean any interoperable interlinked part, not necessarily federated.