Information processing device, information processing method, and information processing program

Abstract

To further improve the efficiency of authentication.SOLUTION: An information processing device which is an information processing device of a credential issuer includes: a credential issuance unit that issues a verifiable credential about a user; a credential provision unit that provides the verifiable credential to a terminal device of the user; a cassette creation unit that creates a cassette having the function of updating the verifiable credential; and a cassette provision unit that provides the cassette to the terminal of the user.SELECTED DRAWING: Figure 3

Description

Technical Field

[0007]

[0001] The present invention relates to an information processing apparatus, an information processing method, and an information processing program.

Background Art

[0002] Techniques related to FIDO (Fast Identity Online), in which a technique using an authenticator is disclosed (see Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the above prior art, there is still room for improvement regarding FIDO authentication, including the confirmation of the identity of the person at the time of authentication.

[0005] The present application has been made in view of the above, and an object thereof is to further improve the efficiency of authentication.

Means for Solving the Problems

[0006] The information processing apparatus according to the present application An information processing device that handles verifiable certificates, a certificate issuer As a function , a certificate issuing unit that issues a verifiable certificate regarding a user, a certificate providing unit that provides the verifiable certificate to the terminal device of the user, and a cassette creating unit that creates a cassette having a function of updating the verifiable certificate, A cassette key creation unit creates a key pair consisting of a cassette verification private key used for signing when the cassette updates the verifiable certificate on the user's terminal device side, and a cassette verification public key for verifying the signature made by the cassette; and a cassette key registration unit registers the cassette verification public key in a public repository. the cassette along with the private key for verifying the cassette and a cassette providing unit that provides the cassette to the terminal device of the user.

Effects of the Invention

[0007] According to one embodiment, the efficiency of authentication can be further improved. [Brief explanation of the drawing]

[0008] [Figure 1] Figure 1 is an explanatory diagram illustrating the overview of FIDO authentication. [Figure 2] Figure 2 is an explanatory diagram illustrating the conceptual framework for the distribution method of verifiable certificates (VCs). [Figure 3] Figure 3 is an explanatory diagram showing an overview of the certificate distribution device according to the embodiment. [Figure 4] Figure 4 shows an example of the configuration of an information processing system according to the embodiment. [Figure 5] Figure 5 shows an example of the configuration of a terminal device according to this embodiment. [Figure 6] Figure 6 shows an example of the configuration of a server device according to the embodiment. [Figure 7] Figure 7 shows an example of a user information database. [Figure 8] Figure 8 shows an example of a historical information database. [Figure 9] Figure 9 shows an example of a key information database. [Figure 10] Figure 10 shows an example of a cassette information database. [Figure 11] Figure 11 is a sequence diagram showing the processing procedure according to the embodiment. [Figure 12] Figure 12 shows an example of a hardware configuration. [Modes for carrying out the invention]

[0009] The following describes in detail, with reference to the drawings, embodiments for implementing the information processing device, information processing method, and information processing program according to the present application (hereinafter referred to as "embodiments"). Note that these embodiments do not limit the information processing device, information processing method, and information processing program according to the present application. Furthermore, the same parts are denoted by the same reference numerals in the following embodiments, and redundant descriptions are omitted.

[0010] [1. Overview of Information Processing Methods] First, let's refer to Figure 1 and explain the overview of FIDO authentication. Figure 1 is an explanatory diagram showing the overview of FIDO authentication. Figure 1 also explains the basic mechanism of FIDO authentication.

[0011] As shown in Figure 1, the information processing system 1 includes a terminal device 10 and a server device 100. The terminal device 10 and the server device 100 are connected to each other via a network N (see Figure 4) by wire or wireless means so that they can communicate with each other. In this embodiment, the terminal device 10 cooperates with the server device 100.

[0012] Terminal device 10 is a smart device such as a smartphone or tablet used by user U, and is a mobile terminal device capable of communicating with any server device via a wireless communication network such as 4G (Generation) or LTE (Long Term Evolution). Terminal device 10 also has a screen such as an LCD display with touch panel functionality, and accepts various operations on displayed data such as content from user U using a finger or stylus, such as tapping, sliding, and scrolling. Operations performed on the area of ​​the screen where content is displayed may also be considered operations on the content. Furthermore, terminal device 10 may be not only a smart device, but also an information processing device such as a desktop PC (Personal Computer) or a notebook PC.

[0013] In this embodiment, the terminal device 10 functions as a FIDO client in FIDO authentication (Fast Identity Online). The FIDO client performs user authentication in cooperation with an authenticator. Note that the authenticator may be implemented on the same device as the FIDO client (built-in authenticator), or may be implemented on a device physically different from the FIDO client (external authenticator).

[0014] For example, in FIDO authentication, authentication methods using memorized items or possessions such as PIN (Personal Identification Number), USB (Universal Serial Bus) security keys, and smart cards, or authentication methods using biometric information or behavioral information such as fingerprints, faces, irises, veins, and voiceprints can be implemented. The authentication method is not limited to these, and any method can be introduced. Also, multi-modal biometric authentication or multi-factor authentication can be realized by combining multiple authentication methods.

[0015] Hereinafter, for simplicity of explanation, the FIDO client and the authenticator are not distinguished, and the terminal device 10 will be described as a FIDO client and an authenticator. That is, the case where the authenticator is an internal authenticator will be described as an example. In actuality, the authenticator may be an external authenticator physically independent from the terminal device 10 and capable of cooperating with the terminal device 10.

[0016] Also, a Web authentication API (Application Programming Interface) for calling the authenticator from web content displayed on the Web browser of the FIDO client and enabling FIDO authentication in the communication with the authentication server can be implemented, but the description thereof is omitted in this embodiment.

[0017] Server device 100 is an information processing device that functions as an authentication server (FIDO server) in FIDO authentication, and is implemented by a computer or cloud system. The authentication server corresponds to an RP (Relying Party) / IdP (Identity Provider). An RP (Relying Party) refers to an entity or organization that implements the FIDO server. In FIDO authentication, "secrets" such as passwords and biometric information are not shared between the authenticator and the authentication server, making it resistant to phishing.

[0018] As shown in Figure 1, in FIDO authentication, when the authentication server receives an authentication request from a user, it sends a challenge to the user's authenticator. The challenge is a random string that is valid only once and is a different data sequence each time, determined based on a random number. The user performs user verification using the authenticator and verifies their identity locally. The authenticator then signs the verification result with its private key and sends it to the authentication server as a signed response. When the authentication server receives the signed response, it verifies the signature with its public key. The pair of private and public keys is called a key pair.

[0019] The key pair for FIDO registration is, for example, the key pair consisting of the private key used to sign the authenticator certificate (Attestation) (registration private key) and the public key used to verify it (registration public key). The key pair for FIDO authentication is, for example, the key pair consisting of the private key used to sign the certificate of user verification result (Assertion) at the authenticator (authentication private key) and the public key used to verify it (authentication public key).

[0020] Thus, in FIDO authentication, the authentication server uses a public key to verify that the user's authenticator possesses the appropriate private key, thereby achieving authentication. The authenticator and the authentication server do not share the "private key".

[0021] Furthermore, the server device 100 also functions as a federated RP / SP (Service Provider) that provides identity services through identity federation with an RP / IdP that supports FIDO authentication. When FIDO authentication and identity federation are combined, the authentication context is propagated from the authenticator to the federated RP / SP via the RP / IdP.

[0022] For the sake of simplicity, the following explanation will not distinguish between RP / IdP and collaborative RP / SP, and will describe server device 100 as both RP / IdP and collaborative RP / SP. In practice, however, the server device acting as RP / IdP and the server device acting as collaborative RP / SP may be physically separate and independent server devices.

[0023] For example, the server device 100 may cooperate with each user U's terminal device 10 and provide each user U's terminal device 10 with API (Application Programming Interface) services for various applications (hereinafter referred to as "apps"), as well as various data.

[0024] Furthermore, the server device 100 may be an information processing device that provides some kind of Web service online to each user U's terminal device 10. For example, the server device 100 may provide services such as internet connection, search services, SNS (Social Networking Service), e-commerce (EC), electronic payment, online games, online banking, online trading, accommodation / ticket reservations, video / music distribution, news, maps, route search, route guidance, route information, service information, and weather forecasts as Web services. In practice, the server device 100 may cooperate with various servers that provide the above-mentioned Web services and act as an intermediary for Web services, or it may be responsible for processing Web services.

[0025] Furthermore, the server device 100 can acquire user information about user U. For example, the server device 100 acquires information about user U's attributes, such as gender, age, and residential area. The server device 100 then stores and manages information about user U's attributes along with identification information (such as user ID) that identifies user U.

[0026] Furthermore, the server device 100 acquires various historical information (log data) indicating user U's actions from user U's terminal device 10, or from various servers based on the user ID, etc. For example, the server device 100 acquires location history, which is the history of user U's location and date and time, from the terminal device 10. The server device 100 also acquires search history, which is the history of search queries entered by user U, from the search server (search engine). The server device 100 also acquires browsing history, which is the history of content viewed by user U, from the content server. The server device 100 also acquires purchase history (payment history), which is the history of user U's product purchases and payment processing, from the e-commerce server or payment processing server. The server device 100 may also acquire listing history and sales history, which are the history of user U's listings on the marketplace, from the e-commerce server or payment processing server. The server device 100 also acquires posting history, which is the history of user U's posts, from posting servers that provide word-of-mouth posting services or SNS servers. The various servers mentioned above may also be the server device 100 itself. In other words, the server device 100 may function as the various servers mentioned above.

[0027] [1-1. Distribution of verifiable certificates] Verifiable Credentials (VCs) are digital certificates used to have attribute information verified by a third party. They play a role in linking attribute information to an identity represented by a Decentralized Identifier (DID) (an identity not linked to attribute information). For example, VCs can store information representing the attributes of a physically existing individual, such as a driver's license, academic transcripts, professional certifications, and other confidential data. In reality, a VC is not the information itself, but rather a container that stores that information, and the authenticity of that container can be verified (like a verifiable shipping container).

[0028] Figure 2 is an explanatory diagram illustrating the outline of the concept for the distribution method of verifiable certificates (VCs). This concept is a standard specification recommended by the W3C and defines a reliable and privacy-conscious method for distributing data. Among the multiple server devices 100 (100-i, i=1 to n: n is arbitrary), server device 100-1 of the business that issues certificates is designated as the "Certificate Issuer," and server device 100-2 of the company that verifies certificates is designated as the "Certificate Verifier." Furthermore, user U and their terminal device 10 (authentication device) are designated as "Certificate Holders." In addition, repository 200 is designated as a common "Verifiable Data Registry" among the server devices 100. Repository 200 stores verification data such as public keys.

[0029] The repository 200 may be an independent database or one of several server devices 100. In other words, the repository 200 may be installed on one of several server devices 100. Furthermore, the repository 200 may manage verification data such as public keys on a blockchain using distributed ledger technology (DLT). For example, the repository 200 may be a node that constitutes a blockchain network.

[0030] For example, as shown in Figure 2, the server device 100-1 of the business operator, which is the certificate issuer, creates a verifiable certificate (VC). At this time, the server device 100-1 of the business operator, which is the certificate issuer, creates a private key and a public key pair and signs the verifiable certificate (VC) with the private key. The server device 100-1 of the business operator, which is the certificate issuer, also registers verification data such as the public key in the repository 200, which is the Verifiable Data Registry. The server device 100-1 of the business operator, which is the certificate issuer, also issues the verifiable certificate (VC) to the terminal device 10 (authentication device) of user U, which is the certificate holder.

[0031] The terminal device 10 (authentication device) of user U, who is the certificate holder, stores the issued verifiable certificate (VC). Furthermore, the terminal device 10 (authentication device) of user U, who is the certificate holder, presents the verifiable certificate (VC) to the server device 100-2 of the company, which is the certificate verifier. For example, the terminal device 10 (authentication device) of user U, who is the certificate holder, stores the verifiable certificate (VC) in a VC management application (e.g., a wallet application), and when the VC management application (e.g., a wallet application) is used at a store, the terminal device 10 (authentication device) presents the verifiable certificate (VC) to the server device 100-2 of the company, which is the certificate verifier at the store.

[0032] In this concept, individual signed and issued verifiable certificates (VCs) can be combined and presented as a single verifiable presentation certificate (VP). The VP includes one or more verifiable certificates (VCs) and is presented to the server device 100-2 of the company that is the certificate verifier.

[0033] The company's server device 100-2, which is the certificate verifier, verifies the presented verifiable certificate (VC) by referring to verification data such as public keys registered in the repository 200, which is the verifiable data registry. For example, the company's server device 100-2, which is the certificate verifier, uses the public key registered in the repository 200, which is the verifiable data registry, to verify the signature of the signed issued verifiable certificate (VC) contained in the presented certificate (VP).

[0034] However, with traditional verifiable certificates (VCs), the certificate's contents are signed, so once a signed certificate is issued, user U cannot update it. In other words, once a verifiable certificate (VC) is signed, the data of that verifiable certificate (VC) cannot be updated.

[0035] For example, suppose a server device 100-1 of a business that issues certificates creates and issues a verifiable certificate (VC) of user U's driver's license, which will act as the terminal device 10 (authentication device) of user U, the holder of the certificate. If user U's verifiable certificate (VC) contains information that user U does not want to disclose to the other party (e.g., place of origin information), user U cannot use the certificate. Alternatively, user U may be forced to disclose the certificate against their will. Therefore, if a verifiable certificate (VC) contains information that user U does not want to disclose to the other party, problems arise such as the inability to utilize the information or the leakage of privacy.

[0036] However, even if you wish to remove information you don't want to disclose to the other party from a verifiable certificate (VC), once it's signed, changing even a single character of the data will alter the signature information and be considered tampering, making certificate verification impossible (unsuccessful).

[0037] [1-2. Certificate Distribution Device] Figure 3 is an explanatory diagram showing an overview of a certificate distribution device according to this embodiment. In this embodiment, it is possible to renew, issue, and distribute signed, issued verifiable certificates (VCs). Specifically, the certificate issuer creates a VC update cassette (hereinafter referred to as the cassette) that has the function to update verifiable certificates (VCs) and distributes it in a form in which its reliability can be verified. The certificate holder then retrieves and operates the cassette, causing the cassette to update the certificate. The certificate verifier verifies the authenticity of the updated certificate by verifying the authenticity of the cassette.

[0038] In this case, selective disclosure of attribute information may be performed on the verifiable certificate (VC). In selective disclosure of attribute information, a presentation certificate (VP) is dynamically created in which attribute information that does not need to be collected is obscured so that it cannot be read. Examples of obscuration include blacking out, blurring, mosaic, image overlay, text / image conversion, encryption, blanking out / deleting, etc. However, in practice, it is not limited to these examples. The means (methods) of obscuration are arbitrary. Through this, only attribute information agreed upon between the data requester and the data provider can be exchanged.

[0039] For example, as shown in Figure 3, the server device 100, which is the certificate issuer, provides a VC management application (e.g., a wallet application) to the terminal device 10 (authenticator) of user U, who is the certificate holder, via network N (see Figure 4). The terminal device 10 (authenticator) of user U, who is the certificate holder, installs the VC management application provided by the certificate issuer. This VC management application has a VC creation function, a VC update function, and a VC storage function.

[0040] The VP creation function is a function that creates a single presented certificate (VP) by combining one or more signed issued verifiable certificates (VCs). The VC update function is a function that updates signed issued verifiable certificates (VCs). The VC storage function is a function that stores the updated verifiable certificates (VCs). In the example in Figure 3, each of the VC update cassette group (C1, C2, ..., Cn (where n is arbitrary)), which is a cassette imported into the VC management application, has the VC update function. C1, C2, ... represent individual cassettes. The VC storage function stores the group of signed issued verifiable certificates (VCs) (VC1, VC2, ..., VCn (where n is arbitrary)). VC1, VC2, ... represent individual verifiable certificates (VCs).

[0041] [1-2-1. Renewal of Verifiable Certificates (VC)] The intentions and processes involved in updating verifiable certificates (VCs) via cassettes imported into the VC management application include, for example, "deletion of information," "obfuscation of information," "anonymization of information," and "processing of information." However, these are merely examples; in reality, the process is not limited to these examples.

[0042] (1) Deletion of information For example, a cassette imported into the VC management app will not include unnecessary information (such as information you don't want to disclose to others) in the verifiable certificate (VC). In other words, a cassette imported into the VC management app removes unnecessary information from the verifiable certificate (VC). Furthermore, a cassette imported into the VC management app eliminates redundant information (such as information that overlaps between VCs) when creating a presented certificate (VP).

[0043] (2) Information ambiguity For example, if a cassette imported into the VC management app has user U's age information as "Age: 30 years old," but it is sufficient to know that the user is 20 years old or older, change it to "Age: 20 years old or older," etc. Also, if user U's location information, such as their place of residence or workplace, is "135.55 degrees East longitude, 35.55 degrees North latitude," but you want to be vague about the decimal part without showing the precise value, change it to "135 degrees East to 136 degrees East longitude, 35 degrees North to 36 degrees North latitude," etc. Alternatively, if user U's location information, such as their place of residence or workplace, is "Less than 1km radius from point A," but you want to be vague with a more general value without showing the precise value, change it to "Less than 5km radius from point A," etc.

[0044] (3) Anonymization of information For example, a cassette imported into the VC management app changes user U's account information from "User ID: taro-tanaka" to "ID: anonymous" (anonymous). Alternatively, it changes user U's account information from "User ID: taro-tanaka" to "ID: one of the people in Department A" (not specifically identified, but a member of the group).

[0045] (4) Processing of information For example, if a cassette imported into a VC management app has the values ​​"A=1", "B=2", and "C=1", it will be changed to "A+B+C=4". In this way, when the components are known, instead of showing the individual components, the total value is calculated and presented, obscuring the information by showing only the total value without showing the breakdown.

[0046] [1-2-2. VC Update Cassette] The cassette is a VC update cassette that has the function of updating verifiable certificates (VCs), and may be implemented in either software or hardware. The cassette performs predetermined updates (deletion, ambiguation, anonymization, processing, etc.) using predetermined processes (calculations, algorithms, etc.). The authenticity of the cassette is verifiable. Methods for verifying the authenticity of the cassette include verifying the signature in the binary information of the verifiable certificate (VC), or checking whether it returns an appropriate response (output) to a predetermined request (input).

[0047] Furthermore, any entity (such as a business) can create a cassette, and its reliability can be judged by others by disclosing its processing details (such as algorithms). A cassette may also be created for each issued verifiable certificate (VC). Additionally, a cassette may be created for each individual update to a verifiable certificate (VC) (such as deletion, ambiguation, anonymization, or modification).

[0048] At this time, the server device 100-1 of the business operator, which is the certificate issuer and provider of the VC management application, registers the public key of the cassette corresponding to the cassette (public key for cassette verification) in the VC update cassette management repository 200. The certificate verifier verifies the appropriateness of the updated verifiable certificate (updated VC) by verifying the authenticity of the encrypted VC, which is the binary information (encryption information) of the original verifiable certificate (VC) before the cassette update, and the authenticity of the cassette. The authenticity of the original encrypted VC can be verified with the public key (public key for VC verification) of the certificate issuer. The authenticity of the cassette can be verified with the public key (public key for cassette verification) of the cassette. For example, the server device 100-1 verifies the signature using the private key (private key for cassette verification) of the cassette using the public key (public key for cassette verification) of the cassette.

[0049] (1) Cassette registration For example, server device 100-1 of a business that is both a certificate issuer and a provider of a VC management application (e.g., a wallet application) creates its own cassette (e.g., an information deletion cassette). At this time, server device 100-1 creates a key pair consisting of the cassette's private key (cassette verification private key) and the cassette's public key (cassette verification public key). Server device 100-1 registers the cassette's public key (cassette verification public key) in the VC update cassette management repository 200. Simultaneously, it also registers and publishes the cassette's intent and processing details as public information. The cassette's public key (cassette verification public key) and the cassette's intent and processing details (public information) may be linked. A certificate verifier can check what actions were taken by the cassette by referring to the public information registered in repository 200. The private key for the cassette (private key for cassette verification) will be provided to the VC management application (e.g., wallet application) along with the cassette, as described later.

[0050] (2) VC storage The terminal device 10 (authentication device) of user U (the holder of the certificate) receives a signed verifiable certificate (VC) (e.g., a driver's license with registered domicile information) from the server device 100-1 of the business that is the issuer of the certificate, and stores it in a VC management application (e.g., a wallet application). At the same time, the terminal device 10 (authentication device) also receives a signed encrypted VC, which is the binary information (encrypted information) of the verifiable certificate (VC), from the server device 100-1 of the business that is the issuer of the certificate, and stores it in a VC management application (e.g., a wallet application). The encrypted VC is, for example, the binary information of the verifiable certificate (VC). The encrypted VC can be signed with the private key (private key for VC verification) of the issuer of the certificate.

[0051] At this time, the server device 100-1 of the business operator, which is the certificate issuer, creates a key pair between the certificate issuer's private key (private key for VC verification) and the certificate issuer's public key (public key for VC verification) when issuing a verifiable certificate (VC) (e.g., a driver's license with registered domicile information). Then, the server device 100-1 signs the encrypted VC, which is the binary information (encrypted information) of the verifiable certificate (VC), using the certificate issuer's private key (private key for VC verification). In addition, the server device 100-1 stores the certificate issuer's private key (private key for VC verification) internally (or in a secure storage location) and registers the certificate issuer's public key (public key for VC verification) in the VC update cassette management repository 200.

[0052] (3) VC update User U, the holder of the certificate, needs a driver's license as proof to submit to the company acting as the certificate verifier. However, if they find that information about their place of origin is not required, they would like to request the issuance of a presentation certificate (VP) by removing the place of origin information from a verifiable certificate (VC) (e.g., a driver's license with place of origin information).

[0053] The terminal device 10 (authentication device) of user U, who is the holder of the certificate, confirms that the above cassette is secure and evaluated, and then downloads the above cassette and the corresponding private key (cassette verification private key) from the server device 100-1 of the business operator that provides the VC management application (e.g., wallet application), and imports them into the VC management application (e.g., wallet application). At this time, after FIDO registration, user U's terminal device 10 (authentication device) and the business operator's server device 100-1 may perform FIDO authentication before / during the download, and may only allow the download if FIDO authentication is successful. In addition, user U's terminal device 10 (authentication device) may store the above cassette's private key (cassette verification private key) in a secure area (secure element). Then, user U's terminal device 10 (authentication device) uses (executes) the functions of the above cassette imported into the VC management application (e.g., wallet application) to issue a presentation certificate (VP) without permanent address information on the wallet application.

[0054] Here, user U's terminal device 10 (authentication device) attaches an encrypted VC with a signature to the presented certificate (VP) using the function of the cassette. At this time, user U's terminal device 10 (authentication device) attaches a signature using the cassette's private key (cassette verification private key) to the presented certificate (VP), including the verifiable certificate (updated VC) updated by the cassette, using the function of the cassette. For example, user U's terminal device 10 (authentication device) signs the verifiable certificate (updated VC) updated by the cassette using the private key of the cassette (cassette verification private key). Note that user U's terminal device 10 (authentication device) may also sign the verifiable certificate (VC) using the private key of the cassette (cassette verification private key) when it updates the verifiable certificate (VC) using the function of the cassette.

[0055] Furthermore, the user U's terminal device 10 (authentication device), through the function of the cassette, attaches an encrypted VC, which is the binary information (encrypted information) of the original verifiable certificate (VC) before it was updated by the cassette, to the presented certificate (VP) along with the updated verifiable certificate (updated VC) updated by the cassette. The updated VC and the encrypted VC may be linked. The reason for attaching the original verifiable certificate (VC) is to enable the certificate verifier to verify the authenticity of the original verifiable certificate (VC). The reason for encrypting the original verifiable certificate (VC) is that it contains information not included in the updated VC, such as information from before the cassette update (deleted information, unnecessary information, etc.).

[0056] The encrypted VC, which is the binary information (encrypted information) of the original verifiable certificate (VC) before it was updated by the cassette, can only be decrypted by the server device 100-1 of the business operator that issued the certificate and provided the cassette (and the terminal device 10 (authentication device) of user U who possesses the cassette). The server device 100-2 of the company that is the certificate verifier cannot decrypt it and refer to the original verifiable certificate (VC). The encryption method is not limited to binary conversion. The encryption method is arbitrary. In practice, it is sufficient to be able to present the updated VC, so it is not necessary to decrypt the encrypted VC. For example, instead of encryption, the original verifiable certificate (VC) may be vectorized and converted into vector data.

[0057] Furthermore, user U's terminal device 10 (authentication device) may sign the entire presented certificate (VP) with a private key for identity verification (authentication private key) that proves it was created by the user, and register the corresponding public key for identity verification (authentication public key) in the repository 200, thereby making it possible to verify the signature of the presented certificate (VP) using the public key for identity verification (authentication public key) registered in the repository 200. In practice, user U's terminal device 10 (authentication device) may, separately from the authentication private key and authentication public key pair, create a new private key and public key pair that proves it was created by the user, and sign the entire presented certificate (VP) using this private key. Alternatively, user U's terminal device 10 (authentication device) may directly provide (disclose) the public key for identity verification to the certificate holder or certificate verifier without registering the public key for identity verification in the repository 200.

[0058] (4) VP verification When the company's server device 100-2, which is the certificate verifier, receives the above-mentioned presented certificate (VP), it verifies the presented certificate (VP), the signed encrypted VC, and the authenticity of the cassette. The signature of the encrypted VC can be verified with the certificate issuer's public key (public key for VC verification). The authenticity of the cassette can be verified with the cassette's public key (public key for cassette verification). For example, server device 100-2 verifies the authenticity of the cassette by verifying the signature made with the cassette's private key (private key for cassette verification) with the cassette's public key (public key for cassette verification) stored in repository 200.

[0059] [1-3. Features] Thus, in this embodiment, the user U, who is the holder of the certificate, can issue a presentation certificate (VP) with updated information contained in the verifiable certificate (VC) (VC information) without modifying the signed verifiable certificate (VC) or requesting the certificate issuer (Issuer) to reissue the verifiable certificate (VC).

[0060] Furthermore, it is possible to provide only the minimum necessary information that conforms to the information disclosure policy (preference) of the certificate holder and the information acceptance policy of the certificate verifier, which is the entity that utilizes the verifiable certificate (VC). As a result, user privacy can be protected.

[0061] In the above explanation, the information stored in the verifiable certificate (updated VC) updated by the cassette includes the encrypted VC, which is the binary information (encryption information) of the original verifiable certificate (VC) before the cassette update. However, including the original encrypted VC is not mandatory. For example, even if the updated VC itself does not contain the encrypted VC, if the processing details (public information) of the VC update function (cassette) registered in repository 200 include the information of the original encrypted VC as input information, it can be confirmed that the verifiable certificate (updated VC) updated by the cassette is information that was legitimately updated by the cassette based on the original encrypted VC. Alternatively, one of the functions of that cassette may include "verification of the original encrypted VC" as a preprocessing step when creating the updated VC. Furthermore, the contents of the updated VC may include information such as "the original encrypted VC has been verified" or "updated based on the original encrypted VC."

[0062] [2. Example of an information processing system configuration] Next, the configuration of the information processing system 1, which includes the server device 100 according to the embodiment, will be described using Figure 4. Figure 4 is a diagram showing an example of the configuration of the information processing system 1 according to the embodiment. As shown in Figure 4, the information processing system 1 according to the embodiment includes a terminal device 10, a server device 100, and a repository 200. These various devices are connected to each other via a network N, either by wire or wireless communication. The network N is, for example, a LAN (Local Area Network) or a WAN (Wide Area Network) such as the Internet.

[0063] Furthermore, the number of devices included in the information processing system 1 shown in Figure 4 is not limited to those illustrated. For example, in Figure 4, only one terminal device 10 is shown for the sake of illustration, but this is merely an example and not limiting; there may be two or more.

[0064] Terminal device 10 is an information processing device used by user U. For example, terminal device 10 may be a smart device such as a smartphone or tablet, a mobile phone such as a feature phone, a PC (Personal Computer), a PDA (Personal Digital Assistant), a game console or AV equipment with communication functions, an information appliance or digital appliance, a car navigation system, a wearable device such as a smartwatch or head-mounted display, or smart glasses. Alternatively, terminal device 10 may be a house or building compatible with the Internet of Things (IoT), a car, a home appliance, an electronic device, etc.

[0065] Furthermore, the terminal device 10 can connect to the network N via wireless communication networks such as LTE (Long Term Evolution), 4G (4th Generation), and 5G (5th Generation), or via short-range wireless communication such as Bluetooth (registered trademark) and Wi-Fi (Local Area Network), and communicate with the server device 100.

[0066] The server device 100 and repository 200 are, for example, computers such as PCs or blade servers, or mainframes or workstations. The server device 100 and repository 200 may also be implemented through cloud computing.

[0067] [3. Example of terminal device configuration] Next, the configuration of the terminal device 10 will be explained using Figure 5. Figure 5 is a diagram showing an example of the configuration of the terminal device 10. As shown in Figure 5, the terminal device 10 comprises a communication unit 11, a display unit 12, an input unit 13, a positioning unit 14, a sensor unit 20, a control unit 30 (controller), and a storage unit 40.

[0068] (Communications Section 11) The communication unit 11 is connected to the network N (see Figure 4) by wire or wireless connection and transmits and receives information to and from the server device 100 via the network N. For example, the communication unit 11 can be implemented using a NIC (Network Interface Card) or an antenna.

[0069] (Display section 12) The display unit 12 is a display device that displays various information such as location information. For example, the display unit 12 may be a liquid crystal display (LCD) or an organic electro-luminescent display (OLED). The display unit 12 may also be a touch panel display, but is not limited to this.

[0070] (Input section 13) The input unit 13 is an input device that receives various operations from the user U. For example, the input unit 13 has buttons for inputting characters, numbers, etc. The input unit 13 may also be an input / output port (I / O port) or a USB (Universal Serial Bus) port. If the display unit 12 is a touch panel display, a part of the display unit 12 functions as the input unit 13. The input unit 13 may also be a microphone that receives voice input from the user U. The microphone may be wireless.

[0071] (Positioning unit 14) The positioning unit 14 receives signals (radio waves) transmitted from GPS (Global Positioning System) satellites and, based on the received signals, acquires position information (e.g., latitude and longitude) indicating the current position of the terminal device 10. In other words, the positioning unit 14 determines the position of the terminal device 10. Note that GPS is just one example of a GNSS (Global Navigation Satellite System).

[0072] Furthermore, the positioning unit 14 can determine its position using various methods other than GPS. For example, the positioning unit 14 may use various communication functions of the terminal device 10 to determine its position as an auxiliary positioning means for position correction, etc., as described below.

[0073] (Wi-Fi positioning) For example, the positioning unit 14 determines the location of the terminal device 10 by utilizing the Wi-Fi® communication function of the terminal device 10 and the communication network provided by each telecommunications company. Specifically, the positioning unit 14 determines the location of the terminal device 10 by performing Wi-Fi communication, etc., and determining the distance to nearby base stations and access points.

[0074] (Beacon positioning) Furthermore, the positioning unit 14 may determine the location using the Bluetooth® function of the terminal device 10. For example, the positioning unit 14 determines the location of the terminal device 10 by connecting to a beacon transmitter connected via the Bluetooth® function.

[0075] (Geomagnetic positioning) Furthermore, the positioning unit 14 determines the position of the terminal device 10 based on the geomagnetic pattern of the structure, which has been measured in advance, and the geomagnetic sensor provided by the terminal device 10.

[0076] (RFID positioning) Furthermore, if, for example, the terminal device 10 is equipped with an RFID (Radio Frequency Identification) tag function equivalent to that of a contactless IC card used at a train station ticket gate or in a store, or if it is equipped with a function to read RFID tags, the location where it was used will be recorded along with the information on the payment or other transactions made by the terminal device 10. The positioning unit 14 may determine the location of the terminal device 10 by acquiring such information. Alternatively, the location may be determined by an optical sensor or infrared sensor equipped in the terminal device 10.

[0077] The positioning unit 14 may, if necessary, determine the position of the terminal device 10 using one or a combination of the positioning means described above.

[0078] (Sensor unit 20) The sensor unit 20 includes various sensors mounted on or connected to the terminal device 10. The connection can be wired or wireless. For example, the sensors may be detection devices other than the terminal device 10, such as wearable devices or wireless devices. In the example shown in Figure 5, the sensor unit 20 includes an acceleration sensor 21, a gyro sensor 22, a barometric pressure sensor 23, a temperature sensor 24, a sound sensor 25, a light sensor 26, a magnetic sensor 27, and an image sensor (camera) 28.

[0079] The sensors 21-28 described above are merely examples and not limiting. In other words, the sensor unit 20 may be configured to include some of the sensors 21-28, or it may include other sensors such as humidity sensors in addition to or instead of the sensors 21-28.

[0080] The acceleration sensor 21 is, for example, a 3-axis acceleration sensor and detects the physical movement of the terminal device 10, such as its direction of movement, velocity, and acceleration. The gyro sensor 22 detects the physical movement of the terminal device 10, such as its tilt in the three axes, based on its angular velocity. The barometric pressure sensor 23 detects the atmospheric pressure around the terminal device 10, for example.

[0081] Since the terminal device 10 is equipped with the acceleration sensor 21, gyroscope 22, barometric pressure sensor 23, etc., it becomes possible to determine the position of the terminal device 10 using technologies such as pedestrian dead-reckoning (PDR) that utilize these sensors 21 to 23. This makes it possible to obtain indoor location information that is difficult to obtain with positioning systems such as GPS.

[0082] For example, a pedometer using an accelerometer 21 can calculate the number of steps, walking speed, and distance walked. Additionally, a gyroscope 22 can be used to determine the user U's direction of movement, gaze direction, and body tilt. Furthermore, the barometric pressure detected by the barometric pressure sensor 23 can be used to determine the altitude and floor number of the user U's terminal device 10.

[0083] The temperature sensor 24 detects, for example, the ambient temperature around the terminal device 10. The sound sensor 25 detects, for example, the ambient sound around the terminal device 10. The light sensor 26 detects the ambient illumination around the terminal device 10. The magnetic sensor 27 detects, for example, the Earth's magnetic field around the terminal device 10. The image sensor 28 captures an image of the area around the terminal device 10.

[0084] The aforementioned pressure sensor 23, temperature sensor 24, sound sensor 25, light sensor 26, and image sensor 28 can detect the surrounding environment and conditions of the terminal device 10 by detecting atmospheric pressure, temperature, sound, and illuminance, respectively, and by capturing images of the surroundings. Furthermore, it becomes possible to improve the accuracy of the location information of the terminal device 10 based on the surrounding environment and conditions.

[0085] (Control Unit 30) The control unit 30 includes, for example, a microcomputer having a CPU (Central Processing Unit), ROM (Read Only Memory), RAM, input / output ports, and various circuits. Alternatively, the control unit 30 may be composed of hardware such as an integrated circuit (ASIC) or FPGA (Field Programmable Gate Array). The control unit 30 includes a transmission unit 31, a reception unit 32, a processing unit 33, a registration request unit 34, a key creation unit 35, a VC management unit 36, and an authentication request unit 37.

[0086] (Transmitter 31) The transmission unit 31 can transmit various information, such as information input by the user U using the input unit 13, various information detected by sensors 21-28 mounted on or connected to the terminal device 10, and location information of the terminal device 10 determined by the positioning unit 14, to the server device 100 via the communication unit 11.

[0087] (Receiving unit 32) The receiving unit 32 can receive various information provided by the server device 100, as well as requests for various information from the server device 100, via the communication unit 11.

[0088] (Processing 33) The processing unit 33 controls the entire terminal device 10, including the display unit 12. For example, the processing unit 33 can output and display various information transmitted by the transmission unit 31 and various information received from the server device 100 by the reception unit 32 to the display unit 12.

[0089] In practice, the processing unit 33 may function as the registration request unit 34, key creation unit 35, VC management unit 36, and authentication request unit 37 described below by launching an application or executing a program.

[0090] (Registration request section 34) The registration request unit 34 sends a registration request (Reg request) to the server device 100 of the business operator, which is the certificate issuer, via the transmission unit 31. For example, the registration request is a request for FIDO registration. Then, as a response to the registration request, the registration request unit 34 receives a verifiable certificate (VC) issued by the server device 100 of the business operator, which is the certificate issuer, via the reception unit 32. In this embodiment, the registration request unit 34 has a certificate reception unit 34A.

[0091] (Certificate receiving unit 34A) The certificate receiving unit 34A receives a verifiable certificate (VC) for user U issued by the certificate issuer via the receiving unit 32.

[0092] (Key creation section 35) The key creation unit 35 creates a key pair consisting of a private key and a public key. For example, the key creation unit 35 creates a key pair consisting of a registration private key and a registration public key. The key creation unit 35 also creates a key pair consisting of an authentication private key and an authentication public key. The key creation unit 35 may also transmit and provide the authentication public key to the server device 100 of the business operator, which is the certificate issuer, via the transmission unit 31 before or at the time of issuance of the verifiable certificate (VC).

[0093] In this embodiment, the key creation unit 35 includes a key creation unit 35A for personal identification, a key management unit 35B for personal identification, and a key disclosure unit 35C for personal identification.

[0094] (Key creation unit for identity verification 35A) The user authentication key creation unit 35A creates a key pair consisting of a user authentication private key that authenticates that the user created it, and a corresponding user authentication public key. Note that the key pair of the user authentication private key and user authentication public key may be a key pair of an authentication private key and an authentication public key.

[0095] (Key management section for identity verification 35B) The identity verification key management unit 35B stores the identity verification private key internally. For example, the identity verification key management unit 35B stores the identity verification private key in the secure area (secure element) of the storage unit 40.

[0096] (Key disclosure section for identity verification 35C) The identity verification key disclosure unit 35C makes the identity verification public key public. At this time, the identity verification key disclosure unit 35C may register the identity verification public key in the public repository 200, or it may directly provide (disclose) the identity verification public key to the certificate holder or certificate verifier.

[0097] (VC Management Department 36) The VC management unit 36 ​​manages verifiable certificates (VCs) issued by certificate issuers (Issuers) for users U. At this time, the VC management unit 36 ​​may execute various functions of a VC management application (e.g., a wallet application). This VC management application has a VC creation function, a VC update function, and a VC storage function.

[0098] In this embodiment, the VC management unit 36 ​​includes a cassette receiving unit 36A, a certificate renewal unit 36B, a presentation certificate creation unit 36C, and a presentation certificate signing unit 36D.

[0099] The cassette receiver 36A receives a cassette that has the function of updating verifiable certificates (VCs) created by the certificate issuer. For example, the cassette receiver 36A downloads a cassette that has the function of updating verifiable certificates (VCs) from the server device 100 of the business operator, which is the certificate issuer. At this time, the cassette receiver 36A receives the cassette along with the cassette (cassette verification private key) used for signing when updating the verifiable certificate (VC) by the cassette's function from the certificate issuer. The cassette receiver 36A then imports (stores / registers) the cassette and the cassette's private key (cassette verification private key) into the VC management application.

[0100] The certificate renewal unit 36B renews the verifiable certificate (VC) using the cassette's functionality. When the certificate renewal unit 36B renews the verifiable certificate (VC) using the cassette's functionality, it signs the renewed verifiable certificate (VC) using the cassette's private key (cassette verification private key).

[0101] The presentation certificate creation unit 36C uses the cassette function to combine multiple verifiable certificates (VCs) to create a single presentation certificate (VP: Verifiable Presentation). Furthermore, when a verifiable certificate (VC) is updated, the presentation certificate creation unit 36C uses the cassette function to attach both the encrypted pre-update verifiable certificate (encrypted VC) and the updated verifiable certificate (updated VC) to the presentation certificate (VP).

[0102] The presentation certificate signing unit 36D signs the presentation certificate (VP) using the private key for identity verification. That is, the presentation certificate signing unit 36D signs the entire presentation certificate (VP), which includes multiple verifiable certificates (VCs), using the private key for identity verification. Note that the presentation certificate signing unit 36D may be part of the presentation certificate creation unit 36C. That is, the presentation certificate creation unit 36C may have the functionality of the presentation certificate signing unit 36D and sign the presentation certificate (VP) when it creates it.

[0103] (Authentication request section 37) The authentication request unit 37 sends an authentication request to the server device 100 of the company that is the certificate verifier via the transmission unit 31. At this time, the authentication request unit 37 sends a presentation certificate (VP) including a verifiable certificate (VC) along with the authentication request to the server device 100 of the company that is the certificate verifier via the transmission unit 31. For example, in response to the authentication request, the server device 100 of the company that is the certificate verifier performs FIDO authentication and password authentication. If authentication is successful, the authentication request unit 37 logs in to the server device 100 of the company that is the certificate verifier and receives services from the server device 100 of the company that is the certificate verifier (or the linked RP / SP beyond it). In this embodiment, the authentication request unit 37 has a certificate presentation unit 37A.

[0104] (Certificate presentation section 37A) The certificate presentation unit 37A transmits and presents the updated verifiable certificate (VC) to the certificate verifier via the transmission unit 31. In practice, the certificate presentation unit 37A presents the certificate verifier with a presentation certificate (VP) that includes the updated verifiable certificate (VC). That is, the certificate presentation unit 37A presents the updated verifiable certificate (VC) to the certificate verifier as a presentation certificate (VP). Alternatively, the certificate presentation unit 37A may display the presentation certificate (VP) (either itself or as a 2D code) on the display unit 12 and present it to the reader or the certificate verifier.

[0105] (Storage unit 40) The storage unit 40 is implemented by, for example, semiconductor memory elements such as RAM (Random Access Memory) and flash memory, or by storage devices such as HDD (Hard Disk Drive), SSD (Solid State Drive), and optical discs. Various programs and various data are stored in this storage unit 40.

[0106] Furthermore, the secure area (secure element) of the storage unit 40 stores the registration secret key 40A, the authentication secret key 40B, and the VC management application 40C. In this case, the registration secret key 40A, the authentication secret key 40B, and the VC management application 40C may be stored in a different secure area.

[0107] The registration private key 40A is, for example, the private key used to sign an authenticator certificate (Attestation). The authentication private key 40B is, for example, the private key used to sign an assertion certificate (Assertion) of the user verification result at the authenticator.

[0108] The VC management application 40C is an application (e.g., a wallet application) that stores verifiable certificates (VCs), a function (cassette) that allows for certificate renewal, and the private keys (cassette verification private keys) of the cassettes. The processing unit 33 downloads various cassettes, along with the corresponding cassette's private key (cassette verification private key), from the server device 100, which is the provider of the VC management application, and imports them into the VC management application 40C. There may be multiple cassettes, and there is a one-to-one relationship between the cassette's private key (cassette verification private key) and the cassette. That is, the number of cassette's private keys (cassette verification private keys) is the same as the number of cassettes.

[0109] In this embodiment, the VC management application 40C has at least a VP creation function, a VC update function, and a VC storage function. The VC management application 40C may also store a presentation certificate (VP) containing one or more verifiable certificates (VCs). In practice, only confidential information such as the cassette's private key (cassette verification private key), verifiable certificates (VCs), and presentation certificates (VPs) of the VC management application 40C may be stored in a secure area (secure element), while the VC management application itself and the cassette may be stored in a normal storage area.

[0110] [4. Example of Server Device Configuration] Next, the configuration of the server device 100 according to the embodiment will be described using Figure 6. Figure 6 is a diagram showing an example of the configuration of the server device 100 according to the embodiment. As shown in Figure 6, the server device 100 includes a communication unit 110, a storage unit 120, and a control unit 130.

[0111] (Communications Department 110) The communication unit 110 is implemented, for example, by a NIC (Network Interface Card). The communication unit 110 is connected to the network N (see Figure 4) by wire or wireless connection.

[0112] (Storage unit 120) The storage unit 120 is implemented by, for example, semiconductor memory elements such as RAM (Random Access Memory) and flash memory, or by storage devices such as HDDs, SSDs, and optical discs. As shown in Figure 6, the storage unit 120 includes a user information database 121, a history information database 122, a key information database 123, and a cassette information database 124.

[0113] (User Information Database 121) The user information database 121 stores user information about user U. For example, the user information database 121 stores various information such as user U's attributes. Figure 7 shows an example of the user information database 121. In the example shown in Figure 7, the user information database 121 has items such as "User ID (Identifier)", "Age", "Gender", "Home", "Workplace", and "Interests".

[0114] "User ID" refers to identification information used to identify user U. Note that "User ID" may be user U's contact information (telephone number, email address, etc.) or identification information used to identify user U's terminal device 10.

[0115] Furthermore, "Age" indicates the age of user U, identified by the user ID. Note that "Age" may be information indicating user U's specific age (e.g., 35 years old), or information indicating user U's age group (e.g., 30s), or "Age" may be information indicating user U's date of birth, or information indicating user U's generation (e.g., born in the 1980s). Furthermore, "Gender" indicates the gender of user U, identified by the user ID.

[0116] Furthermore, "Home" indicates the location information of user U's home, which is identified by the user ID. In the example shown in Figure 7, "Home" is represented by an abstract code such as "LC11," but it could also be latitude and longitude information, etc. Also, for example, "Home" could be a regional name or address.

[0117] Furthermore, "Workplace" indicates the location information of the workplace (or school in the case of a student) of user U, identified by the user ID. In the example shown in Figure 7, "Workplace" is illustrated with an abstract code such as "LC12," but it may also be latitude and longitude information, etc. Also, for example, "Workplace" may be a regional name or address.

[0118] Furthermore, "Interests" indicate the interests of user U, who is identified by their user ID. In other words, "Interests" indicate the subjects of high interest to user U, who is identified by their user ID. For example, "Interests" may be search queries (keywords) that user U enters into a search engine. In the example shown in Figure 7, one "Interest" is shown for each user U, but there may be multiple interests.

[0119] For example, in the example shown in Figure 7, user U, identified by user ID "U1", is in their 20s and is male. Also, for example, user U, identified by user ID "U1", has their home address at "LC11". Furthermore, for example, user U, identified by user ID "U1", has their workplace at "LC12". Finally, for example, user U, identified by user ID "U1", is interested in "sports".

[0120] In the example shown in Figure 7, abstract values ​​such as "U1," "LC11," and "LC12" are used to illustrate the information, but it is assumed that "U1," "LC11," and "LC12" actually store specific strings, numbers, or other information. In the following diagrams relating to other information, abstract values ​​may also be used to illustrate the information.

[0121] The user information database 121 is not limited to the above and may store various types of information depending on the purpose. For example, the user information database 121 may store various types of information about user U's terminal device 10. In addition, the user information database 121 may store information about user U's demographic, psychographic, geographic, and behavioral attributes. For example, the user information database 121 may store information such as name, family structure, place of origin (hometown), occupation, job title, income, qualifications, type of residence (detached house, apartment, etc.), whether or not a car is owned, commuting time, commuting route, commuter pass section (station, line, etc.), frequently used stations (other than the nearest station to home / workplace), lessons / classes (location, time, etc.), hobbies, interests, and lifestyle.

[0122] (History Information Database 122) The history information database 122 stores various information related to the history information (log data) that shows the user U's actions. Figure 8 shows an example of the history information database 122. In the example shown in Figure 8, the history information database 122 has items such as "User ID", "Location History", "Search History", "Browsing History", "Purchase History", and "Posting History".

[0123] "User ID" indicates identification information used to identify user U. "Location History" indicates the location history, which is the history of user U's location and movements. "Search History" indicates the search history, which is the history of search queries entered by user U. "Browsing History" indicates the browsing history, which is the history of content viewed by user U. "Purchase History" indicates the purchase history, which is the history of purchases made by user U. "Posting History" indicates the posting history, which is the history of posts made by user U. Note that "Posting History" may include questions about user U's possessions.

[0124] For example, in the example shown in Figure 8, user U, identified by user ID "U1", moves as described in "Location History #1", searches as described in "Search History #1", views content as described in "Browsing History #1", purchases specified goods at specified stores as described in "Purchase History #1", and posts as described in "Posting History #1".

[0125] In the example shown in Figure 8, abstract values ​​such as "U1", "Location History #1", "Search History #1", "Browsing History #1", "Purchase History #1", and "Posting History #1" are used for illustration. However, it is assumed that "U1", "Location History #1", "Search History #1", "Browsing History #1", "Purchase History #1", and "Posting History #1" will actually store specific strings, numbers, and other information.

[0126] The history information database 122 is not limited to the above and may store various types of information depending on the purpose. For example, the history information database 122 may store the usage history of user U for a specified service. The history information database 122 may also store the visit history of user U to a physical store or a facility. The history information database 122 may also store the payment history of user U using the terminal device 10 for payments (electronic payments).

[0127] (Key Information Database 123) The key information database 123 stores various information about the public keys stored in the repository 200. Figure 9 shows an example of the key information database 123. In the example shown in Figure 9, the key information database 123 has items such as "Key ID", "Public Key URL", and "User ID".

[0128] The "Key ID" indicates identification information for identifying the public key stored in repository 200. The public key is not limited to the registration public key or authentication public key created by user U's terminal device 10 (authentication device), but may also be the certificate issuer's (VC verification public key) or the cassette's (cassette verification public key).

[0129] Furthermore, the "Public Key URL" indicates the reference DID that shows the location of the public key stored in repository 200. Here, the reference DID corresponds to the reference DID associated with the public key stored in repository 200.

[0130] Furthermore, the "User ID" refers to identification information used to identify the user U (user) who undergoes FIDO authentication using a public key. In practice, however, it may be identification information for the authenticator (authentication device ID) instead of the User ID.

[0131] For example, in the example shown in Figure 9, the public key indicated by key ID "KID1" is located at the location indicated by public key URL "DID1" (repository 200), and if FIDO authentication using the public key is successful, user ID "UID1" will be extracted.

[0132] In the example shown in Figure 9, abstract values ​​such as "KID1," "DID1," and "UID1" are used for illustration, but it is assumed that "KID1," "DID1," and "UID1" will store specific strings, numbers, or other information.

[0133] The key information database 123 is not limited to the above and may store various types of information depending on the purpose. For example, the key information database 123 may store information not only about public keys but also about private keys generated by the server device 100 itself. The key information database 123 may also store authenticator certificates (Attestation) and user verification result certificates (Assertion). The key information database 123 may also store verifiable certificates (VC) issued by the server device 100. Furthermore, the key information database 123 may function as a repository 200. For example, one of the multiple server devices 100 may store a repository 200 in its storage unit 120.

[0134] (Cassette Information Database 124) The cassette information database 124 stores various information about VC update cassettes (cassettes) that have the function of updating verifiable certificates (VCs). Figure 10 shows an example of the cassette information database 124. In the example shown in Figure 10, the cassette information database 124 has items such as "Cassette ID", "Cassette Body", "Private Key", and "User ID".

[0135] "Cassette ID" indicates identification information for identifying a cassette that has the function of updating verifiable certificates (VCs). "Cassette Body" indicates the data of the cassette body provided to the user U's terminal device 10 (authentication device).

[0136] Furthermore, "private key" refers to the data of the private key (cassette verification private key) of the cassette that is provided (distributed) with the cassette. In practice, it may include not only the data of the cassette's private key but also identification information (key ID) to identify the cassette's private key. In this case, the key ID of the cassette's private key and the key ID of the cassette's public key may be linked and stored together.

[0137] Furthermore, the "User ID" refers to identification information used to identify the user U to whom the cassette was provided. In practice, however, it may not be the User ID, but rather identification information (Authentication Device ID) used to identify the terminal device 10 (Authentication Device) that downloaded the cassette, or identification information (Application ID) used to identify the VP management application that imported the cassette.

[0138] For example, in the example shown in Figure 10, cassette "C1," indicated by cassette ID "CID1," is downloaded along with the cassette's private key (cassette verification private key) "Prikey1" to the terminal device 10 (authentication device) of user U, identified by user ID "UID1," and imported into the VP management application.

[0139] In the example shown in Figure 10, abstract values ​​such as "CID1", "C1", "Prikey1", and "UID1" are used for illustration, but it is assumed that "CID1", "C1", "Prikey1", and "UID1" will store specific strings, numbers, or data.

[0140] Furthermore, the cassette information database 124 may store various types of information depending on the purpose, not limited to those mentioned above. For example, the cassette information database 124 may store data from a VP management application that imports cassettes. The cassette information database 124 may also store verifiable certificates (VCs) and presented certificates (VPs) updated by cassettes. In addition, the cassette information database 124 may store information regarding the correspondence between cassettes and verifiable certificates (VCs).

[0141] (Control unit 130) Returning to Figure 6, let's continue the explanation. The control unit 130 is a controller, and is realized by various programs (corresponding to an example of an information processing program) stored in the internal memory of the server device 100, such as a CPU (Central Processing Unit), MPU (Micro Processing Unit), ASIC (Application Specific Integrated Circuit), or FPGA (Field Programmable Gate Array), executing them using a memory area such as RAM as the working area. In the example shown in Figure 6, the control unit 130 includes an acquisition unit 131, a registration processing unit 132, an authentication processing unit 133, a certificate issuance unit 134, a creation unit 135, a registration unit 136, a certificate signing unit 137, and a provision unit 138.

[0142] (Acquisition part 131) The acquisition unit 131 acquires the search query entered by the user U. For example, when the user U enters a search query into a search engine or the like and performs a keyword search, the acquisition unit 131 acquires the search query via the communication unit 110. In other words, the acquisition unit 131 acquires the keyword entered by the user U into the search box of a search engine, website, or application via the communication unit 110.

[0143] Furthermore, the acquisition unit 131 acquires user information about user U via the communication unit 110. For example, the acquisition unit 131 acquires identification information (such as user ID), location information, and attribute information of user U from user U's terminal device 10. The acquisition unit 131 may also acquire identification information and attribute information of user U when user U is registered. The acquisition unit 131 then registers the user information in the user information database 121 of the storage unit 120.

[0144] Furthermore, the acquisition unit 131 acquires various historical information (log data) indicating the user U's actions via the communication unit 110. For example, the acquisition unit 131 acquires various historical information indicating the user U's actions from the user U's terminal device 10, or from various servers based on the user ID, etc. The acquisition unit 131 then registers the various historical information in the history information database 122 of the storage unit 120.

[0145] Furthermore, during registration, the acquisition unit 131 receives a registration request from the user U's terminal device 10 (authentication device) via the communication unit 110. Also, during authentication, the acquisition unit 131 receives an authentication request from the user U's terminal device 10 (authentication device) via the communication unit 110.

[0146] Furthermore, when password authentication is performed, the acquisition unit 131 receives the user ID and password of user U from the user U's terminal device 10 via the communication unit 110. For example, when user U registers or is authenticated, the acquisition unit 131 receives the user ID and password of user U from the user U's terminal device 10 via the communication unit 110. In practice, if the user ID has already been entered, the acquisition unit 131 may only receive the password.

[0147] (Registration processing unit 132) The registration processing unit 132 performs registration processing for user U, who uses terminal device 10 as an authenticator, in response to a registration request. At this time, the registration processing unit 132 requests FIDO registration using a previously published registration public key from another server device (authentication server) that performs FIDO authentication during registration, receives the FIDO registration result as a response, determines whether the FIDO registration is successful or not based on the FIDO registration result, and performs registration processing for user U if the FIDO registration is successful. For example, if the FIDO registration is successful, the registration processing unit 132 performs user registration including user ID and password for user U.

[0148] Furthermore, the FIDO registration result may also be the result of authenticating the authenticator's authenticity (signature verification). That is, the registration processing unit 132 may perform user registration, including the user ID and password of user U, if the authenticating the authenticator's authenticity (signature verification) is successful.

[0149] Furthermore, the certificate issuing unit 134, the creation unit 135, the registration unit 136, and the certificate signing unit 137, which will be described later, may be part of the registration processing unit 132. That is, the registration processing unit 132 may have the certificate issuing unit 134, the creation unit 135, the registration unit 136, and the certificate signing unit 137, which will be described later.

[0150] (Authentication processing unit 133) The authentication processing unit 133 performs FIDO authentication using the authentication public key during authentication. For example, during authentication, the authentication processing unit 133 verifies the authenticity of the verifiable certificate (VC) and uses the authentication public key to verify the signature of the signed challenge signed with the authentication private key.

[0151] In this case, the authentication processing unit 133 may, during authentication, request (or redirect) FIDO authentication from another server device (authentication server) that performs FIDO authentication, receive the FIDO authentication result as a response, and determine whether FIDO authentication is successful or not based on the FIDO authentication result.

[0152] (Certificate Issuance Section 134) The certificate issuing unit 134 issues a verifiable certificate (VC) for user U. The certificate issuing unit 134 may be part of the registration processing unit 132 described above.

[0153] (Creation section 135) The creation unit 135 includes a cassette creation unit 135A, a cassette key creation unit 135B, and a certificate key creation unit 135C.

[0154] (Cassette creation unit 135A) The cassette creation unit 135A creates a cassette that has the function to update the verifiable certificate (VC).

[0155] (Cassette key creation unit 135B) The cassette key creation unit 135B creates a key pair consisting of the cassette's private key (cassette verification private key), which is used for signing when the cassette updates its verifiable certificate (VC) on the user U's terminal device 10 (authentication device), and the cassette's public key (cassette verification public key), which is used to verify the signature made by the cassette.

[0156] (Certificate key creation unit 135C) The certificate key creation unit 135C creates a key pair consisting of the certificate issuer's private key (VC verification private key) used to sign the verifiable certificate (VC), and the certificate issuer's public key (VC verification public key) used to verify the signature of the verifiable certificate (VC). Note that the certificate key creation unit 135C may be part of the registration processing unit 132 described above.

[0157] (Registration Section 136) The registration unit 136 includes a cassette key registration unit 136A, a certificate key management unit 136B, and a certificate key registration unit 136C.

[0158] (Cassette key registration unit 136A) The cassette key registration unit 136A registers the cassette's public key (cassette verification public key) in the public repository 200 via the communication unit 110.

[0159] (Certificate Key Management Section 136B) The certificate key management unit 136B stores the certificate issuer's private key (VC verification private key) used to sign verifiable certificates (VCs) internally (or in a secure storage location). For example, the certificate key management unit 136B registers the certificate issuer's private key (VC verification private key) in an internal database or table.

[0160] (Certificate key registration section 136C) The certificate key registration unit 136C registers the certificate issuer's (Issuer) public key (VC verification public key) in the public repository 200 via the communication unit 110.

[0161] (Certificate Signature Section 137) The certificate signing unit 137 signs the verifiable certificate (VC) using the certificate issuer's private key (VC verification private key). For example, the certificate signing unit 137 accesses the certificate issuer's private key (VC verification private key) stored in the repository 200 via the communication unit 110 and signs the verifiable certificate (VC) using this certificate issuer's private key (VC verification private key). Note that the certificate signing unit 137 may be part of the registration unit 136.

[0162] (Provider 138) The provisioning unit 138 includes a certificate provisioning unit 138A, a cassette provisioning unit 138B, and a service provisioning unit 138C.

[0163] (Certificate Provision Section 138A) The certificate provisioning unit 138A provides a verifiable certificate (VC) to the user U's terminal device 10 (authentication device) via the communication unit 110. The certificate provisioning unit 138A may be part of the certificate issuing unit 134.

[0164] (Cassette supply section 138B) The cassette supply unit 138B provides the cassette to the user U's terminal device 10 (authentication device) via the communication unit 110. At this time, the cassette supply unit 138B also provides the cassette along with the cassette's secret key (cassette verification secret key) to the user U's terminal device 10 (authentication device). Note that the cassette supply unit 138B may be part of the cassette creation unit 135A.

[0165] (Service Provision Department 138C) If FIDO authentication is successful, the service provider unit 138C provides the service to user U's terminal device 10 (or user U themselves, or other devices owned by user U) via the communication unit 110. The service provider unit 138C may also provide the authentication public key to another server device (authentication server) via the communication unit 110.

[0166] [5. Processing Procedure] Next, the processing procedure by the server device 100 according to the embodiment will be described using Figure 11. Figure 11 is a sequence diagram showing the processing procedure according to the embodiment. The processing procedure described below is repeatedly executed by the control unit 30 of the terminal device 10 and the control unit 130 of the server device 100.

[0167] For example, the certificate issuance unit 134 of the server device 100-1 of the business operator, which is the certificate issuer, issues a verifiable certificate (VC) relating to user U to the terminal device 10 (authentication device) of user U, which is the certificate holder, via the communication unit 110 (step S101).

[0168] At this time, the certificate signing unit 137 of the server device 100-1 signs the verifiable certificate (VC) using the certificate issuer's private key (VC verification private key). Then, the certificate providing unit 138A of the server device 100-1 provides the verifiable certificate (VC) to the user U's terminal device 10. The certificate receiving unit 34A of the user U's terminal device 10 receives the verifiable certificate (VC) via the receiving unit 32.

[0169] Next, the creation unit 135 of the server device 100-1 creates and distributes a cassette that has the function of updating the verifiable certificate (VC) and the cassette's private key (cassette verification private key) used for signing when the cassette updates the verifiable certificate (VC) (step S102).

[0170] At this time, the cassette creation unit 135A of the server device 100-1 creates a cassette that has the function of updating the verifiable certificate (VC). The cassette key creation unit 135B of the server device 100-1 also creates a key pair consisting of the cassette's private key (cassette verification private key) used for signing when the cassette updates the verifiable certificate (VC) on the user U's terminal device 10, and the cassette's public key (cassette verification public key) used to verify the signature made by the cassette. The cassette key registration unit 136A of the server device 100-1 registers the cassette's public key (cassette verification public key) in the public repository 200. The cassette provision unit 138B of the server device 100-1 provides the cassette and the cassette's private key (cassette verification private key) to the user U's terminal device 10.

[0171] Next, the cassette receiver 36A of the terminal device 10 of user U, who is the holder of the certificate, receives the cassette's private key (cassette verification private key) along with the cassette having the function of updating the verifiable certificate (VC) from the server device 100-1, and imports the cassette and the cassette's private key (cassette verification private key) into the VC management application (step S103).

[0172] Next, the certificate update unit 36B of user U's terminal device 10 updates the verifiable certificate (VC) using the cassette function and signs the updated verifiable certificate (VC) using the cassette verification private key (step S104).

[0173] Next, the presentation certificate creation unit 36C of user U's terminal device 10 combines multiple verifiable certificates (VCs) using the cassette function to create a single presentation certificate (VP: Verifiable Presentation) (step S105). At this time, when a verifiable certificate (VC) is updated, the presentation certificate creation unit 36C attaches both the encrypted pre-update verifiable certificate (encrypted VC) and the updated verifiable certificate (updated VC) to the presentation certificate (VP) using the cassette function.

[0174] Next, the presentation certificate signing unit 36D of user U's terminal device 10 signs the presentation certificate (VP) using the identity verification private key (authentication private key) (step S106). That is, the presentation certificate signing unit 36D signs the entire presentation certificate (VP), which includes multiple verifiable certificates (VCs), using the identity verification private key.

[0175] Next, the certificate presentation unit 37A of user U's terminal device 10 transmits and presents the presentation certificate (VP), which includes the updated verifiable certificate (VC), to the company's server device 100-2, which is the certificate verifier, via the transmission unit 31 (step S107).

[0176] Next, the authentication processing unit 133 of the company's server device 100-2, which is the certificate verifier, verifies the authenticity of the presented certificate (VP) and the verifiable certificate (VC) by referring to the various public keys stored in the repository 200 (step S108). At this time, the authentication processing unit 133 verifies the appropriateness of the updated verifiable certificate (updated VC) by verifying the authenticity of the encrypted pre-update verifiable certificate (encrypted VC) and the authenticity of the cassette.

[0177] Next, if the authenticity verification is successful, the service provision unit 138C of the server device 100-2 provides the service to user U's terminal device 10 (or user U itself, or other equipment owned by user U) via the communication unit 110 (step S109).

[0178] [6. Variant Example] The terminal device 10 and server device 100 described above may be implemented in various other forms besides those of the embodiment described above. Therefore, the following describes modifications of the embodiment.

[0179] In the above embodiment, some or all of the processing performed by the server device 100 may actually be performed by the terminal device 10. For example, the processing may be completed in a standalone manner (by the terminal device 10 alone). In this case, the terminal device 10 is assumed to have the functions of the server device 100 in the above embodiment. Furthermore, in the above embodiment, since the terminal device 10 is in cooperation with the server device 100, from the perspective of the user U, it appears as if the processing of the server device 100 is also being performed by the terminal device 10. In other words, from another perspective, it can be said that the terminal device 10 is equipped with the server device 100.

[0180] Furthermore, in the above embodiment, the server device 100, which is the authentication server, may combine FIDO authentication with other authentication methods to implement multi-factor authentication. For example, the server device 100, which is the authentication server, may combine FIDO authentication with password authentication to implement two-factor authentication. Alternatively, the server device 100, which is the authentication server, may combine FIDO authentication with a secret question to implement two-factor authentication.

[0181] Furthermore, in the above embodiment, the server device 100, which is the authentication server, may perform authentication by combining two or more of the three authentication elements, "knowledge information," "possession information," and "biometric information," in FIDO authentication. In other words, the server device 100, which is the authentication server, may employ multi-factor authentication (MFA).

[0182] Furthermore, in the above embodiment, the terminal device 10 (authentication device) of user U, who is the certificate holder, can also extract only the information "20 years of age or older (adult)" from the verifiable certificate (VC) (e.g., driver's license with registered domicile information) using the VC update function (cassette) to create and issue a new verifiable certificate (VC). Thus, the issuance of a new VC by the cassette based on (or by splitting) the information of the original encrypted VC is also a form of "VC update". Therefore, similar to the verification of the updated VC, the certificate verifier can verify the appropriateness of the newly issued verifiable certificate (VC) (cassette-issued VC) by verifying the authenticity of the original encrypted VC and the authenticity of the cassette. The authenticity of the original encrypted VC can be verified using the public key (public key for VC verification) of the certificate issuer (issuer). The authenticity of the cassette can be verified using the public key of the cassette (public key for cassette verification).

[0183] [7. Effects] As described above, the information processing device (server device 100) according to the present application is an information processing device for a certificate issuer, and is characterized by comprising: a certificate issuing unit that issues verifiable certificates (VCs) relating to a user; a certificate providing unit 138A that provides verifiable certificates (VCs) to the terminal device 10 (authentication device) of user U; a cassette creation unit 135A that creates a cassette having a function to update verifiable certificates (VCs); and a cassette providing unit 138B that provides the cassette to the terminal device 10 (authentication device) of user U.

[0184] Furthermore, the information processing device (server device 100) according to the present invention further includes a cassette key creation unit 135B that creates a key pair of a cassette verification private key used for signing when the cassette updates a verifiable certificate (VC) on the user U's terminal device 10 (authentication device) side, and a cassette verification public key for verifying the signature by the cassette, and a cassette key registration unit 136A that registers the cassette verification public key in a public repository 200. The cassette provision unit 138B provides the cassette along with the cassette verification private key to the user U's terminal device 10 (authentication device).

[0185] Furthermore, the information processing device (server device 100) according to the present application further comprises: a certificate key creation unit 135C that creates a key pair of a VC verification private key used for signing a verifiable certificate (VC) and a VC verification public key for verifying the signature of the verifiable certificate (VC); a certificate signing unit 137 that signs the verifiable certificate (VC) using the VC verification private key; a certificate key management unit 136B that internally stores the VC verification private key; and a certificate key registration unit 136C that registers the VC verification public key in a public repository 200.

[0186] From another perspective, the information processing device (terminal device 10) according to the present application is an information processing device for a certificate holder, and is characterized by comprising: a certificate receiving unit that receives a verifiable certificate (VC) relating to a user issued by a certificate issuer; a cassette receiving unit 36A that receives a cassette having a function to update the verifiable certificate (VC) created by the certificate issuer; a certificate updating unit 36B that updates the verifiable certificate (VC) according to the function of the cassette; and a certificate presenting unit 37A that transmits and presents the updated verifiable certificate (VC) to the certificate verifier.

[0187] Furthermore, the cassette receiver 36A receives the cassette along with the cassette from the certificate issuer, along with the cassette's private key used for signing the verifiable certificate (VC) when it is updated using the cassette's functionality. The certificate update unit 36B updates the verifiable certificate (VC) using the cassette's functionality and signs the updated verifiable certificate (VC) using the cassette's private key.

[0188] Furthermore, the information processing device (terminal device 10) according to the present application further includes a presentation certificate creation unit 36C that combines multiple verifiable certificates (VCs) using the cassette function to create a single presentation certificate (VP). When a verifiable certificate (VC) is updated using the cassette function, the presentation certificate creation unit 36C attaches an encrypted pre-update verifiable certificate (encrypted VC) and an updated verifiable certificate (updated VC) to the presentation certificate (VP).

[0189] Furthermore, the information processing device (terminal device 10) according to the present application further comprises: an identity verification key creation unit 35A that creates a key pair of an identity verification private key that authenticates that it was created by the user himself and a corresponding identity verification public key; a presentation certificate signing unit 36D that signs a presentation certificate (VP) using the identity verification private key; an identity verification key management unit 35B that stores the identity verification private key internally; and an identity verification key disclosure unit 35C that makes the identity verification public key public.

[0190] By any or a combination of the above-described processes, the information processing device according to the present invention can further improve the efficiency of authentication.

[0191] [8. Hardware Configuration] Furthermore, the terminal device 10 and server device 100 according to the above-described embodiment are realized by a computer 1000 having a configuration such as that shown in Figure 12. The following explanation will use the server device 100 as an example. Figure 12 is a diagram showing an example of the hardware configuration. The computer 1000 is connected to an output device 1010 and an input device 1020, and has a configuration in which an arithmetic unit 1030, a primary storage device 1040, a secondary storage device 1050, an output interface 1060, an input interface 1070, and a network interface 1080 are connected by a bus 1090.

[0192] The arithmetic unit 1030 operates based on programs stored in the primary storage device 1040 and the secondary storage device 1050, as well as programs read from the input device 1020, and executes various processes. The arithmetic unit 1030 can be implemented using, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), an ASIC (Application Specific Integrated Circuit), or an FPGA (Field Programmable Gate Array).

[0193] The primary storage device 1040 is a memory device, such as RAM (Random Access Memory), that temporarily stores data used by the arithmetic unit 1030 for various calculations. The secondary storage device 1050 is a storage device where data used by the arithmetic unit 1030 for various calculations and various databases are registered, and can be implemented using ROM (Read Only Memory), HDD (Hard Disk Drive), SSD (Solid State Drive), flash memory, etc. The secondary storage device 1050 may be internal storage or external storage. The secondary storage device 1050 may also be a removable storage medium such as USB (Universal Serial Bus) memory or SD (Secure Digital) memory card. The secondary storage device 1050 may also be cloud storage (online storage), NAS (Network Attached Storage), file server, etc.

[0194] The output I / F 1060 is an interface for transmitting information to be output to output devices 1010, such as displays, projectors, and printers, and is implemented using connectors of standards such as USB (Universal Serial Bus), DVI (Digital Visual Interface), and HDMI (High Definition Multimedia Interface). The input I / F 1070 is an interface for receiving information from various input devices 1020, such as mice, keyboards, keypads, buttons, and scanners, and is implemented using, for example, USB.

[0195] Furthermore, the output interface 1060 and input interface 1070 may be wirelessly connected to the output device 1010 and input device 1020, respectively. In other words, the output device 1010 and input device 1020 may be wireless devices.

[0196] Furthermore, the output device 1010 and the input device 1020 may be integrated as a touch panel. In this case, the output I / F 1060 and the input I / F 1070 may also be integrated as an input / output I / F.

[0197] The input device 1020 may also be a device that reads information from, for example, an optical recording medium such as a CD (Compact Disc), DVD (Digital Versatile Disc), or PD (Phase Change Rewritable Disk), a magneto-optical recording medium such as an MO (Magneto-Optical disk), a tape medium, a magnetic recording medium, or a semiconductor memory.

[0198] The network interface 1080 receives data from other devices via network N and sends it to the computing unit 1030, and also transmits data created by the computing unit 1030 to other devices via network N.

[0199] The arithmetic unit 1030 controls the output device 1010 and the input device 1020 via the output interface 1060 and the input interface 1070. For example, the arithmetic unit 1030 loads a program from the input device 1020 or the secondary storage device 1050 onto the primary storage device 1040 and executes the loaded program.

[0200] For example, when computer 1000 functions as a server device 100, the arithmetic unit 1030 of computer 1000 realizes the functions of the control unit 130 by executing a program loaded onto the primary storage device 1040. Alternatively, the arithmetic unit 1030 of computer 1000 may load a program obtained from another device via the network interface 1080 onto the primary storage device 1040 and execute the loaded program. Furthermore, the arithmetic unit 1030 of computer 1000 may cooperate with other devices via the network interface 1080 and call and use program functions, data, etc., from other programs on other devices.

[0201] [9. Other] Although embodiments of the present invention have been described above, the present invention is not limited by the content of these embodiments. Furthermore, the aforementioned components include those that can be easily conceived by those skilled in the art, those that are substantially the same, and those that fall within the so-called equivalent range. Moreover, the aforementioned components can be combined as appropriate. Furthermore, various omissions, substitutions, or modifications of the components can be made without departing from the gist of the embodiments described above.

[0202] Furthermore, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically by known methods. In addition, the processing procedures, specific names, and information including various data and parameters shown in the above document and drawings can be arbitrarily changed unless otherwise specified. For example, the various information shown in each figure is not limited to the information shown.

[0203] Furthermore, the components of each illustrated device are functionally conceptual and do not necessarily need to be physically configured as shown. In other words, the specific forms of distribution and integration of each device are not limited to those shown, and all or part of them can be functionally or physically distributed and integrated in any unit according to various loads and usage conditions.

[0204] For example, the server device 100 described above may be implemented using multiple server computers, and the configuration can be flexibly changed, such as by calling external platforms via APIs (Application Programming Interfaces) or network computing depending on the function.

[0205] Furthermore, the embodiments and modifications described above can be combined as appropriate, provided that the processing content is not inconsistent.

[0206] Furthermore, the terms "section, module, unit" mentioned above can be replaced with "means" or "circuit," etc. For example, the acquisition unit can be replaced with acquisition means or acquisition circuit. [Explanation of symbols]

[0207] 1. Information Processing System 10 Terminal devices 33 Processing Unit 34A Certificate Receiving Unit 35A Key Creation Department for Identity Verification 35B Key Management Department for Identity Verification 35C Key Disclosure Section for Identity Verification 36A Cassette Receiver 36B Certificate Renewal Section 36C Presentation Certificate Creation Department 36D Signature section of the presented certificate 37A Certificate Presentation Section 40C VC Management App 100 Server Devices 110 Communications Department 120 Storage section 121 User Information Database 122 History Information Database 123 Key Information Database 124 Cassette Information Database 130 Control Unit 131 Acquisition Department 132 Registration Processing Unit 133 Authentication Processing Unit 134 Certificate Issuance Department 135A Cassette Creation Unit 135B Cassette Key Creation Unit 135C Certificate Key Creation Section 136A Cassette Key Registration Unit 136B Certificate Key Management Department 136C Certificate Key Registration Section 137 Certificate Signature Section 138A Certificate Provision Department 138B Cassette Distributor 138C Service Department 200 repositories

Claims

1. An information processing device for handling verifiable certificates, As a function of the issuer of verifiable certificates, A certificate issuing unit that issues verifiable certificates about users, A certificate providing unit that provides the verifiable certificate to the user's terminal device, A cassette creation unit that creates a cassette having a function to update the verifiable certificate, A cassette key creation unit creates a key pair consisting of a cassette verification private key used for signing when the cassette updates the verifiable certificate on the user's terminal device side, and a cassette verification public key for verifying the signature made by the cassette. A cassette key registration unit that registers the aforementioned public key for cassette verification in a public repository, A cassette supply unit provides the cassette along with the cassette verification secret key to the user's terminal device, An information processing device characterized by comprising:

2. An information processing device for handling verifiable certificates, As a function of the issuer of verifiable certificates, A certificate key creation unit creates a key pair consisting of a VC verification private key used to sign a verifiable certificate relating to a user and a VC verification public key for verifying the signature of the verifiable certificate. A certificate signing unit that signs the verifiable certificate using the aforementioned VC verification private key, A certificate key management unit that internally stores the aforementioned VC verification private key, A certificate key registration unit that registers the aforementioned VC verification public key in a public repository, A certificate issuing unit that issues the aforementioned verifiable certificate, A certificate providing unit that provides the verifiable certificate to the user's terminal device, A cassette creation unit that creates a cassette having a function to update the verifiable certificate, A cassette supply unit that provides the cassette to the user's terminal device, An information processing device characterized by comprising:

3. An information processing device for handling verifiable certificates, As a function of the holder of a verifiable certificate, A certificate receiving unit that receives a verifiable certificate concerning a user issued by a certificate issuer, A cassette receiving unit that receives a cassette having the function of updating the verifiable certificate created by the issuer of the aforementioned certificate, A certificate update unit that updates the verifiable certificate using the functions of the cassette, A certificate presentation unit that transmits and presents the updated verifiable certificate to the certificate verifier, The information processing apparatus according to claim 1, further comprising:

4. The cassette receiving unit receives, along with the cassette, a private key for cassette verification used to sign the verifiable certificate when it is renewed by the function of the cassette, from the issuer of the certificate. The certificate renewal unit updates the verifiable certificate using the cassette's function and signs the updated verifiable certificate using the cassette's verification private key. The information processing apparatus according to claim 3.

5. The system further includes a presentation certificate creation unit that, based on the functionality of the cassette, combines multiple verifiable certificates to create a single presentation certificate. When the verifiable certificate is updated by the cassette's function, the aforementioned certificate creation unit attaches the encrypted pre-update verifiable certificate and the updated verifiable certificate to the certificate being presented. The information processing apparatus according to feature 4.

6. A key creation unit for identity verification creates a key pair consisting of a private key for identity verification that authenticates that the user created it, and a corresponding public key for identity verification. A signature unit for the presentation certificate that signs the presentation certificate using the aforementioned private key for identity verification, The personal identification key management unit stores the aforementioned personal identification private key internally, The identity verification key disclosure unit discloses the aforementioned identity verification public key, The information processing apparatus according to claim 5, further comprising:

7. An information processing method performed by an information processing device that handles verifiable certificates, When an information processing device functions as an issuer of verifiable certificates, The certificate issuance process involves issuing verifiable certificates about users, A certificate provision step of providing the verifiable certificate to the user's terminal device, A cassette creation process that creates a cassette having the function of updating the aforementioned verifiable certificate, A cassette key creation step involves creating a key pair on the user's terminal device side, which consists of a cassette verification private key used for signing when the cassette updates the verifiable certificate, and a cassette verification public key for verifying the signature made by the cassette. The process of registering the aforementioned public key for cassette verification in a public repository is a cassette key registration process, A cassette provision step of providing the cassette along with the private key for cassette verification to the user's terminal device, An information processing method characterized by including

8. An information processing method performed by an information processing device that handles verifiable certificates, When an information processing device functions as an issuer of verifiable certificates, A certificate key creation step involves creating a key pair consisting of a VC verification private key used to sign a verifiable certificate relating to a user, and a VC verification public key used to verify the signature of the verifiable certificate. A certificate signing step in which the verifiable certificate is signed using the VC verification private key, A certificate key management process for internally storing the aforementioned VC verification private key, The process of registering the aforementioned VC verification public key in a public repository is a certificate key registration process, A certificate issuance process for issuing the aforementioned verifiable certificate, A certificate provision step of providing the verifiable certificate to the user's terminal device, A cassette creation process that creates a cassette having the function of updating the aforementioned verifiable certificate, A cassette provision step of providing the cassette to the user's terminal device, An information processing method characterized by including

9. An information processing method performed by an information processing device that handles verifiable certificates, When acting as a holder of a verifiable certificate, The certificate receiving process involves receiving a verifiable certificate concerning a user issued by the certificate issuer, A cassette receiving step includes receiving a cassette having a function to update the verifiable certificate created by the issuer of the aforementioned certificate, A certificate renewal process in which the verifiable certificate is updated by the function of the cassette, A certificate transmission step of sending and presenting the updated verifiable certificate to the certificate verifier, The information processing method according to claim 7, further comprising:

10. An information processing program to be executed by an information processing device that handles verifiable certificates, To enable an information processing device to function as an issuer of verifiable certificates, Certificate issuance procedure for issuing verifiable certificates about users, A certificate provision procedure for providing the verifiable certificate to the user's terminal device, A cassette creation procedure for creating a cassette that has the function to update the aforementioned verifiable certificate, A procedure for creating a cassette key, which involves creating a key pair on the user's terminal device side, consisting of a cassette verification private key used for signing when the cassette updates the verifiable certificate, and a cassette verification public key for verifying the signature made by the cassette, The procedure for registering the aforementioned public key for cassette verification in a public repository, A cassette provision procedure for providing the cassette along with the private key for cassette verification to the user's terminal device, An information processing program characterized by causing an information processing device to execute it.

11. An information processing program to be executed by an information processing device that handles verifiable certificates, To enable an information processing device to function as an issuer of verifiable certificates, A procedure for creating a certificate key, which involves creating a key pair consisting of a VC verification private key used to sign a verifiable certificate relating to a user, and a VC verification public key used to verify the signature of the said verifiable certificate, A certificate signing procedure that signs the verifiable certificate using the aforementioned VC verification private key, A certificate key management procedure for internally storing the aforementioned VC verification private key, The procedure for registering the aforementioned VC verification public key in a public repository is a certificate key registration procedure, A certificate issuance procedure for issuing the aforementioned verifiable certificate, A certificate provision procedure for providing the verifiable certificate to the user's terminal device, A cassette creation procedure for creating a cassette that has the function to update the aforementioned verifiable certificate, A cassette provision procedure for providing the cassette to the user's terminal device, An information processing program characterized by causing an information processing device to execute it.

12. An information processing program to be executed by an information processing device that handles verifiable certificates, To enable the information processing device to function as a holder of a verifiable certificate, Certificate receiving procedure for receiving a verifiable certificate about a user issued by the certificate issuer, A cassette receiving procedure for receiving a cassette having the function of updating the verifiable certificate created by the issuer of the aforementioned certificate, A certificate update procedure for updating the verifiable certificate using the functions of the aforementioned cassette, A certificate transmission procedure for sending and presenting the updated verifiable certificate to the certificate verifier, The information processing program according to claim 10, further characterized by causing an information processing device to execute it.

Images