Mobile identification techniques

Abstract

Techniques for mobile document provisioning are described herein. An example method includes a device receiving, from an inspection system of a first jurisdiction, a request for a mobile identification document of a second jurisdiction. The device may send the mobile identification document to the inspection system based on the request, the mobile identification document including a mobile identification document public key. The device may receive a mobile supplemental document, the mobile supplemental document including a mobile supplemental document public key derived from the mobile identification document public key, and the inspection system configured to derive the mobile supplemental document public key from the mobile identification document public key. The device may derive a mobile supplemental document private key corresponding to the mobile supplemental document public key, the derivation of the mobile supplemental document private key linking the mobile supplemental document to the mobile identification document.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of priority under 35 U.S.C.§119(e) to U.S. Non - Provisional Application No. 17 / 976,649, filed on October 28, 2022, the disclosure of which is hereby incorporated by reference in its entirety for all purposes. Technical Field

[0003] This application relates to the field of information security, and more particularly to mobile identification technology in said information security. Background Art

[0004] Digital documents may include readable content that can be presented to a third party via an electronic device. In a sense, digital documents can be regarded as a paperless alternative to original paper documents. Digital documents can be stored on electronic devices (such as mobile phones or tablets) and presented using these electronic devices. These digital documents can offer advantages over paper documents, including improved storage capacity, accessibility, organization, and security. Brief Description of the Drawings

[0005] Figure 1 Illustrates a system for issuing and presenting travel documents according to one or more embodiments.

[0006] Figure 2 Illustrates a data model of a mobile document according to one or more embodiments.

[0007] Figure 3 Is a process flow for authenticating a mobile document on a device according to one or more embodiments.

[0008] Figure 4 Is a process flow for authenticating a mobile document on a device according to one or more embodiments.

[0009] Figure 5 Is a process flow for authenticating a mobile document on a device according to one or more embodiments.

[0010] Figure 6 Is a process flow for authenticating a mobile document on a device according to one or more embodiments.

[0011] Figure 7 Is a process flow for authenticating a mobile document on a device according to one or more embodiments.

[0012] Figure 8 Illustrates the data exchange of a passport document between a device and an inspection system according to one or more embodiments.

[0013] Figure 9 An illustration of data elements of a mobile passport (mPass) according to one or more embodiments.

[0014] Figure 10 An illustration of a security mechanism for a mobile travel document according to one or more embodiments.

[0015] Figure 11 An illustration of a request and response sequence for a travel document according to one or more embodiments.

[0016] Figure 12 A process flow for linking a mobile travel record to a mobile passport according to one or more embodiments.

[0017] Figure 13 A block diagram of a mobile device according to one or more embodiments. DETAILED DESCRIPTION

[0018] In the following description, various embodiments will be described. For purposes of explanation, numerous specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will also be apparent to those skilled in the art that the embodiments may be practiced without these specific details. Additionally, well-known features may be omitted or simplified to prevent obscuring the embodiments described herein.

[0019] As technology allows people to control more aspects of their lives through their devices, people also want to manage more interactions in their interactions with third parties using their devices. One area of our daily lives that may be affected by technological advancements is travel. The proportion of the population that can now travel by air and especially internationally is larger than ever. Electronic devices can be used to handle commercial aspects such as airplane tickets, hotel reservations, and car rentals abroad.

[0020] Official travel documents or other identification documents such as passports, visas, and passport stamps cannot be used as travel documents that can be electronically stored in a mobile device and presented to government agencies. For example, an electronic passport cannot be presented to verify age, identity, or entry into a foreign jurisdiction. Electronically stored documents may present various problems such as verifying whether the travel document was generated by the correct government agency, verifying whether the government agency intended to supply the travel document on a particular device, and / or verifying how the reader device authenticates the travel document.

[0021] Embodiments of the present disclosure solve the problems described above by providing a mobile identity document (such as a mobile passport) on a user device that can be presented to a reader device (e.g., a secure terminal device, a point-of-sale device, etc.) for authentication. The reader device can authenticate that the mobile document originated from the correct issuing authority and request additional mobile supplementary documents such as other mobile travel documents (if necessary). For example, the user device can present mobile supplementary documents such as visas and other travel records to the reader device. The reader device can also authenticate the mobile visas and other mobile travel records for informed decision-making.

[0022] These mobile travel vouchers can consist of a set of mobile documents that can be linked together. For example, mobile documents can be linked together by using a mobile passport (mPass) identifier. Mobile documents (mDoc) for travel can include mobile identity documents such as mPass, which can be a digital passport issued by an issuing country, and a mobile visa (mVisa) that can be issued by the issuing country. The mPass can be cryptographically linked to the mVisa at a secure location on the user's device. The mDoc can also include a travel record (mTR) that can be issued by a country's inspection system (e.g., the reader device). The mTR can include a digital passport stamp since a digital passport cannot be stamped physically. The user device can store multiple mTRs, depending on how many countries the user has visited. Each mTR can also be cryptographically linked to the mPass. As described herein, the mPass can be considered the parent document, and the mVisa and mTR can be considered child documents. Although the present disclosure relates to passports, visas, and passport stamps, travel documents can also include other documents required to enter a foreign jurisdiction (such as work permits, residence cards, etc.) or even other documents that can be used to identify a user (e.g., concert admission tickets, bus passes, etc.).

[0023] Embodiments are described with respect to a mobile passport (mPass), a mobile visa (mVisa), and a mobile travel record (mTR). It should be understood that the techniques related to the embodiments described below (e.g., key derivation, linking) can also be applied to other mobile documents (mDoc). For example, vaccination cards, access credentials, identity credentials, loyalty credentials, insurance cards, property ownership and registration documents, and other suitable mobile documents. In these instances, the mobile identity document can be the primary form of identification, and the mobile supplementary document can be an additional document that can be linked to the mobile identity document (e.g., vaccination cards, access credentials, identity credentials, loyalty credentials, insurance cards, property ownership and registration documents).

[0024] Figure 1Illustrates system 100 for issuing and presenting travel documents according to one or more embodiments. Mobile device 102 can be a portable device that can be carried by a single individual. Mobile device 102 is operable to exchange information with another device without a wired connection. Mobile device 102 can include persistent and temporary local data storage means and an independent power source. Mobile device 102 can include one or more means for conveying information to the user (e.g., a display, a speaker, a vibration actuator). The user can be an "mDoc holder" as defined by ISO / IEC 18013-5 (to whom the mDoc is issued). Mobile device 102 can also include components for the user to interact with the device (e.g., a touch screen, buttons, motion sensors).

[0025] Mobile device 102 can store one or more mDocs (e.g., mVisa, mPass, mTR), where the mDoc can be as defined by ISO / IEC 18013-5. Mobile device 102 can communicate with passport issuing authority 104, which can supply mPass 106 to mobile device 102 upon presentation of appropriate documents. mPass 106 can represent a mobile digital version of an electronic passport. Mobile device 102 can also communicate with visa issuing authority 108, which can supply mVisa 110 to mobile device 102 upon presentation of appropriate documents. Generally, the passport issuing authority can be a government agency, and visa issuing authority 108 can be a government agency.

[0026] The mobile device 102 can also communicate with a reader 112 (e.g., an mDoc reader). The reader can be a device that can retrieve an mDoc as defined in ISO / IEC 18013-5 for authentication purposes. The reader 112 can be located at a border (e.g., a port) or a functional equivalent of a border (e.g., an airport). The user can use the mobile device 102 to present the mPass 106 and the mVisa 110 (if necessary) to the reader 112. The reader 112 can communicate with the mobile device 102 to authenticate the mPass 106 and the mVisa 110 (if required). In response to the authentication, the reader 112 can supply the mTR 114 to the mobile device 102. For example, the reader 112 can supply the mobile device 102 with a digital stamp similar to an ink stamp on a physical passport. The mPass 106, the mVisa 110, and the mTR 114 can be cryptographically linked by, for example, using the identifier of a parent document (e.g., the mPass). In this sense, subsequent readers can authenticate that each mDoc in the mDoc (mPass 106, mVisa 110, and mTR 114) is supplied to the same holder as the parent document holder (e.g., the mPass). The device reader can also use an anti-cloning mechanism (e.g., digital signatures and media access control techniques) as described in ISO / IEC 18013-5 to authenticate that the mDoc is being presented by the mobile device to which it was issued. In some instances, the user can have more than one passport (e.g., a dual national). In many instances, the user can travel to more than one foreign jurisdiction and can have multiple issued visas. Additionally, when the user moves from one foreign jurisdiction to another, the user can accumulate more than one mTR. The mobile device 102 can be operative to store multiple instances of the mDoc and cryptographically link each mDoc in the mDoc.

[0027] The reader 112 can include an inspection system that can request, receive, and authenticate the integrity and authenticity of the mPass 106, the mVisa 110, and / or the mTR 114, regardless of whether an online connection is available for the mobile device 102 or the reader 112. Additionally, the reader 112 can perform its functions without any relationship with the passport issuing authority 104 or the visa issuing authority 108.

[0028] The mobile device 102 and the reader 112 can communicate using an interface that can support the selective disclosure of information and data minimization. In this sense, neither device is provided with more information than is required to present and authenticate the mDoc. The user can use the mobile device 102 to present one or more mDocs and / or receive mTRs without having to switch devices. In other words, the user can hold the mobile device 102 in their hand and move the device close enough to the reader 112 to initiate a secure session to exchange information. The mobile device 102 can also be configured to allow the user to authorize the presentation of one or more mDocs. For example, the mobile device 102 can include a display that provides a prompt as to whether the user wishes to present one or more mDocs to the reader 112.

[0029] Figure 2 is an illustration 200 of a data model for mobile documents according to one or more embodiments. As illustrated, mPass 202, mVisa 204, and mTR 206 can be provisioned onto a mobile device (such as Figure 1 mobile device 102). mPass202 can include a set of mPass data elements 208 that can include holder name, date of birth, address, phone, passport issuing authority, passport number, and other appropriate information. The mPass data elements 208 can be arranged in groups called namespaces, as described in ISO / IEC 18013-5. For example, the mPass data elements 208 can include biometric data, such as facial images, fingerprints, iris scans. The biometric data can be grouped together using a biometric-related namespace (such as "holder biometrics"). Another grouping can be emergency contact information, such as contact name, address, and phone number. The emergency contact information can be grouped together using a namespace (e.g., "person to notify"). Each data element in the mPass data elements 208 can be cryptographically signed using the mPass issuer public key. The mPass public key 210 can be stored in a secure location described by ISO / IEC 18013-5 as a "secure area". A reader (e.g., reader 112) can use an interface to retrieve and authenticate the mPass public key 210.

[0030] mVisa 204 may include a set of mVisa data elements 214. The mVisa data elements 214 may include, for example, the name of the holder, the name of the visa issuing authority, and the visa document number. Similar to mPass 202, the mVisa data elements 214 may be divided into groups and identified by a namespace. Each data element in the mVisa data elements 214 and the mVisa public key 216 may be cryptographically signed with the mVisa issuer private key. The mVisa public key 216 may be included in a Mobile Security Object (MSO) 212, where the MSO is as described in ISO / IEC 18013-5. A reader (e.g., reader 112) may use an interface to retrieve the mVisa data elements 214 and the mVisa public key 216 and use the mVisa issuer public key to verify their signatures. The reader (e.g., reader 112) may use an interface to verify the trustworthiness of the mVisa issuer public key.

[0031] mTR 206 may also include a set of mTR data elements 220. The mTR data elements 220 may include, for example, the name of the holder, the name of the mTR issuing authority, and the mTR document number. Similar to mPass 202 and mVisa 204, the mTR data elements 220 may be divided into groups and identified by a namespace, as described in ISO / IEC 18013-5. Each data element in the mTR data elements 220 may be cryptographically signed with the mTR issuer public key. The reader (e.g., reader 112) may use an interface to verify the trustworthiness of the mTR issuer public key.

[0032] A key derivation process may be used to link mPass 202, mVisa 20, and mTR 206, where key derivation may include using a Key Derivation Function (KDF) to generate one or more keys using a master key (e.g., mPass public key 210). A mobile device (such as Figure 1The mobile device 102) may also store the mPass private key corresponding to the mPass public key 210. The mPass private key may be known only to the mobile device and is also stored in the secure area. In an instance where the visa issuing authority provisions an mVisa on the mobile device, a key derivation function (KDF) that can be described as an asymmetric elliptic curve key derivation and the mPass public key 210 as the parent key may also be used to generate the mVisa public key 216. The visa issuing authority may also include the mVisa public key in the MSO 218. Additionally, the mobile device may use the key derivation function for deriving the mVisa public key and the mPass private key as the parent key to generate the mVisa private key. Thus, although the mVisa public key 216 is known to the visa issuing authority, the corresponding mVisa private key is unknown to the visa issuing authority. Similarly, if an institution provisions an mTR 206 to the mobile device, the institution may use the KDF and the mVisa public key 216 as the parent key to create the mTR public key 222. Further, the mobile device may use the KDF and the mVisa private key as the parent key to generate the mTR private key. Again, the mTR issuing authority may know the mTR public key 222, but only the device may know the mTR private key.

[0033] A reader (such as Figure 1 reader 112) may use various methods to check the mDocs provisioned in the mobile device. For example, the reader may use a "forward convention" or a "reverse convention". In some embodiments, the reader may use sequential requests to request each mDoc required to complete a transaction. For example, if a user is attempting to enter a foreign jurisdiction, the reader may first request the mPass, and then, if the mPass is authenticated, request the mVisa, and then, if the mVisa is authenticated, request the first mTR, and so on. Thus, the user may present the requested mDocs to the reader, wait for the authentication of the mDocs, and then keep presenting the subsequently requested mDocs until the authentication process is complete. In other embodiments, the reader may send a modified message to the mobile device in a single request to request all the required mDocs. For example, if the reader needs to view both the mPass and the mVisa, instead of requesting the two mDocs separately, the two mDocs are requested via the modified message.

[0034] Figure 3is a process flow 300 for authenticating a mobile document on a device according to one or more embodiments. Although the operations of processes 300, 400, 500, 600, 700, and 1200 are described as being performed by a general-purpose computer, it should be understood that any suitable device (e.g., a mobile device, a reader device) can be used to perform one or more of the operations of these processes. Processes 300, 400, 500, 600, 700, and 1200 (described below) are illustrated as logical flowcharts, and each operation of these logical flowcharts represents a sequence of operations that can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, an operation represents computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the operation. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a particular function or implement a particular data type. The order in which the operations are described is not intended to be construed as limiting, and any number of the described operations can be combined in any order and / or in parallel to implement the described process.

[0035] Figures 3 to 5 relates to a forward convention that may be optimal for presenting the mDoc in person, where proximity protocols such as Near Field Communication (NFC), Bluetooth, and Wi-Fi can be used. Generally, a user action can activate a passport application on the device, and the device and the inspection system can share convention data regarding the sending method and how to set up a secure session as defined by ISO / IEC 18013-5. For example, the user action can be an NFC tap or a QR code scan. The device can also use mDoc requests and mDoc responses to exchange information. An mDoc request can indicate whether the requested document is critical (e.g., necessary for entry into a jurisdiction) or conditional (e.g., optional for entry into a jurisdiction). An mDoc request can also indicate that the value of a data element must be equal to a certain value or can indicate that the value of a data element must be equal to one of a set of values.

[0036] At 302, the user can perform an action to initialize a passport application on a device (such as Figure 1 the mobile device 102). The action can be, for example, manually touching a passport application icon displayed on the device using a touch screen. Both the device and the inspection system can be equipped with short-range communication technologies such as NFC technology, Radio Frequency Identification (RFID), Wi-Fi, or Bluetooth technology. After touching the passport application icon, the user's device and the inspection system can detect each other based on proximity and can initiate a secure session between them.

[0037] At 304, the passport application can be initialized based on the user's action at 302. In some instances, the passport application can be displayed on the device based on the initialization. By initializing the passport application, the application can transition from a sleep state to a wake state to perform its functions.

[0038] At 306, the device and the inspection system can share convention data. The convention data can be exchanged according to a short-range transmission protocol and used by the device and the inspection system to identify each other. For example, the device and the inspection system can exchange the convention data necessary to perform, for example, handshake authentication, challenge-response authentication, password authentication, or other information for verifying each other.

[0039] At 308, the device and the inspection system can establish a secure session. Both the device and the inspection system can include an encryption protocol such that any information to be sent is encrypted before being sent.

[0040] At 310, the inspection system can request mPass data from the device. The request can be in the form of an encrypted message sent by the inspection system to the device through a secure channel.

[0041] At 312, the device can transmit mPass data to the inspection system. In some embodiments, the device can be configured to require user consent before providing the mPass data. Consent can be received, for example, by displaying a prompt asking the user to consent to sharing the mPass data with the inspection system.

[0042] At 314, the inspection system can receive the mPass data, where the mPass data can be a mobile passport and be regarded as the parent document. The inspection system can receive the mPass data from the device via a secure channel.

[0043] At 316, the inspection system can determine whether a sub-document is required. For example, to enter some jurisdictions, additional mDocs (e.g., visas, work permits) are required in addition to the passport. This mDoc can be regarded as a sub-document of the parent document.

[0044] At 318, if the inspection does require a sub-document, the inspection system can transmit a message to the device requesting the additional sub-document. For example, the inspection system can use a secure channel to transmit a request for mVisa to the device.

[0045] At 320, the device can transmit the requested sub-document to the inspection system. In some embodiments, the device can also be configured to require user consent before providing the requested sub-document. For example, the device can transmit the requested sub-document via a secure channel based on receiving a signal indicating user consent.

[0046] At 322, the inspection system can receive a requested sub-document from the device. For example, the inspection system can receive a requested mVisa from the device via a secure channel.

[0047] The method then returns to 316, where the inspection system determines whether additional sub-documents (e.g., mTR) are needed. An additional sub-document can be, for example, a work permit. If the inspection system determines that additional sub-documents are needed, the method repeats steps 318 to 322 for that additional sub-document.

[0048] If at 316 the inspection system determines that no sub-documents are needed from the device, the inspection system can determine whether it needs to issue a sub-document to the device (e.g., sub-mDoc). For example, the determination can be "Does the inspection system need to issue a passport stamp to the device?"

[0049] If the answer to the determination at 324 is no, the inspection system and / or the device can end this process and start another process at 326.

[0050] However, if the answer to the determination is yes, at 328 the inspection system can derive the public key of the sub-document. For example, the inspection system can use a key derivation function (KDF) and the public key of the parent document to derive the public key of the sub-document.

[0051] At 330, the inspection system can issue a sub-document (e.g., mTR, mVisa) to the device. For example, the inspection system can send the sub-document to the device via a secure channel.

[0052] At 332, the device can add the sub-document to the set of mDocs stored in a secure location on the device. The sub-document can be cryptographically linked to the parent document (e.g., mPass). The device can also derive the private key of the sub-document from the private key of the parent document. The private key can also be stored in a secure location on the device.

[0053] After deriving the private key of the sub-document, the inspection system and / or the device can end this process and start another process at 326.

[0054] Figure 4 is a process flow 400 for authenticating mobile documents on a device according to one or more embodiments. At 402, the user can perform an action to initialize a passport application on a device (such as Figure 1 the mobile device 102). The action can be, for example, using a touch screen to manually touch the passport application icon displayed on the device. Both the device and the inspection system can be equipped with short-range communication technologies such as NFC technology, RFID, or Bluetooth technology. The user's device and the inspection system can detect each other based on proximity and can initiate a secure session between them.

[0055] At 404, the passport application can be initialized based on the user's action at 402. In some instances, the passport application can be displayed on the device based on the initialization. By initializing the passport application, the application can transition from a sleep state to a wake state to perform its functions.

[0056] At 406, the device and the inspection system can share convention data. The convention data can be exchanged according to a short-range transmission protocol and used by the device and the inspection system to identify each other. For example, the device and the inspection system can exchange the convention data necessary to perform authentication such as handshake authentication, challenge-response authentication, password authentication, or other information for verifying each other.

[0057] At 408, the device and the inspection system can establish a secure session. Both the device and the inspection system can include an encryption protocol such that any information to be sent is encrypted before being sent.

[0058] At 410, the inspection system can request all required mDocs. In other words, the inspection system can be configured to request all mDocs in a single message instead of making a new determination of the need for additional sub-documents after receiving the parent document. For example, the inspection system can request "any document whose document type starts with org.iso.mPass, with at least 1 copy required" or "any document whose document type is org.iso.mVisa and has namespace / issuance information". For example, the inspection system can request both mPass and mVisa in a single message instead of sending separate messages to request mPass and mVisa (as Figure 3 illustrated).

[0059] At 412, the device can transmit the requested mDocs to the inspection system. For example, if the inspection system requests mPass and mVisa, the device can transmit two mDocs to the inspection system. The mDocs can be cryptographically linked in the device. In some embodiments, the device can also be configured to require user consent before providing the requested mDocs. For example, the device can transmit the requested mDocs through a secure channel based on receiving a signal indicating user consent.

[0060] At 414, the inspection system can receive the requested mDocs from the device. For example, the inspection system can receive the requested mPass and mVisa from the device through a secure channel.

[0061] At 416, the inspection system can determine whether another mDoc is needed. For example, based on the received mDocs, the inspection system can determine that additional mDocs (such as a work permit) are needed. This mDoc can be regarded as a sub-document of the parent document.

[0062] If the inspection system determines that another mDoc is needed, at 418, the inspection system may transmit another query to the device.

[0063] At 420, the device may transmit the requested mDoc to the inspection system. For example, if the inspection system requests a mobile work permit, the device may transmit the mobile work permit to the inspection system. The mDoc may be cryptographically linked in the device. In some embodiments, the device may also be configured to require user consent before providing the requested mDoc. For example, the device may transmit the requested mDoc over a secure channel based on receiving a signal indicating user consent.

[0064] At 422, the inspection system may receive the requested mDoc from the device. For example, the inspection system may receive the requested mobile work permit from the device over a secure channel.

[0065] At 424, the inspection system may determine whether to issue an mTR to the device. For example, the inspection system may determine whether to stamp a passport for the device. For illustrative purposes, process flow 400 continues at Figure 5 above.

[0066] Figure 5 is a process flow 500 for authenticating a mobile document on a device according to one or more embodiments. At 502, the inspection system may determine whether to issue an mTR to the device. For example, the inspection system may determine whether to stamp a passport for the device. It should be understood that 502 may be the same step as Figure 4 424.

[0067] If the inspection system determines to issue an mTR (e.g., a passport stamp), at 504, the inspection system may derive the public key of the mTR. For example, the inspection system may use a key derivation function (KDF) and the public key of the parent document to derive the public key of the mTR.

[0068] At 506, the inspection system may issue the mTR (e.g., a passport stamp) to the device. For example, the inspection system may send the passport stamp to the device over a secure channel.

[0069] At 508, the device may add the mTR to the set of passport mDocs. The mDocs may be stored in a secure location on the device. Each mDoc in the mDocs may be cryptographically linked in the device. The device may also derive the private key of the mTR. For example, the device may use a KDF and the private key of the parent document to derive the private key of the mTR. The private key may also be stored in a secure location on the device.

[0070] At 510, once the device stores the mTR private key or it has been determined at 502 not to issue an mTR, the inspection system and / or the device may end this process and start another process.

[0071] Figure 6 is a process flow 600 for authenticating a mobile document on a device according to one or more embodiments. It should be understood that in Figures 3 to 6 the case of a forward convention, Figure 6 a reverse convention is involved, where the inspection system shares information about the secure session setup and requests data from the device. The device can also use the mDoc response to respond to the request.

[0072] At 602, the user can perform an action to initialize a passport application on a device (such as Figure 1 mobile device 102). This action can be, for example, using a touch screen to manually touch the passport application icon displayed on the device.

[0073] At 604, the inspection system can prepare a request for the mPass and prepare inspection system convention data. The inspection system convention data can include information for establishing a secure session between the device and the inspection. For example, the convention data can include information related to handshake authentication, challenge - response authentication, password authentication, or other information for verifying each other.

[0074] At 606, the inspection system can send the convention information and the request for the mPass to the device. The device can include a passport application executed on the device. The passport application can be operable to store one or more mDocs for the user's travel.

[0075] At 608, the device can authenticate the identity of the inspection system. The device can employ a public key infrastructure (PKI) system to authenticate the reader certificate.

[0076] At 610, the device can generate a response to the request from the inspection system. In response to receiving the request from the inspection system, the device can create an mDoc response message including the mPass and any necessary key information. For example, the mDoc response can include critical information that the inspection system can use to authenticate the mPass. The device can also use an encryption protocol to encrypt the response.

[0077] At 612, the device can return the encrypted response to the inspection system. For example, the device can send the encrypted mDoc response to the inspection system via a secure channel.

[0078] At 614, the inspection system can receive the response from the device and can inspect the mPass. The response can be an mDoc response and includes the mPass. The inspection system can inspect the data elements included in the mPass to determine whether the mPass includes any required data elements and whether the mPass is associated with the user and the user device.

[0079] At 616, the inspection system can determine whether any mVisa is required.

[0080] At 618, the inspection system can transmit a request for mVisa from the device. The request can be based on the inspection system determining that mVisa is needed. For example, the inspection can transmit a second mDoc request to the device. The second mDoc request can be encrypted according to an encryption protocol and sent to the device via a secure channel.

[0081] At 620, the device can transmit mVisa to the inspection system. The mVisa can be stored in a secure location of the device that executes the passport application. The device can retrieve the mVisa from the secure location and encrypt the mVisa including any associated keys. The device can then send the encrypted mVisa to the inspection system via a secure channel.

[0082] At 622, the inspection system can receive mVisa from the device. For example, the inspection can receive an encrypted mDoc response from the device. The inspection system can decrypt the encrypted mDoc response and inspect the mVisa.

[0083] At 624, the inspection system can determine whether any sub-documents are needed from the device. The sub-documents can be, for example, a work permit or a vaccination status card.

[0084] If the inspection system determines that an mTR is needed, at 626, the inspection system can transmit a request for the mTR. For example, the inspection system can transmit another mDoc request for the mTR to the device. The mDoc request can be encrypted based on an encryption protocol and sent using a secure channel.

[0085] At 628, the device can send the requested mTR to the inspection system. For example, the device can retrieve the mTR from a secure location of the device. The device can also encrypt the mTR and use a secure channel to send the mTR as an mDoc response to the inspection system.

[0086] At 630, the inspection system can receive the mTR from the device. For example, the inspection system can decrypt the encrypted mTR and inspect the mTR for authentication.

[0087] At 632, the inspection system and / or the device can end this process and start another process.

[0088] Figure 7 is a process flow 700 for authenticating a mobile document on a device according to one or more embodiments. At 702, the user can perform an action to initialize the passport application on a device (such as Figure 1 the mobile device 102). The action can be, for example, using a touch screen to manually touch the passport application icon displayed on the device.

[0089] At 704, the inspection system can prepare a request (e.g., a request for an mDoc such as mPass) and prepare inspection system convention data. The inspection system convention data can include information for establishing a secure session between the device and the inspection system. For example, the convention data can include information related to handshake authentication, challenge - response authentication, password authentication, or other information for verifying each other.

[0090] At 706, the inspection system can send the convention information and the request to the passport application executed on the device. The passport application can be operative to store one or more mDocs for the user's travel.

[0091] At 708, the passport application can authenticate the identity of the inspection system. For example, the passport application can be pre - configured with an identifier associated with the inspection system. The passport application can compare the pre - configured device identifier with the device identifier included in the convention data.

[0092] At 710, the device can generate a response to the request from the inspection system. In response to receiving the request from the inspection system, the device can create an mDoc response message including mPass and any necessary key information. For example, the mDoc response can include key information that the inspection system can use to authenticate mPass. The device can also use an encryption protocol to encrypt the response.

[0093] At 712, the device can return the encrypted response to the inspection system. For example, the device can send the encrypted mDoc response to the inspection system through a secure channel.

[0094] At 714, the passport application can receive the response from the device and can inspect mPass. The response can be an mDoc response and include mPass. The passport application can inspect the data elements included in mPass to determine whether mPass includes any required data elements and whether it is associated with the user and the user device.

[0095] At 716, the inspection system can determine whether any other documents are required. For example, the inspection can determine whether another mDoc such as mTR is required for entry into the jurisdiction.

[0096] At 718, the inspection system can transmit a request for an additional document (e.g., mTR) from the device. The request can be based on the inspection system determining that an additional document is required. For example, the inspection can transmit a second mDoc request to the device. The second mDoc request can be encrypted according to an encryption protocol and sent to the device through a secure channel.

[0097] At 720, the device may transmit additional documents to the inspection system. The additional documents may be stored in a secure location of the device executing the passport application. The device may retrieve the additional documents from the secure location and encrypt the documents including any associated keys. The device may then send the encrypted documents to the inspection system over a secure channel.

[0098] At 722, the inspection system may receive the additional documents from the device. For example, the inspection system may receive an encrypted mDoc response from the device. The inspection system may decrypt the encrypted mDoc response and inspect the additional documents. For example, the inspection system may analyze one or more data elements of the additional documents to determine whether the user may enter a foreign jurisdiction.

[0099] At 724, the inspection system and / or the device may end this process and start another process.

[0100] Figure 8 Is an illustration 800 of the data exchange between a passport document and an inspection system according to one or more embodiments. The issuing authority of the mPass (e.g., a government agency) may supply the mPass 804 in a secure area 806 of a device such as a mobile device. The issuing authority of the mVisa 808 (e.g., a government agency) may supply the mVisa in the secure area 806 of the device. The secure area 806 may also store one or more mTRs 812 (e.g., passport stamps, work permits) supplied by an authorized entity.

[0101] The mobile device and the inspection system may use a data format such as Concise Binary Object Representation (CBOR) or JavaScript Object Notation (JSON) to exchange messages (e.g., mDoc requests and mDoc responses). In some embodiments, the data exchange illustrated between Figure 8 and the device and the inspection system may be as described in ISO / IEC 18013-5. CBOR may be a binary serialization format comparable to JSON. CBOR may allow serialization into a binary format that may be smaller and faster to generate and parse by the device and the inspection system. It should be understood that other message exchange formats are possible.

[0102] The inspection system 814 may send a request 816 for a document to the device. For example, the inspection system may transmit a request for the mPass 804 to the device. The request 816 may be an mDoc request formatted according to a data format (e.g., CBOR format). The request may undergo a session encryption process 818.

[0103] The encrypted request can be sent in a technical sending format. As described, the device and the inspection system can communicate via various sending protocols (e.g., using Bluetooth and / or Bluetooth LE standards, NFC, etc.). The device can process the request through the decryption process 822. The decrypted request 824 can be parsed by the device.

[0104] Based on the request, the device can generate a response 824 (e.g., an mDoc response). The response 824 can be in CBOR format. For example, if the request is for mPass 804, the device can generate an mDoc response including mPass 804. The device can use the session decryption process 822 to encrypt the response.

[0105] The encrypted response can be sent in the sending technical format 820 to the inspection system. The inspection system 814 can use the session decryption process 818 to decrypt the encrypted response. The inspection system 814 can analyze the decrypted response. For example, the inspection system 814 can receive the decrypted response in CBOR format. The inspection system 814 can then analyze the data elements in mPass 804 for determination, such as for age verification or entry into a jurisdiction.

[0106] Figure 9 Illustrations of the data elements of mPass 900 according to one or more embodiments are shown. The mPass can include one or more namespaces that identify groups of data elements. Each data element can relate to information for determination (e.g., for verifying age or identity or determining whether an individual can enter a jurisdiction). As shown, the first namespace 902 (e.g., holder data) can be associated with a first set of data elements 904 of the passport holder's identification information. For example, the data elements can include name (holder_name), date of birth (date_of_birth), passport issuing authority (issuing_authority), passport number (document_number), holder signature (displayed_signature), and nationality (nationality). These data elements can be defined as in the International Civil Aviation Organization (ICAO) document 9303-3 or other documents. It should be understood that additional data elements can be included in the first set of data elements 904. For example, the first set of data elements can include an age_over_xx data element, where the data element is defined as in ISO 18013-5. For example, the data elements can also include address, phone number, occupation, title, personal profile, other travel documents, regulatory information, observation remarks, tax refund requirements, portrait specifications, document code, nationality alternative data, displayed portrait, and people to be notified.

[0107] In addition, it should be understood that although mPass is illustrated, mVisa and mTR may also be organized similarly to mPass. The mVisa data elements may include, for example, the issuing organization, visa type, number of entries, duration of stay, passport number, territorial information, place of issue, date of issue, expiration date, document number, additional information, full name, primary identifier, secondary identifier, gender, date of birth, and nationality. The mTR data elements may include entry / exit status, visa approval, data, inspection agency, inspector number, type of transportation, duration of stay conditions, and passport number.

[0108] A second namespace 906 (e.g., the person to be notified) may be associated with a second set of data elements 908 of emergency contact information. For example, the second set of data elements 908 may include the emergency contact name (Name), the emergency contact phone number (Phone), the emergency contact physical and / or email address (Address), and the emergency contact establishment date (Date). The data elements in the second set of data elements may be defined as in ICAO document 9303-X.

[0109] A third namespace 910 (e.g., holder biometrics) may be associated with a third set of data elements 912 of biometric data. Each biometric data element may contain one of the user's biometrics encoded as described in the International Civil Aviation Organization document 9303, rather than as a Tag Length Value (TLV). This may be the equivalent of the data group 2 (DG2) to DG4 biometric templates. The third set of data elements 912 may include a CBOR-encoded structure corresponding to the face of the holder, which may be input into a face recognition system. Each biometric record may include multiple records with different biometric encodings. For example, the third set of data elements 912 may include facial features (Face), fingerprint scans (Fingerprint), iris scans (Iris), and other biometric data (Other) that may be used to identify the holder. The data element for the face may be a face image used in machine-assisted identity verification. If there are multiple records of the face, the most recent international interoperability may be the first entry.

[0110] A fourth namespace 914 (e.g., backward compatibility) may be associated with a fourth set of data elements 916 to achieve backward compatibility. The fourth set of data elements 916 may contain data elements having the content of data groups (DG) as defined by the ICAO document 9303. For example, the fourth set of data elements 916 may include data elements of DG1, DG2, DG11, and Others (e.g., DG16). Each DG may be a logical grouping of data elements that may be used to digitally store a travel document after the travel document has been issued and during the validity period of the document.

[0111] The mPass can also be associated with a public key 918. The public key can be generated by the issuer of the mPass.

[0112] In some embodiments, the device and the inspection system can implement a security mechanism as defined in ISO 18013-5. The security mechanism can provide anti-counterfeiting protection. Each mDoc in the mDoc can be signed by the issuer of the mDoc. The degree of anti-counterfeiting protection can be based on the degree to which the issuer's key is protected. The security mechanism can provide anti-cloning protection. The device can use the private key of the device to generate a signature on the session data. The corresponding inspection system with the public key can implement trust in the device public key signed by the issuer. The degree of anti-cloning protection can be based on the degree to which the device private key is protected. The security mechanism can prevent eavesdropping during a transaction. The communication between the device and the inspection system can be encrypted and authenticated. For example, by using the verification of the digital signature on the session data, a man-in-the-middle attack can be detected by the inspection system. The security mechanism can provide inspection system authentication. For example, a reader certificate and a signature created by the reader using the corresponding private key. The reader certificate can be signed by a certificate authority trusted by the device.

[0113] In addition to the security mechanism described above, the mDocs can be linked together based on two components: (1) the passport number signed by the issuer in both the parent document (mPass) and the child documents (mVisa, mTR), and (2) the dynamic relationship between the mDocs derived from the key. In particular, the child document can have a key derived from the parent key.

[0114] First, if the mPass has a document number signed by the issuer, the mVisa and mTR can be linked to a specific mPass by including the document number (e.g., passport number). The strength of the link based on the document number can be comparable to the document number.

[0115] Second, the device (e.g., mobile device, inspection system) can use an export function to generate a new child key (e.g., mVisa key, mTR key) from the parent key (e.g., mPass key). For a given child public key, the corresponding child private key can only be derived by the holder of the parent private key. Even if a malicious actor obtains the parent public key and the corresponding child public key, the actor cannot derive the child private key using only these two keys. The actor can only derive the child private key using the parent private key. The relationship between the parent key and the corresponding child key can be used to confirm the link between the parent document and the child document.

[0116] A variety of export functions can be used to derive child keys from a parent key. A first derivation function can be used to generate a child public key from a parent public key. This can be used to allow a checking system to issue a child document that is cryptographically linked to a parent document without having to verify key attestation and key residency credentials in a secure area of a mobile device. A second export function can be used to derive a child private key from a parent private key. To issue a new child document, a new public key can be computed from a parent key (e.g., an mPass key). The issuer of the child document can use the key export process to create the new public key. Additionally, authentication / session key establishment properties as described in ISO 18013-5 (e.g., Elliptic Curve Diffie-Hellman protocol for Media Access Control (MAC) algorithms, unforgeability of signatures) can be retained. A symmetric secret (SK) parameter can be jointly generated between the checking system and the device.

[0117] Given a highest-level public / private key pair (which we call {d, P}) and a symmetric secret (SK), a device or a checking system can define two derived integers {u_i, v_i} = KDF(SK, i). Then, the device or the checking system can perform the export of the public key as follows: P_i = u_i.P + v_i.G (where G is the generating point of the curve). The corresponding private key can be derived as: d_i = u_i*d + v_i. The correctness P_i == d_i.G can be verified.

[0118] For each new export, a new value of SK can be generated. If SK is compromised (extracted), an attacker may be able to link the keys together, but the attacker can neither perform the Elliptic Curve Diffie-Hellman (ECDH) key protocol nor sign with the Elliptic Curve Digital Signature Algorithm (ECDSA), which allows the device or the checking system to store SK and export the public key outside the security domain where the secret key {d} is disposed of.

[0119] Figure 10 is an illustration of a security mechanism for mobile travel documents according to one or more embodiments. Attested key attestation can occur, where the properties of the mPass public key and the mPass private key can be verified. For example, an mPass issuer authority (IA) 1002 can verify that the mPass public key 1012 corresponds to the mPass private key 1004 stored in a secure area of a device 1008 (e.g., a mobile device). Based on this verification, the mPass IA can supply the mPass 1010 to the device 1008. The mPass 1010 can include the previously verified mPass public key 1012 in the mPass MSO, where the MSO is a data structure signed by the mPass issuer. This step can occur when the user is having the mPass IA 1002 supply the mPass 1010 on the device 1008.

[0120] Finally, the user will want to use the mPass 1010 to, for example, verify age, verify identity, or enter a foreign jurisdiction. The user may use the device 1008 to initiate a secure session with the inspection system (IS) 1014. For example, part of the purpose of the secure session may be to receive a passport stamp. For example, the user may present their device 1008 to the inspection system 1014, such as at an airport or shipping port in a foreign jurisdiction, to obtain the stamp. The inspection system 1014 may retrieve the mPass public key 1012, use the derived data, and apply a derivation function to establish a new public key 1016. The new public key 1016 may be used by the inspection system 1014 to provision the mTR 1018 (e.g., passport stamp) on the device 1008. The mTR may also include information related to the derivation function in addition to the stamp data, such as key metadata, derived data, and data elements. The inspection system 1014 may also sign the mTR including the key metadata, derived data, and data elements using the IS private key 1020. The public key corresponding to the IS private key 1020 may be used to verify the mTR1018. Thus, a subsequent inspection system (e.g., when the user travels to another country) may use the public key to verify the authenticity of the mTR based on the signature included in the mTR 1018, where this public key corresponds to the IS private key 1020.

[0121] In addition to the parent private key 1004, the device may also use the derived data included in the mTR and derive the mTR private key 1022. The derived private key 1022 may be used in subsequent transactions to prove that the mTR has not been cloned and stored on the device. For example, if the mTR1018 has been cloned and stored on a new device, the signature of the mTR 1018 may be verified by the IS using the mTR issuer public key. However, the new device will not have access to the mTR private key 1022 because the mTR private key 1022 can only be derived on the original device 1008.

[0122] Figure 11 Illustrates a request and response sequence for a travel document according to one or more embodiments. The device 1102 and the inspection system 1104 may use a short-range transmission protocol to establish a secure session with each other. The short-range transmission protocol may be, for example, NFC, Bluetooth, or Wi-Fi.

[0123] The inspection system 1104 may transmit a request for the mPass 1106, such as an mDoc request, to the device 1102. For example, the inspection system may be set up for entry into a foreign jurisdiction that requires a passport. The mPass 1106 may include the mPass public key 1108 corresponding to the mPass private key 1110. The mPass public key 1108 may have been signed by the issuing authority of the mPass 1106. The mPass private key may be stored in a secure area of the device 1102.

[0124] Device 1102 may use the mPass private key 1110 to sign the mPass 1106 and send the mPass 1106 to the inspection system 1104. In some embodiments, the sending may be an mDoc response encrypted and formatted using the CBOR format.

[0125] The inspection system 1104 may receive the mPass 1106 from the device 1102 via a secure channel. The inspection system 1104 may also decrypt the message from the device 1102. The inspection system 1104 may trust the mPass public key 1108 because the mPass public key has been signed by the mPass issuing authority. The inspection system 1104 may also use the mPass public key 1108 to verify the signature of the device. Based on verifying the signature of the device, the inspection system 1104 may verify that the mPass was originally issued to the same device presenting it and start inspecting the data elements included in the mPass 1106.

[0126] Figure 12 is a process flow 1200 for linking a mobile supplementary document to a mobile identity document (such as a mobile passport) according to one or more embodiments. At 1202, the method may include a user device receiving a request for a mobile identity document of a second jurisdiction from an inspection system of a first jurisdiction, the user device including a mobile identity document private key. The user device may be the user's mobile device. The first jurisdiction may be, for example, the destination country, and the second jurisdiction may be, for example, the country of departure. The process may be initialized by a passport application executed on the user device. The user device and the reader may establish a connection when in close proximity and communicate with each other using a short-range transmission protocol (such as NFC, Bluetooth, or Wi-Fi).

[0127] At 1204, the method may include the user device sending the mobile identity document to the inspection system at least partially based on the request, the mobile passport including a mobile identity document public key. In some embodiments, the user is provided with the opportunity to manually input whether to provide the mobile identity document to the inspection system. The sending may be based on receiving this consent.

[0128] At 1206, the method may include the user device receiving a mobile supplementary document, such as a mobile travel record, from the inspection system, the mobile supplementary document including a mobile supplementary document public key derived from the mobile identity document public key, the inspection system being configured to derive the mobile supplementary document public key from the mobile identity document public key. The mobile supplementary document may be, for example, a work permit, a passport stamp, or other travel-related document. The inspection system may have received the mobile identity document public key and used a key derivation function to derive the mobile supplementary document public key.

[0129] At 1208, the method may include the user equipment exporting a mobile supplementary document private key corresponding to the mobile supplementary document public key, the mobile supplementary document private key being derived from the mobile identity document private key, the derivation of the mobile supplementary document private key from the mobile identity document private key linking the mobile supplementary document to the mobile identity document. The user equipment may use a key derivation function to export the mobile supplementary document private key. The mobile supplementary document private key and the mobile identity document private key may be stored in a secure area of the user equipment and separated from the mobile identity document and the mobile supplementary document. In this sense, only the device has access to either private key. Thus, even if the mobile identity document and / or the mobile supplementary document are cloned and stored on another device, the new device will not have access to the private key and will not be able to be authenticated by a subsequent inspection system.

[0130] Figure 13 is a block diagram of a mobile device 1300 according to some embodiments. The mobile device 1300 may implement any or all of the mobile device functions, behaviors, and capabilities described herein, as well as other functions, behaviors, and capabilities not explicitly described. The mobile device 1300 may include a processing subsystem 1310, a storage device 1312, a user interface 1314, a communication interface 1316, a security element 1318, and a cryptographic logic module 1320. The mobile device 1300 may also include other components (not explicitly shown), such as a battery, a power supply for the mobile device, and other components operable to provide various enhanced capabilities. In various embodiments, the mobile device 1300 may be implemented in a desktop computer, a laptop computer, a tablet computer, a smart phone, a wearable computing device, or other systems having any desired form factor.

[0131] The storage device 1312 may be implemented, for example, using a disk, flash memory, or any other non-transitory storage medium or combination of media, and may include volatile media and / or non-volatile media. In some embodiments, the storage device 1312 may store one or more application programs and / or operating system programs to be executed by the processing subsystem 1310, including programs for implementing any or all of the operations performed by the mobile device described herein. For example, the storage device 1312 may store a unified mobile device application that may read attachment definition records and generate a graphical user interface for controlling the attachment based on the information therein. In some embodiments, part (or all) of the mobile device functions described herein may be implemented in an operating system program rather than an application program. In some embodiments, the storage device 1312 may also store application programs designed for a specific attachment or a specific class of attachments (e.g., a passport application).

[0132] The user interface 1314 may include input devices such as a touchpad, a touch screen, a scroll wheel, a click wheel, a dial pad, buttons, switches, a keypad, a microphone, etc.; and output devices such as a video screen, indicator lights, speakers, a headphone jack, etc., along with supporting electronics (e.g., a digital-to-analog converter or an analog-to-digital converter, a signal processor, etc.). A user may operate the input devices of the user interface 1314 to invoke the functions of the mobile device 1300 and may view and / or listen to the output from the mobile device 1300 via the output devices of the user interface 1314.

[0133] The processing subsystem 1310 may be implemented as one or more integrated circuits, such as one or more single-core or multi-core microprocessors or microcontrollers, examples of which are known in the art. In operation, the processing system 1310 may control the operation of the mobile device 1300. In various embodiments, the processing subsystem 1310 may execute various programs in response to program code and may maintain multiple simultaneously-executing programs or processes. At any given time, some or all of the program code to be executed may reside in the processing subsystem 1310 and / or a storage medium such as the storage device 1312.

[0134] Through appropriate programming, the processing subsystem 1310 may provide various functions for the mobile device 1300. For example, in some embodiments, the processing subsystem 1310 may implement the various processes (or portions thereof) described above as implemented by the mobile device. The processing subsystem 1310 may also execute other programs (including programs stored in the storage device 1312) to control other functions of the mobile device 1300. In some embodiments, these programs may interact with an accessory, for example, by generating messages to be transmitted to the accessory and / or by receiving messages from the accessory. Such messages may conform to the unified accessory protocol described above.

[0135] The communication interface 1316 may provide voice and / or data communication capabilities for the mobile device 1300. In some embodiments, the communication interface 1316 may include: radio frequency (RF) transceiver components for accessing wireless voice and / or data networks (e.g., using cellular phone technology, data network technologies such as 3G, 4G / LTE, 5G, Wi-Fi (IEEE 802.11 series standards) or other mobile communication technologies or any combination thereof), components for short-range wireless communication (e.g., using Bluetooth standards and / or Bluetooth LE standards, NFC, RFID, WiFi, etc.), and / or other components. In some embodiments, in addition to or instead of the wireless interface, the communication interface 1316 may provide wired network connectivity (e.g., Ethernet). The communication interface 1316 may be implemented using a combination of hardware components (e.g., driver circuits, antennas, modulators / demodulators, encoders / decoders, and other analog signal processing circuits and / or digital signal processing circuits) and software components. In some embodiments, the communication interface 1316 may support multiple communication channels concurrently using the same transmission or different transmissions.

[0136] The secure element 1318 may be an integrated circuit or the like that can securely store cryptographic information (e.g., a secure area) for the mobile device 1300. Examples of information that may be stored within the secure element 1318 include the long-term public and private keys of the mobile device and a list of paired accessories (e.g., a lookup table that maps accessory IDs to the accessory long-term public keys of the accessories for which the pairing setup or pairing addition process has been completed as described above).

[0137] In some embodiments, cryptographic operations may be implemented in a cryptographic logic module 1320 that communicates with a secure element 1318. Physically, the cryptographic logic module 1320 may be implemented in the same integrated circuit as the secure element 1318 or a different integrated circuit (e.g., a processor in the processing subsystem 1310) as needed. The cryptographic logic module 1320 may include various logic circuits (fixed or programmable as needed) that implement or support the cryptographic operations of the mobile device 1300 (including any or all of the cryptographic operations described above). The secure element 1318 and / or the cryptographic logic module 1320 may appear as a "black box" to the rest of the mobile device 1300. Thus, for example, the communication interface 1316 may receive messages in encrypted form that it cannot decrypt and may simply deliver the messages to the processing subsystem 1310. The processing subsystem 1310 may also be unable to decrypt the messages, but it may recognize the messages as encrypted and deliver them to the cryptographic logic module 1320. The cryptographic logic module 1320 may decrypt the messages (e.g., using information extracted from the secure element 1318) and determine which information to return to the processing subsystem 1310. Thus, certain information may be available only within the secure element 1318 and the cryptographic logic module 1320. If the secure element 1318 and the cryptographic logic module 1320 are implemented on a single integrated circuit that only executes code from an internal secure repository, this may make information extraction very difficult and thus provide a high level of security. Other specific implementations are possible.

[0138] Accordingly, although specific embodiments have been described, it should be understood that embodiments may include all modifications and equivalents within the scope of the following claims.

[0139] As described above, one aspect of the technology of the present invention is to supply mobile travel documents on a device. The present disclosure contemplates that in some instances, the collected data may include personal information data that uniquely identifies or can be used to identify a specific person. Such personal information data may include demographic data, phone numbers, email addresses, home addresses, data or records related to the user's passport or related documents, date of birth, or any other personal information.

[0140] The present disclosure recognizes that the use of such personal information data in this technology can be used to benefit the user. For example, personal information data can be used to authenticate the user's identity. In addition, the present disclosure also anticipates other uses of personal information data that are beneficial to the user.

[0141] The present disclosure contemplates that entities responsible for collecting, analyzing, disclosing, transmitting, storing, or otherwise using such personal information data will comply with established privacy policies and / or privacy practices. Specifically, such entities will be expected to implement and consistently apply privacy practices generally recognized as meeting or exceeding those required by industry or government for maintaining user privacy. Such information regarding the use of personal data should be prominent and accessible to users, and should be updated as the data collection and / or use changes. Personal information from users should only be collected for legitimate purposes (e.g., travel to and from foreign jurisdictions). Additionally, such collection / sharing should only occur after receiving user consent or other legal bases as provided for in applicable law. Additionally, such entities should consider taking any necessary steps to protect and safeguard access to such personal information data and ensure that other entities with access to personal information data comply with the privacy policies and procedures of other entities. Additionally, such entities may subject themselves to third-party assessments to demonstrate their compliance with widely accepted privacy policies and practices. Further, policies and practices should be tailored to the specific types of personal information data being collected and / or accessed and made applicable to applicable laws and standards, including jurisdiction-specific considerations that may be used to impose higher standards. For example, in the United States, the collection or access to certain biometric data may be governed by federal and / or state laws; while health data in other countries may be subject to other regulations and policies and should be handled accordingly.

[0142] Notwithstanding the foregoing, the present disclosure also anticipates embodiments where users selectively block the use or access of personal information data. That is, the present disclosure anticipates that hardware elements and / or software elements may be provided to prevent or block access to such personal information data. For example, the inventive technology may be configured to allow a user to select to "provide" or "not provide" travel documents to an inspection system. In addition to providing "provide" and "not provide" options, the present disclosure also contemplates providing notifications related to the access or use of personal information. For example, a user may be notified when their passport data will be accessed while using a light app, and then reminded again just before the passport data is accessed by the app.

[0143] Some or all of these technologies may be at least partially implemented through, for example, as at least in the foregoing Figures 1 to 13Those shown in the [description] are implemented, but not necessarily through those. Although many embodiments have been described above with reference to computing devices and user devices, it should be understood that other types of computing devices may be suitable for performing the techniques disclosed herein. In addition, various non-limiting examples have been described in the foregoing description. For purposes of explanation, numerous specific configurations and details have been set forth in order to provide a thorough understanding of the examples. However, it should also be apparent to those skilled in the art that some examples may be implemented without these specific details. In addition, well-known features may sometimes be omitted or simplified to prevent obscuring the examples described herein.

[0144] The various embodiments may also be implemented in a variety of operating environments, which in some cases may include one or more user computers, computing devices, or processing devices that may be used to operate any of a number of applications. User or client devices may include any of a number of general-purpose personal computers, such as desktop or laptop computers running a standard operating system, as well as cellular, wireless, and handheld devices that run mobile software and are capable of supporting a number of networking and messaging protocols. This system may also include a number of workstations running any of a variety of commercially available operating systems and other known applications for purposes such as development and database management. These devices may also include other electronic devices, such as virtual terminals, thin clients, gaming systems, and other devices capable of communicating via a network.

[0145] Most embodiments utilize at least one network familiar to those skilled in the art to support communication using any of a variety of commercial protocols such as TCP / IP, OSI, FTP, UPnP, NFS, CIFS, and AppleTalk. The network can be, for example, a local area network, a wide area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network, and any combination thereof.

[0146] In embodiments that utilize a network server, the network server may run any of a variety of server or middle-tier applications, including HTTP servers, FTP servers, CGI servers, data servers, Java servers, and business application servers. The server may also be capable of executing programs or scripts in response to requests from user devices, such as by executing one or more applications that may be implemented as one or more scripts or programs written in any programming language (such as C, C#, or C++) or any scripting language (such as Perl, Python, or TCL) and combinations thereof. The server may also include a database server, including but not limited to those commercially available from and commercially available.

[0147] The environment can include various data repositories and other memories and storage media, as discussed above. These can reside in various locations, such as on a storage medium local to one or more computers or on a storage medium remote from any or all of the computers on a network (and / or reside within one or more computers). In a particular set of embodiments, the information can reside in a storage area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing functions attributed to a computer, server, or other network device can be stored locally and / or remotely as needed. In cases where the system includes computerized devices, each such device can include hardware elements electrically coupled via a bus, which include, for example, at least one central processing unit (CPU), at least one input device (e.g., a mouse, keyboard, mobile device, touchscreen, or keypad), and at least one output device (e.g., a display device, printer, or speaker). Such systems can also include one or more storage devices, such as disk drives, optical storage devices, and solid-state storage devices such as RAM or ROM, as well as removable media devices, memory cards, flash cards, and the like.

[0148] Such devices can also include a computer-readable storage medium reader, communication devices (e.g., a modem, network card (wireless or wired), infrared communication device, etc.), and working memory, as described above. The computer-readable storage medium reader can be connected to or configured to represent a non-transitory computer-readable storage medium of a remote, local, fixed, and / or removable storage device, as well as a storage medium for temporarily and / or more persistently containing, storing, sending, and retrieving computer-readable information. The system and various devices will generally also include a number of software applications, modules, services, or other elements located within at least one working memory device, including an operating system and applications, such as client applications or browsers. It should be understood that alternative embodiments can have many variations according to what is described above. For example, custom hardware can also be used, and / or specific elements can be implemented in hardware, software (including portable software, such as applets), or both. Additionally, connections to other computing devices such as network input / output devices can be employed.

[0149] Non-transitory storage media and computer-readable storage media for containing code or portions of code can include any suitable media known or used in the art, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data, including RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, DVD or other optical memory, magnetic tape cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other media that can be used to store the desired information and can be accessed by a system device. Based at least in part on the disclosures and teachings provided herein, those of ordinary skill in the art will recognize other ways and / or methods of implementing the various embodiments. However, computer-readable storage media do not include transitory media such as carrier waves and the like.

[0150] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. However, it is obvious that various modifications and changes can be made thereto without departing from the broader spirit and scope of the disclosure set forth in the claims.

[0151] Other variations are within the spirit of the disclosure. Thus, although the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrative embodiments thereof have been shown in the drawings and have been described in detail above. However, it should be understood that it is not intended to limit the disclosure to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalent forms falling within the spirit and scope of the disclosure as defined by the appended claims.

[0152] In the context of describing the disclosed embodiments (especially in the context of the following claims), the terms "a", "an", and "the" and similar indicators are to be construed as covering the singular and the plural, unless otherwise specified or clearly contradicted by the context. Unless otherwise indicated, the terms "comprising", "having", "including", and "containing" are to be construed as open-ended terms (i.e., meaning "including but not limited to"). The term "connected" is construed to mean included, attached, or joined together in whole or in part even with something intervening. The phrase "at least partially based on" should be understood as open-ended and not limited in any way, and is intended to be construed or otherwise understood as "at least partially based on" in appropriate circumstances. Unless otherwise specified herein, the recitation of numerical ranges herein is merely intended to be a convenient method of referring individually to each separate value falling within the range, and each separate value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order, unless otherwise specified herein or clearly contradicted by the context. Unless otherwise stated, the use of any and all examples, or example language (e.g., "such as") provided herein is merely intended to better illustrate the embodiments of the present disclosure and does not pose a limitation on the scope of the present disclosure. No language in the specification should be construed as indicating any non-stated element as essential to the practice of the present disclosure.

[0153] Unless otherwise specifically stated, disjunctive language such as the phrase "at least one of X, Y, or Z" is understood in context to generally be used to present items, terms, etc. that can be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is generally not intended and should not imply that certain embodiments require the presence of at least one of each of X, at least one of Y, or at least one of Z. Additionally, unless otherwise specifically stated, conjunctive language such as the phrase "at least one of X, Y, and Z" should also be understood to mean X, Y, Z, or any combination thereof, including "X, Y, and / or Z".

[0154] Preferred embodiments of the present disclosure are described herein, including the best mode known to the inventors for carrying out the present disclosure. After reading the foregoing description, variations of those preferred embodiments may become apparent to those of ordinary skill in the art. The inventors expect those skilled in the art to appropriately employ such variations, and the inventors intend the present disclosure to be practiced otherwise than as specifically described herein. Accordingly, as permitted by applicable law, the present disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto. Additionally, unless otherwise indicated herein or clearly contradicted by the context, the present disclosure includes any combination of all possible variations of the above elements.

[0155] All references cited herein, including publications, patent applications, and patents, are hereby incorporated by reference as if each reference were individually and specifically indicated to be incorporated by reference and set forth in its entirety herein.

Claims

1. A method, the method comprising: receiving, by a user device, a request for a mobile identity document from an inspection system, the user device storing a mobile identity document private key on the mobile identity document; sending, by the user device, at least partially based on the request, the mobile identity document to the inspection system, the mobile identity document including a mobile identity document public key; receiving, by the user device, a mobile supplementary document from the inspection system, the mobile supplementary document including a mobile supplementary document public key derived from the mobile identity document public key, the inspection system being configured to derive the mobile supplementary document public key from the mobile identity document public key; deriving, by the user device, a mobile supplementary document private key corresponding to the mobile supplementary document public key, the mobile supplementary document private key being derived from the mobile identity document private key; and linking, by the user device, the mobile supplementary document to the mobile identity document at least partially based on the derivation of the mobile supplementary document private key from the mobile identity document private key.

2. The method according to claim 1, wherein the method further comprises: determining whether user consent has been provided to send the mobile identity document to the inspection system; and sending the mobile identity document at least partially based on the determination.

3. The method according to any one of claims 1 or 2, wherein the request for the mobile identity document is a sequential request for the mobile identity document and a mobile visa, and wherein the method further comprises sending the mobile identity document and the mobile visa to the inspection system at least partially based on the sequential request.

4. The method according to any one of claims 1 to 3, wherein the request comprises a first request, and wherein the method further comprises: sending the mobile identity document to the inspection system at least partially based on the first request; receiving a second request for a mobile visa after the first request; and sending the mobile visa at least partially based on the second request.

5. The method according to any one of claims 1 to 4, wherein the mobile supplementary document includes a mobile identity document number associated with the mobile identity document, and wherein the mobile identity document number also links the mobile supplementary document to the mobile identity document.

6. The method according to any one of claims 1 to 5, wherein the method further comprises storing the mobile identity document private key and the mobile supplementary document private key in a secure location of the device.

7. The method according to any one of claims 1 to 6, wherein the inspection system is associated with a first jurisdiction, and the mobile identity document is associated with a second jurisdiction.

8. The method according to any one of claims 1 to 7, wherein the mobile identity document is a mobile passport, and the mobile supplementary document is a mobile travel record.

9. A user device, the user device comprising: a processor; and a computer-readable medium including instructions that, when executed by the processor, cause the processor to perform operations including the following: Receive a request for a mobile identity document from an inspection system, where the user equipment stores a mobile identity document private key on the mobile identity document; Send the mobile identity document to the inspection system at least in part based on the request, the mobile identity document including a mobile identity document public key; Receive a mobile supplementary document from the inspection system, the mobile supplementary document including a mobile supplementary document public key derived from the mobile identity document public key, the inspection system being configured to derive the mobile supplementary document public key from the mobile identity document public key; Derive a mobile supplementary document private key corresponding to the mobile supplementary document public key, the mobile supplementary document private key being derived from the mobile identity document private key; and Link the mobile supplementary document to the mobile identity document at least in part based on the derivation of the mobile supplementary document private key from the mobile identity document private key.

10. The user equipment according to claim 9, wherein the instructions, when executed by the processor, further cause the processor to perform operations including: Determine whether user consent has been provided to send the mobile identity document to the inspection system; and Send the mobile identity document at least in part based on the determination.

11. The user equipment according to any one of claims 9 or 10, wherein the request for the mobile identity document is a sequential request for the mobile identity document and a mobile visa, and wherein the instructions, when executed by the processor, further cause the processor to perform operations including: sending the mobile identity document and the mobile visa to the inspection system at least in part based on the sequential request.

12. The user equipment according to any one of claims 9 to 11, wherein the request includes a first request, and wherein the instructions, when executed by the processor, further cause the processor to perform operations including: Send the mobile identity document to the inspection system at least in part based on the first request; Receive a second request for a mobile visa after the first request; and Send the mobile visa at least in part based on the second request.

13. The user equipment according to any one of claims 9 to 12, wherein the mobile supplementary document includes a mobile identity document number associated with the mobile identity document, and wherein the mobile identity document number also links the mobile supplementary document to the mobile identity document.

14. The user equipment according to any one of claims 9 to 13, wherein the instructions, when executed by the processor, further cause the processor to perform operations including: storing the mobile identity document private key and the mobile supplementary document private key in a secure location of the device.

15. The user equipment according to any one of claims 9 to 14, wherein the inspection system is associated with a first jurisdiction, and the mobile identity document is associated with a second jurisdiction.

16. The user equipment according to any one of claims 9 to 15, wherein the mobile identity document is a mobile passport, and the mobile supplementary document is a mobile travel record.

17. A non-transitory computer-readable medium storing a sequence of instructions that, when executed by a processor of a cloud infrastructure node, cause the processor to perform operations including the following: Receive a request for a mobile identity document from an inspection system; Send the mobile identity document to the inspection system, at least in part based on the request, the mobile identity document including a mobile identity document public key; Receive a mobile supplementary document from the inspection system, the mobile supplementary document including a mobile supplementary document public key derived from the mobile identity document public key, the inspection system being configured to derive the mobile supplementary document public key from the mobile identity document public key; Derive a mobile supplementary document private key corresponding to the mobile supplementary document public key, the mobile supplementary document private key being derived from a mobile identity document private key; and Link the mobile supplementary document to the mobile identity document, at least in part based on the derivation of the mobile supplementary document private key from the mobile identity document private key.

18. The non-transitory computer-readable medium according to claim 17, wherein the mobile identity document is a mobile passport, and wherein the instructions, when executed by the processor, further cause the processor to perform operations including the following: Determine whether user consent has been provided to send the mobile passport to the inspection system; and Send the mobile passport, at least in part based on the determination.

19. The non-transitory computer-readable medium according to any one of claims 17 or 18, wherein the request for the mobile identity document is a sequential request for the mobile identity document and a mobile visa, and wherein the method further includes sending the mobile identity document and the mobile visa to the inspection system, at least in part based on the sequential request.

20. The non-transitory computer-readable medium according to any one of claims 17 to 19, wherein the mobile supplementary document includes a mobile identity document number associated with the mobile identity document, the mobile identity document number further linking the mobile supplementary document to the mobile identity document.

Images