Is the information sharing infrastructure of the "number" system complex?

In the context of the National ID System, the "Number" System (sometimes mistakenly called the Common Number System), there is a system infrastructure called the "Information Collaboration Infrastructure." The diagram below (from the Interim Report of the Cabinet Secretariat Information Collaboration Infrastructure Technology Working Group) shows the following:Orange boxThat is it.

It seems that this part has a bad reputation among "experts" in various fields, who say things like it's "complicated and strange," "it doesn't work," and "it only benefits vendors."

In reality, having such a mechanism is essential from a privacy and security standpoint, and the reasons for this are documented in endless reports and minutes, but from my perspective, it's not even "complicated" in the first place (as long as you're careful about how you do it), so I'd like to write about that first.

Is the Internet a complicated, strange, inoperable system?

So, here's the question.

If you are reading this article right now, do you think the Internet is a complicated, strange, and inoperable system?

Of course not. The fact that you are reading this article is proof enough.

Let me briefly list out the steps it takes to read this article.

1. Specify the "number" of this article (e.g., by clicking on the link to the article) (http://www.sakimura.org/2011/08/1223/).
2. The browser resolves this into http, www.sakimura.org (where the information is retrieved), and /2011/08/1223/ (the number of this article at the destination).
3. Query the DNS for www.sakimura.org and convert it to an IP address.
4. Start communication with port 80 of this IP address as the destination
5. (The following is about routing, conversion of IP addresses to MAC addresses at the destination router, etc.)
6. Once communication is established, send a command such as GET /2011/08/1223 HTTP/1.1.
7. The HTML source of this page is returned.
8. The browser parses this HTML source and, if any images or other elements have been inserted, retrieves them through the same process as above.
9. The obtained results are evaluated and displayed.

Well, to put it very simply, it's something like this.

In contrast, if we were to write about what the information sharing platform does at a similar level, it would look something like this (the following is the "access token method" of the two methods being considered).

1. Specify the address of the individual you want to obtain information about (Code A) and the information you want.
2. The combination of "Code A" and the desired information is queried from the "information sharing platform," and the "information source" and "intermediate address A" corresponding to "Code A" are obtained.
3. Send "intermediate address A" to "information source."
4. The "information source" queries the "information sharing platform" for "intermediate address A" to obtain "code B" and the "list of desired information."
5. The "information source" creates the "desired information" corresponding to "code B" and returns it.

What is so complicated and strange about this?

Furthermore, if you are an engineer who is familiar with the latest web technologies, you will already be wearing it comfortably.
"Oh, this is the same process as OAuth 2.0."

OAuth 2.0 is an information sharing technology that is currently being standardized by the IETF, and is expected to become the mainstream in the world. Calling this protocol, which is famous for being "simple," "clear," and "easy," "complicated and mysterious" calls into question common sense.

By the way, if you were to translate the above into OAuth 2.0 terms, it would be like this:

1. Specify the "resource" and "scope" for which you want to obtain information.
2. An “authorization server” is queried for access authorization for the “resource” and “scope”, and an “access token” corresponding to the “resource” and “scope” is obtained.
3. Send the “access token” to the “resource”.
4. The "resource" queries the "authorization server" for the "access token" and obtains the "list of information that should actually be returned."¹.
5. The "resource" creates the "information to be returned" and returns it.

Almost the same, right? In fact, I think this mechanism can be implemented with OAuth 2.0.² .

Some people may say, "No, that's not true. Unlike private systems, this is an ultra-large-scale system that will cover 1 million people!" To that, I would like to respond as follows.

"Google has 2 million people and Facebook has 6 million people running these systems. 1 million is not a particularly large system. And when it comes to transaction volume, it's a pittance compared to a national system."

So, here's the conclusion.

The "information sharing platform" shown in Figure 1 is not a "complex and mysterious" or "inoperable" system. Rather, it is technically a "simple," "clear," and "simple" system.Possible.

Hmm, "possible"?

That's right. The Information Collaboration Platform Technology Working Group has only defined requirements/policies, but has not mentioned any specific designs. (It probably shouldn't be mentioned at this stage.) There is more than one way to do anything. You can do it simply like OAuth2.0, or you can come up with a truly "complex and bizarre" implementation design. What you should do is to keep an eye out to avoid the latter, not to scream "complex and bizarre" based on your impression of Figure 1.

1. An implementation might choose to encode the returned information in the access token so that the resource can parse it itself.
2. An identity layer will be needed, including a Pairwise Pseudonymous Identifier (PPID) for people, so in reality, you will probably end up using the OpenID Connect part as well.