Document authorized fetch

[evanp]

The Mastodon service has a feature called authorized fetch that requires HTTP signature authentication for any GET request for objects on the server, even if the object is publicly readable. Some other software also supports this feature.

The advantage of this feature is that it can be used to enforce server blocks and user blocks. It gives an authorization model of "everyone except these actors: ...".

We should document this pattern in the Primer to make it easier for developers to interoperate with other servers.

[trwnh]

Tagging #339 as tangential to this, since "authorized fetch" is technically a spec violation for the definition of as:Public

[snarfed]

Thanks @trwnh!

Also, tangent, it'd be nice to maybe try to rename this to "authenticated fetch," which seems more accurate. Not sure if we're too late there though 😁

[trwnh]

to be precise, it's really "signed fetch" since it uses http signatures (cavage draft 08). one could imagine a similar mechanism which works on bearer tokens or pre-shared secrets or what have you. AUTHORIZED_FETCH is just the environment variable that mastodon uses to refer to the feature

edit: this is a bit pedantic to be sure but "authorized fetch" to me evokes a sense of using the http Authorization header whereas "signed fetch" signals that we are using the http Signature header.

[nightpool]

In this case, "authorized fetch" is referring to the fact that the origin server has enough information to make an authorization decision. (e.g., to enforce blacklists)

On Wed, Dec 13, 2023, 2:43 PM trwnh @.***> wrote:

to be precise, it's really "signed fetch" since it uses http signatures (cavage draft 08). one could imagine a similar mechanism which works on bearer tokens or pre-shared secrets or what have you. AUTHORIZED_FETCH is just the environment variable that mastodon uses to refer to the feature

— Reply to this email directly, view it on GitHub https://github.com/w3c/activitypub/issues/402#issuecomment-1854673246, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABZCV3G4UGFYAZMV7NQMVDYJIHORAVCNFSM6AAAAABATRY5IKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJUGY3TGMRUGY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[cristianolongoodhl]

please consider that HTTP Signature is not a Recommendation, but just a dead draft

[tesaguri]

please consider that HTTP Signature is not a Recommendation, but just a dead draft

Could you elaborate on the phrase, a dead draft? It's true that HTTP Message Signatures is an IETF Internet Draft rather than being a W3C Recommendation, but its latest draft is marked as Active.

[trwnh]

HTTP Message Signatures is not the same as HTTP Signatures. The active draft replaced the older Cavage draft that the fediverse currently uses. The Cavage draft is what is considered "dead".

[snarfed]

Understood! The goal here isn't to specify anything normative anywhere, it's just to document the fediverse's already widespread existing usage of HTTP Sigs, especially the subset of instances that currently require them on object fetches. We can definitely mention loudly in that documentation that that the Cavage HTTP Sigs standard is "dead," or whatever the most appropriate term is.

[snarfed]

I took a stab at documenting authorized fetch and instance actors as they stand today in the wild. Feedback is welcome! https://www.w3.org/wiki/index.php?title=SocialCG%2FActivityPub%2FAuthentication_Authorization&type=revision&diff=116867&oldid=116776

[evanp]

Since this ticket was opened, the SocialCG decided to start a whole Report on ActivityPub and HTTP Signature. We now have a very useful draft report at https://swicg.github.io/activitypub-http-signature/ including a whole section on Authorized Fetch at https://swicg.github.io/activitypub-http-signature/#authorized-fetch . I think this resolves the issue, and since I'm the original requester I'm going to use my prerogative to close the ticket.

[evanp]

I added a new issue to make sure the AuthC/AuthZ primer page is synched with the HTTP Signatures report. #435