Users should be able to retire their own identifiers at any time, and such retirement will be permanent; no other user will be able to claim that identity in the future. Retiring an identifier implies that as much data related to that identifier as possible should be removed or made inaccessible. To accomplish this, we should define and document the implications of a "Retire Identifier" operation (in line with #214 operations definitions).
Motivation
The core DSNP concept that a user controls their own identity implies that they should be able to retire that identity. This helps align DSNP with a "Right to be Forgotten" philosophy and further evidences the commitment to user control that is paramount in DSNP.
Specification Pull Request
224
Rationale
While not specifically called out in the DSNP white paper, retirement of identifiers has been discussed frequently within the DSNP community. While it could be left to implementations to define, providing explicit definitions of what the implications of retirement are on other DSNP operations is a key reason to make it a part of the spec.
We also considered suggesting that this be an optional operation rather than a required one, but felt that this expression of control was important enough to be required.
Backwards Compatibility
Not applicable.
Reference Implementation and/or Tests
The Frequency implementation already supports a RPC method aligned with this proposal. Additional tests should be written to ensure that once retired, identifiers are not eligible to perform further operations.
Security Considerations
Retiring an identifier implies that there should be strong guarantees that attempts to utilize the identifier after retirement will not succeed.
There is also a tradeoff between retirement and being completely forgotten. Completely forgotten would imply that an implementation retains no record whatsoever that an identifier even existed. This has both a practical limitation (a DSNP implementation may not control the deletion of previously generated content) and a functional consideration (assigning the retired identifier to someone new could cause many headaches, so implementations need to remember at least the fact that an identifier is retired).
Dependencies
From a formatting perspective, the PR for #214 should be completed and merged first, or extended to encompass this DIP.
Abstract
Users should be able to retire their own identifiers at any time, and such retirement will be permanent; no other user will be able to claim that identity in the future. Retiring an identifier implies that as much data related to that identifier as possible should be removed or made inaccessible. To accomplish this, we should define and document the implications of a "Retire Identifier" operation (in line with #214 operations definitions).
Motivation
The core DSNP concept that a user controls their own identity implies that they should be able to retire that identity. This helps align DSNP with a "Right to be Forgotten" philosophy and further evidences the commitment to user control that is paramount in DSNP.
Specification Pull Request
224
Rationale
While not specifically called out in the DSNP white paper, retirement of identifiers has been discussed frequently within the DSNP community. While it could be left to implementations to define, providing explicit definitions of what the implications of retirement are on other DSNP operations is a key reason to make it a part of the spec.
We also considered suggesting that this be an optional operation rather than a required one, but felt that this expression of control was important enough to be required.
Backwards Compatibility
Not applicable.
Reference Implementation and/or Tests
The Frequency implementation already supports a RPC method aligned with this proposal. Additional tests should be written to ensure that once retired, identifiers are not eligible to perform further operations.
Security Considerations
Retiring an identifier implies that there should be strong guarantees that attempts to utilize the identifier after retirement will not succeed.
There is also a tradeoff between retirement and being completely forgotten. Completely forgotten would imply that an implementation retains no record whatsoever that an identifier even existed. This has both a practical limitation (a DSNP implementation may not control the deletion of previously generated content) and a functional consideration (assigning the retired identifier to someone new could cause many headaches, so implementations need to remember at least the fact that an identifier is retired).
Dependencies
References
None at this time.
Copyright
Copyright and related rights waived via CC0.