Building Decentralized Identity Solutions, Responsibly
An important factor in the success of self-sovereign identity (SSI) has been the recognition that interoperability via open standards is essential. Contributors to this open ecosystem include huge players like Microsoft and IBM.
If you’re a fan of movies about the early PC wars (e.g. Pirates of Silicon Valley), it’s wonderful to see this sort of cooperation. SSI contributors/builders recognize that the stakes are extremely high with identity solutions.
Fortunately, non-tin-foil-hat wearing individuals are becoming increasingly aware of the problems caused by companies treating data irresponsibly…whether through honey-pot data leaks or 20-page EULAs that only increase opacity.
In January I gave a talk at MIT’s Digital Currency Initiative about Blockcerts’ past and future. I ended up spending a lot of time on the topic of growing an open standard and community while building a commercial product. Navigating these seemingly conflicting goals is a common pattern in the SSI space. From a commercial and technology perspective, of course everyone hopes their solution will succeed. Yet we all have a high incentive for interoperability. And that is because we know that the stakes are so high.
My goal with this article is to describe how I’ve navigated this tradeoff since Blockcerts’ inception. I hope this raises useful discussion points for best practices — not only in decentralized identity solutions, but also blockchain-based solutions, and possibly any company walking that fine line between open-source and a commercial product.
Blockcerts
Blockcerts began as an incubation project between the MIT Media Lab and Learning Machine. Philipp Schmidt (@schmidtphi) pioneered a blockchain-based credentialing solution based on Open Badges that addressed the problem of decentralized verification.
That’s where I got involved. Through Learning Machine, I worked with Philipp and Juliana Nazaré to open source their work. For me (and I hope for them) it was a wonderful collaboration. But I’m sure I benefited the most from the arrangement — for example, giving me the ability to tap the brains of brilliant folks at MIT Media Lab and the DCI. Neha Narula’s incisive questioning from first principles was invaluable, and enabled me to succinctly communicate where the Bitcoin blockchain was useful to our specific use case (note: in general the SSI community needs to discuss this topic more).
From Philipp and Juliana’s original work, we grew Blockcerts into an open standard for creating, issuing, verifying Blockchain-anchored credentials. Blockcerts’ current schema is an extension of Open Badges enabling decentralized verification.
It’s critical that the Blockcerts specification is theoretically blockchain-agnostic (reference implementation includes Bitcoin and Ethereum). We were wary of blockchain-based solutions that took the approach of (informally) “put all your data on our blockchain, we’ll make your dreams come true”. This decision helped enable recipient control and portability; i.e. Blockcerts had no skin in the game to select a specific blockchain.
From a commercial product perspective, this flexibility also allowed us to move quickly. We could focus on building usable a SaaS product while developing and advocating for open standards and open source through bodies like the W3C Credentials Community Group, Rebooting Web of Trust, and the Decentralized Identity Foundation. For example, Learning Machine has an incentive for Decentralized Identifiers (DIDs) to succeed, but has no incentive for a specific DID method to succeed. (So for example, Learning Machine would be happy to provide a flexible DID provider model allowing customers and recipients to choose the method they want.)
This approach allowed us to contribute to open solutions that help ensure interoperability and user control.
What went well
Market Support of Open Standards
By carefully setting scope, Learning Machine was able to build a credentialing solution that promotes recipient control and attempts to avoid lock-in via open standards, open source, and SSI community engagement.
Building a responsible commercial credentialing product required phased releases that were not overly ambitious in scope (i.e. not risking a privacy nightmare). Specifically, the first releases targeted lower stakes credentialing scenarios. (The Blockcerts roadmap describes the open standards path to higher stakes credentials.)
We were able to build a vibrant open Blockcerts community by focusing on open source developer usability. Our solution required minimal resource overhead — our quick starts allowed credential issuance via the Bitcoin regtest test network and testnet Bitcoin explorers. The open source included a Dockerfile for issuers, easy to deploy verifiers, and open source, free iphone and android Blockcerts wallets.
For Learning Machine, this commitment to openness and interoperability was a huge selling point for our customers. I can’t emphasize how significant this is — our customers understood the importance of recipient centrism (and longevity) of their credentials and actually made purchasing decisions based on this.
It’s wonderful when the market pushes for solutions that are in individuals’ interest.
Support for Full Transparency
It must be frustrating for sales and marketing folks to deal with their technical counterparts starting every conversation with all the caveats and limitations of their solution. Luckily, Learning Machine was supportive of this — as were the standards communities we work with, and even customers.
In my mind, it’s obvious that if you are building an identity solution, openness and standards compliance is essential. And of course it’s fine to talk about what’s available now vs what will be available in the future. But there are a lot of scammy blockchain pitches in general, so identity plus blockchain? You better lay it all on the table*.
*I know, I know, except for IP…but some companies seem to think every fleeting notion is a precious little IP nugget…and these companies are generally the ones doing the least interesting technical work. A topic for another day.
The SSI community is still at the beginning of understanding the impact, corner cases, and best practices of using blockchain-based identity solutions. Fortunately, major participants in the space are extremely committed to open standards, transparency, and careful/cautious incremental deployment of solutions.
We wrote regularly about Blockcerts’ design decisions, existing limitations and roadmap, and worked with SSI community groups to investigate better solutions. That included improving revocation techniques, removing centralization points, and increasing options for recipient control and privacy.
The community was extremely appreciative of the ability to ask about specific concerns (see for example Blockcerts community discussions on revocation and centralization) and get a technically precise response on the limitations and future plans.
Vibrant Open Badges Ecosystem
The Open Badges community was incredibly supportive and valuable to Blockcerts’ success. Open Badges has a robust ecosystem, is based on recipient-centric principles, and a commitment to supporting interoperable standards.
Folks like Nate Otto, Kerri Lemoie, and IMS Global helped us fine-tune Blockcerts’ role in the Open Badges community and specification. And Serge Ravet, whether you like it or not, your perspective was essential, and helped me get to the bottom of where blockchains fit in. Even if we disagree about the details, you are right, it is all about trust.
Challenges
Schema/Specification Restrictions
When we started, the DID and Verifiable Credentials (VC) standards were, and still are, in their infancy. Some may debate this viewpoint, but I feel that using the Open Badges schema as our basis increased our backcompat burden by limiting our options at the time. The data model and somewhat limited privacy dials make it better suited for low stakes credentials. This is in contrast to VCs, which have a very lightweight structural overhead and robust privacy/security spectrum.
Also, while blockchain anchoring addressed the credential integrity verification problem, there were additional centralization points during verification that would require breaking from the Open Badges standard, including issuer authenticity and revocation checks. That said, the magnificent Nate Otto built an approach with us that enables Open Badges to utilize the advantages of Verifiable Credentials.
But to be clear, there were no well-known standards addressing these problems at the time, and even now are not commercially deployed (in contrast to Open Badges, which are widely deployed). For example, the DID spec, which would allow us to decentralize the issuer authenticity problem, is still not yet at v1.
Maintaining an Open Source Project
If only I had known.
I take it back — it was wonderful having an engaged community interested in building and deploying Blockcerts-based solutions.
What I didn’t predict is that Blockcerts would end up being many developers’ first introduction to blockchain programming…and aspiring developers…and more. And that is a wonderful thing, I constantly tell myself. It really is.
Blockcerts developers (credits at the end) made the open source very easy to use, with Dockerfiles, READMEs, command-line utils. But this opened a floodgate causing us to initially spend a lot of time explaining what Docker is, helping people debug their machine-specific docker issues, etc. Although an unexpected side-effect, we did appreciate the opportunity to introduce more people to the joy of blockchain programming.
On the community engagement side, we tried several forums. Of course, nothing beats github issues for developer-centric discussions, but what about people just getting started, or people interested in higher-level discussions? We started with a dedicated slack organization, but it was (and remains) not super searchable and browsable, and we found ourselves answering the same questions again and again. We eventually switched to Discourse, which was the sweet spot for Blockcerts.
The above work was initially a heavy investment of company resources. Over time, as more people started participating, the community became more self-maintaining.
Governance
All SSI companies using a combined “open standard/commercial application” approach face the challenge of managing perceptions around who governs the evolution of the standard, and who benefits from it. That’s especially the case where one commercial player might dedicate a significant amount of resources to the development of the standard. Other companies may be reluctant to join the effort if they see a potential competitor being too closely associated with it.
There is a natural tension between the need to craft marketing messages highlighting the potential benefits of new technology, and the careful technical deliberations behind it. Open standards are particularly sensitive to uncertainty. If there is uncertainty about the intended purpose of a standard, the type of capabilities it offers, or the way its evolution is governed, it can hamper community buy-in, especially from other commercial partners.
My suggestion is to invest up front in the following (I owe a more detailed post on each of these bullets):
- Governance
- Touchpoints to ensure the commercial/open standard communications are accurate
- Accept that not everyone will understand the tech, so take the time to explain to everyone in different roles
- Develop external communication guidelines
- Be very clear (and communicate) about the limitations
- Clearly delineate what is part of the standard
Lessons Learned Highlights
When we started, the standards we needed weren’t ready yet. The emerging SSI standards were the missing piece, and this made all the difference. Finding common purpose with SSI and related credentialing communities accelerated our understanding of the technical challenges and best practices. We benefited from 20+ years of experience from those communities.
We found that our customers and the SSI community appreciated our transparency and contributions. Everyone recognizes that SSI tech is just getting started and we need to work together.
I’m especially grateful for every critical voice we encountered, because it allowed us to refine our thinking and solution. Thoughtful criticism is a gift. Be wary of those who won’t embrace it.
Lastly, I was delighted to find there is actually a demand for standards-based solutions, and found that taking the time to research and participate in those related communities paid off in spades.
Now into the Future
The Blockcerts roadmap describes priorities for increasingly high-stakes credentials, including removing centralization points and increasing options for recipient control/privacy through DIDs, VC alignment, and other improvements.
We will continue building SSI standards and solutions through Blockcerts, the W3C Credentials Community Group, W3C Verifiable Credentials Working Group, Rebooting Web of Trust, Internet Identity Workshop, and (most recently) through our position on the Decentralized Identity Foundation steering committee. DIF is building valuable prototypes and pre-standards of fundamental SSI stack elements including claims manifests, credentials exchange, and identity hubs — all of which are essential to the Blockcerts ecosystem.
Bonus: The Carrot and The Stick
The carrot of transparent decentralized identity solutions is, as described above, market demand. I’m actually equally excited about the stick — GDPR and other emerging privacy regulations.
While GDPR is baffling to even the most patient of us, the more I drilled in, the more I appreciated both the intent and generous rollout. It’s steering companies to better privacy practices by causing companies to think deeply about (and architect for!) privacy and individual control of data. By “generous rollout” I mean it recognizes that, as a new/complex regulation, people may not grok all the nuances immediately (which tbh aren’t fully shaken out yet), while supporting well-intentioned actors by encouraging them to think about their users’ privacy, implement solutions, and document their decisions.
Conclusion
This article was prodded by my presentation to DCI about Blockerts’ past and future, when I started thinking about the unique situation of the SSI space, consisting of individuals, organizations, and for-profit companies miraculously cooperating to build interoperable standards. It’s incredible that the market is asking for interoperable standards, and recipient-centric approaches. I hope my observations and lessons learned can benefit others in the space, and start a conversation on best practices.
Thanks to the people mentioned in the article; to the Blockcerts developers — Matthieu Collé, Chris Downie, Julien Fraichot, Lucas Parker, Yancy Ribbens, Anthony Ronning, and João Santos; to Dimi Arhontidis for his inspired design work; to Dan Hughes and Chris Jagers for beginning and continually supporting the collaboration on behalf of Learning Machine; to Christopher Allen, Joe Andrieu, Manu Sporny, Heather Vescent, and Kaliya Young for embracing us into the SSI community, as well as sharing their identity expertise — strongly influencing Blockcerts’ evolution; and of course Natalie Smolenski and Chris Jagers for their impressive work evangelizing Blockcerts. Lastly, thanks to Dave Fields for a remarkable display of Blockcerts support I shall never forget.
