-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need to write DID:BTCR Best Practices vs Reasonable Practices Docs #20
Comments
A first pass at some quick definitions:
|
assign to Christopher |
This issue was moved to WebOfTrustInfo/rwot5-boston#28 |
At some point we need to write up some best practices vs reasonable practices documentation.
For instance, ideally you should treat your keys like you do with bitcoin — you use your root key to sign your transaction and immediately sign a few other objects with it (such as the DDO), and you never use it again. If you need ongoing signing keys, put them in the DDO and expire them regularly.
For a high-value pseudo-anonymous identity, you should treat your keys like glacier does for high-value bitcoin transactions, with raw transactions and air-gapped computers: https://glacierprotocol.org/
Clearly the DDO itself should not be centralized, so services like IPFS
As a different kind of example, in my first personal DDO at https://raw.githubusercontent.com/ChristopherA/self/master/ddo.jsonld, I do some things that are not recommended for a pseudo-anonymous identity (as it is clearly not anonymous). However, my choices there are reasonable. First, my DDO is centralized (it is a DNS URL, and it is hosted on github), but my commit of my DDO is signed by my PGP key there. Both are mirrored in a variety of places. When we later can add timestamping it will have more provenance.
Even though in my personal DDO example I'm not trying to be pseudo-anonymous, I also plan to try to not reveal information about others. So I might say I "know" another DID, but I will only do so if they have accepted it as a counter-claim (i.e. they "know" my DID). There is no technological way to force this, but as a social practice we should encourage it.
The text was updated successfully, but these errors were encountered: