What a nice surprise today: our F-Ticks system today reports that the one billionth eduroam authentication has just taken place. Having been with eduroam R&D since it’s early days, I can say that we’ve come a long way. I still recall the days when a conference with a few hundred participants caused anxiety and clearly visible spikes in the international authentication stats, because the overall user base was only a few thousand people. Today, any given conference, no matter how big, isn’t even noticeable. Congratulations to all those people around the planet that continue to make eduroam such a success!
The journey from a “Wow! It actually works!” to a service spanning over 70 countries, ten thousands of hotspots and millions of users which expect an excellent quality of service for a technology which is essential for their everyday lives taught me many lessons. Like that things done manually don’t scale: the mere existence of the F-Ticks system (originally thought to be the “federated authentication ticker”) is owed to the fact that manually searching through log files for stats just doesn’t work very well at scale. Another example is the eduroam Configuration Assistant Tool (CAT) (no idea what I’m talking about? – quit living under a rock and look here: https://cat.eduroam.org ): while configuring eduroam was okay to be done manually by “the eduroam guy” in the office for his five IT colleagues, it’s much less okay if that guy now has a queue of thousands of students in front of him.
Our journey certainly isn’t over: we still have many areas where we can improve. Like in fault reporting and fault-finding: telling a user with problems to phone home – only to possibly be told that he needs to walk up to a local help desk at a roaming place instead – isn’t exactly the greatest customer service. We are currently working on improving this, with an online expert system which tries its best to find out where and what the problem exactly is, putting you in touch with the people who can actually help you, as automated and real-time as possible. Or like compliance checks: we don’t really know much about the end user’s experience at the hotspot, and his local problems there which do not show up in any roaming log – does he get an IP address from DHCP, does the hotspot open all required ports so that users can get to do their work, does the hotspot maybe have woefully outdated Wi-Fi setups (WPA/TKIP-only, burn you must!)? We are working on getting closer to the user with our diagnostics. Ideally, when a user reports a problem at a given hotspot, I’d like to be able to tell him: we are with you – logging in in real-time at exactly the spot you are at, finding out
about possible problems in real-time.
Last but not least, we should work on expanding our footprint further: there are certainly many small institutions out there for whom running an own RADIUS server in order to become an eduroam Identity or Service Provider is a too daunting task. Activating those would be an extra kick to our installed base and would yield even more happy users than we have right now. And with that, I’m sure there will be continuous growth for eduroam towards even more mind-blowing numbers than the billion we saw today. Like what people say about money: the first billion is always the hardest!
Stefan Winter
