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 (#433)

Browse Source 
- Listed same-origin embedding as 4th condition in "Authentication" section.
- Added a note about acceptable risks.
- Added "Access control" section.
- Minor formatting changes.

Reviewed-on: https://codeberg.org/fediverse/fep/pulls/433
Co-authored-by: silverpill <silverpill@firemail.cc>
Co-committed-by: silverpill <silverpill@firemail.cc>
This commit is contained in:
silverpill
2024-10-29 10:40:47 +00:00
committed by helge
parent fcfe867e4b
commit 01f137d025
1 changed files with 14 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
fep/c7d3/fep-c7d3.md
+14 -6
View File
@@ -34,10 +34,10 @@ Ownership is indicated by a property of an ActivityPub object. The name of this
The owner of an object MUST be an actor.
>[!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.
>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".
>In subsequent sections, "objects" and "activities" will be referred to as simply "objects".
## Origin
@@ -46,7 +46,7 @@ Object identifiers are grouped together into protection domains called "origins"
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.
>There might be other ways to establish trust, but they are not covered by this document.
## Identifiers and ownership
@@ -57,20 +57,24 @@ 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:
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.
2. It was delivered to inbox and the `POST` 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.
4. If it is embedded within another object, and its owner has the same origin as the owner of the containing object.
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.
### 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 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.
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.
### Anonymous objects
@@ -93,10 +97,14 @@ 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.
## Ownership transfer
### Ownership transfer
When ownership changes, the new owner ID MUST have the same origin as the old owner ID.
### Access control
When a protected object is fetched, the `GET` request MUST contain a [HTTP signature][HttpSig] 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.
## References
- Christine Lemmer Webber, Jessica Tallon, [ActivityPub][ActivityPub], 2018