Each Govstack specification offers a blueprint of a digital service landscape. Assuming you think this is possible, among the various Govstack specs, the most important is the GovStack Identity Building Block specification– because most governments that participate in the 50-in-5initiative will start their digital public infrastructure projects with “identity”.
But the Govstack identity initiative is not going to work. This article will raise five “buts” or reasons that will highlight some of the challenges. ButI will also offer five possible course corrections which may help the effort achieve more success–or to at least accelerate momentum toward a different solution.
This approach to Momentum Thinking was developed by John Wolpert in The Two But Rule. The format is simple. The first “but” is “but that will never work because…” The second “but” is, “but it would work if…” The idea behind the book is that “buts” should always come in pairs–two “buts” are better than one. The first “but” identifies the challenge; the second “but” suggests a solution. Even if the second “but” is ridiculous, it still maintains momentum. You always want an even number of “buts”! Unless that even number of “buts” is zero! Wolpert warns that a “no buts” environment results in a culture of toxic positivity clinging to blind optimism and prone to creating a “cacophony of unexamined nonsense.” My hope is that Ten Buts should create a huge amount of momentum! Are you still with me? I hope so! Here’s the first But…
But The APIs!
But it won’t work because they shouldn’t have defined an API in the first place!
In The Two But Rule, Wolpert advises to “move fast, but don’t break things.” Nick Schrock (the inventor of GraphQL) says it well in my podcast, Open Source Underdogs, Episode 65:
“Know when to go slow and know when to go fast, especially when you’re talking about so-called “one-way doors” in Jeff Bezos speak, where you’re making decisions that are either extremely costly or impossible to undo… API decisions, especially in open source, last forever. You need to be deliberate on that.”
There are two kinds of endpoints in the current Identity BB “Service APIs” definitions: (1) not sufficiently specified; (2) not sufficiently considered. Simultaneously the Identity BB Service API gives too much detail and not enough!
Insufficiently specified
The Govstack Identity BB copies several API definitions from elsewhere, but does a bad job. Why copy and not just reference? Good question–I don’t know. For example, the authorize endpoint… they make a vague mention that it is the “authorize endpoint of Open ID Connect.” If you’re wondering… that’s not how “OpenID” is spelled–this lack of attention to detail is typical. There is no mention of which version of OpenID Connect was used (probably 1.0 incorporating errata set 2). There are no footnotes that specify where the referenced documents are located. Note that the authorize endpoint is defined in not one, but in several OpenID and OAuth specifications. See this well written section in the OpenID Connect Core Spec–that’s probably the one they were thinking about. But what about RFC 7636 which defines “PKCE”–a critical enhancement to the authorize endpoint for javascript clients to prevent a code interception attack, and documented in RFC 7636? No mention of it anywhere. I could go on and on here… but I’m trying to keep this as short as possible…
Not sufficiently considered
Let’s just look at the “client-management” endpoint, which the Identity BB spec defines as an endpoint “to add a new open ID connect client” – yes, yet another creative spelling of “OpenID Connect”. Spelling aside… I have to ask, why is this endpoint necessary? There was no such requirement from OpenID Connect software vendors in the past ten years–each vendor has their own config control plane. If standardization was needed, it could have been requested by universities or governments, but no one is asking for it. What is defined in OpenID Connect and OAuth is client “registration”–this is a way for a software client to register asymmetric secrets–passwords are bad for both people and software! For more information, you can see the OpenID Connect Discovery spec which was developed around 2015. You should also look at an excellent profileof OpenID Connect Dynamic Client Registration by the UK Open Banking Implementation Entity (“OBIE”). Why didn’t the Identity BB study this profile? Well, they didn’t know about it. I asked… they had never heard of it.
Specifying a bad API can cause governments harm. What harm? There is the cost of migrating off the wrong API. And perhaps most significant are the “opportunity costs” – or the benefits lost by going in the wrong direction. For example, the incremental improvements that never happen, lost engineering team experience, and lost new capabilities in systems that are never developed because of API decision mistakes. As Nick Schrock says–”the API lasts forever.” So how can we fix it?
But it could work if Govstack refrains from designing APIs until a later time, when the need for standardization is clear, and multiple implementations can collaborate in a consensus based process, preferably governed by a professional standards body like OASIS, Kantara or the OpenID Foundation (maybe in the iGov workgroup?).
Bonus But: it could work if Govstack profiled available specs, rather than defining new ones. For example, in the open banking ecosystem, the Financial API (“FAPI”) profile defines acceptable cryptographic algorithm strengths, and which OpenID Flows provide acceptable protection for consumers.
Double Bonus But: It could work if Govstack leveraged some of the contributors who are domain experts to give critical feedback on major decisions, creating a technical advisory committee, to insure the technical integrity of the deliverables, and to contribute to conversations about strategic direction.
But Trust!
But it won’t work because we don’t live in a one IDP world!
Ok, now I’m going to go a little identity geek on you. Quick definition: IDP = “identity provider” – it’s an organizational software service that displays the web login pages, issues digital access tokens and mints digitally signed identity “assertions” that describe the “who, what, where, and when” about the authentication event.
I’ll start with an observation from a recent market engagement webinar published by the great state of Texas, a gov’t of 30M people that is pretty good at building infrastructure. I might like more public transportation, but I can normally drive 80 miles an hour past the Tesla factory when I’m headed up north. And we also have some experience building digital infrastructure–although we’re far from perfect, and probably not even the best in the US. If you watch the above referenced webinar, what’s interesting is that you can see that the Identity BB blueprint is repeating the mistakes of Texas. Initially Texas rolled out a “citizen identity” component as part of the ecommerce website. See this diagram:
But over the years, they realized that this approach fell short. One citizen identity provider would never rule them all. And this one-off identity solution was expensive and slow to innovate. Adding insult to injury, it hindered, not accelerated, digital transformation in the state. Other governments should learn from the real world experiences of states like Texas. They should build what Texas wants now, not what failed them more than ten years ago. The new architecture looks like this:
You need to listen to the webinar to appreciate the nuance. Texas doesn’t need a citizen IDP–remember that boondoggle is going to cost them a fortune to fix. Texas needs a platform to host IDPs for departments and jurisdictions. They need to become Okta–and host IDPs like they host compute, network, and persistence. Just to give you an example, Gluu serves the state of Maine. They have an IDP just for their election workers. Another example in the US–most state police departments have their own IDP, because each department has their own way to vet people, i.e. their own identity management business process for onboarding. Any officer with access to such an IDP in the US can access the FBI National Data Exchange (N-DEx). Identity is not just a citizen challenge.
This brings me to one of my major criticisms of the Identity BB–the Identity BB should start by thinking about how to establish TRUST. The return on investment (“ROI”) for any infrastructure is based on the economic value derived from public and private private sector use. For example, a person gets value when they use their digital identity to obtain government subsidized health services, open a bank account or get hired by a private company. How can we make it easier for all the parties involved to trust each other?
To build trust, we need both “tools and rules”. The tools are the technical standards and open source software. The rules are the legal agreements that protect domains that consume digital identity, protect individuals who need to control their digital identity data, and protect the government agencies that share data about its workforce and citizens. Through federations, trust marks, and other tools in the digital identity space, the Identity BB can provide useful templates that can jump start trust.
If you want to consider the “infrastructure” analogy, the “identity” roads that governments need to build will enable the government departments and the private sector to connect to each other. The more “cars,” the higher the ROI. It’s not the government’s job to drive the trucks, but to set the traffic laws and enforce them.
The impending adoption of decentralized identity credentials makes trust even more challenging. While two-party federated trust ecosystems based on OpenID Connect offer the fastest current ROI–countries should all be studying Singpass, supported by more then 200 Singaporean organizations–verifiable credentials (“VC’s”) solve some interesting new challenges. But VC’s won’t make trust any easier! Without the muscle memory of federated identity trust, countries will find it more difficult to adopt the next generation of digital identity infrastructure. You can’t leap frog here–you need to build a solid foundation.
The whole idea of trust management is unaddressed in the Identity BB blueprint. In fact, just considering the lack of details around client registration betrays this fact. Clients aren’t “added” by admins in the government–i.e. You don’t need to POST to the client-mgt endpoint as the Identity BB imagines. Client registrations should be approved according to a normalized business process defined in the federation for the applicable department (health, justice, defense, elections, etc). There is a fundamental lack of understanding betrayed in the current documents about how modern federated trust ecosystems are constructed.
But it would work if Govstack focused on creating templates for governments to build trust ecosystems that enable business value creation from identity infrastructure.
Bonus But it would work if we establish patterns and guidelines for governments to create identity platforms instead of identity providers.
But The Scope!
But it won’t work because the IT landscape is actually a bit more complex than Govstack envisions
I have to admit, I think the idea of a blueprint for a state digital identity service is optimistic. I would argue that national identity systems are by definition bespoke. Obviously scale varies with each country, as does technical debt. Each government’s current “platform”can also vary quite a bit. I just brain-dumped some of the platform systems that interact or are required to launch a digital identity service in the diagram below, just to give you an idea of what your average state IT director needs to consider.
The scope of the Govstack identity blueprint is a subset of citizen “Authn” (i.e. authentication) and citizen“IDM” (i.e. identity management)–the green boxes in the diagram above. Authentication includes issuing citizens some kind of identifier and an authenticator–normally a password, but it could be anything, e.g. mobile phone or passkey. Identity Management includes providing a way for citizens to register and recover their identity.
Right out of the box I wonder why we are focusing on citizens and not government workforce identity. If the government workforce is going to build and operate this citizen service, how can they even help citizens if we don’t know who they are, and what government agency they work for? This goes back to the idea that governments don’t need a citizen identity solution, they need an identity silo that provides identity for many segments: citizen, workforce, healthcare, public safety, defense, etc.
The current Govstack Identity BB is too “in the weeds”. This may sound obvious, but Govstack should help governments govern IT, not tell them how to assemble the various components. If you listen to the Texas Digital Identity Solution webinar, it’s clear that they are not going to operate this infrastructure–the operation of the service is a big part of what they are bidding out. I suggest the Govstack Identity BB spec follows Texas’ lead and focuses on governing IT. Ultimately, governments will need to make a buy-versus-build decision with regard to design, build, and operate. They will need to engage with the market–let commercial entities propose different technical solutions and operational contracts. The total budget for a digital identity service needs to consider the totality of licensing, cloud infrastructure, staffing, legal, marketing, QA, and many other aspects of the service. Ultimately the license is a small part of the total cost of ownership, and whether to build up from an open source base or license a commercial product is a business decision. Open source is only free if you don’t value your time. It may save money to license software if it’s more productive or efficient. Thus, Govstack should not be overly prescriptive with regard to the specifics of the solution. And let’s not kid ourselves, any “lab” we create is purely academic, because there will be so many differences with a government’s real world IT landscape. Personally, I think a lab is a waste of money because there is no technical risk here–digital identity is a mature technology with well-known best practices, documented particularly well by IDPro.
Also, there is no “right” answer to the buy-versus-build question. Govstack should not advocate for building. In Texas they want to buy–they don’t have the internal resources to design or operate this technically complex, mission critical infrastructure. In Ethiopia, maybe they want to build because they see positive externalities to catalyze the tech industry in Addis Ababa.
I know just diving in head first, and enrolling citizens may sound like a great idea–people are registering… progress! But that doesn’t mean we’re delivering value. It’s like having a driver’s license in a country with no roads! Let’s lay the groundwork for trust in our digital society and take our time making the big decisions that impact end-user citizen identity–like how we identity proof, and which credentials we enroll. Make content available before we make a huge push for citizen adoption.
But we can fix the scope if we limit ourselves initially to the governance of the service, rather than nuts and bolts of a specific implementation!
Bonus But we can focus on building trust between the public and private sector organizations that will create and consume identity and consider more carefully the recommendations regarding citizen identity!
But the Team!
But it won’t work because the Identity BB team doesn’t have the right people on the bus.
Jim Collins in his seminal book Good to Great, says the first challenge is “who”– GET THE RIGHT PEOPLE ON THE BUS! The right people doesn’t mean the most famous people. I have spoken and reached out to almost everyone listed as an author or contributor on the Identity BB. If you are one of those people, and you want to talk, contact me on Linkedin! The pattern I see is that there were some super smart people who just didn’t have enough time to participate. There were some people who were clearly unqualified to contribute–but no one either knew better or felt safe enough to voice their concerns about their contributions. This has led to some pretty shoddy work. Nor does there seem like there is any desire to undertake a review or consider feedback–and I offered plenty of the latter myself. In fact, Jaume Dubois, one of the leading authors of the spec, said he had no regrets about the work, and he is advising national governments to adopt it. I don’t doubt the good intentions, but the potential results are uncertain.
Who is on the team? The authors and contributors are listed in the spec. As mentioned above, the contributors are probably either minor participants or altruistic technologists who want to lend a helping hand. So let’s consider the authors. The Identity BB spec was written by three organizations: MOSIP, Technoforte, and ID30. This was not originally apparent. The original authors page had a mistake–the OpenID Foundation was listed as another organization that contributed, but it turns out that the person did not contribute any text, only attended “one or two meetings”, and asked to have their name removed. This is consistent with the “shoddy work” theme… you should ask people before you list them as an author, and find out what organization they are representing.
After doing some personal investigation, and speaking with the real authors, what I’ve noticed is that the current authors are either uninvolved in the conversation, or have material gaps in their knowledge, or both. Leaders in the group had never heard of well known identity standards, like SCIM or XACML. Some had no knowledge of popular identity federations, like eduGAIN in the higher education space, which has thousands of participants, or the UK Open Banking federation. When I asked about the plan to establish trust between identity providers (i.e. between domains), there was no answer. This kind of industry knowledge is essential to advise nations how to build their identity infrastructure. For example, when I asked why the group defined an enrollment endpoint, versus adopting SCIM, one author asked “What is SCIM?” And after I explained it, instead of saying something like “oh, we should look into that”… the SCIM standard was dismissed as “commercial.” It’s clear the current team needs different leadership and to be held technically accountable.
There are many excellent federation experts out there. I know at least a dozen who would be amazing. We need to get them in here or what we’re going to get is a “a cacophony of nonsense” with lots of spelling mistakes.
But we can get the right people on the bus if we find the people with the right skills, experience, attitudes, habits and values and pay them the rate they ask–the right design has a huge ROI!
Bonus But: we can minimize the team size by joining existing standards efforts where possible.
But we want a competitive vendor landscape, and they wrote the spec in the way that only one product can satisfy their requirements
A competitive ecosystem of vendors–who offer both commercial and open source software solutions–is desirable. If the Govstack Identity BB writes a spec in a way that only one vendor’s product can satisfy it, then it has failed.
The Govstack Identity spec seems to double as a product design document for MOSIP. The client management endpoint–the one I criticized above– makes perfect sense if you think of the Identity BB spec as a MOSIP product design document. And coincidentally, all the authors of the Identity BB are closely associated with the project.
MOSIP is funded by donations from the Gates Foundation and EK Step (a foundation funded by Nandan Nilekani, the co-founder of Infosys.) They are doing some interesting work in citizen identity management, although one has to wonder if a donations based funding model will result in sufficient long term maintenance of the software and innovation. Ultimately, they need a monetization strategy to fund the boring stuff (updates), and the fun stuff (new research and development). Deploying MOSIP into production given the uncertainties of this funding model is not without its risks. Will Gates Foundation and EK Step continue to fund it? If not, how will MOSIP monetize? Ultimately, this “open source” effort is starting to look more and more like a business. When I heard Gabi Adotevi speak at the DPGAMeeting in November about MOSIP, he sounded awfully concerned about new funding commitments from donors. In my opinion, he should have been more concerned about revenues, and less concerned about raising more capital. As Bill Gates knows, in the software business, hostages are better than customers. It’s free now, but are current MOSIP customers future MOSIP hostages, because no other solution supports this “standard”? Only time will tell!
The DPGA, a UN initiative, and Govstackshould not be the marketing arm of MOSIP. And although we all want to see synergies between the altruistic investments of the various donors, in this case the stakes are simply too high to put your fingers on the scales to favor one very risky solution. MOSIP should have to compete in the marketplace of ideas and against economics, just like all the other commercial and open source solutions. If the Govstack Identity BB spec stands as is, it has failed completely to coalesce an ecosystem of vendors. In layman’s terms, no vendor or open source projects wants to implement a deficient API that is not really a standard.
But we can fix the Identity BB spec to make sure that it only uses open standards that have multiple competitors who can satisfy the requirements!
Wow, if you made it to the end of this article, congratulations! I know it’s a lot. Frankly, I have more but I’ve run out of time to share the rest of my thoughts! Please reach out to me on Linkedin if you are DPGA or Govstack leadership–this article is for you. It’s not too late to maintain momentum and help achieve the goals of SDG 9–to build resilient infrastructure, promote sustainable industrialization and foster innovation. But wishful thinking is not going to enable us help countries build digital public infrastructure. But we can act now, address the problems, and make sure we don’t make things worse!
