If you’ve ever created an account on a Korean online platform — any platform, not just the big ones — you’ve gone through 본인인증. You enter your name, date of birth, pick your mobile carrier, and wait for an SMS code. It looks like two-factor authentication, but the underlying mechanism is fundamentally different.
What actually happened is that your mobile carrier confirmed your civil identity to a government-authorized intermediary, who then generated a cryptographic identifier tied to your national registration number and handed it to the platform you were signing up for. The platform now knows that you are a real, unique, legally accountable person — not an email address or a username, but a verified civil identity.
Most of the world’s internet doesn’t work this way. And there are good reasons it doesn’t — but also good reasons South Korea decided it should.
A brief history of how Korea got here
Korea’s relationship with digital identity starts with the 주민등록번호 — the Resident Registration Number, a 13-digit identifier issued to every citizen at birth. Through the 2000s, most Korean websites simply asked for it at signup. It worked, in the sense that it established identity. It also meant that hundreds of private companies were sitting on databases of national ID numbers with varying levels of security.
The consequences were predictable. The 2011 SK Communications breach exposed 35 million records. The 2014 Korea Credit Bureau incident hit another 20 million. In a country of 51 million people, those numbers are staggering. The government moved quickly: amendments to the Personal Information Protection Act (PIPA, 개인정보보호법) banned direct collection of RRNs by private entities and mandated the use of authorized intermediaries for identity verification.
That’s how we got 본인인증 — the system where NICE Evaluation Information and Korea Credit Bureau (KCB) sit between the user and the platform, verifying identity through carrier records so that the platform itself never touches the raw national ID number. It was a reasonable architectural response to a real crisis. But the identifiers it generates carry implications that most users — and many engineers — have never examined closely.
CI and DI: the identifiers behind the curtain
The 본인인증 system produces two values when you verify your identity.
CI (연계정보, Connecting Information) is an 88-byte hash derived from your RRN through a one-way function managed by KISA, the Korea Internet & Security Agency. CI has one property that defines everything else about this system: it is the same value regardless of which platform triggered the verification. Verify on Naver, get a CI. Verify on Kakao, same CI. Verify on a tiny regional shopping mall, same CI. CI was designed specifically for cross-platform duplicate detection — one person maps to exactly one CI, making second accounts structurally impossible.
DI (중복가입확인정보, Duplicate Subscription Confirmation Information) is a per-service identifier, scoped to the individual platform. Conceptually, DI is the identifier that should prevent cross-platform correlation — it’s different for every service, so two platforms can’t compare DI values and learn they share a user. In practice, though, CI is what platforms actually store and rely on — DI exists in the specification, but CI is the identifier that runs the ecosystem.
This matters because CI is, by its nature, a universal correlatable identifier. If two platforms both hold your CI, they can confirm you’re the same person. Not through some sophisticated data-matching technique — just by comparing a single value. The cross-platform linkability is an intentional architectural property — it’s what makes the identity assurance model work.
How this compares to the global standard
OpenID Connect, the protocol behind “Sign in with Google” and most federated login on the English-speaking web, took the opposite approach. The OIDC spec defines something called a pairwise subject identifier — a sub value that’s unique per relying party. When you use Google to log into two different services, each service gets a different sub. They can’t correlate you. The protocol prevents it mathematically, not through policy or good behavior.
The pairwise sub is an elegant privacy mechanism, and it solves the linkability problem at the protocol level. But it solves only that problem. OIDC tells a platform that someone authenticated through an identity provider. It says nothing about whether that someone is a real person, whether they’re the only account that person holds, or whether they can be held legally accountable for their actions on the platform. A single person with five Gmail accounts appears as five distinct users to any OIDC relying party.
Korea looked at that tradeoff and decided it was unacceptable. For e-commerce dispute resolution, financial regulation, age-restricted content, and anti-fraud enforcement, platforms needed to know they were dealing with a real, singular, identifiable human. OIDC’s pseudonymous model simply doesn’t offer that. CI does.
The transparency gap that neither system closed
So we have two models. OIDC optimized for privacy through isolation — your identity stays fragmented across services, and that fragmentation is your protection. Korea’s 본인인증 optimized for accountability through correlation — your identity is unified across services, and that unification is your protection against fraud, abuse, and impersonation.
The engineering choices behind each system were defensible given their respective goals, and each solved real problems the other cannot. Where they converge is in what they left out: neither system ever found a way to tell the user what’s actually going on.
The OIDC consent screen is a good example. It lists the scopes a service is requesting — your email, your profile photo, maybe your calendar. What it never mentions is whether your sub is pairwise or public, what that distinction means for your ability to be tracked across services, or how the identity provider’s own data practices might undermine the protocol’s privacy guarantees. The strongest privacy feature in the system is completely invisible to the people it exists to protect.
The Korean 본인인증 consent flow has the same problem in reverse. A series of mandatory checkboxes, a wall of legal text that satisfies PIPA’s disclosure requirements, and an SMS verification prompt. What it never mentions is that the CI value generated during this process is universal — identical across every platform you’ve ever verified with — that multiple entities in the chain (your carrier, the intermediary, the platform) each handle your personally identifiable information with their own retention policies, and that your online activity is technically correlatable across the entire Korean internet through a single identifier you’ve never seen.
The root cause is the same in both cases: the identity architecture operates at a layer that consent screens were never designed to expose. OIDC hides a protection; 본인인증 hides a risk. Checking a box that says “I agree to the collection and use of personal information for identity verification purposes” is legal compliance. It is not informed consent — not when the architectural reality involves a universal correlator that the user has never heard of.
That gap between legal compliance and actual comprehension is where the real failure sits.
The missing layer
The EU is working on something ambitious with eIDAS 2.0 — a digital identity wallet that tries to combine government-grade assurance with selective disclosure, so you can prove you’re over 18 without revealing who you are, and do it without a universal correlator following you across services. W3C Verifiable Credentials and zero-knowledge proof research point toward a future where high-assurance identity verification and privacy isolation can coexist in the same protocol.
These are promising directions. But they’ll reproduce the same transparency deficit unless they’re built with a layer that neither OIDC nor 본인인증 ever included — one that makes the identity architecture itself visible and understandable to the person whose identity is at stake. Not a privacy policy. Not a consent checkbox. Something that can answer, at the moment of authentication: who just verified me, what identifier was generated, who received it, and can it follow me somewhere else.
The global identity ecosystem effectively split into two branches: the open web optimized for consent and interoperability, while Korea optimized for assurance and accountability. Each branch solved problems the other left open. But neither branch addressed transparency in any meaningful way — and that remains the gap most worth closing.
A detailed technical companion covering protocol-level analysis and regulatory context will be published separately.