The current implementation of UserOverrideableDKIMRegistry only supports pessimistic key updates; i.e., each user's approval is always required to enable a new public key set by the main authorizer.
This causes liveness issues when the user loses access to their account.
However, a naive implementation for optimistic key updates, which enables a new public key set by the main authorizer without the user's approval immediately, has a safety issue when the main authority is invalid.
To make it possible to balance this tradeoff, this PR introduces a time delay until the public key set by the main authorizer is enabled without the user's approval.
Such a public key is enabled 1) after the time delay passes or 2) when the user approves the public key before the time delay passes.
Therefore, the greater the delay becomes, the closer it approaches a pessimistic update, while the opposite brings it closer to an optimistic update.
Type of Change
Please delete options that are not relevant.
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] This change requires a documentation update
Checklist:
[x] I have discussed with the team prior to submitting this PR
[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings
[x] New and existing unit tests pass locally with my changes
Description
The current implementation of UserOverrideableDKIMRegistry only supports pessimistic key updates; i.e., each user's approval is always required to enable a new public key set by the main authorizer. This causes liveness issues when the user loses access to their account. However, a naive implementation for optimistic key updates, which enables a new public key set by the main authorizer without the user's approval immediately, has a safety issue when the main authority is invalid. To make it possible to balance this tradeoff, this PR introduces a time delay until the public key set by the main authorizer is enabled without the user's approval. Such a public key is enabled 1) after the time delay passes or 2) when the user approves the public key before the time delay passes. Therefore, the greater the delay becomes, the closer it approaches a pessimistic update, while the opposite brings it closer to an optimistic update.
Type of Change
Please delete options that are not relevant.
Checklist: