The future of cryptocurrency is trust

As you’re here I assume you know what a blockchain is and some basics around cryptocurrency — their existence as a digital asset; what they are and how they are exchanged on blockchains.

None of this post should be construed as advice, particularly the financial kind.

The rise of cryptocurrencies has given birth to a largely unregulated ‘wild west’ market where pretty much anything goes —including outright fraud; ponzi schemes; the same ponzi scheme again! and insider trading.

Blockchain systems are designed in a such a way that personal or corporate identities are not used; no trust is offered or needed; and where security and reliability are assured through mathematical functions and code.

This lack of trust at a core functionality level is on face-value really great technology innovation however it is also disjointed from the ‘real world’ where bad things happen and not everyone is always honest.

With an equivalent to ~$30 billion USD being transacted every day (source: coinmarketcap.com) there is ample space for nefarious activities and intentions to be carried out alongside legitimate use-cases.

In this post I am going to talk about why I think trust — and identities to support that trust — are needed for the cryptocurrency market to be legitimised and make way for the next wave of investment and implementation.

The identities and trust we have now

Digital signatures

Wonderfully described in this post blockchains require private and public keys which form a digital identity and signature (or ‘wallet’)— they are not the unique identity of an individual or organisation but generally belong to one, as each private key is unique and thus must in theory be possessed/owned (but could also be shared through duplication).

This post ignores multi-signature wallets on purpose as such is far less common and arguably specialist looks at the trust/identity perspective based on end-users (whether individual or organisational) as that is the main market from a quantity perspective.

Know your customer (KYC)

KYC is a process organisations can go through in an attempt to understand someones real-world identity and verify the same. The identity assurance arena is filled with nuance and effectively boils down to probability — you probably are who you say you are; it is probably you logging in with a username and password but we can increase the probability by using multi-factor authentication; asking for an identity document scan etc etc.

Anti-money Laundering (AML)

AML is a series of laws; regulations and processes designed to limit the capability to move funds gained from illegal activities. Usually requires KYC.

Exchanges

There are 189 exchanges (source: coinmarketcap.com) — the vast majority of which I would not touch with a barge pole even if remotely by Starman in a cherry red Tesla — who in an unfair broad-stroke brush: do not maintain or mimic anything resembling good governance; accreditation or compliance.

Some exchanges KYC for pseudo-AML purposes but a large portion of the small subset that do are usually also sketchy for data protection — do you really want to send your full identity scope that is perfect for identity theft to a website? Is it clear who will see it; how long they keep it for; and who they can share it with? Will your data be processed in a jurisdiction that does not afford adequate protection of your data (‘Which countries have an adequate level of protection?’ on this UK Information Commissioner’s Office page)?

The vast majority of exchanges you can sign-up to via Tor/VPN with an anonymous email account and rinse/repeat to stay below their KYC thresholds (usually $20–30k USD in transactions before you have to KYC to continue to trade/withdraw).

Exchanges; coins and tokens are generally unregulated and unprotected. There is a distinct lack of protection schemes such as US Federal Deposit Insurance Corporation (FDIC); US Securities Investor Protection Corporation (SPIC) or the UK Financial Services Compensation Scheme (FSCS).

Many exchanges do not differentiate between client accounts and their own (let alone buy insurance) so should the worst happen all of their clients will be left with nothing as there is no protection to say that their client wallet balances belong to their clients not the exchange i.e.: your money is their money.

Most jurisdictions have determined the tax basis for cryptocurrencies (but of course…) but not the supervisory or regulatory basis but we’re getting closer to that.

‘Offline’ Trading

Many wallet systems let you generate offline and it is entirely possible to never interact with an ‘exchange’ by trading in-person or peer-to-peer — you still need to use the blockchain network to transact (even if a side-chain) unless you’re trading wallets (private keys) themselves instead of the digital assets held within but that is an entirely different problem space.

‘Offline’ trading would bypass any centralised identity federations along with any KYC and pseudo-AML they operate.

As things stand right now, where KYC and pseudo-AML are in place this information is not currently shared with anyone and cannot be checked so one could argue the limited value that presents.

The identities and trust we could have

This is by no means exhaustive and as mentioned the identity assurance world is filled with nuance — having consulted on various private and public sector identity platforms over a number of years: this is just a whistle stop from a single viewpoint and has various holes that could be poked (some are discussed, some are not).

I am hoping IOHK through Cardano (ADA) will help solve this problem and achieve industry and regulatory agreement when doing so.

Digital signatures are associated to ‘identities’

Where they are generated online by the Identity Provider (IdP) — the signature (public key component) is associated to the real-world identity the IdP has already verified (or will soon). This isn’t done on the blockchain (but could be) but just in held metadata.

The IdP in this will most likely be an exchange (for example Coinbase) or otherwise trading or conversion platform (like Changelly).

I am using IdP as this is effectively someone who ‘knows’ an identity because have checked it (to whatever level of trust) and is willing to warrant that identity to somebody else. The term isn’t a perfect fit but it means the right thing in the identity assurance world but would usually be used to label issuers of documents themselves (HM Passport Office in the UK for example would be the perfect IdP for UK passport documents) but works well enough.

Where they are generated offline outside of the realm of an IdP— if the user (individual or organisation) wishes to elevate their trust position they could approach any IdP and sign-up, and complete the KYC process (verify their real-world identity) and also prove the wallet is theirs through something like a dummy transaction (as only the private key holder could have done that).

An offline user choosing to verify their identity with an IdP doesn’t mean they have to use the IdP’s other services (for example, trading or their online wallet system) it is just an entirely elective means of volunteering to elevate their trust position by choosing to join the identity and trust structure.

^ I specifically butchered that paragraph to re-iterate that it should be entirely voluntary and their level of verification be their choice.

Know your customer (KYC) just becomes ‘identities’

These IdPs should be part of an identity federation (new or existing — like the Open Identity Exchange) and use a standards-based approach to record KYC’d identities in a way that can be shared if required. This is technically already true for traditional KYC (for example, Coinbase store the results of their KYC process) but not in a way that is designed to be queried or easily shared and they don’t currently share this with anyone unless legally compelled to.

Identities can vary from simply an email address (from a non-anonymous email provider) that has been verified (email link, user clicks it) through to various levels of verification from documentation (with database checks, for known-stolen known-bad etc) through to verified bank accounts (deposit is made and user must confirm deposit value or reference, or the inverse where the user must dispatch a payment). I’ll leave biometrics out this for the moment.

Recording and sharing identities is a big fraud and privacy risk. I am not advocating the movement of real-world identity documents; names; emails etc — we should be looking to exchange flags (yes/no/other) and attributes (value=2) not share identity documents or personal information.

I have spent many years championing end-user privacy and data rights and working with clients to change their systems so they require and retain less personal data — and I have no intention of stopping now and/or throwing privacy under the bus.

Further, even the confirmation (or not confirmation, as described by OWASP in their authentication cheat sheet) of a flag can be problematic thus the ability to query such should be well-designed and considered as infinite queries that cannot be stopped would be bad (for privacy as well as technical scale).

This risk is usually reduced (note, I didn’t say ‘solved’; ‘closed’ or ‘mitigated’) in identity circles by limiting who can query members of the federation to known members (even if that is tiered) — however — given the nature of cryptocurrencies and the ‘offline’ trading and so on my gut thinks the ability to query some information publicly will be required. My gut thinks it is doable… but I also often chastise my gut for not remembering that it is probably not going to be the one implementing the solution (and mitigating attacks at 3am).

Anti-money Laundering (AML) associates to ‘trust’

Now that we have identities, the Level of Assurance (ISO/IEC 29115) can now be also understood and agreed by the identity federation.

As LOA as defined by 29115 might not be directly suitable, the federation could simply make it up or use a coherent standards-based scale on increasing verification, for example:

1: email address verified
2: email address and government-issued ID verified
3: email address; government-issued ID and address verified
4: email address; government-issued ID; address and bank account verified

^ the use of ‘verified’ is generous on the basis that it is unlikely IdPs will directly query the authorities who issued the documents. Products like NetVerify from Jumio do a great job in finding acceptable middle-grounds in probabilities. (Also, yes, it won’t always be this cumulative in terms of layered verification.)

AML can boil down to forensic-readiness; record keeping; reporting and KYC so verified identities that you can trust goes a long way to helping all of that.

Exchanges

As IdPs they will carry the main weight of the federation burden (which seems reasonable as most of them exist for commercial gain anyway) and in my view — the same view shared by regulatory and law enforcement it would seem — they should/must be doing this anyway.

Regulatory & Law Enforcement

Once IdPs are ‘in’ and running this would be comparable to banks across the world and how one assumes there is some sort of posture scale and everyone sings from the same hymn sheet. (Yes I realise it is not that simple.)

The bodies can join the identity federation and query for status. If they require a deep-dive and a copy of the ID itself they can wander off to get their warrants and present them to the right IdP to be provided with that information.

Other service providers

Blockchain has increasing use-cases as everyone jumps on a band wagon — while I type this post another 1,024 ICOs will have been launched (source: my contempt for the unhealthy amount of useless or scam ICOs).

Many of these use-cases could benefit from some element of real-world identity/trust and instead of doing it themselves they can simply query to check instead. I could make many convincing arguments that an organisation that does ‘y’ should focus on ‘y’ and not duplicate identity information and further frustrate their users.

Much like the use of IdP, ‘service provider’ is also not a perfect fit but effectively means someone who needs to check they can trust an identity or that it is true etc but doesn’t need to necessarily know the underlying details.

While I am loathed to type it… some ICOs do attempt KYC in order to exclude some jurisdictions (this is usually popular for ensuring they won’t fall into US regulatory scopes) and the identity federation could also help them do that without creating more privacy risks… because ICOs can be sketchy enough.

^ I am not commenting on why they try and exclude some people from some jurisdictions (or whether that is OK or not) just that some do and the reality is they will continue to do so.

Exchanges that now don’t need to be IdPs

In a simple world, it means that with enough identity understanding within the federation a new exchange doesn’t need to be an IdP: it could simply be a service provider and consume the identity federations’s existing work to fulfil their KYC (they would continue to account for AML).

This is a largely blue sky idea as thats not how organisations trust each other… but it is a theoretical possibility.

There is a significant and valid privacy argument for reducing the number of organisations that an individual needs to send their personal data to when it is for a comparable purpose.

Hold on a second, so how does some key bits of this actually work?

Patience my friend… explanations come to those that keep scrolling (…sometimes… maybe).

So what identifier is used to query?

The ‘wallet’ public key.

The public key is just a string like `0x4a68cacd5f6bd7bf25b942b860701c01f6be7e30` (randomly selected Ethereum wallet — not mine) so is, on face value, great to be used for privacy reasons — you’re not transmitting email addresses all over the place.

Note: data protection law (rightly) does not consider the source or public nature of information so I have argued (and will continue to argue) that exchanges (etc) who can identity an individual and also know their wallet information need to consider the wallet address/info personal data.

Given the range of IdPs, how does one find which IdP has verified which public key?

Each IdP could be queried individually because as a federation it will be clear who the members are; where the API endpoint is and the schema to use (because they will all be using the same one — hooray standards!).

However, there are circumstances which complicate this simple functionality such as due to the fact someone who generated their wallet offline can verify the same public key with multiple IdPs using different emails/IDs (etc) and thus do so to varying levels of trust.

There could also be a proxy, or series thereof, which acts as an aggregation point to receive the same query; check all of the IdPs in the federation that should be queried; query them; and return an aggregated (highest value?) result.

Couldn’t each IdP verify to different levels though?

Yes.

IdP one may not have the ability to reliably verify bank accounts (or their commercial proposition does not require it) thus the existence of a proxy may become more important and de facto.

Are all IdPs equal?

In a simple world, yes, but in reality as mentioned above they will vary in capability as well as assurance around themselves — you wouldn’t be shouted at for trusting a regulated exchange based in the EU more than an unregulated one based in a non-extradition country that does not offer robust international grievance resolution and redress.

Isn’t the proxy a privacy and trust issue?

The proxy would only be relaying a query which is based on a public key and aggregating results. It would still only ‘know’ what a directly query to each IdP would show — sort of (I argued against my own thought train as I wrote…)

That all said, yes, the proxy is in a relatively privileged position and the assurance around it and the management/operation of it should be well considered.

What does an example query/response look like?

I am making this up but here goes! — No judgement please: this is off the cuff and not complete let alone technically accurate. No risk assessment has been conducted.

Example Query 1 (direct to an IdP):
{Public key; Known?}

Example Response 1:
{Public key; Yes/No}

Example Query 2 (via a proxy):
{Public key; Known?; LOA?}

Example Response 2:
{Public key; Yes/No; 2; 4}

^ re-iterate public key; yes/no response; # of IdPs the public key is known by and highest level of trust found across those IdPs.

Example Query 3 (from regulatory or law enforcement body):
{Public key; Known?}

Example Response 3:
{Public key; Yes/No; 2; 4; IdP[@]}

^ re-iterate public key; yes/no response; # of IdPs the public key is known by; the highest level of trust found across those IdPs and a list of IdPs who responded.

Go go gadget SAML.

Is this on or off chain?

There is no reason blockchain metadata could not be extended to include some of these markers (though that would be fun for message signing…) however what I have described is disjointed from that for simplicity — changing blockchains and wallets is not easy or quick and is largely contentious.

Surely there must be more to it than this?

Yes, but this is a just Medium post not a whitepaper — I also should have drawn a few diagrams but Medium doesn’t offer that functionality natively so I… er… didn’t.

The surrounding governance is not really considered by this post but entirely required — each federation member will need to be trusted to do the right thing and then checked against those promises, and because not all IdPs are made equal, this may mean a range in probabilities and the use of framework legal agreements; ISO27001; ISO9001 etc.

Each federation member will need a standards-based identity for themselves which might look something like mutual TLS auth; some awful expensive private managed PKI solution (please no) etc as each request/response should be signed/encrypted.

Who defines these standards and oversees the identity federation?

I don’t believe it should be a government body (but it could be an arms-length agency with government money) and would most likely be formed by IdPs talking to each other from across the world in collaboration with regulatory and law enforcement agencies being invited to the table.

Why would IdPs sign-up to be IdPs?

Because they will be (hopefully) required to conduct KYC/AML, this is just a more joined up way of doing so that both propels the market forward and helps them meet their obligations.

If the management of the federation paid IdPs for queries responded to that could certainly be another model as well.

What if someone does share/trade their private key?

This is comparable to giving someone else your online banking credentials — you’re not motivated to do so but there could be a rational reason you may want to (even though you shouldn’t!).

If a public key is verified and then the ‘account’ is sold, then yes, that new owner is in theory the wrong person. This is also an issue when someone changes their name; moves home etc.

The problem is not unique but it needs consideration. Good data practice covers this problem and usually requires/encourages data re-validation. In the identity assurance arena, this is usually through mandatory expiry on ‘idle’ or through re-validation after x period of time or y markers (background checks show address of individual may have changed).

In short, it is not simple and it is a fraud risk.

So what does this all achieve?

Better trade

Whether trading through an exchange (so the exchange is worried about processing naughty money) or individually, this would in theory allow the trust to be higher than it is now (nothing) in a privacy-friendly way.

This doesn’t mean you can’t trade with an unverified public key, it just means you could choose to trust some more than others or electively choose your trading buddies.

Web of Trust

Blockchain transactions are fun to trace in how they handle inputs and outputs (a random Bitcoin blockchain transaction) and in reality it is simple to attempt to obfuscate the true sender and true receiver by generating a lot of transactions and so on.

Where each transaction (which is publicly viewable, as I am blissfully ignoring privacy-orientated coins which specifically obfuscate transactions and wallets by design because by transaction volumes and market shares they remain niche — I’m looking at you Monero) shows a series of trusted or untrusted public keys, it is easier to understand what you could not before — is there identity and trust throughout? Could this be money laundering?

The vast majority of those involved in trading in cryptocurrencies do so through exchanges (even if they use a hardware wallet like a Ledger Nano S or Trezor) so it is likely that end-to-end identity and trust will be quickly achieved for a large number of users.

If you view it from a regulatory or law enforcement perspective: while you can’t simply dismiss them entirely ‘accounts’ that have verified identities versus those that don’t imply you can start separating the haystacks into at least smaller haystacks when looking for that nefarious needle.

Also from a taxation/regulatory perspective: you can now associate high-value wallets (public keys transacting or holding significant amounts) to a probable identity through a means you did not have before without difficult technical reverse engineering (‘the blockchain records indicate Bitstamp is involved, lets go talk them based on a guess’ etc).

Anti-money Laundering (AML)

As described immediately above, this web of trust can help you (probably a regulatory or law enforcement body) unpick (or not) suspicious activity and who they could in theory talk to about whether something is problematic or not.

This isn’t a magic bullet by any means as there is not proposing mandatory centralisation — one can continue to generate a wallet offline and choose not to verify it with an IdP in the network — but I think that is a healthy balance of introducing trust into the trading; providing a logic route for enforcement bodies and protecting individual rights (particularly privacy ones).

A disproportional crowbar to forbid certain types of wallets/trading and force everything down a strict one-size compliance path will only force some users further underground or away entirely which is probably why privacy-specific coins are increasingly popular in the face of perceived growing regulation.

Uptake explosion

Once there is a basis for trust (however optional) organisations can choose to only trade where there is trust: this opens the world up to the financial sector to jump right on it.

While we have Futures and other partnerships in the works to provide greater access to this market space we will not see scalable consistent investment and interaction until the ‘wild west’ ends and the price manipulation is squashed (although that will never be entirely gone) and part of that is reasonable identity and reasonable trust.

Can this be actually done?

Definitely, maybe

To be clear this is not needed and individual exchanges can continue to KYC/AML in their own wonderful ways.

In market where many things are green and many other things are commodity, doing ‘identity’ well (to me) seems like a commodity problem.

This is a lot of technology that needs to be made

Maybe — many of the required technical components exist in various forms (many open-source) and the identity patterns; threat modelling and framework agreements can also be creatively borrowed some existing identity models such as GOV.UK Verify or even eIDAS.

I know you set privacy-orientated coins to one side, but… what about them?

As with the existing financial transaction market the possibility to evade detection for nefarious ends will never truly disappear and there will continue to be an underlying ‘dark web’ of cryptocurrencies.

More in a future post… maybe :-)

What next?

Good question.

I am mainly waiting for IOHK and the Cardano Foundation to work across the sector and figure this out.

While one of my companies is increasingly consulting with clients on the use of blockchain I am not in a position to be at the forefront of such a movement because that is not what I/we are known for. If I/we were approached to assist I would gladly dive in.

You might find other exciting posts in my Medium profile.

Thanks to Robert for his peer review and reminding me I can’t speel.