If you know me or Betteridge’s Law, you can probably predict the answer, but there are still interesting points to be made. The most important being: it likely never will be.
Before we start, let me just rule out some perceived “applications” that will not be treated here. When I’m talking about “blockchain in the enterprise,” I’m not talking various bitcoins, about pump-and-dump scams like KodakCoin, I’m not talking about random cluster-B CEOs executing their own pump-and-dumps for the LOLs or to sell off their own bitcoins, and I’m not talking about “blockchain-in-name-only” solutions like the several rebrandings of existing distributed databases. Those are all bad and should be taken out back and shot, but that’s just not what we’re talking about here.
Blockchain “solves” a classical computer science problem within consensus: how do you get multiple parties to agree if they do not have a common base of trust? Consensus can be on questions such as “who owns this bitcoin?” or “is this user allowed to log in?” This is exemplified in the classical Byzantine General’s problem, where a number of generals need to agree to attach or retreat, but the cell coverage is useless, so they have to rely on messengers that can be captured by enemies and replaced by spies. The generals can only win if they all attack, otherwise they die, so it is imperative they reach consensus on the question “attack or retreat?” It is undergraduate curriculum to prove that this problem is unsolvable. Blockchain as implemented in bitcoin “solves” the problem by wasting computing power (and by proxy electricity) and letting the most wasteful person decide. Solves is in quotes, because there is always a probability that proper consensus is not reached, and it is always possible to trick other participants by just wasting enough computing power and electricity. As soon as we allow solving the problem with caveats, classical computer science has a plethora of off-the-shelf solutions to the problem as well under various assumptions. So, while blockchain does solve a problem, it does so in a very wasteful way that makes assumptions that rarely hold true (absolutely no trust between peers).
Decentralized Identifiers
With that said, blockchain does solve the consensus problem, so it might be possible to use this in the enterprise for consensus-related stuff, why not? One genuine problem is that of identity online. I have an identity when I’m logged into the WordPress blogging software you’re reading this on. I’ve another when logged in to my work systems, another one on LinkedIn, Twitter, Apple’s eco systems, etc. Heck, I even have 4 separate identities for Microsoft Office (a personal id, one for studies, one for work, and another for a customer at work). It would be nice if I would just have one identity, but no provider can likely be trusted with this. In addition, while I don’t personally go to great lengths to keep my identities apart, I don’t need my Twitter shitposts to show up on LinkedIn, so I’d also like to able to separate identities on different sites. It’s a genuine (first world) problem.
Blockchain claims to have a solution for this: decentralized identifiers (DIDs). The idea is that you generate an id somehow, and have to prove ownership of this id. This id can then be used on all participating platforms. This is very close to the idea behind OAuth, OIDC, JWT, JOSE and similar related technologies: you get an id, state where the ownership can be verified, and participating platforms can then validate your credentials. This is what is happening if you use the “sign in with Apple/Twitter/LinkedIn” buttons on various sites (or if you try logging in on my blog, except I host my own id provider). DID instead says that this is bad because you then need to trust the id provider, which has some truth to it, and wouldn’t it be better if it just happened without having to trust a particular id provider? The linked standard goes on to reinvent the JWT/JOSE standard, except leaving doors open so “sign/encrypt credential with a known, efficient, and tried technology” can be replaced by “use a blockchain and accomplish the same, maybe, by wasting power and electricity.” I’d like to note that this is not some random “whitepaper” on a website ending in .biz, but a real W3C standard near recommendation that actual people might read and think of using.
DID has one remarkable shortcoming, though. If you go to section 7, the one about actually verifying a credential, the current draft as of May 2021:
Let me translate this if you didn’t bother reading it or had a hard time making sense of the rather heavy language: “this feature was too hard, so we moved it to another standard to make it somebody else’s problem.” A standard dedicated entirely to copying another standard on defining identifiers and verifying ownership of them found it too difficult to implement the “verify ownership” part of the standard. This is equivalent to a student going to a written exam, filling in the freebees like name and date, and for all actual questions just writing “ask prof, lol, i dunno,” and expecting a passing grade for this. The standard solves absolute no problems. The feature has been moved to another standard, currently at version 0.2, and I’m sure will be due out “in two months” perpetually.
As mentioned, this post is based on the May 2021 draft of the standard. The April 2021 draft did not completely take out the feature, just containing the warning, and earlier this year the section contained some hand-waving explanation about resolving identifiers to DID documents (which would essentially contain a certificate which could be used to verify signatures made by the owner of the identity, thereby validating their identity). Except, even before the feature was taken out for being too difficult, the standard didn’t even do that. It defined a general infrastructure of protocols for resolving DID documents. That means the specification of how to actually resolve a concrete identifier was delegated to further standards, one for each type of identifier. The first standard was using a regular web-server (ignoring the testing standards), and some drafts are made for various blockchains (and classical SSO providers, lol).
Note that none of this cannot be solved using plain JWT/JOSE: provide an ID token, the participating application looks up the “issuer” (id provider) field in the token and validates that the signature on the token matches that of the issuer. This out of the box works with multiple providers (just change the issuer field), and requires you either provide a list of trusted issuers or set up/piggyback onto an existing trust architecture like the existing one for issuing certificates for web-sites.
So, to sum this up, DID solves the problem of having to trust a particular ID provider by instead defining a framework, which requires you to trust a particular protocol (specified elsewhere). The most stable protocol is exactly the same as the existing implementation, with the true decentralized solution “coming soon.” The actual difficult part has not only been taken out of the standard and delegated to individual protocol standards, but the part that says that is what is happening has been taken out of the standard and postponed to another standard coming “Real Soon Now.” This is very typical blockchain: claim to solve a problem, provide an intermediate solution that is equivalent to an existing solution, just different because… reasons? and claim the “real solution” is coming soon, better get on board now instead of using what is known to work because… reasons? and please buy my tokens…
Verifiable Credentials
If we assume the identification problems has been solved, either using DIDs (lol) or using classical JWT/JOSE identifiers, how do we communicate access rights? Surely, LinkedIn would not trust the same credentials as I send to Twitter? Enter the Verifiable Credentials (VC) standard. VCs combine classical JWT/JOSE tokens with the with-it and happening standard RDF (which is admittedly cool, but unlikely to ever become a thing outside niche applications and academia), and blockchain.
JWT/JOSE specify permissions as “claims,” which are just generic JSON objects inside another JSON object. Some properties have a pre-defined meaning, some by de jure and some by de facto standards. It’s not perfect, but it is working. VC instead says that claims are RDF documents, specified using the JSON-LD standard for transforming linked data to JSON. The RDF documents can be specified using an external ontology (see, a theme: a crypto standard delegates the actual specification as somebody else’s problem). It’s fine, but it’s not great. JSON-LD is a clusterfuck of a standard, making JSON objects that are not canonical (the same meaning can be expressed in many different ways). This makes is much harder to parse without a full RDF framework (which may or may not require reasoning over a non-computable language). I know, I have always been looking to add that sort of complexity to my security stack. Anyway, this is just the iffy part, not the really bad part.
VCs are intended to mimic physical credentials. For example a user may need a proof they are 18 years or older to purchase weapons online. This can be attested by a trusted party (trusted via DID or via an actually working “legacy” solution like JWT/JOSE) and included in a request for weapons online via web-service. This can also be useful in business settings, for example a unit manager can grant permission to one of their minions to access a company resource (e.g., email or an intranet) without having to involve an IT department who is able to grant all permissions to all employees.
So, VCs can be embedded in verifiable presentations. That’s just envelopes. They literally only serve the purpose of wrapping multiple VCs into a single message. So, we have JWTs, but worse, inside other JWTs, but worse. Saying anything using JSON-LD instead of a plain claim is 2-4 times more verbose, and every time we say JWT, we make the message 33% larger (JWTs are typically, and in this case, base64 encoded which only uses 6 bits of each byte so it is possible to send over UUCP mail and NNTP and other similarly relevant technologies).
Disregarding making our security stack rely on non-computable elements, blowing credentials up by a factor 10, the really, really bad part is that the standard comes with built-in replay and other man-in-the-middle attacks. That’s right, the security standard is insecure by default. This is mentioned in non-normative section 8.4 (and further elaborated on in non-normative appendix C):
I’m not a security expert, so my advice and own mode of operation is always to 1) use a known-good implementation of a known-good standard in a known-good way without making my own changes to “improve security” or, if that fails, 2) make and rigorously test a hopefully-good implementation of a known-good standard and pray bugs get discovered by somebody with a white fedora before somebody with a black trilby comes around. The first rule of security is always to not roll your own and rely on existing implementations and standards. Making a security standard that fails when using this strategy is like selling a gun that also shoots projectiles out the back and put a note on page 57, in the middle of some unreadable legalise nobody sane would ever read, that says “maybe wear a bulletproof vest or point back of gun away from self when firing.” Yes, technically the gun discloses it is dangerous when used normally, but as a user it is fair to assume that when used normally it wouldn’t kill you. Similarly, it is fair to assume that a security standard is secure by standard. This is based on the November 2019 recommendation, BTW, so this doesn’t even have the advantage of being able to claim it is still a draft. This is outright irresponsible!
The most obvious bug (aside from replay attacks and other DoS-like attacks), this standard suggests you implement, is that it enforces no integrity checks. For example, consider that in most European banks you can withdraw money using your passport if you have lost your bank card. Now, consider I wanted some free money, and I happened to know that Donald Trump went to a hotel nearby recently (one of the ones with plastic sheets and room rental by the hour). Hotels require clients present a passport, and they make a copy for their internal records using a laser printer with a drum that has been beeping for replacement since 2005. Now, I break into the hotel. Or my job is to “clean” the toilets. Or I bribe the clerk. Using any of these methods, I get the copy of Trump’s passport, put on a fake moustache and waddle into the nearest bank. I tell them my name is Michael, show them the copy of Trump’s passport, and ask to withdraw €10000000000000 from Vladimir Putin’s account. The bank looks at me, looks at the copy of a passport (where the picture obviously does not match me because Trump has no moustache, has tiny hands and also is more orange than Amsterdam on April 27th), look at the account that doesn’t match with the passport, see that the amount I wish to withdraw is not available in the account, and proceeds to hand me the money and wish me a good day, while remarking it is curious I was also there to withdraw 5 minutes ago, and looked entirely different then.
This sounds insane and outrageous because it is. But that’s what the VC standard allows out of the box: it is possible to wrap VCs in VPs without any correspondance between them. That means I can take a VC, obtained somehow (as a rogue part of the network, using a MITM attack, or as a rogue employee at a legitimate part of the network, to mention just the ones that immediately spring to my mind), wrap it in another VP created and signed by me, and presented as mine. All the individual parts are completely legitimate on their own, but add up to a pile of nonce-cents. The VC in this case is Trump’s passport and the VP is me presenting it at the bank. There is no canonical way to link the VC to domain data (Putin’s bank account), it’s just outside the scope of the standard. The bad photocopy of fake moustache in the story serves no real purpose but to illustrate the ridiculousness: in a digital world, a copy of a passport is identical to the original and indistinguishable, and the bank clerk doesn’t know me, so the fake moustache only serves to remind readers that VC is so ridiculous it literally supports a scenario so silly that such epitomes of moon logic as adventure games have been ridiculed for it.
There are sort-of legitimate reasons this moon logic exists here: the standard also wants to work with more complex cases, such as performing actions on behalf of others (e.g., somebody being the legal guardian of somebody else or having power-of-attorney), or legitimate impersonation (allowing an administrator to perform actions as somebody else). But the solution is not to make a gun that will kill the user on first use, but to actually solve these difficult problems if that is your intent. Not this roley-poley-fucking-holey piece of shit standard.
What happens is that credentials that should not be secret, such as a person’s age, becomes a bearer token: anybody with access to the token can gain any rights granted by the token. This is generally frowned upon, and bearer tokens typically have lifespans of a seconds to a few minutes because they are dangerous. VCs instead are intended to be long-lived, public, and refreshable, which allows a pre-teen to use their parents’ id to purchase a gun online. A gun that shoots backwards. The only way to fix this is to add things on top of the standard, which essentially means rolling your own security, which then needs to be audited (lol, if you think that happens in most cases).
Again, we see a blockchain that despite the name isn’t even a chain of blocks. It’s just blocks, a cheap and bad knock-off of LEGOs. It badly copies what is already existing, deflects the actually complicated parts using a SEP field, and delivers a fundamentally flawed “solution.”
Self-Issued OpenID Provider
Now that we’ve solved the problem of identifying users, them demonstrating they have certain credentials, the last bit(coin) to get a fully dysfunctional blockchain solution to authentication is to allow users to log in. The current solution is OAuth/OIDC (or SAML if you are particularly enterprisey). That’s the “log in with LinkedIn” button you see when you wish to sign up for Belle Delphine’s OnlyFans. Now, to identify myself, I do not have to create an OnlyFans account, but instead get sent to my LinkedIn account, where I log in if I’m not already, and LinkedIn then does the whole identification thing and I get access.
The problem with this solution is that in many cases, you end up with a lot of these buttons log in with Twitter, Github, O365, etc. For example, there is a Dutch payment solution that allows me to pay for things online using a Dutch bank account. To pay somewhere, I select my bank, get sent to my bank’s page where I used to have to log in, but these days just get a QR code I need to scan with my mobile bank app, and then payment works out.
Instead, Self-Issued OpenID Provider (SIOP) tries to solve the fundamental problem of “clicking on a button” by instead, you guessed it, making it somebody else’s problem. Instead of getting sent to my bank’s page, I get a special URL that my browser has to recognise and then send me to my bank’s page. Or I can configure it to send me to LinkedIn, or Twitter, or my self-hosted application. Some may require login from particular providers (like a webshop that wants payment for industrial-grade diesel-powered sextoys), while others may take any kind of ID (like TikTok, which just wants me to boost the likes for 14-years-old influencers from Siberia).
SIOP does kind-of solve a problem, especially for particularly loosely-identified services that just want to provide me a standard account with my personal settings and no further authentication (or which want me to provide a VC so they ac grant me permissions rightfully belonging to others). The problem is that it makes the assumption that browsers will support this. Like, all of them, on all the platforms. The browser-manufacturers who cannot even agree on how to make text correctly blink on the web, need to agree on a authentication method they do not control, despite each and every one of them having their own identity networks.
I cannot provide deeper technical insight on the SIOP standard, as I got it kicked from the project before I had to read the standard in details, but looking it up for this post, I noticed it has now been cancelled in favour of SIOP v2, hanled by another standardisation group, and which will be incompatible.
As conclusion here, let’s not focus on how the standard never materialised, how it delegated the real complexity to somebody else, or how it solved problems that has established solutions that are tried and tested on the large scale. Let’s instead review how Microsoft has actually and really solved the same problem: if you’ve ever logged on Office 365 from a corporate account, you may have noted that you started typing in your email in a field on one page, only to get redirected to a page as you move to the password field. That’s because Microsoft notices that your account is really authorised by an external system while you type it in, so it sends you there, with everything you’ve already typed and little inconvenience to the user. It is clever, a bit hacky, but you know what it is not? expecting you to use a dodgy browser plugin or a browser that doesn’t exist yet.
Conclusion
So, let’s sum up my experiences with using blockchain standards intended for the enterprise. I’ll not even go into how these standards are poorly-written meandering nightmares that take forever to read because they are so focused on irrelevant junk and trying to hide that they are “solving” an already solved problem, but just mention that blockchain standards always
- Promise fancy solutions that will blow your mind,
- By delegating the fancy solution to an external document to be written by somebody else “any day now,”
- But providing a temporary work-around, which is just a worse non-standard way of doing something that already exists, and
- Never arriving or at best arriving years late with a severely reduced feature-set.
So, to answer the question posed in the title, no, blockchain is not ready for the enterprise. And I don’t think it ever will be. Blockchain is a technology aggressively ignoring the past 70 years of developments in computer science. It is perpetuated by the same useless people that 5 years would have been talking about IoT, 10 years ago built another social network for 15 people, and 25 years ago were backing pets.com. Blockchain always defines “frameworks” and “layers” that have to be filled in by others, but for now here’s a worse solution than what you already have, so you can be future-proof when blockchain takes off Real Soon Now.
I cannot blame the architect wishing to use these standards in a project. If you don’t dig really deep, they do seem to provide a nice solution, and if you believe the claims that it will be ready any minute now, why wouldn’t you use an emerging standard that will surely be required in the future? Of course it makes sense to base a project that will be done in 1-2 years on a standards that’s near-complete and will be out in ½-1 year’s time. The problem is the charlatans trying to sell it.
Instead, just stick with recent version of tried frameworks and standards. When (lol, never going to happen) blockchain takes off and publishes something useful, you’ll have years to implement it anyway, because the existing standards will be obsoleted and replaced by something incompatible by that time, and everybodt who has prepared using future-proof current standards will hve to first get rid of that junk which will be obsolete and incomplete before implementing something that works. Or, you know, something else (statistics for dumb people AI) may take the fancy of these people that develop software using Powerpoint and a Reddit account, and that will be the new thing you “cannot live without.”
