w3c / activitypub

http://w3c.github.io/activitypub/
Other
1.22k stars 77 forks source link

as:Authenticated proposal #339

Closed kaniini closed 3 months ago

kaniini commented 5 years ago

Description

This issue proposes adding a new security label to ActivityPub alongside as:Public called as:Authenticated.

The as:Authenticated security label would behave like as:Public but, in a compliant implementation, only allows any authenticated user to view the object.

The as:Authenticated security label would be represented over the wire as https://www.w3.org/ns/activitystreams#Authenticated.

Motivation

Recently there have been a few high profile incidents involving wholesale archival of fediverse instances. This has lead to many users expressing unhappiness as they had "buyer's remorse" considering their decision to label posts as as:Public.

Discussion frequently reveals that users commonly fall back to as:Public instead of sending to their followers collection due to motivations of reaching a wider audience of fediverse participants, but do not consider the possibility of permanent archival.

By introducing a new security label, as:Authenticated we introduce an alternative to as:Public for users who wish to make posts that any fediverse participant may interact with which excludes unauthenticated guest users.

JSON-LD Context

{
  "@context": [
    {"as": "https://www.w3.org/ns/activitystreams"},
    {"Authenticated": "as:Authenticated"}
  ]
}

Security Considerations

Rogue Implementations

This section is non-normative.

The Fediverse is an open world network built on top of the ActivityPub and related standards. Accordingly, an implementation may choose to be intentionally non-compliant with certain aspects of the protocol, such as not enforcing security labels or limiting access to specified collections. This threat is not changed by this proposal, but a compliant server would ideally provide a way to make trust assertions about it's peers which includes limiting what objects are shared with those peers.

Authenticated Fetches

When as:Authenticated objects are Announced through the network, they should be referenced by their id. The recipient of the Announce MUST make an authenticated fetch using HTTP Signatures using a key belonging to an actor on the server. The server would ideally use a server-specific actor's key instead of a user's key if one is present.

The server which hosts the as:Authenticated object being fetched SHOULD verify that the signature belongs to a key which belongs to an instance that is authorized to fetch the object. The specific logic for determining whether an authenticated fetch is allowed is unspecified and implementation dependent.

evanp commented 3 months ago

I'm going to close this ticket, since a FEP is in progress. New commenters should follow the work at https://codeberg.org/fediverse/fep/src/branch/main/fep/7502/fep-7502.md .