November 18, 2012 5:01 PM

Several years have already passed since debate on the My Number system began, and a change of government has arrived without the bill being enacted. Looking back, the discussion was constrained too heavily by existing systems from the outset and became distorted. This is therefore a good opportunity to pause and reconsider it.

In fiscal 2011, I struggled from inside as a member of the Information-Sharing Platform Technical Committee. After observing from a distance for nearly 1 years, I would like to organize my thoughts again.

1. Establish Robust Objectives

Creating a number system is merely a means. What truly matters is how government administration should change amid unprecedented population aging and a declining workforce. For example:

  • Halve the cost of administrative procedures
  • Halve private-sector costs of dealing with government
  • Make administrative procedures real-time in principle, and complete them within 24 hours at the latest

2. Start from New Ideas, Unconstrained by Existing Systems

Set aside Supreme Court rulings and current systems and procedures for the moment. Consider how the system would be built from scratch today, then devise the steps for reaching that design.

3. Recognize That Identity Management Is the Foundation of Everything

Ultimately, every system consists only of identifying resources such as people, objects, and information, and transferring, processing, and storing them. The foundation is therefore identifying and managing people, objects, and information: identity management.

4. Specific Systems

What would a concrete system design look like with 1 through 3 above in mind?

4.1 Citizen Core Identity System

A person’s Core Identity means attributes unchanged since birth. Specifically:

  • Primary key (4 bytes)
  • Name at birth (128)
  • Date of birth (8)
  • Sex at birth (2)
  • Place of birth (8)
  • Nationality at birth (2)
  • Registration date and time (3)

First, generate from the family-register database a database containing only these items. Until family registers are abolished, record a person in the Citizen Core Identity Register simultaneously with registration of birth in the family register, or foreign-resident registration for a foreign national. The database key is an automatically generated, immutable number that is never used outside the database: a so-called invisible number.

Records in this database are never deleted.

Initially, this database contains at most 100 million3,000 people. It grows by about 1 million people annually; even over 100 years, that adds only 100 million people. At 1 record of 152 bytes, after 100 years, even if it reaches 200 million5,000 records, it remains a small, append-only database of only tens of GB including indexes.

4.2 Removed-Persons Database

A database recording people who no longer exist due to death or other reasons. This too is basically append-only.

  • Primary key
  • Citizen Core Identity Register primary key
  • Date of removal

4.3 Number Conversion Service

A system that converts one sector-specific number into another.
 
Build the other systems with loose coupling around the 3 systems above.
For the time being, every system should provide a RESTful interface.

4.4 Resident-Service Attribute Database

Next, use this foundation to create a resident-attribute database managing the following attributes. In practice it would likely comprise multiple related tables; only the fields are listed here.

Current Name Table

Basically append-only.

  • Primary key
  • Citizen Core Identity Register primary key
  • Basic Resident Register number
  • Family name
  • Given name
  • Other names
  • Update date
Contact Table
  • Primary key
  • Basic Resident Register number
  • Contact type (registered address, residence, telephone number, email address, etc.)
  • Contact information
  • Confidence level (1 = self-reported; 2 = delivery verified)
  • Date and time of last delivery verification
  • Update date

Designated Account Table

  • Primary key
  • Basic Resident Register number
  • Account number
  • Update date
Family Relationship Register
  • Primary key
  • Subject’s Basic Resident Register number
  • Relationship
  • Family member’s Basic Resident Register number

4.5 Tax System

Receive withholding data with taxpayer numbers from withholding agents, calculate and pre-fill tax amounts, and after confirmation by the person, debit or credit the designated account in the resident-service system. Abolish year-end adjustment to reduce private-sector burdens, so transactions will generally be deposits into the designated account.

4.6 Social Security System

Use tax-system data to identify eligible persons and deposit funds into their designated accounts.

4.7 Health Insurance System

Omitted

4.8 Pension System

Omitted

4.9 Medical Information System

Introduce a primary-care physician system. Consolidate each person’s medical information in the system provided by their primary-care physician, probably using a private cloud service. Encrypt medical information with an encryption key, and store that key encrypted with the public keys of the person, the responsible hospital, and an independent body. In principle, without the person’s private key, the hospital cannot view information other than records of care it provided.

Define as standards the APIs private cloud services must provide.

Publish assessment criteria and certify services.

4.10 Resident Authentication System

Manage credentials residents use for system access.

  • Primary key
  • Resident authentication number
  • IdP identifier
  • User-local identifier
  • Credential used for registration
  • Validity flag
  • Last update date

5 Network

Use the Internet for all networking. Encrypt every communication with algorithms considered secure at the time.

6 Identity-Proofing System

Omitted