Confirmed users
358
edits
No edit summary |
|||
Line 163: | Line 163: | ||
In any case, since such a move will have to happen across the whole services infrastructure to be worthwhile, it's largely orthogonal to the development of the key recovery service itself. | In any case, since such a move will have to happen across the whole services infrastructure to be worthwhile, it's largely orthogonal to the development of the key recovery service itself. | ||
== Keeping Things in Sync == | |||
The client will need to have some protocol for updating the stored recovery information when the user changes their password, or for detecting when the stored info is stale due to a password reset. Will this fit into the existing "uh-oh your password seems to have changed" workflow on the client? | |||
We could *try* to manage some of that automatically on the server but that sounds like trouble. Perhaps we need the ability for the account-management service to forcibly delete stored data when it knows a user's password ha been changed. |