silverpill on Nostr: Updating FEP-fe34: Origin-based security model: ...
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).
#fep_fe34
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).
#fep_fe34