Updating FEP-fe34: Origin-based security model: https://codeberg.org/fediverse/fep/pulls/698
- It now explains how origins and owners should be compared.
- Embedded objects can be trusted if they have same origin and same owner.
fep_fe34
Minor FEP-fe34 update: https://codeberg.org/fediverse/fep/pulls/683
I think the document is almost complete, both S2S and C2S are covered.
Added new requirements to FEP-fe34:
https://codeberg.org/fediverse/fep/pulls/672
Previously the FEP put the burden of C2S validation solely on the originating server (producer), but I think it would be better to do corresponding security checks on the consumer side too:
- When fetching an object: verify that Content-Type includes one of the AP & AS media types.
- When verifying a signature: also perform same-owner check and verify key ownership.
Both are already considered good practices in the Fediverse.
I also attempted to clarify how fetching from origin (authentication) is related to access control (authorization).
Edited 71d ago
FEP-fe34 update: https://codeberg.org/fediverse/fep/pulls/711
This is a follow-up to the FEP-2277 update. I added the algorithm for determining the owner of any object:
1. Run the duck typing algorithm specified in FEP-2277.
2. If the type is Link, return error.
3. If the type is neither Object nor Collection, and the object has an attributedTo property, return error.
4. If the type is Actor, return the value of the id property.
5. If the type is VerificationMethod, return the value of the controller property.
6. If the type is PublicKey, return the value of the owner property.
7. If the type is Activity, return the value of the actor property.
8. If the type is Object or Collection, return the value of the attributedTo property.
RE: https://mitra.social/objects/019a362e-7109-11ad-864a-495e4e42b12c
Updating FEP-fe34: Origin-based security model:
https://codeberg.org/fediverse/fep/pulls/563/files
I described the conditions in which the model should be used: HTTP(S) identifiers and server-managed actors. Servers MUST NOT share secret keys with clients, because if keys are shared, non-admin users might impersonate other users on the same server.
This means actor registration process in FEP-ae97 is not secure, and will be replaced with a different one.
-----
The model can be used with 'ap' and DID URLs too, but FEP-fe34 currently doesn't cover this case, because it is not clear how origin should be computed for them. This is an experimental feature. I am using ("ap", <did>, 0) tuples (see FEP-ef61), but also considering introducing a new type of origin - cryptographic origin - which is not a tuple, but just a DID (WHATWG HTML standard already specifies two types: opaque origin and tuple origin; cryptographic will be the third).
I updated FEP-fe34 (origin-based security model):
https://codeberg.org/fediverse/fep/pulls/653
The "Authentication" section is fully rewritten. I moved requirements from the "Assumptions" section to sections describing related authentication methods.
Besides that, there is a major change in how embedded objects are treated. Previously, the same-origin policy was recommended. In the new version, embedded objects shouldn't be trusted except for 3 cases:
- The object of a Create activity.
- Embedded object identified by a fragment.
- Embedded anonymous object.
It is difficult for a server to guarantee authenticity of an embedded object that was published using C2S API. Such object can be embedded somewhere deep in the object graph, and verifying embedded objects at all levels is not practical.
The previous recommendation was only appropriate for a network where servers don't implement C2S API.
A minor update to FEP-fe34: Origin-based security model
https://codeberg.org/fediverse/fep/pulls/662
- Explained how to identify public keys. They can be identified by publicKeyPem and publicKeyMultibase properties ("duck typing").
- Added a warning for JSON-LD consumers. Even innocuously looking property can become publicKeyPem or publicKeyMultibase after doing JSON-LD transformations.
You can read more about this problem in this post: https://socialhub.activitypub.rocks/t/am-i-understanding-something-wrong-or-is-json-ld-remote-context-support-a-gigantic-security-vulnerability-if-any-dumb-c2s-server-implementation-tries-to-federate-with-the-current-network/5439/1
@kopper suggests possible workarounds there but I think they are way too complicated. Just don't do JSON-LD.