Electronic authentication system and electronic authentication method

Abstract

This electronic authentication system comprises: an ID provider which issues a digital ID to a user after confirming the identity of the user; a first authentication authority which issues a first electronic certificate to the user; and a second authentication authority which issues a second electronic certificate to the user, wherein the first authentication authority and the second authentication authority combine the same digital ID issued to the user by the ID provider into the first electronic certificate and the second electronic certificate.

Description

Electronic authentication system and electronic authentication method

[0001] The present invention relates to trust services.

[0002] In order to realize sound electronic transactions, trust services based on rules and guidelines such as the eIDAS rule and NIST SP800-63 are accelerating.

[0003] The assurance level of an entire service is determined by the respective assurance levels of the "trust service provider," "identity verification," and "personal authentication." For example, legally compliant transactions require person authentication using a high-assurance digital certificate. On the other hand, strict person authentication involves the use of personal information, which creates a trade-off with privacy. Therefore, it is desirable to be able to use digital certificates that meet the appropriate assurance level and legal requirements for each service. However, there are issues with usability, such as the inability to link services across multiple digital certificates and the complicated management process. Furthermore, differences in legal regulations and person authentication methods between countries make it difficult to realize cross-border trust services.

[0004] Therefore, an object of the present invention is to provide a trust service model that can accommodate various assurance levels.

[0005] To achieve the above object, the present invention provides an electronic authentication system comprising an ID provider that issues a digital ID to a user after verifying the user's identity, a first certification authority that issues a first digital certificate to the user, and a second certification authority that issues a second digital certificate to the user, wherein the first certification authority and the second certification authority link the first digital certificate and the second digital certificate to the same digital ID issued to the user by the ID provider, thereby enabling certificate switching and flexible inter-service collaboration.

[0006] The present invention can be understood as an electronic authentication system, an electronic authentication method, an electronic authentication program, and a recording medium non-temporarily storing an electronic authentication program that uses an electronic certificate linked to a digital ID. The present invention can also be understood as a system, method, program, and program-storing recording medium for issuing or managing digital IDs and / or electronic certificates. The present invention can also be understood as a storage medium that stores a digital ID and an electronic certificate linked thereto, or an information terminal equipped with such a storage medium. The information terminal may be any device equipped with a processor and a storage medium, and examples include computers, smartphones, tablet terminals, game consoles, IC cards, smartwatches, and smart glasses. The present invention can also be understood as a service provision system, method, program, and programmable recording medium that provides trust services that can be used using a digital ID and an electronic certificate linked thereto.

[0007] According to the present invention, it is possible to provide a trust service model that can accommodate various assurance levels.

[0008] FIG. 1 is a diagram showing the elements that make up a trust service and their assurance levels. FIG. 2 is a diagram showing the configuration of a trust service model according to an embodiment of the present invention. FIG. 3 is a diagram showing a use case of the proposed model. FIG. 4 is a diagram showing an implementation example of the proposed model. FIG. 5 is a diagram showing the schematic configuration of an electronic authentication system that implements the proposed model. FIG. 6 is a diagram showing examples of three types of certification authorities and electronic certificates issued by each certification authority. FIG. 7 is a diagram showing an example of the configuration of an electronic authentication system. FIG. 8 is a diagram showing an example of the configuration of an electronic authentication system. FIG. 9 is a diagram showing an example of the configuration of an electronic authentication system. FIG. 10 is a diagram showing an example of the configuration of an electronic authentication system. FIG. 11 is a diagram showing an example of the process of issuing an electronic certificate. FIG. 12 is a diagram showing an example of the process of reissuing an electronic certificate. FIG. 13 is a diagram showing an example of the process of updating an electronic certificate. FIG. 14A is a diagram showing an example of the process of issuing an electronic certificate. FIG. 14B is a diagram showing an example of the process of issuing an electronic certificate. FIG. 15 is a diagram showing an example of the process of reissuing an electronic certificate. FIG. 16 is a diagram showing an example of the process of reissuing an electronic certificate. FIG. 17 is a diagram showing an example of the process of issuing an electronic certificate. FIG. 18A is a diagram showing an example of the process of linking a digital ID to an existing electronic certificate after the fact. FIG. 18B is a diagram showing an example of processing for linking a digital ID to an existing electronic certificate after the fact. FIG. 19 is a diagram showing an example of processing for user registration for a service that requires identity verification. FIG. 20 is a diagram showing an example of a user registration screen for a service that requires identity verification. FIG. 21 is a diagram showing an example of processing for user registration for a service that can be used anonymously. FIG. 22 is a diagram showing an example of a user registration screen for a service that can be used anonymously. FIG. 23 is a diagram showing an example of login processing. FIG. 24 is a diagram showing an example of processing for linking a digital ID to an existing login ID after the fact. FIG. 25 is a diagram showing an example of inter-service collaboration via a data collaboration platform. FIG. 26 is a diagram showing an example of direct inter-service collaboration.

[0009] With the spread of the internet and the recent increase in face-to-face transactions due to the COVID-19 pandemic, there has been a growing demand for electronic procedures and services. To ensure the soundness of these electronic procedures, rules and guidelines such as the eIDAS Regulation (No. 910 / 2014) in the EU, NIST SP800-63 in the US, and the Identification Management Standard in New Zealand have been established, and trust services that comply with these have been developed.

[0010] Individuals who use electronic transactions or services under a trust service often require a digital ID and a digital certificate. Digital IDs are used to verify personal and attribute information online, and digital certificates are used as elements for authenticating the individual online. In this specification, a digital ID is a digital representation of known information about a specific individual or organization. A digital ID may include not only a name but also various additional information such as identifiers and attribute information.

[0011] The level of legal backing and the services available to certificate authorities vary depending on their classification, requiring different types of certificates depending on the service and intended use. For example, the criteria for electronic certificates that can be used with the National Tax Electronic Filing and Payment System (e-Tax) state that "electronic certificates issued by a certification authority that has been certified for specific certification services under the Electronic Signature Act and is mutually certified with a bridge certification authority of the Government PKI (GPKI) system and confirmed to be usable with e-Tax" are required. Furthermore, laws such as the Act on Prevention of Transfer of Criminal Proceeds, the Secondhand Goods Dealers Act, and the Mobile Phone Fraud Prevention Act specifically specify the types of electronic certificates that can be used as a method of identity verification. Services subject to strict legal restrictions, such as administrative procedures, require legally backed electronic certificates.

[0012] On the other hand, some certification authorities include personal information in the digital certificates they issue, and in cases like the one mentioned above where the number of available digital certificates is limited, personal information is inevitably disclosed to the public or recipient. In other words, there is a trade-off between ensuring identity and privacy. It is conceivable that there will be services that do not require this stored information, and it would be desirable for each individual to manage multiple digital certificates and use digital certificates that meet the assurance level and appropriate legal requirements appropriate to the service.

[0013] However, even if an individual possesses multiple digital certificates, there is no guarantee that those digital certificates belong to the same person. This has led to problems in usability, such as the inability to link services across digital certificates and the complexity of management.

[0014] Furthermore, given the differences in legal regulations between countries, it is difficult to realize a trust service that spans borders. More specifically, when exchanging purchase orders with overseas business partners, there may be cases where the trust service in one country does not comply with the legal regulations that the business partner must abide by, or where it is necessary to comply with legal regulations that are stricter than the home country's. Therefore, possible solutions include using a common trust service with many restrictions that complies with multiple legal regulations, or dealing with each country individually. However, the former is undesirable from a privacy perspective, and the latter could complicate the service configuration. There is a need for a trust service model that can flexibly adapt to differences in legal regulations between countries without complicating the service.

[0015] Therefore, the inventors propose a trust service model that can accommodate various assurance levels by defining service components in a customizable manner. Specifically, by issuing a digital ID to a user and multiple electronic certificates with different assurance levels linked to the ID, it becomes possible to switch between certificates and flexibly link between services. When issuing a digital ID, as a general rule, eKYC (electronic Know Your Customer), which has a high assurance level, is performed, enabling strict linking of the digital ID and the electronic certificate.

[0016] In addition, by incorporating passport-based eKYC into this model, it becomes possible to verify the identity of people who do not reside in the country where the service is provided and issue digital IDs to them. This enables identity verification for a wider range of users, making it possible to provide services to people who reside abroad, such as inbound tourists. In this invention, the identity of the user is guaranteed by incorporating the digital ID into the electronic certificate, and there are no restrictions on identity verification related to issuance or the information contained in the electronic certificate. By selecting an identity verification method and certification authority that suits the characteristics of the user, it is possible to comply with various domestic and international laws and regulations and adjust the level of assurance. The present invention has the following advantages.

[0017] 1. Expanding the use of digital IDs: We propose a trust service model that allows digital IDs to be linked to multiple digital certificates. This model allows users to enjoy a variety of services, including those that are highly regulated, such as administrative procedures, by managing only one digital ID. Furthermore, the management costs of digital IDs are also low because only this single ID needs to be managed.

[0018] 2. Flexible support for various assurance levels: The proposed model allows for the use of multiple digital certificates to support various assurance levels with a single digital ID, which we believe benefits both service users and trust service providers. First, service users can select a digital certificate for each service they use. For example, if a method such as an administrative procedure is specified, they can use a legally compliant digital certificate. If no certification authority or storage information is specified, they can use a digital certificate that does not contain personal information in consideration of privacy. To enable service users to use various assurance levels, it is desirable for a wide range of trust service providers to enter the market. Our proposal ensures user identity by incorporating digital IDs, which reduces the cost for service providers. Furthermore, service deployment can potentially lead to service integration with other fields, which we believe benefits service providers as well.

[0019] 3. Consideration of a service model for overseas residents: The proposed model is premised on high-level identity verification, but it can also support identity verification using trust anchors unique to Japan, such as the My Number Card, as well as trust anchors unique to other countries. In the embodiment of the present invention described below, an example of an eKYC use case using a passport will be described.

[0020] <Trust Framework and Current Status> The elements that make up the trust service are shown in Figure 1. The trust assurance levels are defined as three levels: Identity Assurance Level (IAL), Authentication Assurance Level (AAL), and Trust Service Assurance Level (TAL).

[0021] (1) Identity Assurance Level (IAL) Identity verification refers to proving or confirming that the user's registered name, address, date of birth, etc. are correct. For example, in Japan, My Number cards and health insurance cards are used for identity verification, while passports are used overseas. Regulations and guidelines such as the eIDAS Regulation and NIST SP800-63 classify the strictness of identity verification into levels called IALs. For example, as shown in Table 1, NIST SP800-63 classifies assurance levels into three levels, with Level 1 being the lowest IAL and Level 3 being the highest IAL, where a declaration using an email address is verified in person by a qualified person. Furthermore, at higher assurance levels, the use of official identification is implicitly required. Because official identification is generally provided by the issuing country to its citizens, a high IAL method for verifying the identity of temporary visitors from abroad, such as inbound tourists, presents a challenge.

[0022]

[0023] (1.1) Identity verification procedures using eKYC in Japan In Japan, amendments to the Enforcement Regulations of the Act on Prevention of Transfer of Criminal Proceeds were implemented in November 2018, and identity verification using eKYC as described below was newly approved.

[0024] Article 6, Paragraph 1, Item 1, Ho: Sending an image of the identification document + sending an image of the person's appearance (using an internet video call function is also permitted). Article 6, Paragraph 1, Item 1, Ho: Sending the IC chip information from the identification document + sending an image of the person's appearance. Article 6, Paragraph 1, Item 1, To (1): Used for inquiries to banks, etc. The customer sends an image of the identification document or IC chip information to the business, which then inquires about the customer's information from the bank, etc. Article 6, Paragraph 1, Item 1, To (2): Used for small transfers to an account in the customer's name. The customer sends an image of the identification document or IC chip information to the business, and the business makes a small transfer to the account in the customer's name. The customer then sends an image of the transaction details screen on their internet banking.

[0025] Since identity verification by implementing the eKYC is a remote verification of identification attributes, the IAL is positioned at Level 2 based on the definition in NIST SP800-63.

[0026] (1.2) Passports as a Means of Identification Passport standards are established by the International Civil Aviation Organization (ICAO), and the specifications are published in Doc 9303 Machine Readable Travel Documents.

[0027] Passports with an IC chip are called ePassports, and in addition to storing data linked to the passport holder, various security mechanisms are incorporated. Specifically, information such as the passport number, date of birth, gender, expiration date, nationality, name, and facial image is stored. Furthermore, a DS certificate issued by the certification authority Document Signer (DS) is stored. This electronic certificate is used to detect data tampering in the passport. DS acts as an intermediate certification authority, and a root certification authority called Country Signing Certification Authority (CSCA) is a member of ICAO, with one in each country that issues ePassports. These electronic certificates are managed and operated by a repository called ICAO PKD to authenticate ePassports across borders, and the information necessary for authentication is exchanged between countries.

[0028] The ePassports currently issued in Japan incorporate three security mechanisms: Basic Access Control (BAC), Passive Authentication (PA), and Active Authentication (AA). The roles of these security mechanisms are as follows:

[0029] BAC: A security mechanism to prevent skimming and misuse, which performs mutual authentication between the passport and the inspection system and shares a session key. After the session key is shared by BAC, encrypted communication is performed between the IC chip and the inspection terminal, making it possible to access various data on the IC chip.

[0030] PA: A security mechanism for verifying that the data stored in the passport's IC chip has not been tampered with. This verification involves verifying the digital signature of the data stored in the passport, signed with the private key of the DS, and verifying the hash value of the data stored in the passport.

[0031] AA: Passport authentication is performed by signing the challenge sent from the inspection system with a private key stored in an unreadable area called secure memory in the passport. Even if a copy of the data in the IC chip is made, the private key in the secure memory cannot be copied, so passport cloning can be detected by using AA.

[0032] IAL, which involves verifying identity using a passport, is classified as Level 3 for face-to-face verification and Level 2 for online verification.

[0033] (2) Authentication Assurance Level (AAL) Authentication refers to verifying that a person is performing a task by verifying credentials related to either "biometrics," "possession," or "knowledge." Similar to identity verification, authentication is also classified into levels as AALs, and NIST SP800-63 classifies it into three levels according to the storage location and type of credentials, as shown in Table 2.

[0034]

[0035] Identity authentication can use credential elements such as fingerprints, digital certificates, and passwords, either individually or in combination. For example, authentication using a password alone is based solely on "knowledge," making it the lowest AAL at level 1, while authentication using a digital certificate stored in tamper-resistant hardware combined with a fingerprint is a two-factor authentication that combines "possession" and "biometrics," making it the highest AAL at level 3. Credentials issued by trust service providers are generally used, but there is an issue that these credentials cannot be used with other services.

[0036] (3) Trust Service Assurance Level (TAL) Trust service providers provide services such as ID providers, cloud signatures, certification authorities, and timestamp authorities, and create, verify, and validate certificates related to these services. The standards for assessing their reliability and the nature of conformity assessments must be developed with an eye toward international compatibility, and a working group organized by the Digital Agency has been studying them. TAL is organized as a service provider's operational policy, and its requirements include organizational, facility, technical, key management, operational, and audit requirements. Similar to IAL and AAL, three levels are envisioned, and classification by certification body is proposed as shown in Table 3.

[0037]

[0038] There are two challenges with TAL. The first is that, similar to the credential management required for identity authentication mentioned above, digital certificates are issued by trust service providers and must be managed individually. This poses problems in terms of convenience, such as the inability to deploy services that span digital certificates and the complexity of managing digital certificates. The second is that digital certificates issued by trust service providers involve a trade-off between the strength of their assurance level and privacy. Specifically, while digital certificates with strong legal backing can be applied to a wide range of services, there are cases in which digital certificates that do not contain personal information are preferred from a privacy perspective because they contain personal information.

[0039] (3.1) Classification of Certification Services in Japan Certification services are services that certify that the items used to confirm that the user has made an electronic signature (in the case of an electronic signature based on public key cryptography, this refers to the public key recorded in the electronic certificate, etc.) belong to the user. Under the Electronic Signature Act, certification services that meet certain standards can be certified by the Prime Minister and the Minister of Justice. Specifically, certification services can be classified as follows depending on their certification status:

[0040] ・General authentication service: Authentication service that uses electronic signatures that is not related to the Electronic Signature Act. ・Certification service under the Electronic Signature Act: Authentication service that meets the requirement of the Electronic Signature Act, which is that it is an authentication service that proves that an electronic signature is related to the user. ・Specific authentication service: Authentication service that meets the following two requirements stipulated in the Electronic Signature Act. (a) It is an authentication service that proves that an electronic signature is related to the user. (b) It is an authentication service that uses an electronic signature that meets the technical standards (encryption method). ・Accredited authentication service: In addition to the requirements of specific authentication services, it is an authentication service that has been reviewed and certified by the government (Digital Agency and Ministry of Justice). More specifically, specific authentication services that have been reviewed and certified regarding the requirements for authentication equipment, user identity verification methods, and other business methods are called certified authentication services.

[0041] Furthermore, among the above classifications, specific authentication services and accredited authentication services have stronger legal backing than general authentication services and authentication services under the Electronic Signature Act, with accredited authentication services being the authentication services with the strongest legal backing. More specifically, the certificate issuance policy for accredited authentication services is classified as TAL Level 3, while the certificate issuance policy for specific authentication services is classified as TAL Level 2 or Level 1.

[0042] <Configuration of the Trust Service Model According to This Proposal> The configuration of the trust service model according to the embodiment of the present invention is shown in Figure 2. This model is designed so that the service components can be appropriately replaced at the granularity of identity verification, person authentication, and trust service, and this high level of customizability makes it possible to support any desired assurance level.

[0043] (1) Identity Verification The proposed model of this embodiment employs two types of identity verification methods to achieve a high IAL. The first is eKYC, which uses the My Number card issued by Japan to its citizens. The second is eKYC, which uses a passport issued universally. The former is a method for users who reside in Japan, while the latter is a method for users who do not reside in Japan, such as inbound tourists.

[0044] (1.1) eKYC using My Number Card In eKYC using My Number Card, in accordance with Article 6, Paragraph 1, Item 1 (wa) of the Enforcement Regulations of the Act on Prevention of Transfer of Criminal Proceeds, the digital signature certificate and four basic pieces of information included in the My Number Card, along with the user's facial photograph, are sent to a certified certification authority. The certified certification authority then verifies the validity of the certificate via J-LIS and manually verifies that the personal information and facial photograph are correct. If there are no problems with the identity verification results, a digital certificate is issued to the user.

[0045] (1.2) eKYC using a Passport With eKYC using a passport, the user sends the passport's IC chip information to the service provider, along with an image of the user's appearance. The information in the IC chip is verified using the various security mechanisms (BAC, PA, AA) and ICAO PKD mentioned above. Specifically, the DS certificate stored in the passport is verified using the CSCA certification authority's public key, and then the passport's security mechanisms, PA and AA, verify that the data has not been tampered with or cloned. As with the procedure when using a My Number card, the certification authority performs this series of eKYC procedures on behalf of the user, and if the results are satisfactory, an electronic certificate is issued to the user.

[0046] (2) User Authentication: User authentication in the proposed model achieves a higher-level AAL by using a digital certificate stored in the smartphone's secure element. Furthermore, by linking digital certificates to digital IDs, it becomes possible to authenticate users across multiple digital certificates. That is, by verifying digital certificates using a PKI (Public Key Infrastructure) of a certification authority (CA), and then using the verification results in various other services, user authentication is achieved independently of the service provider. A method using a passport-issued digital certificate instead of a digital certificate issued by a certification authority (CA) is also possible. In this case, after performing public key verification and data tampering detection similar to the passport-based eKYC described above, a copy of the DS certificate is stored in the smartphone's secure element. This DS certificate is used as the digital certificate for user authentication. In the case of a passport-based DS certificate, it is desirable to ensure security by taking into account the security requirements of the service and complying with the passport's standard specifications. When using these digital certificates, they may also be implemented in combination with user "knowledge" authentication, such as a password or PIN code.

[0047] (3) Trust Service The proposed model's trust service employs multiple different TAL certification authorities, such as certified certification authorities and designated certification authorities, to issue the aforementioned digital certificates. Users can select the appropriate level of assurance and privacy by using digital certificates issued by these certification authorities. Specifically, digital certificates issued by certified certification authorities can be used for services that utilize personal information by including not only a digital ID but also personal information such as the four basic pieces of information obtained through eKYC. Digital certificates issued by designated certification authorities are designed to ensure privacy by including only a digital ID, and can be used for a wide range of general services. In this case, the same organization operates these certification authorities and assigns a common digital ID to each user of the digital certificate, thereby enabling user identification across the aforementioned multiple digital certificates.

[0048] <Example use cases of the proposed model> Two example use cases of the proposed model are described below. As shown in Figure 3, both use cases have the advantage of being able to conduct identity verification and some of the services online. Specifically, due to the nature of online procedures, which do not restrict the location of the procedures, service users can complete some of the procedures from home. Furthermore, by making the procedures that can be conducted online multilingually, service users can complete the procedures in their native language and it is thought that this will also reduce the psychological burden on users.

[0049] (1) Use Cases in Tourism Services The proposed model is suitable for use in tourism services, as it is expected to be used by inbound tourists. For example, the digital ID issued by this model can be used for registering and using services such as bicycle rentals. If a bicycle rental service is developed that utilizes smartphone-based digital IDs and allows users to complete the procedure simply by holding the smartphone over the bicycle, the intuitive operation makes it easy for inbound tourists to complete the procedure without language barriers. Furthermore, by linking the bicycle's location information, it is possible to record the movement history during the time the bicycle was used and measure the calories burned. These records can be used as a record of the travels of inbound tourists, and can also be used as health data for people who live in the area and regularly use rental bicycles.

[0050] (2) Use Cases in Payment Services The proposed model is designed to accommodate various levels of guarantee, making it suitable for payment services requiring a high level of guarantee. Linking the digital ID issued by the proposed model to payment services and managing purchase history is expected to automate the cumbersome tax-free procedures performed by inbound tourists. While the electronic tax-free sales process itself began in October 2021, tourists are still required to present their physical passports, and not all procedures have been digitized. By using the proposed model, tax-free procedures may be possible with just a smartphone in the future.

[0051] (3) Challenges for realizing the use case Popularization of ICAO passports: According to data published by ICAO PKD, there are currently 88 countries that are members of ICAO PKD and issue IC passports. Although the number of countries participating in ICAO PKD is increasing every year, there are still several countries that are not members or that do not issue ICAO passports. Therefore, one of the challenges for the future is to consider how to deal with service users from countries that are not members of ICAO PKD or that only issue paper passports.

[0052] Differences in passport reliability by country: The eKYC proposed by the inventors does not require different procedures depending on the country, as long as the user has a passport. However, just as Active Authentication is an optional feature among the security mechanisms built into ePassports, the adoption of various optional features varies from country to country, and therefore the security of the passport is likely to differ depending on the choice of feature. Furthermore, since passport reliability differs significantly from country to country, one future challenge is to consider the need to introduce additional procedures when reliability and security mechanisms fall below a certain level, taking into account differences in passport approaches and reliability between countries.

[0053] <Implementation example> An implementation example of the proposed model is shown in Figure 4. Figure 4 shows an example of granting a digital ID through the implementation of the My Digital Certificate Service by a certified certification authority and eKYC using a My Number card. Users can enjoy various trust services using the digital ID on their smartphone.

[0054] <Electronic Authentication System> Figure 5 shows the schematic configuration of an electronic authentication system that implements this proposed model. The electronic authentication system 1 is a system that issues and verifies electronic certificates, and has as its main elements an ID provider 20 and multiple certificate authorities 30.

[0055] The ID provider 20 is responsible for verifying the identity of users via eKYC and issuing and managing digital IDs. Digital IDs are unique identification information assigned to users (including individuals and organizations). For example, a digital ID may be composed of a string of characters (a combination of numbers, letters, symbols, etc.) of about 10 to 10 digits. While the format and content of a digital ID may be freely designed, it is preferable that the digital ID alone cannot identify an individual user. In this proposed model, the digital ID is only required to indicate that multiple electronic certificates have been issued to the same user; it does not require the ability to identify individuals, such as "who issued them." By ensuring that the digital ID alone cannot identify an individual user, the use of the digital ID alone can be separated from privacy concerns and personal information handling issues, simplifying the operation of the electronic authentication system 1.

[0056] The certification authority 30 is an element responsible for issuing, verifying, and managing digital certificates. It is preferable that the certification authority 30 be composed of multiple certification authorities 30, 30 that issue digital certificates with different assurance levels (TALs). The example in FIG. 5 shows a first certification authority 30 that issues a first digital certificate and a second certification authority 30 that issues a second digital certificate with a lower assurance level than the first digital certificate. However, the number of certification authorities 30 is not limited to two; three or more certification authorities 30 may be provided. When using a digital service, a user can select which of multiple digital certificates issued by the electronic authentication system 1 to use. For example, the user can use different digital certificates depending on the assurance level required by the digital service. FIG. 5 shows an example in which a first digital certificate is used for a first service and a second certificate is used for a second service.

[0057] FIG. 6 shows, as an example, three types of certification authorities 30a, 30b, and 30c and examples of electronic certificates issued by each certification authority 30a, 30b, and 30c. The certified certification authority 30a is a certification authority that performs certified certification services certified by the government and issues digital signature certificates EC1 and EC2 with the strictest assurance level, meeting TAL Level 3. The digital signature certificates EC1 and EC2 are used for specific purposes, such as electronic signatures on official documents. The digital signature certificates EC1 and EC2 contain the user's personal information (such as name, address, and date of birth). The specific certification authority 30b is a certification authority that performs specific certification services that meet the requirements of the Digital Signature Act and issues a digital authentication certificate EC3 with an assurance level that meets TAL Level 2 or Level 1. The digital authentication certificate EC3 is not particularly limited in its use, but is used for electronic signatures, authentication, encryption, and other purposes that meet the requirements of the Digital Signature Act. The general certification authority 30c is a certification authority that performs authentication services without legal backing. The electronic certificate EC4 issued by the certification authority 30c has no particular limitations on its use and does not meet the requirements of the Digital Signature Act. The authentication electronic certificate EC3 and the general electronic certificate EC4 do not include any personal information.

[0058] Each digital certificate is linked to a digital ID issued by the ID provider 20. If the four types of digital certificates shown in Fig. 6 are issued to the same user, the same digital ID will be linked to each digital certificate. Therefore, by checking whether the digital IDs are the same, it is possible to determine and manage whether the digital certificates belong to the same user.

[0059] Here, "linking a digital ID" refers to the operation of clearly indicating and guaranteeing the correspondence between a digital ID and an electronic certificate. Typically, the digital ID is written in the electronic certificate. Since the electronic certificate itself cannot be tampered with, spoofing of the digital ID can be prevented if the digital ID is written in the electronic certificate. However, if the correspondence between the digital ID and the electronic certificate can be guaranteed or verified by a separate means, the electronic certificate and the digital ID may be managed as separate data.

[0060] With the above configuration, the electronic authentication system 1 issues a digital ID and multiple types of electronic certificates linked to the digital ID to a user. Adopting such a framework has the following advantages.

[0061] Among the multiple types of electronic certificates EC1 to EC4, the level of assurance increases and the scope of application widens in the order of general electronic certificate EC4, authentication electronic certificate EC3, and signature electronic certificates EC1 and EC2. On the other hand, general electronic certificate EC4 and authentication electronic certificate EC3 do not contain personal information and therefore have a higher level of anonymity than signature electronic certificates EC1 and EC2. Users can use electronic certificates EC1 to EC4 appropriately depending on the purpose, such as using an electronic certificate with a higher level of assurance when using services that require legal backing, and an electronic certificate with a higher level of anonymity for other purposes. This enables the operation of electronic certificates to strike a balance between the required level of assurance and legal requirements and the protection of privacy.

[0062] Furthermore, electronic certificates EC1 to EC4 are linked to digital IDs, and these digital IDs are issued only after the user's identity has been verified. Therefore, even anonymous electronic certificates (EC3 and EC4) are guaranteed to belong to the user because they are linked to the digital ID. In other words, electronic authentication system 1 realizes electronic certificates with the contradictory property of "anonymity with identity." With various digital services provided over the Internet, users often desire to use the services as easily as possible while keeping their personal information confidential, while service providers often desire to eliminate users with unknown identities and fake accounts as much as possible to ensure the secure operation of their services. Electronic certificates with "anonymity with identity" are highly practical, as they enable operational designs that balance the conflicting demands of users and service providers.

[0063] Furthermore, by using digital IDs to ensure that multiple electronic certificates belong to the same user, so-called "service-to-service linkage across electronic certificates" becomes possible. For example, as shown in Figure 5, consider a scenario in which a user is using a first service and a second service and wishes to link information stored in the first service to the second service. Conventionally, there has been no way for service providers to reliably verify and confirm that the users of the first service and the second service are both the same person and identical. Therefore, even if a user desires and authorizes service-to-service linkage, exchanging user data between different service providers is risky and difficult to implement. In contrast, within the framework of electronic authentication system 1, the identities and identity of the users of the first and second services can be confirmed by comparing the digital ID associated with the first electronic certificate used to authenticate the first service with the digital ID associated with the second electronic certificate used to authenticate the second service. Therefore, it is expected that data sharing between different service providers will become possible safely and with simple procedures.

[0064] <System Configuration> The two elements of the electronic authentication system 1, the ID provider 20 and the certificate authority 30, may be implemented on the same server or on different servers. Also, a configuration in which multiple certificate authorities 30a-30c with different assurance levels are implemented on a single server is possible, or a configuration in which each certificate authority 30a-30c is implemented on a different server is possible. An example of a system configuration is shown below in Figures 7 to 10.

[0065] (1) Configuration in which all certification authorities have an ID provider An example of a system configuration in which all certification authorities have an ID provider will be described with reference to Fig. 7. In addition to the configuration of the electronic authentication system 1, Fig. 7 also shows the devices of users and service providers who use the trust services provided by the electronic authentication system 1.

[0066] The electronic authentication system 1 is composed of multiple certification authority servers 3. Of these, reference numeral 3a denotes a certified certification authority server, reference numeral 3b denotes a specific certification authority server, and reference numeral 3c denotes a general certification authority server (hereinafter, in descriptions common to all certification authority servers, reference numerals only containing numbers will be used, while in descriptions of individual certification authority servers, reference numerals containing letters a to c will be used to distinguish between them). The certification authority server 3 is roughly composed of two units: an ID provider 20 and a certification authority 30. The ID provider 20 has the function of verifying the identity of a user by verifying the user's identification (identity verification) and the function of issuing and managing digital IDs (ID issuance). The certification authority 30 has the function of issuing and managing electronic certificates (certificate issuance), the function of linking digital IDs to electronic certificates (ID assignment), and the function of checking the revocation of electronic certificates (certificate verification). The certification authority 30a of the certification certification authority server 3a is a certification certification authority capable of performing certification certification tasks, the certification authority 30b of the specific certification authority server 3b is a specific certification authority capable of performing specific certification tasks, and the certification authority 30c of the certification authority server 3c is a general certification authority.

[0067] The certificate authority server 3 can be configured, for example, by a general-purpose computer equipped with a processor (CPU), memory, storage, communication device, etc., and the above-mentioned functions are realized by the processor executing a program loaded from storage to memory. The certificate authority server 3 may be configured by a single computer, or may be configured by multiple computers working together as in distributed computing, or may be configured by dynamically allocated resources as in cloud computing. Alternatively, some or all of the functions provided by the certificate authority server 3 may be configured by circuits such as FPGAs or ASICs, or by dedicated hardware.

[0068] A user can use the trust service using the user terminal 4. The user terminal 4 has functions related to the trust service, such as a function to request the electronic authentication system 1 (ID provider 20) to issue a digital ID (ID issuance request), a function to request the electronic authentication system 1 (certificate authority 30) to issue an electronic certificate (certificate issuance request), a function to store and manage a digital ID granted by the electronic authentication system 1 (ID management), a function to store and manage an electronic certificate granted by the electronic authentication system 1 (certificate management), a function to issue an electronic signature using a public key cryptosystem (electronic signature), a function to read information from an IC chip mounted on an official identification card (such as an Individual Number card or an IC passport) (reader), a function to take a photo of the user's appearance or the official identification card (camera), and a function to generate a key pair of a private key and a public key.

[0069] The user terminal 4 can be configured, for example, by a general-purpose computer equipped with a processor (CPU), memory, storage, communication device, input device, display device, card reader, camera, etc. Specifically, a smartphone, tablet device, personal computer, wearable device, etc. can be used as the user terminal 4. The functions related to the above-mentioned trust service are realized by a dedicated app (program) installed on the user terminal 4. The user terminal 4 preferably has a tamper-resistant secure IC chip (secure element), and data related to the trust service (digital ID, electronic certificate, private key, public key, etc.) is preferably stored in such a secure IC chip. It is also preferable that all or part of the functions of the dedicated app are stored in and executed within the secure IC chip. In such a configuration, the program executed by the processor of the user terminal 4 uses the data and functions in the secure IC chip via a Cryptographic Application Programming Interface (CryptoAPI). Furthermore, when using the data or functions in the secure IC chip, it may be necessary to require the input of a password, PIN code, etc. This configuration makes it possible to prevent tampering, unauthorized use, and leakage of data related to the trust service.

[0070] The service providing server 5 is a server operated by a service provider and provides users with digital services via the Internet. The type of digital service is not important. Examples of various services include e-commerce, SNS, video streaming, cashless payments, online meetings, food ordering and delivery, Internet banking, fintech services, sharing services, administrative procedures, store search and reservations, online medical consultations, online dispensing, taxi dispatching, and membership apps.

[0071] The service providing server 5 uses the electronic certificate issued by the electronic authentication system 1 to authenticate users (i.e., people who access the service providing server 5 from the user terminal 4) and to verify electronic signatures received from the user terminal 4. The service providing server 5 may determine the assurance level of the electronic certificate to be requested from the user depending on the assurance level required for the digital service to be provided. For example, in the case of services that require a high assurance level, such as administrative procedures or internet banking, the service providing server 5 may request the user to provide electronic certificates EC1 to EC3 issued by the certified certification authority 30a or the specified certification authority 30b, whereas in the case of services that do not require a high assurance level, such as e-commerce or SNS, the service providing server 5 may request the user to provide electronic certificate EC4 issued by the general certification authority 30c.

[0072] The service providing server 5 can be configured, for example, by a general-purpose computer equipped with a processor (CPU), memory, storage, communication device, etc., and the above-mentioned functions are realized by the processor executing a program loaded from the storage to the memory. The service providing server 5 may be configured by a single computer, or may be configured by multiple computers working together as in distributed computing, or may be configured by dynamically allocated resources as in cloud computing. Alternatively, some or all of the functions provided by the service providing server 5 may be configured by circuits such as FPGAs or ASICs, or by dedicated hardware.

[0073] In the system configuration of Fig. 7, any of the certification authority servers 3a to 3c can issue a digital ID. Information on the digital ID issued to a user is shared between the certification authority servers 3a to 3c via the user terminal 4, or by the certification authority servers 3a to 3c directly cooperating with each other, or via a data coordinating platform (not shown), and is used for processes such as issuing an electronic certificate. The configuration of Fig. 7 is suitable, for example, for cases where the certification authorities 30a to 30c are operated by different organizations or where the scale of use of each certification authority is large.

[0074] (2) Configuration in which the certification authority and the ID provider are different entities An example of a system configuration in which the certification authority and the ID provider are different entities will be described with reference to Fig. 8. Since the configurations of the user terminal 4 and the service providing server 5 are the same as those in Fig. 7, only the configuration of the electronic authentication system 1 will be described below.

[0075] The electronic authentication system 1 is composed of an ID provider server 2 and multiple certification authority servers 3 (a certified certification authority server 3a, a specified certification authority server 3b, and a general certification authority server 3c). The ID provider 20 implemented in the ID provider server 2 has the function of verifying the identity of a user by verifying the user's identification (identity verification) and the function of issuing and managing digital IDs (ID issuance). The certification authority 30 implemented in the certification authority server 3 has the function of issuing and managing electronic certificates (certificate issuance), the function of linking digital IDs to electronic certificates (ID assignment), and the function of checking the revocation of electronic certificates (certificate verification). The electronic authentication system 1 is constructed by the ID provider server 2 and the certification authority server 3 linking via the Internet.

[0076] The ID provider server 2 can be configured, for example, by a general-purpose computer equipped with a processor (CPU), memory, storage, communication device, etc., and the above-mentioned functions are realized by the processor executing a program deployed from storage to memory. The ID provider server 2 may be configured by a single computer, or by multiple computers working together as in distributed computing, or by dynamically allocated resources as in cloud computing. Alternatively, some or all of the functions provided by each of the servers 2 and 3 may be configured by circuits such as FPGAs or ASICs, or by dedicated hardware.

[0077] In the system configuration of Fig. 8, the issuance of digital IDs and the issuance of electronic certificates are performed by different servers. Information on digital IDs issued to users is shared among the certification authority servers 3a-3c via the user terminal 4, or by direct collaboration between the ID provider server 2 and the certification authority servers 3a-3c, or via a data collaboration platform (not shown), and is used for processes such as issuing electronic certificates. The configuration of Fig. 8 is suitable, for example, for cases where the ID provider 20 and the certification authorities 30a-30c are operated by different organizations, or where the ID provider and the certification authorities are used on a large scale.

[0078] (3) Configuration in which multiple certification authorities are implemented on one server An example of a system configuration in which multiple certification authorities with different assurance levels are implemented on one certification authority server will be described with reference to Fig. 9. The configurations of the user terminal 4 and the service providing server 5 are the same as those in Fig. 7, so only the configuration of the electronic authentication system 1 will be described below.

[0079] The electronic authentication system 1 is composed of one certificate authority server 3. The certificate authority server 3 is roughly composed of an ID provider 20, a certified certificate authority 30a, a specified certificate authority 30b, and a general certificate authority 30c. The ID provider 20 has a function to verify the identity of a user by verifying the user's identification (identity verification) and a function to issue and manage digital IDs (ID issuance). Furthermore, each of the certificate authorities 30a to 30c has a function to issue and manage electronic certificates (certificate issuance), a function to link digital IDs to electronic certificates (ID assignment), and a function to check the revocation of electronic certificates (certificate verification).

[0080] The system configuration in Fig. 9 is a minimum configuration that can realize the trust service of this proposed model with only one server. For example, it is suitable for use at the start of operation, when the operation scale is small, or in a private network with a limited number of users and scope of use (for example, an intranet service within a company or school).

[0081] (4) Configuration in which the certification authority with the highest assurance level also serves as the ID provider An example of a system configuration in which the certification authority with the highest assurance level also serves as the ID provider will be described with reference to Fig. 10. The configurations of the user terminal 4 and the service providing server 5 are the same as those in Fig. 7, so only the configuration of the electronic authentication system 1 will be described below.

[0082] The electronic authentication system 1 is composed of multiple certification authority servers 3 (certification authority server 3a, specific certification authority server 3b, and general certification authority server 3c). Of these, only the certification authority server 3a, which has the highest level of assurance, is provided with an ID provider 20. With this configuration, handling of user identification data (personal identification information) required for issuing digital IDs and digital signature certificates EC1 and EC2 can be completed within the certification authority server 3a. Information on the digital ID issued by the certification authority server 3a is shared among the certification authority servers 3a to 3c via the user terminal 4, or by direct collaboration between the certification authority servers 3a to 3c, or via a data collaboration platform (not shown), and is used for processes such as issuing digital certificates.

[0083] The system configurations shown in FIGS. 7 to 10 are merely examples, and the most suitable system configuration may be adopted depending on the scale, operating organization, operation management, scope of use, etc. of the ID provider or certification authority.

[0084] <Issuance of Digital ID and Electronic Certificate> Next, we will explain the flow of the process for issuing a digital ID and an electronic certificate by the electronic authentication system 1. Since the process, data flow, and entity that executes the process differ depending on the configuration of the electronic authentication system 1 (Figs. 7 to 10), we will show examples of variations in the process for each system configuration below. It is assumed that a dedicated app is installed on the user terminal 4.

[0085] (1) Example in which one server issues digital IDs and electronic certificates Figure 11 shows an example of a processing sequence in which a single certificate authority server 3 issues digital IDs and multiple electronic certificates. For example, the processing sequence in Figure 11 can be adopted in the system configuration shown in Figure 9. For convenience of illustration and explanation, an example of two certificate authorities 30x and 30y is shown below, but it will be readily apparent to those skilled in the art that similar processing can be extended to three or more certificate authorities.

[0086] First, the user launches a dedicated app on the user terminal 4 and requests the issuance of a digital ID and electronic certificate (step S100). A key pair is generated by the dedicated app (step S101). The key pair is stored in a secure element (SE). A selection of ID cards to be used for identity verification (personal verification) is displayed on the screen, and the user selects the desired ID card (step S102). ID cards incorporating an eKYC-compatible IC chip can be used. In this example, either a My Number card or an IC passport can be selected. Then, following the on-screen guidance, the user places the ID card in the card reader of the user terminal 4, and the card reader reads the ID card data from the ID card's IC chip (step S103). If necessary, the user's facial image may be captured and biometric information may be acquired. The user's ID card data and public key are sent to the certification authority server 3 (step S104).

[0087] The identification data and public key may be sent to the certification authority server 3 at the same time (in a single request), or they may be sent in two stages (in separate requests), such as first sending the identification data to verify identity using eKYC, and then sending the public key to issue the certificate.

[0088] The identification data is information used to verify the identity of a user, and includes, for example, the four basic pieces of information (name, address, date of birth, and gender). In the case of eKYC using a My Number card, in addition to the four basic pieces of information, the electronic certificate stored in the My Number card and an image of the individual's appearance may also be acquired as identification data. In the case of eKYC using an IC passport, in addition to the four basic pieces of information, the DS certificate stored in the IC passport and an image of the individual's appearance may also be acquired as identification data. Furthermore, the serial number of the identification card may also be included in the identification data.

[0089] When the ID provider 20 of the certification authority server 3 receives the identification data from the user terminal 4, it confirms the authenticity and validity of the identification data (step S105). Specifically, in the case of eKYC using a My Number card, the ID provider 20 confirms the validity of the My Number card's electronic certificate through verification and inquiry to J-LIS. In addition, in the case of eKYC using an IC passport, the ID provider 20 confirms the validity of the DS certificate through verification and inquiry to ICAO PKD. Once the authenticity and validity of the identification data have been confirmed, the ID provider 20 issues a digital ID to the user (step S106).

[0090] The ID provider 20 associates the user's identification data with the digital ID and registers them in a user database. The ID provider 20 also notifies each of the certification authorities 30x and 30y of the issued digital ID and requests them to generate a digital certificate. At this time, the user's public key and the user's identification data (only the necessary information) are also passed to the certification authorities.

[0091] The first certificate authority 30x is, for example, a certified certificate authority, and issues a legally backed digital certificate for signing (step S107). In the case of a digital certificate compliant with X.509 standard established by the ITU-T, the digital certificate contains information such as the user's public key, user information, the certificate authority's digital signature, the expiration date of the digital certificate, and issuer information. In the example of FIG. 6, the digital certificate for signing EC1 contains only the name (in Roman letters) as user information, while the digital certificate for signing EC2 contains the name (in Roman letters), name (in Kanji characters), address, and date of birth as user information. In addition to this information, the first certificate authority 30x also contains a digital ID in the digital certificate, thereby linking the digital ID to the digital certificate (step S108). In this case, the first certificate authority 30x may attach a digital signature to a data description containing the user's public key, user information, and digital ID. This makes it possible to prevent tampering with the digital ID in the electronic certificate, thereby ensuring the ability of the digital ID to certify the identity of the electronic certificate.

[0092] The second certificate authority 30y is, for example, a general certificate authority, and issues a general digital certificate (step S109). The general digital certificate is, for example, an anonymous digital certificate EC4 that does not include personal information of the user, as shown in FIG. 6. The second certificate authority 30y associates the digital ID with the digital certificate by describing the digital ID in the digital certificate (step S110). In this case, it is also preferable to affix the digital signature of the second certificate authority 30y to the data description including the digital ID.

[0093] The certificate authority server 3 transmits a data set consisting of the issued digital ID and multiple electronic certificates issued by each certificate authority 30x, 30y to the user terminal 4 (step S111). The dedicated application on the user terminal 4 stores the received digital ID and multiple electronic certificates in a secure element (SE) (step S112). Through the above procedure, the user can receive the digital ID and multiple electronic certificates through an online procedure using the user terminal 4.

[0094] Note that the "digital ID" is always the same across multiple electronic certificates, but the "public key" may be the same across multiple electronic certificates, or may be different for each electronic certificate. If the public key is different for each electronic certificate, multiple key pairs are generated in step S101, and multiple public keys for each certification authority are sent to the certification authority server 3 in step S104.

[0095] Fig. 12 shows an example of a processing sequence for reissuing a digital certificate. For example, if a user loses their digital certificate or key pair due to loss or malfunction of the user terminal 4, they can have it reissued by following the procedure in Fig. 12.

[0096] First, the user launches a dedicated app on the user terminal 4 and requests the reissue of a digital ID and electronic certificate (step S120). A new key pair is generated by the dedicated app and stored in the secure element (step S121). A selection of ID cards to be used for identity verification (personal verification) is displayed on the screen, and the user selects the desired ID card (step S122). ID cards incorporating an eKYC-compatible IC chip can be used. In this example, either a My Number card or an IC passport can be selected. Then, following the on-screen guidance, the user places the ID card in the card reader of the user terminal 4, and the card reader reads the ID card data from the ID card's IC chip (step S123). If necessary, the user's facial image may be captured and biometric information may be acquired. The user's ID card data and public key are sent to the certification authority server 3 (step S124).

[0097] When the ID provider 20 of the certificate authority server 3 receives the identification data from the user terminal 4, it checks the authenticity and validity of the identification data and then checks whether the same user's registration data exists in the user database (step S125). Whether the user is the same or not is determined by evaluating the consistency of the identification data.

[0098] If the registration data of the same user exists, the ID provider 20 reads the digital ID of the user from the user database (step S126). The processing of subsequent steps S127 to S132 is essentially the same as the processing of steps S107 to S112 in Figure 11, and therefore a description thereof will be omitted. If the certificate authority server 3 stores in the user database a digital certificate previously issued to the user, and if that digital certificate is usable, the stored digital certificate may be provided to the user terminal 4 instead of reissuing the digital certificate. Note that if the registration data of the same user does not exist in the user database, a new digital ID must be issued, and the processing may proceed to step S106 in Figure 11.

[0099] 13 shows an example of a processing sequence for updating a digital certificate. For example, if a user has a digital certificate that has expired or is close to expiring, the expiration date can be updated using the procedure shown in FIG.

[0100] The user uses the dedicated app to select the electronic certificate to be updated from among the electronic certificates stored in the user terminal 4 and performs an update request operation (step S140).The dedicated app then reads the electronic certificate to be updated from the secure area (step S141) and sends it to the certificate authority server 3 together with an update request (step S142).

[0101] The certificate authority server 3 delivers the digital certificate to be updated received from the user terminal 4 to the certificate authority 30x or 30y that issued the digital certificate. The certificate authority 30x or 30y confirms the validity of the digital certificate by verifying the digital signature attached to the digital certificate to be updated (steps S143 and S146). If the validity of the digital certificate is confirmed (i.e., if it is confirmed that the digital certificate was previously issued by the certificate authority 30x or 30y), the certificate authority 30x or 30y reissues the digital certificate and associates it with the digital ID (steps S144 to S145, S147 to S148). At this time, the user's digital ID, user information, public key, and other information contained in the old digital certificate can be used as is. This is because the validity of this information, including the digital ID, is guaranteed by the digital signature attached to the old digital certificate.

[0102] The certificate authority server 3 transmits the new updated digital certificate to the user terminal 4 (step S149). The dedicated application on the user terminal 4 replaces the old digital certificate stored in the secure element with the new digital certificate (step S150). According to the above procedure, updating the digital certificate linked to the digital ID can be achieved with simple operations. In particular, since identity verification is not required, the burden and complexity on the user is reduced.

[0103] (2) Example of issuing a digital ID by a certified certificate authority server The processing sequences of Figures 14A and 14B show an example of a procedure in which a first certificate authority server 3x issues a digital ID and a digital certificate for signature, and then the same digital ID is linked to a digital certificate issued by another second certificate authority server 3y. For example, the processing sequences of Figures 14A and 14B may be adopted in the case of the system configuration shown in Figure 10. For convenience of illustration and explanation, an example of two certificate authority servers 3x and 3y is shown below, but it will be readily apparent to those skilled in the art that similar processing can be extended to three or more certificate authority servers.

[0104] The processing in steps S200 to S204 is substantially the same as the processing in steps S100 to S104 in FIG. 11, and therefore a description thereof will be omitted.

[0105] When the ID provider 20 of the first certificate authority server 3x receives the identification data from the user terminal 4, it checks the authenticity and validity of the identification data (step S205). The specific checking method may be the same as step S105 in Fig. 11. Once the authenticity and validity of the identification data have been confirmed, the ID provider 20 issues a digital ID to the user (step S206). The ID provider 20 associates the user's identification data with the digital ID and registers them in the user database.

[0106] Then, the certificate authority 30x of the first certificate authority server 3x issues a digital signature certificate linked to the digital ID (steps S207 to S208). The specific processing may be the same as steps S107 to S108 in FIG. 11 . The first certificate authority server 3x transmits a data set consisting of the issued digital ID and digital certificate to the user terminal 4 (step S209). The dedicated application of the user terminal 4 stores the received digital ID and digital certificate in a secure element (step S210). Hereinafter, the digital certificate issued by the first certificate authority 30x will be referred to as the "first digital certificate."

[0107] After receiving a digital ID and a first electronic certificate from the first certificate authority 30x, the user can receive an electronic certificate linked to the same digital ID from another certificate authority 30y.

[0108] Specifically, the user launches a dedicated app on the user terminal 4 and requests the issuance of an additional digital certificate (step S211). A new key pair is generated by the dedicated app and stored in the secure element (step S212). A selection of ID cards to be used for identity verification (personal verification) is displayed on the screen, and the user selects the desired ID card (step S213). Again, either a My Number card or an IC passport can be selected. The user then follows the on-screen guidance to place the ID card in the card reader of the user terminal 4, and the card reader reads the ID card data from the IC chip in the ID card (step S214). If necessary, the user's facial image may be photographed and biometric information may be acquired.

[0109] The dedicated application digitally signs the identification data using the private key corresponding to the first electronic certificate (step S215), and sends the digitally signed identification data, the public key generated in step S212, and the first electronic certificate to the second certification authority server 3y (step S216).

[0110] When the second certificate authority server 3y receives an application for issuance of a digital certificate from the user terminal 4, it first verifies the digital signature (step S217). Specifically, the second certificate authority server 3y inquires of the first certificate authority 30x about the authenticity and validity of the first digital certificate. Once the authenticity and validity of the first digital certificate are confirmed (step S218), the second certificate authority server 3y verifies the digitally signed ciphertext using the public key included in the first digital certificate and checks whether the verification result matches the original data, thereby confirming that the digital signature was issued by the user himself / herself (using his / her private key). At this time, the second certificate authority server 3y may obtain the user's registration data from the first certificate authority server 3x, or may confirm whether the user's digital ID registered in the first certificate authority server 3x matches the digital ID linked to the first digital certificate.

[0111] Next, the second certificate authority server 3y checks the authenticity and validity of the identification data (step S219). Note that, because the first certificate authority server 3x performs strict identity verification when issuing a digital ID, it is sufficient to perform the minimum necessary identity verification according to the assurance level of each certificate authority at this timing (if the second certificate authority server 3y does not include personal information of the user in the digital certificate issued by the second certificate authority server 3y, the process of step S219 may be omitted).

[0112] The second certificate authority server 3y then issues a second digital certificate linked to the user's digital ID (steps S220 and S221). Specific processing may be the same as steps S109 and S110 in FIG. 11. The digital ID information may be that described in the first digital certificate provided by the user terminal 4. Because the authenticity of the first digital certificate is guaranteed by the processing in step S217, it is also guaranteed that the digital ID described therein belongs to the user.

[0113] The second certificate authority server 3y transmits a data set consisting of the digital ID and the newly issued second electronic certificate to the user terminal 4 (step S222). The dedicated application of the user terminal 4 stores the received digital ID and second electronic certificate in a secure element (step S223). The second certificate authority server 3y also transmits the second electronic certificate to the first certificate authority server 3x (step S224). The first certificate authority server 3x aggregates and manages the first and second electronic certificates associated with the same digital ID in a user database. If aggregate management of electronic certificates is not required, the processing of step S224 may be omitted.

[0114] By following the above procedure, the user can receive an additional digital certificate linked to the digital ID from any certification authority at any time.

[0115] The processing sequence in Fig. 15 shows an example of the procedure for reissuing a digital certificate. If a digital certificate is lost but the key pair remains in the secure element of the user terminal 4, the digital certificate can be reissued by following the procedure in Fig. 15.

[0116] First, the user launches the dedicated app on the user terminal 4 and requests the reissue of the electronic certificate (step S230). A selection of ID cards to be used for identity verification (personal identification) is displayed on the screen, and the user selects the desired ID card (step S231). Again, either a My Number card or an IC passport can be selected. Then, the user follows the on-screen guidance to place the ID card in the card reader of the user terminal 4, and the card reader reads the ID card data from the IC chip of the ID card (step S232). If necessary, the user's facial image may be photographed and biometric information may be acquired. The user's ID card data is sent to the first certification authority server 3x (step S233).

[0117] When the first certification authority server 3x receives the identification data from the user terminal 4, it checks the authenticity and validity of the identification data and then checks whether the same user's registration data exists in the user database (step S234). Whether the user is the same or not is determined by evaluating the consistency of the identification data.

[0118] If registration data for the same user exists, the first certification authority server 3x reads the user's digital ID and electronic certificate from the user database (step S235) and transmits them to the user terminal 4 (step S236). If the first certification authority server 3x centrally manages electronic certificates issued by other certification authorities, it is recommended that all electronic certificates linked to the user's digital ID be transmitted to the user terminal 4. The dedicated application on the user terminal 4 stores the received digital ID and multiple electronic certificates in a secure element (SE) (step S237).

[0119] The above procedure allows multiple digital certificates issued by different certification authorities to be reissued in one go. However, if the user's registration data does not exist in the user database, or if the registration data exists but the previous digital certificate is no longer usable (for example, if the user has lost their key pair), a new digital certificate must be issued.

[0120] The processing sequence in Fig. 16 shows another example of the procedure for reissuing a digital certificate. In the processing sequence in Fig. 16, a reissue request is made individually to the certification authority that issued the digital certificate. If multiple digital certificates linked to a digital ID are not centrally managed, the procedure in Fig. 16 can be performed.

[0121] When a request for reissuance of a digital certificate is made on the user terminal 4, an identification card is selected and the necessary identification card data is read (steps S240 to S242). The procedure up to this point is the same as the processing sequence in Fig. 15. Thereafter, in the processing sequence in Fig. 16, the identification card data is sent from the user terminal 4 to the first certification authority server 3x and the second certification authority server 3y, respectively (steps S243 and S248).

[0122] When the first certificate authority server 3x receives the identification data from the user terminal 4, it checks the authenticity and validity of the identification data and then queries the user database to see if the same user's registration data exists (step S244). Whether the user is the same or not is determined by evaluating the consistency of the identification data. If the same user's registration data exists, the first certificate authority server 3x reads the user's digital ID and electronic certificate from the user database (step S245) and sends them to the user terminal 4 (step S246). The dedicated application on the user terminal 4 stores the received digital ID and electronic certificate in a secure area within the secure element (step S247).

[0123] Similarly, when the second certificate authority server 3y receives identification data from the user terminal 4, it checks the authenticity and validity of the identification data and then queries the user database to see if the same user's registration data exists (step S249). Whether the user is the same or not is determined by evaluating the consistency of the identification data. If the same user's registration data exists, the second certificate authority server 3y reads the user's digital ID and electronic certificate from the user database (step S250) and sends them to the user terminal 4 (step S251). The dedicated application on the user terminal 4 stores the received digital ID and electronic certificate in a secure area within the secure element (step S252).

[0124] By following the above procedure, the user terminal 4 can receive a new digital certificate from each of the certificate authority servers 3x and 3y.

[0125] (3) Example in which the digital ID and the electronic certificate are issued on different servers The processing sequence in Fig. 17 shows an example of a procedure in which the digital ID and the electronic certificate are issued on different servers. For example, the processing sequence in Fig. 17 can be adopted in the case of the system configuration shown in Fig. 8.

[0126] The processing in steps S300 to S304 is the same as the processing in steps S100 to S104 in FIG. 11, and therefore a description thereof will be omitted.

[0127] When the ID provider 20 of the ID provider server 2 receives the identification data from the user terminal 4, it verifies the authenticity and validity of the identification data (step S305). The specific verification method may be the same as step S105 in FIG. 11. Once the authenticity and validity of the identification data have been verified, the ID provider 20 issues a digital ID to the user (step S306). The ID provider 20 associates the user's identification data with the digital ID and registers them in the user database. The ID provider 20 then sends a request for issuance of a digital certificate to the certification authority server 3 along with the digital ID, personal information, and public key (step S307).

[0128] The certificate authority server 3 issues a digital certificate linked to the digital ID based on the issuance request from the ID provider server 2 (steps S308 to S309). The specific processing may be the same as steps S107 to S108 in Fig. 11. The certificate authority server 3 transmits the issued digital certificate to the ID provider server 2 (step S310).

[0129] The ID provider server 2 registers the digital certificate received from the certificate authority server 3 in the user database (step S311) and transmits a data set consisting of the digital ID and the digital certificate to the user terminal 4 (step S312). The dedicated application on the user terminal 4 stores the received digital ID and digital certificate in a secure area within the secure element (step S313).

[0130] Through the above procedure, the user can be issued a digital ID and an electronic certificate. To receive an additional electronic certificate from another certification authority, the same processes as steps S211 to S223 in FIG. 14B can be performed on the other certification authority. Furthermore, for reissuing an electronic certificate, the same process sequence as in FIG. 15 or 16 can be used. However, the role of the first certification authority server 3x in FIG. 14B, FIG. 15, and FIG. 16 is played by the ID provider server 2.

[0131] (4) Linking a digital ID to an existing electronic certificate For example, a user may have an electronic certificate that was obtained before subscribing to the trust service of the electronic authentication system 1 or an electronic certificate issued by an organization unrelated to the electronic authentication system 1. By linking a digital ID to such an existing electronic certificate after the fact, it is possible to add identity to the existing electronic certificate and enable centralized management using the digital ID.

[0132] 18A and 18B show an example of a procedure for linking a digital ID to an existing electronic certificate after the fact. It is assumed that the user has already been issued a digital ID by the ID provider 20, and that an electronic certificate (electronic certificate not including a digital ID) issued by the certification authority 60 of the certification authority server 6 that is unrelated to the electronic authentication system 1 is stored in the user terminal 4.

[0133] First, the user launches a dedicated app on the user terminal 4 and requests ID assignment to the electronic certificate (step S400). A selection of ID cards to be used for identity verification (personal verification) is displayed on the screen, and the user selects the desired ID card (step S401). Again, either a My Number card or an IC passport can be selected. Then, following the on-screen guidance, the user places the ID card in the card reader of the user terminal 4, and the card reader reads the ID card data from the IC chip of the ID card (step S402). If necessary, the user's facial image may be photographed and biometric information may be acquired. The dedicated app on the user terminal 4 reads the electronic certificate to be assigned an ID from memory (step S403) and sends an ID assignment request to the ID provider server 2 along with the electronic certificate and the ID card data (step S404).

[0134] When the ID provider 20 of the ID provider server 2 receives the identification data from the user terminal 4, it checks the authenticity and validity of the identification data and then queries the user database to see if the same user's registration data exists (step S405). Whether the user is the same or not is determined by evaluating the consistency of the identification data. If the same user's registration data exists, the ID provider 20 reads the user's digital ID from the user database (step S406). The ID provider 20 sends an ID assignment request to the certification authority 60 along with the digital ID, the user's personal information, and the electronic certificate (step S407). The certification authority 60 is the certification authority that issued the electronic certificate to which the ID is to be assigned.

[0135] The certificate authority 60 verifies whether the accepted digital certificate is valid (step S408) and then performs a process of linking the digital certificate to the digital ID. If the digital certificate to which the ID is to be assigned has specifications that allow additional information to be written (Yes in step S409), the certificate authority 60 writes the digital ID into the digital certificate (step S410) and transmits the updated digital certificate to the ID provider server 2 and the user terminal 4, respectively (steps S411 and S412). The ID provider server 2 stores the updated digital certificate in association with the user's digital ID and other digital certificates (step S413). The dedicated app on the user terminal 4 also stores the updated digital certificate (the digital certificate containing the digital ID) in a secure element (step S414).

[0136] If the electronic certificate to which the ID is to be assigned does not allow additional information to be written (No in step S409), the certificate authority 60 sends a request to the ID provider server 2 to link the digital ID and the electronic certificate (step S415). The ID provider server 2 stores the electronic certificate in association with the user's digital ID and other electronic certificates (steps S416-S417), and then sends an ID assignment completion notification to the user terminal 4 (step S418). Upon receiving the ID assignment completion notification, the dedicated application on the user terminal 4 registers the correspondence between the digital ID and the electronic certificate in the application's management database (step S419). This mechanism makes it possible to link a digital ID and an electronic certificate even if the electronic certificate does not allow the digital ID to be written.

[0137] <Example of Use of Electronic Certificates> Next, we will explain the procedure for using an electronic certificate issued by the electronic authentication system 1 for a digital service, and an example of how to use electronic certificates with different assurance levels. To simplify the explanation, we will assume that a user holds two types of electronic certificates ECx and ECy: a first electronic certificate ECx (containing personal information, high assurance level) issued by a first certification authority 30x; and a second electronic certificate ECy (not containing personal information, low assurance level) issued by a second certification authority 30y.

[0138] (1) User registration for digital services requiring identity verification The procedure for user registration for digital services requiring identity verification will be described with reference to Figures 19 and 20. Figure 19 shows an example of a processing sequence for user registration, and Figure 20 shows an example of a screen displayed on the user terminal 4. Examples of digital services requiring identity verification include administrative procedures, internet banking, and online medical care.

[0139] First, the user operates the user terminal 4 to launch a service application for using a digital service (step S500). At the first launch, a user registration screen 60 such as that shown in Fig. 20 is displayed, and the user is requested to enter user data such as name, address, date of birth, gender, and telephone number (step S501). After the user has entered the requested user data, the user data is handed over to the dedicated application.

[0140] Next, the dedicated app displays an electronic certificate selection screen 61 (step S502). The selection screen 61 displays a list of electronic certificates stored in the secure element of the user terminal 4. Although not shown, when using data or functions of the secure element, the user may be required to enter a PIN code or password (the same applies below). The selection screen 61 shown in FIG. 20 displays two options, electronic certificate ECx and electronic certificate ECy, and the user can select an electronic certificate to use for user registration for a digital service on this screen 61. The selection screen 61 may display descriptions of each electronic certificate ECx and ECy, such as whether or not personal information is included and its intended use (assurance level). Here, an electronic certificate ECx that meets the assurance level required by the digital service is selected. Note that the service app or dedicated app may assist the user in selecting an electronic certificate by automatically selecting an electronic certificate that meets the assurance level required by the digital service or by excluding from the options electronic certificates that do not meet the assurance level required by the digital service.

[0141] Next, the dedicated application reads the selected electronic certificate ECx from the secure element and digitally signs the user data using the private key (step S503). At this time, the dedicated application may confirm the user's intention regarding the subject to which the electronic signature is to be applied and the procedure to be performed using the electronic signature. In this example, the dedicated application may confirm the user's intention regarding the digital signature being applied to user data including personal information for the user registration application. Then, the service application transmits the user data with the digital signature and the electronic certificate ECx to the service providing server 5 (step S504).

[0142] The service providing server 5 verifies the digital signature received from the user terminal 4 (step S505). Specifically, the service providing server 5 verifies the digitally signed ciphertext using the user's public key included in the digital certificate ECx, and confirms that the digital signature was issued using the user's private key by checking whether the verification result matches the user data. The service providing server 5 also queries the certificate authority 30x, the issuer of the digital certificate ECx, about the authenticity and validity of the digital certificate ECx. The certificate authority 30x checks whether the digital certificate ECx has been revoked and returns the confirmation result to the service providing server 5 (step S506).

[0143] If the verification of the digital signature and digital certificate ECx is successful (Yes in step S507), the service providing server 5 registers the "digital ID" and "user information" extracted from the digital certificate ECx and the "user data" received from the user terminal 4 in a database (step S508). When the user registration is complete, the service providing server 5 notifies the user terminal 4 that the user registration was successful (steps S509 and S510). Figure 20 shows an example of a notification screen 62 that is displayed on the user terminal 4 when the user registration is successful. Note that if the verification of the digital signature fails or the digital certificate ECx has expired, the user registration is not performed, and the service providing server 5 notifies the user terminal 4 that the user registration has failed (steps S509 and S510).

[0144] Note that since the electronic certificate ECx used here contains personal information, the "user information" of the electronic certificate ECx may contain the same items as the "user data" entered by the user (e.g., name, address, etc.). In such cases, the verification in step S505 may check whether the "user information" and the "user data" match (i.e., whether the information entered on the user terminal 4 is correct or false). If any mismatch is detected, the user registration may be interrupted, and the user terminal 4 may be notified that there is an error in the input data.

[0145] As described above, when using a digital service that requires a high level of assurance, highly reliable identity verification can be performed using an electronic certificate ECx that includes personal information. In this case, there is no need to provide personal identification documents or ID cards, and the process can be completed simply by operating an app on the user terminal 4, so the burden (complexity) on the user is small. In other words, by using the trust service provided by the electronic authentication system 1, it is possible to achieve both a high level of assurance and improved convenience for users.

[0146] (2) User Registration for Anonymously Available Digital Services The procedure for user registration for anonymously available digital services will be described with reference to Figures 21 and 22. Figure 21 shows an example of a processing sequence for user registration, and Figure 22 shows an example of a screen displayed on the user terminal 4. Examples of digital services that can be used anonymously include SNS, store search, and membership apps.

[0147] First, the user operates the user terminal 4 to launch a service app for using a digital service (step S520). When the app is launched for the first time, a user registration screen 63 such as that shown in FIG. 22 is displayed, and the user is prompted to enter user data such as a user name, residential area, and age group (step S521). The user does not need to enter a real name as the user name; a nickname or email address can be used. The residential area and age group are optional input items and are used to identify the user's general attributes. Once the user has finished entering the user data, the user data is handed over to the dedicated app.

[0148] Next, the dedicated app displays an electronic certificate selection screen 64 (step S522). The selection screen 64 displays a list of electronic certificates stored in the secure element of the user terminal 4. The selection screen 64 shown in FIG. 22 displays two options, electronic certificate ECx and electronic certificate ECy, and the user can select an electronic certificate to use for user registration for the digital service on this screen 64. Here, an electronic certificate ECy that meets the assurance level required by the digital service is selected. Of course, the user is free to select an electronic certificate ECx with a higher assurance level than the requirements of the digital service. However, since there is no need to unnecessarily disclose personal information, it is more appropriate to select an electronic certificate ECy with an assurance level necessary and sufficient for the requirements of the digital service. The service app or the dedicated app may assist the user in selecting an electronic certificate by automatically selecting or recommending an electronic certificate that best meets the requirements of the digital service.

[0149] Next, the dedicated application reads the selected electronic certificate ECy from the secure element and digitally signs the user data using the private key (step S523).Then, the service application transmits the user data with the digital signature and the electronic certificate ECy to the service providing server 5 (step S524).

[0150] The service providing server 5 verifies the electronic signature received from the user terminal 4 (step S525). Specifically, the service providing server 5 verifies the electronically signed ciphertext using the user's public key included in the electronic certificate ECy, and confirms that the electronic signature was made with the user's private key by checking whether the verification result matches the user data. The service providing server 5 also queries the certificate authority 30y, the issuer of the electronic certificate ECy, about the authenticity and validity of the electronic certificate ECy. The certificate authority 30y checks whether the electronic certificate ECy has been revoked and returns the confirmation result to the service providing server 5 (step S526).

[0151] If the verification of the electronic signature and electronic certificate ECy is successful (Yes in step S527), the service providing server 5 registers the "digital ID" extracted from the electronic certificate ECy and the "user data" received from the user terminal 4 in the database (step S528). When the user registration is complete, the service providing server 5 notifies the user terminal 4 that the user registration was successful (step S529). Figure 22 shows an example of a notification screen 65 displayed when the user registration is successful. Note that if the verification of the electronic signature fails or the electronic certificate ECy has expired, the user registration is not performed, and the service providing server 5 notifies the user terminal 4 that the user registration has failed (step S530).

[0152] As described above, when using a digital service that can be used anonymously, user registration can be performed using an electronic certificate ECy that does not include any personal information. In this case, although identity verification using personal information such as real name is not performed, "identity" is guaranteed by the digital ID linked to the electronic certificate ECy. In other words, by using the trust service provided by the electronic authentication system 1, identity can be guaranteed without disclosing the user's personal information, which is beneficial to both the user and the service provider.

[0153] (3) Logging in to a Digital Service (User Authentication) The procedure for user authentication when logging in to a digital service will be described with reference to Fig. 23. Fig. 23 shows an example of a processing sequence for user authentication.

[0154] First, the user operates the user terminal 4, launches a service app for using the digital service, and performs a login operation (step S600). The dedicated app then selects an electronic certificate to be used for user authentication from among the electronic certificates stored in the secure element (step S601). Technically, any electronic certificate issued by any certification authority can be used for user authentication. Therefore, unless there are special restrictions or requirements, it is recommended to use electronic certificate ECy, which does not contain personal information, for user authentication. However, if the digital service requires the use of an electronic certificate with a high assurance level for user authentication, electronic certificate ECx, which contains personal information, is used for user authentication. The dedicated app may automatically determine which electronic certificate to select based on the assurance level required by the digital service. Here, the following explanation will be continued assuming that electronic certificate ECy is selected.

[0155] The dedicated application reads the selected electronic certificate ECy from the secure element and digitally signs the login message using the private key (step S602).Then, the service application transmits the digitally signed login message and the authentication electronic certificate ECy to the service providing server 5 (step S603).

[0156] The service providing server 5 verifies the digitally signed login message received from the user terminal 4 (step S604). Specifically, the service providing server 5 verifies the digitally signed ciphertext using the user's public key included in the digital certificate ECy, and by checking that the verification result matches the login message, confirms that the digital signature was issued using the user's private key. The service providing server 5 also queries the certificate authority 30y, the issuer of the digital certificate ECy, about the authenticity and validity of the digital certificate ECy. The certificate authority 30y checks whether the digital certificate ECy has been revoked and returns the verification result to the service providing server 5 (step S605).

[0157] If the verification of the digital signature and digital certificate ECy is successful (Yes in step S606), the service providing server 5 checks whether the digital ID listed in the digital certificate ECy is registered in the user database (i.e., whether the user is a registered user) (step S607). If the digital ID is a registered digital ID (Yes in step S607), the service providing server 5 issues an ID token to the user terminal 4 (step S608). Thereafter, the user terminal 4 uses this ID token to communicate with the digital services of the service providing server 5.

[0158] If the verification of the electronic signature fails, if the electronic certificate ECy has expired, or if the digital ID is not registered, the service providing server 5 notifies the user terminal 4 that the login has failed (step S609).

[0159] As described above, by using a digital certificate for user authentication when logging in, it is not necessary to input a login ID or password, which simplifies the login process. Furthermore, by performing user authentication that combines a digital certificate and a digital ID, it is possible to reliably prevent unauthorized logins such as spoofing. Furthermore, the digital ID can guarantee the identity of the user, regardless of whether the user uses their real name or is anonymous.

[0160] (4) Linking an Existing Login ID to a Digital ID Let's consider a scenario in which a user switches from using a digital service that uses a login ID and password for authentication to using a digital certificate from this Trust Service for user authentication. When switching to this scenario, the existing login ID used for user authentication of the digital service must be linked (integrated) with the user's digital ID. Figure 24 shows an example of the process of linking a digital ID to an existing login ID.

[0161] First, the user operates the user terminal 4, launches a service app for using the digital service, and logs in to the digital service using their existing login ID and password (steps S650 and S651). After user authentication using the existing login ID, an electronic certificate and digital ID are registered during that authentication session. When a request for linking the digital ID is made on the service app (step S652), the dedicated app selects an electronic certificate to be used for user authentication from among the electronic certificates stored in the secure element (step S653). Technically, any electronic certificate issued by any certification authority can be used for user authentication. Therefore, unless there are special restrictions or requirements, it is recommended to use an electronic certificate ECy that does not contain personal information for user authentication. However, if the digital service requires the use of an electronic certificate with a high assurance level for user authentication, an electronic certificate ECx that contains personal information is used for user authentication. The dedicated app may automatically determine which electronic certificate to select based on the assurance level required by the digital service. Here, the following explanation will be continued assuming that electronic certificate ECy is selected.

[0162] The dedicated application reads the selected electronic certificate ECy from the secure element and digitally signs the message using the private key (step S654).The service application then transmits the message with the digital signature and the authentication electronic certificate ECy to the service providing server 5 (step S655).

[0163] The service providing server 5 verifies the digitally signed message received from the user terminal 4 (step S656). Specifically, the service providing server 5 verifies the digitally signed ciphertext using the user's public key included in the digital certificate ECy, and by checking that the verification result matches the message, confirms that the digital signature was made using the user's private key. The service providing server 5 also queries the certificate authority 30y, the issuer of the digital certificate ECy, about the authenticity and validity of the digital certificate ECy. The certificate authority 30y checks whether the digital certificate ECy has been revoked and returns the confirmation result to the service providing server 5 (step S657).

[0164] If the verification of the electronic signature and electronic certificate ECy is successful (Yes in step S658), the service providing server 5 links the digital ID written in the electronic certificate ECy to the login ID and user data of the user registered in the user database (step S659). If the linking of the digital ID is successful, the service providing server 5 transmits a notification that the linking was successful to the user terminal 4 (step S660). If the verification of the electronic signature fails, if the electronic certificate ECy has expired, or if the linking of the digital ID fails, the service providing server 5 notifies the user terminal 4 that the linking has failed (step S661).

[0165] By the above-described processing, digital services that have been used in conventional login ID / password authentication can be incorporated into the framework of trust services related to the electronic authentication system 1.

[0166] <Service Linkage Across Digital Certificates> In a situation where a user uses two services A and B operated by different businesses, even if the user wishes to use their own information stored in service B in service A, it is practically difficult to link data between the different businesses. This is because there is no system that allows the businesses to confirm and reliably determine whether the user using service A and the user using service B are in fact the same person.

[0167] In this regard, under the trust service provided by the electronic authentication system 1 of this proposal, the identity and integrity of the user can be confirmed using a digital ID, allowing data to be exchanged safely and easily between multiple services that the user uses using an electronic certificate.

[0168] If such secure inter-service collaboration can be achieved, it can be expected to be applied in a variety of situations. For example, providing electronic medical records from Hospital B to Hospital A, providing data from Pharmacy B to Medical Institution A, providing transaction history from Bank B to FinTech Service A, providing purchase data from Online Shopping Service B to Advertising Service A, and providing reservation information from Travel Booking Site B to Rental Car Booking Site A are just a few examples.

[0169] Below, we will explain two specific methods for achieving inter-service collaboration: (1) inter-service collaboration via a data collaboration platform, and (2) direct inter-service collaboration.

[0170] (1) Service-to-service collaboration via a data collaboration platform The electronic authentication system 1 shown in Fig. 25 includes a data collaboration server 7. The data collaboration server 7 serves as a data collaboration platform that centrally manages user authentication and authorization of data collaboration. For example, a framework such as OIDC (OpenID Connect) or OAuth may be used as the authentication and authorization method.

[0171] In Figure 25, reference numeral 5a denotes a service providing server that provides service A. When a user uses service A, user registration and user authentication are performed using an electronic certificate linked to a digital ID, and the service providing server 5a stores and manages user data in association with the digital ID, which is the user's personal identifier. Similarly, service providing server 5b that provides service B stores and manages user data in association with the user's digital ID. Even if a user uses services A and B anonymously (and with different user names), it is possible to determine whether the data belongs to the same user by checking that the digital IDs match.

[0172] The following describes the procedure for providing user data of a user stored in service B to service A. It is assumed that the user has previously agreed to "providing user data stored in service B to service A," and that the consent information is registered in the consent database of the data linkage server 7.

[0173] First, the user logs in to the data link server 7 from the user terminal 4 and requests authorization (step T1). User authentication uses a digital signature using the user's private key and a digital certificate of the corresponding public key (step T2). At this time, a facial image of the user, biometric information, identification (My Number card or IC passport), etc. may be combined.

[0174] The data linkage server 7 verifies the validity and authenticity of the user's digital signature and digital certificate by inquiring with the certificate authority 30 (step T3). If the verification is successful (i.e., if it is confirmed that the user is actually logged in), the data linkage server 7 issues an authorization code (step T4). The authorization code indicates that the user has been authorized to link services via the data linkage platform. The authorization code is used when the service providing server obtains an ID token for accessing the data linkage platform.

[0175] When the user terminal 4 receives the authorization code, it automatically transitions to the login page of service A and logs in to service A with the authorization code (step T5). The service providing server 5a then presents the authorization code to the data linkage server 7 and requests an ID token (step T6). The data linkage server 7 verifies the validity and legitimacy of the authorization code, and if the verification is successful, issues an ID token to the service providing server 5a (step T7). The ID token is a temporary permit for the service providing server 5a to access the data linkage platform.

[0176] Thereafter, the user requests data linkage with service B from service A via the user terminal 4 (step T8). The service providing server 5a then presents the ID token to the data linkage server 7 to request an access token (step T9). The data linkage server 7 verifies the validity and authenticity of the ID token, and if the verification is successful, issues an access token to the service providing server 5a (step T10). The access token is a temporary permit for the service providing server 5a to access other service providing servers. A limited access token that specifies the service to be linked may be used, or a general-purpose access token that does not specify the service to be linked may be used.

[0177] Upon acquiring the access token, the service providing server 5a presents the access token and requests data from the service providing server 5b (step T11). The service providing server 5b queries the data linkage server 7 to verify the validity and legitimacy of the access token, and to confirm whether the user has agreed to provide the user data stored in service B to other services, the scope of information that may be provided (for example, whether personal information may be disclosed), and the like. The service providing server 5b is notified of the verification and confirmation results along with the user's digital ID. The data linkage server 7 manages the authorization code, ID token, and access token that it issues in association with the user's digital ID, and therefore can identify the user and their digital ID based on the access token presented by the service providing server 5b.

[0178] The service providing server 5b identifies the user of service B by the digital ID (step T13), and provides the user's data to the service providing server 5a (step T14).

[0179] According to the above-described procedure, data can be linked between services A and B operated by different operators. At this time, the user terminal 4, data linking server 7, service A, and service B each verify the identity and consistency of the user using a digital ID, thereby ensuring high security and the necessary level of assurance while enabling data linking through a simple procedure.

[0180] (2) Direct Inter-Service Collaboration Fig. 26 shows an example in which the servers of Service A and Service B directly collaborate on data without using a data collaboration platform. The procedure for providing user data of a user stored in Service B to Service A will be described with reference to Fig. 26.

[0181] First, the user logs in to the service app on the user terminal 4 (step U1). An electronic certificate is used for user authentication. At this time, a facial image of the user, biometric information, identification (My Number card or IC passport), etc. may be combined. The service app verifies the validity and authenticity of the user's electronic certificate by inquiring with the certification authority 30 (step U2). If the verification is successful, the service app on the user terminal 4 automatically transitions to the login page of service A and the user logs in to service A (step U3).

[0182] Thereafter, the user requests service A to link data with service B from the user terminal 4 (step U4). This data link request includes the user's digital signature and digital certificate. The service providing server 5a queries the certificate authority 30 and verifies the validity and authenticity of the digital signature and digital certificate (step U5). If the verification is successful, the service providing server 5a sends a request for service linkage to the service providing server 5b together with the digital ID linked to the digital certificate (step U6).

[0183] Upon receiving the request for inter-service collaboration, the service providing server 5b inquires of the user terminal 4 about whether data collaboration with service A is permitted (step U7). At this time, the user terminal 4 can be identified by the digital ID notified in step U6. If the user gives consent on the confirmation screen displayed on the user terminal 4, the service app automatically transitions to the login page for service B, logs in to service B, and then notifies the service providing server 5b that data collaboration with service A is permitted (step U8). The service providing server 5b verifies that the service app login request includes the user's digital signature. The service providing server 5b inquires of the certificate authority 30 and verifies the validity and authenticity of the digital signature and digital certificate (step U9). If the verification is successful, the service providing server 5b issues an access token to the service providing server 5a (step U10).

[0184] When the service providing server 5a acquires the access token, it presents the access token and requests data from the service providing server 5b (step U11). The service providing server 5b provides the requested data to the service providing server 5a (step U12). At this time, the user is identified by the digital ID notified in step U6.

[0185] According to the procedure described above, data can be linked between services A and B operated by different operators. At this time, the identity and identity of the user are confirmed by the digital ID at each of the user terminal 4, service A, and service B, thereby ensuring high security and the necessary level of assurance while enabling data linkage through a simple procedure.

[0186] <Others> In the above embodiment, a passport-based eKYC card was proposed. However, since there are currently multiple passport-based eKYC services, it is possible to use such services instead of the proposed one. Existing passport-based eKYC services are divided into two types: one that reads the passport's IC chip with an NFC-enabled terminal and transmits information, and one that reads the passport's facial image and then transmits information. Examples of the former type of service include Nets Passport Reader, LibJeID, and Jumio. Nets has a high security standard known as eIDAS High, and is a service designed for use within the EU. LibJeID can access official IC cards commonly used in Japan, and is a service designed for use in Japan. Jumio provides ID verification solutions and has a proven track record in over 200 countries.

[0187] On the other hand, eKYC services that read facial images printed on passports include LIQUID eKYC and TRUSTDOCK. Compared to services that read IC chip information, services that read facial images printed on identity documents have the advantage that an NFC-compatible terminal is not required to implement eKYC. However, there is also the risk that identity verification may not be performed correctly due to deterioration of the passport itself, and that the facial image on the passport may be counterfeit.

[0188] According to the present embodiment described above, the separate handling of digital IDs and electronic certificates has been revised, enabling a trust service model that can handle both of them comprehensively. By using digital IDs issued by this model, users can use multiple electronic certificates depending on the service. Furthermore, the components of this model are highly customizable, enabling appropriate assurance levels for each service and the provision of services to countries and regions outside of Japan. By incorporating a person's attribute information, qualification information, and characteristics into the digital ID, authorization can be provided in addition to authentication, based on the person's attributes.

[0189] In the above-described embodiment, the My Number card and the IC passport are used as official identification documents for identity verification, but other official identification documents may also be used, such as Pakistan's Computerized National Identity Card (CNIC), Indonesia's Kartu Tanda Penduduk Elektronik (e-KTP), India's Aadhaar card, and the Philippines' ePhilID card.

Claims

1. an ID provider that issues a digital ID to a user after verifying the user's identity; a first certification authority that issues a first digital certificate to the user, the first digital certificate being certified by a national government; a second certification authority that issues a second digital certificate to the user, the second digital certificate being certified by the second certification authority or a private third party organization; the first certificate authority describes the digital ID issued to the user by the ID provider in the first digital certificate; The second certificate authority writes the same digital ID as that in the first digital certificate in the second digital certificate. Electronic authentication system.

2. The digital ID is an identifier in a format that cannot identify the individual user by itself. The electronic authentication system of claim 1 .

3. the first digital certificate describes the first public key and the digital ID of the user, and a digital signature of the first certificate authority is affixed to a data description including the first public key and the digital ID; The second digital certificate contains the second public key and the digital ID of the user, and a digital signature of the second certification authority is affixed to a data description including the second public key and the digital ID. The electronic authentication system of claim 1 .

4. the first digital certificate is a digital certificate with a higher assurance level than the second digital certificate; The electronic authentication system of claim 1 .

5. the first electronic certificate includes personal information of the user; The second digital certificate does not include personal information of the user. The electronic authentication system according to any one of claims 1 to 4.

6. The ID provider verifies the user's identity using an eKYC with an official identification card. The electronic authentication system of claim 1 .

7. Verifying the user's identity through eKYC using an official identification card; issuing a digital ID to said user after identity verification; a step of the first certification authority issuing a first digital certificate to the user, the first digital certificate being certified by a country; a step in which the second certification authority issues a second digital certificate to the user, the second digital certificate being certified by the second certification authority or a private third party; storing the digital ID, the first digital certificate, and the second digital certificate in a memory of a user terminal of the user; and the first certificate authority, when issuing the first digital certificate, describes the digital ID issued to the user in the first digital certificate; The electronic authentication method, wherein the second certification authority, when issuing the second electronic certificate, describes the same digital ID as that of the first electronic certificate in the second electronic certificate.

8. a step of having the user select an electronic certificate to be used when registering the user for a service provided by a service providing server from a plurality of electronic certificates including the first electronic certificate and the second electronic certificate; digitally signing user data required for user registration using a private key corresponding to the selected digital certificate; transmitting the selected digital certificate and the user data with the digital signature to the service providing server; a step of verifying the selected digital certificate and the digital signature in the service providing server, and if the verification is successful, registering a digital ID extracted from the selected digital certificate and the user data in a database; The electronic authentication method of claim 7, comprising:

9. Logging in to a second service provided by a second service providing server using user authentication with a login ID and a password; having the user select an electronic certificate to be used for the second service from a plurality of electronic certificates including the first electronic certificate and the second electronic certificate; transmitting the selected digital certificate to the second service providing server; In the second service providing server, a digital ID extracted from the selected digital certificate is associated with the login ID; The electronic authentication method of claim 7, comprising:

10. Log in to a first service provided by a first service providing server from the user terminal. and a step of requesting, from the user terminal to the first service providing server, data linkage with a second service provided by a second service providing server while logged in to the first service; The first service providing server acquires an access token from a data link server; the first service providing server presenting the access token to request data from the second service providing server; the second service providing server inquiring about the validity of the access token from the data link server; The second service providing server acquires a digital ID of the user who has requested data linkage from the data linkage server; the second service providing server identifying a user of the second service by the digital ID and providing data of the user to the first service providing server; The electronic authentication method of claim 7, comprising:

11. Logging in to a first service provided by a first service providing server from the user terminal; a step of transmitting a request for data linkage with a second service provided by a second service providing server and an electronic certificate from the user terminal to the first service providing server while logged in to the first service; transmitting a request for inter-service cooperation to the second service providing server together with a digital ID linked to the digital certificate received by the first service providing server; the second service providing server identifying a user of the second service by the digital ID and providing data of the user to the first service providing server; The electronic authentication method of claim 7, comprising: