Agent-centric Digital Identity
Introducing Distributed Public Key Infrastructure
As folks slowly begin to grok Holochain’s many subtle interventions into the crypto-space (assumptions about currency design and distributed computing more generally), it can seem like there are more new questions than answers. On top of Holochain’s core combination of immutable hashes and gossip-enabled validation, you’ve got a wide range of possible authorization requirements for maximal fit with the intention of your app — completely fit-for-purpose. The requirements for entry into a Holochain app are entirely up to the the people who comprise /develop/govern it — think anything from completely open access to requiring a state-issued driver’s license, to having to present your firstborn to those governing the app (Kidding! Not in my app-world!).
Nevertheless, this has also meant that we’ve thought a lot about the necessary mix-ins and add-ons that will make integrating more familiar security measures easy. With greater flexibility comes greater responsibility! If Holochain core furnishes rigorous data provenance, our new pluggable mix-in module can seamlessly bridge any Holochain application to the latest in human-use security. We’re not only implementing a public key infrastructure…
We’re making Distributed Public Key Infrastructure an integral part of Holochain!
Let’s return to the basics to get a full sense of DPKI as…
→a step forward in human factors of security based in revocation.
→crucial for continuity, enabled by an agent’s ability to bridge personal data from one application to another.
→an aggregation of identity information.
Putting the “D” In Front of “PKI”
Public Key Infrastructure (PKI) is all about digitally signed statements that contain public keys and different possible types of subject names, aka certificates. Some central authority, usually a third-party company, verifies that the pair of keys (public and private) is owned by the same subject named in the certificate, and signs it. Then, the certificate with the public key in it can be distributed to anyone. The public/private keys comes into play when data encrypted by the public key needs to be decrypted by that user, which is only possible to do with the private key. Provided the user keeps the private key secure, it can be used to make a digital signature that the public key confirms.
As far as the centralized web goes, we trust certificate issuers which are pre-stored and trusted by browsers. But we’re talking about the distributed apps and the distributed web ushered in by Holo’s >1,000 hosting nodes. DPKI is a public key infrastructure, too, so it operates similarly. However, since DPKI is specific to Holochain, it operates in an app environment that already leverages immutable, signed hashes, authenticated using a DHT-per-app that each app user keeps a little piece of.
PGP and the “Hard Problem” of Agent ← → Key
The problem of correctly identifying a public key as belonging to a particular user is endemic to all public/private key systems. Pretty Good Privacy (PGP) is already distributed, in that it uses self-certified certificates for cryptographic privacy and data/communication authentication. Unfortunately, though, it still begs the question of how we find out whether or not the person we think we’re communicating with really is that person.
Web of trust servers are part of PGP’s vetting scheme, where information binding a user name to a key is signed by another PGP user to attest to the user-key association. This certainly addresses the problem somewhat. And, the original version of PGP leaves the decision of whether or not to use its endorsement/vetting system to the user. In contrast, centralized PKI schemes mandate that if a certificate is attested to by a central certificate authority, it’s to be accepted. But even if the self-certified, distributed nature of PGP improves upon the central dependence of PKI, webs of trust inspire little confidence. Not only are they hard to keep up to date, but they lack an obvious context for reliable validation.
Approaching the Hard Problem: Device- and Context-Bridging
On Holochain, DPKI is self-certified, like PGP key infrastructures, but in such a way that bridges app-spaces through an agent. It’s still a public key management infrastructure, but how one chooses to interface with it for the purposes of ID’ing is left totally open…
Imagine a scenario in which you want to invite someone into a highly exclusive application-community. If you send something encrypted with the key of the person you’re trying to reach, the person who controls the key can decrypt it and put it into, say, an invitation code required for entry and participation. When someone says that they’re a certain DPKI agent, they should be able to encode something from that public key using their DPKI identity, hand it to others from some communication channel, and then come back to the context in question decoded.
What’s happening is that triangulation from context to context inspires trust because you can choose not just a trusted communication channel, but a trusted stream of communication, in which you really felt that the person was that person. As far as really truly knowing whether or not someone is who they say they are goes, DPKI lets a person to make the call based on their own perception of another’s self-similarity. Then, the onus is on the agent making a claim that they are the key controller to decrypt the communication in order to get access to the new app community.
Another thing to take note of is that a public key is an address of a device on Holochain (a laptop, say, or a cellphone). Any entity that owns and operates digital devices, a person with many devices, or many people with one, to name a few examples, can use DPKI to unify ownership or actorship behind devices. The idea behind DPKI is that a source chain and key “rule” the device, making it possible to ID themselves, as an agent, across devices. It’s also possible to locally cache a source chain from other devices (with cross-caching), in order to have off-line access to information across devices. Not only can one now confirm self-similarity across applications, but apps can automate this process, doing a “handshake” that ensures self-similarity right when a bridge is created from an outside channel to the current one.
Better Key Management
Not dissimilar from the problem of initial entry into a key infrastructure (pairing real person to digital key), another major hurdle for digital identity is the human element of key management. Or if you prefer not to berate humans for their comparatively sub-par management of all things, the hurdle is the gap between actual people’s concerns and the management of their distance relations that computers handle.
DPKI lets you regain control of your app history, your source chain, by being able to revoke the keys when you leave and establish new keys. This is an especially important consideration in light of the horror of losing keys to a crypto-wallet holding Bitcoin or Ether. If you lose the keys, you lose the money, too. Luckily if you lose keys to your source chain or even to your phone, DPKI can be used to revoke and issue a new set of keys.
Of the three revocation methods available to DPKI users, a couple are familiar from centralized PKI schemes and OpenPGP, but the final is brand new!
- The first is a revocation key that is separate from a source chain key. Imagine that someone makes the wise decision to store that revocation key in a physical space. Should that person have a device stolen from them, it would be easy for them to revoke the key and create a new one. We’d have to assume, of course, that the person is able to manage their key physically…
- Next method? Delegation of a revocation authority. So, if that revocation authority should be…well…not your absent-minded self, you could cozy up to your most reliable friend and have that person revoke keys in a similar instance of necessity.
- M of N signing by authorized peers that create a mini trust-web for the express purpose of revoking a single set of keys.
Identity Robustness
Now that there are methods for secure ease-of-use in place, what about the anchors, claims, and assertions that we really need before making any big decisions to interact with others? DPKI is a modular piece, but it also offers a space to aggregate identity information. Thinking about public key infrastructure means getting into the basic issues of identifying who’s who (or as we said, continuity of agent from one context to the next). But what about the more familiar meaning of identity? Identity is about a historical record that creates trust. Digital identity currently works through mechanisms like facial or physical recognition, language detection and recognition, government-issued, authoritative documents, private rating systems (owned by companies like Ebay), social media platforms, and media appearances and publications correlated through these other forms.
Once you have a private key on DPKI, you can
→create entries like the above and have them signed and vouched for by other DPKI keyholders.
→discover other user-controlled identity services.
→choose to delegate public-facing identity services to a provider, store identity information in private entires on your own your own DPKI chain for selective release, or both!
→link signed claims from third parties authenticating aspects of your identity to create a whole private or provider-managed store of records about you.
Overall, you can think of DPKI as a way of combining Holochain’s already-distributed engineering with an effort in better key management, leveraged for user-managed identity services.
Check out the DPKI Github Repo here. And, if you want to support Holochain’s development, the Holo ICO is whitelisting participants now!
