In discussions of a national ID system—the “Number” system, sometimes incorrectly called the Common Number system—one system component is called the “information-sharing platform.” It is the orange box in the diagram below, taken from the interim report of the Cabinet Secretariat’s Information-Sharing Platform Technology Working Group.

This component seems to have a poor reputation among various fields’ “experts,” who call it “byzantine,” say it “will not work,” or claim it “only benefits vendors.”
In reality, such a mechanism is essential for privacy and security, and the reasons are recorded at length in reports and minutes. My view, however, is that—provided the implementation is handled carefully—it is not even “complex” in the first place. I would like to begin there.
Is the Internet a Byzantine System That Does Not Work?
Here is a question.
You are reading this article right now. Do you think the Internet is a byzantine system that does not work?
Of course not. The fact that you can read this article is the best proof.
Let us list the steps occurring when you view this article.
- By following a link, you obtain this article’s “number”, namely http://www.sakimura.org/2011/08/1223/)を指定する。
- The browser separates it into http; www.sakimura.org, the source of the information; and /2011/08/1223/, the article’s number at that source.
- The browser queries DNS for www.sakimura.org and converts it to an IP address.
- It begins communicating with port 80 of that IP address as the destination.
- (Then come routing, conversion of the IP address to a MAC address at the destination router, and various other steps.)
- Once communication is established, it sends a command such as GET /2011/08/1223 HTTP/1.1.
- The HTML source of the page is returned.
- The browser parses the HTML source and, if it contains images or other inserted resources, retrieves them through the same process.
- It evaluates and displays the retrieved result.
That is a greatly simplified account.
Described at the same level, the information-sharing platform works as follows. This is the “access-token method,” one of 2 methods under consideration.
- Specify the address of the person whose information is sought, “Identifier A,” and the desired information.
- Query the information-sharing platform with the combination of “Identifier A” and the desired information, and obtain the “information source” and “Intermediate Address A” corresponding to “Identifier A.”
- Send “Intermediate Address A” to the “information source.”
- The “information source” queries the information-sharing platform with “Intermediate Address A” and obtains “Identifier B” and the “list of desired information.”
- The “information source” creates the “desired information” corresponding to “Identifier B” and returns it.
What part of this is byzantine?
Moreover, if you are an engineer familiar with recent Web technology, this should already have clicked:
“Oh, this is the same flow as OAuth 2.0.”
OAuth 2.0 is an information-sharing technology currently being standardized at the IETF and is expected to become the global mainstream. Calling this protocol, renowned for being simple, clear, and easy, “byzantine” would call one’s judgment into question.
Translated into OAuth 2.0 terminology, the steps above become:
- Specify the “resource” and “scope” desired.
- Query the “authorization server” for authorization to access the “resource” and “scope,” and obtain the “access token” corresponding to them.
- Send the “access token” to the “resource.”
- The “resource” queries the “authorization server” with the “access token” and obtains a “list of information actually to be returned”1.
- The “resource” creates and returns the “information to be returned.”
Almost identical, is it not? In fact, I believe this mechanism can be implemented with OAuth 2.02.
Some may say, “No, that is wrong. Unlike a private system, this is an enormous system covering 100 million2,000 people!” My answer is:
“Systems like this serve 200 million people at Google and 600 million at Facebook. 100 million2,000 people is not a particularly large system. As for transaction volume, a national system’s volume is trivial.”
So here is the conclusion.
The “information-sharing platform” shown in Figure 1 is neither “byzantine” nor a system that “will not work.” Technically, it can be easy, clear, and simple.
Wait, “can be”?
Yes. The Information-Sharing Platform Technology Working Group defines only requirements and policies; it says nothing about the specific design, nor should it at this stage. There is never only one way to do something. It could be implemented simply like OAuth 2.0, or designed in an utterly byzantine way. What we should do is watch closely to prevent the latter, not look at Figure 1 and shout “byzantine.”
Footnotes
- Depending on the implementation, the information to return might be encoded within the access token so the resource can parse it itself.
- An identity layer is required, including Pairwise Pseudonymous Identifiers (PPIDs) for people, so in practice the OpenID Connect portion would probably also be used.
Related posts

【Breaking News】The Future of Digital ID Is Changing! OpenID Foundation Responds to Regulation and Market Competition with a Third-Party Certification Service!
The OpenID Foundation, which establishes international standards for digital identity, has announced that it will launch a new certification service in 2026, during the 2nd quarter!…

IETF 123: OAuth WG Session 2 Summary (Japan Time, the 25th)
Quite some time has passed, and my memory is already hazy... Below, I will see whether I can remember it while rewriting the summary that NotebookLM…

IETF 123: OAuth WG Session 1 Summary (Japan Time, Day 24)
Overview On July 24 Japan time, OAuth WG Session 123 at IETF 1 Madrid was held. The previously announced agenda was as follows, but a session…

You must be logged in to post a comment.