A cautionary tale of reinventing the wheel and history repeating itself in the name of blockchain
Recently, at the European Identity & Cloud Conference (EIC) 2018, I delivered a talk titled ‘Lessons Learned from Integrating with Blockchain Identity Providers”. It’s probably the only time I’m going to give this talk, and it seemed to go down well if only as a cautionary tale, and as an example of past mistakes and failed technologies repeating themselves.
You can find the original slides on SlideShare.
Why Would I Do This?
Back in November/December, this little thing called Bitcoin had a dramatic surge in value, and as a result, there was a rush to put anything and everything “onto the blockchain”. Something about Web 3.0 and ICOs.
This all sounded very exciting to me, and I wanted to get involved. Now, I’m not going to pretend to be an expert on blockchain, but I still wanted to contribute in some way. I’m primarily a software developer with an expertise in identity and protocols such as OAuth and OpenID Connect, so maybe there was some cross-over here. As it turns out, the combination of blockchain and identity is a very popular topic.
So, my goal was to go out and find a blockchain identity product, maybe integrate with it using my programming language of choice and then present it to my particular niche community as the next “big thing”. Put simply I wanted to find an external identity provider I could use to receive identity data.
In this article, we’ll take a walk through my journey from my first Google search, to (spoiler alert) why I’m still searching.
I’m going to be Vague
I’m not going to explicitly state names of products & companies in the article; however, if you take a look at past articles or my GitHub history, it won’t be hard to find the main culprits.
Initial Google Search
Simply searching for “blockchain identity” on Google reveals that this is certainly a space that has a lot of activity. Searching for “identity” on icoalert.com gives us 61 projects both past and upcoming. So, yes, blockchain identity is definitely a thing.
Luckily for me, there was already a curated list of all things blockchain identity that includes articles, products, academic papers, you name it. The last time I checked, there were 91 links on this page.
91 is a bit too high for me; I was interested in the subject, but not that interested. So, to narrow things down, I looked through this list for products with a full product page (and not just a one-page placeholder site for vapourware). This brought the total down to 17. Apparently my wife enjoys speaking to me, so I was made to narrow this down further by looking for a product with a product page, with apps available on the iOS app store for public usage (and not hidden behind an “enterprise” contact us now form). This brought the total down to a more manageable 3.
Initial Impressions
Initial impressions from looking through the product websites where promising enough. There was some developer documentation, maybe just a single page walking through the usage of an integration library, explaining what was happening behind the scenes.
The products typically only had one integration library, mostly written in nodejs, which, while not my first choice, was something that I could work with and adapt to my preferred platform.
A developer portal was also available, allowing you to register new applications to use the product, including app identifiers, allowed URIs, and private/public keys. These were fairly basic; however, it was good to see each product eat their own dog food; each developer portal was protected by their respective product.
One thing that did make things awkward was whether or not the product was “tokenized”. If it was, most Google searches for the product resulted in some well-groomed, young individual regurgitating the sales page and telling me that it was the next being thing and that I needed to invest. If the product built upon an existing blockchain, then a Google search typically brought back more useful data such as a conference talk by the development team or a community article.
The Typical Flow
Next up, I took the products for a spin using their demo applications. This gave me flows that looked like the following:
- The identity requestor (some application) made a request to the blockchain identity product
- The blockchain identity product did something on the blockchain and responded with a QR code to display to the user
- The QR code was scanned by the user using the blockchain identity product’s mobile app
- User consents to identity data being shared
- Identity data is sent to the identity requestor
Now, this might look familiar to you. That’s because it’s basically OAuth/OpenID Connect. In fact, this is pretty much identical to the upcoming OAuth Device Flow.
Let’s change those names to something more honest:
Here the identity requestor is the client application (or maybe the relying party), and the blockchain identity product is the identity provider.
I found this quite exciting. It’s something I know, and in turn, it’s something I can work with.
Dig a Little Deeper…
Things were starting to smell though.
This flow is nothing new; it’s based on well-known and mature open standards, and yet one product had actually gone and trademarked the above flow, and then had the audacity to start badmouthing OAuth/OpenID Connect. Digging a little further into their implementation and it becomes clear that this was not only a reimagining of OAuth but also a bad one, ignoring years of innovation upon the original standards and best current practices.
Each product was desperate for people to create integration libraries. This came as a shock to me, as there are already hundreds of libraries available for OAuth and OpenID Connect integration. What made these products so special that they needed their own integration libraries?
I also saw no evidence of blockchain usage. Sure, I could buy tokens on various exchanges and read some outdated whitepapers, but I saw no evidence throughout the usage of the product that showed the usage blockchain, or how it benefited identity. If the product used smart contracts things where a little clearer since the product gave me transaction ID’s that I could then lookup, but still, how did this help and improve upon existing solutions?
I also felt mis-sold. These products had sold themselves as having no single point of failure, making the bold claim that even if their servers went down, your system would be unaffected. However, this wasn’t the case. All network requests pointed back to a single identity provider, which if it were down, would cause my client application to stop working. This is fine, it’s something we are used to and deal with in OAuth and OpenID Connect, and it’s something we factor into our risk assessments. Just don’t lie about it.
The Code
My next step was to try and integrate with some of these providers, either using my programming language of choice or their integration library. And this is when things got really scary.
The first big issue was the use of JWTs. Now, I know we all love JWTs and probably use them more than necessary, but some of these products took it to the next level. We literally had JWTs within JWTs within JWTs. We had non-standard signing methods. By that, I don’t mean the use of elliptic curves that aren’t officially in the JOSE suite just yet, but multiple signing methods on the same JWT and multiple signatures appended to the JWT (breaking most JWT handling libraries as a result). We also had non-standard JWT encryption methods being used. Either the developers didn’t know about JWE, or they thought they knew better. I’m not sure which worries me more.
We then had hidden public keys. Because the products weren’t using open standards, it also meant that they had no metadata or discovery documents for publicising public keys. Instead, in order to find the public key to validate JWTs they were sending me, I had to dig through the source code of their existing integration library to find this hardcoded string. Looking around, when the community created libraries they faced the same issue and didn’t know where to look. As a result, some integrators just gave up and didn’t bother validating the JWTs.
We also had instances of private keys that were no longer private. So, one product had this amazing reactjs template that automatically gave you a pretty website complete with integration with their product. All you had to do was simply copy & paste in your configuration such as your application ID and your signing keys. However, the default setup for this template had developers pasting their private keys into JavaScript that would then be downloaded and run on the end-user device. This means that their private keys were no longer private.
This template came with a 15+ page article explaining how to use it. It was full of emojis, memes, and some very trendy language, and yet it only dedicated one sentence warning you not to put your private keys into your code like this, and that you should maybe change this before you entered production. However, they offered no alternative. After some digging, I did finally find the library they recommended using for keeping private keys server side, and some demo code of how to use it, however, it turned out that that library had been broken for approximately five months.
And even if you ignore all the above issues, the products with their OAuth-not-OAuth implementations are now starting to face implementation challenges that have been long solved. These products have forsaken open standards and the work of industry experts, and as a result, they are now starting to realize that their implementations do not work for native applications (such as mobile apps), single page applications, or even “Đapps”. They’ve talked the talk about web 3.0, but their current models seem to only work securely on traditional web server applications.
Stephen Wilson’s “Proposed Digital Identity Stack”
I think Steve Wilson’s Proposed Digital Identity Stack, that was featured in a recent IDPro newsletter, perfectly illustrates the issue with these products. Here we have the different layers involved in an identity system, and if you ask me, they are all equal in terms of importance. If you get one layer wrong, the entire system falls apart.
What these products have done is leave the last two layers to the last minute, or just decided to reinvent them, causing any work they’ve done on the other layers, or even with distributed ledgers, to be redundant. It’s as if they’ve insisted on trying to do something new and revolutionary for each layer. And that’s a real shame because I’m sure some good work was done in those other layers.
There’s Still Hope
All this being said, there is still hope. Open standards are on their way in the form of the Distributed Identity Foundation (DIF) and Sovrin, calling on a wide range of industry experts.
That said, both of these organizations have only just started authentication/integration working groups, while I would argue that these should have been considered from the very beginning.
Also, looking at the members/contributors in the DIF I see some of the products that were reviewed as part of this article, and even some known bogus blockchain projects such as IOTA. I’m not sure how much these organizations contribute, but it was still a shock to see them listed as members.
These two organizations seem to be much more rational and open in how they are doing things, engaging with and building upon existing community efforts and standards. It’s going to be interesting to see what these folks come up with.
The Moral of the Story
If you’re building one of these products, please do not work in a silo. Do not stealth release your product. Get involved with the community, look at current best practices and open standards. Not every part of your product needs to use the blockchain or other blockchain based products. If you have truly found a use for the blockchain, focus on that singular goal, just don’t reinvent the wheel and everything else around it.
Whether or not blockchain has any use in the identity space is yet to be seen. I think the concept of self-sovereign identity (a subject for another day) is interesting, but I’ve yet to see a compelling argument or use case that truly means that distributed ledgers are necessary for identity or self-sovereign identity. What I can say for certain, however, is that current solutions should not be used in production.