Great article, and very interesting read. Not a piece of crap at all, in my opinion. Now to get to the point...
Lets say there was a distributed database that stores identities (I'll reference to this as "node" from hereon), and anything that has ever been said about them at anytime, by any other identity residing on the same node. Anyone with access to this node could create identities and say anything about any other identity on the node. Also, both identities and the node itself create and mange their own personalized Webs of Trust (WoT), who'll need to be insusceptible to Sybil attacks, in order to ensure that all relevant information remains reliable at any given point in time for said node/identity.
Any identity on the node would consist of:
1.) A subset of attributes (which I'll refer to as "identifiers" from hereon).
The types of identifiers could either be a name, nickname, gender, DoB, URL to social media account, IS_UK_RESIDENT, IS_OVER_18, BTC address, etc.
There wouldn't need to be restrictions on the types nor values of these identifiers, only agreements / a protocol among trusted parties to ensure they all understand each other when they need to, so that basically any kind of identifier could be added by any identity, to any other identity on the node. These types could then contain any given value, with no restriction on it whatsoever. Examples could be: type of identifier = name, and value = Bob; type = IS_OVER_18, and value = YES; type = BTC, and value = a public Bitcoin address on the main net, etc.
Identifiers also have a private/public setting, to which I'll get back at point of smart contracts.
Both the identity and its identifiers all have their own seperate public addresses. The owner of any identity / creator of an identifier would be the only one able to prove (s)he's the creator of that identity/identifier, via ownership of a private key and corresponding signature and public address, and thereby verifies that information to be true according to him/her.
2.) The reputation tied to any identity, would be sent and received ratings.
Sent/received ratings are meant for any identity to be able to say anything about any identity at anytime. This could be either "Alice is a terrific barber", "Bob is the worst car salesman I've ever met!", or "DID_REPAY_LOAN_ON_TIME".
Also, a score could be added to the rating. How scores are measured will be decided upon by the owner of the node, so that it could be either between -10 and +10, between 0 and +100, or between 3 thumbs down and 3 thumbs up.
3.) The identity (the node is an identity too for that matter) has its own personalized WoT, according to the whitelisting principle. This should guard any identity's verified relevant information on the node from the irrelevant information, and should thus solve the Sybil attack.
Only identifiers that have been verified by an identity will be added to the identity's WoT, along with the identifier's associated identity. This way, an identity within Alice's WoT could contain different identifiers than the same identity in Bob's WoT, since Alice might verifiy identifiers A, B, and C, while Bob might verify identifiers B, C, and F.
This type of a mechanism will make the trustworthiness of the WoT as good as the least trustworthy identity within it, based on which identifiers/identities have been verified by the owner of the WoT itself.
By applying this technique, identities could verify identifiers of any identity, or add identifiers to identities and thereby verify these identifiers, which would automatically add these verified identifiers and their associated identity to their WoT. This means that all identifiers that have not been verified will be seen as irrelevant and hold no influence over the identity's WoT in any way.
--------
Now to address the issues you've posed in your article above:
Gender issue: Say Alice has added an identifier to her identity (type = gender, value = female), to then turn bi-gender. She could now simply down-vote the old gender identifier, and add a new one (type = gender, value = bi-gender).
Everyone who has verified Alice's identity by verifying her gender will now see that Alice has said that the old identifier is longer true, according to herself, and can then see that she claims to be bi-gender from this point on. Since these parties seem to trust Alice, she's in their WoT after all, they can assume to a high degree of certainty that this information is true.
A group of people: Basically another identity. The person who controls and manages this identity could add/verify that certain other identities belong to this identity (type = member, value = public address of the identity).
Machines: They could have their own public addresses, corresponding private keys, and personalized WoTs. This way, any machine could have their own identity, and automatically decide whom to trust. Maybe the privkey could be stored in a Trusted Execution Environment or something. I don't know, I'll let the security experts figure that one out.
Smart Contracts: Here is where it gets interesting, since only the node itself won't suffice from this point on. What we now need is an ability for nodes to communicate with one another, in order to be able to exchange information among themselves, based on a set of permissions and thresholds.
For this, we'll take a slightly modified node that can act as a permission database, and filter/firewall & communication application, to interact with other (trusted) nodes.
These type of nodes also contain their own WoT, of course, which they'll use for the purpose of the permission database. The modification to this node would therefor be mostly to act as a communication application between nodes, running as a seperate node between the node that stores the identities and all the other trusted nodes. Thresholds could now be set on both sides and verified/executed. Any identifier marked as private will never be shared, not even with trusted nodes, and identifiers marked as public may be shared in accord with the permission database.
This will enable private nodes to talk with each other. So, then we would have public nodes, private nodes, and public/private (translucent?) nodes.
Locations could now be tied to public addresses, and be stored in a decentralized name services fashion. Also, this technique could enable alertSigningKeys and dnsSeeds like functions.
Blockchains have a name, so we'd just need to agree on a set of names for the types in order to solve the issue of chain identitifiers (e.g., BTC for Bitcoin mainnet, BTCtest for test, BTCalice for AliceNet, BTCmynet for Mynet, and Skynet for Skynet), for when we'd all want to be able to talk with one another, but there wouldn't be any restrictions on the types. For the values, associated to the types, we could then use the public addresses.
So if you'd like to refer to the BTC mainnet as "Namecoin" on your node, that's fine with my node. That information will then simply make no sense to my node while communicating, that's all.
This should also solve the issues corporates might have with such a system, since they can use it however they like, and it should nicely integrate within their existing production and legal environments.
I'm not sure what a DAO should look like myself neither, but the image that I get of it looks pretty cool. I'm sure the system described above here could help them in some sense, since it's inessentially nothing more than just another identity. This would give them the needed keys for signing, and the possibility for nodes/identities to verify that any statement/verification/addition has been added/verified by that identity itself.
Either the node or any identities stored on it would be First Class Persons, looking at the characteristics. It should also enable giving an identity to any device connected to the IoT (Internet of Targets).
Looking at what's needed for that, according to what you've described in your article, Alice and Bob would now be able to make any type of claims, and Carol would be able to verify any of those. Also, the IT dept. should be able to handle all of this stuff in both a user-friendly (with whitelisting? whoah!) and secure way, via the front-end. So, yes, without a trade-off between UX and security.
So, people, smart contracts, machines, religious organizations, corporates, whole countries for that matter, would be not much more than just another identity on a node. All the same and both different at the same time, so that the interpretion of Alice about Bob's identity could difer from Carol's view on who he is, according to her.
JSON seems like a good way to go about it. How about using the same JSON RPC API that the Bitcoin daemon (bitcoind) uses? To give an example, it could make the JSON of a sent verification of an identifier look something like this:
-------------
{
"hash": "AEiHP29kXaW3k5QkVNYP8gd1hrdSs7LvEauanfTzGMAa",
"data": {
"signature": {
"pubKey": "PA4oX2htY35kXuNVnvNxXHiSigfcfJJyxJntwfgx7tgisjVbuEKcb1v3V2dojuHkrRyfVAu9Yi24nFcSPEdEvLeN",
"signature": "AN1rKr3gnNf7JgmDXANoLkSN3KNMgsyJtMAYKFXdPdxAvDktfFTncCpEvi1Z1AtJ9JjxGeFhdchPcWgWkg3Mceh2KAsbpQKTP"
},
"signedData": {
"author": [
[
"url",
"https://www.facebook.com/Alice"
]
],
"recipient": [
[
"name",
"Bob"
],
[
"url",
"https://www.facebook.com/bob"
]
],
"timestamp": 1414442863,
"type": "confirm_connection"
}
},
"published": true,
"priority": 17,
"signatureDetails": {
"signerPubKey": "PA4oX2htY35kXuNVnvNxXHiSigfcfJJyxJntwfgx7tgisjVbuEKcb1v3V2dojuHkrRyfVAu9Yi24nFcSPEdEvLeN",
"signerKeyID": "1DqrzTcimQp3Ye88oHgxdU7DBTsM2TRYFj",
"signature": "AN1rKr3gnNf7JgmDXANoLkSN3KNMgsyJtMAYKFXdPdxAvDktfFTncCpEvi1Z1AtJ9JjxGeFhdchPcWgWkg3Mceh2KAsbpQKTP"
},
"authorName": "Alice",
"recipientName": "Bob",
"authorEmail": "",
"signerName": "Identi.fi",
"authorGravatar": "7e381ba0e2e40353d922f8ad49006437",
"recipientGravatar": "f31830f37a67bc0f6e0d87c9f019bb7e",
"linkToAuthor": [
"url",
"https://www.facebook.com/alice"
],
"linkToRecipient": [
"url",
"https://www.facebook.com/bob"
]
}
-------------
This way it would also include its own PKI. I'm open to suggestions concerning the line-based tag-equals-value.
This system should also square Zooko's triangle, if I'm not mistaken.
You can find the free open source (MIT licensed) proof-of-concept of the system described above here: https://github.com/identifi/identifi
I'd be more than interested for your feedback and/or questions, and to see if you're going to send us back to the drawing board. If so, no hard feelings.
Posted by Tim Pastoor at May 3, 2015 05:02 PM