silverpill on Nostr: Following the FEP-fe34 update, I am publishing a new version of FEP-ae97: Client-side ...
Following the FEP-fe34 update, I am publishing a new version of FEP-ae97: Client-side activity signing
https://codeberg.org/fediverse/fep/pulls/564
The registration process is completely different now. Keys for signing S2S requests are generated on the server and only public parts are shared with the client.
When FEP-ae97 client retrieves activities from the inbox, it signs GET requests with a key associated with actor's DID authority.
For example, this actor:
ap://did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK/actor"
Will generate an HTTP signature with this keyId parameter:
keyId="did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
Implementations have been updated too (Nomadic AP Client and Mitra).
#fep_ae97
https://codeberg.org/fediverse/fep/pulls/564
The registration process is completely different now. Keys for signing S2S requests are generated on the server and only public parts are shared with the client.
When FEP-ae97 client retrieves activities from the inbox, it signs GET requests with a key associated with actor's DID authority.
For example, this actor:
ap://did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK/actor"
Will generate an HTTP signature with this keyId parameter:
keyId="did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
Implementations have been updated too (Nomadic AP Client and Mitra).
#fep_ae97
quoting nevent1q…yj9yUpdating 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",, 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