WO2022004854A1 - 利用者端末、認証者端末、登録者端末、管理システムおよびプログラム - Google Patents

利用者端末、認証者端末、登録者端末、管理システムおよびプログラム Download PDF

Info

Publication number
WO2022004854A1
WO2022004854A1 PCT/JP2021/025001 JP2021025001W WO2022004854A1 WO 2022004854 A1 WO2022004854 A1 WO 2022004854A1 JP 2021025001 W JP2021025001 W JP 2021025001W WO 2022004854 A1 WO2022004854 A1 WO 2022004854A1
Authority
WO
WIPO (PCT)
Prior art keywords
distributed ledger
ledger network
token
distributed
control unit
Prior art date
Application number
PCT/JP2021/025001
Other languages
English (en)
French (fr)
Inventor
盛徳 大橋
達郎 石田
篤 中平
滋 藤村
昌義 近田
順一 岸上
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to US18/010,313 priority Critical patent/US20230232222A1/en
Publication of WO2022004854A1 publication Critical patent/WO2022004854A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration

Definitions

  • the present invention relates to a user terminal, an certifier terminal, a registrant terminal, a management system and a program using the distributed ledger technology.
  • blockchain which is a type of decentralized distributed ledger technology, is used. Since blockchain has high robustness against tampering, it is being considered for use in various applications such as smart contracts that can execute various contracts and transactions, in addition to cryptocurrencies.
  • As a programmable blockchain that can handle smart contracts for example, there is Ethereum that can execute a general-purpose decentralized application.
  • Distributed ledger technology that can realize various smart contracts has a data structure that organizes transactions into blocks and links the blocks with hashes, so it is not suitable for managing files with large data sizes.
  • Non-Patent Document 1 As a distributed file management method, there is a storage that manages files with a unique identifier (ID) created from a content hash or the like (see, for example, Non-Patent Document 1). There is also a method of registering a file in the storage and recording and managing the file ID in the distributed ledger (see, for example, Non-Patent Document 2). Further, in addition to the file ID, a method of managing a decentralized identifier (DID: Decentralized ID) created by an individual on Ethereum is also being studied.
  • DID Decentralized ID
  • DID and file management are performed in a distributed ledger, it is assumed that DID and file metadata are managed by a contract registered in a programmable blockchain such as Ethereum, and files are managed in external storage or external distributed file storage. Will be done. That is, an administrator is required for the contract for managing the DID. However, the management structure required by the administrator can be a single point of failure. In particular, unlike the management of file metadata, DID is highly common information, so a management structure that depends on a specific administrator is not appropriate for managing DID.
  • the present invention has been made by paying attention to the above circumstances, and an object thereof is to provide a user terminal, an certifier terminal, a registrant terminal, a management system and a program capable of realizing robust and flexible information management. It is in.
  • the user terminal is a user terminal that can be connected to the first distributed ledger network and the second distributed ledger network, and is a generation unit and a first.
  • a control unit and a second control unit are included.
  • the generator uses the verification key to generate a distributed identifier for the user.
  • the first control unit generates a registration transaction including the verification key and the distributed identifier, and transmits the registration transaction to the first distributed ledger network.
  • the second control unit generates a token transaction related to the issuance of a token including the user data and the distributed identifier, and transmits the token transaction to the second distributed ledger network.
  • the certifier terminal relates to a first distributed ledger network in which a distributed identifier relating to a user and a verification key associated with the distributed identifier are held in a distributed ledger, and the user.
  • An certifier terminal capable of connecting to a second distributed ledger network in which a token containing encrypted data is held in the distributed ledger, and is an acquisition unit, a first control unit, a second control unit, and a decryption unit. And the verification department.
  • the acquisition unit acquires the distributed identifier, the identity verification information about the user, and the decryption key.
  • the first control unit refers to the first distributed ledger network and extracts the verification key associated with the distributed identifier.
  • the second control unit refers to the second distributed ledger network and extracts the encrypted data to be authenticated by using the access information to the token.
  • the decryption unit decodes the encrypted data using the decryption key.
  • the verification unit verifies the signature given to the token using the verification key, and verifies the decrypted data using the identity verification information.
  • the registrant terminal relates to a first distributed ledger network in which a distributed identifier relating to a user and a verification key associated with the distributed identifier are held in a distributed ledger, and the user.
  • the generation unit generates additional information newly associated with the distributed identifier.
  • the encryption unit encrypts the additional information.
  • the control unit generates a registration transaction for associating the encrypted additional information with the token, and transmits the registration transaction to the second distributed ledger network.
  • the transmission unit transmits the access information to the token associated with the additional information and the decryption key for decrypting the encrypted additional information.
  • the management system is a management system including a user terminal and an certifier terminal that can access the first distributed ledger network and the second distributed ledger network.
  • the user terminal includes a generation unit, an encryption unit, a first control unit, and a second control unit.
  • the generator uses the verification key to generate a distributed identifier for the user.
  • the encryption unit encrypts the user's data.
  • the first control unit generates a registration transaction including the verification key and the distributed identifier, and transmits the registration transaction to the first distributed ledger network.
  • the second control unit generates a token transaction related to the issuance of a token including the encrypted data of the user and the distributed identifier, and transmits the token transaction to the second distributed ledger network.
  • the certifier terminal includes an acquisition unit, a first control unit, a second control unit, a decoding unit, and a verification unit.
  • the acquisition unit acquires the distributed identifier, the identity verification information about the user, and the decryption key from the user terminal.
  • the first control unit refers to the first distributed ledger network and extracts the verification key associated with the distributed identifier.
  • the second control unit refers to the second distributed ledger network and extracts the encrypted data to be authenticated by using the access information to the token.
  • the decryption unit decodes the encrypted data using the decryption key.
  • the verification unit verifies the signature given to the token using the verification key, and verifies the decrypted data using the identity verification information.
  • FIG. 1 is a conceptual diagram of a management system according to the present embodiment.
  • FIG. 2 is a block diagram showing a user terminal according to the present embodiment.
  • FIG. 3 is a block diagram showing an certifier terminal according to the present embodiment.
  • FIG. 4 is a block diagram showing a registrant terminal according to the present embodiment.
  • FIG. 5 is a sequence diagram showing an example of the DID registration process of the management system according to the present embodiment.
  • FIG. 6 is a sequence diagram showing an example of the DID registration process of the management system according to the present embodiment.
  • FIG. 7 is a sequence diagram showing an example of the DID authentication process of the management system according to the present embodiment.
  • FIG. 8 is a sequence diagram showing an example of a recording process of the DID authentication result of the management system according to the present embodiment.
  • FIG. 9 is a sequence diagram showing an example of the DID registration process in the management system when additional information is registered in the DID.
  • FIG. 10 is a sequence diagram showing an example of the DID registration process in the management system when additional information is registered in the DID.
  • FIG. 11 is a sequence diagram showing an example of confirmation processing of additional information of the management system according to the present embodiment.
  • the management system 10 includes a user terminal 1, an certifier terminal 2, a storage service 8, a first distributed ledger network 4, a second distributed ledger network 5, and a registrant terminal 3. ..
  • the user terminal 1 is a terminal that generates a distributed identifier (DID) and generates data to be associated with the DID (also referred to as association data).
  • DID distributed identifier
  • the linking data is assumed to be, for example, data related to an individual, an organization or a thing including the person, or metadata incidental to the data, but it is meaningful to manage by linking with the DID. Anything can be used as long as it is available.
  • the user terminal 1 can be connected to the first distributed ledger network 4, the second distributed ledger network 5, and the storage service 8. Further, the user terminal 1 manages an account that can be connected to the first distributed ledger network 4, the second distributed ledger network 5, and the storage service 8, respectively, and a signature key associated with the account and a corresponding verification key. ..
  • the signature key a value common to the first distributed ledger network 4, the second distributed ledger network 5, and the storage service 8 may be used, or different values may be used.
  • the signature key may be stored in the storage unit 12 of the user terminal 1 or a SIM (Subscriber Identity Module), or is managed in a storage location different from the user terminal 1 such as a cloud server, a dedicated device, or paper. May be good.
  • SIM Subscriber Identity Module
  • the certifier terminal 2 is a terminal that authenticates the association between the DID generated by the user terminal 1 and the token generated on the second distributed ledger network 5.
  • the certifier terminal 2 is assumed to be a certification body having a social position, but is not limited to this, and may be an organization, an organization, or an individual who performs genuine certification.
  • the certifier terminal 2 can access the first distributed ledger network 4, the second distributed ledger network 5, and the storage service 8.
  • the certifier terminal 2 also manages the signature key associated with the account that can be connected to the first distributed ledger network 4 and the second distributed ledger network 5.
  • the registrant terminal 3 is a terminal that generates new information (hereinafter referred to as additional information) for associating with the DID generated by the user terminal 1.
  • the registrant terminal 3 can also access the first distributed ledger network 4, the second distributed ledger network 5, and the storage service 8 in the same manner as the user terminal 1 or the certifier terminal 2. Further, the signature key associated with the account that can be connected to the first distributed ledger network 4 and the second distributed ledger network 5 is managed.
  • the first distributed ledger network 4 is a network using a decentralized distributed ledger technology that does not require a specific administrator.
  • the first distributed ledger network 4 assumes a blockchain network such as Namecoin that can register data in a key-value store format, but at least two elements can be related and managed by the distributed ledger, and transaction verification and execution can be performed. , Any distributed ledger technology that does not include the process acquired by a specific administrator in the process of registration to the ledger.
  • the second distributed ledger network 5 is a network using a logical centralized distributed ledger technology that requires a specific administrator.
  • the second distributed ledger network 5 assumes a blockchain network such as EOS and Ethereum that can realize a decentralized application (DApps) related to blockchain applications such as smart contracts, but is a program executed by a transaction. Any network using distributed ledger technology, in which registration and management are acquired by a specific administrator, may be used.
  • the storage service 8 is a service that manages personal information acquired from the user terminal 1 as a file in a database or the like.
  • the storage service 8 registers a file
  • the storage service 8 issues a registration identifier (registration ID) for the file.
  • the registration ID is an identifier that uniquely identifies the file, and is also referred to as a file identifier.
  • the storage service 8 may be a centralized type in which a server (not shown) manages files, or terminals involved in the maintenance of the storage service 8 such as IPFS (InterPlanetary File System) and Swarm are distributed and P2P (P2P). Peer to Peer) It may be a decentralized type that manages files on the network.
  • the first distributed ledger network 4 and the second distributed ledger network 5 are assumed to be different independent networks, but the data processing innately provided in the base does not require a specific administrator. 1st distributed ledger network 4 and 2nd distributed ledger network 5 in one distributed ledger network, if it is possible to distinguish between the layer of the above and the layer of data processing by a program registered by a specific administrator acquiredly. May be configured.
  • the user terminal 1, the certifier terminal 2, and the registrant terminal 3 belong to the first distributed ledger network 4 and the second distributed ledger network 5, and may have a node function for maintaining their respective networks. ..
  • the node function is a function that performs transaction verification processing, approval processing, and update and retention of ledger information (block information, state database, etc.).
  • the certifier terminal 2, and the registrant terminal 3 even if a terminal (referred to as another node) that substitutes for the node function exists in the first distributed ledger network 4 and the second distributed ledger network 5. good.
  • another node 6 that maintains the first distributed ledger network 4 may exist, or another node 7 that maintains the second distributed ledger network 5 may exist.
  • the user terminal 1, the certifier terminal 2, and the registrant terminal 3 may not include the node function when another node 6 and another node 7 that substitute for the node function exist. In this embodiment, a case where the user terminal 1, the certifier terminal 2, and the registrant terminal 3 also execute the node function will be described.
  • the user terminal 1 includes a processing circuit 11, a storage unit 12, and a communication interface 13.
  • the processing circuit 11 includes an acquisition unit 111, a generation unit 112, an encryption unit 113, a first distributed ledger control unit 114, a second distributed ledger control unit 115, and a communication control unit 116.
  • the acquisition unit 111 acquires personal information to be linked to the DID and a file to be registered in the storage service 8. Further, the acquisition unit 111 acquires the registration ID from the storage service 8.
  • the generation unit 112 generates a signature key for DID and a verification key corresponding to the signature key.
  • the generation unit 112 uses the verification key to generate a DID for the user. Further, the generation unit 112 may generate the association data for association with the DID.
  • the encryption unit 113 encrypts the data for association.
  • the encryption method for example, a common key encryption method using a common key is assumed, but any method may be used as long as it is an encryption method in which security strength is guaranteed.
  • the first distributed ledger control unit 114 generates a registration transaction including a DID and a verification key.
  • the first distributed ledger control unit 114 transmits the registration transaction to the first distributed ledger network 4. Further, the first distributed ledger control unit 114 executes a node function for maintaining the first distributed ledger network.
  • the first distributed ledger control unit 114 includes the registration ID issued by the storage service 8 in the registration transaction.
  • the second distributed ledger control unit 115 relates to token data including a signature target message including user data and a DID, and a signature value obtained by digitally signing the signature target message with the user's signature key. Generate a token transaction. Token data is data related to the issuance of tokens.
  • the second distributed ledger control unit 115 transmits the token transaction to the second distributed ledger network 5.
  • the second distributed ledger control unit 115 executes the node function in the same manner as the first distributed ledger control unit 114.
  • the communication control unit 116 controls data communication between the storage service 8, the first distributed ledger network 4, and the second distributed ledger network 5.
  • the communication control unit 116 performs a process of transmitting data to the storage service 8 and receiving a registration ID related to the data, it is also called a registration unit.
  • the storage unit 12 includes ledger data of the first distributed ledger network 4 and the second distributed ledger network 5, a key pair for issuing a transaction, a key pair for linking proof, a file, and an identifier of a registered transaction issued by itself (registered transaction). It also stores ID), access information to tokens, and so on.
  • the access information to the token is information for referring to the information stored in the token or the information stored in the token transaction used for token generation. Specifically, for example, the identifier of the token transaction (token). (Also referred to as a transaction ID), a contract address, access interface information, and an ID assigned or assigned to a token.
  • the communication interface 13 is an interface for data communication between the first distributed ledger network 4, the second distributed ledger network 5, and the storage service 8, respectively. Since the communication interface 13 may use a generally used communication interface, the description thereof is omitted here.
  • the certifier terminal 2 includes a processing circuit 21, a storage unit 22, and a communication interface 23.
  • the processing circuit 21 includes an acquisition unit 211, a decoding unit 212, a verification unit 213, a first distributed ledger control unit 214, a second distributed ledger control unit 215, and a communication control unit 216.
  • the acquisition unit 211 acquires, for example, a DID, identity verification information, and a decryption key as an authentication request from the user terminal 1.
  • the identity verification information may be any information obtained from documents for certifying the identity, such as a driver's license, a health insurance card, and a passport, which are required from services using DID.
  • the decryption key is a key for decrypting the encrypted data for association.
  • the decryption unit 212 decodes the associated data encrypted by using the decryption key.
  • the verification unit 213 verifies the signature given to the token using the verification key, and verifies the decrypted association data using the identity verification information.
  • the first distributed ledger control unit 214 refers to the first distributed ledger network 4 and extracts the verification key.
  • the second distributed ledger control unit 215 refers to the second distributed ledger network 5 and extracts encrypted data for association to be authenticated by using the access information to the token.
  • the first distributed ledger control unit 214 and the second distributed ledger control unit 215 realize the same node functions as the first distributed ledger control unit 114 and the second distributed ledger control unit 115 of the registrant terminal, respectively.
  • the communication control unit 217 controls data communication between the first distributed ledger network 4, the second distributed ledger network 5, and the storage service 8.
  • the storage unit 22 stores ledger data of the first distributed ledger network 4 and the second distributed ledger network 5, a key pair for issuing a transaction, access information to a token, a registered transaction ID, and the like, if necessary.
  • the communication interface 23 performs almost the same processing as the communication interface 13 of the user terminal 1.
  • the registrant terminal 3 includes a processing circuit 31, a storage unit 32, and a communication interface 33.
  • the processing circuit 31 includes an acquisition unit 311, a decryption unit 312, an information generation unit 313, an encryption unit 314, a verification unit 315, a first distributed ledger control unit 316, and a second distributed ledger control unit 317. Includes a communication control unit 318.
  • the acquisition unit 311 receives the DID, the decryption key, the identity verification information, the access information to the token, and the like from the user terminal 1. Similar to the decryption unit 212, the decryption unit 312 decodes the associated data encrypted by using the decryption key. The information generation unit 313 generates additional information to be newly associated with the DID separately from the association data. The encryption unit 314 encrypts the additional information. As the encryption method, the same method as that of the encryption unit 113 may be used. Similar to the verification unit 213, the verification unit 315 verifies the signature given to the token using the verification key, and verifies the decrypted association data using the identity verification information.
  • the first distributed ledger control unit 316 refers to the first distributed ledger network 4 and extracts the verification key associated with the DID.
  • the second distributed ledger control unit 317 refers to the second distributed ledger network 5 and extracts encrypted data for association to be authenticated by using the access information to the token.
  • the first distributed ledger control unit 316 and the second distributed ledger control unit 317 realize the same node functions as the first distributed ledger control unit 114 and the second distributed ledger control unit 115 of the registrant terminal, respectively.
  • the communication control unit 318 controls data communication between the first distributed ledger network 4, the second distributed ledger network 5, and the storage service 8.
  • the storage unit 32 stores ledger data of the first distributed ledger network 4 and the second distributed ledger network 5, a key pair for issuing a transaction, access information to a token, and the like.
  • the communication interface 33 performs almost the same processing as the communication interface 13 of the user terminal 1.
  • the processing circuit 11 of the user terminal 1, the processing circuit 21 of the certifier terminal 2, and the processing circuit 31 of the registrant terminal 3 are processors such as a CPU (Central Processing Unit) and a GPU (Graphics Processing Unit), respectively, or It is composed of integrated circuits such as FPGA (Field Programmable Gate Array) and ASIC (Application Specific Integrated Circuit).
  • processors such as a CPU (Central Processing Unit) and a GPU (Graphics Processing Unit), respectively, or It is composed of integrated circuits such as FPGA (Field Programmable Gate Array) and ASIC (Application Specific Integrated Circuit).
  • FPGA Field Programmable Gate Array
  • ASIC Application Specific Integrated Circuit
  • the storage unit 12 of the user terminal 1, the storage unit 22 of the certifier terminal 2, and the storage unit 32 of the registrant terminal 3 are, for example, HDD (Hard Disk Drive), SSD (Solid State Drive), flash memory, etc., respectively. Consists of commonly used storage media.
  • FIG. 5 is a sequence showing a time series regarding data transmission / reception between the user terminal 1 and the first distributed ledger network 4.
  • terminals user terminal 1, certifier terminal 2 and registrant terminal 3 not shown are also the first distributed ledger network 4 and the second distributed terminal. You may participate as a node to maintain the ledger network 5.
  • the certifier terminal 2 and the registrant terminal 3 may execute transaction verification and approval in the first distributed ledger network 4 as nodes.
  • step S501 the generation unit 112 of the user terminal 1 generates a signature key for DID and a verification key corresponding to the signature key.
  • step S502 the generation unit 112 of the user terminal 1 creates a DID using the verification key.
  • the hash value of the verification key may be DID.
  • the hash value of the hash value of the verification key that is, the double hash may be used as the DID, and any value may be used as the DID as long as it is a uniquely identifiable value that does not cause a value collision.
  • the first distributed ledger control unit 114 of the user terminal 1 generates a registration transaction including a DID and a verification key.
  • the first distributed ledger control unit 114 digitally signs the registration transaction with the signature key generated to use the first distributed ledger network 4, and digitally signs the registration transaction. Broadcast the registration transaction to the first distributed ledger network 4.
  • a plurality of terminals having a node function in the first distributed ledger network 4 verify a registration transaction by a consensus algorithm. If the registration transaction meets certain requirements, the registration transaction is included in the block. Here, assuming that the registration transaction satisfies a predetermined requirement, the registration transaction is confirmed by the first distributed ledger network 4.
  • step S505 the first distributed ledger control unit 114 of the user terminal 1 receives the registration result of the registration transaction from the first distributed ledger network 4.
  • the registration result is, for example, the registration transaction and the approval result (True or False or status code), and the block number of the registration transaction when it is registered in the block.
  • step S506 for example, the communication control unit 116 of the user terminal 1 notifies the user of the user terminal 1 of the completion of DID creation.
  • the notification method any method may be used, such as displaying the completion of creation on the screen or notifying by voice or sound.
  • FIG. 6 is a sequence showing a time series regarding data transmission / reception between the user terminal 1, the first distributed ledger network 4, the second distributed ledger network 5, and the storage service 8.
  • personal information such as personal information of a user is assumed as the linking data.
  • the encrypted personal information metadata is included in the token, and the encrypted personal information itself (or the remaining data of the personal information contained in the token) is registered in the storage service 8 as a file. do.
  • step S601 the generation unit 112 of the user terminal 1 creates personal information.
  • the personal information and the metadata of the personal information are created.
  • the encryption unit 113 of the user terminal 1 encrypts the personal information created in step S601 and the metadata of the personal information with a common key.
  • the communication control unit 116 of the user terminal 1 transmits the encrypted personal information to the storage service 8 via the communication interface 13.
  • step S604 the storage service 8 registers the encrypted personal information, and the management is started.
  • step S605 the storage service 8 issues an ID (hereinafter referred to as a registration ID) for the registered personal information.
  • the registration ID may be, for example, a character string created from the hash value of a file such as a fingerprint, or an ID including a phrase indicating a service provider in addition to the character string created from the hash value. Alternatively, it may be an identifier such as a URI (Uniform Resource Identifier). That is, an identifier that can uniquely identify the registered personal information may be issued.
  • URI Uniform Resource Identifier
  • a signature target message regarding token issuance including a DID (or a hash value of the DID), encrypted personal information metadata, and a registration ID, and a signature value obtained by digitally signing the signature target message with a signature key are included.
  • Generate a token transaction The second distributed ledger control unit 115 of the user terminal 1 digitally signs the token transaction with the signature key generated to use the second distributed ledger network 5 in order to make the token transaction a valid transaction. , The digitally signed token transaction is broadcast to the second distributed ledger network 5.
  • the second distributed ledger network 5 verifies the token transaction by a consensus algorithm. If the token transaction meets certain requirements, the token transaction is included in the block. Here, assuming that the token transaction meets a predetermined requirement, the token transaction is approved by the second distributed ledger network 5.
  • step S608 the second distributed ledger control unit 115 of the user terminal 1 receives the registration result of the token transaction from the second distributed ledger network 5.
  • the registration result is, for example, a token transaction and an approval result (True or False or status code), and if the token transaction is registered in the block, its block number.
  • the information of the token approved on the second distributed ledger network 5 is associated with the DID already approved on the first distributed ledger network 4.
  • the first distributed ledger control unit 114 of the user terminal 1 generates a registration transaction including the DID and the identification information of the token.
  • the token identification information is, in other words, access information to the token, and includes a transaction ID given to the token transaction and a block number in which the token transaction is incorporated. Further, a unique ID may be newly generated as the identification information of the token. For example, a unique ID generated by connecting the contract ID and the token identifier by separating them with a colon ":”, such as "Token: contract ID: token identifier”, may be used as the identification information for the token.
  • the first distributed ledger control unit 114 digitally signs the registration transaction with the signature key generated to use the first distributed ledger network 4, and digitally signs the registration transaction. Broadcast the registration transaction to the first distributed ledger network 4.
  • step S610 a plurality of terminals having a node function in the first distributed ledger network 4 verify a registration transaction by a consensus algorithm. If the registration transaction meets certain requirements, the registration transaction is included in the block. Here, assuming that the registration transaction satisfies a predetermined requirement, the registration transaction is confirmed by the first distributed ledger network 4.
  • step S611 the first distributed ledger control unit 114 of the user terminal 1 receives the registration result of the registration transaction from the first distributed ledger network 4.
  • the registration result is, for example, the registration transaction and the approval result (True or False or status code), and the block number of the registration transaction when it is registered in the block.
  • step S612 for example, the communication control unit 116 of the user terminal 1 notifies the user of the completion of the association between the encrypted personal information and the DID.
  • FIG. 6 shows an example of registering the encrypted personal information in the storage service 8, it is not necessary to register the encrypted personal information in the storage service 8.
  • the signature target message including the DID and the encrypted personal information and the signature value may be included in the token transaction, the processes from step S603 to step S605 shown in FIG. 6 are omitted.
  • the encrypted personal information may be registered in the storage service 8, and the token transaction may include the registration ID without including the metadata of the encrypted personal information.
  • step S606 a token transaction including the signature target message including the DID and the registration ID and the signature value is generated.
  • FIG. 7 is a sequence showing a time series regarding data transmission / reception between the user terminal 1, the certifier terminal 2, the first distributed ledger network 4, the second distributed ledger network 5, and the storage service 8.
  • the "request” and “return” in the sequence are shown as accessing the first distributed ledger network 4 and the second distributed ledger network 5, but the first distributed ledger network 4 and It can also be realized by the internal processing of the certifier terminal 2 without directly accessing the second distributed ledger network 5.
  • each terminal (user terminal 1, certifier terminal 2 and registrant terminal 3) participates in the first distributed ledger network 4 and the second distributed ledger network 5 as nodes, the terminal itself is the distributed ledger. This is because it plays a part in the network. That is, by referring to the distributed ledger held by each terminal, transactions and various data that match the verifier's request may be extracted.
  • step S701 the user terminal 1 notifies the certifier terminal 2 of the authentication request.
  • the user's DID, the decryption key, the identity verification information, and the access information to the token may be notified by, for example, an e-mail or a message application.
  • the decryption key is a key for decrypting the encrypted personal information metadata and the encrypted personal information registered in the storage service 8.
  • the token held in the second distributed ledger network 5 includes the DID
  • the user's DID may not be included in the information to be notified as the authentication request.
  • step S702 the second distributed ledger control unit 215 of the certifier terminal 2 designates the token to be authenticated by using the access information of the token as a search key, and performs DID and encryption for the second distributed ledger network 5.
  • the signature target message including the metadata of the personal information and the registration ID and the signature value thereof are requested. Specifically, necessary information may be requested by using, for example, the API of the corresponding token or the token transaction.
  • step S703 the signature target message including the DID, the encrypted personal information metadata and the registration ID, and the signature value thereof are returned from the second distributed ledger network 5 in response to the request from the certifier terminal 2. Will be done.
  • the second distributed ledger control unit 215 of the certifier terminal 2 refers to the second distributed ledger network 5, and the DID, the metadata of the encrypted personal information, and the metadata of the encrypted person information are used. It may be executed as a process of extracting the registration ID and the signature value.
  • step S704 the first distributed ledger control unit 214 of the certifier terminal 2 requests the first distributed ledger network 4 for a verification key associated with the same DID as the extracted DID.
  • step S705 the first distributed ledger network 4 returns the verification key corresponding to the DID in response to the request from the certifier terminal 2.
  • the processes of steps 704 and S705 may be executed as a process in which the first distributed ledger control unit 214 of the certifier terminal 2 refers to the first distributed ledger network 4 to extract the DID and the signature value. Further, for example, when the first distributed ledger network 4 is realized by Bitcoin Core, a registered transaction matching the registered transaction ID may be searched from the ledger, and a verification key associated with the DID may be obtained from the registered transaction.
  • step S706 the verification unit 213 of the certifier terminal 2 verifies the signature value with the verification key.
  • a verification method in a general digital signature may be used. If the verification determines that the signature value is genuine, it can be determined that the token is a genuine token sent by the user to the second distributed ledger network 5, and if it is determined that the signature value is not genuine, it is invalid. It can be determined that it is a token.
  • the communication control unit 216 of the certifier terminal 2 specifies the registration ID and requests the storage service 8 for the encrypted personal information.
  • step S708 the storage service 8 searches the database for the encrypted personal information corresponding to the registration ID and sends it to the certifier terminal 2.
  • step S709 the decryption unit 212 of the certifier terminal 2 decrypts the encrypted personal information metadata and the encrypted personal information with the decryption key acquired in step S701.
  • step S710 the verification unit 214 of the certifier terminal 2 verifies the consistency between the decrypted personal information and the personal verification document. If the decrypted personal information and the content disclosed in the personal verification document are the same, it can be determined that the personal information is genuine. On the other hand, if the decrypted identity information and the content disclosed in the identity verification document are not the same, it can be determined that either the identity information or the identity verification document may be fraudulent.
  • step S707 If the encrypted personal information is not registered in the storage service 8, the encrypted personal information is included in the token transaction and the encrypted personal information is returned in step S703. Therefore, steps S707 and step S707. S708 may be omitted, and the encrypted personal information may be decrypted in step S709.
  • the encrypted personal information is registered in the storage service 8 and only the registration ID is included in the token transaction, the principal encrypted from the storage service 8 in step S708 based on the registration ID extracted in step S703. Since the information is returned to the certifier terminal 2, the encrypted personal information may be decrypted in step S709.
  • the certifier terminal 2 may receive the sharing of the registered transaction ID directly or indirectly from the user terminal 1 in the first distributed ledger network 4, and store the shared registered transaction ID in the storage unit 22. ..
  • the second distributed ledger control unit 215 can efficiently extract the verification key by referring to the shared registration transaction ID stored in the storage unit 22. For example, when the distributed ledger network of Bitcoin is utilized as the first distributed ledger network 4, if the registered transaction ID is shared, it is useful when extracting the verification key.
  • FIG. 8 is a sequence showing a time series regarding data transmission / reception between the user terminal 1, the certifier terminal 2, and the second distributed ledger network 5.
  • step S801 the second distributed ledger control unit 215 of the certifier terminal 2 generates a registration transaction for recording the verification result.
  • the generated registration transaction is assumed to be a transaction that includes the certifier's ID, the date of authentication, confirmation means indicating how the identity information was confirmed, but other information such as the type of identity information confirmed. It may be a transaction including.
  • the second distributed ledger control unit 215 of the certifier terminal 2 digitally signs the generated registration transaction with the signature key generated for using the second distributed ledger network 5, and digitally signs the registration transaction. Broadcast to the second distributed ledger network 5.
  • step S802 the second distributed ledger network 5 verifies the registration transaction by the consensus algorithm. If the registration transaction meets certain requirements, the registration transaction is included in the block. Here, assuming that the registration transaction meets a predetermined requirement, the registration transaction is approved by the second distributed ledger network 5.
  • the second distributed ledger control unit 215 of the certifier terminal 2 receives the registration result of the registration transaction from the second distributed ledger network 5.
  • the registration result is, for example, the registration transaction and the approval result (True or False or status code), and the block number when the registration transaction is registered in the block.
  • step S804 for example, the acquisition unit 111 of the user terminal 1 receives the registration result from the certifier terminal 2. As a result, the user of the user terminal 1 can confirm that the information associated with the DID is authenticated as correct information and registered in the first distributed ledger network 4 and the second distributed ledger network 5. ..
  • FIG. 9 is a sequence showing a time series regarding data transmission / reception between the user terminal 1, the registrant terminal 3, the first distributed ledger network 4, the second distributed ledger network 5, and the storage service 8.
  • step S901 the user terminal 1 notifies the registrant terminal 3 of the information. Specifically, the acquisition unit 311 of the registrant terminal 3 acquires the DID, the decryption key, the identity verification information, and the access information to the token. Since the process from step S702 to step S709 may be performed by the registrant terminal 3 in the same manner as the process of the certifier terminal 2 shown in FIG. 7, the description thereof is omitted here. In step S902, it is confirmed whether or not the decrypted personal information has been authenticated by the certifier terminal 2.
  • step S706 it is possible to verify that the signature obtained from the token by the verification key is authentic, and further, in step S901, the token is authenticated by the DID certifier, and the personal information is decrypted. It suffices if it can be confirmed that the personal information to be linked with the information to be registered is correct.
  • the user terminal 1 may notify the registrant terminal 3 of a signature proving that the owner of the DID is the owner.
  • a digital signature may be given to the access information to the DID, the decryption key, and the token notified from the user terminal 1.
  • the registrant terminal 3 may verify the notified digital signature by the same method as in step S706, and confirm that the user terminal 1 is the owner of the DID.
  • FIG. 10 is a sequence showing a time series regarding data transmission / reception between the user terminal 1, the registrant terminal 3, the first distributed ledger network 4, the second distributed ledger network 5, and the storage service 8. be.
  • the token contains the metadata of the encrypted additional information, and the encrypted additional information itself (or the remaining data of the additional information contained in the token) is stored as a file in the storage service 8. It is assumed that it will be registered in.
  • step S1001 the information generation unit 313 of the registrant terminal 3 generates additional information associated with the DID.
  • step S1002 the encryption unit 314 of the registrant terminal 3 encrypts the additional information.
  • the encryption method may be the same as in step S602.
  • step S1003 the communication control unit 318 of the registrant terminal 3 transmits the encrypted additional information to the storage service 8 via the communication interface 33.
  • step S1004 the storage service 8 registers the encrypted additional information.
  • step S1005 the storage service 8 issues an ID (hereinafter, referred to as an additional registration ID) for the registered additional information.
  • the additional registration ID is assumed to have the same format as the registration ID.
  • step S1006 the registrant terminal 3 registers the encrypted additional information and the additional registration ID in the token on the second distributed ledger network 5. For example, the registrant terminal 3 registers the encrypted additional information or the additional information metadata including the additional registration ID in the token presented by the user terminal 1. Alternatively, in order to create a new token, a new token transaction including the encrypted additional information and the additional registration ID is generated, and the token transaction is broadcast. Here, it is assumed that a new token transaction is generated.
  • step S1007 when a new token transaction is generated, the second distributed ledger network 5 verifies the token transaction by the consensus algorithm. Here, it is assumed that the transaction is approved by the second distributed ledger network 5.
  • step S1008 the second distributed ledger control unit 317 of the registrant terminal 3 receives the registration result of the token transaction from the second distributed ledger network 5.
  • step S1009 for example, the communication control unit 318 of the registrant terminal 3 transmits the registration result and the decryption key for decrypting the encrypted additional information from the registrant terminal 3.
  • step S1010 for example, the acquisition unit 111 of the user terminal 1 receives the registration result and the decryption key from the registrant terminal 3.
  • FIG. 11 is a sequence showing a time series regarding data transmission / reception between the user terminal 1, the first distributed ledger network 4, the second distributed ledger network 5, and the storage service 8.
  • step S1101 the second distributed ledger control unit 115 of the user terminal 1 designates the token registered by the registrant terminal 3 in order to acquire additional information, and encrypts the second distributed ledger network 5. Request the additional information and the additional registration ID of the file registered in the storage service 8.
  • step S1102 the encrypted additional information metadata and the additional registration ID are returned from the second distributed ledger network 5 in response to the request from the user terminal 1.
  • step S1103 for example, the communication control unit 116 of the user terminal 1 requests the storage service 8 to acquire the encrypted additional information corresponding to the additional registration ID by using the additional registration ID.
  • step S1104 the storage service 8 searches the database for the encrypted additional information corresponding to the registration ID and transmits it to the user terminal 1.
  • step S1105 the user terminal 1 decodes the metadata of the encrypted additional information and the encrypted additional information by the decryption key acquired in step S1010 shown in FIG. After that, the user terminal 1 confirms the content of the decrypted additional information. The user may confirm whether or not the additional information added by the registrant terminal 3 has a problem.
  • step S1106 the second distributed ledger control unit 115 of the user terminal 1 generates a registration transaction including the confirmation result and broadcasts it to the second distributed ledger network 5 in order to register the confirmation result in step S1105.
  • step S1107 the second distributed ledger network 5 verifies the registration transaction by the consensus algorithm. If the registration transaction meets certain requirements, the registration transaction is included in the block. Here, assuming that the registration transaction meets a predetermined requirement, the registration transaction is approved by the second distributed ledger network 5.
  • step S1108 the second distributed ledger control unit 115 of the user terminal 1 receives the registration result of the registration transaction from the second distributed ledger network 5.
  • the additional information it is not necessary to register the encrypted additional information in the storage service 8 as in the case of the personal information described above.
  • the encrypted additional information may be registered in the storage service 8, and the token transaction may include the additional registration ID without including the metadata of the encrypted additional information.
  • the registration result received in step S1108 may be associated with the registration transaction of the DID registered in the first distributed ledger network 4 and the verification key. It may be left to the user's choice whether to manage the personal information and additional information associated with the DID in the first distributed ledger network 4 or the second distributed ledger network 5.
  • information such as DID with high commonality is managed by a decentralized distributed ledger network that does not require a specific administrator, and data for linking to DID or new information. Additional information is managed in a logical centralized distributed ledger network that requires a specific administrator to realize DApps. As a result, information with high commonality and information for a specific purpose can be appropriately handled. In addition, open information and closed information can be managed separately by the user's choice. The user can realize information control as to which information is disclosed to whom.
  • the basic mechanism for verification can be managed by a decentralized distributed ledger network. Even if a failure such as a program bug or intentional or accidental destruction by an administrator occurs in one DAPPs service (contract), it does not become a single point of failure, but it is used to verify the authenticity of other services. Does not affect. As a result, robust and flexible information management can be realized.
  • the instructions given in the processing procedure shown in the above-described embodiment can be executed by a computer based on a program that is software.
  • the present invention is not limited to the above embodiment as it is, and at the implementation stage, the components can be modified and embodied within a range that does not deviate from the gist thereof.
  • various inventions can be formed by an appropriate combination of the plurality of components disclosed in the above-described embodiment. For example, some components may be removed from all the components shown in the embodiments. In addition, components from different embodiments may be combined as appropriate.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

ロバストかつ柔軟な情報管理を実現できる。本実施形態に係る利用者端末は、第１分散台帳ネットワークと第２分散台帳ネットワークとに接続可能な利用者端末であって、生成部と、第１制御部と、第２制御部とを含む。生成部は、検証鍵を用いて、利用者に関する分散型識別子を生成する。第１制御部は、前記検証鍵と前記分散型識別子を含む登録トランザクションを生成し、前記登録トランザクションを前記第１分散台帳ネットワークに送信する。第２制御部は、前記利用者のデータと前記分散型識別子とを含む、トークンの発行に関するトークントランザクションを生成し、前記トークントランザクションを前記第２分散台帳ネットワークに送信する。

Description

利用者端末、認証者端末、登録者端末、管理システムおよびプログラム
　この発明は、分散台帳技術を利用した利用者端末、認証者端末、登録者端末、管理システムおよびプログラムに関する。
　ビットコイン（登録商標）に代表される暗号通貨の取引においては、非中央集権型の分散台帳技術の一種であるブロックチェーンが用いられている。ブロックチェーンは、改ざんに対して高い堅牢性を有するため、暗号通貨以外にも、種々の契約、取引を実行できるスマートコントラクトなど様々な用途への利用が検討されている。スマートコントラクトを扱うことができるプログラマブルなブロックチェーンとして、例えば、汎用的な分散型アプリケーションが実行できるイーサリアム（Ｅｔｈｅｒｅｕｍ）がある。
　様々なスマートコントラクトを実現可能な分散台帳技術は、トランザクションをブロックにまとめ、ブロック間をハッシュで連関させるデータ構造を持つため、データサイズが大きなファイルの管理には不向きである。
　分散型のファイル管理の方法として、コンテンツハッシュなどから作られるユニークな識別子（ＩＤ）でファイルを管理するストレージがある（例えば、非特許文献１参照）。また、当該ストレージにファイルを登録し、ファイルのＩＤを分散台帳に記録して管理する方法もある（例えば、非特許文献２参照）。
　また、ファイルのＩＤに加え、個人が作成した分散型識別子（ＤＩＤ：Decentralized ID）をイーサリアム上で管理する方法も検討されている。
Juan Banet、"IPFS - Content Addressed, Versioned, P2P File System (DRAFT 3)"、［online］、［令和２年２月２７日検索］、インターネット〈URL：https://ipfs.io/ipfs/QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf〉 Mathis Steichen, 他、"Blockchain-Based, Decentralized Access Control for IPFS"、［online］、［令和２年２月２７日検索］、インターネット〈URL：https://www.researchgate.net/publication/327034734_Blockchain-Based_Decentralized_Access_Control_for_IPFS〉
　ＤＩＤやファイル管理を分散台帳で行う場合、イーサリアムなどのプログラマブルなブロックチェーンに登録されるコントラクトによりＤＩＤとファイルメタデータとを管理し、外部ストレージや外部の分散ファイルストレージでファイルを管理することが想定される。つまり、ＤＩＤを管理するためのコントラクトには管理者が必要となる。
　しかし、管理者が必要となる管理構造は、単一障害点となり得る。特に、ファイルメタデータの管理とは異なり、ＤＩＤは共通性の高い情報であるため、特定の管理者に依存する管理構造は、ＤＩＤを管理する上では適切とはいえない。
　この発明は上記事情に着目してなされたもので、その目的とするところは、ロバストかつ柔軟な情報管理を実現できる利用者端末、認証者端末、登録者端末、管理システムおよびプログラムを提供することにある。
　上記目的を達成するために、この発明の一つの観点に係る利用者端末は、第１分散台帳ネットワークと第２分散台帳ネットワークとに接続可能な利用者端末であって、生成部と、第１制御部と、第２制御部とを含む。生成部は、検証鍵を用いて、利用者に関する分散型識別子を生成する。第１制御部は、前記検証鍵と前記分散型識別子を含む登録トランザクションを生成し、前記登録トランザクションを前記第１分散台帳ネットワークに送信する。第２制御部は、前記利用者のデータと前記分散型識別子とを含む、トークンの発行に関するトークントランザクションを生成し、前記トークントランザクションを前記第２分散台帳ネットワークに送信する。
　また、この発明の一つの観点に係る認証者端末は、利用者に関する分散型識別子と前記分散型識別子に紐付く検証鍵とが分散台帳で保持される第１分散台帳ネットワークと、前記利用者に関する暗号化されたデータを含むトークンが分散台帳で保持される第２分散台帳ネットワークとに接続可能な認証者端末であって、取得部と、第１制御部と、第２制御部と、復号部と、検証部とを含む。取得部は、前記分散型識別子と前記利用者に関する本人確認情報と復号鍵とを取得する。第１制御部は、前記第１分散台帳ネットワークを参照し、前記分散型識別子に紐付けられる前記検証鍵を抽出する。第２制御部は、前記第２分散台帳ネットワークを参照し、前記トークンへのアクセス情報を用いて、認証対象となる前記暗号化されたデータを抽出する。復号部は、前記復号鍵を用いて前記暗号化されたデータを復号する。検証部は、前記検証鍵を用いて前記トークンに付与された署名を検証し、前記本人確認情報を用いて復号されたデータを検証する。
　また、この発明の一つの観点に係る登録者端末は、利用者に関する分散型識別子と前記分散型識別子に紐付く検証鍵とが分散台帳で保持される第１分散台帳ネットワークと、前記利用者に関する暗号化されたデータを含むトークンが分散台帳で保持される第２分散台帳ネットワークとに接続可能な登録者端末であって、生成部と、暗号化部と、制御部と、送信部とを含む。生成部は、前記分散型識別子に新たに紐付く追加情報を生成する。暗号化部は、前記追加情報を暗号化する。制御部は、前記トークンに暗号化した追加情報を紐付けるための登録トランザクションを生成し、前記登録トランザクションを前記第２分散台帳ネットワークに送信する。送信部は、前記追加情報が紐付くトークンへのアクセス情報と、前記暗号化された追加情報を復号するための復号鍵とを送信する。
　また、この発明の一つの観点に係る管理システムは、第１分散台帳ネットワークと第２分散台帳ネットワークとにアクセス可能な、利用者端末および認証者端末を含む管理システムである。前記利用者端末は、生成部と、暗号化部と、第１制御部と、第２制御部とを含む。生成部は、検証鍵を用いて、利用者に関する分散型識別子を生成する。暗号化部は、前記利用者のデータを暗号化する。第１制御部は、前記検証鍵と前記分散型識別子を含む登録トランザクションを生成し、前記登録トランザクションを前記第１分散台帳ネットワークに送信する。第２制御部は、前記利用者の暗号化されたデータと前記分散型識別子とを含む、トークンの発行に関するトークントランザクションを生成し、前記トークントランザクションを前記第２分散台帳ネットワークに送信する。前記認証者端末は、取得部と、第１制御部と、第２制御部と、復号部と、検証部とを含む。取得部は、前記利用者端末から、前記分散型識別子と前記利用者に関する本人確認情報と復号鍵とを取得する。第１制御部は、前記第１分散台帳ネットワークを参照し、前記分散型識別子に紐付けられる前記検証鍵を抽出する。第２制御部は、前記第２分散台帳ネットワークを参照し、前記トークンへのアクセス情報を用いて、認証対象となる前記暗号化されたデータを抽出する。復号部は、前記復号鍵を用いて前記暗号化されたデータを復号する。検証部は、前記検証鍵を用いて前記トークンに付与された署名を検証し、前記本人確認情報を用いて復号されたデータを検証する。
　すなわちこの発明によれば、ロバストかつ柔軟な情報管理を実現できる。
図１は、本実施形態に係る管理システムの概念図である。 図２は、本実施形態に係る利用者端末を示すブロック図である。 図３は、本実施形態に係る認証者端末を示すブロック図である。 図４は、本実施形態に係る登録者端末を示すブロック図である。 図５は、本実施形態に係る管理システムのＤＩＤの登録処理の一例を示すシーケンス図である。 図６は、本実施形態に係る管理システムのＤＩＤの登録処理の一例を示すシーケンス図である。 図７は、本実施形態に係る管理システムのＤＩＤの認証処理の一例を示すシーケンス図である。 図８は、本実施形態に係る管理システムのＤＩＤの認証結果の記録処理の一例を示すシーケンス図である。 図９は、ＤＩＤに追加情報を登録する場合の管理システムでのＤＩＤの登録処理の一例を示すシーケンス図である。 図１０は、ＤＩＤに追加情報を登録する場合の管理システムでのＤＩＤの登録処理の一例を示すシーケンス図である。 図１１は、本実施形態に係る管理システムの追加情報の確認処理の一例を示すシーケンス図である。
　以下、図面を参照しながら本開示の一実施形態に係る利用者端末、認証者端末、登録者端末、管理システムおよびプログラムについて詳細に説明する。なお、以下の実施形態では、同一の番号を付した部分については同様の動作を行うものとして、重ねての説明を省略する。
　本実施形態に係る管理システムについて図１の概念図を参照して説明する。
　本実施形態に係る管理システム１０は、利用者端末１と、認証者端末２と、ストレージサービス８と、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５と、登録者端末３とを含む。
　利用者端末１は、分散型識別子（ＤＩＤ）を生成し、ＤＩＤと紐付けるデータ（紐付け用データともいう）を生成する端末である。紐付け用データは、本実施形態では、例えば本人を含む個人、組織または物に関するデータ、または当該データに付帯するメタデータを想定するが、ＤＩＤと紐付けて管理することに意味があるデータであればどのようなものでもよい。
　利用者端末１は、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５と、ストレージサービス８とに接続可能である。また、利用者端末１は、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５と、ストレージサービス８とにそれぞれ接続可能なアカウントおよびアカウントに紐付く署名鍵と対応する検証鍵とを管理する。なお、署名鍵は、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５と、ストレージサービス８とで共通の値を用いてもよいし、それぞれ異なる値を用いてもよい。署名鍵は、利用者端末１の格納部１２またはＳＩＭ（Subscriber Identity Module）などに保存されてもよいし、クラウドサーバ、専用デバイス、紙などの利用者端末１とは異なる保存場所で管理されてもよい。
　認証者端末２は、利用者端末１が生成したＤＩＤと、第２分散台帳ネットワーク５上に生成されたトークンとの紐付けを認証する端末である。本実施形態では、認証者端末２は、社会的立場を有する認証機関を想定するが、これに限らず、真正な認証を行う機関、組織または個人でもよい。認証者端末２は、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５と、ストレージサービス８とにアクセス可能である。認証者端末２も利用者端末１と同様に、第１分散台帳ネットワーク４および第２分散台帳ネットワーク５に接続可能なアカウントに紐付く署名鍵を管理する。
　登録者端末３は、利用者端末１が生成したＤＩＤと紐付けるための新たな情報（以下、追加情報という）を生成する端末である。登録者端末３も利用者端末１または認証者端末２と同様に、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５と、ストレージサービス８とにアクセス可能である。さらに、第１分散台帳ネットワーク４および第２分散台帳ネットワーク５に接続可能なアカウントに紐付く署名鍵を管理する。
　第１分散台帳ネットワーク４は、特定の管理者を必要としない非中央集権型の分散台帳技術を用いたネットワークである。第１分散台帳ネットワーク４は、ここではｋｅｙ－ｖａｌｕｅストア形式でデータを登録可能なＮａｍｅｃｏｉｎなどのブロックチェーンネットワークを想定するが、少なくとも２つの要素を関連づけて分散台帳で管理でき、トランザクションの検証、実行、台帳への登録の過程で、特定の管理者により後天的に登録された処理を含まない分散台帳技術であればよい。
　第２分散台帳ネットワーク５は、特定の管理者が必要となる、論理的な中央集権型の分散台帳技術を用いたネットワークである。第２分散台帳ネットワーク５は、ここではスマートコントラクトなどのブロックチェーンの応用に関する分散型アプリケーション（ＤＡｐｐｓ）を実現可能な、ＥＯＳ、イーサリアムなどのブロックチェーンネットワークを想定するが、トランザクションにより実行されるプログラムの登録や管理が特定の管理者により後天的に行われる分散台帳技術を用いたネットワークであればよい。
　ストレージサービス８は、利用者端末１から取得した本人情報などをファイルとして、データベースなどで管理するサービスである。ストレージサービス８は、ファイルを登録した場合、当該ファイルの登録識別子（登録ＩＤ）を発行する。登録ＩＤは、当該ファイルを一意に識別する識別子であり、ファイル識別子ともいう。ストレージサービス８は、サーバ（図示せず）がファイルを管理する中央集権型でもよいし、ＩＰＦＳ（InterPlanetary File System）やＳｗａｒｍなどの、ストレージサービス８の維持に関与する各端末が分散してＰ２Ｐ（Peer to Peer）ネットワークでファイルを管理する非中央集権型でもよい。
　なお、本実施形態では、第１分散台帳ネットワーク４と第２分散台帳ネットワーク５とは、異なる独立のネットワークを想定するが、基盤に先天的に備わった、特定の管理者を必要としないデータ処理の層と、後天的に特定の管理者により登録されたプログラムによるデータ処理の層とを区別して利用可能であれば、１つの分散台帳ネットワークで第１分散台帳ネットワーク４および第２分散台帳ネットワーク５を構成してもよい。
　なお、利用者端末１、認証者端末２および登録者端末３は、第１分散台帳ネットワーク４および第２分散台帳ネットワーク５に属し、それぞれのネットワークを維持するためのノード機能を有してもよい。ノード機能は、トランザクションの検証処理や承認処理、台帳情報（ブロック情報、ステートデータベースなど）の更新および保持を行なう機能である。
　なお、利用者端末１、認証者端末２および登録者端末３以外にも、ノード機能を代替する端末（別ノードという）が第１分散台帳ネットワーク４および第２分散台帳ネットワーク５に存在してもよい。図１の例では、第１分散台帳ネットワーク４を維持する別ノード６が存在してもよいし、第２分散台帳ネットワーク５を維持する別ノード７が存在してもよい。利用者端末１、認証者端末２および登録者端末３は、ノード機能を代替する別ノード６および別ノード７が存在する場合は、ノード機能を含まなくともよい。なお、本実施形態では、利用者端末１、認証者端末２および登録者端末３もノード機能を実行する場合について説明する。
　次に、本実施形態に係る利用者端末１について図２のブロック図を参照して説明する。
　利用者端末１は、処理回路１１と、格納部１２と、通信インタフェース１３とを含む。処理回路１１は、取得部１１１と、生成部１１２と、暗号化部１１３と、第１分散台帳制御部１１４と、第２分散台帳制御部１１５と、通信制御部１１６とを含む。
　取得部１１１は、ＤＩＤに紐付けるための本人情報およびストレージサービス８に登録するためのファイルを取得する。また、取得部１１１は、ストレージサービス８から登録ＩＤを取得する。
　生成部１１２は、ＤＩＤ用の署名鍵と署名鍵に対応する検証鍵とを生成する。生成部１１２は、検証鍵を用いて利用者に関するＤＩＤを生成する。また、生成部１１２は、ＤＩＤに紐付けるための、紐付け用データを生成してもよい。
　暗号化部１１３は、紐付け用データを暗号化する。暗号化の方式は、例えば、共通鍵を用いた共通鍵暗号方式を想定するが、セキュリティ強度が担保された暗号化方式であれば、どのような方式を用いてもよい。
　第１分散台帳制御部１１４は、ＤＩＤと検証鍵とを含む登録トランザクションを生成する。第１分散台帳制御部１１４は、登録トランザクションを第１分散台帳ネットワーク４に送信する。また、第１分散台帳制御部１１４は、第１分散台帳ネットワークを維持するためのノード機能を実行する。なお、ストレージサービス８に本人情報が登録される場合、第１分散台帳制御部１１４は、ストレージサービス８から発行された登録ＩＤを登録トランザクションに含める。
　第２分散台帳制御部１１５は、利用者のデータとＤＩＤとを含む署名対象メッセージと、当該署名対象メッセージに利用者の署名鍵でデジタル署名することで得られる署名値とを含む、トークンデータに関するトークントランザクションを生成する。トークンデータは、トークンの発行に関するデータである。第２分散台帳制御部１１５は、トークントランザクションを第２分散台帳ネットワーク５に送信する。第２分散台帳制御部１１５は、第１分散台帳制御部１１４と同様にノード機能を実行する。
　通信制御部１１６は、ストレージサービス８と、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５との間のデータ通信を制御する。特に、通信制御部１１６が、ストレージサービス８にデータを送信し、データに関する登録ＩＤを受信する処理を行う場合は、登録部とも呼ぶ。
　格納部１２は、第１分散台帳ネットワーク４および第２分散台帳ネットワーク５の台帳データ、トランザクション発行用の鍵ペア、紐付け証明用の鍵ペア、ファイル、自身が発行した登録トランザクションの識別子（登録トランザクションＩＤともいう）、トークンへのアクセス情報などを格納する。トークンへのアクセス情報は、トークンに格納された情報、またはトークン生成に使用されたトークントランザクションに格納された情報を参照するための情報であり、具体的には、例えば、トークントランザクションの識別子（トークントランザクションＩＤともいう）、コントラクトアドレス、アクセス用インタフェース情報、トークンに振るまたは振られるＩＤが挙げられる。
　通信インタフェース１３は、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５と、ストレージサービス８との間で、それぞれデータ通信するためのインタフェースである。通信インタフェース１３は、一般的に用いられている通信インタフェースを用いればよいため、ここでの説明は省略する。
　次に、本実施形態に係る認証者端末２について図３のブロック図を参照して説明する。
　認証者端末２は、処理回路２１と、格納部２２と、通信インタフェース２３とを含む。処理回路２１は、取得部２１１と、復号部２１２と、検証部２１３と、第１分散台帳制御部２１４と、第２分散台帳制御部２１５と、通信制御部２１６とを含む。
　取得部２１１は、利用者端末１からの認証依頼として、例えばＤＩＤと本人確認情報と復号鍵とを取得する。本人確認情報は、運転免許証、保険証、パスポートなどＤＩＤを利用するサービスから要求される、本人を証明するための書類から得られる情報であればよい。復号鍵は、暗号化された紐付け用データを復号するための鍵である。
　復号部２１２は、復号鍵を用いて暗号化された紐付け用データを復号する。
　検証部２１３は、検証鍵を用いてトークンに付与された署名を検証し、本人確認情報を用いて復号された紐付け用データを検証する。
　第１分散台帳制御部２１４は、第１分散台帳ネットワーク４を参照し、検証鍵を抽出する。
　第２分散台帳制御部２１５は、第２分散台帳ネットワーク５を参照し、トークンへのアクセス情報を用いて、認証対象となる暗号化された紐付け用データを抽出する。
　なお、第１分散台帳制御部２１４と第２分散台帳制御部２１５とはそれぞれ、登録者端末の第１分散台帳制御部１１４と第２分散台帳制御部１１５と同様のノード機能を実現する。
　通信制御部２１７は、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５と、ストレージサービス８との間のデータ通信を制御する。
　格納部２２は、第１分散台帳ネットワーク４および第２分散台帳ネットワーク５の台帳データ、トランザクション発行用の鍵ペア、トークンへのアクセス情報、または必要に応じて登録トランザクションＩＤなどを格納する。
　通信インタフェース２３は、利用者端末１の通信インタフェース１３とほぼ同様の処理を行う。
　次に、本実施形態に係る登録者端末３について図４のブロック図を参照して説明する。
　登録者端末３は、処理回路３１と、格納部３２と、通信インタフェース３３とを含む。処理回路３１は、取得部３１１と、復号部３１２と、情報生成部３１３と、暗号化部３１４と、検証部３１５と、第１分散台帳制御部３１６と、第２分散台帳制御部３１７と、通信制御部３１８とを含む。
　取得部３１１は、利用者端末１から、ＤＩＤ、復号鍵、本人確認情報およびトークンへのアクセス情報などを受け取る。
　復号部３１２は、復号部２１２と同様に、復号鍵を用いて暗号化された紐付け用データを復号する。
　情報生成部３１３は、紐付け用データとは別にＤＩＤに新たに紐づける、追加情報を生成する。
　暗号化部３１４は、追加情報を暗号化する。暗号化方式は、暗号化部１１３と同様の方式を用いればよい。
　検証部３１５は、検証部２１３と同様に、検証鍵を用いてトークンに付与された署名を検証し、本人確認情報を用いて復号された紐付け用データを検証する。
　第１分散台帳制御部３１６は、第１分散台帳ネットワーク４を参照し、ＤＩＤに紐付けられた検証鍵とを抽出する。
　第２分散台帳制御部３１７は、第２分散台帳ネットワーク５を参照し、トークンへのアクセス情報を用いて、認証対象となる暗号化された紐付け用データを抽出する。
　なお、第１分散台帳制御部３１６と第２分散台帳制御部３１７とはそれぞれ、登録者端末の第１分散台帳制御部１１４と第２分散台帳制御部１１５と同様のノード機能を実現する。
　通信制御部３１８は、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５と、ストレージサービス８との間のデータ通信を制御する。
　格納部３２は、第１分散台帳ネットワーク４および第２分散台帳ネットワーク５の台帳データ、トランザクション発行用の鍵ペア、トークンへのアクセス情報などを格納する。
　通信インタフェース３３は、利用者端末１の通信インタフェース１３とほぼ同様の処理を行う。
　なお、利用者端末１の処理回路１１、認証者端末２の処理回路２１および登録者端末３の処理回路３１はそれぞれ、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）などのプロセッサ、または、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）などの集積回路で構成される。上述した処理回路１１および処理回路２１の各部は、プロセッサまたは集積回路が処理プログラムを実行することで、プロセッサまたは集積回路の一機能として実現されてもよい。
　また、利用者端末１の格納部１２、認証者端末２の格納部２２および登録者端末３の格納部３２はそれぞれ、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリなどの一般的に用いられる記憶媒体で構成される。
　次に、本実施形態に係る管理システム１０でのＤＩＤの登録処理について図５および図６のシーケンス図を参照して説明する。
　図５は、利用者端末１と、第１分散台帳ネットワーク４との間のデータ送受信に関する時系列を示すシーケンスである。なお、以下の図５から図１１までのシーケンス図でも同様であるが、図示されない端末（利用者端末１、認証者端末２および登録者端末３）も、第１分散台帳ネットワーク４および第２分散台帳ネットワーク５の維持のためにノードとして参加してもよい。図５の例では、認証者端末２および登録者端末３がノードとして第１分散台帳ネットワーク４におけるトランザクションの検証および承認を実行してもよい。
　ステップＳ５０１では、利用者端末１の生成部１１２が、ＤＩＤ用の署名鍵と署名鍵に対応する検証鍵を生成する。
　ステップＳ５０２では、利用者端末１の生成部１１２が、検証鍵を用いてＤＩＤを作成する。例えば、検証鍵のハッシュ値をＤＩＤとすればよい。なお、検証鍵のハッシュ値のハッシュ値、つまりダブルハッシュをＤＩＤとしてもよく、値の衝突が発生しないような一意に識別可能な値であれば、どのような値をＤＩＤとしてもよい。
　ステップＳ５０３では、利用者端末１の第１分散台帳制御部１１４が、ＤＩＤと検証鍵とを含む登録トランザクションを生成する。第１分散台帳制御部１１４は、登録トランザクションを有効なトランザクションとするため、登録トランザクションに対して第１分散台帳ネットワーク４を利用するために生成された署名鍵でデジタル署名を行ない、デジタル署名された登録トランザクションを第１分散台帳ネットワーク４にブロードキャストする。
　ステップＳ５０４では、第１分散台帳ネットワーク４においてノード機能を有する複数の端末が、コンセンサスアルゴリズムにより、登録トランザクションを検証する。当該登録トランザクションが所定の要件を満たしていれば、登録トランザクションがブロックに取り込まれる。ここでは登録トランザクションが所定の要件を満たすとして、第１分散台帳ネットワーク４により登録トランザクションが承認（confirm）される。
　ステップＳ５０５では、利用者端末１の第１分散台帳制御部１１４が、第１分散台帳ネットワーク４から登録トランザクションの登録結果を受信する。登録結果は、例えば、登録トランザクションと承認結果（True or Falseまたはステータスコード）、登録トランザクションがブロックに登録された場合、そのブロック番号である。
　ステップＳ５０６では、例えば利用者端末１の通信制御部１１６が、利用者端末１の利用者に対してＤＩＤの作成の完了通知を行う。通知方法としては、画面に作成完了の旨を表示する、音声や音で通知するなどどのような方法でもよい。
　次に図６は、利用者端末１と、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５と、ストレージサービス８との間のデータ送受信に関する時系列を示すシーケンスである。
　なお、以下に示す図６から図９までの例では、紐付け用データとして、例えば利用者の個人情報などの本人情報を想定する。また、暗号化された本人情報のメタデータがトークンに含まれ、暗号化された本人情報自体（またはトークンに含まれる本人情報の残りのデータ）がファイルとしてストレージサービス８に登録される場合を想定する。
　ステップＳ６０１では、利用者端末１の生成部１１２が、本人情報を作成する。ここでは、本人情報と本人情報のメタデータとを作成する。
　ステップＳ６０２では、利用者端末１の暗号化部１１３が、ステップＳ６０１で作成した本人情報と本人情報のメタデータとを共通鍵で暗号化する。
　ステップＳ６０３では、利用者端末１の通信制御部１１６が、通信インタフェース１３を介して暗号化された本人情報をストレージサービス８に送信する。
　ステップＳ６０４では、ストレージサービス８が、暗号化された本人情報を登録し、管理が開始される。
　ステップＳ６０５では、ストレージサービス８が、登録した本人情報に対するＩＤ（以下、登録ＩＤという）を発行する。登録ＩＤは、例えば、フィンガープリントのようなファイルのハッシュ値から作られる文字列でもよいし、ハッシュ値から作られる文字列に加えて、サービス提供者を示すフレーズを含めたＩＤでもよい。または、ＵＲＩ（Uniform Resource Identifier）のような識別子であってもよい。すなわち、登録した本人情報を一意に識別可能な識別子が発行されればよい。利用者端末１の通信制御部１１６が、登録ＩＤを受信することで、ストレージサービス８への本人情報の登録処理が完了する。
　ステップＳ６０６では、ＤＩＤ（またはＤＩＤのハッシュ値）、暗号化された本人情報のメタデータおよび登録ＩＤを含むトークン発行に関する署名対象メッセージと、署名対象メッセージを署名鍵でデジタル署名した署名値とを含むトークントランザクションを生成する。利用者端末１の第２分散台帳制御部１１５は、トークントランザクションを有効なトランザクションとするため、トークントランザクションに対して第２分散台帳ネットワーク５を利用するために生成された署名鍵によりデジタル署名を行ない、デジタル署名されたトークントランザクションを第２分散台帳ネットワーク５にブロードキャストする。
　ステップＳ６０７では、第２分散台帳ネットワーク５が、コンセンサスアルゴリズムにより、トークントランザクションを検証する。当該トークントランザクションが所定の要件を満たしていれば、トークントランザクションがブロックに取り込まれる。ここではトークントランザクションが所定の要件を満たすと仮定して、第２分散台帳ネットワーク５によりトークントランザクションが承認される。
　ステップＳ６０８では、例えば利用者端末１の第２分散台帳制御部１１５が、第２分散台帳ネットワーク５からトークントランザクションの登録結果を受信する。登録結果は、例えばトークントランザクションと承認結果（True or Falseまたはステータスコード）、トークントランザクションがブロックに登録された場合、そのブロック番号である。
　ステップＳ６０９では、すでに第１分散台帳ネットワーク４上で承認されているＤＩＤに対して、第２分散台帳ネットワーク５上で承認されたトークンの情報を紐付ける。具体的には、利用者端末１の第１分散台帳制御部１１４が、ＤＩＤとトークンの識別情報とを含む登録トランザクションを生成する。トークンの識別情報は、言い換えればトークンへのアクセス情報であり、トークントランザクションに付与されたトランザクションＩＤやトークントランザクションが取り込まれたブロック番号があげられる。また、トークンの識別情報として、ユニークなＩＤを新たに生成してもよい。例えば、「Ｔｏｋｅｎ：コントラクトＩＤ：トークン識別子」のように、コロン「：」でコントラクトＩＤおよびトークン識別子を区切って接続することで生成されたユニークなＩＤをトークンへの識別情報として用いればよい。第１分散台帳制御部１１４は、登録トランザクションを有効なトランザクションとするため、登録トランザクションに対して第１分散台帳ネットワーク４を利用するために生成された署名鍵でデジタル署名を行ない、デジタル署名された登録トランザクションを第１分散台帳ネットワーク４にブロードキャストする。
　ステップＳ６１０では、第１分散台帳ネットワーク４においてノード機能を有する複数の端末が、コンセンサスアルゴリズムにより、登録トランザクションを検証する。当該登録トランザクションが所定の要件を満たしていれば、登録トランザクションがブロックに取り込まれる。ここでは登録トランザクションが所定の要件を満たすとして、第１分散台帳ネットワーク４により登録トランザクションが承認（confirm）される。
　ステップＳ６１１では、利用者端末１の第１分散台帳制御部１１４が、第１分散台帳ネットワーク４から登録トランザクションの登録結果を受信する。登録結果は、例えば、登録トランザクションと承認結果（True or Falseまたはステータスコード）、登録トランザクションがブロックに登録された場合、そのブロック番号である。
　ステップＳ６１２では、例えば利用者端末１の通信制御部１１６が、利用者に対して、暗号化された本人情報とＤＩＤとの紐付けの完了通知を行う。
　なお、図６の例では、ストレージサービス８に暗号化された本人情報を登録する例を示すが、ストレージサービス８に暗号化された本人情報を登録しなくともよい。この場合は、トークントランザクションに、ＤＩＤと暗号化された本人情報とを含む署名対象メッセージと署名値とを含めばよいため、図６に示すステップＳ６０３からステップＳ６０５までの処理は省略される。
　また、ストレージサービス８に暗号化された本人情報を登録し、トークントランザクションには暗号化された本人情報のメタデータを含まずに登録ＩＤを含む場合であってもよい。この場合は、ステップＳ６０６において、ＤＩＤと登録ＩＤとを含む署名対象メッセージと署名値とを含むトークントランザクションが生成される。
　次に、本実施形態に係る管理システム１０のＤＩＤの認証処理について図７を参照して説明する。
　図７は、利用者端末１と、認証者端末２と、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５と、ストレージサービス８との間のデータ送受信に関する時系列を示すシーケンスである。
　図７では、説明の便宜上、シーケンスにおける「要求」および「返却」は、第１分散台帳ネットワーク４および第２分散台帳ネットワーク５にアクセスしているように図示するが、第１分散台帳ネットワーク４および第２分散台帳ネットワーク５に直接アクセスせずに、認証者端末２の内部処理で実現することもできる。これは、各端末（利用者端末１、認証者端末２および登録者端末３）がノードとして第１分散台帳ネットワーク４および第２分散台帳ネットワーク５に参加している場合は、端末自身が分散台帳ネットワークの一部を担うからである。つまり、各端末が保持する分散台帳を参照することで、検証者の要求に合致するトランザクションおよび各種データなどを抽出すればよい。
　ステップＳ７０１では、利用者端末１から、認証者端末２に対して認証依頼を通知する。認証依頼は、例えば、利用者のＤＩＤと、復号鍵と、本人確認情報と、トークンへのアクセス情報とを、例えばメールやメッセージアプリケーションで通知すればよい。復号鍵は、暗号化された本人情報のメタデータと、ストレージサービス８に登録された暗号化された本人情報とを復号するための鍵である。なお、第２分散台帳ネットワーク５で保持されるトークンにＤＩＤが含まれている場合は、認証依頼として通知すべき情報に、利用者のＤＩＤを含めなくてもよい。
　ステップＳ７０２では、認証者端末２の第２分散台帳制御部２１５が、トークンのアクセス情報を検索キーとするなどにより認証対象のトークンを指定して、第２分散台帳ネットワーク５に対し、ＤＩＤ、暗号化された本人情報のメタデータおよび登録ＩＤを含む署名対象メッセージとその署名値とを要求する。なお、具体的には、例えば対応するトークンのＡＰＩまたはトークントランザクションを用いて、必要な情報を要求すればよい。
　ステップＳ７０３では、第２分散台帳ネットワーク５から、認証者端末２からの要求に応じて、ＤＩＤ、暗号化された本人情報のメタデータおよび登録ＩＤを含む署名対象メッセージと、その署名値とが返却される。なお、ステップ７０２およびステップＳ７０３の処理は、認証者端末２の第２分散台帳制御部２１５が、第２分散台帳ネットワーク５を参照して、ＤＩＤと、暗号化された本人情報のメタデータと、登録ＩＤと、署名値とを抽出する処理として実行されてもよい。
　ステップＳ７０４では、認証者端末２の第１分散台帳制御部２１４が、第１分散台帳ネットワーク４に対し、抽出したＤＩＤと同一のＤＩＤに紐付けられる検証鍵を要求する。
　ステップＳ７０５では、第１分散台帳ネットワーク４が、認証者端末２からの要求に応じて、ＤＩＤに対応する検証鍵を返却する。なお、ステップ７０４およびステップＳ７０５の処理は、認証者端末２の第１分散台帳制御部２１４が、第１分散台帳ネットワーク４を参照してＤＩＤおよび署名値を抽出する処理として実行されてもよい。また、例えばＢｉｔｃｏｉｎ　Ｃｏｒｅで第１分散台帳ネットワーク４を実現する場合、台帳から登録トランザクションＩＤと一致する登録トランザクションを検索して、登録トランザクションからＤＩＤに紐付く検証鍵を取得すればよい。
　ステップＳ７０６では、認証者端末２の検証部２１３が、検証鍵で署名値を検証する。検証鍵による署名値の検証は、一般的なデジタル署名における検証方法を用いればよい。検証によって署名値が真正であると判定された場合は、利用者が第２分散台帳ネットワーク５に送信した真正なトークンであると判定でき、署名値が真正でないと判定された場合は、不正なトークンであると判定できる。
　ステップＳ７０７では、認証者端末２の通信制御部２１６が、登録ＩＤを指定してストレージサービス８に対して暗号化された本人情報を要求する。
　ステップＳ７０８では、ストレージサービス８が、登録ＩＤに対応する暗号化された本人情報をデータベースから検索し、認証者端末２に送信する。
　ステップＳ７０９では、認証者端末２の復号部２１２が、暗号化された本人情報のメタデータおよび暗号化された本人情報を、ステップＳ７０１で取得した復号鍵により復号する。
　ステップＳ７１０では、認証者端末２の検証部２１４が、復号された本人情報と本人確認書類との整合性を検証する。復号された本人情報と本人確認書類に開示される内容とが同一であれば、本人情報が真正であると判定できる。一方、復号された本人情報と本人確認書類に開示される内容とが同一でなければ、本人情報または本人確認書類のどちらかが不正な可能性があると判定できる。
　なお、ストレージサービス８に暗号化された本人情報を登録しない場合は、トークントランザクションに暗号化された本人情報が含まれ、ステップＳ７０３において暗号化された本人情報が返却されるため、ステップＳ７０７およびステップＳ７０８を省略し、ステップＳ７０９において当該暗号化された本人情報を復号すればよい。
　一方、ストレージサービス８に暗号化された本人情報を登録し、トークントランザクションには登録ＩＤのみを含む場合は、ステップＳ７０３において抽出した登録ＩＤに基づき、ステップＳ７０８においてストレージサービス８から暗号化された本人情報が認証者端末２に返却されるので、ステップＳ７０９において当該暗号化された本人情報を復号すればよい。
　また、認証者端末２は、第１分散台帳ネットワーク４において、利用者端末１から直接または間接的に登録トランザクションＩＤの共有を受け、共有された登録トランザクションＩＤを格納部２２に保存してもよい。第２分散台帳制御部２１５は、ステップＳ７０４において、格納部２２に保存された共有された登録トランザクションＩＤを参照することで、効率的に検証鍵の抽出が実行できる。例えば、ビットコインの分散台帳ネットワークを第１分散台帳ネットワーク４として活用する場合、登録トランザクションＩＤが共有されていれば、検証鍵を抽出する際に有益である。
　次に、本実施形態に係る管理システム１０のＤＩＤの認証結果の記録処理について図８のシーケンス図を参照して説明する。
　図８は、利用者端末１と、認証者端末２と、第２分散台帳ネットワーク５との間のデータ送受信に関する時系列を示すシーケンスである。
　ステップＳ８０１では、認証者端末２の第２分散台帳制御部２１５が、検証結果を記録するための登録トランザクションを生成する。生成される登録トランザクションは、認証者のＩＤ、認証した日付、どのような方法で本人情報を確認したかを示す確認手段などを含むトランザクションを想定するが、確認した本人情報の種類などその他の情報を含めたトランザクションとしてもよい。
　認証者端末２の第２分散台帳制御部２１５は、生成した登録トランザクションに対して第２分散台帳ネットワーク５を利用するために生成された署名鍵でデジタル署名を行い、デジタル署名された登録トランザクションを第２分散台帳ネットワーク５にブロードキャストする。
　ステップＳ８０２では、第２分散台帳ネットワーク５が、コンセンサスアルゴリズムにより、登録トランザクションを検証する。当該登録トランザクションが所定の要件を満たしていれば、登録トランザクションがブロックに取り込まれる。ここでは登録トランザクションが所定の要件を満たすと仮定して、第２分散台帳ネットワーク５により登録トランザクションが承認される。
　ステップＳ８０３では、認証者端末２の第２分散台帳制御部２１５が、第２分散台帳ネットワーク５から登録トランザクションの登録結果を受信する。登録結果は、例えば登録トランザクションと承認結果（True or Falseまたはステータスコード）、登録トランザクションがブロックに登録された場合、そのブロック番号である。
　ステップＳ８０４では、例えば利用者端末１の取得部１１１が、認証者端末２から登録結果を受信する。これにより、利用者端末１の利用者は、自身がＤＩＤに紐づけた情報が正しい情報であるとして認証され、第１分散台帳ネットワーク４および第２分散台帳ネットワーク５に登録されたことを確認できる。
　次に、ＤＩＤに追加情報を登録する場合の管理システム１０でのＤＩＤの登録処理について図９および図１０を参照して説明する。
　図９は、利用者端末１と、登録者端末３と、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５と、ストレージサービス８との間のデータ送受信に関する時系列を示すシーケンスである。
　ステップＳ９０１では、利用者端末１が登録者端末３に情報を通知する。具体的には、登録者端末３の取得部３１１が、ＤＩＤ、復号鍵、本人確認情報およびトークンへのアクセス情報を取得する。
　ステップＳ７０２からステップＳ７０９までの処理は、登録者端末３が、図７に示す認証者端末２の処理を同様に実行すればよいため、ここでの説明は省略する。
　ステップＳ９０２では、復号された本人情報が認証者端末２により認証済みであるか否かを確認する。ステップＳ７０６において、検証鍵によりトークンから取得した署名が真正であることを検証でき、さらに、当該ステップＳ９０１においてトークンがＤＩＤの認証者により認証を受けていること、および、本人情報を復号して、登録する情報を紐づけようとしている本人情報が正しいことを確認できればよい。
　なお、ステップＳ９０１において、利用者端末１からＤＩＤの持ち主であることを証明する署名を登録者端末３に通知してもよい。例えば、利用者端末１から通知されるＤＩＤ、復号鍵およびトークンへのアクセス情報に対してデジタル署名を付与してもよい。この場合ステップＳ９０２において、登録者端末３が、通知されたデジタル署名を例えばステップＳ７０６と同様の方法で検証し、利用者端末１がＤＩＤの持ち主であることを確認してもよい。
　次に図１０は、利用者端末１と、登録者端末３と、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５と、ストレージサービス８との間のデータ送受信に関する時系列を示すシーケンスである。
　なお、図１０および図１１では、暗号化された追加情報のメタデータがトークンに含まれ、暗号化された追加情報自体（またはトークンに含まれる追加情報の残りのデータ）がファイルとしてストレージサービス８に登録される場合を想定する。
　ステップＳ１００１では、登録者端末３の情報生成部３１３が、ＤＩＤに紐づける追加情報を生成する。
　ステップＳ１００２では、登録者端末３の暗号化部３１４が、追加情報を暗号化する。暗号化方式については、ステップＳ６０２と同様であればよい。
　ステップＳ１００３では、登録者端末３の通信制御部３１８が、通信インタフェース３３を介して暗号化された追加情報をストレージサービス８に送信する。
　ステップＳ１００４では、ストレージサービス８が、暗号化された追加情報を登録する。
　ステップＳ１００５では、ストレージサービス８が、登録した追加情報に対するＩＤ（以下、追加登録ＩＤという）を発行する。追加登録ＩＤは、登録ＩＤと同様な形式を想定する。
　ステップＳ１００６では、登録者端末３が、暗号化した追加情報と、追加登録ＩＤとを、第２分散台帳ネットワーク５上のトークンに登録する。例えば、登録者端末３は、暗号化された追加情報または追加登録ＩＤを含む追加情報メタデータを、利用者端末１から提示されたトークンに登録する。
　または、新規にトークンを作成するため、暗号化した追加情報と追加登録ＩＤとを含む新規のトークントランザクションを生成し、当該トークントランザクションをブロードキャストする。ここでは、新規のトークントランザクションを生成した場合を想定する。
　ステップＳ１００７では、新規のトークントランザクションが生成された場合、第２分散台帳ネットワーク５が、コンセンサスアルゴリズムにより、トークントランザクションを検証する。ここでは、第２分散台帳ネットワーク５によりトランザクションが承認される場合を想定する。
　ステップＳ１００８では、登録者端末３の第２分散台帳制御部３１７が、第２分散台帳ネットワーク５からトークントランザクションの登録結果を受信する。
　ステップＳ１００９では、例えば登録者端末３の通信制御部３１８が、登録者端末３から登録結果と暗号化した追加情報を復号するための復号鍵とを送信する。
　ステップＳ１０１０では、例えば利用者端末１の取得部１１１が、登録者端末３から登録結果と復号鍵とを受信する。
　次に、管理システム１０による追加情報の確認処理について、図１１のシーケンス図を参照して説明する。
　図１１は、利用者端末１と、第１分散台帳ネットワーク４と、第２分散台帳ネットワーク５およびストレージサービス８との間のデータ送受信に関する時系列を示すシーケンスである。
　ステップＳ１１０１では、利用者端末１の第２分散台帳制御部１１５は、追加情報を取得するべく、登録者端末３により登録されたトークンを指定して、第２分散台帳ネットワーク５に対し、暗号化された追加情報とストレージサービス８に登録されたファイルの追加登録ＩＤとを要求する。
　ステップＳ１１０２では、第２分散台帳ネットワーク５から、利用者端末１からの要求に応じて、暗号化された追加情報のメタデータと追加登録ＩＤとが返却される。
　ステップＳ１１０３では、例えば利用者端末１の通信制御部１１６が、追加登録ＩＤを用いて、ストレージサービス８に追加登録ＩＤに対応する暗号化された追加情報の取得依頼を要求する。
　ステップＳ１１０４では、ストレージサービス８が、登録ＩＤに対応する暗号化された追加情報をデータベースから検索し、利用者端末１に送信する。
　ステップＳ１１０５では、利用者端末１が、暗号化された追加情報のメタデータおよび暗号化された追加情報を、図１０に示すステップＳ１０１０で取得した復号鍵により復号する。その後利用者端末１が、復号された追加情報の内容を確認する。追加内容の確認は、利用者が登録者端末３により追加された追加情報が問題があるか否かを確認すればよい。
　ステップＳ１１０６では、利用者端末１の第２分散台帳制御部１１５が、ステップＳ１１０５における確認結果を登録するため、確認結果を含む登録トランザクションを生成し、第２分散台帳ネットワーク５にブロードキャストする。
　ステップＳ１１０７では、第２分散台帳ネットワーク５が、コンセンサスアルゴリズムにより、登録トランザクションを検証する。当該登録トランザクションが所定の要件を満たしていれば、登録トランザクションがブロックに取り込まれる。ここでは登録トランザクションが所定の要件を満たすと仮定して、第２分散台帳ネットワーク５により登録トランザクションが承認される。
　ステップＳ１１０８では、利用者端末１の第２分散台帳制御部１１５が、第２分散台帳ネットワーク５から登録トランザクションの登録結果を受信する。
　なお、追加情報についても、上述した本人情報の場合と同様に、ストレージサービス８に暗号化された追加情報を登録しなくてもよい。または、ストレージサービス８に暗号化された追加情報を登録し、トークントランザクションには、暗号化された追加情報のメタデータを含まず追加登録ＩＤを含む場合であってもよい。
　また、ステップＳ１１０８で受信した登録結果を、第１分散台帳ネットワーク４に登録したＤＩＤと検証鍵との登録トランザクションに紐付けてもよい。
　ＤＩＤに紐付く本人情報および追加情報に関して、第１分散台帳ネットワーク４で管理するか、第２分散台帳ネットワーク５で管理するかを利用者の選択に委ねてもよい。
　以上に示した実施形態によれば、共通性の高いＤＩＤなどの情報を、特定の管理者を必要としない非中央集権型の分散台帳ネットワークで管理し、ＤＩＤに紐付ける紐付け用データまたは新たな情報である追加情報を、ＤＡｐｐｓが実現される特定の管理者が必要となる論理的な中央集権型の分散台帳ネットワークで管理する。
　これにより、共通性の高い情報と、特定用途の情報とを適切に扱うことができる。また、利用者の選択により、オープンな情報とクローズな情報とを区別して管理することできる。利用者は、どの情報を誰に開示するかという情報のコントロールが実現できる。
　また、ＤＩＤを利用する様々なポリシーを有するＤＡｐｐｓが増加したり、ＤＡｐｐｓのポリシーに変更がある場合でも、検証のための基本的な仕組みを非中央集権型の分散台帳ネットワークで管理することで、１つのＤＡｐｐｓによるサービス（コントラクト）にプログラムバグや管理者による意図的なまたは偶発的な破壊などの障害が発生しても、単一障害点とならずに、他のサービスの真正性の検証に影響を及ぼさない。結果として、ロバストかつ柔軟な情報管理を実現できる。
　上述の実施形態の中で示した処理手順に示された指示は、ソフトウェアであるプログラムに基づいてコンピュータで実行されることが可能である。
　要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
１０…管理システム
１…利用者端末
２…認証者端末
３…登録者端末
４…第１分散台帳ネットワーク
５…第２分散台帳ネットワーク
６，７…別ノード
８…ストレージサービス
１１，２１，３１…処理回路
１２，２２，３２…格納部
１３，２３，３３…通信インタフェース
１１１，２１１，３１１…取得部
１１２…生成部
１１３，３１４…暗号化部
１１４，２１４，３１６…第１分散台帳制御部
１１５，２１５，３１７…第２分散台帳制御部
１１６，２１６，３１８…通信制御部
２１２，３１２…復号部
２１３，３１５…検証部
３１３…情報生成部

Claims (10)

  1. 　第１分散台帳ネットワークと第２分散台帳ネットワークとに接続可能な利用者端末であって、
    　検証鍵を用いて、利用者に関する分散型識別子を生成する生成部と、
    　前記検証鍵と前記分散型識別子を含む登録トランザクションを生成し、前記登録トランザクションを前記第１分散台帳ネットワークに送信する第１制御部と、
    　前記利用者のデータと前記分散型識別子とを含む、トークンの発行に関するトークントランザクションを生成し、前記トークントランザクションを前記第２分散台帳ネットワークに送信する第２制御部と、
    　を具備する利用者端末。
  2. 　前記データをストレージサービスに登録し、前記ストレージサービスから前記データを管理するために発行された登録識別子を受信する登録部をさらに具備し、
    　前記第１制御部は、前記登録識別子をさらに含む登録トランザクションを生成する、請求項１に記載の利用者端末。
  3. 　利用者に関する分散型識別子と前記分散型識別子に紐付く検証鍵とが分散台帳で保持される第１分散台帳ネットワークと、前記利用者に関する暗号化されたデータを含むトークンが分散台帳で保持される第２分散台帳ネットワークとに接続可能な認証者端末であって、
    　前記分散型識別子と前記利用者に関する本人確認情報と復号鍵とを取得する取得部と、
    　前記第１分散台帳ネットワークを参照し、前記分散型識別子に紐付けられる前記検証鍵を抽出する第１制御部と、
    　前記第２分散台帳ネットワークを参照し、前記トークンへのアクセス情報を用いて、認証対象となる前記暗号化されたデータを抽出する第２制御部と、
    　前記復号鍵を用いて前記暗号化されたデータを復号する復号部と、
    　前記検証鍵を用いて前記トークンに付与された署名を検証し、前記本人確認情報を用いて復号されたデータを検証する検証部と、
    　を具備する認証者端末。
  4. 　前記第２制御部は、認証者の識別子と前記検証部の検証結果とを含む登録トランザクションを生成し、前記登録トランザクションを前記第２分散台帳ネットワークに送信する、請求項３に記載の認証者端末。
  5. 　利用者に関する分散型識別子と前記分散型識別子に紐付く検証鍵とが分散台帳で保持される第１分散台帳ネットワークと、前記利用者に関する暗号化されたデータを含むトークンが分散台帳で保持される第２分散台帳ネットワークとに接続可能な登録者端末であって、
    　前記分散型識別子に新たに紐付く追加情報を生成する生成部と、
    　前記追加情報を暗号化する暗号化部と、
    　前記トークンに暗号化した追加情報を紐付けるための登録トランザクションを生成し、前記登録トランザクションを前記第２分散台帳ネットワークに送信する制御部と、
    　前記追加情報が紐付くトークンへのアクセス情報と、前記暗号化された追加情報を復号するための復号鍵とを送信する送信部と、
    　を具備する登録者端末。
  6. 　前記第１分散台帳ネットワークは、特定の管理者を必要としない非中央集権型のブロックチェーンネットワークであり、
    　前記第２分散台帳ネットワークは、特定の管理者が必要となる、論理的な中央集権型のブロックチェーンネットワークである、請求項１に記載の利用者端末、または請求項３に記載の認証者端末、または請求項５に記載の登録者端末。
  7. 　第１分散台帳ネットワークと第２分散台帳ネットワークとにアクセス可能な、利用者端末および認証者端末を含む管理システムであって、
    　前記利用者端末は、
    　　検証鍵を用いて、利用者に関する分散型識別子を生成する生成部と、
    　　前記利用者のデータを暗号化する暗号化部と、
    　　前記検証鍵と前記分散型識別子を含む登録トランザクションを生成し、前記登録トランザクションを前記第１分散台帳ネットワークに送信する第１制御部と、
    　　前記利用者の暗号化されたデータと前記分散型識別子とを含む、トークンの発行に関するトークントランザクションを生成し、前記トークントランザクションを前記第２分散台帳ネットワークに送信する第２制御部と、を具備し、
    　前記認証者端末は、
    　　前記利用者端末から、前記分散型識別子と前記利用者に関する本人確認情報と復号鍵とを取得する取得部と、
    　　前記第１分散台帳ネットワークを参照し、前記分散型識別子に紐付けられる前記検証鍵を抽出する第１制御部と、
    　　前記第２分散台帳ネットワークを参照し、前記トークンへのアクセス情報を用いて、認証対象となる前記暗号化されたデータを抽出する第２制御部と、
    　　前記復号鍵を用いて前記暗号化されたデータを復号する復号部と、
    　　前記検証鍵を用いて前記トークンに付与された署名を検証し、前記本人確認情報を用いて復号されたデータを検証する検証部と、
    　を具備する、管理システム。
  8. 　コンピュータを、請求項１または請求項２に記載の利用者端末の各部として実行させるためのプログラム。
  9. 　コンピュータを、請求項３または請求項４に記載の認証者端末の各部として実行させるためのプログラム。
  10. 　コンピュータを、請求項５に記載の登録者端末の各部として実行させるためのプログラム。
     
     
PCT/JP2021/025001 2020-07-01 2021-07-01 利用者端末、認証者端末、登録者端末、管理システムおよびプログラム WO2022004854A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/010,313 US20230232222A1 (en) 2020-07-01 2021-07-01 User terminal, authentication terminal, registration terminal, management system and program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020-113934 2020-07-01
JP2020113934A JP7462903B2 (ja) 2020-07-01 2020-07-01 利用者端末、認証者端末、登録者端末、管理システムおよびプログラム

Publications (1)

Publication Number Publication Date
WO2022004854A1 true WO2022004854A1 (ja) 2022-01-06

Family

ID=79316396

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/025001 WO2022004854A1 (ja) 2020-07-01 2021-07-01 利用者端末、認証者端末、登録者端末、管理システムおよびプログラム

Country Status (3)

Country Link
US (1) US20230232222A1 (ja)
JP (1) JP7462903B2 (ja)
WO (1) WO2022004854A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024150529A1 (ja) * 2023-01-12 2024-07-18 富士通株式会社 プログラム、情報処理方法および情報処理装置

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112468301B (zh) * 2020-10-23 2022-08-02 苏州浪潮智能科技有限公司 一种基于区块链的云平台认证的方法、系统、设备及介质
US20230142147A1 (en) * 2021-11-10 2023-05-11 Microsoft Technology Licensing, Llc Network communication using proof of presence
WO2024090530A1 (en) * 2022-10-26 2024-05-02 Nec Corporation Decentralized identity management apparatus, decentralized identity management system, decentralized identity management method, and decentralized identity management storage medium

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020085378A1 (ja) * 2018-10-24 2020-04-30 日本電信電話株式会社 権利者端末、利用者端末、権利者プログラム、利用者プログラム、コンテンツ利用システムおよびコンテンツ利用方法
US20200153639A1 (en) * 2019-07-02 2020-05-14 Alibaba Group Holding Limited System and method for decentralized-identifier authentication

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020085378A1 (ja) * 2018-10-24 2020-04-30 日本電信電話株式会社 権利者端末、利用者端末、権利者プログラム、利用者プログラム、コンテンツ利用システムおよびコンテンツ利用方法
US20200153639A1 (en) * 2019-07-02 2020-05-14 Alibaba Group Holding Limited System and method for decentralized-identifier authentication

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024150529A1 (ja) * 2023-01-12 2024-07-18 富士通株式会社 プログラム、情報処理方法および情報処理装置

Also Published As

Publication number Publication date
JP2022012244A (ja) 2022-01-17
JP7462903B2 (ja) 2024-04-08
US20230232222A1 (en) 2023-07-20

Similar Documents

Publication Publication Date Title
CN111164594B (zh) 用于将去中心化标识映射到真实实体的系统和方法
CN111095865B (zh) 用于发布可验证声明的系统和方法
CN111066020B (zh) 用于创建去中心化标识的系统和方法
CN111095327B (zh) 用于验证可验证声明的系统和方法
JP6943356B2 (ja) Ｕｔｘｏ基盤プロトコルを利用したブロックチェーン基盤の文書管理方法及びこれを利用した文書管理サーバ｛ｍｅｔｈｏｄ ｆｏｒ ｍａｎａｇｉｎｇ ｄｏｃｕｍｅｎｔ ｏｎ ｂａｓｉｓ ｏｆ ｂｌｏｃｋｃｈａｉｎ ｂｙ ｕｓｉｎｇ ｕｔｘｏ−ｂａｓｅｄ ｐｒｏｔｏｃｏｌ，ａｎｄ ｄｏｃｕｍｅｎｔ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ ｕｓｉｎｇ ｓａｍｅ｝
JP7177575B2 (ja) ランダム・シーケンスを生成および検証するための分散型台帳
JP6877448B2 (ja) 分散ハッシュテーブル及びブロックチェーンを用いてコンピュータソフトウェアを保証する方法及びシステム
WO2022004854A1 (ja) 利用者端末、認証者端末、登録者端末、管理システムおよびプログラム
US11646891B2 (en) Compact recordation protocol
US10936552B2 (en) Performing bilateral negotiations on a blockchain
JP2022059070A (ja) 電子投票システム、装置、制御方法、及び、プログラム
EP4002786B1 (en) Distributed ledger system
JP7114078B2 (ja) 電子認証方法及びプログラム
JP2019153181A (ja) 管理プログラム
JP2024507908A (ja) Ｓｓｉを用いたブロックチェーンネットワークアイデンティティ管理
US20240214392A1 (en) Unified authentication system for decentralized identity platforms
US20200082391A1 (en) Performing bilateral negotiations on a blockchain
WO2022193920A1 (en) Blockchain data segregation
US20230206219A1 (en) Identification token, systems and methods for identification and identity verification.
WO2023099357A1 (en) Compressible blockchains
JP2024534315A (ja) プライバシー保護状態参照
JP2023087665A (ja) システム、方法、およびコンピュータプログラム製品（許可型ブロックチェーンのためのマルチ発行者匿名クレデンシャル）
WO2021153421A1 (ja) 制御方法、サーバ、および、プログラム
JP2007110175A (ja) 管理サービス装置、バックアップサービス装置、通信端末装置及び記憶媒体
JP6901373B2 (ja) ユーザ管理装置、ユーザ管理システム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21832407

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21832407

Country of ref document: EP

Kind code of ref document: A1