mirceanis
commented
4 years ago When you use the EthrIdentityProvider with the IdentityManager plugin in daf you can call agent.identityManagerAddKey(...) or agent.identityManagerAddService(...)
This allows you to specify different keys and services that can be used on behalf of that DID.
Combined with the corresponding agent.identityManagerRemove...() methods this forms the basis of a key (and service) rotation mechanism.
At this moment, the remove methods are not implemented in the EthrIdentityProvider but it would be trivial to add them since they already exist in ethr-did
Also, ethr-did allows the controller of an ethr DID to be rotated to a new address/publicKey. This is also not yet exposed in daf but could be added easily.
The controller is the key or address that has the authority to modify the DID document (to perform other key rotations for example). When a key is removed or rotated or expires, then by convention all the signatures generated by that key become invalid (from the perspective of daf and did-jwt). Some discussions have started regarding the question of "was this signature valid at time T?" which is technically solvable when using ethr-did but for the moment there is no standard happening there.
I hope this answers your question. Please reopen if there are unanswered items relating to this subject.
Dear team,
According to https://github.com/uport-project/ethr-did-registry#ethereum-did-registry
"This contract allows Ethereum addresses to present signing information about themselves with no prior registration. It allows them to perform key rotation and specify different keys and services that are used on its behalf for both on and off-chain usage.""
Q: When it come to key rotation how exactly does it work?
Q: How key rotation being used in identity use cases?
Thanks