DICE 2024 Retrospective
After decades with hundreds of conferences, DICE, the Digital Identity unConference Europe, has quickly become one of my favourites. Firstly, because of the format, which I thoroughly enjoy and find incredibly useful at fostering meaningful conversations. Also, it is not a vendor sales driven event. Even competitors meet here and discuss possible solutions to current challenges openly. And lastly, because of the people. The mix of backgrounds, ages, experiences really makes for a diverse set of perspectives.
Competency
What’s more, the Swiss government is engaging at this conference in ways that are really unusual. Starting with Swiss Federal Council Beat Jans, whose opening notes were competent to a level of detail that surpassed several of the regular participants, to the 13 Swiss governmental employees — most of them working on the Swiss eID — who held several sessions, and found themselves constructively engaging with the community on a wide variety of issues.
This dialog is also something that we’re experiencing on an ongoing basis within DIDAS, the Swiss Digital Identity Association, the organizers of this conference. But when Beat Jans went off-script in the following discussion, spoke about the critical nature of identity and drew connections of topics discussed during DICE to the political challenges around asylum seekers in Europe, it was truly impressive.
It was Timothy Ruff who during one of the sessions around KERI made an impassionate plea that
“Identity is a matter of life and death!”
based on the understanding that problems in the design of the identity system will result in people losing their reputation, livelihood and health — causing deaths from suicide, murder and lack of proper healthcare.
The Federal Department of Justice and Police is responsible also for asylum seekers in Switzerland. Federal Council Jans is leading the department and gave practical perspectives for how accurate that assessment is. His answers reflected how seriously he takes these responsibilities and how mindful he is of the consequences of bad technological and political decisions.
Which makes it all the more unfortunate that some communities are still under-represented at DICE, especially people with security background.
Security
Considering the significance of identity, session announcements like “I know did:web is not secure, but I have built some tooling that makes it really easy to use” make me wonder whether it is perhaps a good idea many companies still struggle with adoption.
That is not to say did:web does not have a use case. We have for instance very successfully used it at Vereign in rapid prototyping early stage Proof of Concept developments.
And there will be use cases where did:web may prove sufficient. Basically, if classic Web 2.0 security with all its known attack vectors is deemed “good enough”, lack of privacy is not a concern, and tamper evidence is not required, did:web is an inexpensive method to put a thin “SSI Interaction Layer” on the classic Web.
Use cases where this can be appropriate will mostly involve organisations in largely centralized structures. But as soon as natural people enter the picture, did:web is probably not such a great idea any more since it brings with it all the concerns that plague the current Web. It may still be ok for governmental use cases, but users should be aware that the system won’t really be “privacy by design.”
Because these issues are meanwhile widely known and documented, some people in the community now work on better versions of did:web. All the convenience, none of the disadvantages, or so it seems. Based on the sessions at DICE, the currently most popular such proposal is did:tdw, or “Trust DID Web.”
The problem with did:tdw
The means by which did:tdw aims to address the issues of did:web make it more complex, but ultimately less secure than did:web itself. And it’s the additions that were supposed to make it more secure that make it less so. Which in security circles will surprise no-one. It has happened to people thousands of times.
So what happened? Inspired by key pre-rotation in KERI as a means to allow recovering from compromise, and reacting to fundamental changes such as quantum cryptography, among other things, did:tdw also specifies a mechanism for key pre-rotation.
Borrowing from the KERI Key Event Log (KEL), it provides a JSON DID log, allowing to backtrace the rotations over time for the identifier in order to arrive at the root identifier. Which seems great.
But KERI also has a mechanism by which it can ensure that older versions of identifiers, using keys that have already been rotated, are no longer considered valid and trusted. This mechanism is provided by the witnesses and watchers in KERI.
Trust DID Web has no such mechanism. Compromised keys remain valid, allowing an attacker to create a fully credible history of key rotation, arriving at their own current key, and validating back to the original root identifier they have taken over.
So in the event of key takeover, the only thing stopping an attacker from impersonating an entity are the authoritative roots of trust based on DNS and TLS, as well as the security of the web server itself.
In fact, DID TDW also has a Move mechanism which preserves the same identifier, but authoritatively moves it to another domain. So taking over DNS or the web server isn’t required. Because even without resorting to a IDN Homograph Attack there are plenty of “credible enough” domains available to an attacker.
For the benefit of people not familiar with the IDN Homograph Attack: Large parts of the security model of Web 2.0 — and consequently did:web and did:tdw — depend on humans being alerted by the difference between did:tdw:vеrеign.com and did:tdw:vereign.com when not paying attention.
And yes, did:tdw has a section about International Domain Names. But whenever security people see something like this in a specification, experience tells them someone is bound to get this wrong, someone is bound to get burned, and the user is going to get damage and blame as is commonplace in our industry today:
Most of these vulnerabilities result from combining identity and identifier together in a DID. Which is how the web works. A URL is an explicit identity statement. Users are meant to assume the domain microsoft.com is authoritative for the Microsoft company identity.
So while the desire to create easier migration paths and integration scenarios for Web2 services is understandable, the result is an import of explicit identity assumption into SSI that is problematic.
KERI — and some other methods — avoid this by using Autonomous Identifiers (AIDs) instead. Which unlike DNS names also do not have such a high risk of being considered Personally Identifiable Information (PII) under data protection law.
Adding key pre-rotation in did:tdw was meant to increase security, but has ultimately achieved the opposite. Using ephemeral identifiers or the much simpler did:web are the better choice for security.
And if using did:tdw cannot be helped or avoided, the next key commitment is better left empty. Key pre-rotation in did:tdw should never be used, and a fresh identifier should be generated instead.
/whois service endpoint
That is not to say did:tdw does not have some good ideas to contribute to the domain. Personally I think the /whois endpoint is an intriguing idea. Organizations might start to routinely provide their verifiable presentation of the GLEIF vLEI at that endpoint, allowing for an easier automatic discovery and verification of organizational identities.
And I really hope that the above is received in the way it was meant: As honest and constructive criticism, and perhaps a reminder of why early peer review at conceptual stage should include people with security background. Security is hard. And very easy to get wrong. All of us have fallen into traps laid by our own mind before.
So I really hope that more people from the security community will join that particular dialog and help us avoid making mistakes in the identity infrastructure of the future that may otherwise prove fatal — and not only in the metaphorical sense.
eIDAS 2.0
All of this is relevant context especially because the European Union has been working on the electronic identification and trust services for electronic transactions in the internal market, also known as eIDAS. In essence, eIDAS 1.0 has been an adoption failure due to the involvement of the centralized administrative trust industry, i.e. Certification Authorities, which ended up choking the market before it even existed.
eIDAS 2.0 was supposed to correct that adoption failure, among other things by enabling Self Sovereign Identity and less centralized approaches. After years of very active participation by the centralized administrative trust industry, they are now again deeply interwoven with the regulation.
This is reflected in the technical choices, which are mostly based on Web 2.0, including usage of did:web, which was never intended by its authors for this kind of use case, and which does not technically protect privacy and security as much as would be possible.
Understandably, the European Digital Identity Architecture and Reference Framework was a big topic at DICE 2024, with several sessions touching upon the pilots and the implementation of wallets.
One of the most important take-aways was the complexity that had meanwhile fully sunk in to wallet implementors, and a certain level of frustration that even made its way into the final conclusion round in the form of comments “whether it would be possible to implement this, at all.”
Complexity has always been used as a barrier to market entry for competition by the centralized administrative trust industry. So it is perhaps not surprising it’s also being employed against competition from the SSI space. And perhaps the end result will be that European Citizens will need to wait for eIDAS 3.0 for a truly privacy by design, decentralized, affordable and usable eID without gatekeepers that will see some large scale adoption. Time will tell.
Which then could perhaps draw inspiration from Switzerland where the work on the eID is happening with a somewhat different focus and in process that is more open, participatory and transparent than any other I’ve seen in the past. The declared goal is to end up with a system that is as secure as we can make it, and offers protection of privacy that is technical, and not just administrative.
KERI
To my knowledge, the currently best proposal to achieve that is the Key Event Receipt Infrastructure (KERI) by Sam Smith, who was participating at DICE this year, and whose sessions were exceptional. Personally I’ve thoroughly enjoyed the security architecture deep dive, where Sam took us on a tour of how his own understanding evolved.
The path from administrative root of trust, over ledgers as a global, technical root of trust, to a system like KERI, which uses what might be described as a “locally consistent, tamper evident” approach, which brings benefits in terms of scalability (no need to establish a global consensus all the time) and also practical benefits like garbage collection (no need for test ledgers for fears of cluttering up expensive global storage).
Following Sams route through this evolution reminded me of my own. The next step along that route will be the Trust Spanning Protocol which is currently being worked on at the Trust over IP Foundation.
It’s been great to see the interest in KERI throughout DICE. Sessions were many, lively and packed. Yet from talking to people at the conference it seems there is still a gap that keeps us as a community to rally behind KERI. So what is that gap?
As of today, KERI is already in production issuing vLEI credentials at GLEIF, based on the Python reference implementation. Which is a great achievement.
But there is still very little information available about the current network of Witnesses and Watchers, and thus no way to make an informed decision about the actual security of the current system.
Also, in conversations with third parties, I’ve come across a concern of using Python at protocol level in a security critical, network connected backend service.
Partially due to concerns of a lack of competency within the organisation to adequately understand the entire application and maintain it, if necessary. And partially due to concerns about maintaining and supporting Python in production which have been outlined by Jos Visser last year.
Many of the people I’ve spoken to seem to wait for a complete KERI agent that can be wrapped and integrated into the frontend or backend interchangeably, using the same technology stack and implementation.
Which means ideally it ought to be in a language like Rust which plays well both with Javascript / Typescript, the dominant choice on the client side, and Golang, Java or other technology in the backend.
In order to allow KERI to develop rapidly in both specification and implementation at the same time, Python is of course a great choice.
I believe it would be in the interest of our community to make sure we allow Sam Smith to continue focusing on the hard conceptual issues, and delivering them as both specification and reference implementation going forward.
But to increase adoption and build a community, we should also provide an implementation in Rust (or language with similar properties) for a full agent with tooling and libraries that can be deployed on any device, with any number of resource constraints, and inside any technology family. Ideally it would also provide command line tooling to facilitate easy scripting and experimentation.
All the cryptographic operations of the Python reference implementation are already in low-level libraries, many of which are written in C and some in Rust.
In addition, the Human Colossus Foundation has started work on a Rust implementation, which has seen substantial development over the past years. On the other hand, being published under the EUPL may have inhibited adoption somewhat, and it seems that it already diverged to some degree from the reference implementation.
Another valiant attempt at a Rust implementation has been KERIOX, but that hasn’t seen a lot of contribution in the past two years.
If we want to see adoption of KERI to speed up and eventually reach critical mass, we should focus on avoiding fragmentation of effort. Perhaps using a common vehicle to align resources so we can reach a state where we can point toward a full set of complete implementations with good documentation and examples, as well as reference nodes and a bit of marketing which would then be crucial to promote adoption in the technical community.
Getting this done is not rocket science. But it must start somewhere and can then improve over time. I’d love to hear from people who’d like to collaborate toward this end. Because helping ourselves while working together is what we do in the software freedom community.
And if you would like to learn more about KERI in the meantime, the KERI Suite Search Engine (KERISSE) has a lot of great resource to get you started.
Principles of Governance
On closing, I’d like to go back to Timothy Ruff again, whose session on models for government was intriguing. Basically, he proposes to break down the values for governments into functions of Utility, Security and Autonomy.
His postulate is that virtually all governments have an interest in functioning well, and being secure. But when it comes to the level of Autonomy, and issues such as transparency of government towards its citizens, or privacy of citizens vis a vis the government, there is a sliding scale of expectations, which is largely cultural in nature.
At face value, that seems to hold true. Although I would argue that there are also governments that have a similar sliding scale for Utility and Security. Because lack of Utility can keep people so occupied with daily chores that they do not think about overthrowing the government. And lack of Security can increase the desire for a strong leader. Likewise, lack of both can even keep different factions in the government at bay because they are too busy to complain about one another while struggling with somehow getting their job done.
It might be an interesting exercise to look at different countries around the world to see where they fall on these sliding scales from 1 (lowest) to 10 (highest). For instance Switzerland is aiming for a (10, 10, 10) with its eID System. But finds the need for compatibility with the EU; which is closer to (8, 8, 6), now putting challenges ahead of Switzerland in its practical ability to get close to that goal.
Where would you place your own country or region in this scale?
DICE 2025
In any case: DICE 2024 was an amazing confererence, to the extent that people were asking to perhaps hold it twice a year during the closing session. While I am sure the organizers briefly had a slight heart attack at the thought, no better compliment can or need be given.
Make sure to keep an eye out for the next edition and register early. This year has been at maximum capacity, and there were no last minute tickets available any more.
Addendum
Have you been able to detect the difference between those two DIDs in the section about the IDN Homograph Attack?
If not, this article successfully conducted a so-called “Punycode Attack” on you.
If you look very closely, you will notice the “e” is slightly bolder in the font used on Medium. In some other fonts, the lower bound of the upper part of the e is slightly slanted. And in some fonts, they look entirely the same.
You can make it a bit more obvious by using a tool like Punycoder.com. If you cut & paste only the domain parts of both DIDs, you should see something like this:
So while they may look the same, they are not the same.
Which is a fundamental weakness in all DNS based methods with human readable identifiers. Which is what the Web relies on for its security.
By using Web based methods, Self-Sovereign Identity is opening itself to a whole host of attack vectors which are very hard to defend against, and with which attackers have decades of sophisticated experience.
Which is the point I was trying to demonstrate, above. So I hope you’ll forgive me the Punycode attack — it was purely for educational purposes.
