mirrors/fep
1
0
Fork 0
mirror of https://codeberg.org/fediverse/fep.git synced 2026-08-05 11:46:04 +00:00
Code Packages Wiki Activity

FEP-c7d3: Update proposal (#387)

Browse Source 
- Use "same origin" principle instead of "same owner" in authentication.
- Self-ownership of actors.
- Ownership of public keys and verification methods.
- Owner must be an actor and must not change.
- Generalize unattributed collection rule to all objects.

Reviewed-on: https://codeberg.org/fediverse/fep/pulls/387
Co-authored-by: silverpill <silverpill@firemail.cc>
Co-committed-by: silverpill <silverpill@firemail.cc>
This commit is contained in:
silverpill
2024-08-25 16:41:48 +00:00
committed by silverpill
parent 1d5305b89b
commit 088df8efde
1 changed files with 22 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
fep/c7d3/fep-c7d3.md
+22 -12
View File
@@ -24,13 +24,17 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
## Ownership
Ownership is indicated by `actor` and `attributedTo` properties.
Ownership is indicated by a property of an ActivityPub object. The name of this property differs depending on the object type:
Every activity MUST have an `actor` property, which describes the actor that performed the activity. This actor is considered the owner of the activity.
- Owner of an actor is indicated by its `id` property.
- Activities have an `actor` property, which describes the actor that performed the activity. This actor is considered to be the owner of the activity.
- An object (that is, not an actor and not an activity) can have an `attributedTo` property, which describes the actor to which the object is attributed. This actor is considered to be the owner of the object.
- Public keys and verification methods have `owner` and `controller` properties.
Every object (that is, not an actor and not an activity) MUST have an `attributedTo` property, which describes the actor to which the object is attributed. This actor is considered the owner of the object.
The owner of an object MUST be an actor.
Collections MAY have an `attributedTo` property. If this property is present, the actor indicated by it is considered the owner of the collection.
>[!WARNING]
> According to [Activity Vocabulary][ActivityVocabulary], `actor` and `attributedTo` properties 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".
@@ -39,27 +43,33 @@ Collections MAY have an `attributedTo` property. If this property is present, th
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.
## Identifiers and ownership
Identifier of an object and identifier of its owner MUST have the same origin.
## Authentication
The object is considered authentic if any of the following conditions are met:
- It was fetched from the location that has the same origin as its owner's ID.
- It was delivered to inbox and the request contained a valid [HTTP signature][HttpSig] created by the owner.
- It contains a valid [FEP-8b32] integrity proof created by its owner.
1. It was fetched from the location that has the same origin as its owner's ID.
2. It was delivered to inbox and the request contained a valid [HTTP signature][HttpSig] created using a key whose owner has the same origin as the object owner.
3. It contains a valid [FEP-8b32] integrity proof 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.
### Delivered to inbox
If the object was delivered to inbox and its authentication fails, the recipient SHOULD fetch it and repeat the authentication procedure.
### Emdedded objects
If the object is embedded within another object, it MAY be considered authentic if its owner matches the owner of the containing object. If the embedded and the containing objects have different owners, 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.
If the object is embedded within another object, it MAY be considered authentic if its owner has the same origin as the owner of the containing object. 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.
### Unattributed collections
### Unattributed objects
Collections without an `attributedTo` property are owned by the server. Unattributed collection is considered authentic if fetched from the location that matches its ID.
An object without an owner is owned by the server. Such object MUST be considered authentic only if fetched from the location that matches its ID.
## Authorization
@@ -74,9 +84,9 @@ Examples:
- `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.
## Implementation notes
## Ownership transfer
According to [Activity Vocabulary][ActivityVocabulary], `actor` and `attributedTo` properties 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.
When ownership changes, the new owner ID MUST have the same origin as the old owner ID.
## References