Integrating FortID into the Foosball App

Introduction

Here at FortID HQ, we bought a foosball table mostly because it seemed like a good way to take a short break between meetings, debugging sessions, and architecture discussions. It was not supposed to become infrastructure. It was just a table, a ball, and a few people pretending they were not taking it too seriously.

That lasted for about as long as you would expect. Once the games started getting competitive, we built a simple in-house app for logging match results. The first version did not try to be clever. It stored who played, who won, and who lost, which was already better than relying on memory, trust, or heated post-match debates about who “definitely won last Tuesday”.

The next small upgrade was Slack integration for live match monitoring. Every match start, goal, and match end posts a message to a channel, so the rest of the office can follow the action without standing next to the table. Office foosball, apparently, needed a broadcast layer.

After that, plain wins and losses stopped being enough, so we added a rating system similar to the Elo rating system originally developed for chess. The app could now track not only match history, but also the slow rise and sudden collapse of everyone’s position on the office leaderboard. Naturally, once rankings were involved, the whole thing became much more important than it had any right to be.

The next step was removing manual score entry. We mounted a tablet near the table and turned it into the match control screen. Players use it to start a match, and while the match is in progress it shows the live scoreboard. Under the table, a Raspberry Pi 5 listens for goal events and reports them back to the app.

The whole software stack is written in Rust, except for the web UI, which is plain jQuery for simplicity. Live goal data is sent from the Raspberry Pi to the tablet UI over WebSockets, so the scoreboard can update as soon as the sensors detect a goal.

The goal detection setup is fairly practical. Break beam sensors, which detect when something (in this case the ball) interrupts a light beam, are mounted on the goals, wired through a protoboard, and connected to the Raspberry Pi. A buzzer provides sound feedback when the match starts, when a goal is scored, and when the match ends. In other words, our foosball table became a very serious IoT device made from a Raspberry Pi, sensors, wires, a protoboard, and just enough office competitiveness to justify it.

Before starting a match, players select their names in the Foosball App UI and click Start Match so the system knows which players should receive wins, losses, and ELO changes. This worked well enough for a while, but it had one obvious weakness: the application trusted whoever was using the screen.

There was no mechanism for verifying that the selected players were actually the players standing at the table. A mistake could happen while clicking player names, especially when people are in a hurry to start the next match. Even worse, someone could deliberately register another player and attach a loss to their record. We would like to say this would never happen in a friendly office environment, but once rankings are involved, assumptions become dangerous.

From a technical perspective, the problem was simple: the app knew which names were selected, but it did not know which people were present.

That made the foosball app a perfect small-scale identity challenge. It was low-risk, easy to understand, and just absurd enough to be fun.

Enter FortID

We figured our foosball app would be an ideal environment for some dogfooding.

The goal was to replace the old trust-based match registration system with a FortID-enabled flow where each player proves their identity using a verifiable credential from their EUDI wallet.

Instead of simply selecting names from a list, players would now go through an OpenID4VP credential presentation flow before being assigned to a match. The app would only start the game once all required players had successfully presented their credentials.

This gave us a practical way to test our technology in a real internal application, while also solving a very real and definitely business-critical problem: protecting the integrity of the office foosball ladder.

Issuing Foosball Credentials

Before players could use their EUDI wallets to register for matches, they first needed to receive a credential.

For this, we created a separate admin screen that allowed us to generate an OpenID4VCI issuance QR code for each player. Each QR code represented an issuance session for that specific player’s foosball credential.

The process looked like this:

1. An admin selected a player in the admin interface.
2. The system generated an OpenID4VCI issuance QR code.
3. The QR code was printed on paper.
4. The printed code was delivered to the player in an envelope.
5. The player scanned the QR code with their EUDI wallet.
6. The credential was issued into the player’s wallet.

We intentionally kept the issuance process simple and physical. Since this was an internal demo, printing the QR codes and handing them out in envelopes was a nice way to make the credential issuance feel tangible. It also avoided turning a fun internal experiment into a large onboarding project.

Once scanned, the player’s EUDI wallet contained a foosball credential that could later be used to prove their identity to the Foosball App.

This credential does not need to contain anything overly complicated. For our use case, the important part is that the app can reliably connect a successful presentation to a known player in the system. The player proves possession of their credential, the app verifies the presentation, and the match registration can continue with much stronger assurance than a simple dropdown selection.

Registering for a Match

After players have their credentials, they can use their EUDI wallets to register for a match through the new OpenID4VP-enabled UI.

Unlike the old start match screen, the OpenID4VP powered one initiates credential presentation sessions for each player instead of blindly trusting whoever is operating the wall tablet.

After clicking Start Registration, each player receives a QR code for initiating a credential presentation session. The player scans the QR code with their EUDI wallet and presents their foosball credential. The Foosball App then verifies the response and marks that player as registered. The player name is also automatically retrieved from the credential presentation, no need to manually select player names.

For a standard two-versus-two match, this means four successful presentation sessions are required before the match can begin.

Once all four players have completed the flow, the app has much stronger confidence that the people registered for the match are the people actually standing at the table. Only then does it allow the match to start.

This approach removes the most obvious sources of error from the previous flow. No more accidental player selection. No more registering someone else “as a joke”. No more suspicious ELO movements while someone is away from the office.

Foosball justice, backed by verifiable credentials.

Now for the Serious Part

Obviously, office foosball is not the highest-stakes identity use case in the world. Nobody is crossing a border, signing a mortgage, or accessing sensitive medical records here.

But that is exactly what makes it a useful demo.

The flow is easy to understand:

• A user has a credential in their wallet.
• An application asks the user to present that credential.
• The application verifies the presentation.
• Access to a specific action is granted only after successful verification.

In our case, the action is starting a foosball match. In other use cases, it could be accessing a service, proving membership, confirming eligibility, or authorizing a workflow.

The same building blocks apply.

By integrating FortID into a familiar internal app, we were able to test the developer experience, wallet interaction, issuance flow, presentation flow, and verification logic in a setting that people actually wanted to use. It gave us a small but realistic playground for validating how the technology behaves outside of a controlled demo environment.

And because the app is used by our own team, we get immediate feedback when something feels awkward, slow, unclear, or unnecessarily complicated. That kind of feedback is hard to get from diagrams alone.

Lessons Learned

One of the main takeaways was that credential-based flows do not have to feel heavy or intimidating. When the interaction is clear and the purpose is obvious, scanning a QR code with a wallet can feel like a natural part of the process.

The foosball use case also helped us think about user experience in a very practical way. A match registration flow needs to be fast. Nobody wants to spend several minutes preparing to play a five-minute game. That pushed us to keep the UI simple, make each player’s registration status visible, and ensure that the overall process remained understandable even for someone seeing it for the first time.

It also reminded us that trust problems exist in many shapes and sizes. Some are serious and regulated. Others involve a small plastic ball and a surprisingly competitive engineering team. The underlying question is often the same:

How does a system know that the user is who they claim to be?

With FortID and EUDI-compatible flows, we can answer that question using standards-based credential issuance and presentation instead of relying on manual selection, passwords, or blind trust.

Conclusion

Integrating FortID into our Foosball App gave us a fun and practical way to use our own technology in a real internal setting. We replaced a simple name selection flow with an OpenID4VP-based credential presentation process and used OpenID4VCI to issue foosball credentials into players’ EUDI wallets.

The result is a match registration system that is more trustworthy, less prone to mistakes, and significantly harder to abuse for ELO-related mischief.

It is still just foosball, of course.

But for us, it was a useful example of how verifiable credentials can be applied to everyday workflows. Start small, make the flow understandable, test it with real users, and learn from the experience.

And in our case, make sure every goal, win, loss, and ranking change is assigned to the right person.

Have questions about the implementation, the OpenID4VCI issuance flow, the OpenID4VP presentation flow, or how we wired everything into the Foosball App? Reach out — we are always happy to talk identity, credentials, and occasionally foosball.