An identity and personal key management infrastructure, built right into Holochain. Learn about the project in our GitHub repo https://github.com/Holochain/dpki or read more about it in The Agent Centric Web of Trust. If you need help using this library, you can also post in #technical:app-development and use the tag #dpki or #deepkey.
1 Like
Could this be deeply integrated into the shared profile/avatar used in the OASIS API (which powers Our World) since other hApps will also share this profile/avatar/karma. The identity would be linked to your profile/avatar…
http://www.ourworldthegame.com
https://chat.holochain.org/appsup/channels/our-world-netclient
@philipbeadle and I were chatting the other day, and… this is mostly a stream of consciousness but let’s see. I wasn’t sure how deep his concerns about ref-checking for key revocations on every action were performance-wise… but consider in the context of this post a capability-based solution?
What if you invert the model? DPKI contains a registry of all the hApps which your keys have been authorised to. The validate_agent callback is responsible for assigning initial capabilities for accessing a network, even hc_public; in other words, without an explicit initial capability grant for a zome then even reading data from the network is denied. Change initial agent entries such that they also grant a system capability, revoke_key; which DPKI can call to de-authorise a compromised key and update it with an alternate (which is automatically given revoke_key for next time).
This does put the onus on the caller and means you have to track the registered apps in a robust way, so the zome which stores those needs to be replicated via a shared private DHT of your own devices. It also means we’re only designing for privileged people with multiple devices, or running trusted cloud services 
But on the upside, it means that configuration of an agent’s connected hApps moves from a TOML config file into a DHT. Things start to feel “more Holochain”.
Is any of this kinda stuff of concern / do some of these ideas work, or defeat the whole purpose because the mechanism for key revocation is stored in the same database as the key that may be compromised? If the latter- what if the revoke_key is delegated to a derived revocation key that the agent is responsible for writing down on paper (like a wallet seed) at setup time?
1 Like
Are there any examples of this being used? How does this relate to @philipbeadle persona hApp?
Is the persona app used anywhere? Any examples?
Is HoloVault part of this or is it part of DPKI? Any examples of this being used?
Finally how does RSM effect all of this?
What are the current recommendations and best practices?
Thanks peeps. 
1 Like