The attestation advantage
In previous posts about the Shyft Network, as well as the current version of our whitepaper, we discuss the concept of attestations, but the concept is so integral to our ecosystem that we felt it was worthwhile to drill down a bit on exactly what the concept means and why we’ve opted for this sort of model.
The current security threshold
To discuss what we mean by attestations, we have to start by noting that there’s a lot of information that’s important (essential, even) to the successful delivery of financial services that we never want to put on a blockchain in any form, because the on-chain presence of that information represents far too great a user security risk.
As an example, to assure financial service providers that you’re not, for example, a corrupt politician trying to use their service to process bribes, one of the most basic pieces of information they’ll want about you is some sort of ID.
To do this right now, I’d go to a bank, and they’d take a scan of my passport, and that scan would live in their data warehouse, where they have security teams tasked with preventing copies of that scan from going to people who ought not to have it.
If that scanned passport were instead kept on a blockchain, then all the awful things that someone might try to hack it from a bank for are now things they can do for the comparatively low cost of just reading it off the chain. Since that cost-difficulty has been drastically lowered (compared to the costs of mounting a physical infiltration of the bank), you have effectively placed a target on your back.
The blockchain problem
A naive solution would be to put an encrypted copy on the chain. However, key compromise is already a serious problem on blockchains, so that’s not really a solution; either the key can be lost, and the encrypted copy will be useless to its legitimate holder, the key can be leaked, and the copy will be permanently available to any attacker, or even worse, both things can happen.
And given how long data on a blockchain persists (basically forever, since it’s a permanent, immutable ledger), “can” in this case eventually, inevitably, means “will.”
So the entities that collect this data (we call them Trust Anchors) need a way to make this data available to the financial service providers, who in turn need to use it to make sure that their customers aren’t — oh, why not use the example again? — crooked politicians furnishing bribes.
Attestation and revocation
An attestation is basically a declaration by the Trust Anchor, the entity that collected the data in the first place, that they have data about the person in control of the private key for a given address. (Likewise, an attestation can actually be a revocation of a previous attestation, declaring that, for example, control of the key in question has been lost. For more on revocation, see this post on “banking the unbanked.”)
The data itself isn’t included in the attestation, just hashes and description tags on the data (which are also encrypted to give the end users extra privacy), as well as some additional metadata, such as the amount of time the attestation is expected to be valid for, the terms a financial services provider can request the data under, etc.
It’s basically the starting point of a conversation between the entity who has data on a Shyft user, and the entity who wants that data (and of course the user, who has to consent to that data being shared in the first place).
The conversation itself is mediated by a collection of smart contracts, with a standard API, designed to provide an audit trail, so that parties that handle this sort of data correctly, can prove their correct handling by way of data on the chain.
This, in turn, protects the user, and the privacy of their data, since any leaks due to mishandling can quickly have their cause identified and corrected by reference to the audit trail.
If you’ve been paying attention, you’ll notice that the attestation/revocation model necessitates some level of centralization in the network — next week, we’ll go into a little more detail about why we’ve opted for a hybrid model as opposed to a dogmatically decentralized one.
***
Join our Telegram (https://t.me/shyftnetwork), follow us on Twitter (https://twitter.com/shyftnetwork), GitHub (https://github.com/ShyftNetwork) and other channels found on https://www.shyft.network
