So, Matthias, you already stole some of my thunder. No, no, no, no, by introducing, because my question is, is this really the name of Roman and Rintaro?
So, what's been really interesting over the last couple of days, I've heard this many times, is the amount of friction that people have with their physical identity and a name that they're born with or is an official name that they don't use every day and then they book an airline or they check into a hotel or they go to do something that is not so official and then they bring out a piece of physical documentation and something doesn't match.
So, we have lots of challenges in the existing identity world with instruments, driver's license, passports, birth certificates, marriage certificates that are official but don't necessarily enable us to do things in the physical world. So, one of the things we're going to explore today is if we already have those challenges in the physical world, how might we start to overcome those in the world of verified credentials?
So, Roman, over to you. And the clicker.
Ah, the clicker. Yes. Yeah.
So, my name is Roman Zuhn. It's pronounced Zuhn. It has something from French language somehow inside.
Later, we'll explain why. I've worked since five years in the sphere of death-trial identity, mostly with the Swiss government in several positions, and it started with the technical interoperability.
Oh, if we want to exchange credentials, we need to align the protocols. Later, when we come to the first POCs and pilots, we notice, oh, we need a schema. Because if the attribute name, no one knows the attribute name, you can't ask for this. So then people started to look, okay, we need VC catalogs and stuff like this. So then the VC catalog started in Switzerland. In my position as DDoS, we're also responsible for the VC schemas there. And then when it comes to the real pilot, through all the Switzerland, we have four languages.
And then it's also the question, okay, so the French guy, so in the French part of Switzerland, he wants to see his credential in French with the attribute name, the value and everything. But if he goes to like 30 kilometers to the east, it's German. So the verifier asks the German version of the attribute.
So now, and then this is what happens in Switzerland. And then at Swisscom, we talked about the interoperability in the global world. And then we notice, oh my God, the problem is also in the value of the attribute. And I want to just show an example. This is Zhivko Ivanov. It's a fake ID. You can't use it to open a bank account later. So this is Zhivko Ivanov. And if he is traveling through Europe, his name will be transferred through ICAO, the first one. So it will be Zhivko in the Latin letters. If he is going more to the American part, it will be more on the ISO standard, Zhivko.
And if you go to the eastern, not the Asian, but the eastern, to the Russian, Kyrillic languages, then they have their own standard. Then there is still a German internal standard.
Then it's, of course, often you just scan a PDF, and then you have OCR, and it reads Kyrillic letters also different, and then you are wrong in the system. And this is not a complete list. There is a lot of standards. No one knows why. And then if you look on Japan, they don't have any standard. They have like phonetical transcription. And their problems are more problematic, rentable, say. And I was also, I had to sacrifice something from my personal life because of this. I was born in Russia. It's not popular right now. So we moved away in 1997.
So basically we ran away from Putin, already there. And then, so my last name is Zuhn. My birthplace is Chelyabinsk. And it was transcripted through a standard which was placed in Germany. So I was then Zuhn, and my birthplace was written like this. And then I need to renew my passport. And something changed in the standard. Germany accepted something, a different standard, and they changed my name. And all my degrees, everything what happened in the past was not valid. And I had some problems during interviews, traveling.
It was a bit more problematic because I couldn't explain, could not explain why I have my driver's license and my ID have different names. So it took me a lot of applications, a lot of time to change my name again back. But then it's a change again.
Now, if I come with my Cyrillic language, they would never get to my name, what I have right now. And now this is a bit problematic.
So for me, this is solved. I give up my Russian citizenship. I'm only German now. And I live in Switzerland. It's a bit complicated. But what I want to say is this is something that exists. And if you want to have the value from credentials, you need to streamline. You need to machine-readable application to this. It's not possible that credential is, I don't know, some of administrators will look on the credential and then, hmm, this is phonetical, should be this, and is it completable, and so on and so on. And this is super complicated then. And if you want real value, we need to solve this.
And now, Rintaro will also tell something from how is it in Japan. Okay, thank you, everyone. Good afternoon, everyone. I'm Rintaro Okamoto from DNP.
Today, I will discuss Japan's unique linguist challenges, linguist structure, and its impact on digital identity systems. As you can see from this slide, Lost in Translation will be exploring how Japan's multiple writing system creates significant challenges in digital identity system.
So, at first, Japan stands out globally for using four writing systems simultaneously. Unlike most countries with a single writing system, we regularly combine kanji, hiragana, katakana, and the Latin alphabet in our daily communication. This unique linguistic complexity creates challenges for digital identity management, which I'll demonstrate with concrete example. To illustrate these challenges, let's look at an example. Consider this famous Japanese national soccer player, Tanaka Maruko Tsuturio. Maybe you don't know. As you can see, his name can be written in four different ways.
In hiragana as Tanaka Maruko Tsuturio, in katakana as Tanaka Maruko Tsuturio, in a mix of kanji and katakana as Tanaka Maruko Tsuturio, or in the Latin alphabet as Tanaka Maruko Tsuturio. All represent the same person, yet digital systems often fail to recognize them as identical, creating serious challenges for identity verification. These aren't abstract problems. They cause real difficulties daily. Here's a specific example. When foreign tourists visit Japan and book hotels, they frequently encounter issues.
As you can see in this example, a reservation made under Stuart John in katakana won't match the passport name John Stuart. This name mismatch causes check-in delays and frustration for both the guests and hotel staff. This issue is particularly common with international travelers as Japanese systems handle names differently than Western systems. The language barriers create significant frictions in services delivery. The situation is further complicated by evolving standards.
Last year, after 70 years, the Japanese government updated its romanization guidelines to Hepburn systems. This change creates inconsistencies between legacy systems and new implementations. Here you can see the differences between Hepburn romanization, which produces names like Tsukiji, Chashitsu, and Fukushima, and non-Hepburn romanization, which produces Tsukiji, Chashitsu, Fukushima, or the same words. I experienced these challenges personally.
My passport uses Hepburn romanization Okamoto Rintaro, but when I tried to book a flight, the air apps had my name registered using the previous non-Hepburn system, Okamoto Rintaro. This created a mismatch with my passport name, and I had to go through a name change process and took an entire week to resolve, just to book a simple flight. As you can see from this slide, these are real problems that people encounter in everyday situations. In closing, Japan's multiple writing system creates tangible digital identity challenges that affect real people in everyday situations.
The critical point, as highlighted on this slide, is that it's not enough just to issue digital credentials. Verifiers play an essential role in this ecosystem. As we've seen in the example today, the same person can be represented through different writing systems. A single individual might have their name recorded in Hiragana, Kanji, and the Latin alphabet across different identity documents. When these credentials are presented to verifiers like banks, hospitals, and the airlines, the verification process is becoming challenging.
Verifiers need to be aware of these linguistic complications when handling digital certification from Japan and similar multilingual environments. By addressing these challenges at the verification levels, we can create digital identity systems that respect linguistic diversity while maintaining security and efficiency across borders. Thank you for your attention.
Thank you, Roman. Last words.
Also, recommendation is not only a verifier problem, it's also an issue problem. When we look at Swiss EID and EIDAS, what they say about transliterations at all, this is the regulations where you are mostly involved, and here we see that with the overlay capture architecture, which was decided for the Swiss EID, we want to tackle the multi-language problem that the user, when he has a French phone, he sees this credential in French, but in reality, the data and credentials are in four languages.
So when the verifier asks, he still can ask for the German language or French language, but the user doesn't see this. It's a user experience thing. And in EIDAS, they just provide, you need to provide some transliteration within Europe for first and last name, and birthday is optional. So here's a call for action. So please do some research on your own. Find some challenges here, and this is something that will not be triggered by the regulation within European Union, and also not in Switzerland. This is something that we need to find out on ourselves. Thank you very much. Now it's done.
Please, if you have questions. So there are no online questions, but there should be, yeah, I guess so. So my understanding is that all these challenges are because we are trying to ask computers to deal with something which was not designed for computers. So would it be better for airlines and banks just to say, okay, every nation is supposed to give a number ID, which is pretty much like numbers and kind of characters, and when you are checking in, if that number matches and name kind of matches, it should be okay. Would you consider that as the right direction?
I think it would be much better if you would take the solution from China with the fingerprint, but then we need to trust someone. Fingerprint, it's just a way for you to pretty much identify a specific person. But in general, the reason what you are seeing is the problem is the system, the airline, cannot deal with these four, Hiragana, Katakana, Kanji. So why don't we enter in the computers what the computers can deal with instead of trying to circumvent? Like vectorized words. Like word embedding in a credential to embrace the machine readability. This is basically a good idea, I think.
I think one of the problems with this approach, if you look to the US and the social security number, is that a single identifier can become incredibly weaponized. So if you look at the situation with Roman actually leaving Russia, having a translation, creating a new national identity, it's also possible to decouple from maybe a place of birth or a regime or an identifier.
So one of the challenges is it's happy and good for machines, but if we're looking at lots of real-world situations or edge cases where a single identifier can create multiple problems, then we have challenges in another way. So I think your idea in terms of finding something that's machine-readable is on the right track, but if it is one single unique identifier for life, then there are many other life challenges that can come associated with that. Not for life, but for the document. Yes. Maybe like a serial number for my passport. Yes.
But then the challenge still then is linking that document back to something that you present. So I think the possibility of this or the other possibilities, starting to think of nested credentials where there is some way of being able to present something that matches a document, but presents something that's cryptographically signed as a way of translation. And usually we are focusing on a system that from organization perspective really separated.
Because when we provide a credential in Switzerland and we provide a number, how we can ensure that someone in Japan can get access to this and so on and so on. So this is the magic of this dead central identity is that you don't have the number that you can check in a central registry. I hope this helps to answer the question. If you mean that you take the name as a chain of letters and make some embeddings out of this, that this is like a Rackstack approach, then it could be an option. But now then I think there are also several possibilities how to embed this.
It's also changed over time, I think. Okay, other opinions. I'm just thinking of the bigger problem, for example, the preferred name that many people have that they prefer Bartek instead of Bartosz.
Two names, same person. Joe instead of a longish name in Asian context. So just to make things easier, that also should fit into such an upcoming scheme and I think that's really a challenge. The good thing is that means we are not yet done with identity.
Yeah, so basically when you want to provide an EID that is globally accepted, it will be 10 megabytes or something just for names. Yeah, but it's 20, 25 to 10 megabytes shouldn't be an issue. The standards should be the issue.
Okay, but then we're done for today regarding this afternoon's session. Thank you very much to Katrina, to Roman, and you helped me. That's the problem with names, right? So thank you very much. We all have the message. Yeah.
