Airline ticket business management system and airline ticket business management method based on Web5 architecture

Abstract

The invention discloses an air ticket management system and an air ticket management method based on a Web5 architecture, and relates to the field of air ticket management, a storage layer of the air ticket management system comprises a plurality of local decentralized network nodes DWN and a public relay node, a passenger DWN stores a complete ciphertext of an air ticket verifiable voucher, and the public relay node stores the complete ciphertext of the air ticket verifiable voucher; the airline DWN node is used for storing a hash value of an air ticket verifiable certificate, a state identifier and access strategy metadata authorized by a passenger, and the airport DWN node and other third-party DWN nodes are used for storing the hash value of the air ticket verifiable certificate authorized by the passenger, a pre-generated verification key and an authority time window. And different local DWN nodes directly establish connection by analyzing the DWN service end point identified by the opposite node. According to the invention, a technical problem that a passenger data leakage risk is easily caused by adopting a centralized management strategy in an air ticket business management process in related technologies is solved.

Description

Technical Field

[0001] This invention relates to the field of airline ticketing management technology or other related fields. Specifically, it relates to an airline ticketing management system and method based on Web5 architecture. Background Technology

[0002] The current airline ticketing system is primarily based on a centralized architecture, where passenger data is controlled by a centralized database managed by the airline. While this supports the airline's operational needs to some extent, it has significant shortcomings. In the existing system, airlines centrally control passengers' personal information and travel data. This centralized data management approach not only makes airlines a major risk point for data breaches, but also prevents passengers from making their own decisions about how their data is used and shared. Furthermore, the lack of unified data exchange and verification standards between different airlines means that passengers must repeatedly provide personal information and flight details during multiple journeys (especially during layovers). This process is not only cumbersome, but also increases the risk of data breaches due to the transfer of data between different systems.

[0003] In recent years, blockchain technology and decentralized identifiers have been adopted to replace centralized data architectures, particularly in improving data security, enhancing privacy, and improving passenger experience. However, the practical application of these technologies still faces certain limitations: directly storing large amounts of verifiable credentials or their hashes on the blockchain is constrained by blockchain performance, resulting in issues such as low transaction throughput, high block confirmation latency, and high storage costs, which is unacceptable for the aviation industry, which requires frequent access and verification. Furthermore, while decentralized identifiers allow passengers to have their own digital identities, in practice, the validity and status of verifiable credentials still heavily rely on records and smart contracts on the blockchain.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This invention provides an airline ticketing management system and method based on Web5 architecture, to at least solve the technical problem that centralized management strategies in airline ticketing management can easily lead to the risk of passenger data leakage in related technologies.

[0006] According to one aspect of the present invention, an airline ticketing management system based on a Web5 architecture is provided. The storage layer of the airline ticketing management system includes: multiple local decentralized network nodes (DWN nodes) and public relay nodes. The multiple local decentralized network nodes (DWN nodes) include: passenger DWN nodes, airline DWN nodes, airport DWN nodes, and other third-party DWN nodes. The passenger DWN nodes are used to store the complete encrypted text of the verifiable ticket credential and support offline access. The complete encrypted text includes: flight information, refund and change records, access permission policies, and operation audit logs. The airline DWN nodes are used to store the verifiable ticket credential. The system stores the hash value, status identifier, and metadata of the passenger-authorized access policy; the airport DWN node and other third-party DWN nodes are used to store the hash value of the passenger-authorized verifiable ticket credential, the pre-generated verification key, and the permission time window; the public relay node is pre-connected to multiple local DWN nodes and is used to save the data to be synchronized when the local DWN nodes are offline through an offline data storage and synchronization mechanism; the public relay node is also used to provide identifier resolution services for multiple local DWN nodes, and different local DWN nodes can directly establish connections by resolving the DWN service endpoint of the other node's identifier to complete the decentralized interaction across entities.

[0007] Optionally, the airline DWN node further includes a message update module, which is used to automatically generate a status update message when a ticket is refunded or changed, and synchronously push the refund or change message to all authorized associated nodes.

[0008] Optionally, the airline ticketing management system further includes an identity layer, which comprises: an identity identifier library storing multiple passenger identity identifier documents and key pairs, wherein the identity identifier document stores the passenger's identity identifier generated by the Web5 wallet, the passenger's public key, and the DWN server endpoint, and the passenger's private key in the key pair is securely stored in a key vault within the identity management execution unit; and a ticket verifiable credential library storing ticket verifiable credentials signed using an asymmetric algorithm, wherein the data fields of the ticket verifiable credential include: digital signature, issuer, validity period, passenger identity identifier, and hash value of flight information.

[0009] Optionally, the Web5 wallet on the passenger side includes at least: an identity storage module for storing the passenger's identity; a ticket verification credential storage module for storing the passenger's ticket verification credential; and an identity management executor for managing the passenger's keys.

[0010] Optionally, the identity management execution unit includes: a key repository for storing and managing passengers' private keys, which are used to generate decentralized identifiers and sign and encrypt ticket verifiable credentials; an identifier parser for parsing the identity identifier document; and a verifiable credential processor for receiving ticket verifiable credentials and, if the issuer, validity period, and credential status of the ticket verifiable credentials are verified, storing the ticket verifiable credentials in a local or decentralized storage system; wherein, the verifiable credential processor also supports generating proof documents using zero-knowledge proof strategies, and using the proof documents to complete the validity verification of the ticket verifiable credentials.

[0011] Optionally, the airline ticketing management system further includes a verification layer, which comprises: a verification request initiation module, which sends a structured verification request to the identity management execution entity on the passenger side via a decentralized application (DWA), the structured verification request including the request type, the hash value of the target flight number, and the identity identifier of the verifier; a request preprocessing module, which decrypts the complete ciphertext of the stored verifiable ticket credential using a local private key; utilizes the identity management execution entity to call a zero-knowledge proof engine to load a preset zero-knowledge proof circuit, and verifies whether the hash value of the local flight number matches the hash value of the target flight number in the structured verification request; and a proof document generation module, used to generate a verification result indicating the hash value. In the case of a match, the target parameters are input into the zero-knowledge proof circuit, and the zero-knowledge proof engine generates a proof file. The target parameters include: the airline's public key, validity period, hash value of the local flight number, and credential status identifier. The zero-knowledge proof circuit has pre-integrated signature verification logic and credential status validity check logic. The proof transmission module is used to transmit the generated proof file to the verifier through a secure channel. The proof verification module is used to query the hash status of the ticket verifiable credential from the airline's DWN node to confirm that the ticket verifiable credential has not been revoked, and to verify the validity of the proof file using the airline's public key. After all verifications pass, the passenger is confirmed to meet the conditions, and the trusted verification is completed.

[0012] Optionally, the airline ticketing management system also includes an application layer, which includes: a ticketing module, where after passengers complete flight selection and payment through the airline's decentralized application, the airline's identity authorization module issues a verifiable ticket credential in a specified format using a private key, pushes the encrypted verifiable ticket credential to the passenger's DWN node for storage through the airline's DWN node, and synchronizes the hash value of the verifiable ticket credential to the airport's DWN node; an authorization module, where passengers configure an authorized access policy, which is then signed with the passenger's private key and pushed to the verifier's DWN node, which verifies the signature and stores it, wherein the verifier's nodes include: airport DWN nodes and third-party DWN nodes; a verification module, where when a passenger's DWN node initiates a verification request, it returns a proof file or temporary token generated by a zero-knowledge proof engine to the verifier, who then completes real-time verification using the proof file or temporary token; and an auditing module, which audits the access operations in the operation audit log, wherein all access operations of the verifiable ticket credential in the passenger's DWN node are fully recorded in the operation audit log.

[0013] According to another aspect of the present invention, a Web5-based airline ticket verification method is also provided, applied to the passenger-side identity management execution unit in the Web5-based airline ticket management system described in any one of the above embodiments. The Web5-based airline ticket verification method includes: receiving a structured verification request sent by a verifier through a decentralized application (DWA), wherein the structured verification request includes a request type, a hash value of the target flight number, and the verifier's identity identifier; decrypting the complete ciphertext of a stored verifiable ticket credential based on a local private key, wherein the complete ciphertext includes at least: flight information, the flight information including at least a local flight number and a hash value of the local flight number; and invoking a zero-knowledge proof engine to load a preset zero-knowledge proof circuit and verifying the local... The system checks whether the hash value of the flight number matches the hash value of the target flight number in the structured verification request. If the verification result indicates a hash value match, the target parameters are input into the zero-knowledge proof circuit, and the zero-knowledge proof engine is used to generate a proof file. The target parameters include: the airline's public key, validity period, hash value of the local flight number, and credential status identifier. The zero-knowledge proof circuit has pre-integrated signature verification logic and credential status validity period check logic. The generated proof file is transmitted to the verifier through a secure channel. The verifier queries the airline's DWN node for the hash status of the ticket verifiable credential to confirm that the ticket verifiable credential has not been revoked, and uses the airline's public key to verify the validity of the proof file. After all verifications pass, the passenger is confirmed to meet the conditions, and the trusted verification is completed.

[0014] Optionally, the supporting documents include at least one of the following: whether the airline signature is valid, whether the current time is within the validity period, whether the flight number matches, and whether the credential status of the ticket verification credential is valid.

[0015] Optionally, it further includes: after initiating a ticket credential request to the airline's decentralized network application, receiving the ticket verifiable credential returned by the airline's decentralized network application, wherein the ticket credential request is a credential acquisition request initiated by the passenger after completing flight selection and payment through the airline's decentralized application; receiving the ticket verifiable credential in a specified format issued by the airline's identity authorization module using a private key after the passenger completes flight selection and payment through the airline's decentralized application; storing the ticket verifiable credential in a verification credential processor; and synchronizing the hash value of the ticket verifiable credential to the airport DWN node.

[0016] Optionally, the system further includes: during check-in for the first flight, the passenger generates a temporary authorization credential through the identity management execution entity, authorizing the transit airline's DWN node to access the reserved baggage-related fields and the transit flight fields, thereby obtaining the temporary authorization credential; the first-flight airline's DWN node sends an encrypted baggage information fragment to the transit airline's DWN node; the transit airline's DWN node uses the temporary authorization credential to decrypt the data and generate a baggage zero-knowledge proof document; if the baggage zero-knowledge proof document is verified, the baggage is automatically checked through; if the passenger's baggage status is updated, the transit airline's DWN node pushes the status hash to the passenger's DWN node.

[0017] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to execute the above-described Web5-based airline ticketing verification method.

[0018] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the Web5-based airline ticket verification method described above.

[0019] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the above-described Web5-based airline ticketing verification method.

[0020] In this disclosure, the storage layer of the airline ticketing management system includes: multiple local decentralized network (DWN) nodes and public relay nodes. The multiple local DWN nodes include: passenger DWN nodes, airline DWN nodes, airport DWN nodes, and other third-party DWN nodes. The passenger DWN nodes store the complete encrypted text of the verifiable ticket credential and support offline access. The complete encrypted text includes: flight information, refund and change records, access permission policies, and operation audit logs. The airline DWN nodes store the hash value, status identifier, and passenger-authorized access permissions of the verifiable ticket credential. The system queries policy metadata; airport DWN nodes and other third-party DWN nodes are used to store the hash value of the verifiable credential for passenger-authorized tickets, pre-generated verification keys, and permission time windows; public relay nodes are pre-established with multiple local DWN nodes to save data to be synchronized when local DWN nodes are offline through offline data storage and synchronization mechanisms; among them, public relay nodes are also used to provide identifier resolution services for multiple local DWN nodes, and different local DWN nodes can directly establish connections by resolving the DWN service endpoint of each other's node identifiers to complete decentralized cross-entity interaction.

[0021] In this disclosure, a local DWN node is used to ensure users' autonomous control and management of their personal data, including data storage location, access permission policies, and auditing of data usage. This greatly enhances passengers' control over their personal data. Through a zero-knowledge proof engine, the verifier can complete the verification of credential validity without accessing the original sensitive data. This improves verification efficiency and protects user privacy, achieving a secure verification mode of "data usable but not visible." This solves the technical problem in related technologies where centralized management strategies in airline ticketing management can easily lead to the risk of passenger data leakage. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings: Figure 1 This is a schematic diagram of an optional web5-based distributed storage system for verifiable ticket credentials according to an embodiment of the present invention. Figure 2 This is a schematic diagram illustrating the interaction between optional local DWN nodes according to an embodiment of the present invention; Figure 3 This is a schematic diagram of an optional data verification process according to an embodiment of the present invention; Figure 4 This is a flowchart of an optional airline ticket verification method based on a Web5 architecture according to an embodiment of the present invention; Figure 5 This is a hardware structure block diagram of an electronic device (or mobile device) that performs an airline ticketing verification method based on a Web5 architecture according to an embodiment of the present invention. Detailed Implementation

[0023] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0024] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0025] To facilitate understanding of the present invention by those skilled in the art, some terms or nouns involved in the various embodiments of the present invention are explained below: A Flight Verifiable Credential (FVC) is a digital credential conforming to the W3C VC standard for use in air travel. It contains the passenger's DID, a hash of flight information, and the airline's digital signature. It supports zero-knowledge proof technology, allowing passengers to selectively disclose information to the verifier without revealing sensitive details.

[0026] Decentralized Web Node (DWN) is a personal data storage and interaction node built on DID (Data Identity). Each DWN allows users to have complete control over their data, including storage location and access permissions, and establishes connections with other entities through DID resolution, thus achieving decentralized data management.

[0027] Decentralized Web Applications (DWAs) are applications built on the Web5 architecture. Through DWN nodes, users can autonomously store and manage data, using standardized protocols to ensure control over identity and data, while providing secure data exchange capabilities. They offer secure and private data exchange capabilities under the protection of encryption technology and a distributed architecture, and also support seamless cross-application interaction.

[0028] Web5 Architecture, or Web5 for short, is a next-generation internet architecture centered on user data sovereignty. It enables data storage, management, and verification in a distributed network environment, aiming to build an internet infrastructure that is censorship-resistant, interoperable, and privacy-first.

[0029] Web5 Agent is an identity management executor that follows the Web5 technology stack. It integrates a key vault, DID parser, and VC processor to act as an agent for users in identity authentication, data access control, and privacy protection, enabling seamless interaction between users and the decentralized network.

[0030] Decentralized Identifier (DID) is a new type of identity strategy that allows users to create and control their own digital identities without relying on centralized servers or databases. It supports global interoperability and enhances privacy and data security.

[0031] It should be noted that the information (including but not limited to passenger device information, passenger personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) collected in this public disclosure are information and data authorized by passengers or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data all comply with the relevant laws, regulations, and standards of the relevant regions, necessary confidentiality measures have been taken, and it does not violate public order and good morals. Corresponding access points are provided for passengers to choose whether to authorize or refuse. For example, this system has interfaces with relevant passengers or institutions. Before obtaining relevant information, a request to obtain the information needs to be sent to the aforementioned passengers or institutions through these interfaces, and the relevant information is obtained only after receiving consent from the aforementioned passengers or institutions.

[0032] It should be noted that in this disclosure, customer information is collected and analyzed, and passengers are provided with corresponding operation entry points to choose whether to agree to or reject the automated decision-making results; if the passenger chooses to reject, the process proceeds to the expert decision-making process.

[0033] Among related technologies, airline ticketing systems have three major pain points: First, the lack of user data sovereignty, with sensitive information (such as identity and travel data) being centrally controlled by airlines, leading to the risk of privacy leaks; second, poor interoperability across airlines, with isolated systems causing lengthy transfer verification processes, severely impacting user experience; and third, unavailability in offline scenarios, as over-reliance on central servers makes it impossible to complete voucher verification in network failures or remote airport scenarios.

[0034] The following embodiments of the present invention can be applied to various Web5-based airline ticketing verification systems / applications / devices. The present invention is applicable to scenarios such as airline ticketing management systems, airport security and boarding procedures, and automated baggage check-in. In the airline ticketing management system scenario, the present invention supports decentralized ticket issuance, storage, and verification, and is particularly suitable for cross-airline credential recognition in multi-airline operations, improving the passenger transfer experience and reducing the time spent on repetitive data entry and verification. In the airport security and boarding procedure scenario, through local DWN nodes and zero-knowledge proof technology, airport security personnel can efficiently verify passenger qualifications and flight information while protecting passenger privacy, optimizing the boarding process and supporting offline verification scenarios. In the automated baggage check-in scenario, the present invention allows passengers to authorize subsequent airlines to access only necessary baggage information during the initial flight check-in, without disclosing the complete itinerary, thus automating cross-airline baggage check-in, improving baggage handling efficiency, and ensuring data security.

[0035] This invention ensures users' autonomous control and management of their personal data through local DWN nodes, including data storage location, access permission policies, and auditing of data usage, greatly enhancing users' control over their personal data. With the help of a pre-set zero-knowledge proof engine, the verifier can complete credential validity verification without accessing the original sensitive data, improving verification efficiency while protecting user privacy, achieving a secure verification mode of "data usable but not visible."

[0036] Furthermore, the local DWN node in this invention supports offline interaction methods such as NFC / Bluetooth, ensuring that passengers can still present encrypted credentials for boarding or baggage processing in environments without network access, thus solving the service continuity problem in remote airports or situations with unstable networks. Through DID resolution and direct message passing between nodes, airlines, airports, and other institutions can achieve real-time and secure data sharing without relying on a centralized system, significantly improving the efficiency and user experience of cross-airline services.

[0037] Compared to traditional centralized or blockchain solutions, the decentralized architecture of this invention reduces the need for high-cost data centers or consortium blockchain nodes, requiring only the maintenance of simple local DWN nodes, thus significantly reducing overall deployment and maintenance costs.

[0038] The present invention will now be described in detail with reference to various embodiments.

[0039] Example 1 According to embodiments of the present invention, an airline ticketing management system based on a Web5 architecture is proposed. This system achieves autonomous control and secure data sharing by introducing a multi-layered distributed storage network. The storage layer consists of multiple local decentralized network nodes (DWN nodes) and public relay nodes, constructing an efficient, decentralized, and privacy-preserving data storage and interaction environment. Specifically, the storage layer of the airline ticketing management system includes multiple local decentralized network nodes (DWN nodes) and public relay nodes. The multiple local decentralized network nodes (DWN nodes) include passenger DWN nodes, airline DWN nodes, airport DWN nodes, and other third-party DWN nodes.

[0040] The passenger DWN node stores the complete encrypted text of the ticket verifiable credential (FVC) and supports offline access. This complete encrypted text includes flight information, refund and change records, access control policies, and operation audit logs. Flight information may include, but is not limited to, flight number, departure point, destination, time, and passenger name. This information is encrypted during storage to ensure that even if the data is accessed without authorization, sensitive information cannot be directly deciphered. Refund and change records may include, but are not limited to, refund and change dates, reasons, and potential fee changes. Access control policies are defined by the passenger, specifying who can access specific fields in the FVC, when, and how. This enables fine-grained access control based on roles, time windows, and data types, ensuring that only authorized entities have access while minimizing excessive data disclosure. Operation audit logs record relevant operations (including requester DID, operation time, and operation type) when the FVC is accessed or modified, forming a complete audit chain. These records are also stored in encrypted form, providing passengers with a complete and private view of their travel history. They also provide airlines and airports with some information needed to verify passenger eligibility, but do not expose the specific content.

[0041] In addition, the passenger DWN node in this embodiment also provides offline access functionality, which supports local storage on the mobile phone. When encountering network instability or network outage, passengers can still directly present encrypted ticket verification credentials through short-range communication technologies such as NFC or Bluetooth to complete the verification process, ensuring service continuity and optimizing passenger experience.

[0042] The airline's DWN node is used to store the hash value of the ticket's verifiable credentials, status identifier, and metadata of the passenger's authorized access policy.

[0043] In this embodiment, the airline DWN node primarily stores the hash value of the ticket verifiable credential (FVC), status identifiers (such as valid, refunded / changed, used), and metadata about the passenger's authorized access policy. When the ticket status changes, such as through a refund or change, the airline DWN node automatically generates a status update message and synchronizes the update to all authorized associated nodes, such as the passenger DWN node and the airport DWN node, ensuring the consistency of the credential status. Furthermore, the airline DWN node also undertakes the responsibility of issuing and managing VCs, ensuring the authenticity and immutability of the credentials through DID and private key signing.

[0044] When a ticket is refunded or changed, the message update module in this embodiment is automatically activated, instantly generating a status update message. The message includes the ticket's basic information hash, a new status identifier (such as refunded, changed, and the hash of the changed flight information), and related metadata, such as a timestamp and operation type. Optionally, the airline's DWN node also includes a message update module, used to automatically generate a status update message when a ticket is refunded or changed, and synchronously push the refund / change message to all authorized associated nodes.

[0045] When a passenger's ticket status changes, the message update module of the airline's DWN node immediately constructs a status update message. The message construction follows a standardized data model to ensure all recipients can correctly parse and understand the message content. Based on the passenger's DID and authorized access policy metadata, the message update module determines which associated nodes (including all entities that have interacted with the passenger's FVC, such as airports and other airlines potentially involved in transfers) need to receive the status update. After identifying the associated target nodes, the message update module can use a P2P network protocol to push the status update message to the DWNs of these nodes. If the target node is temporarily offline, the message update module will temporarily store the update in a public relay DWN, automatically synchronizing it once the target node comes online, ensuring real-time information and consistency. After verifying the message's validity, the receiving node updates its locally stored FVC status and reports the updated status to the airline's DWN node through a message confirmation mechanism. Furthermore, all status change operations are recorded in the local DWN audit log for subsequent auditing and dispute resolution.

[0046] Airport DWN nodes and other third-party DWN nodes are used to store the hash value of the passenger's authorized ticket verification credentials, pre-generated verification keys, and permission time windows.

[0047] In this embodiment, the information stored by the airport DWN node and other third-party DWN nodes (such as airport transfer stations, car rental companies, etc.) is relatively limited, including only the FVC hash value authorized by the passenger, the pre-generated verification key, and the permission time window. These nodes do not store complete sensitive information, but only retain the basic data required for verification, achieving minimal data disclosure while ensuring the efficiency and security of data verification. During the verification process, the airport or third-party node only needs to verify the hash value and verification key to confirm the validity and authenticity of the credentials, without accessing the passenger's personal information, thereby ensuring service efficiency while maximizing the protection of passenger privacy.

[0048] The public relay node establishes pre-connection relationships with multiple local DWN nodes to save data to be synchronized when local DWN nodes are offline through an offline data storage and synchronization mechanism. The public relay node also provides identifier resolution services for multiple local DWN nodes. Different local DWN nodes can directly establish connections by resolving the DWN service endpoint of each other's node identifiers to complete decentralized interaction across entities.

[0049] In this embodiment, the public relay node acts as a bridge and router, establishing pre-established connections with multiple local DWN nodes. On one hand, when local DWN nodes are offline (e.g., passenger devices lose network access), the public relay node can serve as a temporary data storage point, temporarily storing data to be synchronized (such as airline status update messages). Once the local nodes are back online, the data is automatically retrieved, ensuring data consistency. On the other hand, the public relay node provides an identifier resolution service, helping local DWN nodes from different entities directly discover and establish connections through DID resolution, achieving real-time, decentralized data interaction and information synchronization. This mechanism not only simplifies the data transmission process between nodes but also avoids the single point of failure risk of centralized servers, enhancing the overall stability and security of the system.

[0050] In this embodiment, each DWN node adheres to the Decentralized Identifier (DID) standard, ensuring equality and interoperability among all nodes. The use of key pairs (public and private keys) enables data encryption, decryption, and signature verification, guaranteeing data security and integrity. Furthermore, the introduction of public relay nodes solves the challenges of node discovery and offline data synchronization in distributed networks, improving system robustness and user experience.

[0051] The aforementioned Web5-based airline ticketing management system ensures users' autonomy in controlling and managing their personal data through local DWN nodes, including data storage location, access permission policies, and data usage auditing. This greatly enhances passengers' control over their personal data. Verifiers can complete credential validity verification without accessing the original sensitive data, improving verification efficiency and protecting user privacy. It achieves a "data usable but not visible" secure verification mode, thereby solving the technical problem of passenger data leakage risks that arise from centralized management strategies in airline ticketing management.

[0052] Optionally, the airline ticketing management system also includes an identity layer, which includes: an identity identifier library, which stores multiple passenger identity identifier documents and key pairs. The identity identifier document stores the passenger's identity identifier generated by the Web5 wallet, the passenger's public key, and the DWN server endpoint. The passenger's private key in the key pair is securely stored in the key vault within the identity management execution unit. A ticket verifiable credential library is used to store ticket verifiable credentials signed using an asymmetric algorithm. The data fields of the ticket verifiable credential include: digital signature, issuer, validity period, passenger identity identifier, and hash value of flight information.

[0053] The identity repository, as the core of the identity layer, is responsible for storing and managing passenger-related identity documents. These documents contain the passenger's identity / decentralized identifier (DID), automatically generated by the passenger's Web5 wallet, along with their associated public key and DWN server endpoint information. Each passenger has a unique decentralized identifier (DID), serving as their digital identity in cyberspace. The passenger's public key is used to verify operations related to that DID, such as authorization for access to and use of the FVC. The identity document explicitly identifies the server endpoint of the passenger's local DWN node. Verifiers can parse the DID document to obtain the passenger's DWN node address and establish a direct connection, thus bypassing the limitations of traditional centralized systems. The key pair (containing a public and private key) associated with each passenger's DID is securely stored in the key vault of the identity management execution entity (which can be defined as the Web5 Agent in this embodiment). The private key never leaves the local device, ensuring the highest level of control and security over passenger data.

[0054] In addition, the FVC (Flying Ticket Verifiable Token) repository stores flying ticket verifiable tokens signed by airlines using an asymmetric algorithm. The digital signature, generated by the airline's private key, ensures the authenticity and integrity of the FVC, preventing forgery or tampering. The issuer's ID (DID), typically the airline's, is explicitly included in the FVC, serving as proof of authenticity. The validity period is the start and end timestamps of the flying ticket verifiable token, used to verify its validity. The passenger identity identifier (DID) ensures the binding relationship between the token and a specific passenger, facilitating quick identification and verification of passenger eligibility. To protect passenger privacy, sensitive fields of flight information are not stored directly in the FVC but rather their hash values. This allows verifiers to confirm information matching by comparing hash values ​​without needing to know the specific information content, thus minimizing data disclosure required for the scenario.

[0055] Optionally, the passenger-side Web5 wallet includes at least: an identity storage module for storing the passenger's identity; a ticket verifiable credential storage module for storing the passenger's ticket verifiable credential; and an identity management executor for managing the passenger's keys.

[0056] The ticket verifiable credential storage module performs the encrypted storage function for ticket verifiable credentials. When passengers receive ticket verifiable credentials issued by the airline, these credentials are saved in encrypted form, ensuring that sensitive information cannot be easily deciphered even if the data is accessed without authorization. In addition, this embodiment also supports intelligent storage strategies, such as storing the complete encrypted text of frequently used credentials locally, while only retaining the hash index and access strategy for infrequently accessed historical credentials locally. The complete encrypted text can be migrated to a distributed storage system to balance data security and storage resources.

[0057] Optionally, the identity management executor includes: a key vault for storing and managing passengers' private keys, which are used to generate decentralized identifiers and sign and encrypt ticket verifiable credentials; an identifier parser for parsing identity documents; and a verifiable credential processor for receiving ticket verifiable credentials and storing them in a local or decentralized storage system after verifying that the issuer, validity period, and credential status of the ticket verifiable credentials are all verified. The verifiable credential processor also supports generating proof documents using zero-knowledge proof strategies, and uses the proof documents to verify the validity of the ticket verifiable credentials.

[0058] When the verifiable credential processor receives a ticket verifiable credential (FVC), it first verifies the issuer, validity period, and status of the credential. Only after these elements are verified will the FVC be stored locally or in a decentralized storage system. Furthermore, it supports zero-knowledge proof strategies, generating a proof document without revealing the specific content of the credential to verify its validity, greatly enhancing the system's privacy protection capabilities.

[0059] Optionally, the airline ticketing management system also includes a verification layer, which comprises: a verification request initiation module, which sends a structured verification request to the identity management executor on the passenger side via a decentralized application (DWA). The structured verification request includes the request type, the hash value of the target flight number, and the identity identifier of the verifier; a request preprocessing module, which decrypts the complete ciphertext of the stored verifiable ticket credential using a local private key; utilizes the identity management executor to call a zero-knowledge proof engine to load a preset zero-knowledge proof circuit and verify whether the hash value of the local flight number matches the hash value of the target flight number in the structured verification request; and a proof document generation module, which is used to generate a certificate when the verification result indicates a match between the hash values. In the case of a matching system, the target parameters are input into the zero-knowledge proof circuit, and the zero-knowledge proof engine generates a proof file. The target parameters include: the airline's public key, the validity period, the hash value of the local flight number, and the credential status identifier. The zero-knowledge proof circuit has pre-integrated signature verification logic and credential status validity check logic. The proof transmission module is used to transmit the generated proof file to the verifier through a secure channel. The proof verification module is used to query the hash status of the ticket verifiable credential from the airline's DWN node to confirm that the ticket verifiable credential has not been revoked, and to verify the validity of the proof file using the airline's public key. After all verifications pass, the passenger is confirmed to meet the conditions, and the trusted verification is completed.

[0060] In this embodiment, the verifier may include, but is not limited to, airports and connecting airlines. The verifier sends a structured verification request to the passenger's identity management execution entity via a decentralized application (DWA). Upon receiving the verification request, the passenger's identity management execution entity initiates a request preprocessing module. This module uses the passenger's locally stored private key to decrypt the stored complete FVC ciphertext to obtain the original credential information. Subsequently, the module invokes a zero-knowledge proof engine to load pre-defined verification logic, including but not limited to signature verification and credential validity checks. This ensures that the necessary verification logic is adequately prepared and loaded before processing the verification request, thereby improving the accuracy and efficiency of the verification.

[0061] Once the request preprocessing module confirms that the hash value of the local flight number matches the hash value of the target flight number in the structured verification request, the proof document generation module begins its work. It inputs a series of target parameters into the zero-knowledge proof engine, including the airline's public key, the validity period of the credential, the hash value, and the credential status identifier. By executing pre-integrated verification logic (such as the Groth16 algorithm based on zk-SNARKs), the zero-knowledge proof engine generates a proof document. This document contains verification conclusions such as "airline signature is valid," "time is within the validity period," "flight number matches," and "credential status is valid," but does not contain any sensitive information such as specific flight times or passenger identities. The generated proof document is then transmitted to the verifier by the proof transmission module through a secure communication channel, ensuring the security of the proof document transmission and preventing data tampering or leakage during transmission, thereby maintaining the integrity and reliability of the entire verification process.

[0062] Ultimately, the verifier's proof verification module is responsible for completing the verification process. First, it queries the airline's DWN node to check the hash status of the FVC, confirming that the credential is currently valid and has not been revoked. Next, the verifier uses the airline's public key to verify the validity of the proof document π, ensuring the correctness of the airline's signature and the accuracy of other verification logic. Once verification is successful, the proof verification module confirms that the passenger meets the verification conditions, completing the trusted verification.

[0063] Optionally, the airline ticketing management system also includes an application layer, which includes: a ticketing module, where after passengers complete flight selection and payment through the airline's decentralized application, the airline's identity authorization module issues a verifiable ticket credential in a specified format using a private key, pushes the encrypted verifiable ticket credential to the passenger's DWN node for storage through the airline's DWN node, and synchronizes the hash value of the verifiable ticket credential to the airport's DWN node; an authorization module, where passengers configure authorized access policies, which are then signed with the passenger's private key and pushed to the verifier's DWN node, which verifies the signature and stores it, including the airport's DWN node and third-party DWN nodes; a verification module, where when a passenger's DWN node initiates a verification request, it returns a proof file or temporary token generated by a zero-knowledge proof engine to the verifier, who then completes real-time verification using the proof file or temporary token; and an auditing module, which audits access operations in the operation audit log, where all access operations of the verifiable ticket credential in the passenger's DWN node are fully recorded in the operation audit log.

[0064] The ticketing module allows passengers to select flights and make payments through the airline's decentralized application (DWA). After the ticketing process is completed, the airline's identity authorization module is activated, using the airline's private key to issue a Flight Verifiable Certificate (FVC) based on a predefined format and standard (such as the W3C VC standard data model). Subsequently, the airline's DWN node is responsible for pushing the encrypted FVC to the passenger's DWN node for local storage, while simultaneously synchronizing the FVC's hash value to the airport's DWN node so that verification parties such as the airport can verify the certificate's status in subsequent processes.

[0065] The authorization module empowers passengers to configure authorized access policies, allowing them to specify which verification parties (such as airports and customs) can access specific fields in verifiable credentials, and when and how. Passengers create these policies using an identity execution agent (such as a web5 agent) and sign them with their private key to ensure the authenticity and immutability of the policies. The signed authorization policies are then pushed to verification party DWN nodes, including airport DWN nodes and third-party DWN nodes. Upon receiving the authorization policy, the verification party DWN node verifies the signature, stores it after confirmation, and provides a basis for subsequent credential access and verification.

[0066] In addition, this embodiment uses an audit module to monitor and audit all access operations related to passenger FVC. In this embodiment, all access operations involving FVC, including but not limited to initiating verification requests, pushing authorization policies, generating zero-knowledge proofs, and accessing data, are fully recorded in the operation audit log and stored in the passenger DWN node. The audit module allows passengers to view these logs at any time to understand the usage of credentials. At the same time, it also provides a traceable chain of evidence for dispute resolution, enhancing the transparency and security of the system.

[0067] The invention will now be described through another optional implementation.

[0068] The main components of this invention include: 1. Airline side: Deploying a DID registration service, publishing the reservation JSON format and glossary of ticket VCs; simultaneously deploying local DWN nodes to provide VC issuance service endpoints. 2. Passenger side: Installing a Web5 wallet APP integrating a local DWN module; local DWN nodes have NFC / Bluetooth offline interaction enabled by default. 3. Third-party side (airports, etc.): Deploying local DWN nodes, such as airport counter terminals and customs verification equipment. Nodes are pre-configured with an airline DID list and basic verification policies. 4. Public network relay DWN: Deploying public network relay nodes by a neutral organization to assist offline nodes in message storage and routing; the nodes do not store any business data.

[0069] This invention proposes a Web5-based four-layer collaborative architecture: "identity layer - storage layer - verification layer - application layer". Figure 1 This is a schematic diagram of an optional Web5-based distributed storage system for verifiable flight tickets, according to an embodiment of the present invention. Figure 1 As shown, the specific node content of the application layer and storage layer is displayed, while the identity layer and authentication layer can be determined through the interaction of these nodes. The following sections will explain the architecture of these four layers respectively.

[0070] (1) Identity layer: DID and VC issuance system.

[0071] Passengers can generate their own W3C-compliant DIDs (e.g., did:key:xxx) using their Web5 wallets. Their DID documents contain public keys, DWN server endpoints, etc., while the user's private key is securely stored in the Web5 Agent's key vault.

[0072] The ticket VC (Verifiable Credential) adopts the W3C standardized verifiable credential architecture. Core data fields include the issuer (airline DID), validity period, passenger DID, and flight information (including sensitive data such as passenger name, departure point, flight number, and time). It is signed using an asymmetric algorithm and issued with the airline's private key, ensuring immutability.

[0073] (2) Storage layer: Distributed DWN network and synchronization mechanism.

[0074] A hybrid storage model of "multi-subject local DWN + public relay node" is adopted, in which all nodes interact equally.

[0075] 1. Multi-subject local DWN.

[0076] All participants, including passengers, airlines, airports, and customs, deploy independent local DWN nodes (such as passenger mobile phones, airline servers, and airport terminals). Each node autonomously manages data storage and interaction permissions, forming an equal P2P network, similar to the peer-to-peer relationship of nodes in a distributed chat room.

[0077] Passenger's local DWN node: Stores the complete encrypted credential (VC) of the ticket, including complete flight information, refund and change records, access control policies, and operation audit logs. Offline access is also supported, such as local storage on a mobile phone; the encrypted credential can be presented directly via NFC / Bluetooth when there is no network connection.

[0078] Airline local DWN node: Stores the hash value of the ticket VC, status identifier (valid / refundable / used), and metadata of the passenger's authorized access policy. When a ticket is refunded or changed, the airline's local DWN node automatically generates a status update message and pushes it to all authorized associated nodes (such as the passenger's and airport's local DWN) for synchronization.

[0079] Airport / third-party local DWN nodes: only store the passenger-authorized ticket VC hash value, pre-generated verification key, and permission time window (such as the time period during which the ticket can be verified for check-in), and do not store complete sensitive information to ensure minimal data disclosure.

[0080] 2. Public relay DWN node.

[0081] The relay DWN nodes deployed on the public network serve only as temporary bridges for end-to-end interaction. Their core functions are reflected in two aspects: First, through an offline data storage and synchronization mechanism, when the local DWN node is offline (such as when passengers or institutional equipment lose network access), it temporarily saves data to be synchronized (such as refund and change status updates), and automatically retrieves the data through the P2P protocol after the node regains network access.

[0082] Secondly, it enables node discovery and routing based on DID resolution services, helping local DWNs of different entities to directly establish connections by resolving each other's DID service endpoints, thereby supporting decentralized direct interaction across entities.

[0083] Specific application process. Figure 2 This is a schematic diagram illustrating the interaction between optional local DWN nodes according to an embodiment of the present invention, such as... Figure 2 As shown, the system includes the following entities: UserA (i.e., user A), UserB (i.e., user B), A's DWN (i.e., the local DWN node corresponding to user A), B's DWN (i.e., the local DWN node corresponding to user B), and DID Resolver (corresponding to the decentralized identifier resolver mentioned above). During the interaction, UserA parses the DID document, obtains the node server address, and sends a message to B's DWN. Then, B's DWN transmits the data to UserB, and UserB sends a reply to A's DWN. Finally, A's DWN transmits UserB's response information to UserA, completing the node information interaction process.

[0084] 3. Local dynamic DWN storage.

[0085] Passenger Data WNs (DWNs) can incorporate a dynamic storage optimization mechanism, intelligently adjusting storage strategies based on credential access frequency: High-frequency access credentials (VCs) are stored locally in their entirety (encrypted), ensuring immediate access for critical business operations; low-frequency access credentials (historical VCs) are automatically migrated to distributed storage systems like IPFS, with the local DWN retaining only the hash index and access strategy. This mechanism supports customizable threshold configurations (e.g., setting access frequency ≤ 2 times within 30 days as low-frequency), achieving a dynamic balance between storage resources and security.

[0086] (3) Verification layer: Zero-knowledge proof and privacy protection sharing.

[0087] When verification parties such as airports and connecting airlines need to confirm whether passengers meet specific conditions, passengers do not need to disclose complete plaintext credentials. Trusted verification based on zk-SNARKs protocols (such as Groth16) is achieved through a zero-knowledge proof engine. The zero-knowledge proof engine integrates functions such as verification request processing, encrypted data decryption, dedicated circuit execution, and proof verification.

[0088] Figure 3 This is a schematic diagram of an optional data verification process according to an embodiment of the present invention, such as... Figure 3 As shown, the verification process includes: 1. Validation Request Initiation: The validator sends a structured validation request to the passenger's Web5 Agent through the decentralized application DWA for airline ticketing management. The request includes the request type (such as "flightValidation"), the hash value of the target flight number, and the validator's DID.

[0089] 2. Preprocessing of the zero-knowledge proof engine: After receiving the request, the passenger-side Web5 Agent first uses its local private key to decrypt the stored ticket VC ciphertext and obtain the raw data; secondly, the Agent calls the zero-knowledge proof engine to load the preset zero-knowledge proof circuit (such as a dedicated circuit for flight verification), which has integrated logic such as signature verification and state validity check; finally, it verifies whether the hash value of the local flight number matches the hash value of the target flight number in the request to ensure the consistency of the verification target.

[0090] 3. Zero-Knowledge Proof Document Generation: The zero-knowledge proof engine verifies the logic input circuit. Input parameters include the airline's public key, validity period, hash value of the flight number, and credential status identifier. After execution by the Groth16 algorithm, a proof document π is generated. This proof only contains conclusive information such as "airline signature is valid," "time is within the validity period," "flight number matches," and "credential status is valid," without disclosing sensitive data such as specific flight time or passenger identity.

[0091] 4. Secure transmission of proof: The generated proof π is transmitted to the verifier via secure channels such as Bluetooth and HTTPS to ensure that the data is not tampered with or stolen during the transmission process.

[0092] 5. The verifier performs the verification: First, it queries the airline's DWN to check the hash status of the VC and confirm that the credential has not been revoked; second, it uses the airline's public key to verify the validity of the proof document π. Once both verifications pass, the passenger is confirmed to meet the requirements, and the trusted verification is complete.

[0093] (4) Application layer: DWA interaction and permission management.

[0094] 1. Ticketing stage: After the passenger completes the flight selection and payment through the airline's DWA, the airline's DID uses its private key to issue a JSON-LD format ticket VC, and pushes the encrypted complete VC to the passenger's local DWN storage through DWN, and simultaneously hashes it to the airport's DWN.

[0095] 2. Authorization Phase: Passengers configure authorized access policies (e.g., allowing airport DWNs to access ticket VCs from 12:00 to 14:00 on September 1, 2025). The policy, signed with the passenger's private key, is directly pushed to the verifying DWN. The node verifies the signature and stores it. If the target is offline, the policy is temporarily stored on a public network relay node and automatically synchronized upon returning online. Typical policies include limiting the verifying DID's access to specific fields in the VC (such as flight information and transfer times) within a specific time period, achieving fine-grained authorization based on time, role, and data, ensuring complete user control over the scope of credential usage.

[0096] 3. Verification Phase: When the verifier (e.g., at the airport counter) initiates a verification request compliant with the W3C VP standard, the passenger needs to confirm authorization. After authorization, the Agent generates a zero-knowledge proof or temporary token as needed and returns it to the verifier. The verifier can complete real-time verification by verifying with the zero-knowledge proof or by submitting the token to the airline's DWN.

[0097] 4. Audit Phase: All access operations of VCs in passenger DWNs (including requester DID, timestamp, operation type, zero-knowledge proof type, etc.) are fully recorded in the local audit log, and cross-DWN audit log synchronization is supported. Users can view historical operation records at any time, providing a traceable chain of evidence for dispute resolution.

[0098] The following section, combining the content of the above four levels, explains the processing procedure of the airline ticketing management system.

[0099] Part 1: Issuance and storage process of verifiable ticket vouchers (VCs).

[0100] (1) Passengers submit DID and flight requests through the airline's DWA; (2) The airline's DWA generates a VC that conforms to a predetermined format, encrypts it, and pushes it to the passenger's local DWN. At the same time, the airline's local DWN stores the hash value and status identifier of the VC.

[0101] (3) After the passenger's local DWN receives the VC, it encrypts the complete VC ciphertext and stores it, and generates an access control policy; (4) If the passenger or airline node is offline, the VC hash and status information to be synchronized are temporarily stored in the public network relay DWN; after the node is connected to the network, it will automatically pull the data from the public network relay to ensure the consistency of the status of the passenger and airline's local DWN.

[0102] Part Two: Offline Fast Verification at the Boarding Gate for Transit Flights.

[0103] Requirements: Poor network conditions (e.g., no signal on the jet bridge), only need to verify the validity of the ticket, not its real-time status.

[0104] (1) When passengers connect to the network, a "zero-knowledge certificate of flight validity" is pre-generated, which includes the validity of the airline's signature, the validity of the certificate, and the matching of the flight number; (2) The proof document is stored in the local DWN and an NFC-readable encrypted data packet is generated; (3) The boarding gate equipment reads data packets using a short-range communication strategy to verify the validity of the passenger's signature, whether the current time is within the validity period of the credential status, and the authenticity of the basic flight information in the zero-knowledge proof document. If the current time exceeds the validity period of the credential status, offline verification is rejected; (4) Release the device after verification and upload the audit log after the device is connected to the network.

[0105] Part Three: Automatic Verification of Through-Check-in Baggage for Cross-Airline Airlines.

[0106] Requirements: Requirement to share baggage information across airlines and avoid leaking complete itinerary details.

[0107] (1) When passengers check in for the first flight, they generate a temporary authorization credential through Web5 Agent to authorize the connecting airline DWN to access fields such as "baggage destination" and "connecting flight number"; (2) The first-leg airline DWN will send encrypted baggage information fragments to the connecting airline DWN; (3) The transit airline DWN uses the temporary authorization certificate to decrypt the data and generate a zero-knowledge proof (proving that "the baggage destination is consistent with the transit flight destination"). (4) Once the proof is verified, the baggage will be automatically checked through without disclosing the passenger's complete itinerary information. (5) When baggage status is updated, the transit airline's DWN pushes the status hash to the passenger's DWN to ensure tracking visibility.

[0108] Through the above implementation method, personal data, including the complete encrypted text of the ticket VC, can be stored and managed through a local DWN node, ensuring that passengers have complete control over their data, including data storage location, access permissions, and operation auditing. Passengers can decide how their data is used, avoiding privacy leaks and data misuse problems that may occur in traditional centralized systems.

[0109] The local DWN node of this invention supports offline data interaction via NFC and Bluetooth. The pre-generated zero-knowledge proof ensures the validity verification of credentials in unstable or no-network environments, guaranteeing that passengers can pass through security checks and board smoothly even in remote airports or network failure scenarios, thus enhancing the robustness and practicality of the system.

[0110] Furthermore, in this embodiment of the invention, the integration of zero-knowledge proof technology achieves the principle of minimizing data disclosure. Only the abstract conclusions required for verification are transmitted during the verification process without revealing specific information, thus ensuring the protection of sensitive data (such as flight times, passenger identities, etc.) and maintaining data privacy even during the verification process, thereby constructing a secure environment where "data is usable but not visible".

[0111] It avoids the need for expensive centralized servers or consortium blockchain deployments, and achieves low-cost system operation and maintenance through lightweight local DWN nodes and public relay DWN nodes. This reduces the equipment investment for airlines, while ensuring performance and security that are comparable to or even better than traditional centralized systems, which is conducive to promotion and large-scale application.

[0112] According to an embodiment of the present invention, an embodiment of an airline ticket verification method based on Web5 architecture is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0113] This invention provides an airline ticketing verification method based on Web5 architecture, which is applied to the passenger-side identity management execution unit in any of the above-mentioned airline ticketing management systems based on Web5 architecture.

[0114] Figure 4 This is a flowchart of an optional Web5-based airline ticket verification method according to an embodiment of the present invention, such as... Figure 4 As shown, the method includes the following steps: Step S401: Receive a structured verification request sent by the verifier through the decentralized application DWA, wherein the structured verification request includes the request type, the hash value of the target flight number, and the identity identifier of the verifier.

[0115] Step S402: Decrypt the complete ciphertext of the stored ticket verifiable credential based on the local private key. The complete ciphertext includes at least the following: flight information, which includes at least the local flight number and the hash value of the local flight number.

[0116] Step S403: Call the zero-knowledge proof engine to load the preset zero-knowledge proof circuit and verify whether the hash value of the local flight number matches the hash value of the target flight number in the structured verification request.

[0117] Step S404: If the verification result indicates that the hash value matches, the target parameters are input into the zero-knowledge proof circuit, and the zero-knowledge proof engine is used to generate a proof file. The target parameters include: the airline's public key, the validity period, the hash value of the local flight number, and the credential status identifier. The zero-knowledge proof circuit has pre-integrated signature verification logic and credential status validity period check logic.

[0118] Step S405: The generated proof document is transmitted to the verifier through a secure channel. The verifier queries the airline's DWN node for the hash status of the ticket verification credential to confirm that the ticket verification credential has not been revoked, and uses the airline's public key to verify the validity of the proof document. After all verifications are successful, the passenger is confirmed to meet the conditions, and the trusted verification is completed.

[0119] Through the above steps, local DWN nodes can ensure users' independent control and management of personal data, including data storage location, access permission policies, and auditing of data usage. This greatly enhances passengers' control over their personal data. Through a zero-knowledge proof engine, the verifier can complete the verification of credential validity without accessing the original sensitive data, which improves verification efficiency and protects user privacy. It achieves a "data usable but not visible" secure verification mode, thereby solving the technical problem that centralized management strategies in airline ticketing management can easily lead to the risk of passenger data leakage.

[0120] Optionally, the supporting documentation may include at least one of the following: whether the airline's signature is valid, whether the current time is valid, whether the flight number matches, and whether the ticket verification document status is valid.

[0121] Optionally, it also includes: after initiating a ticket credential request to the airline's decentralized network application, receiving a ticket verifiable credential returned by the airline's decentralized network application, wherein the ticket credential request is a credential acquisition request initiated by the passenger after completing flight selection and payment through the airline's decentralized application; after receiving the ticket verifiable credential in a specified format issued by the airline's identity authorization module using a private key after the passenger completes flight selection and payment through the airline's decentralized application; storing the ticket verifiable credential in a verification credential processor; and synchronizing the hash value of the ticket verifiable credential to the airport DWN node.

[0122] Optionally, it also includes: during check-in for the first flight, the passenger generates a temporary authorization credential through the identity management executor, authorizing the transit airline's DWN node to access the reserved baggage-related fields and the transit flight fields, and obtains the temporary authorization credential; the first-flight airline's DWN node sends an encrypted baggage information fragment to the transit airline's DWN node; the transit airline's DWN node uses the temporary authorization credential to decrypt the data and generate a baggage zero-knowledge proof document; if the baggage zero-knowledge proof document is verified, the baggage is automatically checked through; if the passenger's baggage status is updated, the transit airline's DWN node pushes the status hash to the passenger's DWN node.

[0123] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is running, it controls the device where the computer-readable storage medium is located to execute any of the above-described Web5-based airline ticket verification methods.

[0124] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the Web5-based airline ticket verification method of any one of the above embodiments.

[0125] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the airline ticketing verification method based on Web5 architecture described in various embodiments of this application.

[0126] This application also provides a computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the airline ticketing verification method based on Web5 architecture described in various embodiments of this application.

[0127] Figure 5 This is a hardware structure block diagram of an electronic device (or mobile device) that executes an airline ticketing verification method based on a Web5 architecture according to an embodiment of the present invention. Figure 5 As shown, an electronic device may include one or more ( Figure 5The processor 502 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 504 for storing data may also be included. In addition, it may include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a keyboard, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 5 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, the electronic device may also include components that are more... Figure 5 The more or fewer components shown, or having the same Figure 5 The different configurations shown.

[0128] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0129] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0130] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0131] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0132] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0133] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0134] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. An airline ticketing management system based on Web5 architecture, characterized in that, The storage layer of the airline ticketing management system includes: multiple local decentralized network nodes (DWN nodes) and public relay nodes. The multiple local decentralized network nodes (DWN nodes) include: passenger DWN nodes, airline DWN nodes, airport DWN nodes, and other third-party DWN nodes. The passenger DWN node is used to store the complete encrypted text of the ticket verification credential and supports offline access. The complete encrypted text includes: flight information, refund and change records, access permission policies and operation audit logs. The airline's DWN node is used to store the hash value, status identifier, and metadata of the passenger's authorized access policy for the ticket verification credential. The airport DWN node and other third-party DWN nodes are used to store the hash value of the passenger's authorized ticket verifiable credentials, the pre-generated verification key, and the permission time window; The public relay node is pre-connected to multiple local DWN nodes to save data to be synchronized when the local DWN nodes are offline, through an offline data storage and synchronization mechanism. The public relay node is also used to provide identifier resolution services for multiple local DWN nodes. Different local DWN nodes can directly establish connections by resolving the DWN service endpoint of the other node's identifier, thus completing decentralized interaction across entities.

2. The airline ticketing management system according to claim 1, characterized in that, The airline's DWN node also includes: The message update module is used to automatically generate a status update message for the airline's DWN node when a ticket is refunded or changed, and to synchronously push the refund or change message to all authorized associated nodes.

3. The airline ticketing management system according to claim 1, characterized in that, The airline ticketing management system also includes an identity layer, which includes: The identity database stores multiple passenger identity documents and key pairs. The identity document stores the passenger's identity generated by the Web5 wallet, the passenger's public key, and the DWN server endpoint. The passenger's private key in the key pair is securely stored in the key vault within the identity management execution unit. The ticket verifiable credential library is used to store ticket verifiable credentials signed by an asymmetric algorithm. The data fields of the ticket verifiable credential include: digital signature, issuer, validity period, passenger identification, and hash value of flight information.

4. The airline ticketing management system according to claim 3, characterized in that, The passenger-side Web5 wallet includes at least: An identity storage module is used to store the passenger's identity information; The ticket verifiable credential storage module is used to store the passenger's ticket verifiable credential; The identity management executor is used to manage passenger keys.

5. The airline ticketing management system according to claim 4, characterized in that, The identity management execution entity includes: A key vault is used to store and manage passengers' private keys, which are used to generate decentralized identifiers and sign and encrypt ticket verifiable credentials; An identifier parser is used to parse the identity document; And a verifiable credential processor, used to receive a verifiable ticket credential, and store the verifiable ticket credential in a local or decentralized storage system if the issuer, validity period and credential status of the verifiable ticket credential are verified. The verifiable credential processor also supports generating proof documents using zero-knowledge proof strategies, and uses these proof documents to verify the validity of the ticket verifiable credential.

6. The airline ticketing management system according to claim 1, characterized in that, The airline ticketing management system also includes a verification layer, which includes: The verification request initiation module sends a structured verification request to the identity management execution body on the passenger side through the decentralized application DWA. The structured verification request includes the request type, the hash value of the target flight number, and the identity identifier of the verifier. The request preprocessing module uses the local private key to decrypt the complete ciphertext of the stored ticket verifiable credential; it then uses the identity management executor to call the zero-knowledge proof engine to load the preset zero-knowledge proof circuit and verify whether the hash value of the local flight number matches the hash value of the target flight number in the structured verification request. The proof document generation module is used to input the target parameters into the zero-knowledge proof circuit when the verification result indicates that the hash value matches, and generate a proof document using the zero-knowledge proof engine. The target parameters include: airline public key, validity period, hash value of local flight number, and credential status identifier. The zero-knowledge proof circuit has pre-integrated signature verification logic and credential status validity period check logic. The proof transmission module is used to transmit the generated proof documents to the verifier through a secure channel; The verification module is used to query the hash status of the ticket verification credential from the airline's DWN node, confirm that the ticket verification credential has not been revoked, and verify the validity of the proof document using the airline's public key. After all verifications pass, the passenger is confirmed to meet the conditions, and the trusted verification is completed.

7. The airline ticketing management system according to claim 1, characterized in that, The airline ticketing management system also includes an application layer, which includes: In the ticketing module, after the passenger completes flight selection and payment through the airline's decentralized application, the airline's identity authorization module uses a private key to issue a ticket verification credential in a specified format. The encrypted ticket verification credential is then pushed to the passenger's DWN node for storage through the airline's DWN node, and the hash value of the ticket verification credential is synchronized to the airport's DWN node. The authorization module allows passengers to configure authorized access policies, which are then signed with the passenger's private key and pushed to the verification party DWN node. The verification party DWN node verifies the signature and stores it. The verification party node includes: airport DWN node and third-party DWN node. In the verification module, when a passenger DWN node initiates a verification request, it returns a proof file or temporary token generated by the zero-knowledge proof engine to the verifier, who then completes real-time verification using the proof file or temporary token. The audit module reviews the access operations in the operation audit log. All access operations for verifiable credentials for tickets in the passenger DWN nodes are fully recorded in the operation audit log.

8. A method for verifying airline tickets based on Web5 architecture, characterized in that, The passenger-side of the Web5-based airline ticketing management system as described in any one of claims 1 to 7, the Web5-based airline ticketing verification method includes: The receiving verifier sends a structured verification request through the decentralized application DWA, wherein the structured verification request includes the request type, the hash value of the target flight number, and the identity identifier of the verifier; The complete ciphertext of the verifiable ticket credential stored based on the local private key is decrypted, wherein the complete ciphertext includes at least: flight information, which includes at least the local flight number and the hash value of the local flight number; The zero-knowledge proof engine is invoked to load the preset zero-knowledge proof circuit and verify whether the hash value of the local flight number matches the hash value of the target flight number in the structured verification request. If the verification result indicates a hash value match, the target parameters are input into the zero-knowledge proof circuit, and the zero-knowledge proof engine is used to generate a proof file. The target parameters include: the airline's public key, the validity period, the hash value of the local flight number, and the credential status identifier. The zero-knowledge proof circuit has pre-integrated signature verification logic and credential status validity period check logic. The generated proof document is transmitted to the verifier through a secure channel. The verifier queries the airline's DWN node to check the hash status of the ticket verification credential, confirms that the ticket verification credential has not been revoked, and uses the airline's public key to verify the validity of the proof document. After all verifications are successful, the passenger is confirmed to meet the conditions, and the trusted verification is completed.

9. The airline ticket verification method according to claim 8, characterized in that, The supporting documents include at least one of the following: whether the airline's signature is valid, whether the current time is within the validity period, whether the flight number matches, and whether the ticket verification certificate status is valid.

10. The airline ticket verification method according to claim 8, characterized in that, Also includes: After initiating a ticket credential request to the airline's decentralized network application, the system receives the verifiable ticket credential returned by the airline's decentralized network application. The ticket credential request is initiated by the passenger after completing flight selection and payment through the airline's decentralized application. After the passenger completes flight selection and payment through the airline's decentralized application, the airline's identity authorization module uses the private key to issue a verifiable ticket credential in a specified format. Store the verifiable ticket credential in the verification credential processor; Synchronize the hash value of the verifiable ticket credential to the airport DWN node.

11. The airline ticket verification method according to claim 8, characterized in that, Also includes: During check-in for the first flight, the passenger generates a temporary authorization credential through the identity management execution entity, authorizing the transit airline's DWN node to access the booked baggage-related fields and the transit flight fields, and obtains the temporary authorization credential. The first airline's DWN node sends encrypted baggage information fragments to the transit airline's DWN node; The transit airline's DWN node uses a temporary authorization credential to decrypt the data and generate a baggage zero-knowledge proof document; If the zero-knowledge proof of baggage is verified, the baggage will be automatically checked through. When a passenger's baggage status is updated, the transit airline's DWN node pushes the status hash to the passenger's DWN node.

12. An electronic device, characterized in that, The system includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the Web5-based airline ticketing verification method according to any one of claims 8 to 11.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the airline ticketing verification method based on the Web5 architecture as described in any one of claims 8 to 11.

Images