suuch a hard problem, esp for government that has to include 'everyone' and all the weird edgecases that forces on you.
Couple that with proof of identity being one of the few things that might have been issued 40, 50.. 60+ years ago (birth certificates) and never updated (unlike passports..) and when issued had no concept or sympathy that it might be used for digital verification in the future.
Without redefining the problem to avoid issues like birth certificates, i'm not sure this is solvable in the way stakeholders expect it to be. Stakeholders (like citizens paying for it) expect to be able to point technology at the problem and have it solved, 'its just an app right?' or 'lets use biometrics!' but so many other things have to adapt to make something like this successful.
Estonia had an interesting approach where they just issued everyone smartcards/certificates and used that as proof, this bypasses the 'birth certificate' problem but is expensive (Estonia has smallish population, newish government so ok) but such an approach itself has a root of trust problem.. who do I issue the smartcards to? It isn't directly transferable to other countries/governments.
You work around the root of trust problem by creating exceptions and alternate paths to verification, maybe do it in-person for people with disabilities etc. But then how long does that take to roll-out? How easily abused is such a system? How many of the identity moment can I use it for? Is in-person verification trusted less?
It is very easy for the resulting system to be quite brittle too and not reflect real use-cases, real world identity moments are very diverse and often have more flex than you'd think and it is very difficult to carve out the right chunk of the identity problem to solve and which to leave behind and still create something that improves the ecosystem.
Oh, birth certificates. If you need to support birth certificates in your system -- you need to support each and every format of birth certificate issued in the last 100 years in every part of the world, not just ones issued in $countryname.
It's like "falsehood programmers believe about Names" combined with one about dates and all others too. Because sometimes including name of lunar month is more important than assigning a number to the document.
Couple that with proof of identity being one of the few things that might have been issued 40, 50.. 60+ years ago (birth certificates) and never updated (unlike passports..) and when issued had no concept or sympathy that it might be used for digital verification in the future.
Without redefining the problem to avoid issues like birth certificates, i'm not sure this is solvable in the way stakeholders expect it to be. Stakeholders (like citizens paying for it) expect to be able to point technology at the problem and have it solved, 'its just an app right?' or 'lets use biometrics!' but so many other things have to adapt to make something like this successful.
Estonia had an interesting approach where they just issued everyone smartcards/certificates and used that as proof, this bypasses the 'birth certificate' problem but is expensive (Estonia has smallish population, newish government so ok) but such an approach itself has a root of trust problem.. who do I issue the smartcards to? It isn't directly transferable to other countries/governments.
You work around the root of trust problem by creating exceptions and alternate paths to verification, maybe do it in-person for people with disabilities etc. But then how long does that take to roll-out? How easily abused is such a system? How many of the identity moment can I use it for? Is in-person verification trusted less?
It is very easy for the resulting system to be quite brittle too and not reflect real use-cases, real world identity moments are very diverse and often have more flex than you'd think and it is very difficult to carve out the right chunk of the identity problem to solve and which to leave behind and still create something that improves the ecosystem.
learnt through pain, built digitalid.com