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

FEP-fe34: Clarify scope (#563)

Browse Source 
- Requiring keys to be controlled by server.
- Added Move(Actor) to the list of cross-origin relationship examples.

Reviewed-on: https://codeberg.org/fediverse/fep/pulls/563
Co-authored-by: silverpill <silverpill@firemail.cc>
Co-committed-by: silverpill <silverpill@firemail.cc>
This commit is contained in:
silverpill
2025-04-23 15:23:55 +00:00
committed by silverpill
parent 136d6c14b6
commit b1ddd252c0
1 changed files with 8 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
fep/fe34/fep-fe34.md
+8 -3
View File
@@ -35,9 +35,11 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
## Origin
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.
Object identifiers can be 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.
The same-origin policy determines when a relationship between objects can be trusted. Different origins are considered potentially hostile and are isolated from each other to varying degrees.
Origin-based security model is supposed to be used when object identifiers are HTTP(S) URIs and actors are managed by servers. The model can also be used with other kinds of identifiers, but that is not covered in this document.
## Authentication
@@ -54,6 +56,8 @@ If none of these conditions are met, the object MUST be discarded.
Consumers SHOULD attempt to fetch the object by its ID if other authentication methods are not available.
Servers MUST NOT share secret keys with clients.
>[!NOTE]
>In some cases, consumers can process unauthenticated objects if the risk is deemed acceptable.
@@ -63,7 +67,7 @@ An object without an ID can only exist when embedded within another object. It i
## Authorization
Authorization is the process of veryfing permission to [create, read, update or delete](https://en.wikipedia.org/wiki/Create%2C_read%2C_update_and_delete) an object.
Authorization is the process of verifying permission to [create, read, update or delete](https://en.wikipedia.org/wiki/Create%2C_read%2C_update_and_delete) an object.
### Ownership
@@ -125,6 +129,7 @@ Examples:
- An activity can be signed with a key of different origin if that key is referenced from the actor document.
- An object can be deleted by an actor of different origin if that actor is specified as a moderator for the context to which the object belongs.
- An actor can migrate from one server to another by performing the `Move` activity if the migrating actor is included in the target actor's `alsoKnownAs`.
## References