Mobile Identification Technology

Abstract

Techniques for mobile document provisioning are described herein. An exemplary method includes a device receiving a request for a mobile identity certificate for a second jurisdiction from an audit system for a first jurisdiction. The device can transmit the mobile identity certificate to the audit system based on the request, where the mobile identity certificate includes a mobile identity public key. The device can receive a mobile supplement, where the mobile supplement includes a mobile identity public key derived from the mobile identity public key, and the audit system is configured to derive the mobile supplement public key from the mobile identity public key. The device can derive a mobile supplement private key corresponding to the mobile supplement public key, where derivation of the mobile supplement to the private key links the mobile supplement to the mobile identity certificate.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Non-provisional Patent Application No. 17 / 976,649, filed October 28, 2022, the disclosure of which is incorporated herein by reference in its entirety for all purposes.

[0002] The present application relates to the field of information security, and in particular to mobile identity verification techniques in information security. [Background technology]

[0003] Digital documents can contain readable content that can be presented to a third party via an electronic device. In a sense, digital documents can be considered a paperless replacement for the original paper document. Digital documents can be stored on and presented using an electronic device, such as a mobile phone or tablet. These digital documents can offer advantages over paper documents, including improved storage capacity, accessibility, organization, and security. [Brief explanation of the drawings]

[0004] [Figure 1] FIG. 1 is a diagram of a system for travel document issuance and presentation, according to one or more embodiments.

[0005] [Figure 2] FIG. 2 illustrates a data model for a mobile document, according to one or more embodiments.

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

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

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

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

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

[0011] [Figure 8] FIG. 1 illustrates the exchange of passport document data between a device and an examination system, according to one or more embodiments.

[0012] [Figure 9] FIG. 1 is a diagram of data elements for a Mobile Passport (mPass) in accordance with one or more embodiments.

[0013] [Figure 10] FIG. 1 is a diagram of a security mechanism for a mobile travel document, according to one or more embodiments.

[0014] [Figure 11] FIG. 1 is a diagram of a request and response sequence for a travel document according to one or more embodiments.

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

[0016] [Figure 13]FIG. 1 is a block diagram of a mobile device according to one or more embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0017] In the following description, various embodiments are described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will be apparent to those skilled in the art that the embodiments may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified so as not to obscure the embodiments being described.

[0018] As technology enables people to manage more and more aspects of their lives through devices, they simultaneously want to use their devices to manage more of their interactions with third parties. One area of ​​our daily lives that may be affected by technological advances is travel. Air travel, especially international travel, is now within reach of a larger percentage of the population than ever before. Aspects of commerce such as airline tickets, hotel reservations, and car rentals in foreign countries can be handled using electronic devices.

[0019] Official travel documents or other identification documents, such as passports, visas, and passport stamps, are not available as travel documents that can be stored electronically on a mobile device and presented to government authorities. For example, an electronic passport cannot be presented to verify age, identity, or enter a foreign jurisdiction. Electronically stored documents can present various challenges, such as verifying that the travel document was generated by the appropriate government agency, verifying that the government agency intended to provision the travel document on a particular device, and / or verifying how the reader device authenticates the travel document.

[0020] Embodiments herein address the above-mentioned problems 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 security terminal device, a point-of-sale device, etc.) for authentication. The reader device can authenticate that the mobile document originated from the appropriate issuing authority and request additional mobile supplemental documents, such as other mobile travel documents, as needed. For example, the user device can present mobile supplemental documents, such as visas and other travel records, to the reader device. The reader device can further authenticate the mobile visas and other mobile travel records to make an informed decision.

[0021] These mobile travel credentials can consist of a group of mobile documents, which can be linked to one another. For example, the mobile documents can be linked to one another by using a mobile passport (mPass) identifier. Mobile documents (mDocs) used for travel can include a mobile identity card, such as an mPass, which can be a digital passport issued by an issuing country, and a mobile visa (mVisa), which can be issued by the issuing country. The mPass can be cryptographically linked to the mVisa, which resides in a secure location on the user's device. The mDoc can further include a Travel Record (mTR), which can be issued by a national screening system (e.g., a reader device). Because digital passports cannot be stamped by physical means, the mTR can include a digital passport stamp. A user device can store multiple mTRs depending on the number of countries the user has visited. Each mTR can, in turn, be cryptographically linked to an mPass. As described herein, the mPass can be considered the parent document, and the mVisa and mTR can be considered child documents. Although this disclosure refers to passports, visas, and passport stamps, travel documents may include other documents required to enter a foreign jurisdiction, such as work permits, residence cards, and even other documents that can be used to identify a user (e.g., concert admission tickets, bus passes, etc.).

[0022] The embodiments are described in the context of a mobile passport (mPass), a mobile visa (mVisa), and a mobile travel record (mTR). It should be understood that techniques related to the embodiments described below (e.g., key derivation, linking) may also apply to other mobile documents (mDocs). For example, vaccination cards, access credentials, identity credentials, loyalty credentials, insurance cards, property ownership and registration documents, and other suitable mobile documents. In these examples, the mobile identity card may be the primary form of identity proof, and the mobile supplemental documents may be additional documents (e.g., vaccination cards, access credentials, identity credentials, loyalty credentials, insurance cards, property ownership and registration documents) that may be linked to the mobile identity card.

[0023] FIG. 1 illustrates a system 100 for the issuance and presentation of travel documents according to one or more embodiments. The mobile device 102 may be a portable device that can be carried by a single individual. The mobile device 102 may be operable to exchange information with another device without a wired connection. The mobile device 102 may include persistent and temporary local data storage and a built-in power source. The mobile device 102 may include one or more methods for communicating information to a user (e.g., a display, a speaker, a vibration actuator). The user may be an "mDoc holder" (the person to whom the mDoc is issued) as defined by ISO / IEC 18013-5. The mobile device 102 may further include means for the user to interact with the device (e.g., a touchscreen, buttons, a motion sensor).

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

[0025] The mobile device 102 can further communicate with a reader 112 (e.g., an mDoc reader). A reader can be a device capable of retrieving an mDoc for validation purposes as defined by ISO / IEC 18013-5. The reader 112 can be located at a border (e.g., a port) or the functional equivalent of a border (e.g., an airport). A user can use the mobile device 102 to present an mPass 106 and, if necessary, an mVisa 110 to the reader 112. The reader 112 can communicate with the mobile device 102 to authenticate the mPass 106 and, if necessary, the mVisa 110. In response to authentication, the reader 112 can provision the mobile device 102 with an mTR 114. For example, the reader 112 can provision the mobile device 102 with a digital stamp similar to an ink stamp on a physical passport. The mPass 106, mVisa 110, and mTR 114 can be cryptographically linked, for example, by using the identifier of the parent document (e.g., mPass). In this sense, a subsequent reader can verify that each mDoc (mPass 106, mVisa 110, and mTR 114) was provisioned to the same holder as the holder of the parent document (e.g., mPass). The device reader can further verify that the mDocs are presented by the mobile device for which they were issued using anti-cloning mechanisms (e.g., digital signatures and media access control techniques) as described in ISO / IEC 18013-5. In some instances, a user may have more than one passport (e.g., dual citizenship). Often, a user may travel to more than one foreign jurisdiction and have multiple issued visas. Furthermore, a user may accumulate more than one mTR as they move from one foreign jurisdiction to another. The mobile device 102 is operable to store multiple instances of an mDoc and cryptographically link each of the mDocs.

[0026] Regardless of whether online connectivity is available to either the mobile device 102 or the reader 112, the reader 112 can include a screening system that can request, receive, and verify the integrity and authenticity of the mPass 106, mVisa 110, and / or mTR 114. Furthermore, the reader 112 can perform its functions independently of the passport-issuing authority 104 or visa-issuing authority 108.

[0027] The mobile device 102 and the reader 112 can communicate using an interface that can support selective disclosure of information and data minimization. In this sense, neither device is provided with more information than is necessary to present and authenticate an mDoc. A user can use the mobile device 102 to present one or more mDocs and / or receive mTRs without having to hand over the device. In other words, a user can hold the mobile device 102 in their hand and bring it close enough to the reader 112 to initiate a secure session for exchanging information. The mobile device 102 can be further 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.

[0028] FIG. 2 is a diagram 200 of a mobile document data model in accordance with one or more embodiments. As shown, an mPass 202, an mVisa 204, and an mTR 206 can be provisioned on a mobile device, such as the mobile device 102 of FIG. 1. The mPass 202 can include a set of mPass data elements 208, which can include the holder's name, date of birth, address, telephone passport issuing authority, passport number, and other suitable information. The mPass data elements 208 can be arranged into groups known as namespaces, as described in ISO / IEC 18013-5. For example, the mPass data elements 208 can include biometric data such as a facial image, fingerprint, or iris scan. The biometric data can be grouped using a biometric-related namespace, such as "holder biometric." Another grouping can be emergency contacts, i.e., contact name, address, and phone number. Emergency contact information can be grouped using a namespace, such as "person to notify." Each data element in 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 the interface to retrieve and authenticate the mPass public key 210.

[0029] The mVisa 204 can include a set of mVisa data elements 214. The mVisa data elements 214 can include, for example, the holder's name, the name of the visa issuing agency, and the visa document number. Similar to the mPass 202, the mVisa data elements 214 can be grouped and identified by namespaces. Each data element of the mVisa data elements 214 can be cryptographically signed by an mVisa issuer private key, as well as an mVisa public key 216. The mVisa public key 216 can 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) can use the interface to retrieve the mVisa data elements 214 and the mVisa public key 216 and verify their signatures using the mVisa issuer public key. A reader (e.g., reader 112) can use the interface to verify the authenticity of the mVisa issuer public key.

[0030] The mTR 206 can also include a set of mTR data elements 220. The mTR data elements 220 can include, for example, the holder's name, the mTR issuing authority's name, and the mTR document number. Similar to the mPass 202 and mVisa 204, the mTR data elements 220 can be grouped and identified by namespaces as described in ISO / IEC 18013-5. Each data element in the mTR data elements 220 can be cryptographically signed using the mTR issuer's public key. A reader (e.g., reader 112) can verify the authenticity of the mTR issuer's public key using the interface.

[0031] mPass 202, mVisa 20, and mTR 206 can be linked using a process of key derivation, which can 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 mobile device 102 of FIG. 1, can also store an mPass private key corresponding to mPass public key 210. The mPass private key is known only to the mobile device and can be stored in a secure area. When a visa-issuing authority provisions mVisa on a mobile device, the authority can further generate mVisa public key 216 using a KDF, which can be described as asymmetric elliptic curve key derivation, and the mPass public key 210 as the parent key. The visa-issuing authority can further include the mVisa public key in the MSO 218. Additionally, the mobile device can generate an mVisa private key using the key derivation function used to derive the mVisa public key and the mPass private key as the parent key. Thus, the mVisa public key 216 is known to the visa issuing authority, but the corresponding mVisa private key is not known to the visa issuing authority. Similarly, when an authority provisions a mobile device with an mTR 206, the authority can use the KDF and the mVisa public key 216 as parent keys to create the mTR public key 222. The mobile device can then use the KDF and the mVisa secret as parent keys to generate the mTR private key. Again, the mTR issuing authority knows the mTR public key 222, but only the device knows the mTR private key.

[0032] A reader, such as reader 112 of FIG. 1, can use various methods to review the mDocs provisioned to a mobile device. For example, the reader can use “forward engagement” or “reverse engagement.” In some embodiments, the reader can use sequential requests to request each mDoc needed to complete a transaction. For example, if a user is entering a foreign jurisdiction, the reader can first request an mPass, then, if the mPass is authenticated, request an mVisa, then, if the mVisa is authenticated, request the first mTR, and so on. Thus, the user can present the requested mDoc to the reader, wait for the mDoc to be authenticated, and then continue to present subsequently requested mDocs until the authentication process is complete. In other embodiments, the reader can send a modified message to the mobile device requesting all required mDocs in a single request. For example, if the reader needs to see both the mPass and the mVisa, they can request both mDocs separately and request both mDocs via a modified message.

[0033] FIG. 3 illustrates a process flow 300 for authenticating a mobile document on a device, according to one or more embodiments. While 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) may be used to perform one or more operations of these processes. Processes 300, 400, 500, 600, 700, and 1200 (described below) are illustrated as logical flow diagrams, with each operation in those flow diagrams representing a sequence of operations that may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Typically, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement a process.

[0034] 3-5 relate to forward engagement, which may be ideal for in-person presentation of an mDoc, which may use proximity protocols such as Near Field Communication (NFC), Bluetooth, and Wi-Fi. Generally, a user action may activate a passport application on the device, allowing the device and screening system to share engagement data regarding how to transmit and set up a secure session, as defined by ISO / IEC 18013-5. The user action may be, for example, a Near Field Communication (NFC) tap or a QR code scan. Devices may further exchange information using an mDoc request and mDoc response. The mDoc request may indicate whether the requested document is critical (e.g., required to enter the jurisdiction) or conditional (e.g., optional to enter the jurisdiction). The mDoc request may further indicate that the value of a data element must equal a specific value, or may indicate that the value of a data element must equal one of a set of values.

[0035] At 302, a user may perform an action to initialize a passport application on a device, such as mobile device 102 of FIG. 1. The action may be, for example, touching a passport application icon displayed on the device with a hand using a touchscreen. Both the device and the screening system may be equipped with short-range communication technology, 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 screening system may detect each other based on proximity and may open a secure session between them.

[0036] At 304, a passport application can be initialized based on the user's action at 302. In some examples, the passport application can be displayed on the device based on the initialization. Initializing the passport application allows the application to transition from a sleep state to an awake state to perform its functions.

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

[0038] The device and the screening system can establish a secure session at 308. Both the device and the screening system can include encryption protocols so that any information to be transmitted is encrypted before transmission.

[0039] At 310, the screening system may request mPass data from the device. This request may be in the form of an encrypted message sent by the screening system to the device over a secure channel.

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

[0041] At 314, the screening system can receive the mPass data, where the mPass data is a mobile passport and can be considered a parent document. The screening system can receive the mPass data from the device over a secure channel.

[0042] At 316, the screening system can determine if a child document is required. For example, some jurisdictions require an additional mDoc (e.g., visa, work permit) in addition to a passport for entry. This mDoc can be considered a child document to the parent document.

[0043] If the screening requires child documents, the screening system can send a message to the device requesting additional child documents at 318. For example, the screening system can send a request for an mVisa to the device using a secure channel.

[0044] At 320, the device may transmit the requested child document to the review system. In some embodiments, the device may be further configured to request user consent before providing the requested child document. For example, the device may transmit the requested child document over a secure channel based on receiving a signal indicating user consent.

[0045] At 322, the screening system can receive the requested child document from the device. For example, the screening system can receive the requested mVisa from the device over a secure channel.

[0046] The method then returns to 316, where the screening system determines whether additional child documents (e.g., mTRs) are required. The additional child documents can be, for example, work permits. If the screening system determines that additional child documents are required, the method repeats steps 318 through 322 for the additional child documents.

[0047] If the screening system determines that a child document from the device is not needed at 316, the screening system can determine whether a child document (e.g., a child mDoc) needs to be issued to the device. For example, the determination can be, "Does the screening system need to issue a passport stamp to the device?"

[0048] If the answer to the determination at 324 is "no," the screening system and / or device may end this process at 326 and begin another process.

[0049] However, if the answer to the question is "yes," the review system may derive the public key of the child document at 328. For example, the review system may use a key derivation function (KDF) and the public key of the parent document to derive the public key of the child document.

[0050] At 330, the screening system can issue a child document (e.g., mTR, mVisa) to the device. For example, the screening system can send the child document to the device over a secure channel.

[0051] At 332, the device can add the child document to an mDoc collection stored in a secure location within the device. The child document can be cryptographically linked to the parent document (e.g., mPass). The device can further derive a private key for the child document from the private key of the parent document. The private key can further be stored in a secure location on the device.

[0052] Upon deriving the private key for the child document, the review system and / or device may end this process and begin another process at 326.

[0053] 4 is a process flow 400 for authenticating a mobile document on a device, according to one or more embodiments. At 402, a user may perform an action to initialize a passport application on a device, such as the mobile device 102 of FIG. 1. The action may be, for example, touching a passport application icon displayed on the device with a hand using a touchscreen. Both the device and the screening system may be equipped with short-range communication technology, such as NFC technology, RFID, or Bluetooth technology. The user's device and the screening system may detect each other based on proximity and may open a secure session between them.

[0054] At 404, a passport application can be initialized based on the user's action at 402. In some examples, the passport application can be displayed on the device based on the initialization. Initializing the passport application allows the application to transition from a sleep state to an awake state to perform its functions.

[0055] At 406, the device and the audit system can share engagement data. The engagement data is exchanged according to a short-range transmission protocol and can be used by the device and the audit system to identify each other. For example, the device and the audit system can exchange engagement data necessary to perform, for example, handshake authentication, challenge-response authentication, password authentication, or other information to verify each other.

[0056] The device and the screening system can establish a secure session at 408. Both the device and the screening system can include encryption protocols so that any information to be transmitted is encrypted before transmission.

[0057] At 410, the review system can request all necessary mDocs. In other words, rather than determining requirements for additional child documents anew after the parent document has been received, the review system can be configured to request all mDocs in a single message. For example, the review system can request "any document with a doc type starting with org.iso.mPass, at least one required" or "any document with a doc type equal to org.iso.mVisa and namespace / issue." For example, rather than sending separate messages to request mPass and mVisa (as shown in FIG. 3), the review system can request both mPass and mVisa in a single message.

[0058] At 412, the device can transmit the requested mDoc to the screening system. For example, if the screening system requests an mPass and an mVisa, the device can transmit both mDocs to the screening system. The mDocs can be cryptographically linked within the device. In some embodiments, the device can be further configured to request user consent before providing the requested mDoc. For example, the device can send the requested mDoc over a secure channel based on receiving a signal indicating user consent.

[0059] At 414, the screening system can receive the requested mDoc from the device. For example, the screening system can receive the requested mPass and mVisa from the device over a secure channel.

[0060] At 416, the screening system can determine if another mDoc is needed. For example, based on the received mDoc, the screening system can determine that an additional mDoc (e.g., a work permit) is needed. This mDoc can be considered a child document to the parent document.

[0061] If the review system determines that another mDoc is needed, the review system may send another query to the device at 418.

[0062] At 420, the device can transmit the requested mDoc to the screening system. For example, if the screening system requests a mobile work permit, the device can transmit the mobile work permit to the screening system. The mDoc can be cryptographically linked within the device. In some embodiments, the device can be further configured to request user consent before providing the requested mDoc. For example, the device can transmit the requested mDoc over a secure channel based on receiving a signal indicating user consent.

[0063] At 422, the screening system can receive the requested mDoc from the device. For example, the screening system can receive the requested mobile work permit from the device over a secure channel.

[0064] At 424, the screening system can determine whether to issue an mTR to the device. For example, the screening system can determine whether to issue a passport stamp to the device. For illustrative purposes, process flow 400 continues in FIG. 5.

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

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

[0067] At 506, the screening system can issue an mTR (e.g., a passport stamp) to the device. For example, the screening system can send the passport stamp to the device over a secure channel.

[0068] At 508, the device can add the mTR to a collection of passport mDocs. The mDocs can be stored in a secure location on the device. Each of the mDocs can be cryptographically linked within the device. The device can further derive a private key for the mTR. For example, the device can derive the private key for the mTR using the KDF and the private key of the parent document. The private key can further be stored in a secure location on the device.

[0069] After the device stores the mTR private key or determines not to issue an mTR at 502, the screening system and / or device may end this process and begin another process at 510.

[0070] 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 Figures 3-6 relate to a forward engagement, while Figure 6 relates to a reverse engagement, in which the screening system shares information about the secure session setup and requests data from the device. The device can further respond to the request with an mDoc response.

[0071] At 602, a user may perform an action to initialize a passport application on a device, such as mobile device 102 of Figure 1. The action may be, for example, touching a passport application icon displayed on the device with a hand using a touchscreen.

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

[0073] At 606, the screening system can send the engagement information and a request for an mPass to the device. The device can include a passport application running on the device. The passport application can be operable to store one or more mDocs used for travel by the user.

[0074] The device can verify the identity of the screening system at 608. The device can verify the reader certificate using a public key infrastructure (PKI) system.

[0075] At 610, the device can generate a response to the request from the screening system. In response to receiving the request from the screening system, the device can create an mDoc response message that includes the mPass and any necessary key information. For example, the mDoc response can include key information that the screening system can use to verify the mPass. The device can also encrypt the response using an encryption protocol.

[0076] The device can return an encrypted response to the screening system at 612. For example, the device can send the encrypted mDoc response to the screening system over a secure channel.

[0077] At 614, the screening system can receive a response from the device and can screen the mPass. The response can be an mDoc response and can include the mPass. The screening system can screen the data elements included in the mPass to determine if the mPass includes any required data elements and is associated with the user and the user device.

[0078] At 616, the screening system can determine if an mVisa is required.

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

[0080] At 620, the device can send the mVisa to the screening system. The mVisa can be stored in a secure location on the device running 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 screening system over a secure channel.

[0081] At 622, the screening system can receive the mVisa from the device. For example, the screening can receive an encrypted mDoc response from the device. The screening system can decrypt the encrypted mDoc response and screen the mVisa.

[0082] At 624, the screening system can determine if a child document is required from the device. The child document can be, for example, a work permit or a vaccination status card.

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

[0084] At 628, the device can send the requested mTR to the screening system. For example, the device can retrieve the mTR from a secure location on the device. The device can then encrypt the mTR and transmit it to the screening system as an mDoc response using a secure channel.

[0085] At 630, the audit system may receive the mTR from the device. For example, the audit system may decrypt the encrypted mTR and audit the mTR for authentication.

[0086] At 632, the screening system and / or device may end this process and begin another process.

[0087] 7 is a process flow 700 for authenticating a mobile document on a device, according to one or more embodiments. At 702, a user may perform an action to initialize a passport application on a device, such as the mobile device 102 of FIG. 1. The action may be, for example, touching a passport application icon displayed on the device with a hand using a touchscreen.

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

[0089] At 706, the screening system can send the engagement information and request to a passport application running on the device. The passport application can be operable to store one or more mDocs used for travel by the user.

[0090] At 708, the passport application can verify the identity of the screening system. For example, the passport application can be pre-configured with an identifier associated with the screening system. The passport application can compare the pre-configured device identifier with the device identifier included in the engagement data.

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

[0092] The device can return an encrypted response to the screening system at 712. For example, the device can send the encrypted mDoc response to the screening system over a secure channel.

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

[0094] At 716, the review system can determine if any other documentation is required. For example, the review can determine if another mDoc, such as an mTR, is required to enter the jurisdiction.

[0095] At 718, the review system can send a request for additional documentation (e.g., mTR) from the device. The request can be based on the review system determining that additional documentation is needed. For example, the review can send a second mDoc request to the device. The second mDoc request can be encrypted according to an encryption protocol and sent to the device over a secure channel.

[0096] At 720, the device can transmit the additional document to the screening system. The additional document can be stored in a secure location on the device running the passport application. The device can retrieve the additional document from the secure location and encrypt the document, including any associated keys. The device can then transmit the encrypted document to the screening system over a secure channel.

[0097] At 722, the screening system can receive the additional document from the device. For example, the screening system can receive an encrypted mDoc response from the device. The screening system can decrypt the encrypted mDoc response and review the additional document. For example, the screening system can analyze one or more data elements of the additional document to determine whether the user is permitted to enter the foreign jurisdiction.

[0098] At 724, the screening system and / or device may end this process and begin another process.

[0099] 8 is a diagram 800 of a passport document data exchange between a device and an examination system, according to one or more embodiments. An mPass issuing authority (e.g., a government agency) can provision an mPass 804 into a secure area 806 of a device, such as a mobile device. An mVisa 808 issuing authority (e.g., a government agency) can provision an mVisa into the secure area 806 of the device. The secure area 806 can further store one or more mTRs 812 (e.g., passport stamp work permits) provisioned by an authorized entity.

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

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

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

[0103] 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 an mPass 804, the device can generate an mDoc response that includes the mPass 804. The device can encrypt the response using a session decryption process 822.

[0104] The encrypted response can be transmitted to the screening system in a transmission technology format 820. The screening system 814 can decrypt the encrypted response using a session decryption process 818. The screening system 814 can analyze the decrypted response. For example, the screening system 814 can receive the decrypted response in CBOR format. The screening system 814 can then analyze the data elements in the mPass 804 for determinations such as age verification or jurisdictional entry.

[0105] FIG. 9 is a diagram of data elements for mPass 900, according to one or more embodiments. mPass can include one or more namespaces that identify groups of data elements. Each data element can relate to information used, for example, to verify age or identity or to determine whether an individual can enter a jurisdiction. As shown, a first namespace 902 (e.g., holder data) can be associated with a first group 904 of data elements that identify information about the passport holder. For example, the data elements can include name (holder_name), date of birth (date of birth), issuing authority (issuing authority), passport number (doc.number), holder signature (displayed sig.), and citizenship (citizenship). These data elements can be as defined in 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 group 904 of data elements. For example, the first group of data elements may include age_over_xx data elements, as defined by ISO 18013-5. For example, the data elements may further include address, telephone number, occupation, title, employment history, other travel documents, detention information, observation records, tax exit requirements, portrait photo specifications, document code, optional information regarding nationality, displayed portrait photo, and person to notify.

[0106] Additionally, while an mPass is illustrated, it should be understood that an mVisa and an mTR may be organized similarly to an mPass. mVisa data elements may include, for example, issuing authority, visa type, number of entries, length of stay, passport number, regional information, place of issue, issue date, expiration date, document number, additional information, full name, primary identifier, secondary identifier, gender, date of birth, and nationality. mTR data elements may include entry / exit status, visa approval date, adjudicating authority, adjudicator reference, mode of travel, length of stay status, and passport number.

[0107] A second namespace 906 (e.g., person to notify) may be associated with a second group of data elements 908 of emergency contact information. For example, the second group of data elements 908 may include an emergency contact name, an emergency contact telephone number, a physical and / or email address of the emergency contact, and a date the emergency contact was established. The data elements in the second group of data elements may be as defined by ICAO Document 9303-X.

[0108] A third namespace 910 (e.g., holder biometric) may be associated with a third group 912 of data elements for biometric data. Each biometric data element may include one of the user's biometrics encoded as described in International Civil Aviation Organization document 9303, rather than in tag-length-value (TLV) format. This may be the equivalent of Data Group 2 (DG2) for the DG4 biometric template. The third group 912 of data elements may include a CBOR encoding structure corresponding to the holder's face, which may be input into a facial recognition system. Each biometric record may include multiple records with different biometric encodings. For example, the third group 912 of data elements may include facial features (face), fingerprint scan (fingerprint), iris scan (iris), and other biometric data (others) that may be used to identify the holder. The face data element may be a facial image for use in machine-assisted identity verification. If there are multiple records for face, the most recent internationally interoperable one may be the first entry.

[0109] A fourth namespace 914 (e.g., backward compatibility) may be associated with a fourth group of data elements 916 for backward compatibility. The fourth group of data elements 916 may include data elements having the contents of a data group (DG) defined by ICAO document 9303. For example, the fourth group of data elements 916 may include data elements DG1, DG2, DG11, and others (e.g., DG16). Each DG may be a logical grouping of data elements that can be used to digitally store a travel document after it is issued and during the document's validity period.

[0110] The mPass may further be associated with a public key 918. The public key may be generated by the issuing authority of the mPass.

[0111] In some embodiments, the device and the audit system can implement security mechanisms defined by ISO 18013-5. The security mechanisms can provide protection against counterfeiting. Each mDoc can be signed by the mDoc's issuing authority. The degree of protection against counterfeiting can be based on how well the issuer's key is protected. The security mechanisms can provide protection against cloning. The device can generate a signature on the session data using the device's private key. The corresponding audit system, which has the public key, can establish trust in the device public key from the issuer signature. The degree of protection against cloning can be based on how well the device private key is protected. The security mechanisms can protect against eavesdropping during the transaction. Communications between the device and the audit system can be encrypted and authenticated. For example, a man-in-the-middle attack can be detectable by the audit system using verification of a digital signature on the session data. The security mechanisms can provide audit 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.

[0112] In addition to the security mechanisms described above, mDocs can be linked together based on two components: (1) the issuing authority-signed passport number in both the parent document (mPass) and the child documents (mVisa, mTR), and (2) dynamic relationships between mDocs based on key derivation. Specifically, child documents can have keys derived from the parent key.

[0113] First, mVisa and mTR can be linked to a particular mPass by including a document number (e.g., a passport number) if the mPass has an issuing authority-signed data document number. A link based on the document number can be as strong as the document number itself.

[0114] Second, a device (e.g., a mobile device, an audit system) can use a derivation function to generate a new child key (e.g., an mVisa key, an mTR key) from a parent key (e.g., an 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 fraudulent actor possesses 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 link between a parent document and a child document can be confirmed using the relationship between the parent key and the corresponding child key.

[0115] Various derivation functions can be used to derive child keys from parent keys. A first derivation function can be used to generate child public keys from parent public keys. This can be used to allow an audit system to issue child documents cryptographically linked to a parent document without the need to verify key attestation and key certification resident within the secure domain of the mobile device. A second derivation function can be used to derive child private keys from parent private keys. To issue a new child document, a new public key can be calculated from the parent key (e.g., mPass key). The issuing authority of the child document can create a new public key using a key derivation process. Furthermore, 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 maintained. Symmetric secret (SK) parameters can be generated collectively between the audit system and the device.

[0116] Given a top-level public / private key pair (call it {d,P}) and a symmetric secret (SK), a device or audit system can define two derived integers {u_i,v_i} = KDF(SK,i). The device or audit system can then perform the public key derivation as follows: P_i = u_i.P + v_i.G, where G is the generating point of the curve. The corresponding private key is d_i = u_i * It can be derived as d + v_i. The accuracy of P_i == d_i.G can be verified.

[0117] Each new derivation can generate a new value of SK. If SK is compromised (extracted), an adversary may be able to link the keys together, but the adversary cannot perform the Elliptic Curve Diffie-Hellman (ECDH) key protocol or sign with the Elliptic Curve Digital Signature Algorithm (ECDSA), which allows a device or audit system to store SK and derive the public key outside the security domain that handles the private key {d}.

[0118] 10 is a diagram of a security mechanism for mobile travel documents, according to one or more embodiments. Verified key attestation can occur, where the properties of the mPass public key and the mPass private key can be verified. For example, the mPass issuing authority (IA) 1002 can verify that the mPass public key 1012 corresponds to the mPass private key 1004 stored in a secure area of ​​the device 1008 (e.g., a mobile device). Based on the verification, the mPass IA can provision the device 1008 with an mPass 1010. 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 provision the mPass 1010 on the device 1008.

[0119] Eventually, the user may wish to use mPass 1010, for example, to verify age, verify identity, or enter a foreign jurisdiction. The user may use the device 1008 to initiate a secure session with an inspection system (IS) 1014. Part of the purpose of the secure session may be, for example, to receive a passport stamp. For example, the user may present their device 1008 to the inspection system 1014 to receive a stamp, for example, at an airport or port in a foreign jurisdiction. The inspection system 1014 may retrieve the mPass public key 1012 and use the derivation data to apply a derivation function to establish a new public key 1016. The new public key 1016 may be used for an mTR 1018 (e.g., a passport stamp) that is provisioned on the device 1008 by the inspection system 1014. The mTR may include information related to the derivation function, such as key metadata, derivation data, data elements, etc., in addition to the stamp data. The audit system 1014 can further sign the mTR, including the key metadata, derived data, and data elements, using the IS private key 1020. A public key corresponding to the IS private key 1020 can be used to verify the mTR 1018. Thus, a subsequent audit system (e.g., the user travels to yet another country) can verify the authenticity of the mTR based on the signature included in the mTR 1018 using the public key, which corresponds to the IS private key 1020.

[0120] The device can derive the mTR private key 1022 using the parent private key 1004 plus the derived data contained in the mTR. The derived private key 1022 can be used in subsequent transactions to prove that the mTR has not been cloned and stored on the device. For example, if the mTR 1018 is cloned and stored on a new device, the signature of the mTR 1018 can be verified by the IS using the mTR issuer public key. However, because the mTR private key 1022 can only be derived on the original device 1008, the new device does not have access to the mTR private key 1022.

[0121] 11 is a diagram of a request and response sequence for a travel document according to one or more embodiments. The device 1102 and the screening system 1104 can establish a secure session with each other using a short-range transmission protocol. The short-range transmission protocol can be, for example, NFC, Bluetooth, or Wi-Fi.

[0122] The screening system 1104 can send a request, such as an mDoc request, to the device 1102 for an mPass 1106. For example, the screening system can be set up for entry into a foreign jurisdiction that requires a passport for entry. The mPass 1106 can include an mPass public key 1108 that corresponds to an mPass private key 1110. The mPass public key 1108 can be signed by the issuing authority of the mPass 1106. The mPass private key can be stored in a secure area of ​​the device 1102.

[0123] The device 1102 can sign the mPass 1106 using the mPass private key 1110 and send the mPass 1106 to the screening system 1104. In some embodiments, the transmission can be an mDoc response encrypted and formatted using the CBOR format.

[0124] The audit system 1104 can receive the mPass 1106 from the device 1102 over a secure channel. The audit system 1104 can then decrypt the message from the device 1102. The audit system 1104 can trust the mPass public key 1108 because it is signed by the mPass issuing authority. The audit system 1104 can then use the mPass public key 1108 to verify the device's signature. Based on verifying the device's signature, the audit system 1104 can verify that the mPass was originally issued to the same device that is presenting it, and can begin auditing the data elements contained in the mPass 1106.

[0125] 12 is a process flow 1200 for linking a mobile supplemental document to a mobile identity document, such as a mobile passport, according to one or more embodiments. At 1202, the method can include a user device receiving a request for a mobile identity document for a second jurisdiction from an examination system of a first jurisdiction, the user device including a mobile identity document private key. The user device can be the user's mobile device. The first jurisdiction can be, for example, a destination country, and the second jurisdiction can be, for example, an origin country. The process can be initiated by a passport application running on the user device. The user device and reader can establish contact when within proximity and communicate with each other using a short-range transmission protocol, such as NFC, Bluetooth, or Wi-Fi.

[0126] At 1204, the method may include the user device transmitting the mobile identity to the screening system based at least in part on the request, the mobile passport including the mobile identity public key. In some embodiments, the user is provided with an opportunity to manually indicate whether or not to provide the mobile identity to the screening system. The transmission may be based on receiving this consent.

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

[0128] At 1208, the method may include the user device deriving a mobile supplement private key corresponding to the mobile supplement public key, where the mobile supplement private key is derived from the mobile identity private key, and derivation of the mobile supplement private key from the mobile identity private key links the mobile supplement to the mobile identity. The user device may derive the mobile supplement private key using a key derivation function. The mobile supplement private key and the mobile identity private key may be stored in a secure area of ​​the user device and separated from the mobile identity and the mobile supplement. In this sense, only the device has access to either private key. Therefore, if the mobile identity and / or the mobile supplement are cloned and stored on another device, the new device will not have access to the private key and will fail subsequent authentication by the screening system.

[0129] 13 is a block diagram of a mobile device 1300 according to some embodiments. The mobile device 1300 can 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 can include a processing subsystem 1310, a memory device 1312, a user interface 1314, a communication interface 1316, a secure element 1318, and a cryptographic logic module 1320. The mobile device 1300 can also include other components (not explicitly shown), such as a battery, a power mobile device, and other components operable to provide various enhanced capabilities. In various embodiments, the mobile device 1300 can be implemented in a desktop computer, a laptop computer, a tablet computer, a smartphone, a wearable computing device, or other system having any desired form factor.

[0130] Storage device 1312 may be implemented using, for example, a disk, flash memory, or any other non-transitory storage medium or combination of media, and may include volatile and / or non-volatile media. In some embodiments, storage device 1312 may store one or more applications and / or operating system programs executed by processing subsystem 1310, including programs for implementing any or all of the operations described herein as being executed by the mobile device. For example, storage device 1312 may store a permanent mobile device application that can read an accessory definition record and generate a graphical user interface for controlling the accessory based on the information therein. In some embodiments, some (or all) of the mobile device functionality described herein may be implemented in an operating system program rather than an application. In some embodiments, storage device 1312 may also store apps (e.g., a passport application) designed for a particular accessory or a particular category of accessories.

[0131] The user interface 1314 can include input devices such as a touchpad, touchscreen, scroll wheel, click wheel, dials, buttons, switches, keypad, microphone, etc., and output devices such as a video screen, indicator lights, speakers, headphone jack, etc., along with supporting electronics (e.g., digital-to-analog or analog-to-digital converters, signal processors, etc.). A user can manipulate the input devices of the user interface 1314 to invoke functions of the mobile device 1300 and can see and / or hear output from the mobile device 1300 via the output devices of the user interface 1314.

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

[0133] Through suitable programming, processing subsystem 1310 can provide various functionality to mobile device 1300. For example, in some embodiments, processing subsystem 1310 can implement various processes (or portions thereof) described above as being implemented by the mobile device. Processing subsystem 1310 can also execute other programs for controlling other functions of mobile device 1300, including programs that may be stored in storage device 1312. In some embodiments, these programs may interact with accessories, for example, by generating messages to be sent to and / or receiving messages from accessories. Such messages may conform to a fixed accessory protocol as described above.

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

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

[0136] In some embodiments, cryptographic operations can be implemented in a cryptographic logic module 1320 that communicates with the secure element 1318. Physically, the cryptographic logic module 1320 can be implemented in the same integrated circuit as the secure element 1318 or a different integrated circuit (e.g., a processor within the processing subsystem 1310), as appropriate. The cryptographic logic module 1320 can include various logic circuits (fixed or programmable, as appropriate) 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 can appear as a “black box” to the rest of the mobile device 1300. Thus, for example, the communication interface 1316 can receive a message in an encrypted form that it cannot decrypt and simply pass the message on to the processing subsystem 1310. The processing subsystem 1310 may also not be able to decrypt the message, but can recognize the message as encrypted and pass it on to the cryptographic logic module 1320. The cryptographic logic module 1320 can decrypt the message (e.g., using information extracted from the secure element 1318) and determine what information to return to the processing subsystem 1310. As a result, certain information can 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 runs only code from an internal secure repository, this can make extracting the information very difficult and provide a high degree of security. Other implementations are possible.

[0137] Therefore, although particular embodiments have been described, it will be understood that the embodiments may include all modifications and equivalents that fall within the scope of the following claims.

[0138] As noted above, one aspect of the present technology is provisioning mobile travel documents onto a device. This disclosure contemplates that in some cases, this aggregated data may include personal information data that uniquely identifies or can be used to identify a particular 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.

[0139] This disclosure recognizes that the use of such personal information data in the present technology may be for the benefit of the user. For example, the personal information data may be used to authenticate the identity of the user. Additionally, other uses of personal information data that benefit the user are also contemplated by this disclosure.

[0140] This disclosure contemplates that entities responsible for collecting, analyzing, disclosing, transmitting, storing, or otherwise using such personal information data will adhere to well-established privacy policies and / or privacy practices. Specifically, such entities would be expected to implement and consistently apply privacy practices generally recognized as meeting or exceeding industry or government requirements for maintaining user privacy. Such information regarding the use of personal data should be prominent and easily accessible by users and should be updated as data collection and / or use changes. Personal information from users should be collected only for legitimate uses (e.g., travel to and from foreign jurisdictions). Furthermore, such collection / sharing should occur only after receiving the user's consent or based on other legitimate grounds specified in applicable law. Moreover, such entities should consider taking all necessary measures to protect and secure access to such personal information data and to ensure that others with access to the personal information data adhere to their privacy policies and procedures. Furthermore, such entities may undergo third-party assessments to demonstrate their adherence to widely accepted privacy policies and practices. Additionally, policies and practices should be tailored to the specific types of personal information data collected and / or accessed, and should comply with applicable laws and standards, including jurisdiction-specific considerations that may serve to impose higher standards. For example, in the United States, the collection of or access to certain biometric data may be governed by federal and / or state law, while biometric data in other countries may be subject to other regulations and policies and should be addressed accordingly.

[0141] Notwithstanding the foregoing, the present disclosure also contemplates embodiments in which a user selectively prevents use of or access to personal information data. That is, the present disclosure contemplates that hardware and / or software elements may be provided to prevent or block access to such personal information data. For example, the present technology may be configured to allow a user to select whether to “submit” or “not submit” a travel document to the screening system. In addition to providing the “submit” and “not submit” options, the present disclosure contemplates providing notifications regarding the access or use of personal information. For example, a user may be notified that passport data will be accessed when using an App Clip, and then be reminded again immediately before the passport data is accessed by the app.

[0142] Some or all of these techniques may be at least partially implemented by architectures such as those illustrated above in Figures 1-13, although this is not required. While many of the embodiments are 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. Furthermore, in the foregoing description, various non-limiting examples have been described. For purposes of explanation, specific configurations and details have been set forth to provide a thorough understanding of the examples. However, it will also be apparent to those skilled in the art that the examples may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified so as not to obscure the described examples.

[0143] Various embodiments may further be implemented in a wide variety of operating environments, and in some cases, they may include one or more user computers, computing devices, or processing devices that can be used to run any of several applications. User or client devices may include any number of general-purpose personal computers, such as desktop or laptop computers, running standard operating systems, as well as cellular, wireless, and handheld devices that can run mobile software and support numerous network and messaging protocols. Such systems may also include multiple 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 dummy terminals, thin clients, gaming systems, and other devices capable of communicating over a network.

[0144] Most embodiments utilize at least one network well known to those skilled in the art to support communications using any of a variety of commercially available protocols, such as TCP / IP, OSI, FTP, UPnP, NFS, CIFS, AppleTalk, etc. For example, the network can be 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.

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

[0146] The environment may include various data stores and other memory and storage media, as previously described. These may reside in a variety of locations, such as on storage media local to (and / or resident on) one or more of the computers across the network, or on storage media remote from any or all of the computers. In a particular set of embodiments, information may reside within a storage-area network (SAN), which is well known to those skilled in the art. Similarly, files necessary to perform functions by a computer, server, or other network device may be stored locally and / or remotely as needed. Where the system includes computerized devices, each such device may include hardware elements that may be electrically coupled via a bus, including, 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 a system may include one or more storage devices such as disk drives, optical storage devices, and semiconductor storage devices (such as RAM or ROM), as well as removable media devices, memory cards, flash cards, and the like.

[0147] Such devices may also include computer-readable storage medium readers, communication devices (e.g., modems, network cards (wireless or wired), infrared communication devices, etc.), and working memory, as previously described. A computer-readable storage medium reader may be connected to or configured to accept a non-transitory computer-readable storage medium, which represents remote, local, fixed, and / or removable storage devices, as well as storage media for temporarily and / or more permanently storing, storing, transmitting, and retrieving computer-readable information. Systems and various devices also typically include multiple software applications, modules, services, or other elements, including an operating system and application programs (e.g., client applications or browsers), that are located within at least one working memory device. It should be understood that alternative embodiments may have numerous variations from the embodiments described above. For example, customized hardware may be used and / or particular elements may 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 may be used.

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

[0149] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense, although it will be apparent that various modifications and changes may be made thereto without departing from the broader spirit and scope of the present disclosure as set forth in the appended claims.

[0150] Other variations are within the spirit and scope of the present disclosure. Accordingly, while the disclosed technology is susceptible to various modifications and alternative constructions, specific example embodiments of the disclosed technology have been shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the disclosure to the particular form or forms disclosed; on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents included within the spirit and scope of the present disclosure as defined in the appended claims.

[0151] In the context of describing the disclosed embodiments (particularly in the context of the claims that follow), use of the terms "a," "an," and "the" and similar designations should be construed to encompass both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms "comprising," "having," "including," and "containing" should be construed as open-ended (i.e., meaning "including, but not limited to"), unless otherwise noted. The term "connected" should be construed as partially or fully contained within, attached to, or joined together, even if there is something intervening. The phrase "based at least in part on" should be understood to be open-ended and in no way limiting, and is intended to be construed as "based at least in part on" or otherwise read, where appropriate. The recitation of ranges of values ​​herein, unless otherwise indicated herein, is merely intended to serve as a shorthand method of referring individually to each individual value falling within the range, and each individual value is herein incorporated as if it were individually stated herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or example language (e.g., "etc.") provided herein is intended merely to better clarify embodiments of the present disclosure and does not impose a limitation on the scope of the present disclosure unless specifically claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0152] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is understood within the context in which it is generally used to indicate that an item, term, etc., can be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless specifically stated otherwise. Thus, such disjunctive language is generally not intended to, and should not, imply that a particular embodiment requires that at least one of X, at least one of Y, or at least one of Z, respectively, be present. Furthermore, conjunctions 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," unless specifically stated otherwise.

[0153] Preferred embodiments of the present disclosure are described herein, including the best mode known to the inventors for carrying out the disclosure. Variations of these preferred embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. The inventors anticipate that such variations will be employed by those of ordinary skill in the art as appropriate, and the inventors intend for the present disclosure to be practiced otherwise than as specifically described herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Furthermore, any combination of the above-described elements in all possible variations of the present disclosure is encompassed by the present disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0154] All references, including publications, patent applications, and patents, cited in this specification are herein incorporated by reference to the same extent as if each reference was individually and specifically indicated to be incorporated by reference and to the same extent as if each reference was set forth herein as a whole.

Claims

1. 1. A method comprising: receiving, by a user device storing a mobile identity certificate private key, a request for a mobile identity certificate from an audit system; transmitting, by the user device, the mobile identity document to the screening system based at least in part on the request, the mobile identity document including a mobile identity document public key; receiving, by the user device, a mobile supplement from the vetting system, the mobile supplement including a mobile supplement public key derived from the mobile identity certificate public key, the vetting system being configured to derive the mobile supplement public key from the mobile identity certificate public key; deriving, by the user device, a mobile supplement private key corresponding to the mobile supplement public key, the mobile supplement private key being derived from the mobile identity certificate private key; linking, by the user device, the mobile supplement to the mobile identity document based at least in part on the derivation of the mobile supplement private key from the mobile identity document private key. method.

2. The method comprises: determining whether user consent has been provided to transmit the mobile identity document to the screening system; The method of claim 1 , further comprising: transmitting the mobile identity document based at least in part on the determination.

3. 3. The method of claim 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 the method further comprises transmitting the mobile identity document and the mobile visa to the screening system based at least in part on the sequential requests.

4. the request comprises a first request, and the method comprises: transmitting the mobile identity document to the screening system based at least in part on the first request; receiving a second request for a mobile visa subsequent to the first request; transmitting the mobile visa based at least in part on the second request. The method according to any one of claims 1 to 3.

5. The method of any one of claims 1 to 4, wherein the mobile supplemental document includes a mobile identity number associated with the mobile identity document, the mobile identity number further linking the mobile supplemental document to the mobile identity document.

6. The method of any one of claims 1 to 5, further comprising storing the mobile identity certificate private key and the mobile supplement private key in a secure location on the device.

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

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

9. 1. A user device, comprising: a processor; A computer-readable storage medium containing instructions that, when executed by the processor, cause the processor to perform operations, the operations including: receiving a request for a mobile identity certificate from an audit system, the user device storing a mobile identity certificate private key; transmitting the mobile identity document to the screening system based at least in part on the request, the mobile identity document including the mobile identity document public key; receiving a mobile supplement from the vetting system, the mobile supplement including a mobile supplement public key derived from the mobile identity certificate public key, the vetting system configured to derive the mobile supplement public key from the mobile identity certificate public key; deriving a mobile complement private key corresponding to the mobile complement public key, the mobile complement private key being derived from the mobile identity certificate private key; and linking the mobile supplement to the mobile identity certificate based at least in part on the derivation of the mobile supplement private key from the mobile identity certificate private key. User device.

10. The instructions, when executed by the processor, further cause the processor to perform operations, the operations including: determining whether user consent has been provided to transmit the mobile identity document to the screening system; transmitting the mobile identity document based at least in part on the determination. The user device of claim 9 .

11. 11. The user device of claim 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 the instructions, when executed by the processor, further cause the processor to perform an operation including transmitting the mobile identity document and the mobile visa to the screening system based at least in part on the sequential requests.

12. The request includes a first request, and the instructions, when executed by the processor, further cause the processor to perform an operation, the operation comprising: transmitting the mobile identity document to the screening system based at least in part on the first request; receiving a second request for a mobile visa subsequent to the first request; and transmitting the mobile visa based at least in part on the second request.

13. 13. The user device of claim 9, wherein the mobile supplemental document includes a mobile identity number associated with the mobile identity card, the mobile identity number further linking the mobile supplemental document to the mobile identity card.

14. 14. The user device of claim 9, wherein the instructions, when executed by the processor, further cause the processor to perform operations including storing the mobile identity certificate private key and the mobile supplement private key in a secure location on the device.

15. A user device according to any one of claims 9 to 14, wherein the screening system is associated with a first jurisdiction and the mobile identity card is associated with a second jurisdiction.

16. A user device according to any one of claims 9 to 15, wherein the mobile identity document is a mobile passport and the mobile supplemental document is a mobile travel record.

17. 1. A non-transitory computer-readable medium containing a set of instructions stored thereon that, when executed by a processor of a cloud infrastructure node, cause the processor to perform operations, the operations including: receiving a request for a mobile identification card from a screening system; transmitting the mobile identity to the screening system based at least in part on the request, the mobile identity including the mobile identity public key; receiving a mobile supplement from the vetting system, the mobile supplement including a mobile supplement public key derived from the mobile identity certificate public key, the vetting system configured to derive the mobile supplement public key from the mobile identity certificate public key; deriving a mobile complement private key corresponding to the mobile complement public key, the mobile complement private key being derived from a mobile identity certificate private key; linking the mobile supplement to the mobile identity document based at least in part on the derivation of the mobile supplement private key from the mobile identity document private key. Non-transitory computer-readable medium.

18. the mobile identity card is a mobile passport, and the instructions, when executed by the processor, further cause the processor to perform an operation, the operation comprising: determining whether user consent has been provided to transmit the mobile passport to the screening system; transmitting the mobile passport based at least in part on the determination.

20. The non-transitory computer-readable medium of claim 17.

19. 19. The non-transitory computer-readable medium of claim 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 the method further includes transmitting the mobile identity document and the mobile visa to the screening system based at least in part on the sequential requests.

20. 20. The non-transitory computer-readable medium of claim 17, wherein the mobile supplemental document includes a mobile identity number associated with the mobile identity document, the mobile identity number further linking the mobile supplemental document to the mobile identity document.

Images