On contributing code, for the first time, to the EU's official reference wallet ecosystem.

DCQL and Null Matching

For readers who don't work in digital identity, a very short primer. There's a query language that verifier services use to ask a wallet "show me this kind of credential, matching these conditions." It's called DCQL (Digital Credentials Query Language), and it's defined in OpenID for Verifiable Presentations.

One small feature of DCQL is null matching. When you query an array-typed field inside a credential — say, nationalities for someone who holds multiple citizenships — you can put null in the path to mean "match any element of this array":

{ 
    "path": ["nationalities", null], 
    "values": ["LU", "FR", "DE"] 
}

Does the user's nationalities contain any of LU, FR, or DE?

DCQL null matching applies to JSON-based credentials (such as SD-JWT VC). It does not apply to mdoc-based credentials, whose query structure is different and has no null wildcard concept. Everything in this post is about the JSON-based side.

The Problem: the Official EUDI Reference Wallet Didn't Support Null Matching

The iOS stack of the EUDI Wallet reference implementation — the official reference codebase maintained by the European Commission — did not support DCQL null matching. The same query that worked correctly against the Android stack silently failed on iOS.

So I fixed it and pushed the change upstream. The fix spanned two libraries, and both PRs were merged within days:

• PR 179 — eudi-lib-ios-openid4vp-swift

• PR 313 — eudi-lib-ios-wallet-kit

More than the technical details, what I want to share is how this contribution felt.

What It Means to Contribute to an Official Reference Implementation

The EUDI Wallet reference implementation is the official codebase that every EU Member State builds on when shipping its own national wallet. And Europe is running it as open source. I genuinely love this.

It could have been done differently. The European Commission could have awarded a single closed-source vendor contract, or left each Member State to build from scratch. Instead, they chose to publish on GitHub, accept external contributions, and run a real review process. That means an outside engineer — someone who is neither part of any EU institution nor an officially selected vendor — can find a bug, open a pull request, and actually see the fix merged into a codebase that downstream national pilots will pick up.

That is not a trivial choice. Running public infrastructure as open source means absorbing the cost of external review, security scrutiny, and governance coordination. Choosing to do that anyway — and reviewing and merging external contributors' PRs within days — is, I think, one of the reasons the EU digital identity ecosystem is moving at the pace and quality it is today.

A sincere thank you to the EUDI maintainers for the fast review cycle. The feeling of "my work is welcome here" is what makes the next contribution happen. I felt that again this time, and it matters.

What's Next

EUDI isn't the only DCQL implementation missing null matching. Looking around the ecosystem, there seem to be quite a few places where this is still not supported. My plan is to slowly go through them and contribute fixes where I can. I'd like the digital identity ecosystem to reach a state where querying array fields of JSON-based credentials is something that just works — that's one of my small personal goals right now.

And most of all — Europe, thank you for running your public infrastructure in the open. 🇪🇺

Links

• PR 179 — eudi-lib-ios-openid4vp-swift

• PR 313 — eudi-lib-ios-wallet-kit

• OpenID for Verifiable Presentations (DCQL)

• EUDI Wallet — European Commission

This week, in Singapore, we had that demo. And it worked.

The Project, One Year On

The two projects I've been contributing to as part of Hopae — Verifying Digital Identity in the Distribution Process and Contactless Travel — are part of the official IATA Proof of Concept Cycle 2. These are not side experiments. They're
pilots that airlines like Air Canada, British Airways, Qatar Airways, Japan Airlines, and Air New Zealand have bought into, alongside airports (Hong Kong International, Bangalore International) and technology partners ranging from Google Wallet and Amadeus to SITA, NEC, Tip.com and Infosys.

For the past months, the work has been quiet: specs, code, interoperability tests, long threads about edge cases in OpenID4VP and ISO 23220(Photo ID). You don't really feel the weight of what you're building until you're in a room with the airlines who asked for it.

At WDS this week, I felt it.

The Presentation

Seeing the work presented on stage — in front of the people who will carry this forward into production — was one of the most meaningful moments of my year. The presentation was excellent. Credit belongs to the entire consortium: the airlines who pushed for it, the tech partners who built it, and the standards people who made sure the pieces fit together.

But what struck me most wasn't the polish. It was realizing that an idea many of us have been quietly working on for years — that a traveler's digital identity can live in their wallet and work everywhere — is no longer theoretical. It has a working form. It has airlines that believe in it. And it has a path to production.

I've been contributing to digital identity across a lot of contexts: SD-JWT, ISO 18013, EUDI, wallet libraries. Aviation feels different. Aviation is global by nature — you
can't solve it one country at a time. Which makes contributing to it feel bigger, more fragile, and more consequential, all at once.

After WDS: The OneID Workshop

When WDS wrapped up, a group of us went to the OneID Workshop — IATA's initiative for a seamless, identity-based passenger journey across booking, check-in, bag drop, security, boarding, and border control.

The workshop was one of those rare conversations where everyone in the room is honest about the state of the transition. Not the marketing version — the real version. Where are we? What's working? What isn't? What are the parts that still keep us up at night, technically, operationally, and regulatorily?

I left with more energy than I walked in with. There's so much still to do, and so many thoughtful people doing it.

Looking Forward

Cycle 2 is a milestone, not a destination. The next PoC cycle will bring new challenges: deeper integration with legacy PSS stacks, more diverse wallet ecosystems, harder interoperability edges, and the regulatory alignment needed to move all of this from experimental to operational.

I'm genuinely excited to see where it goes. I'm grateful — to Hopae for the trust, to the IATA team for running a PoC process that actually produces working artifacts,
and to every engineer, product person, and policy contributor I've been lucky enough to work alongside over the past months.

Singapore was the moment this year of quiet work became visible. I can't wait for the next cycle.

There's a trap that almost every startup engineer falls into at some point. A problem surfaces. You look at it, recognize a pattern, and think: "Oh, I know what to do here." So you start building. You move fast, you feel productive and three days later, you ship something that technically works, but doesn't actually fix anything.

The assumption was wrong from the start. You just didn't stop long enough to check it.

A story that still stings.

We had a recurring issue: certain features were failing in production, semi-randomly, often enough to erode user trust. The obvious answer seemed clear. We didn't have enough test coverage. So we invested time setting up an E2E test suite. It wasn't trivial. We wrote scenarios, wired up the pipeline, and got it running.

The failures kept happening.

After digging deeper, I finally found the real issue. It wasn't a lack of tests. It was that the underlying code structure made it easy for humans to make mistakes. The architecture had implicit assumptions baked in, no guardrails, and places where a small misstep would silently propagate into a bug. People weren't being careless. The structure was setting them up to fail.

Once we restructured that part of the system, adding explicit contracts, removing ambiguous states, making the wrong path harder to take than the right one. The failures stopped. Not because we caught more bugs, but because the bugs stopped being introduced in the first place.

The E2E tests were a reasonable guess. But they were solving for a symptom, not the cause. We lost real time before we stopped and asked the harder question: what is actually broken here?

The real skill is finding what actually works

Before committing time to a solution, the question isn't "does this make sense?", it's "have I confirmed this actually solves the problem?" Those are very different questions.

In practice, this means:

• Define the problem precisely before touching code. Vague problems produce misdirected solutions.

• Validate your assumption cheaply first. A 30-minute spike or a quick test can save 3 days of wasted implementation.

• Ask "will this actually fix it?" — not "does this look right?" Intuition is a starting point, not a verdict.

Startups don't fail because people weren't working hard enough. They often fail because people were working hard on the wrong things, convinced they were on the right track.

Problem-solving isn't about finding an answer that sounds good. It's about finding one that works and proving it before you bet your sprint on it.

The main reason I was there was work, specifically, deep focus time on the EUDI Wallet ecosystem. Being embedded in Europe made a real difference. Proximity to the people, the standards bodies, and the conversations happening in real time meant I could move faster and understand the context behind the spec decisions in a way that's hard to get remotely.

UNFOLD & Interop Week in Paris

The highlight was traveling to Paris for the UNFOLD event and the interoperability week that followed. These gatherings brought together wallet providers, verifiers, and identity ecosystem players from across Europe. All trying to make their implementations actually talk to each other.

We came in with one goal: prove that our stack works with everyone else's. And we did. We achieved full interoperability with France Identité, and hit 100% interoperability across all participating implementations. Seeing the pieces click together across different teams, different tech stacks, and different national contexts, that was genuinely satisfying in a way that passing your own test suite never quite is.

Beyond the Work

Luxembourg itself surprised me. It's a small country, but the density of people doing interesting things, in tech, in policy, in finance, is remarkable. I met people from all over Europe and had conversations I wouldn't have had anywhere else.

And of course, being in the heart of Europe meant weekends could look like Paris, Brussels, or somewhere entirely unexpected. It gave me a different lens for understanding how Europe thinks about identity, privacy, and digital infrastructure, not just as technical problems, but as deeply cultural ones.

Looking back, 2025 was packed — sometimes overwhelming, but always moving forward.

Conferences, Workshops, and Global Connections

I lost count of how many events I attended and presented at this year: IIW, EUDI Launchpad, FUNKE, UNFOLD, WE BUILD workshop, and the IATA Data PoC face-to-face meeting. I also participate OpenID Foundation standards meetings one time, staying close to where the specifications are being shaped.

Each event was a chance to learn, share, and connect with people working on the same problems across the globe.

Projects That Pushed Me

This year brought a diverse mix of projects:

• Building Korea's wallet standard

• IATA Data PoC

• WE BUILD

• Applying VC technology to CBDC wholesale systems

And beyond the technical work, I had the chance to lead a small team. That experience alone taught me more about myself than any single project could.

On top of that, I shipped two main products for the company, Hopae Connect & Hopae Auth, both from zero to one. Building something from nothing, twice, in one year. That's something I'm proud of.

Looking Ahead to 2025

Did I accomplish everything I planned? No. But that's okay.

Next year, I want to focus on preparing for European compliance, building robust system architecture that runs smoothly in production, and taking another step forward in the EUDI space. I also want to grow as a team lead, not just managing, but actually leading well.

And to Tree, thank you for being such a great teammate this year. None of this would have been possible without you.

Here's to another year of building, 2026.

Where Is Open Source Headed in the AI Era?

The most striking takeaway from the sessions was realizing just how many AI-related open source projects are already thriving under the Linux Foundation. So much of the AI technology we interact with daily runs on open source, and the Linux Foundation provides the governance and sustainability to keep it going.

Open source isn't becoming less relevant in the AI era. it's becoming more essential. Transparency in models, reproducibility, community-driven improvement. All of these align directly with open source philosophy.

A Conversation with Daniela — The Potential of the Korean Community

I had the chance to meet Daniela from Linux Foundation Decentralized Trust. On the 5th, she hosted an evening session, and I gave a presentation there as well. Our conversation centered on expanding the community in Korea, getting more Korean companies and developers involved in LFDT and growing the open source ecosystem here.

It's encouraging to see a global open source foundation taking interest in the Korean community. At the same time, it reminded me that we need to step up and contribute more actively.

Linus Torvalds, Right Across the Table

That evening, I attended the Linux Foundation Dinner at OPENNG. And by some stroke of luck, I ended up sitting directly across from Linus Torvalds.

Of everything he shared, one thing stuck with me the most:

"A lot of people will tell you what they want from your project, but you can't lose sight of your goal."

When you maintain an open source project, requests and opinions come from everywhere, feature requests, suggestions about direction, sometimes criticism. All that feedback matters, but ultimately, you can't lose sight of the core problem the project set out to solve.

This was something I'd been wrestling with as a maintainer. Hearing it directly from Linus gave those words a weight I won't forget.

Heading Home

These two days were more than just a conference. I met people who share the same philosophy, and I got to see where I stand within the global open source ecosystem.

Meeting others with the same struggles at events like this gives me energy again. Open source, after all, isn't something you build alone. it's something you build with a community.

Don't lose sight of the goal. I'll keep Linus's words close.

But reality isn't a photograph. It's a video. Systems continuously move and evolve. Today's perfect abstraction becomes tomorrow's shackle. Today's optimization becomes tomorrow's legacy.

The Art of Trade-offs: Every Decision Has a Price

There's no free lunch in software development. Every decision is a trade-off.

We must constantly weigh current debt vs. future debt. Choose a quick & dirty solution now, and you'll move fast today but accumulate technical debt for tomorrow. Conversely, spend time on perfect abstractions and optimizations now, and you'll slow down current development while increasing costs.

The problem? Many coders reflexively choose the latter. Obsessed with "never creating technical debt," they sink into the swamp of over-abstraction. Ironically, this very behavior creates technical debt.

The Coder's Stupid Decision: Personal Satisfaction

Elegantly abstracted code. Perfectly applied design patterns. Every SOLID principle religiously followed. The developer who creates this "beautiful" code might feel immense satisfaction.

But from the team's perspective, it's a different story:

• Comprehension barriers: New team members or other developers take 2-3x longer to understand the code

• Change resistance: Over-abstraction forces simple changes through multiple layers

• Debugging hell: When problems arise, it's overwhelming to figure out where to start tracing

• Over-engineering costs: Code made "extensible" for changes that will never actually happen

This is the coder's stupid decision: prioritizing personal technical satisfaction over team productivity.

The Architect's Perspective: Evolving Systems

True architects know that systems always change. So instead of perfect snapshots, they build evolvable systems. This mindset is especially critical in startups, where the entire business model might pivot next month, and every week of development time directly impacts runway.

Core considerations for architects:

1. Changeability

"How easily can this code be changed?" matters more than "How perfect is this code?" Sometimes simple, intuitive code is easier to modify than sophisticatedly abstracted code.

2. Team Capability

Perfect code is meaningless if the team can't maintain it. Consider the team's current skill level, domain knowledge, and learning curve. Don't overplay your hand, attempting work beyond your team's current capabilities is a recipe for failure. Start with what you can realistically handle and grow from there.

3. Time Constraints

Business doesn't wait. An 80% solution delivered in 2 weeks can be more valuable than a perfect solution delivered in 3 months.

4. Cost-Effectiveness

If pursuing technical perfection exceeds budget or results in negative ROI, the project itself becomes meaningless.

Principles of Pragmatic Design

1. Just Enough Design

Design only what's needed. Don't try to anticipate every future possibility. Remember YAGNI (You Aren't Gonna Need It).

2. Progressive Enhancement

Don't pursue perfection from the start. Improve incrementally. Start with an MVP, then refactor when actual requirements become clear.

3. Team-First Approach

"Ordinary" code that the entire team can work with comfortably beats "genius" code that only one person understands.

4. Measure, Don't Guess

Don't optimize based on speculation. Measure actual bottlenecks first, then improve. Premature optimization is the root of all evil.

Survival from the AI: The End of Simple Coders

Here's an uncomfortable truth: simple coders obsessed with "perfect code" will soon be replaced by AI. Think about it. What does AI do best?

• Apply design patterns ✓

• Follow best practices ✓

• Generate boilerplate code ✓

• Refactor according to rules ✓

• Reproduce patterns from Stack Overflow ✓

That's right. Everything these simple coders pride themselves on their "technical perfection". AI can already do better. GitHub Copilot, Cursor, Claude... they already write "textbook perfect code" faster and more accurately than humans.

Conclusion: From Coder to Architect

Becoming a good developer isn't just about building technical skills. It's about gaining the wisdom to view systems from a broader perspective, understand team and business context, and make appropriate trade-offs.

Coders see code. Architects see the entire system lifecycle. Coders pursue present perfection. Architects pursue future adaptability.

Do you want to be a photographer or a film director? Do you want to be replaced by AI or command it?

The choice is yours. But remember: the software we build is a living, evolving system. Not a perfect photograph, but an ongoing movie. And the director of that movie is the architect.

Meeting Diverse Industry Stakeholders

What struck me most about the workshop was the opportunity to meet representatives from various airlines and aviation industry companies. Seeing participants from different backgrounds and expertise come together to discuss common goals truly demonstrated the industry's collaborative spirit.

Digital Identity Technology: From Theory to Reality

The core focus of this workshop was Digital Identity Technology. Rather than merely discussing technical possibilities, we engaged in concrete and realistic discussions about how this technology could solve actual problems facing the aviation industry.

Ideas flowed about revolutionizing the complex and time-consuming processes from passenger identity verification to security screening and boarding procedures. The focus was particularly intense on finding solutions that could achieve both improved passenger experience and enhanced operational efficiency.

Real-World Barriers and Implementation Challenges

However, the path to innovation was far from smooth. Beyond technical feasibility, there were numerous real-world barriers to overcome for actual implementation:

• Legacy System Complexity: The compatibility issues with existing systems built over decades proved to be the biggest obstacle. With each airline and airport using different systems, integrating new digital identity technology required far more complexity than simply adding new technology.

• Varying Privacy Regulations by Country: What particularly impressed me was how personal data protection laws differ slightly from country to country. There was a real dilemma in satisfying GDPR and each nation's unique privacy regulations while providing seamless international aviation services.

• Balancing Security and Convenience: Finding the equilibrium between enhanced security and passenger convenience

• Cost and Investment: The enormous economic burden of industry-wide infrastructure changes

Understanding Aviation Industry Realities

Through this workshop, I gained a deeper understanding of the aviation industry's complex ecosystem. I came to appreciate the industry's unique characteristics, that it's not simply about implementing technology, but rather meeting the multifaceted requirements of safety, security, efficiency, and customer experience all at once.

Particularly, given the aviation industry's nature requiring international cooperation, I realized that innovation by individual companies alone has its limitations. True transformation requires industry-wide collaboration and standardized approaches.

The Journey Until April 2025

This project is scheduled to continue until April next year. I'm genuinely excited and thrilled about the possibility of contributing to aviation industry innovation through this journey over the coming months.

Beyond simply developing technology, being able to contribute to solving real industry problems and improving passenger experiences brings great satisfaction.

Closing Thoughts

Those few days in Montreal were truly precious. I was able to witness firsthand the efforts to bridge the gap between technology and reality, and the industry's passion for creating better aviation experiences.

I hope to continue participating in such meaningful projects, contributing to the digital transformation of the aviation industry. I want technology to become a tool that goes beyond simple innovation to actually improve people's lives.

However, for digital identity systems to function effectively, one element stands above all others: trust. We need reliable mechanisms to verify that digital credentials, certificates, and attestations are authentic and issued by trustworthy authorities.

The Current Challenge: Fragmented Trust Systems

Today's digital identity ecosystem suffers from severe fragmentation. Organizations and platforms have built their own isolated trust mechanisms, resulting in a landscape where interoperability between different systems is virtually non-existent.

Consider this common scenario: a digital diploma issued by a Korean university cannot be automatically verified by a German company's hiring system, or professional credentials from Canada remain unrecognizable to employers in Singapore. Each country has developed its own national digital identity framework with distinct technical standards and trust models, creating significant barriers that limit cross-border recognition and the global utility of digital credentials.

The Solution: Open Trust Infrastructure Like DNS

To address this challenge, we need universally accessible and interoperable trust infrastructure, similar to how DNS (Domain Name System) works. Just as DNS serves as the foundational infrastructure that enables the internet to function seamlessly across the globe, digital identity trust systems require an open, standardized approach.

The Power of Open Source

The most effective path to building such infrastructure lies in open source development. This approach offers compelling advantages:

• Transparency: Open code allows anyone to audit and verify the system's integrity

• Accessibility: No vendor lock-in ensures universal access and adoption

• Innovation: Global developer collaboration accelerates advancement and improvement

• Security: Community review strengthens security through collective scrutiny

Standardization Efforts: Trust Registry Query Protocol

In this context, the work of organizations developing standards like the Trust Registry Query Protocol becomes crucial. These protocols provide essential capabilities:

• Verification of digital credential issuing authorities

• Standardized methods for querying trust information

• Interoperability guarantees between diverse systems

• Foundation for scalable, distributed trust networks

Building the Foundation for Tomorrow

The importance of trust services in digital identity systems extends far beyond security considerations. This infrastructure represents the backbone of digital society—the key that ensures equitable access to digital services for everyone.

When we establish open and interoperable trust infrastructure, we unlock tremendous potential:

• For individuals: Safer, more convenient management of digital identities

• For businesses: More efficient and reliable service delivery

• For society: Reduced digital divides and enhanced inclusivity

Looking Ahead

Just as DNS enabled the internet's explosive growth and global adoption, standardized and open digital identity trust infrastructure will serve as the foundation for the next generation of digital society. Achieving this vision requires not only technical standard development but also sustained collaboration among diverse stakeholders and continued commitment from open source communities.

The trust infrastructure we build today will serve as the bedrock of digital society for decades to come. This is precisely why it's essential to design these systems with openness and universal access as core principles from the very beginning.

July's Historic Gathering: Global Digital Collaboration

The OpenWallet Foundation is co-hosting the 'Global Digital Collaboration' event on July 1-2, 2025, in Geneva, Switzerland, alongside over 30 organizations.

As an open source maintainer, I'm very excited about the potential for diverse use case collaborations through this event.

Interoperability and Future Prospects

The Government Advisory Council (GAC) currently has 10 countries participating. The participation of such diverse nations in such a short time is truly impressive.

The OpenWallet Foundation's interoperability approach ensures user choice, security, and privacy while operating on a global scale.

The July 1-2 Global Digital Collaboration will be a major stepping stone for digital identity adoption and interoperability.

Conclusion: Toward a Trustworthy Digital Future

The efforts of the OpenWallet Forum and Foundation go beyond simply creating technical standards. They are fostering an internationally aligned ecosystem that provides trustworthy, open, and inclusive tools for a safe and sound global economy.

The Geneva event in July will be more than just a conference. It will be a historic moment opening a new era of digital trust. At the center of this future of digital identity that the world is creating together are the OpenWallet Forum and Foundation.

The future of digital identity depends on interoperability. And that future is starting now.

1. Passive Attitude: "I Only Do What I'm Told"

The Problem

Nothing is more fatal in a startup than hearing "That's not my job." Passive developers only execute explicit instructions, refusing to see the bigger picture. They spot bugs but think "Not my code, not my problem." They have improvement ideas but never share them.

The Right Direction

Take ownership. Every startup member is a mini-CEO. Even when writing a single line of code, ask yourself: "What value does this bring to our product and users?" When you spot problems, present them with solutions. When you see better ways, speak up actively.

2. The Perfectionism Trap: "I Can't Start Until Everything Is 100% Ready"

The Problem

"The requirements aren't fully clear yet," "How can I start when the design isn't perfect?" "We'll probably have to change this later anyway..."

Some developers live by these excuses. In startups, 100% perfect planning doesn't exist. Markets change daily, user feedback is unpredictable, and the product itself is a hypothesis. While waiting for perfection, competitors pass you by and opportunities disappear forever.

The Right Direction

Execute at 70% readiness, improve the rest as you go. The startup mantra is 'Build-Measure-Learn.' Creating an MVP quickly and getting market feedback beats launching a "perfect" product a year later by a hundredfold.

You need the mindset of "Let's start with this and fix problems as they come." You can always refactor later, but missed opportunities never return.

3. Communication Breakdown: "My Way Is Best"

The Problem

The most frustrating moments:

• The team decides on A in a meeting, but someone builds B anyway

• When given feedback, responding with "You just don't understand"

• Taking help for granted without expressing gratitude

• Sulking and doing sloppy work when their opinion isn't accepted

These attitudes destroy team trust and make collaboration impossible.

The Right Direction

Listening and respect are fundamental. First, hear others out completely. If you disagree, try: "That's a good perspective, but what if we also consider this aspect?" And when someone helps you, express genuine gratitude. Small thank-yous transform team dynamics entirely.

4. Information Hoarding: "I'll Keep It to Myself"

The Problem

Disasters created by developers who don't share information:

• Deadline bombshells: "Oh, actually I don't think I can finish this"

• Delivering something completely different from requirements

• Only reporting progress when explicitly asked

• Struggling alone with problems until missing deadlines

The Right Direction

Practice transparent communication:

• Share honest progress updates in daily standups

• Ask for help immediately when stuck

• Alert the team early about schedule changes

• Document your work and share with the team

Saying "I need help" isn't weakness. It's professionalism.

5. Lack of Accountability: "It's Not My Fault"

The Problem

Developers who make excuses first, who blame others first, block the team's growth. "QA didn't catch it," "The specs weren't clear," "There wasn't enough time"—these excuses don't solve problems.

The Right Direction

Own your mistakes and learn. When problems arise, have the courage to say: "I missed something there. Here's how I'll improve going forward." Mistakes are growth opportunities. What matters is not repeating them.

Final Thoughts: Attitude Determines Ability

In startups, the right attitude often matters more than exceptional coding skills. A growth mindset, open communication, and ownership. These create healthy development cultures.

Startups especially must move fast amid uncertainty. Rather than losing opportunities while pursuing perfection, we need to start now and rapidly iterate.

None of us are perfect. But we can strive to become better developers and better teammates. Why not start making small changes today?

Small attitude shifts create team-wide success. Let's build a better development culture together.

What Was Compromised?

SK Telecom's core server, the HSS (Home Subscriber Server), was infected with sophisticated malware called BPFDoor, leading to the mass theft of the following information:

• IMSI (International Mobile Subscriber Identity): International mobile subscriber identification numbers

• IMEI (International Mobile Equipment Identity): Device unique identifiers (uncertain if compromised)

• Authentication Keys: Core information used for SIM authentication

• MSISDN: Phone numbers

• Personal Information: Names, dates of birth, etc.

Approximately 27 million IMSI records were confirmed compromised, meaning that information for most SKT subscribers was exposed. What's particularly concerning is that this information doesn't exist in isolation—it forms complete communication profiles when connected together.

What Attacks Became Possible?

The Threat of SIM Swapping and USIM Cloning

The most immediate threat enabled by this breach is SIM swapping attacks. Attackers can transfer a victim's phone number to their own SIM card, intercepting text-based authentication to access financial services or social media accounts.

More seriously, USIM cloning attacks became possible. Particularly when USIM cloning is combined with IMEI spoofing, it becomes extremely difficult for carriers to distinguish between legitimate users and attackers. While SKT claims to have strengthened their FDS (Fraud Detection System), this provides only probabilistic defense and cannot guarantee complete protection.

In practice, attackers can combine sophisticated social engineering attacks, such as impersonating government agencies to request device reboots, then attempting SIM swaps during those brief moments. Against such complex attacks, individual users find it nearly impossible to protect themselves.

Fundamental Limitations of the Current System

The Disaster of Centralized Architecture

The current carrier-centric authentication system inherently relies on a centralized structure. Having all subscriber core information concentrated in a single HSS server represents an enormous security risk in itself. This incident demonstrates the realization of such structural vulnerabilities.

The bigger problem is that this information is static. Once generated, IMSI or authentication keys remain the same unless the SIM is replaced. Therefore, once compromised, they can be continuously exploited with no fundamental way to prevent it. This is why SKT decided to replace all customers' SIM cards.

However, SIM replacement cannot be a fundamental solution. If new SIMs are issued using the same structure and methods, the same problems can recur with another hack at any time. It's like replacing only the lock on a broken house while leaving the fence and security system unchanged.

Credential-Based Authentication: A New Paradigm

The Era of Self-Sovereign Identity

We need an entirely new approach. Credential-based authentication is based on the concept of Self-Sovereign Identity, where users directly manage their own digital identities. This represents not just a technical change, but a philosophical shift in how we manage identity in the digital age.

An ID Wallet is a digital wallet securely stored on a user's device, containing Verifiable Credentials. These credentials have dynamic characteristics—they can be created, used, and revoked as needed. Even if someone steals a credential, it's likely already expired or restricted to work only under specific conditions.

Combining Device Binding with Multi-Factor Authentication

Device Binding is a crucial element of this system. It's not simply about software-level information, but binding identity to devices at the hardware level. Using hardware security modules like TPM (Trusted Platform Module) or Secure Elements makes it virtually impossible to clone authentication information without physically stealing the device.

Combining this with various authentication factors—biometrics, PINs—creates even stronger security. Even if attackers steal some information, they cannot succeed in authentication without the remaining factors. This provides a fundamentally different security level compared to the current single-factor (SIM) dependent system.

Additionally, credential-based systems enable 'Selective Disclosure.' For example, when accessing age-restricted services, instead of providing your entire resident registration number, you can present a credential that only proves "I am over 19 years old." This innovative approach simultaneously enhances both privacy protection and security.

Conclusion: A Transition We Can No Longer Delay

The SKT hacking incident is not just a security breach—it reveals the structural limitations of our current digital authentication system. A system where 27 million people's information can be compromised at once is no longer sustainable.

The transition to credential-based authentication has already reached a technologically feasible level. W3C's DID (Decentralized Identifiers) and Verifiable Credentials standards are established, and notably, the W3C Verifiable Credentials Data Model 2.0 was officially published in May, 2025, providing an even stronger standards foundation. Many countries and companies are already conducting pilot projects based on these standards. What we need is not technology, but the will to accept and implement change.

Carriers must prepare to transform their role from managers of all authentication information to trusted authentication service providers. Governments must establish the legal and institutional frameworks to support new authentication systems. And we all must renew our understanding of what digital identity means and how it should be protected.

In the wake of the SKT incident, it's time to accelerate the transition to a safer, more user-centric digital authentication system. Before the next hack occurs, we must begin fundamental change.

This article was written reflecting on the future of digital authentication following the SKT SIM hacking incident. Everyone's attention and participation are needed for a safer digital environment.

The IIW Presentation

Our team has been working on implementing SD-JWT VCLD, which is specified in the OpenID for Verifiable Presentations (OpenID4VP) standard.

During our session at IIW, we focused on:

• Implementation challenges we encountered while building our SD-JWT VCLD solution

• Technical feedback that could help improve the standard

The discussion that followed was invaluable. Fellow implementers and standards experts shared their perspectives, and we engaged in productive debates about edge cases and potential improvements to the specification.

We also participated in the speed demo session, which was a great opportunity to showcase our implementation in action. Being able to demonstrate the actual working code alongside our feedback made our points more concrete and relatable.

OpenID Working Group Meeting at Infinite Loop

The following day brought an exciting opportunity - participating in an OpenID Working Group meeting held at Apple's Infinite Loop campus. Being part of these technical discussions in person added a new dimension to our involvement in the standards community. The face-to-face format enabled deeper technical discussions and helped build stronger connections within the working group.

Closing Thoughts

This experience reinforced the importance of implementer feedback in standards development. By building real implementations and sharing our experiences, we contribute to making these standards more robust and practical for widespread adoption.

It was truly exciting to contribute directly to standards development, and I want to express my appreciation to everyone working passionately to create better standards. Looking forward to continuing this journey and contributing more!

Reconsidering Documentation Processes

While design docs served us well in certain contexts, particularly with large, distributed teams, I've discovered their limitations in fast-paced, innovative environments:

1. Documentation can stall progress - In small, agile teams, documentation often becomes a bottleneck rather than an accelerator.

2. Solutions emerge through building - When creating something truly new, theoretical planning only gets you so far. The most valuable insights come from building and iterating.

3. Documentation can cement sub-optimal decisions - Detailed docs tend to create psychological commitment to initial approaches, making teams reluctant to pivot when necessary.

The "Prototype First, Design Second" Philosophy

After experiencing the downsides of documentation processes, I've adopted a more pragmatic approach:

Talk with Code, Not Docs

I've found that building a minimal, working solution first—even if imperfect—provides concrete material for discussion. Code becomes the primary communication medium, allowing team members to:

• Experience rather than imagine the solution

• Identify practical issues that weren't apparent in theory

• Contribute improvements based on tangible examples

Focus on Solutions, Not Architecture

When faced with novel problems, starting with architecture design often leads to analysis paralysis. Instead:

• Build a simple implementation that addresses the core problem

• Let the architecture emerge organically as you identify actual, not theoretical, constraints

• Use working code as the foundation for more thoughtful planning

Embrace a Hybrid Approach

I haven't abandoned documentation entirely. Instead, I've found a balanced approach works best:

• Use lightweight documentation to capture key decisions and rationales

• Build prototypes to validate assumptions before investing in detailed plans

• Foster a "living documentation" culture where documented decisions are seen as part of an ongoing conversation rather than permanent fixtures, encouraging team members to challenge previous decisions whenever better solutions emerge

Real-World Results

This shift in approach has yielded surprising benefits:

• Faster time-to-value: We're delivering usable features in days rather than weeks

• More innovative solutions: Hands-on building surfaces opportunities that planning sessions miss

• Increased team engagement: Engineers are more invested in solutions they've helped shape through building

• Better adaptability: We pivot more easily when early implementations reveal new insights

From Theory to Practice

My journey from "Design First" to "Prototype First" wasn't straightforward. I encountered several challenges that forced me to refine this approach:

Challenge 1: Maintaining Coherence

Prototype first occasionally led to inconsistent implementations across features. To address this, we introduced:

• Regular code review sessions focused on architectural patterns

• Lightweight design principles documented after successful implementations

• Shared libraries built from proven solutions

Challenge 2: Knowledge Transfer

Without comprehensive documentation, onboarding new team members became challenging. Our solution:

• Well-commented code that explains the "why" behind decisions

• Periodic architecture overview sessions based on existing implementations

• Just enough documentation that captures key design decisions after they're validated

The Refined Approach

What I've ultimately arrived at is a more nuanced process that combines the best of both worlds:

1. Build a minimal working solution to address the core problem

2. Review and refine based on actual usage and feedback

3. Document key decisions and patterns that emerge from successful implementations

4. Scale the solution with the benefit of practical experience

Conclusion

My evolution from advocating detailed upfront design to embracing a "Prototype First, Design Second" approach reflects a deeper understanding of how software development actually works in practice. While documentation remains valuable, I've found that the most effective teams use it as a tool to capture wisdom gained through building, rather than as a prerequisite for creation.

The best conversations happen around working code, not theoretical documents. By letting solutions emerge through building and experimenting, we've created better products faster, while still maintaining the cohesion and knowledge sharing that documentation provides.

Digital Identity has emerged as a crucial infrastructure in the modern digital economy, creating new business opportunities and enhancing our lives through identity verification, credentials, and access control. However, after working in this field for two years, I've observed significant barriers to adoption that continue to persist.

Current Challenges in Digital Identity Adoption

The main challenges organizations face when implementing Digital Identity solutions include:

1. High Implementation Costs: Extended development periods and difficulties in securing specialized talent due to technical complexity

2. Lack of Interoperability: Limited scalability due to compatibility issues between different systems

3. Sustainability Issues: Complex maintenance and update procedures making operations difficult

The root cause of these problems ultimately comes down to the "lack of appropriate infrastructure" - particularly the shortage of developer-friendly tools and frameworks.

Solution: Developer-Friendly Open Source Tools

My proposed solution is the development and distribution of "developer-friendly open source tools" that adhere to the following core principles:

1. Simply Working

Looking at successful authentication/authorization SaaS products like Furo or Clerk, we can see the importance of "simply working." They provide an environment that works immediately after project creation. In contrast, current Digital Identity frameworks require lengthy configuration lists before you can even start.

Think about React.js - you create a project with create-react-app or vite, type npm start, and immediately see results in your browser. Digital Identity tools should work the same way. Instead of wrestling with lengthy configuration documents, developers should be able to start with defaults and customize progressively.

2. Zero Protocol Knowledge Required

When implementing JWT, developers don't need to read RFC 6749 or 6750. They just find the jsonwebtoken library and set the secret and payload. Similarly with React - you learn by manipulating HTML tags and CSS values without understanding the internal workings.

Currently, Digital Identity libraries are only used by a small number of developers who understand the underlying standards and protocols. However, 99% of web developers aren't familiar with these underlying standards. They just want to focus on their business logic.

3. Security by Design

Consider CORS - it enforces security rules by default, and exceptions must be explicitly configured. You can't turn off CORS. Similarly, Digital Identity tools should provide security by default while guiding users on why these security measures are necessary and how they can achieve their business objectives within these security boundaries.

Implementation Example

Based on these principles, I started the Verifiable Digital Credentials project, which features:

• Ready-to-use default configurations

• Simple APIs that don't require protocol knowledge

• Built-in security by design

Conclusion

The field of Digital Identity holds immense potential, but its complexity shouldn't be a barrier to adoption. By focusing on developer experience and providing the right tools, we can make this technology more accessible and practical for everyone. Through open source communities and easily accessible resources, we can build a more inclusive and efficient digital identity ecosystem.

The Initial Challenge

In the early days of our product development, we struggled with some common yet critical issues:

• Different interpretations of product requirements

• Varying approaches to user experience design

• Conflicting ideas about technical implementation

• Misaligned expectations about project timelines

What made these challenges particularly difficult was that we were building something without existing market references. Each team member had their own vision of how the product should work, influenced by their cultural background and local market understanding.

Breaking Point and Solution

The wake-up call came when we realized we had spent three weeks building features based on completely different interpretations of the same product discussions. Our daily standups and weekly planning sessions weren't enough - something had to change.

That's when we developed our systematic approach to design documents. But these weren't your typical technical specs. We created what we called "Context-Rich Design Docs."

Our Documentation Framework:

1. Problem Definition
   - Current user pain points
   - Market context by region
   - Success metrics

2. Proposed Solution
   - Core functionality
   - Regional considerations
   - Technical approach
   - User experience goals

3. Implementation Details
   - Phase-wise breakdown
   - Regional adaptations
   - Testing requirements
   - Success criteria

The Results

After implementing this documentation approach for six months:

• Feature development time reduced by 40%

• Rework requests dropped by 75%

• Team satisfaction scores improved by 60%

• Sprint completion rate increased from 65% to 90%

Why Design Docs Worked

The success came from creating a shared understanding before writing any code:

1. Asynchronous Deep Thinking: Team members could process information and provide thoughtful feedback without time zone pressure.

2. Visual Communication: Diagrams and wireframes helped bridge language gaps and clarify complex concepts.

3. Cultural Context: Explicit documentation of cultural considerations helped prevent misunderstandings.

4. Single Source of Truth: All decisions and their rationale were recorded and easily referenceable.

Key Takeaways for Global Teams

If you're working with a cross-cultural team:

1. Start with clear documentation before jumping into implementation

2. Use visuals extensively - they transcend language barriers

3. Document assumptions and cultural considerations explicitly

4. Create flexible frameworks that can adapt to different perspectives

5. Regular review and update cycles for living documents

Looking Forward

This approach didn't just help us build a better product - it helped us build a stronger, more cohesive team. We're now able to tackle complex features with confidence, knowing we have a solid foundation for cross-cultural collaboration.

My Research Journey

My thesis, titled "Designing an Authentication System with Enhanced User Control over Personal Information: Focused on OIDC and Selective Disclosure Techniques," delved into one of the most pressing challenges in our digital age. As our lives become increasingly interconnected through digital platforms, the need for robust yet user-centric authentication systems has never been more critical.

Through my research, I explored how OpenID Connect (OIDC) could be leveraged alongside selective disclosure techniques to create an authentication framework that respects user privacy while maintaining security. This journey taught me far more than just technical knowledge – it opened my eyes to the complex balance between security, usability, and privacy in digital systems.

Key Learnings

The most valuable lessons from my master's research weren't just about the technical aspects of authentication systems. I learned the importance of:

• Putting users first in security system design

• Understanding the delicate balance between convenience and privacy

• Appreciating how theoretical concepts translate into real-world applications

• Collaborating with peers and mentors to solve complex problems

Looking Toward the Future

As I reflect on this achievement, I find myself increasingly drawn to the academic path. The challenges and discoveries I encountered during my master's research have ignited a passion for deeper exploration in this field. This has led me to an important decision: I want to pursue a Ph.D.

The world of digital authentication and privacy is evolving rapidly, and there are still many unsolved challenges waiting to be addressed. I believe that doctoral research would allow me to contribute meaningfully to this field and help shape the future of digital privacy and security.

Conclusion

My master's journey has been more than just an academic achievement – it's been a stepping stone toward a greater purpose. As I consider the possibility of doctoral studies, I'm excited about the opportunity to dive deeper into research and contribute to advancing the field of digital authentication and privacy.

2024 marked a significant year in my professional journey as I had the privilege of attending both sessions of the Internet Identity Workshop (IIW) in San Francisco - in April and October. These workshops proved to be more than just technical conferences; they were vibrant hubs of innovation, collaboration, and cross-cultural exchange in the digital identity space.

The Power of Open Dialogue

What makes IIW truly unique is its unconventional format. Instead of traditional presentations, the workshop embraces an open, collaborative approach to solving complex technical challenges. This format creates an environment where:

• Ideas flow freely between participants

• Solutions emerge through collective wisdom

• Different perspectives challenge existing assumptions

• Innovation happens organically through discussion

Global Perspectives on Digital Identity

One of the most enriching aspects of IIW was the exposure to various international approaches to digital identity. Each country's unique challenges and solutions provided valuable insights into the global identity landscape. Our team had the opportunity to share South Korea's innovative approach, particularly our esports use case, which generated significant interest among participants.

Spotlight on Our Innovation

The enthusiastic response to our esports use case presentation highlighted how different industries can leverage digital identity solutions in unexpected ways. The intersection of gaming, identity, and security sparked fascinating discussions about potential applications in other sectors.

Mobile Driving License (MDL): A Growing Focus

A notable trend across both workshops was the increasing emphasis on Mobile Driving License technology. The depth and breadth of MDL-related discussions have inspired new directions for our future work. The potential applications and implications of MDL technology present exciting opportunities for innovation in the digital identity space.

Personal Growth Through Global Exchange

These workshops provided more than just technical knowledge; they offered:

• Exposure to diverse problem-solving approaches

• Opportunities to challenge and refine existing ideas

• Valuable networking with global identity experts

• Fresh perspectives on familiar challenges

Looking Forward

The experiences and insights gained from IIW have shaped both my understanding of digital identity and my vision for future projects. The focus on MDL technology, in particular, has opened new avenues for exploration and innovation in our work.

Conclusion

The Internet Identity Workshop represents more than just a conference - it's a testament to the power of collaborative problem-solving and open dialogue in advancing digital identity solutions. As we move forward with our projects, particularly in the MDL space, the lessons and connections made at IIW will continue to influence and inform our approach.

The journey through IIW 2024 has reinforced that the future of digital identity lies not just in technical solutions, but in the power of global collaboration and open dialogue.

Project Overview

KRDS-React (GitHub Repository) is a specialized React component library designed to help developers build government digital services that are both accessible and user-friendly. Our library currently offers about 20 components, each crafted with careful attention to web standards and accessibility guidelines.

Key Features and Principles

Web Standards Compliance

In developing KRDS-React, we prioritized adherence to modern web standards, ensuring that our components work seamlessly across different platforms and browsers. This commitment to standards helps maintain consistency and reliability in government digital services.

Accessibility First

Accessibility isn't just a feature – it's a fundamental principle of our library. Every component is designed and tested to ensure:

• Screen reader compatibility

• Keyboard navigation support

• WCAG compliance

• Clear focus indicators

• Proper ARIA attributes

User Experience

Our components are designed to provide:

• Intuitive interactions

• Consistent behavior patterns

• Responsive design

• Performance optimization

• Clear feedback mechanisms

Impact and Recognition

The project's significance was acknowledged by the National Information Society Agency (NIA), which presented us with a letter of appreciation. This recognition validates our approach and encourages us to continue improving digital government services.

Future Vision

While we're proud of our current suite of 20 components, we see this as just the beginning. Our roadmap includes:

• Expanding the component library

• Enhancing documentation and examples

• Gathering community feedback

• Continuous accessibility improvements

• Performance optimization

Commitment to Better Digital Services

This project represents more than just a technical achievement – it's about making government digital services more accessible to everyone. By providing these tools, we hope to:

• Enable faster development of accessible websites

• Promote consistent user experiences across services

• Raise awareness about web accessibility

• Foster a community of developers committed to accessible design

Conclusion

KRDS-React demonstrates how open-source initiatives can contribute to better public services. We invite developers, designers, and anyone interested in improving government digital services to join us in this endeavor. Together, we can create more accessible and user-friendly digital experiences for all citizens.

The source code is available on GitHub. We welcome contributions and feedback from the community.

As a speaker at the recent Next-Generation Authentication Research Group seminar, hosted by the Korea Information Security Society, I had the opportunity to present on the future of digital identity authentication through the lens of open source initiatives. This presentation explored how both European and American organizations are leveraging open source technologies to build robust digital identity infrastructures.

Global Open Source Digital Identity Initiatives

European Developments

The European digital identity landscape is undergoing significant transformation through open source initiatives. These projects demonstrate a commitment to transparency, interoperability, and community-driven development in creating digital identity solutions.

• European Digital Identity Wallet Architecture and Reference Framework

• EU Digital Identity Wallet Consortium (EWC)

American Approach

In the United States, various organizations and government agencies are similarly embracing open source solutions for digital identity infrastructure. This approach reflects a growing recognition of the importance of collaborative development in creating secure and scalable identity systems.

• opencred

Benefits of Open Source in Digital Identity

Transparency and Trust

Open source solutions provide unprecedented transparency in security implementations, allowing for community review and validation of security measures.

Cost-Effectiveness

The adoption of open source technologies can significantly reduce implementation costs while maintaining high security standards.

Community-Driven Innovation

The collaborative nature of open source development enables rapid innovation and improvement through contributions from diverse experts worldwide.

Security Considerations

Supply Chain Security

One critical aspect discussed was the importance of securing the open source supply chain. Recent incidents have highlighted the need for:

• Careful vetting of dependencies

• Regular security audits

• Monitoring for potential vulnerabilities

• Implementation of secure update mechanisms

Personal Growth and Reflections

Preparing for and delivering this presentation was an invaluable experience in my professional journey. The research process deepened my understanding of digital identity systems and open source security considerations. Beyond the technical aspects, this opportunity helped me develop my presentation skills and ability to communicate complex security concepts to a specialized audience. The preparation process challenged me to think critically about the future of digital identity authentication and helped me grow both as a security professional and as a presenter.

Conclusion

The seminar provided a platform not only to share insights about open source technologies in digital identity authentication but also to grow professionally. The experience reinforced the importance of continuous learning and knowledge sharing in the rapidly evolving field of cybersecurity and authentication.