Concept for discussion: Replacing HTTP Signatures with Bearer Tokens for ActivityPub Federation

Curious what other people think about this idea. What if federation security was re-worked to use target-assigned bearer tokens to authenticate GET/POST requests? This would remove the need for complicated signing schemes and reduce system load under heavy traffic bursts (as no cryptography is required).

A basic implementation could look like this:
1. When instance A (a.example.com) first attempts to federate with instance B (b.example.com), a POST request is made to a dedicated registration endpoint. (for discussion, we'll say it's https://b.example.com/activity-pub/register-instance). This request includes fields necessary for verification, including the source domain name, target domain name, and a securely-generated verification token. Other metadata could be included to allow instance B to selectively allow/prohibit federation based on other criteria, but this is optional.
2. Instance B makes a POST request back to a dedicated verification endpoint on instance A (for discussion, we'll say it's https://a.example.com/activity-pub/verify-registration). This request must include the target domain name and verification token provided in step 2.
3. Instance A checks the verification token (and verify that it matches the target domain name) and return a successful value. The verification code must be invalidated after this call!
4. Instance B, after verifying instance A's request, returns a securely-generated federation key back to instance A. This federation key is a bearer token used to authenticate all requests from instance A to instance B. This key must be unique to instance A!
5. Instance A completes the original request with the Authorization header set to Bearer {federation_key}.
6. Instance B receives the request, detects the federation key, and checks it against the list of registered instances.
7. If the key does not exist or A has been defederated, then a 403 Forbidden error is returned.
8. If the key is expired or revoked, then 401 Unauthorized error is returned. Upon receiving a 401 error, instance A should start over from step 1 to re-authenticate and complete the request with a new token. This process should not be repeated for recursive failures!
9. If the key is approved, then a 200 OK response or 202 Accepted response is returned, and A can consider the request as successful.

Advantages versus HTTP Signatures:
- No cryptography requirements.
- Simple logic, no edge cases around HTTP query parameters or header order.
- Equally effective for all request types.
- Keys can be easily revoked or rotated.
- Supports authorized fetch and defederation use cases "by default".

Disadvantages versus HTTP Signatures:
- Breaks the actor model - instances are required as a first-class concept. (but really, the actor model is basically dead already. you can't even federate reliably without a WebFinger server, at minimum.)
- Requires multi-request "handshake" before communication. (but this is already required in practice, since a signature can't be validated without first requesting the signing actor.)
- Out-of-band protocol - communication can't happen over ActivityPub / ActivityStreams because this is a prerequisite to authenticate any request. (but again, we already require WebFinger and some software requires NodeInfo for full support.)

So, what are your thoughts? Good idea? Bad idea? Did I miss something? Please let me know, I welcome replies here!

#ActivityPub #AP #Federation

@kopper@not-brain.d.on-t.work sure, but I actually prefer this being out-of-band since it's much simpler to implement and verify. Not everything needs to be a relational document, especially not authentication data with secrets!

@kopper @hazelnoot

Not knowledgeable enough on the subject, but saw @cwebber a couple of times advising UCAN as currently the best choice in anticipation of more of the OCapN efforts to become available. If we start looking on very different approaches, I wonder how - if at all - UCAN fits in, and whether someone is already exploring that direction.

Also I'd be in favor of going a direction that brings fediverse closer to actor model again, rather than further away.

https://ucan.xyz

@kopper @hazelnoot @cwebber

I wonder at what cost backwards-compatibility should for always be retained, and what kind of fediverse that'll give us in the future.

The other day I had a good brainstorm with @trwnh and @steve about an AP-compliant protocol extension returning to the promise of the conceptual architecture. Actor model + service-orientation.

Breaking compat with masto-flavored fedi and abstractions introduced but not part of the spec. No sharedInbox, etc.

Protosocial ActivityPub protocol

Protosocial ActivityPub v1.0.0 Pro-social protocol suite for the social web, based on ActivityPub Protosocial ActivityPub protocol is an extension of W3C ActivityPub that focuses on ease of use for the developm…

Discuss Social Coding (discuss.coding.social)

@kopper @hazelnoot @cwebber @trwnh @steve

You are most welcome to join the Groundwork labs matrix chatroom, which is themed to discussing how we can "lay the groundwork", the foundational technology base, for the next-gen social web.

You're invited to talk on Matrix

You're invited to talk on Matrix

(matrix.to)

@smallcircles@social.coop @kopper@not-brain.d.on-t.work @cwebber@social.coop @trwnh@mastodon.social @steve@social.technoetic.com I appreciate the invite, but I get the sense that I would be ideologically at odds with everyone else ​​

@trwnh@mastodon.social @steve@social.technoetic.com @smallcircles@social.coop @cwebber@social.coop @kopper@not-brain.d.on-t.work as an example, this:

an AP-compliant protocol extension returning to the promise of the conceptual architecture. Actor model + service-orientation.

Breaking compat with masto-flavored fedi and abstractions introduced but not part of the spec. No sharedInbox, etc.

@hazelnoot @steve @smallcircles @cwebber @kopper

> as someone who builds and operates [...] platforms

yeah, this is probably the fundamental distinction. anyone is free to agree or disagree with anything, but my personal direction is to do away with siloed platforms and make it easier to maintain personal websites. it's less about federating platforms and more about making the web be the platform. current fedi is more syndication than federation

@trwnh@mastodon.social @steve@social.technoetic.com @smallcircles@social.coop @cwebber@social.coop @kopper@not-brain.d.on-t.work that divide explains a lot, actually. The difference in goals might be causing much of the bikeshedding and conflict that tends to stall major changes to AP. Not sure what to do about that now, though

@hazelnoot @kopper if i had to guess at what's leading to stalling, it's probably more that some aspects of the specs were not fully developed in time, and fedi made some choices based on incomplete guidance that resulted in tech debt, and now some factions want to fix the problems, while other factions want to ratify the problems. i guess you could chalk this up to "difference in goals" but there's also a certain amount of resistance to paying that tech debt.

@trwnh@mastodon.social @kopper@not-brain.d.on-t.work that makes sense. I'm honestly conflicted on that, since I'm generally in favor of fixing tech debt but this situation carries a strong risk of fracturing the network. Fedi admins are kindof infamously bad at updating...

@trwnh@mastodon.social @kopper@not-brain.d.on-t.work like, people still use FireFish even though it has known unfixed vulnerabilities and clear migration path to supported alternatives.

@hazelnoot @kopper yeah, you'd need buy-in from existing softwares to implement some kind of transition period, but outside of mastodon recently i don't think anyone wants to charge ahead with new stuff. but mastodon doesnt want the responsibility of stewarding their own protocol, so it's convenient to paint it as a common approach to avoid concerns of "mastodon EEE" or whatever people are going to say when any attempt at progress is led by mastodon