Basically -- to keep it simple. Holding the signing key in the PDS simplifies linearization and reduces device-pairing actions.
We spent most of the summer planning to store the signing key in the user device(s) but during a late design session we examined why exactly we wanted that, and realized the main reason was for account portability^1. Thing is, we dont need the primary signing key to be local for account portability; we just need a recovery key that allows the user to assign control away from the PDS later. So we switched to a server-held signing key, but we kept in the architectural pieces that make client-held signing keys possible, in case we want to explore that again in the future.
^1 We're interested in end-to-end encryption but that's not what the signing key would accomplish and will need to be developed later. Hopefully we haven't painted ourselves into a corner for that part of things.
Seems to suggest the signing key is all that’s needed to change the keys for a user? I was expecting it to say the recovery key could be used for that (which only I have).
We spent most of the summer planning to store the signing key in the user device(s) but during a late design session we examined why exactly we wanted that, and realized the main reason was for account portability^1. Thing is, we dont need the primary signing key to be local for account portability; we just need a recovery key that allows the user to assign control away from the PDS later. So we switched to a server-held signing key, but we kept in the architectural pieces that make client-held signing keys possible, in case we want to explore that again in the future.
^1 We're interested in end-to-end encryption but that's not what the signing key would accomplish and will need to be developed later. Hopefully we haven't painted ourselves into a corner for that part of things.