KR102829377B1 - Method and system for forced tagging of third party opinion information included in VP (Verifiable Credential) - Google Patents

Abstract

The present invention relates to DID technology, and relates to a method for mandatory tagging of third-party opinion information included in a VP, which encrypts the third-party evaluation content included in a VC so that the VP creator, who is the subject of the evaluation, cannot see it, and assigns a mandatory tag so that the VP can be verified only when it includes the tag.

Description

Method and system for forced tagging of third party opinion information included in VP (Verifiable Credential)

The present invention relates to DID technology, and more particularly, to a method for mandatory tagging of third-party opinion information included in a Verifiable Credential (hereinafter referred to as “VC”), which encrypts the third-party evaluation content included in the VC so that the creator of the Verifiable Credential (hereinafter referred to as “VP”), which is the subject of the evaluation, cannot see it, and assigns a mandatory tag so that the VP can be verified only if it includes the tag.

Decentralized identifiers (hereinafter referred to as 'DIDs') are globally unique identifiers that do not require a centralized registration agency such as a server by registering in a distributed repository using distributed ledger technology or other distributed network technologies, and are used in electronic identification systems built on blockchain technology.

In existing centralized identity management systems where a service provider centrally manages a user's digital identity, it is common to issue a user ID and credentials (e.g. password) to verify the ID, and to retain and manage user information such as user name and address. Since the user identity is delegated to and managed by a central agency, it is difficult for the user to control his or her identity, personal data, and related attribute information managed by the central agency.

In contrast, using distributed network technologies such as blockchain, individual users can manage their own identity information. This is called a distributed identity management system, and the identifier used for this is called DID.

Specifically, you can prove your identity by submitting your DID from your blockchain wallet in situations where it is necessary, such as taking out your resident registration card from your wallet to prove your identity. Compared to existing identity authentication methods, it is characterized by individuals exercising complete control over their own information during the identity verification process.

At this time, in the VP for purposes such as verifying careers, the opinions of third parties evaluating the person requesting career verification may be included, and these third party opinions may contain negative content about the person requesting career verification. In this case, a technology is required to force the person requesting career verification to not omit this information during the submission process while preventing the person requesting career verification from confirming this content.

Republic of Korea Patent No. 10-2439879 (2022.08.30)

The present invention was created to solve the above problems, and the purpose of the present invention is to provide a method for mandatory tagging of third-party opinion information included in a VP, which encrypts the third-party evaluation content included in a VC so that the VP creator, who is the subject of the evaluation, cannot view it, and assigns a mandatory tag so that the VP can be verified only if it includes the tag.

For the above purpose, the present invention provides a method for distributing a VP based on a DID in which an evaluator, a VC issuer, a VP generator, and a VP verifier are registered in a server, and the VP generator generates a VP through a VC issued by the VC issuer and submits the VP to the VP verifier, comprising the steps of: the evaluator generating evaluation information about the VP generator, encrypting it, signing it with a private key, and transmitting the encrypted evaluation information and an encryption key to the VC issuer; the VC issuer signing the personal information of the VP generator including the encrypted evaluation information with a private key at the request of the VP generator to issue a VC; the VP generator processing the VC issued by the VC issuer, signing it with a private key, generating a VP, and submitting the VP to the VP verifier; the VP verifier verifying the signature on the encrypted evaluation information with the public key of the evaluator, and requesting the encryption key from the VC issuer; It is characterized by including a step in which the VC issuer verifies the public key of the VP verifier and transmits an encryption key encrypted using the public key of the VP verifier to the VP verifier; a step in which the VP verifier decrypts the encrypted evaluation information using the transmitted encryption key.

At this time, in the step of issuing the VC (S 120), it is preferable to perform encryption using a symmetric key and transmit the encryption key and initialization vector together.

In the present invention, if a VP for the purpose of career verification, etc. includes a third party's opinion evaluating the user who created the VP, this is encrypted and transmitted to the VP verifier so that the user cannot see it, and this content is forcibly tagged so that the VP can be verified only if it is included. Through this, it is possible to provide a highly useful VP that includes a third party's evaluation, and this evaluation information can also be utilized for verification to improve the security and verification performance of personal information.

Figure 1 is a conceptual diagram of the present invention;
Figure 2 is a flow chart according to an embodiment of the present invention;
Figure 3 is a protocol description diagram according to an embodiment of the present invention.
Figure 4 is a block diagram showing the configuration and connection relationship according to an embodiment of the present invention.

Referring to the attached drawings below, a method for mandatory tagging of third-party opinion information included in the VP of the present invention is specifically described.

FIG. 1 is a conceptual diagram of the present invention, FIG. 2 is a flow chart according to an embodiment of the present invention, and FIG. 3 is a protocol explanatory diagram according to an embodiment of the present invention.

In the basic DID concept, a VC is issued by a VC issuer (did:sov:ABC1) to a VC requester (=VP creator, did:sov:123), and is a verifiable certificate issued by putting the requester's property in the Claim and the signature value signed with the issuer's private key in the proof. For example, the career certificate issued to did:sov:123 by the company he worked for, did:sov:ABC1, becomes a VC.

VP is a certificate that did:sov:123 collects the VCs he received with his career certificates (did:sov:ABC1, did:sov:ABC2...), signs them with did:sov:123's private key, and puts the signature value in the proof.

In the present invention, a method is proposed to prevent personal information from being leaked when a VP generator (did:sov:123) issues a certificate of career (VP) to a recruiting company (=VP verifier, did:sov:BCD) to prove his/her career, and to trace who leaked the personal information if it is leaked.

These DIDs are based on blockchain and are based on a DID creation process in which each of the three entities, a VC issuer (A), a VP creator (B), and a VP verifier (C), registers their own public keys and is assigned a DID address.

The above VC issuer (A) is the Issuer, which is the entity that issues the VC, which is the user's identity information, and is an institution that issues identity information and DID at the request of the user, who is the information subject. The Issuer delivers reliable identity information for the information it issues.

The above VP creator (B) is a user, Holder, who owns the identity information and is a user who wants to prove his/her identity by using DID as the information subject. The system issues and submits a DID.

The above VP Verifier is a service provider that verifies identity information. It receives VP from the user, who is the information subject, and verifies the identity information.

At the request of the VP generator (B), the VC issuer (A) issues a VC, which is a credential that includes the identity information of the VP generator (B), by signing it with the VC issuer's (A) private key, and the details of this signing and issuance are stored on the blockchain.

The VP generator (B) stores the VC issued by the VC issuer (A) in a personal terminal, signs the necessary information with the VP generator's (B) private key to create a VP, and submits it to the VP verifier (C).

The general concept of DID is that the VP verifier (C) verifies the information of the VC issuer and VP creator through the submitted VP, and the fact that the VC issuer has issued the VC through the blockchain.

At this time, the VC consists of Credential metadata, Claims(s), and Proof(s). Credential metadata includes the VC issuer, the specified object, expiration period, disposal method, etc., and Claim(s) stores information about the ID attribute of the Credential subject in the 'Subject-Property-Value' format. Proof(s) contains values required to verify the authenticity of the VC, so the verifying subject can verify whether the VC was issued by the issuer specified in the VC by verifying the Proof of the VC.

VP consists of Presentation Metadata, Verifiable Credential(s), and Proof(s). Presentation Metadata includes data required for VP verification, such as type, terms of use, and evidence that specify that the data is a VP. Verifiable Credential(s) is an area where the verifier selects and enters VCs with ID attributes required by the verifier. The VP creator selects and enters only Claims with ID attributes required by the VP verifier, thereby protecting privacy. Proof includes the VP creator's signature.

Based on such conventional DID, the present invention encrypts the evaluation information of a third party (did:sov:CDE) that evaluated the VP generator and includes it in the VC, encrypts it so that the VP generator cannot view the contents, enables it to be transmitted to the VP verifier, and forcibly tags it so that it can be used for VP verification.

Accordingly, the present invention is based on the premise that an evaluator, a VC issuer, a VP generator, and a VP verifier are registered on a server, and a DID is created by the VP generator generating a VP through a VC issued by the VC issuer and submitting the VP to the VP verifier.

First, a step (S 110) is performed in which the evaluator generates evaluation information for the VP generator through the evaluator terminal (110), encrypts it, signs it using a private key, and then transmits the encrypted evaluation information and an encryption key to the VC issuer.

At this time, the evaluation information is encrypted using JSON Web Encryption (jwe) and the encrypted evaluation information, encryption key, and IV (Initialization Vector) are transmitted to the VC issuer.

The VC issuer, which receives encrypted evaluation information and an encryption key through the VC issuer terminal (120), performs a step (S 120) of issuing a VC by signing the VP generator's personal information including the encrypted evaluation information with a private key at the request of the VP generator.

At this time, the value of the jwe signed by the evaluator of the encrypted evaluation information is entered into the proof, and the VC format according to the embodiment of the present invention is as follows.

...

“credentailSubject”:{

“id”: “did:sov:123”,

“carrer1”: {

“companyName”:“...”

“fromDate”: “...”

“toDate”:“....”

“Project”:[{“name”:“....”, “role”:“....”.....}

“eval”:jwe

“Proof”:{

.... Omitted,

“3rdParty”: did:sov:CDE

“challenge”: ....

“keystorage”: URL or blockchain A,

“jws”: ...

}

}

“Proof”:{

.... Omitted,

type:...

created:....

“creator”: “bankCarrierOn”

“verificationMethod”: “....”

“jws”:“....”

}

},

Here, eval means evaluation for the VP constructor, and bankCarrierOn means the VC constructor. Omitted content is indicated as ....., and omitted DID-related content is a known technology, and to prevent the purpose of the present invention from being obscured, content that is identical to the existing DID is omitted.

Here is the content of jwe:

“header” : { “alg”: public key encryption algorithm “, enc”: symmetric key encryption algorithm “ },

“ciphertext” : “Ciphertext for reputation”

The reason the above challenge value is included is that the encryption key and IV value used when encrypting jwe in eval in keystorage are retrieved using the challenge, and the encryption key and IV are encrypted with the public key of the VC issuer, so the VC issuer decrypts them with its private key, and as described later, when the VC issuer sends the encryption key and IV held by the VP verifier to the VP verifier, the encryption key and IV are encrypted with the public key of the VP verifier in the VP and then transmitted.

Additionally, the Proof in the credentailSubject contains the signed value of jwe in the encrypted evaluation information (eval) by a third party (did:sov:CDE).

The above key storage can be an off-chain server or a blockchain network. The blockchain network is on-chain, and all transaction information on the on-chain is included in the block, and recorded transactions cannot be permanently deleted. It has high stability because it forms its own network and all records in the blockchain are recorded and disclosed to all users.

Off-chain, unlike on-chain, records specific transaction details in an independent external location, not directly on the blockchain. Unlike on-chain, it can process quickly because it does not require a consensus process or verification. Only core data is recorded on the blockchain, and data that requires high speed is recorded on the DAPP central server, not the blockchain, and it is fast and inexpensive.

Next, a step (S 130) is performed in which the VP generator processes the VC issued by the VC issuer through the VP generator terminal (130), signs it with a private key, creates a VP, and submits the VP to the VP verifier. In this process, the evaluation information included in the VC is encrypted, and the encryption key and IV for this are held by the VC issuer, so the VP is created without the VP generator being able to verify the contents.

In an embodiment of the present invention, the form of VP is as follows.

credentialSubject:...eval, Proof..

Proof:......

The following is a step (S 140) in which the VP verifier verifies the signature on the encrypted evaluation information using the public key of the evaluator through the VP verifier terminal (140) and requests the encryption key from the VC issuer. That is, the public key of the evaluator is verified in the blockchain through the evaluator DID in the 3rd Party in the Proof of the credentailSubject, and the jwe signature is verified using the public key of the evaluator.

Thereafter, a step (S 150) is performed in which the VP generator is requested to provide the encryption key and IV, and the VC issuer, which receives the encryption key and IV, verifies the public key of the VP verifier and transmits the encrypted encryption key to the VP verifier.

As mentioned above, the VC issuer retrieves the encryption key and IV value encrypted with the VC issuer's public key from keystorage with the challenge, and when the VC issuer sends the encryption key and IV to the VP verifier with its private key, it encrypts the encryption key and IV with the VP verifier's public key in the VP and transmits them.

Finally, a step (S 160) is performed in which the VP verifier decrypts the encrypted evaluation information using the encryption key received from the VC issuer.

FIG. 4 is a block diagram showing a configuration and connection relationship according to an embodiment of the present invention, and briefly shows a terminal owned by each entity in which a method according to the present invention is performed and a network environment in which it operates.

Basically, the above server (150) is configured to be able to communicate with an evaluator terminal (110), a VC issuer terminal (120), a VP generator terminal (130), and a VP verifier terminal (140) via a network, either wired or wireless, and may be an off-chain server or a blockchain.

The above evaluator terminal (110) is a terminal used by a third party to perform an evaluation of a VP generator. As mentioned above, the third party may be an evaluator who can evaluate the performance or attendance of a VP generator related to VC.

The above VC issuer terminal (120) is a terminal used by the entity issuing the VC and issues a VC, which is data for qualification authentication, to a user whose identity has been verified. For example, the terminal may be a public institution or a company or institution that issues various supporting documents requested by the user.

The above VP generator terminal (130) is a terminal used by the subject of generating the VP and is a terminal owned by the user who is the subject of the information. It has the role of requesting the issuance of a VC to the above VC issuer terminal (110), creating a VP through the issued VC, and registering the information thereon with the server (140) and submitting the VP to the above VP verifier terminal (130).

The above VP verifier terminal (140) is a terminal used by the entity verifying the VP, and can be a terminal of an institution that receives the user's identity verification data and performs identity authentication based on the received identity verification data. Verification of the user can be performed using the decryption information registered in the blockchain network.

The above-mentioned evaluator terminal (110), VC issuer terminal (120), VP generator terminal (130), and VP verifier terminal (140) may be implemented as a computer that can access a remote server or terminal via a network. For example, the computer may include a notebook, desktop, laptop, etc. equipped with a web browser. In addition, the evaluator terminal (110) and the VP generator terminal (130) may include all types of portable personal terminal devices such as a smartphone, a smartpad, a tablet PC, etc., as terminals that can access a remote server or other terminal via a network.

The rights of the present invention are not limited to the embodiments described above, but are defined by what is described in the claims, and it is obvious that a person skilled in the art in the field of the present invention can make various modifications and adaptations within the scope of the rights described in the claims.

110: Evaluator Terminal 120: VC Issuer Terminal
130: VP generator terminal 140: VP verifier terminal
150: Server

Claims (2)

In a specific method of distributing VP based on DID, where an evaluator, a VC issuer, a VP generator, and a VP verifier are registered on a server, and the VP generator generates a VP through a VC issued by the VC issuer and submits it to the VP verifier,
A step (S 110) in which the evaluator creates evaluation information for the VP generator, encrypts it, signs it using a private key, and then transmits the encrypted evaluation information and an encryption key to the VC issuer;
A step (S 120) in which the VC issuer issues a VC by signing the VP generator's personal information, including the encrypted evaluation information, with a private key at the request of the VP generator;
Step (S 130) where the VP generator processes the VC issued by the VC issuer, signs it with a private key, creates a VP, and submits the VP to the VP verifier;
Step (S 140) where the VP verifier verifies the signature on the encrypted evaluation information through the public key of the evaluator and requests the encryption key from the VC issuer;
A step (S 150) in which the VC issuer verifies the public key of the VP verifier and transmits an encryption key encrypted using the public key of the VP verifier to the VP verifier;
A method for mandatory tagging of third-party opinion information included in a VP, characterized in that it includes a step (S 160) of decrypting encrypted evaluation information using a transmitted encryption key by the above VP verifier.
In the first paragraph,
A method for mandatory tagging of third-party opinion information included in a VP, characterized in that in the step of issuing the above VC (S 120), encryption is performed using a symmetric key and an encryption key and an initialization vector are transmitted together.