In this document we discuss the concept of ownership, as applied to ActivityPub objects.
[!WARNING] This FEP has been superseded by FEP-fe34.
ActivityPub standard does not specify authentication and authorization mechanisms.
Many implementations use actor and attributedTo properties (defined in Activity Vocabulary) to determine the validity of activities and objects. This proposal attempts to formalize the current practices and provide guidance for implementers.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC-2119.
Ownership is indicated by a property of an ActivityPub object. The name of this property differs depending on the object type:
id property.actor property, which describes the actor that performed the activity. This actor is considered to be the owner of the activity.attributedTo property, which describes the actor to which the object is attributed. This actor is considered to be the owner of the object.owner and controller properties.The owner of an object MUST be an actor.
[!WARNING] According to Activity Vocabulary,
actorandattributedToproperties can contain references to multiple actors. These scenarios are not covered by this document and implementers are expected to determine the appropriate authentication and authorization procedures on a case-by-case basis.
[!NOTE] In subsequent sections, “objects” and “activities” will be referred to as simply “objects”.
Object identifiers are grouped together into protection domains called “origins”. This concept is similar to the “web origin” concept described in RFC-6454, and origins of object IDs are computed by the same algorithm.
The same-origin policy determines when a relationship between objects can be trusted.
[!NOTE] There might be other ways to establish trust, but they are not covered by this document.
Identifier of an object and identifier of its owner MUST have the same origin.
The object is considered authentic if any of the following conditions are met:
POST request contained a valid HTTP signature created using a key whose owner has the same origin as the object owner.If none of these conditions are met, the object MUST be discarded.
If signature verification is performed, the key owner SHOULD match the object owner.
[!NOTE] In some cases, consumers can process unauthenticated objects if the risk is deemed acceptable.
If the object was delivered to inbox and its authentication fails, the recipient SHOULD fetch it and repeat the authentication procedure.
If the embedded and the containing objects have owners with different origins, the authenticity of the embedded object MUST be verified independently either by fetching it from the server of origin, or by verifying its FEP-8b32 integrity proof.
An object without an ID can only exist when embedded within another object. It has the same owner as the parent object and it is considered authentic when the parent object is authentic.
An object without an explicit owner is owned by the server. Such object MUST be considered authentic only if fetched from the location that has the same origin as its ID.
The actor that creates the object MUST be its owner.
If activity modifies or deletes an object, its owner SHOULD match the object’s owner. If owners are different, their IDs MUST have the same origin.
Examples:
Create, Update and Delete activities, and objects indicated by their object property SHOULD have the same owner.Undo activity and object indicated by its object property SHOULD have the same owner.Add and Remove activities, and objects indicated by their target property SHOULD have the same owner.Announce and Like activities don’t modify objects indicated by their object property, therefore their owners can be different.When ownership changes, the new owner ID MUST have the same origin as the old owner ID.
When a protected object is fetched, the GET request MUST contain a HTTP signature created using a key whose owner SHOULD belong to object’s intended audience. If key owner doesn’t belong to intended audience, its ID MUST have the same origin as one of the actors in object’s intended audience.
CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
To the extent possible under law, the authors of this Fediverse Enhancement Proposal have waived all copyright and related or neighboring rights to this work.