Original motivations and use cases

[snarfed]

Briefly describe the original use case(s) and motivation(s) for using HTTP Sigs with AP, and how well they've addressed those use cases.

Origin (ie server side) authn was largely already provided by SSL, and the fediverse has broadly seemed to accept the current security model that user keys are custodial with servers, and both server and client side authn in practice is at the server (domain) level more than the individual user level. Given that, HTTP Sigs seemed primarily motivated by:

• Authenticating a GET's origin domain to allow authorized fetch and blocking/filtering by requester domain.
• Authenticating inbox delivery POSTs as an optimization so that servers don't always need to re-fetch objects to check that they're valid and not spoofed.

[snarfed]

First pass at text. Please revise!

---

ActivityPub lets different people and groups interact without an existing shared trust anchor. That's great! They still need some form of trust model, though, even if the protocol is decentralized. Specifically, they need to authenticate actors who send activities and serve objects, and they need to check whether those actors are authorized to send those activities and serve those objects.

The ActivityPub spec leaves authentication and authorization largely unspecified. It implies that authorization is a "same origin model" (not to be confused with web browsers): an actor can generally only create, update, or delete objects with itself as actor or attributedTo. Some of this is deferred to ActivityStreams 2.0.

ActivityPub leaves authentication similarly unspecified. In practice, the fediverse currently uses a custodial trust model: each user has one or more asymmetric keypairs. Instances (servers) are generally trusted to hold their users' private keys, serve their public keys, generate signatures, and serve their objects and send their activities in good faith. SSL is required for server-to-server HTTP connections in order to authenticate server domains.

This SSL requirement is the extent of authorization for HTTP GETs that fetch objects. However, ActivityPub does suggest HTTP Signatures and Linked Data signatures as additional mechanisms, and inbox delivery POSTs generally use both. They include HTTP Signatures from the sending actor, and sometimes also LD Signatures from the original actor for inbox forwarding.

This document describes the fediverse's current usage of HTTP Signatures, recommends best practices, and suggests directions for future work.

[snarfed]

More draft text:

---

Those are broad goals, and this report is limited in scope. Here are a number of non-goals that are intentionally not addressed or prioritized.

• Other nearby standards, ecosystems, or authentication mechanisms, eg JSON-LD, LD Signatures, Verified Credentials, etc.
• Authorization or access control.
• Reproducing the contents of existing standards like HTTP Signatures itself (either RFC or cavage-12), PEM/PKCS, SHA-256, ActivityStreams 2, Verified Credentials, HTTP headers, hash algorithms or cipher suites or cryptosystems, etc.
• Strict standards compliance, at the expense of interoperability.
• Providing the absolute strongest security possible, at the expense of interoperability.
• Security analysis of HTTP Signatures, ActivityPub, their integration, or individual implementations.
• Nomadic identity.
• Fragment handling in ActivityPub or ActivityStreams 2 ids, beyond the minimum needed to resolve keyIds.
• ActivityPub client to server, or generating signatures client side.

We also don't expect to update this report on an ongoing basis. It describes a single snapshot in time, when it was published.

Now that we've covered the introduction and background, let's get into the interesting stuff!