A system and method for ticketing on a distributed identifier infrastructure.

Abstract

This invention provides a system and method for ticketing on a decentralized identifier infrastructure. [Solution] A method for ticketing on a distributed identifier infrastructure includes the steps of: a user device uploading a DID (decentralized identification) and a DID document to a VDR (Verifiable Data Registry) and registering the DID; a user device transmitting the DID and requesting the issuance of verifiable credentials (VC) for the purchased ticket; an issuer device obtaining a DID document from the VDR via the DID; an issuer device authenticating ownership of the DID through interaction with the user device using an authentication method included in the DID document; and, if the issuer device successfully authenticates ownership of the DID, issuing verifiable credentials corresponding to the DID to the user device.

Description

Technical Field

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

[0002] The present invention is derived from research conducted as part of the "Advancement and Commercialization of IP for the Promotion of the Commercialization of Metaverse International Standard Technology" project (Project Implementing Agency: Myongji University Industry-Academia Cooperation Foundation; Project Number: RS-2024-00424718) as part of the support for the activation of industry-university cooperation by the Ministry of Science and ICT of Korea.

Background Art

[0003] Traditional media content such as plays, operas, concerts, and sports has continuously received the attention of many people. In particular, ticketing competition for performances by singers or bands with a large fandom like K-POP or competitions of sports stars or teams is fierce. As a result, negative effects such as illegal ticket sales have increased, becoming elements that interfere with healthy culture and sports viewing. Means to prevent such negative effects are required.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] An object of the present invention is to provide a system for ticketing based on a decentralized identifier and a method therefor.

Means for Solving the Problems

[0006] A preferred embodiment of the present invention for ticketing a distributed identifier infrastructure, for achieving the aforementioned objectives, includes the steps of: a user device uploading a DID (decentralized identification) and a DID document to a VDR (Verifiable Data Registry) and registering the DID; the user device transmitting the DID and requesting the issuance of verifiable credentials (VC) for the purchased ticket; an issuer device obtaining a DID document from the VDR via the DID; the issuer device authenticating ownership of the DID by an authentication method included in the DID document through interaction with the user device; and, if the issuer device has successfully authenticated ownership of the DID, issuing verifiable credentials corresponding to the DID to the user device.

[0007] The DID document is characterized by including authentication means and one or more authentication methods for proving ownership of the DID in accordance with the DID.

[0008] The step of authenticating ownership of the DID includes the steps of: the issuing device transmitting encrypted data so as to authenticate ownership of the DID by an 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 issuing device authenticating ownership of the DID by receiving the decrypted data.

[0009] The aforementioned verifiable credential (VC) includes credential metadata, which includes the issuer, expiration date, and disposal method of the verifiable credential; a claim, which includes the entity granting the credentials; and a proof, which includes a value for authenticating the verifiable credential.

[0010] The steps include: the user device generating a verifiable presentation (VP) containing the verifiable credential (VC); the user device providing the verifiable presentation to the 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; if the authentication of the verifiable presentation is successful, the verifier device authenticating ownership of the DID by 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, the verifier device authenticating the user device as a legitimate purchaser of the ticket.

[0011] The step of authenticating the verifiable presentation includes the step of the verifier device authenticating the verifiable credentials included in the verifiable presentation using the public key of the issuer of the verifiable presentation, and, if the verifier device has succeeded in authenticating the verifiable credentials, the step of the verifier device authenticating the verifiable presentation using the public key of the holder of the verifiable presentation.

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

[0013] The verifiable presentation (VP) includes presentation metadata containing data to reference in order to verify the verifiable presentation, one or more verifiable credentials (VC), and a Proof field containing the user's signature.

[0014] A system for ticketing a distributed identifier-based infrastructure according to a preferred embodiment of the present invention for achieving the aforementioned objectives includes: a user device that uploads a DID (decentralized identification) and a DID document to a VDR (Verifiable Data Registry), registers the DID; transmits the DID and requests the issuance of a verifiable credential (VC) for a purchased ticket; and an issuer device that obtains a DID document from the VDR via the DID, authenticates ownership of the DID by an authentication method contained in the DID document through interaction with the user device, and, if successful in authenticating ownership of the DID, issues a verifiable credential corresponding to the DID to the user device.

[0015] The DID document is characterized by including authentication means and one or more authentication methods for proving ownership of the DID in accordance with the DID.

[0016] The issuer device authenticates ownership of the DID by transmitting encrypted data to authenticate DID ownership using an authentication method included in the DID document, and by receiving decrypted data from the user device.

[0017] The aforementioned verifiable credential (VC) includes credential metadata, which includes the issuer, expiration date, and disposal method of the verifiable credential; a claim, which includes the entity granting the credentials; and a proof item, which includes a value for authenticating the verifiable credential.

[0018] The user device generates a verifiable presentation (VP) containing the verifiable credential (VC), provides the verifiable presentation to the verifier device, 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 authentication of the verifiable presentation is successful, it authenticates ownership of the DID by the authentication method included in the DID document through interaction with the user device, and if the authentication of ownership of the DID is successful, it authenticates the user device as a legitimate purchaser of the ticket.

[0019] The verifier device is characterized by authenticating the verifiable credentials included in the verifiable presentation using the public key of the publisher of the verifiable presentation, and if the authentication of the verifiable credentials is successful, authenticating the verifiable presentation using the public key of the holder of the verifiable presentation.

[0020] The step of authenticating ownership of the DID is characterized by the verifier device transmitting encrypted data to authenticate ownership of the DID using the authentication method included in the DID document, receiving decrypted data from the user device, and completing the authentication.

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

Advantages of the Invention

[0022] According to the present invention, by issuing and verifying tickets via decentralized identifiers (DIDs), verifiable credentials (VCs), and verifiable presentations (VPs), only the purchaser who purchases the first ticket can become a legitimate right holder, and adverse effects such as illegal ticket sales can be prevented in advance.

Brief Description of the Drawings

[0023] [Figure 1] It is a diagram for explaining the configuration of a system for decentralized identifier-based ticketing according to an embodiment of the present invention. [Figure 2] It is a diagram for explaining a method of registering a decentralized identifier (DID) according to an embodiment of the present invention. [Figure 3] It is a diagram for explaining the configuration of a decentralized identifier (DID) according to an embodiment of the present invention. [Figure 4] It is a diagram for explaining the configuration of a decentralized identifier (DID) document according to an embodiment of the present invention. [Figure 5] It is a flowchart for explaining a method for authenticating the ownership of a DID according to an embodiment of the present invention. [Figure 6] It is a flowchart for explaining a method for authenticating the ownership of a DID according to another embodiment of the present invention. [Figure 7]This figure illustrates the structure of a verifiable credential (VC) and a verifiable presentation (VP) according to embodiments of the present invention. [Figure 8] This is a diagram illustrating a verifiable credential (VC) according to one embodiment of the present invention. [Figure 9] This is a flowchart illustrating a method for ticketing a distributed identifier infrastructure according to an embodiment of the present invention. [Figure 10] This is a flowchart illustrating a method for ticketing a distributed identifier infrastructure according to an embodiment of the present invention. [Figure 11] This figure illustrates a method for generating a verifiable presentation VP from a verifiable credential VC according to an embodiment of the present invention. [Figure 12] This figure shows a computing device according to an embodiment of the present invention. [Modes for carrying out the invention]

[0024] While the present invention can be subjected to various transformations and has many different embodiments, specific embodiments are illustrated and described in detail in the detailed description. However, this should be understood not as limiting the present invention to specific embodiments, but as including all transformations, equivalents, and substitutes that fall within the spirit and technical scope of the present invention. Furthermore, wherever any part of the specification "includes" a certain component, this does not mean that other components are excluded, but rather that other components may be further included, unless otherwise stated.

[0025] The terms used in this invention are used solely to describe specific embodiments and are not intended to limit the invention. A singular expression includes plural expressions unless the context clearly distinguishes them. In this invention, terms such as "includes" or "has" are intended to specify the presence of features, figures, stages, operations, components, parts, or combinations thereof as described in the specification, and should be understood not to preemptively exclude the presence or possibility of adding one or more other features, figures, stages, operations, components, parts, or combinations thereof.

[0026] In particular, the terms and words used in this specification and claims as described below should not be interpreted as being limited to their ordinary or dictionary meanings, but rather as meanings and concepts that are consistent with the technical idea of ​​the present invention, based on the principle that inventors may appropriately define the concepts of terms in order to best describe their invention.

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

[0028] Referring to Figure 1, the 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 VDR (Verifiable Data Registry) 400.

[0029] User device 100 is a device used by a user who purchases a ticket. User device 100 can perform computing operations and communicate via a network or direct connection between devices. Typically, user device 100 can be exemplified by a smartphone.

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

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

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

[0033] Next, a decentralized identifier (DID) according to an embodiment of the present invention will be described. Figure 2 is a diagram illustrating a method for registering a decentralized identifier (DID) according to an embodiment of the present invention. Figure 3 is a diagram illustrating the structure of a decentralized identifier (DID) according to an embodiment of the present invention. Figure 4 is a diagram illustrating the structure of a decentralized identifier (DID) document according to an embodiment of the present invention.

[0034] Referring to Figure 2, the user device 100 generates a DID and a DID document (DID document) that proves it 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 VDR400. The DID document includes authentication means (e.g., a public key) and authentication methods to prove ownership of the DID. When proof of ownership of the DID is requested, the DID application can refer to the DID document via the location information of the DID document stored in the DID location (e.g., blockchain) within the VDR400.

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

[0036] For example, a DID like "did:btcr:xyv2-xzpq-q9wa-p7t" may be generated. This indicates that the DID was generated based on the Bitcoin blockchain via 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 like "did:sov:mnjkl98uipsndg2hdjdjuf7" may 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 UUID (Universally Unique IDentifier) ​​or the user's public key.

[0038] Referring to Figure 4, a DID document includes authentication means that can prove ownership of the DID. The main components of a DID document include context, identifier (ID), public key, authentication, and service.

[0039] The `@context` field defines the meaning and data contained within the identifier (id), authentication (authentication), and service (service) fields in a DID document. The `@context` field is created using the JSON-LD syntax.

[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; 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) field.

[0041] The public key contains information used to authenticate DID ownership. Specifically, the public key includes 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 authentication authority over "publicKeyPem". For example, the DID on line 7 (line 7 in Figure 4) indicates the DID of the person who possesses the private key (secret key) paired with the public key on line 8 in the case of Ethereum-based RSA asymmetric key authentication. "publicKeyPem" indicates the data used to authenticate DID ownership. For example, line 8 indicates the public key required for asymmetric authentication.

[0043] Authentication includes the ownership authentication method provided in the DID document. User device 100 can authenticate DID ownership by selecting one of the three methods from lines 21 to 23.

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

[0045] In Figure 5, which represents one embodiment, the authentication agency VA may be the issuer device 200 or the verifier device 300. Referring to Figure 5, it is assumed that the user device 100 has uploaded the user's DID and DID document to the VDR400 through user operation and that the DID has been registered.

[0046] Upon receiving the DID from the user device 100, the authentication agency VA, in step S110, asks the user device 100 to refer to the authentication field of the DID document and select an authentication method (1).

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

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

[0049] Next, the authentication agency VA provides the user device 100 with encrypted verification data at the S150 stage (5).

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

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

[0052] In Figure 6, which represents another embodiment, the issuing agency IA may be the issuing device 200, and the authentication agency VA may be the verifying 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] At step S210, the user device 100 can provide the authentication agency VA with the identifier of the issuing agency IA and the user's DID (1).

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

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

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

[0057] Next, verifiable credentials (VC) and verifiable presentations (VP) according to embodiments of the present invention will be described. Figure 7 is a diagram illustrating the structure of verifiable credentials (VC) and verifiable presentations (VP) according to embodiments of the present invention. Figure 8 is a diagram illustrating verifiable credentials (VC) according to one embodiment of the present invention.

[0058] Referring to Figure 7, a verifiable credential VC includes credential metadata, claims, and proof items.

[0059] Credential metadata includes the issuer of verifiable credentials, expiration date, and disposal method. Claims are information about the identity attributes of the credentialing entity and are stored in entity-attribute-value format. That is, Claims include information related to the credentialing entity referenced by the VC. Proofs include values ​​for authenticating verifiable credentials. These may include various encryption technologies such as RSA, ECDSA, and biometric authentication. In particular, Proofs include the signature of the VC issuer.

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

[0061] The `@context` attribute defines the value of the data. The `https: / / www.w3.org / 2018 / credentials / v1` on line 3 must be included as the official VC context. The `https: / / www.example.edu / context` on line 4 is a context that is directly generated and inserted when additional context is needed for a service under development.

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

[0063] In terms of format (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, while "KoreanUniversityCredentia" means that the data required for the graduation certificate is generated using the data structure defined in the self-generation context.

[0064] The issuer indicates the person or organization that issued the VC. The issue date (validFrom) defines when the VC is valid. The expiration date (validUntil) defines the period during which the VC is valid. The credentialSubject is the item containing the claim data. The credentialSchema can define a scheme for specific attributes of a claim or VC. Through this, non-essential attributes of a VC can be restricted to essential attributes.

[0065] The credential status indicates the status of the certification (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 the intended purpose. "VerificationMethod" on line 23 is the address (url) where the public key is stored. "created" is the time the proof was generated. "proof Value" contains the value of the digital signature binary data encoded.

[0067] Furthermore, referring to Figure 7, a verifiable presentation (VP) includes presentation metadata, one or more verifiable credential VCs and proof(s) items, etc.

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

[0069] Verifiable credential VCs allow the verifier to selectively include the necessary ID attributes from the claims within the VC and the VCs that possess those necessary ID attributes. This enables the protection of personal information.

[0070] The Proof(s) field in a VP includes the user's signature. Compared to a VC, the Proof(s) field in a VC includes the issuer's signature. Various cryptographic techniques can be used through Proof(s).

[0071] Next, a method for ticketing a distributed identifier infrastructure according to an embodiment of the present invention will be described. Figures 9 and 10 are flowcharts illustrating a method for ticketing a distributed identifier infrastructure 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 embodiments shown in Figures 9 to 11, the user of the user device 100 may be a ticket purchaser, 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] First, referring to Figure 9, we assume that the user device 100 has uploaded a DID (decentralized identification) and a DID document to the VDR400 and registered the DID. The DID document includes an authentication means and one or more authentication methods to prove ownership of the DID in accordance with the DID.

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

[0075] Next, in step S330, the issuer device 200 transmits the DID to the VDR400 to request the DID document, and in step S340, it obtains the DID document from the VDR400 (3).

[0076] Next, the issuer device 200 proceeds with the authentication procedure for ownership of the DID through interaction with the user device 100 using the authentication method included in the DID document.

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

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

[0079] The issuer device 200 can receive this decrypted data, thereby authenticating ownership of the DID.

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

[0081] Here, a verifiable credential (VC) includes credential metadata, which includes the issuer, expiration date, and disposal method of the verifiable credential; a claim, which includes the entity providing the credentials; and a proof item, which includes a value for authenticating the verifiable credential.

[0082] Referring to Figure 10, the user device 100 has received a verifiable credential VC based on the DID, as described in Figure 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 enters the user's signature in step S410 and generates a verifiable presentation VP that includes a verifiable credential VC (1). In this case, according to an additional embodiment, if multiple (e.g., three) verifiable credential VCs are issued, one verifiable presentation VP can be generated that includes multiple (e.g., three) verifiable credential VCs.

[0084] A verifiable presentation (VP) includes presentation metadata containing data to reference in order to verify the verifiable presentation, one or more verifiable credentials (VC), and a Proof field containing the user's signature.

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

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

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

[0088] If the authentication of the verifiable presentation VP is successful, the verifier device 300 can authenticate ownership of the DID by the authentication method contained in the DID document through interaction with the user device 100 at step S470 (5). Specifically, the verifier device 300 can request the user device 100 to authenticate ownership of the DID by the authentication method contained in the DID document. In this case, the user device 100 can authenticate ownership of the DID by returning authentication data to the issuer device 200 by the authentication method.

[0089] According to one embodiment, the verifier device 300 can transmit encrypted data to the user device 100 if the authentication method included in the DID document is asymmetric key authentication. This allows the user device 100 to decrypt the encrypted data and then return the decrypted data to the issuer device 200 for authentication. As a specific example of step S470, the ticket inspector can use a mobile phone, i.e., the camera or fingerprint recognition device of the verifier device 300, to obtain the user's facial image, fingerprint information, or the user's private key according to the authentication method of the DID registered in the ticket VP, and authenticate ownership of the DID.

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

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

[0092] Figure 12 shows a computing device according to an embodiment of the present invention. The computing device TN100 in Figure 12 may be the devices described herein, namely the user device 100, the issuer device 200, the verifier device 300, and the VDR400, etc.

[0093] In the embodiment shown in Figure 12, the computing device TN100 may include at least one processor TN110, a transceiver TN120, and a memory TN130. The computing device TN100 may further include a storage device TN140, an input interface device TN150, an output interface device TN160, and the like. The components included in the 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 the methods according to embodiments of the present invention are performed. The processor TN110 may be configured to embody the procedures, functions, and methods described in connection with embodiments of the present invention. The processor TN110 can control the components of the computing device TN100.

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

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

[0097] In particular, various functions according to embodiments of the present invention, such as the user device 100, issuer device 200, verifier device 300, and VDR400, can be embodied in a program format readable via computer means, stored in memory TN130, and executed by processor TN110. Alternatively, various functions such as the user device 100, issuer device 200, verifier device 300, and VDR400 can be performed in a lower module of processor TN110.

[0098] The methods according to the embodiments of the present invention described above can be embodied in a program format readable via various computer means and recorded on a computer-readable recording medium. Here, the recording medium may include program instructions, data files, data structures, etc., individually or in combination. The program instructions recorded on the recording medium may be specially designed and configured for the present invention, or they may be publicly known and usable by those skilled in the field of computer software. For example, the recording medium includes 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, and flash memory. Examples of program instructions may include not only machine code created by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like. Such hardware devices may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

[0099] Although one embodiment of the present invention has been described above, a person with ordinary skill in the art can modify and change the present invention in various ways by adding, changing, deleting, or adding components, etc., without departing from the spirit of the invention as described in the claims, and this can also be said to be within the scope of the rights of the present invention. [Explanation of symbols]

[0100] 100 User Devices 200 Issuer device 300 Verifier Devices 400 VDR

Claims

1. The user device uploads the DID (decentralized identification) and DID document to the VDR (Verifiable Data Register) and registers the DID. The user device transmits the DID and requests the issuance of verifiable credentials (VC) for the purchased ticket, The issuing device obtains the DID document from the VDR via the DID, The steps include: the issuing device authenticating ownership of the DID by an authentication method included in the DID document through interaction with the user device; A method for ticketing on a distributed identifier infrastructure, comprising the step of issuing verifiable credentials corresponding to the DID to the user device if the issuer device successfully authenticates ownership of the DID.

2. The aforementioned DID document is The method for ticketing a distributed identifier infrastructure according to claim 1, comprising authentication means and one or more authentication methods for proving ownership of a DID in accordance with the DID.

3. The step of authenticating ownership of the aforementioned DID is: The steps include: transmitting encrypted data so that the issuing device authenticates DID ownership using the authentication method included in the DID document; The user device decrypts the encrypted data using the authentication method and returns the decrypted data. A method for ticketing a distributed identifier infrastructure according to claim 1, comprising the step of authenticating ownership of the DID by the issuer device receiving the decrypted data.

4. The aforementioned verifiable credentials (VC) are: Credential metadata including the issuer of verifiable credentials, expiration date, and disposal method, A claim that includes the entity providing the certification, A method for ticketing a distributed identifier infrastructure according to claim 1, comprising: a Proof item containing a value for authenticating verifiable credentials.

5. The user device generates a verifiable presentation (VP) that includes the verifiable credentials (VC), The user device provides the verifiable presentation to the verifier device, The step of the verifier device obtaining a DID document from the VDR via the DID of verifiable credentials included in the verifiable presentation, The step of the verifier device authenticating a verifiable presentation, If the authentication of the verifiable presentation is successful, The steps include: the verification device authenticating ownership of the DID through interaction with the user device using an authentication method included in the DID document; The method for ticketing on a decentralized identifier infrastructure according to claim 1, further comprising the step of authenticating the legitimate purchaser of the ticket if the ownership of the DID is successfully authenticated.

6. The step of authenticating the aforementioned verifiable presentation is: The verifier device authenticates the verifiable credentials included in the verifiable presentation using the public key of the publisher of the verifiable presentation, The method for ticketing a distributed identifier infrastructure according to claim 5, further comprising the step of: if the verifier device successfully authenticates the verifiable credentials, the verifier device authenticates the verifiable presentation using the public key of the holder of the verifiable presentation.

7. The step of authenticating ownership of the aforementioned DID is: The steps include transmitting encrypted data to authenticate DID ownership using the authentication method included in the DID document, The user device decrypts the encrypted data using the authentication method and returns the decrypted data. The method for ticketing a distributed identifier infrastructure according to claim 5, further comprising the step of the verifier device receiving the decrypted data and completing authentication.

8. The aforementioned verifiable presentation (VP) is, Presentation metadata containing data to reference in order to verify a verifiable presentation, One or more verifiable credentials (VC), A method for ticketing a distributed identifier infrastructure according to claim 5, comprising a proof item including a user's signature.

9. Upload the DID (Decentralized Identification) and DID document to the VDR (Verifiable Data Register) and register the DID. A user device that transmits the aforementioned DID and requests the issuance of verifiable credentials (VC) for the purchased ticket, The DID document is obtained from the VDR via the DID, The user device interacts with the DID to authenticate ownership of the DID using the authentication method included in the DID document. A system for ticketing on a distributed identifier infrastructure, comprising: an issuer device that, upon successful authentication of ownership of the DID, issues verifiable credentials corresponding to the DID to the user device.

10. The aforementioned DID document is The system for ticketing a distributed identifier infrastructure according to claim 9, comprising authentication means and one or more authentication methods for proving ownership of a DID in accordance with the DID.

11. The aforementioned issuer device is The encrypted data is transmitted to authenticate DID ownership using the authentication method included in the aforementioned DID document. The system for ticketing a distributed identifier infrastructure according to claim 9, characterized in that ownership of the DID is authenticated by receiving data decrypted from the user device using the authentication method.

12. The aforementioned verifiable credentials (VC) are: Credential metadata including the issuer of verifiable credentials, expiration date, and disposal method, A claim that includes the entity providing the certification, A system for ticketing a distributed identifier infrastructure according to claim 9, comprising: a Proof item containing a value for authenticating verifiable credentials.

13. The User device is A verifiable presentation (VP) containing the aforementioned verifiable credentials (VC) is generated. Provide the verifiable presentation to the verifier device, The aforementioned verifier device is The DID document is obtained from the VDR via the DID of verifiable credentials included in the verifiable presentation, If the authentication of the verifiable presentation is successful, The ownership of the DID is authenticated by the authentication method contained in the DID document through interaction with the user device, The system for ticketing on a decentralized identifier basis according to claim 9, characterized in that if the ownership of the DID is successfully authenticated, the user is authenticated as a legitimate purchaser of the ticket.

14. The aforementioned verifier device is The verifiable credentials included in the verifiable presentation are authenticated using the public key of the publisher of the verifiable presentation. The system for ticketing on a decentralized identifier infrastructure according to claim 13, characterized in that, upon successful authentication of verifiable credentials, the verifiable presentation is authenticated using the public key of the holder of the verifiable presentation.

15. The step of authenticating ownership of the aforementioned DID is: The verifier device transmits encrypted data to authenticate DID ownership using the authentication method included in the DID document. The system for ticketing on a distributed identifier infrastructure according to claim 13, characterized in that it receives decrypted data obtained by decrypting encrypted data from the user device and completes authentication.

16. The aforementioned verifiable presentation (VP) is, Presentation metadata containing data to reference in order to verify a verifiable presentation, One or more verifiable credentials (VC), A system for ticketing a distributed identifier infrastructure according to claim 13, comprising a Proof item including a user's signature.

Images