System and method for distributed identifier-based ticketing

Abstract

A system and method for decentralized identifier-based ticketing is provided. [Solution] A method for decentralized identifier-based ticketing includes a step in which a user device uploads a decentralized identification (DID) and a DID document to a Verifiable Data Registry (VDR) and registers the DID; a step in which the user device transmits the DID and requests the issuance of a verifiable credential (VC) for the purchased ticket; a step in which an issuer device obtains the DID document from the VDR via the DID; a step in which the issuer device interacts with the user device to authenticate ownership of the DID using an authentication method included in the DID document; and a step in which the issuer device issues a verifiable credential corresponding to the DID to the user device if the issuer device successfully authenticates ownership of the DID.

Description

[Technical Field]

[0001] The present invention relates to ticketing technology, and more particularly to a system and method for distributed identifier-based ticketing.

[0002] This invention was derived from research conducted on the project "IP Advancement and Commercialization for Promoting the Commercialization of Metaverse International Standard Technology" (project executing agency: Myongji University Industry-Academia Collaboration Group; project number: RS-2024-00424718) as part of the Ministry of Science and ICT's support for revitalizing industry-academia collaboration (R&D) program. [Background technology]

[0003] Traditional media content such as plays, operas, concerts, and sports continues to attract a large number of people's attention. Competition for tickets is particularly fierce for performances by singers and bands with large fanbases, such as K-POP, or for sports stars and teams. This has led to increased negative effects such as fraudulent ticket sales, hindering healthy cultural and sports viewing. Measures to prevent such negative effects are needed. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Korean Patent Publication No. 2000-0054443 (Published September 5, 2000) Summary of the Invention [Problem to be solved by the invention]

[0005] SUMMARY OF THE INVENTION It is an object of the present invention to provide a system and method for distributed identifier-based ticketing. [Means for solving the problem]

[0006] To achieve the above-mentioned object, a method for decentralized identifier-based ticketing according to a preferred embodiment of the present invention includes a step in which a user device uploads a decentralized identification (DID) and a DID document to a verifiable data registry (VDR) and registers the DID; a step in which the user device transmits the DID and requests issuance of a verifiable credential (VC) for the purchased ticket; a step in which an issuer device obtains the DID document from the VDR via the DID; a step in which the issuer device authenticates ownership of the DID using an authentication method included in the DID document through interaction with the user device; and a step in which the issuer device issues a verifiable credential corresponding to the DID to the user device if the issuer device successfully authenticates ownership of the DID.

[0007] The DID document is characterized in that it includes an authentication means and one or more authentication methods corresponding to the DID for proving ownership of the DID.

[0008] The step of authenticating ownership of the DID includes a step of the issuer device transmitting encrypted data to authenticate DID ownership using an authentication method included in the DID document, a step of the user device decrypting the encrypted data using the authentication method and returning the decrypted data, and a step of the issuer device authenticating ownership of the DID by receiving the decrypted data.

[0009] The verifiable credential (VC) includes credential metadata, including the issuer, expiration period, and disposal method of the verifiable credential, a claim, including the subject of the credentials, and a proof, including a value for authenticating the verifiable credential.

[0010] The method includes the steps of the user device generating a verifiable presentation (VP) including the verifiable credential (VC), the user device providing the verifiable presentation to a verifier device, the verifier device obtaining a DID document from the VDR via the DID of the verifiable credential included in the verifiable presentation, the verifier device authenticating the verifiable presentation, and if the authentication of the verifiable presentation is successful, the verifier device authenticating ownership of the DID using an authentication method included in the DID document through interaction with the user device, and if the authentication of ownership of the DID is successful, authenticating the user as a legitimate purchaser of the ticket.

[0011] The step of authenticating the verifiable presentation includes the step of the verifier device authenticating a verifiable credential included in the verifiable presentation using the public key of the issuer of the verifiable presentation, and if the verifier device successfully authenticates the verifiable credential, the verifier device authenticating the verifiable presentation using the public key of the holder of the verifiable presentation.

[0012] The step of authenticating the ownership of the DID includes a step of transmitting encrypted data to authenticate the ownership of the DID according to an authentication method included in the DID document, a step of the user device decrypting the encrypted data according to the authentication method and returning the decrypted data, and a step of the verifier device receiving the decrypted data and completing the authentication.

[0013] The verifiable presentation (VP) includes presentation metadata containing data to reference for verifying the verifiable presentation, one or more verifiable credentials (VC), and a proof item containing a user's signature.

[0014] To achieve the above-mentioned object, a system for decentralized identifier-based ticketing according to a preferred embodiment of the present invention includes a user device that uploads a decentralized identification (DID) and a DID document to a verifiable data registry (VDR) and registers the DID; transmits the DID and requests issuance of a verifiable credential (VC) for a purchased ticket; and an issuer device that obtains the DID document from the VDR via the DID, interacts with the user device to authenticate ownership of the DID according to an authentication method included in the DID document, and issues a verifiable credential corresponding to the DID to the user device if the authentication of ownership of the DID is successful.

[0015] The DID document is characterized in that it includes an authentication means and one or more authentication methods corresponding to the DID for proving ownership of the DID.

[0016] The issuer device transmits encrypted data to authenticate DID ownership using an authentication method included in the DID document, and receives data from the user device in which the encrypted data has been decrypted using the authentication method, thereby authenticating the ownership of the DID.

[0017] The verifiable credential (VC) includes credential metadata, including the issuer, expiration period, and disposal method of the verifiable credential, a claim, including the subject of the credentials, and a proof item, including a value for authenticating the verifiable credential.

[0018] The user device generates a verifiable presentation (VP) including the verifiable credential (VC) and provides the verifiable presentation to a verifier device, and the verifier device obtains a DID document from the VDR via the DID of the verifiable credential included in the verifiable presentation, and if the verifiable presentation is successfully authenticated, authenticates ownership of the DID using an authentication method included in the DID document through interaction with the user device, and if the authentication of ownership of the DID is successful, authenticates the user as a legitimate ticket purchaser.

[0019] The verifier device is characterized in that it authenticates the verifiable credential included in the verifiable presentation using the public key of the issuer of the verifiable presentation, and if authentication of the verifiable credential is successful, it authenticates the verifiable presentation using the public key of the holder of the verifiable presentation.

[0020] The step of authenticating the ownership of the DID is characterized in that the verifier device transmits encrypted data to authenticate the ownership of the DID according to an authentication method included in the DID document, and receives decrypted data from the user device, which is the encrypted data, to complete the authentication.

[0021] The verifiable presentation (VP) includes presentation metadata containing data to reference for verifying the verifiable presentation, one or more verifiable credentials (VC), and a proof item containing a user's signature. [Effects of the Invention]

[0022] According to the present invention, by issuing and verifying tickets via a decentralized identifier (DID), a verifiable credential (VC), and a verifiable presentation (VP), only the buyer who purchased the first ticket is the legitimate owner, thereby preventing the negative effects of fraudulent ticket sales and the like. [Brief explanation of the drawings]

[0023] [Figure 1] 1 is a diagram illustrating the configuration of a system for distributed identifier-based ticketing according to an embodiment of the present invention. [Figure 2] 1 is a diagram illustrating a method for registering a decentralized identification (DID) according to an embodiment of the present invention. [Figure 3] FIG. 1 is a diagram illustrating the configuration of a distributed identifier (DID) according to an embodiment of the present invention. [Figure 4] FIG. 2 is a diagram illustrating the structure of a distributed identifier (DID) document according to an embodiment of the present invention. [Figure 5] 1 is a flowchart illustrating a method for authenticating ownership of a DID according to an embodiment of the present invention. [Figure 6] 10 is a flowchart illustrating a method for authenticating ownership of a DID according to another embodiment of the present invention. [Figure 7]1 is a diagram for explaining the structure of a verifiable credential (VC) and a verifiable presentation (VP) according to an embodiment of the present invention. [Figure 8] FIG. 2 is a diagram illustrating a verifiable credential (VC) according to an embodiment of the present invention. [Figure 9] 1 is a flowchart illustrating a method for distributed identifier-based ticketing according to an embodiment of the present invention. [Figure 10] 1 is a flowchart illustrating a method for distributed identifier-based ticketing according to an embodiment of the present invention. [Figure 11] FIG. 2 is a diagram illustrating a method for generating a verifiable presentation VP from a verifiable credential VC according to an embodiment of the present invention. [Figure 12] FIG. 1 illustrates a computing device according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0024] The present invention can be modified in various ways and can have various embodiments, and specific embodiments will be illustrated and described in detail in the detailed description. However, this is not intended to limit the present invention to the specific embodiments, and it should be understood that the present invention includes all modifications, equivalents, and alternatives within the spirit and technical scope of the present invention. Furthermore, throughout the specification, when any part "comprises" a certain element, this does not mean that it excludes other elements, but that it may further include other elements, unless otherwise specified.

[0025] The terms used in the present invention are merely used to describe specific embodiments and are not intended to limit the present invention. A singular expression includes a plural expression unless the context clearly dictates otherwise. In the present invention, terms such as "comprise" or "have" are intended to specify the presence of features, numbers, steps, operations, components, parts, or combinations thereof described in the specification, and should be understood not to preclude the presence or possibility of addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0026] In particular, the terms and words used in the following specification and claims should not be interpreted as being limited to their ordinary or dictionary meanings, but should be interpreted as meanings and concepts that correspond to the technical idea of ​​the present invention based on the principle that the inventor can appropriately define the concept of the term in order to best explain his / her invention.

[0027] First, a configuration of a system for distributed identifier-based ticketing according to an embodiment of the present invention will be described. Figure 1 is a diagram illustrating a configuration of a system for distributed identifier-based ticketing according to an embodiment of the present invention.

[0028] Referring to FIG. 1, a distributed identifier-based ticketing system 10 according to an embodiment of the present invention includes a user device 100, an issuer device 200, a verifier device 300, and a Verifiable Data Registry (VDR) 400.

[0029] The user device 100 is a device used by a user to purchase tickets. The user device 100 can perform computing operations and can communicate via a network or a direct connection between devices. A typical example of the user device 100 is a smartphone.

[0030] The issuer device 200 is a device used by a user who issues a ticket, i.e., an issuer. The issuer device 200 can perform computing operations and can communicate via a network or a direct connection between devices. Typically, the issuer device 200 can be a workstation-class computing device.

[0031] The verifier device 300 is a device used by a user who verifies a ticket, i.e., a verifier. The verifier device 300 can perform computing operations and communicate via a network or a direct connection between devices. In particular, the verifier device 300 may further include a scanner for fingerprint recognition and a camera for face authentication. Examples of such a verifier device 300 include a smartphone, a kiosk, etc.

[0032] The Verifiable Data Registry (VDR) 400 is a storage medium present on a network and, although not shown, is a medium included in one or more computing devices. According to one embodiment, the VDR 400 may be implemented by multiple nodes constituting a blockchain network or may be implemented in an InterPlanetary File System (IPFS). According to another embodiment, the VDR 400 may be implemented via a database server.

[0033] Next, a decentralized identification (DID) according to an embodiment of the present invention will be described. Fig. 2 is a diagram for explaining a method for registering a decentralized identification (DID) according to an embodiment of the present invention. Fig. 3 is a diagram for explaining the configuration of a decentralized identification (DID) according to an embodiment of the present invention. Fig. 4 is a diagram for explaining the configuration of a decentralized identification (DID) document according to an embodiment of the present invention.

[0034] 2, the user device 100 generates a DID and a DID document that proves the DID via a DID application (e.g., an app or web application), and registers the DID by storing the generated DID and DID document in the VDR 400. The DID document includes authentication means (e.g., a public key) and an authentication method for proving ownership of the DID. When proof of ownership of the DID is requested, the DID application can refer to the DID document via location information of the DID document stored in a DID location (e.g., a blockchain) within the VDR 400.

[0035] Referring to FIG. 3, a DID includes a 'did', a DID method based on a storage location, and a method-specific identifier that is an identifier corresponding to the DID method.

[0036] For example, a DID can be generated as "did:btcr:xyv2-xzpq-q9wa-p7t." This indicates that the DID was generated based on the Bitcoin blockchain using the DID method "btcr." The method-specific identifier "xyv2-xzpq-q9wa-p7t" is generated from the Bitcoin transaction location reference.

[0037] As another example, a DID such as "did:sov:mnjkl98uipsndg2hdjdjuf7" can be generated. This indicates that the DID was generated based on a dedicated distributed ledger (Sovrin-Hyperledger Indy) via the DID method "sov." The method-specific identifier "mnjkl98uipsndg2hdjdjuf7" can be generated from a universally unique identifier (UUID) or the user's public key.

[0038] Referring to Figure 4, a DID document includes authentication means that can prove ownership of a DID. A DID document includes, as main items, a context, an identifier (ID), a public key, a certificate, and a service.

[0039] Context (@context) defines the meaning and included data of identifier (id), authentication, and service items in a DID document. Context (@context) items are created using the JSON-LD grammar.

[0040] The identifier (id) contains the DID of the object identified by the id. If the purpose is to identify a user, the user's DID is included, and if the purpose is to identify an object, the object's DID is included. For example, the DID and the DID of the user who created and registered the DID document are recorded in the identifier (id) item.

[0041] The public key (publicKey) contains information for authenticating DID ownership. In particular, the public key (publicKey) contains the details "id", "type", "controller", and "publicKeyPem".

[0042] "id" is used to authenticate DID ownership. "type" can include various authentication methods such as asymmetric key authentication (RSA), biometric authentication, and elliptic curve asymmetric key authentication. "controller" indicates the person who has the authentication authority for "publicKeyPem." For example, in the case of Ethereum-based RSA asymmetric key authentication, the DID on line 7 (line 7 in Figure 4) indicates the DID of the person who holds the private key that forms a pair with the public key on line 8. "publicKeyPem" indicates the data used to authenticate the ownership of the DID. For example, line 8 indicates the public key required for asymmetric authentication.

[0043] The authentication includes the ownership authentication method provided in the DID document. The user device 100 can select one of the three methods shown in lines 21 to 23 to authenticate the DID ownership.

[0044] Next, a method for authenticating ownership of a DID according to an embodiment of the present invention will be described. Fig. 5 is a flowchart illustrating a method for authenticating ownership of a DID according to one embodiment of the present invention. Fig. 6 is a flowchart illustrating a method for authenticating ownership of a DID according to another embodiment of the present invention. Here, Fig. 5 is an example of DID ownership authentication when the user of the user device 100 has authentication authority for the DID, and Fig. 6 is an example when the DID owner does not have authentication authority for the DID.

[0045] 5 according to one embodiment, the authentication agency VA may be the issuer device 200 or the verifier device 300. Referring to FIG. 5, it is assumed that the user device 100 has uploaded the user's DID and DID document to the VDR 400 by the user's operation and registered the DID.

[0046] The authentication agency VA, which receives the DID from the user device 100, asks the user device 100 to select an authentication method by referring to the authentication field of the DID document (step S110) (1).

[0047] Next, the user device 100 selects one of the authentication methods in step S120 (2).

[0048] Next, the authentication agency VA checks the authentication method selected by the user device 100 in step S130 (3), and encrypts the verification data using the public key of “publickey pem” according to the authentication method selected by the user device 100 in step S140 (4).

[0049] Next, the authentication agency VA provides the encrypted verification data to the user device 100 in step S150 (5).

[0050] Next, in step S160, the user device 100 decrypts the encrypted verification data using a secret key (private key) and provides the decrypted data to the authentication agency VA (6).

[0051] This allows the authentication agency VA to complete authentication of DID ownership for the user device 100 via the decrypted verification data.

[0052] 6 according to another embodiment, the issuing agency IA may be the issuer device 200 and the authentication agency VA may be the verifier device 300. In this case, it is assumed that the issuing agency IA is in a state where the user device 100 has issued a DID to the user.

[0053] The user device 100 may provide the identifier of the issuing agency IA and the user's DID to the authentication agency VA in step S210 (1).

[0054] Next, in step S220, the authentication agency VA checks the authentication (e.g., line 20 in Figure 4) field and the public key (publickKey) "controller" field (e.g., line 7 in Figure 4) of the DID document corresponding to the user's DID "did:sov:1234" (2).

[0055] As a result, at step S230, the authentication agency VA requests the issuing agency IA for a private key (secret key), which is the authentication means corresponding to the DID "did:sov:1234" (3).

[0056] Next, the issuing agency IA checks the issuance history in step S240 (4), and then provides the private key to the authentication agency VA in step S250 (5). This allows the authentication agency VA to check the private key and complete the authentication.

[0057] Next, a verifiable credential (VC) and a verifiable presentation (VP) according to an embodiment of the present invention will be described. Fig. 7 is a diagram for explaining the structure of a verifiable credential (VC) and a verifiable presentation (VP) according to an embodiment of the present invention. Fig. 8 is a diagram for explaining a verifiable credential (VC) according to an embodiment of the present invention.

[0058] Referring to FIG. 7, a verifiable credential VC includes credential metadata, a claim, and a proof item.

[0059] Credential metadata includes the issuer of a verifiable credential, its expiration period, and its disposal method. A claim is information about the identity attributes of the credential's subject, and is stored in the form of subject-attribute-value. That is, a claim contains information related to the credential's subject that the VC refers to. A proof contains a value for authenticating a verifiable credential. For example, various encryption technologies such as RSA, ECDSA, and biometric authentication can be included. In particular, a proof contains the signature of the VC issuer.

[0060] More specifically, referring to FIG. 8, a verifiable credential VC includes items such as a context (@context), an identifier (id), a type (type), an issuer (issuer), an issue date (issuanceDate(validFrom)), an expiration date (expireDate(validUntil)), a credential subject (credentialSubject), a credential scheme (credentialSchema), a credential status (credentialStatus), and proof (proof).

[0061] The context (@context) is used to define data values. "https: / / www.w3.org / 2018 / credentials / v1" in line 3 must be included as the official VC context. "https: / / www.example.edu / context" in line 4 is a context that is created and inserted directly when additional context is needed for the service under development.

[0062] The Identifier (Id) field contains the identifier of the VC, such as "http: / / example.edu / / credential / yoon" on line 6. The DID identifier on line 12 is the identifier of the user (or object) identified by the VC.

[0063] In the type, the "VerifiableCredential" type on line 7 means that the VC is generated using the basic VC data structure defined in the VC official context, and "KoreanUniversityCredentia" means that the data required for the graduation certificate is generated using the data structure defined in the self-generation context.

[0064] Issuer refers to the person or organization that issued the VC. IssuanceDate(validFrom) defines when the VC is valid. Expiration Date(validUntil) defines the period for which the VC is valid. CredentialSubject is an item that contains claim data. Credential scheme can define a scheme for specific attributes of claims or VC. Through this, non-required attributes of VC can be restricted to required attributes.

[0065] CredentialStatus is intended to indicate the status of the credential (valid or expired).

[0066] The proof contains information for VC authentication. Here, "type" on line 20 is the type of proof. "proofPurpose" prevents misuse for purposes other than those intended. "VerificationMethod" on line 23 is the address (URL) where the public key is stored. "created" is the time the proof was generated. "proofValue" contains the value in which the digital signature binary data is encoded.

[0067] Still referring to FIG. 7, a verifiable presentation (VP) includes presentation metadata, one or more verifiable credentials VC and proof(s) items, and the like.

[0068] Presentation metadata includes data that can be referenced for VP authentication, such as type, terms of use, and evidence.

[0069] In the verifiable credential VC, the verifier selectively includes the required ID attributes among the claims in the VC, and the VC that has the required ID attributes. This allows for the protection of personal information.

[0070] VP's Proof(s) contain the user's signature. Compared to VC, VC's Proof(s) contain the issuer's signature. Various cryptographic techniques can be used via the Proof(s).

[0071] Next, a method for distributed identifier-based ticketing according to an embodiment of the present invention will be described. Figures 9 and 10 are flowcharts illustrating a method for distributed identifier-based ticketing according to an embodiment of the present invention. Figure 11 is a diagram illustrating a method for generating a verifiable presentation VP from a verifiable credential VC according to an embodiment of the present invention.

[0072] In the embodiment of FIGS. 9 to 11, the user of the user device 100 may be a ticket buyer, the issuer device 200 may be a device of a ticket sales company, and the verifier device 300 may be a device of a concert hall management company.

[0073] 9, it is assumed that the user device 100 has uploaded a decentralized identification (DID) and a DID document to the VDR 400 and registered the DID. The DID document includes authentication means and one or more authentication methods corresponding to the DID for proving ownership of the DID.

[0074] The user device 100 connects to the issuer device 200 in step S310 (1), and then pays the ticket amount to the issuer device 200, transmits the DID, and requests issuance of a verifiable credential (VC) corresponding to the ticket in step S320 (2). According to a further embodiment, for example, if three people are all going to a concert, the DIDs of all three people can be entered and the tickets for all three people can be paid. In this case, the following procedure can be performed for all three people.

[0075] Next, the issuer device 200 transmits the DID to the VDR 400 to request a DID document in step S330, and acquires the DID document from the VDR 400 in step S340 (3).

[0076] Next, the issuer device 200 interacts with the user device 100 to authenticate the ownership of the DID according to the authentication method included in the DID document.

[0077] Specifically, the issuer device 200 transmits encrypted data to the user device 100 so that the user device 100 can authenticate the ownership of the DID according to the authentication method included in the DID document in step S350. The data can be encrypted using the public key of 'publickey pem' (4).

[0078] As a result, the user device 100 decrypts the data encrypted by the authentication method in step S360, and then returns the decrypted data to the issuer device 200 (5). At this time, for example, data encrypted with a public key can be decrypted using a private key.

[0079] Upon receipt of such decrypted data by the issuer device 200, ownership of the DID can be authenticated.

[0080] If the authentication of the ownership of the DID is successful, the issuer device 200 generates a verifiable credential VC corresponding to the DID in step S370 and issues the generated verifiable credential VC to the user device 100 (6).

[0081] Here, a verifiable credential (VC) includes credential metadata including the issuer, expiration period, and disposal method of the verifiable credential, a claim including the subject of the credentials, and a proof item including a value for authenticating the verifiable credential.

[0082] 10, the user device 100 is issued a verifiable credential VC based on a DID according to the method described in FIG. 9. According to one embodiment, the verifiable credential VC may be stored in a wallet.

[0083] Since it is necessary to authenticate that the user is a legitimate ticket purchaser, in order to present the ticket to the concert hall management company, the user device 100 first inputs the user's signature and generates a verifiable presentation VP including a verifiable credential VC in step S410 (1). In this case, according to an additional embodiment, if a user is issued multiple (e.g., three) verifiable credential VCs, a single verifiable presentation VP including the multiple (e.g., three) verifiable credential VCs can be generated.

[0084] A verifiable presentation (VP) includes presentation metadata containing data to reference to verify the verifiable presentation, one or more verifiable credentials (VCs), and a proof item containing a user's signature.

[0085] After generating the verifiable presentation VP, the user device 100 provides the verifiable presentation VP corresponding to the ticket to the verifier device 300 in step S420 (2).

[0086] Next, the verifier device 300 transmits the DID of the verifiable credential VC included in the verifiable presentation VP to the VDR 400 in step S430, requests a DID document, and obtains the DID document from the VDR 400 in step S440 (3).

[0087] Next, the verifier device 300 authenticates the verifiable presentation VP. To do this, the verifier device 300 first authenticates the verifiable credential VC included in the verifiable presentation VP using the public key of the issuer of the verifiable credential VC included in the verifiable presentation VP, i.e., the issuer device 200, in step S450. If the authentication of the verifiable credential VC is successful, the verifier device 300 then authenticates the signature included in the verifiable presentation VP using the public key of the holder of the verifiable presentation VP, i.e., the user device 100, in step S460 (4).

[0088] If the authentication of the verifiable presentation VP is successful, the verifier device 300 can authenticate the ownership of the DID using the authentication method included in the DID document through interaction with the user device 100 in step S470 (5). Specifically, the verifier device 300 can request that the user device 100 authenticate the ownership of the DID using the authentication method included in the DID document. As a result, the user device 100 can authenticate the ownership of the DID by returning data for authentication to the issuer device 200 using the authentication method.

[0089] According to one embodiment, if the authentication method included in the DID document is asymmetric key authentication, the verifier device 300 can transmit encrypted data to the user device 100. As a result, the user device 100 can perform authentication by decrypting the encrypted data and returning the decrypted data to the issuer device 200. As a specific example of step S470, a ticket inspector can authenticate the ownership of the DID by obtaining the user's face image, fingerprint information, or user's private key according to the authentication method of the DID registered in the ticket VP using a mobile phone, i.e., a camera or fingerprint recognition device of the verifier device 300.

[0090] In this way, if the ownership of the DID is successfully authenticated, the verifier device 300 can authenticate the user of the user device 100 that presented the verifiable presentation VP as the legitimate purchaser of the ticket.

[0091] The distributed identifier-based ticketing method according to the present invention described above allows only those who entered their IDs at the time of purchase (DIDs of acquaintances, including the purchaser) to enter the concert hall. As such, the present invention has the effect of fundamentally blocking illegal ticket transfers, since only the DID holders registered on the ticket can enter. Furthermore, only the DID holders registered on the ticket can be authenticated using a private key (e.g., fingerprint, face, pupil).

[0092] 12 is a diagram illustrating a computing device according to an embodiment of the present invention. The computing device TN 100 in FIG. 12 may be any of the devices described herein, such as the user device 100, issuer device 200, verifier device 300, and VDR 400.

[0093] 12, computing device TN100 may include at least one processor TN110, a transceiver device TN120, and a memory TN130. Computing device TN100 may also include a storage device TN140, an input interface device TN150, an output interface device TN160, etc. The components included in computing device TN100 are connected by a bus TN170 and can communicate with each other.

[0094] The processor TN110 can execute program commands stored in at least one of the memory TN130 and the storage device TN140. The processor TN110 refers to a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor on which methods according to embodiments of the present invention are performed. The processor TN110 can be configured to implement procedures, functions, methods, etc. described in connection with embodiments of the present invention. The processor TN110 can control each component of the computing device TN100.

[0095] The memory TN130 and the storage device TN140 can each store various information related to the operation of the processor TN110. The memory TN130 and the storage device TN140 can each be configured with at least one of a volatile storage medium and a non-volatile storage medium. For example, the memory TN130 can be configured with at least one of a read-only memory (ROM) and a random access memory (RAM).

[0096] The transceiver TN120 can transmit or receive wired or wireless signals and can be connected to a network to perform communication.

[0097] In particular, various functions of the user device 100, issuer device 200, verifier device 300, and VDR 400 according to embodiments of the present invention may be implemented in the form of a program readable by a computer, stored in memory TN130, and executed by processor TN110. Alternatively, various functions of the user device 100, issuer device 200, verifier device 300, and VDR 400 may be implemented by a lower module of processor TN110.

[0098] The methods according to the above-described embodiments of the present invention may be embodied in the form of a program readable by various computer means and recorded on a computer-readable recording medium. Here, the recording medium may include program instructions, data files, data structures, and the like, alone or in combination. The program instructions recorded on the recording medium may be specially designed and constructed for the present invention, or may be well known and available to those skilled in the art of computer software. For example, recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, magneto-optical media such as floptical disks, and hardware devices specially configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine language code, such as that produced by a compiler, but also high-level language code that can be executed by a computer using an interpreter, etc. Such hardware devices may be configured to operate as one or more software modules to perform the operations of the present invention, or vice versa.

[0099] Although one embodiment of the present invention has been described above, a person having ordinary knowledge in the art may modify and change the present invention in various ways by adding, changing, deleting or adding components within the scope of the concept of the present invention as set forth in the claims, and this also falls within the scope of the present invention. [Explanation of symbols]

[0100] 100 User Device 200 Issuer Device 300 Verifier Device 400 VDR

Claims

1. a step in which a user device uploads a decentralized identification (DID) and a DID document to a verifiable data registry (VDR) to register the DID; The user device transmits the DID and requests issuance of a verifiable credential (VC) for the purchased ticket; an issuer device obtaining a DID document from the VDR via the DID; the issuer device interacting with the user device to authenticate ownership of the DID according to an authentication method included in the DID document; If the issuer device successfully authenticates the ownership of the DID, issuing a verifiable credential corresponding to the DID to the user device.

2. The DID document is The method for distributed identifier-based ticketing according to claim 1, further comprising: an authentication means and one or more authentication methods for proving ownership of the DID corresponding to the DID.

3. The step of authenticating ownership of the DID includes: The issuer device transmits encrypted data to authenticate the DID ownership according to the authentication method included in the DID document; the user device decrypting the data encrypted by the authentication method and returning the decrypted data; and the issuer device receives the decrypted data, thereby authenticating ownership of the DID.

4. The verifiable credential (VC) is Credential metadata including the issuer, expiration period, and disposal method of the verifiable credential; a claim containing the subject of the credential; and a proof item including a value for authenticating the verifiable credential. The method for distributed identity-based ticketing of claim 1, further comprising:

5. generating a verifiable presentation (VP) including the verifiable credential (VC) by the user device; providing the verifiable presentation to a verifier device by the user device; The verifier device obtains a DID document from the VDR via a DID of a verifiable credential included in a verifiable presentation; authenticating the verifiable presentation by the verifier device; If the verifiable presentation is successfully authenticated, the verifier device authenticating ownership of the DID according to an authentication method included in the DID document through interaction with the user device; 2. The method for distributed identifier-based ticketing according to claim 1, further comprising: if the ownership of the DID is successfully authenticated, authenticating the purchaser as a legitimate purchaser of the ticket.

6. authenticating the verifiable presentation, the verifier device authenticating a verifiable credential included in the verifiable presentation using a public key of the issuer of the verifiable presentation; If the verifier device successfully authenticates the verifiable credential, the verifier device authenticates the verifiable presentation using a public key of the owner of the verifiable presentation.

7. The step of authenticating ownership of the DID includes: transmitting encrypted data to authenticate the DID ownership according to the authentication method included in the DID document; the user device decrypting the data encrypted by the authentication method and returning the decrypted data; The method of claim 5, further comprising: the verifier device receiving the decrypted data and completing authentication.

8. The verifiable presentation (VP) is presentation metadata including data to reference for verifying the verifiable presentation; one or more verifiable credentials (VCs); and a proof item including a user's signature.

6. The method for distributed identity-based ticketing according to claim 5,

9. Upload the decentralized identification (DID) and DID documents to the Verifiable Data Registry (VDR) and register the DID; a user device transmitting the DID and requesting issuance of a verifiable credential (VC) for the purchased ticket; Obtaining a DID document from the VDR via the DID; authenticating ownership of the DID according to an authentication method included in the DID document through interaction with the user device; and an issuer device that issues a verifiable credential corresponding to the DID to the user device if the ownership of the DID is successfully authenticated.

10. The DID document is The system for distributed identifier-based ticketing according to claim 9, further comprising an authentication means and one or more authentication methods for proving ownership of the DID corresponding to the DID.

11. The issuer device Transmitting encrypted data to authenticate the DID ownership according to the authentication method included in the DID document; The system for distributed identifier-based ticketing of claim 9, wherein ownership of the DID is authenticated by receiving data from the user device that has been decrypted using the authentication method.

12. The verifiable credential (VC) is Credential metadata including the issuer, expiration period, and disposal method of the verifiable credential; a claim containing the subject of the credential; and a proof item including a value for authenticating the verifiable credential. The system for distributed identity-based ticketing of claim 9, further comprising:

13. The user device generating a verifiable presentation (VP) containing the verifiable credential (VC); providing the verifiable presentation to a verifier device; The verifier device Obtaining a DID document from the VDR via the DID of the verifiable credential included in the verifiable presentation; If the verifiable presentation is successfully authenticated, authenticating ownership of the DID according to an authentication method included in the DID document through interaction with the user device; 10. The system for distributed identifier-based ticketing according to claim 9, wherein if the ownership of the DID is successfully authenticated, the purchaser is authenticated as a legitimate purchaser of the ticket.

14. The verifier device authenticating a verifiable credential included in the verifiable presentation using the public key of the issuer of the verifiable presentation; 14. The system for distributed identity-based ticketing of claim 13, wherein if the verifiable credential is successfully authenticated, the verifiable presentation is authenticated using a public key of the owner of the verifiable presentation.

15. The step of authenticating ownership of the DID includes: The verifier device transmits encrypted data to authenticate the DID ownership according to the authentication method included in the DID document; The system for distributed identifier-based ticketing of claim 13, wherein the system receives decrypted data obtained by decrypting encrypted data from the user device and completes authentication.

16. The verifiable presentation (VP) is presentation metadata including data to reference for verifying the verifiable presentation; one or more verifiable credentials (VCs); and a proof item including a user's signature. The system for distributed identifier-based ticketing of claim 13,

Images