Blockchain itself is just, at its core, a method of cryptographically proving the authenticity of a ledger history. That’s it. What you DO with that technology is fairly boundless. You can embed anything in a block on the chain. We have lots of existing ways to handle proof of identity that can be inserted into a block (imagine if blocks contained the public key of block’s creator and then the entire block (including the public key) is signed with the private key)
Sure, you could do that, but all that would prove is that a block was signed with the private key associated with the included public key. That doesn’t necessarily say anything about someone’s identity though does it? It just says they know how to generate a public/private key pair and a digital signature. Maybe I’m misunderstanding your example?
I don’t mean to be rude but it sounds like you aren’t very familiar with digital identity management paradigms in the first place?
Proving who you are is always a relative operation. It’s always about the relationship between two things. “I am the person who generated this other message” or “I am the person whose face looks like this”.
Key/certificate issuance follows a variety of different models depending on the use case. Sometimes “this object was generated/signed by the person who controls this key” is enough, as is the case with things like secure emails (think gpg/pgp). Other times you need an authority to give relative meaning to a key/certificate (think SSL).
Yeah I’m definitely not a cryptography expert, but I’m more used to working with it in the “you need an authority to give relative meaning” use cases, not the “this signature came from that private key and that’s good enough” use cases. I feel like a lot of your examples rely on the “you need an authority to give relative meaning” use case though, and I can’t wrap my mind around a way to make that work in a way that that doesn’t largely negate the benefits you get from blockchain and it’s decentralization.
Right, but if it’s being used internally within an organization then the business itself is the authority. I think I mentioned this in another reply somewhere but in many of these use cases it’s about preventing tampering or falsification of records.
Let’s take the pharmaceuticals use case as an example. In that scenario the important things to track are:
When did a product come off the production line
Who or what system handled the packing and shipment
When was it shipped
When was it received
Who received it
When does it expire
When was a specific item provided to a patient
Has a participant had their permissions revoked
If the pharmaceutical company is the one managing that system, and they provide individual health care facilities (and any intermediate handles) with “private keys”, that’s the entire extent of the central authority that’s required. Literally every other element can be encoded on the blockchain.
Compare that to a traditional system where you have to maintain databases, provide always-on connectivity to those databases for every participant, manage access control permissions for every user, etc etc etc
With blockchain, every participant can get the entirety of what they need with just their “private key” and a copy of the blockchain from one other peer. That’s it. They can submit their blocks (for a leaf node, “I received this package”; “I gave the item to this patient”; etc) to that one peer and as long as there is a path through that peer to the distributed network, the rest of the network can authenticate the validity of those blocks through network consensus. Tampering is immediately evident. And every block they submit is traceable to whoever that private key was issued to. And once they submit a block to the chain it can never be undone or modified, even if they have all the “permissions” in the world. They’d have to take over a massive percent of the distributed network to alter consensus.
Blockchain itself is just, at its core, a method of cryptographically proving the authenticity of a ledger history. That’s it. What you DO with that technology is fairly boundless. You can embed anything in a block on the chain. We have lots of existing ways to handle proof of identity that can be inserted into a block (imagine if blocks contained the public key of block’s creator and then the entire block (including the public key) is signed with the private key)
Sure, you could do that, but all that would prove is that a block was signed with the private key associated with the included public key. That doesn’t necessarily say anything about someone’s identity though does it? It just says they know how to generate a public/private key pair and a digital signature. Maybe I’m misunderstanding your example?
I don’t mean to be rude but it sounds like you aren’t very familiar with digital identity management paradigms in the first place?
Proving who you are is always a relative operation. It’s always about the relationship between two things. “I am the person who generated this other message” or “I am the person whose face looks like this”.
Key/certificate issuance follows a variety of different models depending on the use case. Sometimes “this object was generated/signed by the person who controls this key” is enough, as is the case with things like secure emails (think gpg/pgp). Other times you need an authority to give relative meaning to a key/certificate (think SSL).
Yeah I’m definitely not a cryptography expert, but I’m more used to working with it in the “you need an authority to give relative meaning” use cases, not the “this signature came from that private key and that’s good enough” use cases. I feel like a lot of your examples rely on the “you need an authority to give relative meaning” use case though, and I can’t wrap my mind around a way to make that work in a way that that doesn’t largely negate the benefits you get from blockchain and it’s decentralization.
Right, but if it’s being used internally within an organization then the business itself is the authority. I think I mentioned this in another reply somewhere but in many of these use cases it’s about preventing tampering or falsification of records.
Let’s take the pharmaceuticals use case as an example. In that scenario the important things to track are:
If the pharmaceutical company is the one managing that system, and they provide individual health care facilities (and any intermediate handles) with “private keys”, that’s the entire extent of the central authority that’s required. Literally every other element can be encoded on the blockchain.
Compare that to a traditional system where you have to maintain databases, provide always-on connectivity to those databases for every participant, manage access control permissions for every user, etc etc etc
With blockchain, every participant can get the entirety of what they need with just their “private key” and a copy of the blockchain from one other peer. That’s it. They can submit their blocks (for a leaf node, “I received this package”; “I gave the item to this patient”; etc) to that one peer and as long as there is a path through that peer to the distributed network, the rest of the network can authenticate the validity of those blocks through network consensus. Tampering is immediately evident. And every block they submit is traceable to whoever that private key was issued to. And once they submit a block to the chain it can never be undone or modified, even if they have all the “permissions” in the world. They’d have to take over a massive percent of the distributed network to alter consensus.