WO2023288037A1

WO2023288037A1 - Device and systems for remotely provisioning sim profile with strong identity and strong authentication

Info

Publication number: WO2023288037A1
Application number: PCT/US2022/037242
Authority: WO
Inventors: Simon Law; Pasan Hapuarachchi; Michael Allan; Bryan Neilson; William Leddy
Original assignee: Login Id Inc.
Priority date: 2021-07-16
Filing date: 2022-07-15
Publication date: 2023-01-19

Abstract

Mobile network operators need to verify the identity of the user before remotely provisioning a user device with an eSIM, which is prone to fradulence. A user device and an ID server use facial scanning to verify the identity of a person and to provide strong authentication, such as Fast Identity Online (FIDO) authentication. The user device captures a scanned image of an identity document and extracts the photo of the person. The user device also captures an image of the person's face and compares this image with the extracted photo from the identity document. After confirming the faces match, an eSIM provider server provisions the user device with an eSIM profile, which is associated with the strong authentication credentials. Future actions or data, or both, provided by the mobile network operator are trusted by third parties, by using strong authentication credentials which verify the user.

Description

DEVICE AND SYSTEMS FOR REMOTELY PROVISIONING SIM PROFILE WITH STRONG IDENTITY AND STRONG AUTHENTICATION

CROSS-REFERENCE TO RELATED APPLICATION:

[001] This application claims priority to United States Patent Application No.

63/203,287 filed on July 16, 2021 and titled “Device And Systems For Remotely Provisioning SIM Profile With Strong Identity And Strong Authentication”, the entire contents of which are herein incorporated by reference.

TECHNICAL FIELD

[002] The following generally relates to remotely provisioning a SIM profile into a mobile device with strong identity and strong authentication.

DESCRIPTION OF THE RELATED ART

[003] Mobile devices (e.g., smart phones, cell phones, tablets, phablets, computers, loT devices, etc.) typically use a subscriber identity module (SIM) card to connect to a mobile network. These mobile devices are also herein referred to as user devices. The SIM card is a physical card that is inserted into a mobile device, and it stores information that identifies the user and the specified mobile network operator. SIM cards can be removable from the mobile device, so that one or more SIM cards can be used with the mobile device over time, or in some cases, at the same time. Different physical form factors of SIM cards include, for example, full SIM, mini-SIM, micro-SIM, nano-SIM and embedded SIM.

[004] SIM cards are difficult and cumbersome to use. For example, a mobile network operator (MNO) needs to provide a physical SIM card to the user, and the user needs to physically insert the SIM card into their user device. This is difficult if a user cannot physically go to a trusted MNO store, verify their identity in person, get the SIM card. Furthermore, physical SIM cards can be swapped in and out of user devices, causing fraud.

[005] Mobile devices and machine-to-machine devices (also called Internet of Things or loT devices) are starting to transition to a SIM technology that no longer uses the conventional SIM cards. Instead, user devices will become equipped with an embedded Universal Integrated Circuit Card (eUICC) that acts as a programmable SIM card. The eUICC is part of the native hardware of the mobile device or machine and, in other words, there is no requirement to insert a SIM card to connect to a mobile network.

[006] The eUICC is provisioned after completing a know-your-client (KYC) process.

For example, turning to FIG. 1 , in Step 1 , a remote eSIM provisioning process typically includes a mobile network operator 110, or a representative of the mobile network operator, physically meeting and vetting a given user 10. For example, the given user provides their name, address, and photo identification to complete the KYC process. In another example embodiment, a photograph of a driver license is sent to the representative of the mobile network operator for verification of the user, when attempting to remotely complete the KYC process. The given user also typically provides payment 11. Assuming the KYC process has been completed, either in-person or remotely, and that payment has been made, the mobile network operator (or their representative) gives a QR code 12 on a printed document to the given user. The given user uses a camera device, which is part of their user device 13, to scan the QR code 14. For example, the QR code includes an address that launches a data session 18 between a provisioning server system 15 of the mobile network operator and the given user’s mobile device 13. In the session 18, data is exchanged between the user device 13 and the provisioning system 15. The user device 13 includes an eUICC 16, which includes data storage for one or multiple eSIM profiles 17a, 17b, 17c. In Step 1, no eSIM profiles have been stored on the eUICC. In Step 2, the SIM profile 18 is downloaded 19 from the provisioning server system 15 onto the eUICC 16 and activated. In an example aspect of Step 2, an activation code is sent from the user device to the provisioning server system, and the provisioning server system verifies the activation code before returning the data package that contains the eSIM profile. In Step 3, after the eSIM profile has been provisioned and enabled on the eUICC, the user device is then able to connect to the mobile network of the mobile network operator.

[007] It is herein recognized, however, that this process is prone to false data (e.g., purposely fraudulent data), leading to incorrectly provisioned SIM profiles. Furthermore, it is herein recognized that obtaining accurate data in the provisioning process is difficult, as interactions between a mobile network operator, or their representative, and a given user become more remote or virtual. Furthermore, the QR code or data link provided by the mobile network operator, and intended for the user 10, could be stolen or purposely given to another person to provision a different mobile device with an eSIM profile. It is herein recognized that current processes do not verify a strongly authenticated identity of the given user, nor verifiably link a strongly authenticated identity of the given user to their eSIM profile. These technical difficulties become even more challenging when addressing them at a large scale with numerous user devices.

BRIEF DESCRIPTION OF THE DRAWINGS

[008] Embodiments will now be described by way of example only with reference to the appended drawings wherein: [009] FIG. 1 is a schematic diagram showing an existing process of remotely provisioning an eSIM profile on a user device.

[0010] FIG. 2A is a schematic diagram of an example of a system of user devices and server systems that include, for example, an ID server, a Service Provider server and a trusted verifier server.

[0011 ] FIG. 2B shows example components and data on the user device, including specifically the device authenticator, the eUICC, and the local profile assistant (LPA).

[0012] FIG. 3 is a flow diagram of example computer executable or processor implemented instructions for a user device to register using Fast Identity Online (FIDO) authentication and to remotely provision the eSIM profile, including using facial scanning, according to an example embodiment.

[0013] FIGs. 4A and 4B is a flow diagram of example computer executable or processor implemented instructions for a user device, a mobile network operator and an ID server to execute FIDO authentication, remotely provision an eSIM profile, and associate the FIDO credential with the eSIM profile, according to another example embodiment.

[0014] FIG. 5 is a flow diagram of example computer executable or processor implemented instructions for a user device to remotely provision the eSIM profile, complete FIDO authentication, and then associate the FIDO credential with the eSIM profile, according to another example embodiment.

[0015] FIG. 6 is a flow diagram of example computer executable or processor implemented instructions, which is focused on certain operations in FIG. 5, for a user device, an ID server and a mobile network operator to complete FIDO authenticator and associate the FIDO credential with the eSIM profile, according to an example embodiment.

[0016] FIG. 7 is a flow diagram of example computer executable or processor implemented instructions, which are executed after associating the FIDO credential and the eSIM profile. The instructions include executing an action using FIDO authentication and communicating with the mobile network operator.

[0017] FIGs. 8A, 8B, 8C, 8D, 8E, 8F, 8G, 8H, 8I, 8J and 8K show example embodiments of graphical user interfaces (GUI) in a process for FIDO authentication, facial scanning, and eSIM provisioning.

[0018] FIG. 9 is another schematic diagram of an example of a system of user devices and server systems that include, for example, an ID server, a Service Provider server and a trusted verifier server. A first user device that is provisioned with a first eSIM profile is used to provision a second device with a second eSIM profile, in which identity of the first eSIM profile is also linked to the second eSIM profile.

[0019] FIG. 10 is a flow diagram of example computer executable or processor implemented instructions for a first user device, a mobile network operator, an ID server, and a second device to provision a second eSIM profile in the second device. The first user device already has been provisioned with a first SIM profile, and the second eSIM profile is linked to the first eSIM profile.

[0020] FIG. 11 is another schematic diagram of an example of a system of user devices and server systems that include, for example, an ID server, a Service Provider server and a trusted verifier server. A first user device that is provisioned with a first eSIM profile is used to provision a third device with a third eSIM profile, in which identity of the first eSIM profile is also linked to the third eSIM profile. The third device includes its own device authenticator.

[0021 ] FIGs. 12a and 12b are a flow diagram of example computer executable or processor implemented instructions for a first user device, a mobile network operator, an ID server, and a third device to provision a third eSIM profile in the third device. The first user device already has been provisioned with a first SIM profile, and the third eSIM profile is linked to the third eSIM profile.

DETAILED DESCRIPTION

[0022] It will be appreciated that for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the example embodiments described herein. However, it will be understood by those of ordinary skill in the art that the example embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the example embodiments described herein. Also, the description is not to be considered as limiting the scope of the example embodiments described herein.

[0023] Within this specification, different structural entities (which may variously be referred to as “nodes”, “units”, “circuits”, “systems”, “processors”, “module”, “interface”, “device”, “server”, other components, etc.) may be described or claimed as “configured” to perform one or more tasks or operations. This formulation - [entity] configured to [perform one or more tasks] - is used herein to refer to structure (i.e., something physical, such as an electronic circuit). More specifically, this formulation is used to indicate that this structure is arranged to perform one or more tasks during operation. A structure can be said to be “configured to” perform some task even if the structure is not currently being operated. A “biometric sensor configured to collect biometric data” is intended to cover, for example, an integrated circuit that has circuitry that performs this function during operation, even if the integrated circuit in question is not currently being used (e.g., a power supply is not powering it). Thus, an entity described or recited “configured to” perform some task refers to something physical, such as a device, circuit, memory storing program instructions executable to implement the task, etc. This phrase is not used herein to refer to something intangible. Thus, the “configured to” construct is not used herein refer to a software entity, such as an application programming interface (API).

[0024] The term “configured to” is not intended to mean “configurable to.” An unprogrammed Field Programmable Gate Array (FPGA), for example, would not be considered to be “configured to” execute some specific operation, although it may be “configurable to” perform that specific operation and may be “configured to” execute that specific function after programming.

[0025] Reciting in the appended claims that a structure is “configured to” perform one or more tasks is intended not to be interpreted as having means-plus-function elements.

[0026] Throughout the specification and the claims, the following terms take at least the meanings explicitly associated herein, unless the context clearly dictates otherwise. The term "or" is intended to mean an inclusive "or." Further, the terms "a," "an," and "the" are intended to mean one or more unless specified otherwise or clear from the context to be directed to a singular form.

[0027] In this specification, numerous specific details have been set forth. It is to be understood, however, that implementations of the disclosed technology may be practiced without these specific details. In other instances, well-known methods, structures, and techniques have not been shown in detail in order not to obscure an understanding of this description. References to “for example”, "some examples," "other examples," "one example," "an example," "various examples," "one embodiment," "an embodiment," "some embodiments," "example embodiment," "various embodiments," "one implementation," "an implementation," "example implementation," "various implementations," "some implementations," etc., indicate that the implementation(s) of the disclosed technology so described may include a particular feature, structure, or characteristic, but not every implementation necessarily includes the particular feature, structure, or characteristic. Further, repeated use of the phrases "in one example," "in one embodiment," or "in one implementation" does not necessarily refer to the same example, embodiment, or implementation, although it may.

[0028] As used herein, unless otherwise specified the use of the ordinal adjectives "first," "second," "third," etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.

[0029] Devices, systems and processes are herein provided for using biometrics for strong identity and strong authentication to execute an action. For example, strong identity and strong authentication processes are integrated into a single session. The action, for example, can be to access a database, log into an online platform, execute a transaction, etc.

[0030] It is herein recognized that verifying an identity of a person using remote communication (e.g., Internet, cell networks, etc.) is difficult during an eSIM provisioning process because images of identity documents can be fraudulent or copied and distributed to adversaries without the person’s permission. Furthermore, it is herein recognized that information about a new user device is not yet verifiable, since it is new and it is not yet bound to the given person (e.g., the new user). Therefore, in an example aspect, a system is provided that remotely provisions an eSIM profile into the embedded Universal Integrated Circuit Card (eUICC), remotely verifies and strong authenticate the identity of user (e.g., using Fast Identity Online (FIDO) authentication), and associates the FIDO credential and the eSIM profile. The eSIM profile, for example, is identified by a mobile network operator (MNO) trusted identifier (e.g., also herein interchangeably referred to as a MNO trusted ID).

[0031] In an example aspect, a system is herein provided that verifies a strongly authenticated identity of the given user and verifiably links a strongly authenticated identity of the given user to their eSIM profile. In an example aspect, the strongly authenticated identity is a FIDO credential, and the FIDO credential is tied to a MNO trusted ID.

[0032] In an example embodiment, by linking the user device’s FIDO credential with a cellular network level verification (e.g., an eSIM profile or a MNO trusted ID, or both), additional actions can be made by mobile network operator with the user device, or on behalf of the user device (or both). These additional actions executed or permitted by the mobile network operator are verifiably linked to the strongly authenticated identity of the user of the user device.

[0033] Turning to FIG. 2A, the computing architecture includes one or more users 101 and their user devices 100. Examples of user devices include mobile devices, laptops, desktop computers, tablets, smart phones, etc. A user device 100 includes hardware components 102, examples of which include a processor, memory, a communication module (e.g., for communicating via a cell network, WiFi, LAN, WAN, etc.), and a user interface (e.g., display screen, touch interface, keyboard, mouse, etc.). In an example embodiment, one communication module (e.g., Comm. A in FIG. 1 ) is for WiFi communication (i.e., a non- cellular network communication) and another communication module (e.g., Comm.B in FIG.

1 ) is for cellular network communication. In other words, the user device includes at least two types of communication radio devices, including a WiFi radio communication module and a cellular network communication module (e.g., a radio device compatible with 3G, 4G, 5G, and later generations of cellular communication networks). These hardware components 102 can vary in type, number and architecture as user devices continue to develop. In an example aspect, the user device 100 includes a browser 103a, or a native application (also called an app) 103b, or both. The browser 103a or the native app 103b, or both, are more generally herein referred to as the user agent 104. The user agent 104 displays a graphical user interface (GUI) on a display screen to guide the user through the authentication process and the related action (e.g., logging in, executing a command, a transaction, accessing data, etc.).

[0034] The user device also has a device authenticator (DA) 105, which is used to store user-identifying data on the device in a secure manner and to authenticate the user. In an example aspect, device authenticator 105 is a hardware device or hardware component that includes a secure execution and secure storage environment, and which can be implemented using one or more of: a Trusted Execution Environment (TEE); a secure element, a firewall; a software layer; a secure enclave; a Hardware Secure Module (HSM); etc. It will be appreciated that a TEE is a computing chip that, for example, exists on a processor device. It will be appreciated that a HSM is a separated computing appliance. Preferably, in an example embodiment, the device authenticator is a secure hardware component that also includes software security. Authentication data about a user 101 can be stored in the device authenticator. The authentication data about the user, for example, includes a device authentication private key (also referred to as a DA private key) associated with the user 101 and the device authenticator 105 of the device 100. In an example aspect of using the FIDO protocol, the DA private key is known as a FIDO private key. In another example aspect, the device authenticator may also store other data, including, but not limited to: biometric authentication data, passwords, security codes, name, address, account numbers (e.g. like a primary account number (PAN), driver’s license number, etc.), age, date of birth, citizenship, credentials, etc. [0035] The user device may also include one or more scanners 106. Examples of scanners 106 includes a rear camera 106a, a front camera 106b, a radio frequency identification (RFID) scanner 106c, a thumbprint scanner 106d, a heartrate monitor, a microphone for voice detection, etc. In an example embodiment, a face scanning system includes a dot projector that projects infrared dots on a person’s face and an infrared camera takes an image of the face and the dots. The thumbprint scanner, the heartrate monitor, the microphone for voice detection, and the face scanning system are examples of biometric sensors used to verify the identity of a user based on scanning or collecting biometric data.

It is appreciated that currently known and future known scanners can be used to verify that the correct person is truly interacting with their user device.

[0036] The device authenticator 105, for example, interacts with a scanner 106 to obtain identifying data about the user, and compares the scanned identifying data about the user with stored identifying data about the user. For example, the identifying data about the user is biometric authentication data, including and not limited to one or more of: fingerprint scan, eye scan, facial recognition, voice recognition, heartbeat or pulse monitoring, DNA sampling, body temperature, etc. The scanner 106 includes one or more sensors that can capture the biometric authentication data.

[0037] In preferred example embodiments, the processes described herein use a scanner 106. It will also be appreciated that the identifying information about the user can include data that is not biometric in nature. For example, other identifying information includes a password, a pin, a swipe pattern, a code, etc.

[0038] In an example aspect, the user device further includes the eUICC 107 and the local profile assistant (LPA) 108. The eUICC enables the local management of eSIM profiles in a secure way. The eUICC interacts with the LPA. The LPA is a functional element in the user device or in the eUICC 107. The LPA, for example, downloads the eSIM profile into the eUICC. The eUICC then acts a holder of the subscriber identity information for connecting to a mobile network operator. More details about the eUICC and LPA are provided below.

[0039] It will be appreciated that the user device 100 further includes a data bus that facilitates the flow of data between the components and the processor. In other words, the components of the user device are connected to the data bus.

[0040] Continuing with FIG. 2A, in an example embodiment, the device authenticator

105 and the one or more scanners 106 are built into the user device 100.

[0041] In another example embodiment, the device authenticator 105 and the scanner

106 are part of an external authenticator device 100’. The user device 100 and the external authenticator device 100’ are in data communication with each other. For example, the external authenticator device 100’ is connected to the user device 100 via a wire or some other electrical connection (e.g., universal serial bus (USB)). In another example, the external authenticator device 100’ is connected to the user device 100 via wireless communication. Examples of wireless communication include Bluetooth, Near Field Communication, and WiFi. Example embodiments of an external authenticator device 100’ include a smart watch, a USB key, a dongle, and a smartphone. The term “user device” collectively refers to the user device 100 and an external authenticator device 100’, in embodiments that include an external authenticator device.

[0042] The one or more user devices 100 are in data communication with a data network 130. The system also includes other servers 109, 110, 111, 112, 113 which are also in data communication with the data network 130. A “server” herein refers to a computing system that can include one server computer or multiple server computers that are networked to operate together. A server includes one or more processors, memory, and a data communication module for connecting to the network 130. A server also includes software and other logic modules for storing data and executing instructions.

[0043] The eSIM provider server 109 manages and provides the eSIM profiles to user devices. The eSIM provider server, for example, includes a subscription manager data preparation + (SM-DP+). The SM-DP+ is responsible for the creation, generation, management and the protection of resulting eSIM profiles. It is also responsible for the delivery of a profile and making a bound profile package available for secure delivery. The eSIM provider server 109 can also include a subscription manager discovery service (SM- DS). In some example embodiments, the SM-DS are the SM-DP+ are separate computing entities. In this document, these are collectively referred to as the eSIM provider server 109.

[0044] The mobile network operator 110 is an entity of servers and cellular network devices that provide wireless cellular network infrastructure and services. Mobile virtual network operators can purchase these services and resell these services as their own. User devices use eSIM profiles in their eUICC to subscribe to a mobile network operator or a mobile virtual network operator, to access the communication services and the cellular network infrastructure. Although the example embodiment described herein refer to a mobile network operator, it will be appreciated that the principles of the systems and methods described herein can also be interchangeably applied to a mobile virtual network operator.

[0045] In an example embodiment, the eSIM provider server 109 and the mobile network operator 110 are separated. In another example embodiment, the eSIM provider server and the mobile network operator are the same entity. In an example embodiment, the eSIM provider server 109 is also referred to as the provisioning system 15 described in FIG. 1.

[0046] The ID server 111 executes processes that establish and attests to the identity of a user. In an example aspect, for the purpose of establishing identity, the ID server verifies the identity of the user against a trusted government credential using facial biometrics, or other user identity information, or a combination thereof. In another example aspect, for the purpose of attestation, the ID server executes the FIDO protocol to store registered and authenticated user accounts. For example, the ID server performs Strong Identity using facial biometric data captured image of a user against either a reference image or a cropped image of a credential with methods described in the different embodiments. In an example aspect, the ID server and the user device use video recording to conduct a liveness detection of the person, such as live movement of the person’s face. The ID server attests to the authentication of a user by sending a challenge to the user device of the user, receiving a response to the challenge that is signed by the device authenticator 105 of the user device, and authenticating the response using the FIDO protocol. For new users, the ID server also executes a registration process that includes verifying facial biometric data.

[0047] In the examples provided herein, an initial condition may already be established that includes a device authentication private key being securely stored on the device authenticator 105, and the corresponding device authentication public key being stored on the ID server 111. The generation and storage of these keys, for example, adhere to the FIDO protocols developed by the FIDO Alliance (www.fidoalliance.com). In an example aspect, the device authenticator generates the device authenticator private key and the device authenticator public key, and the device authenticator sends the device authenticator public key to the ID server 111 for storage. The device authentication private key can be used to sign responses. These signed responses can include other data, depending on the application. For example, signed responses can include credential data, authorization data, commands, transaction details, etc.

[0048] The trusted verifier server 112, also called the TVS, executes processes to verify an identity document. The TVS 112 for example is specific to a certain organization depending on the type of identity document. For example, a government entity may have a TVS 112 that verifies a government issued identity document (e.g., a passport). A DMV entity, for example, has a TVS 109 that verifies driver licenses, which are a type of identity document. A credit check organization, for example, has a TVS that verifies credit card identity documents. A healthcare entity, for example, has a TVS 112 that verifies healthcare identity documents. The TVS 112, for example, is in data communication with one or more of the other servers 111, 110, 109 and verifies the identity document associated with a user.

[0049] The term “identity document” herein refers to a document that includes identity information or credential information, or both, about a user. In an example embodiment, the identity document includes a photograph of the user. Other types of information that an identity document could include are, for example: name, address, data of birth, sex, citizenship, weight, height, signature, serial number, issue date, expiry date, a code, a bar code, a QR code, special markings (e.g., water markings, holographic markings, stamps, insignia, etc.), a signature of a user, data related to a user account, credentials of the user, data related to the organization, etc. Examples of identity documents include: a driver license, a passport, a healthcare card, a student card, a citizenship or national identity card, an employee card, an academic certificate, a government document, and a health report. Other types of identity documents can be used according to the principles described herein.

[0050] The third-party server 113 operates an interface for conducting operations with the user device 100. For example, third party server is a relying party that relies on the data verification and user authentication provided by the other servers, such as the mobile network operator 110. The service provider server, for example, is an organization (e.g., bank, government entity, healthcare organization, merchant or some other party) that wishes to process a transaction with the user 101. The third-party server 107, for example, has a website on which the user wishes to execute a transaction. In some embodiments, the service provider server provides a physical good, digital good, or service in return for a successful transaction with the user. The transaction or action includes, for example, verifying the identity of the user via the mobile network operator and the user device using FIDO authentication. After registering strong authentication credentials (e.g., FIDO credentials) with the mobile network operator, future actions or data, or both, provided by the mobile network operator are trusted by third parties, by using strong authentication credentials which verify the user.

[0051] It will be appreciated that there may be multiple instances of each of the servers. For example, different instances of a server store different data, or are located in different geographical regions, or both.

[0052] Turning to FIG. 2B, example components of the device authenticator 105, the eUICC 107 and the LPA 108 are shown. As noted above, in an example embodiment, the LPA is a separate element from the eUICC in the user device, and in another example embodiment, the LPA exists within the eUICC. The device authenticator 105 stores thereon the DA private key (e.g., the FIDO private key) 201. In an example embodiment, the device authenticator 105 also stores, for example, the DA public key 202 and other user authentication data 203. The eUICC 107 includes, for example, an eUICC operating system 205, one or more operator disabled profiles 206, one or more operator enabled profiles 207, an embedded UICC controlling authority security domain (ECASD) 208, and an issuer security domain - root (ISD-R) 209. The ECASD securely stores the credentials needed to support the security on the eUICC, and the ECASD includes eUICC private keys for creating signatures, associated certificates for eUICC authentications, eUICC manufacturers’ keyset for key or certificate renewal, and the certificate issuers’ root public keys for verifying the eSIM provider server 109. The ISD-R creates one or more new operator enabled profiles, and manages the lifecycle of these profiles. The LPA 108 includes, for example, a local discovery service (LDS) 220, a local profile download (LPD) 221 , and a local user interface (LUI) 222. The LDS 220 retrieves pending event records from a subscription manager discovery service. The LPD 221 manages the download of the profile package (e.g., the eSIM profile), including downloading the profile package from the eSIM provider server 109 (e.g., the SM-DP+), and transferring the profile package to the eUICC. The LUI 222 allows the user to perform local profile management of the user device. In other words, the LPA (via the LPD) downloads the profile package (also called an Interoperable Profile Package (IPP)), which is a piece of encrypted software transferred from the SM-DP+ over a secure communication, and the LPA passes the IPP to the eUICC, which decrypts and installs the software provisioning the eSIM.

[0053] In an example embodiment, a user device and a server use facial scanning to verify identity of a person and to provide strong authentication. The user device captures a scanned image of a trusted identity document (e.g., a driver license, a passport, a national identity document, a credential document, etc.) extracts the photo of the person from the identity document. The user device also captures an image of the person’s face (e.g., a selfie photo) and compares this image with the extracted photo from the identity document.

If the faces match, then the person’s identity is verified. The verification of the identity and a related action (e.g., registration of the person, logging into a system, etc.) are authenticated using FIDO authentication, or some other type of strong authentication. After FIDO authentication is complete, the eSIM profile is provisioned into the eUICC. The user device and the mobile network operator then communicate with each other to confirm that FIDO authentication. It is appreciated that the FIDO credentials and the eSIM profile are associated with each other. In another example aspect, the FIDO credentials are associated with a MNO trusted ID. It will also be appreciated that the order of the computing processes can vary from the preferred example embodiments described herein. [0054] In another example embodiment, FIDO authentication is completed, and then identity verification is executed by scanning or photographing a trusted identity document. The eSIM profile is provisioned to the eUICC, and the user device and the mobile network operator confirm the FIDO authentication. In an example aspect, the MNO and the user device execute a FIDO confirmation over the MNO network. For example, this is done as a way to confirm that the FIDO authentication can be executed between the MNO and the user device. This can also be done in future computations, where the MNO acts as an intermediary with third parties to provide FIDO authentication with the user device.

[0055] Turning to FIG. 3, example executable instructions are provided for registering a user, including user identity verification. An example of the user identity verification include facial scanning. It will be appreciated that other methods of user identity verification are applicable to the principles described herein.

[0056] Block 301 : A new user device is issued to the user. For example, a new user is shipped a user device.

[0057] Block 302: The User Agent is preferably a web browser. In an example embodiment, the User Agent is preinstalled on the user device operating system, such as a preinstalled web browser. However, in another example embodiment, the User Agent is a native app or a web browser that is downloaded via WiFi.

[0058] Block 303: The User Agent is launched on the user device.

[0059] Block 304: The User Agent initiates FIDO authentication, including creating a

FIDO key pair associated with the user device. FIDO authentication includes, for example, obtaining a biometric scan of the user (e.g., a thumbprint scan, a face scan, or some other scan) and signing the authentication data using a FIDO private key from the device authenticator. In other example embodiments, a FIDO key pair is created using a code or pin and does not use a biometric scan of the user.

[0060] Block 305: The User Agent and the camera on the user device are used to scan a user’s photo identification card or document. For example, the photo identification card or document is a driver’s license, or a passport.

[0061] Block 306: The User Agent and the camera (e.g., the same camera or a different camera) on the user device is used to scan the face of the user.

[0062] Block 307: The User Agent initiates a comparison of the face of the user obtained by facial scan, with the face of the user in the photo identification card or document.

[0063] In an example aspect, if the FIDO authentication is not successful, then the process stops. In another example aspect, if the face comparison or some other user identification process is not successful, then the process stops. In another example aspect, blocks 305, 306 and 307 are executed before executing block 304.

[0064] If the FIDO authentication and the user identity verification (e.g., facial comparison) are successful, the process continues with the eSIM profile provisioning.

[0065] Block 308: The User Agent initiates provisioning of the eSIM, which includes obtaining a link via WiFi to the authentication app. It will be appreciated that WiFi is an example, and the link can be obtained via other communication channels. The link is used to connect the User Agent with the eSIM provider server 109. The User Agent, for example, also obtains an activation code to activate the eSIM profile.

[0066] In an example aspect, the User Agent does not execute the eSIM provisioning. Instead, the user device’s native operating system uses the LPA 108 to execute the eSIM provisioning. The user inputs the activation code into a graphical user interface presented by the LPA.

[0067] Block 309: The user device initiates communication with the cell network of the mobile network operator to execute and complete the eSIM provisioning.

[0068] Block 310: After the eSIM profile is provisioned in the eUICC, the user device communicates with the mobile network operator to confirm FIDO authentication. For example, the user device sends a message to the mobile network operator signed by the user device’s FIDO private key, which mobile network operator can verify by accessing a corresponding FIDO public key. Alternatively, the mobile network operator transmits the message to the ID server, which also holds the corresponding FIDO public key, for verification, and the ID server provides a verification confirmation to the mobile network operator.

[0069] It will be appreciated that the eSIM profile and the FIDO credentials (e.g., FIDO authentication data) are associated with each other.

[0070] It will also be appreciated that establishing the FIDO credentials before eSIM provisioning provides continuity. For example, after the eSIM provisioning has been completed, the FIDO credentials are confirmed again, which further ties the FIDO credentials and the eSIM profile together. In another example aspect, if the eSIM provisioning process is stalled or interrupted, the FIDO credentials can be used to verify the user and re-start or continue the eSIM provisioning process.

[0071] A more detailed example embodiment of FIG. 3 is described in FIGs. 4A and 4B. Turning to FIG. 4A, example executable instructions are provided, which show the interaction between the user device, the eSIM provider server or mobile network operator, or both, and the ID server.

[0072] Block 401 : The user device downloads and launches the User Agent via WiFi.

[0073] Block 402: The user device sends its device ID and request to register with the mobile network operator. This is received by the eSIM provider server or the mobile network operator, or both.

[0074] Block 403: After receiving the register request, the eSIM provider server or the mobile network operator, or both, registers the user device and transmits a session confirmation to the ID server.

[0075] Block 404: After receiving the session confirmation, the ID server generates and sends a session ID to the eSIM provider server or the mobile network operator, or both.

This session ID in turn is sent to the user device.

[0076] In an example aspect, the session ID is created early on to create a secure communication session. In an example aspect, the session ID is also associated with the FIDO credential, so that the combination of both can be used in situations when the session is interrupted or stalled or disconnected, and then attempted to be re-started by the user or the user device. The FIDO credentials and the session ID can be used to re-start or continue the eSIM provisioning process or the eKYC process, depending on which stage the process was interrupted or stopped.

[0077] Block 405: The user device is redirected to the ID server and returns the session ID to the ID server.

[0078] Block 406: The ID server verifies the communication from the user device and verifies the secure communication session. It will be appreciated that other currently known and future known computations to establish a secure communication session can be used.

[0079] Block 407: The ID server sends a challenge to the user device.

[0080] In an example aspect, the ID server 111 creates a challenge. For example, it computes hash of one or more of a nonce, a timestamp, etc. The challenge, for example, is signed by the ID server’s private key. It is appreciated that the ID server’s public key is transmitted to the user device at the same time as sending the challenge to the user device, or at some time prior to sending the challenge. In this way, the user device can use the ID server’s public key to verify the ID server’s signature of the challenge. [0081] Block 408: The device authenticator creates a new FIDO public key and new FIDO private key pair associated with the user account to be registered, or identity document, or both.

[0082] Block 409: The device authenticator authenticates the user using user input. For example, the user input is a biometric scan. For example, the user scans their thumbprint, or their face is scanned, or their voice is analyzed, or their DNA is analyzed, or their heartbeat is analyzed, or some combination of biometric signals are captured and analyzed. In another example embodiment, a password, a code, a pin, a swipe pattern, etc. is inputted for user authentication. In an example aspect, this user data is stored as user authentication data in the device authenticator. The device authenticator signs a challenge response using the new FIDO private key. The challenge response, for example, also includes the FIDO public key.

[0083] Block 410: The ID server receives and verifies the signed challenge response and stores the FIDO public key in relation to the user’s user account.

[0084] Block 411 : The user device obtains and sends an identity document with a photo of the user’s face to generate a reference image. For example, the user device’s camera is activated and scans the identity document (e.g., driver license, passport, health card, etc.). For example, the user agent 104 automatically activates the rear camera 106a and the user 101 captures an image of the identity document.

[0085] Block 412: The ID server receives the image of the identity document. It crops the photo of the user’s face from the identity document, thereby obtaining a reference image.

[0086] Block 413: The ID server then processes the other data from the identity document.

[0087] In an example aspect, the ID server extracts other data from the scanned image of the identity document. Examples of the other extracted data include text data, insignia, graphics, numeric data, position of text data and graphics on the document, barcode, QR code, etc. For example, text and numbers are extracted using optical character recognition. In addition or in alternative, the data extracted from the identity document is scanned using NFC, or by accessing a database, or by accessing another device, or a combination thereof.

[0088] In another example aspect of block 413, the user device also obtains and processes metadata of a scanned image of the identity document. Metadata includes, for example, time stamp, geolocation tagging, user device information, and camera information (e.g., F-stop, ISO, focal length, etc.) associated with the scanned image of the identity document. This metadata can be used for verification. [0089] Block 414: The user device captures a picture from a camera of the person’s face, which is sent to the ID server. This is also called a selfie. The picture is a digital data file that includes image data of the person’s face. The picture, in other words, can include one or more images. In an example aspect, this captured picture is a single static image. In another example aspect, the captured picture is a series of static images. In another example aspect, the captured picture is extracted from a video file. In another example aspect, the captured picture is a video file.

[0090] Block 415: The ID server processes this captured picture.

[0091] In an example aspect, the ID server obtains and processes metadata of the picture. Examples of metadata associated with the picture include: time stamp, geolocation tagging, user device information, and camera information associated with the captured picture of the user. For example, the time stamp of the image captured at block 414 should be within a threshold number of seconds from the time the picture of the identity document was taken at block 411. In another example, the geolocation tag of the image captured at block 414 should match the geolocation tag of the picture of the identity document captured at block 411.

[0092] In another example aspect, other features of the captured pictured (captured at block 414) are analyzed to determine if the image of user is live. This can include using a point cloud (e.g., captured via LiDAR) of the person’s face, or by looking at movement of the person’s face over a series of images, or both. This is done, for example, to prevent a user submitting a photo of another static image.

[0093] Block 416: The ID server compares the captured picture (e.g., the selfie) with the cropped photo from the scanned image of the identity document to determine similarity of faces. The ID server verifies that the faces match each other.

[0094] It will be appreciated that if it is determined that the faces do not match, then the registration process is stopped.

[0095] Block 417: In an example aspect, for additional verification of the identity document, the ID server or a trusted verifying partner (e.g., the TVS 112) verifies contents of identity document. For example, the ID server extracts text data (e.g., using optical character recognition) and other data from the scanned image of the identity document. For example, if the identity document is a driver license, then the extracted text data from the scanned image is sent to the TVS 112 for verification of the name, address, driver license number, issue date, expiry date, etc. The TVS 112 verifies that this information is correct and sends a verification message back to the ID server indicating the same. [0096] If the information extracted from the identity document is found to be unverified (e.g., a fake driver’s license, a fake passport, a fake credential document, etc.), then the registration process is stopped.

[0097] Block 418: The ID server associates the verified identity document with the FIDO public key associated with the user account or the identity document (or both). More generally, the ID server associates the verified identity document with the public key associated with the user’s device authenticator.

[0098] Turning to FIG. 4B, the process from FIG. 4A continues.

[0099] Block 419: The ID server sends an attestation message of the identity document to another server (e.g., mobile network operator 110 or eSIM provider server 109). In an example aspect, the attestation message includes the FIDO public key that is associated with the identity document and the user’s device authenticator.

[00100] In an example aspect, the ID Server 108 has associated with it a private key, called the ID server private key, and a corresponding ID server public key. The mobile network operator 110 or eSIM provider server 109 has a copy of the ID server public key. When generating the attestation message, the ID Server signs the attestation message using the ID server private key. The mobile network operator 110 or eSIM provider server 109 uses the ID server public key to verify that the attestation message has been signed by the ID Server.

[00101] Alternatively, the ID server uses its ID server private key to sign the FIDO public key that is associated with the identity document, which becomes an ID server signature. In this way, the device authenticator’s signature associated with the identity document is attested to by the ID server 108.

[00102] It will be appreciated that other computations for securing the communication between the ID server, the mobile network operator, and the eSIM provider are applicable to the principles described herein.

[00103] Block 420: The eSIM provider server or the mobile network operator (or both) receives the attestation message, which includes and attests to the identity of the user. The eSIM provider server or the mobile network operator (or both) obtains data for generating an eSIM profile for the user. For example, this includes reserving an integrated circuit card identifier (ICCID) for the user device’s eUCCID. This ICCID forms part of the eSIM profile. This data for the eSIM profile, or the eSIM profile itself, is associated with the FIDO public key of the user’s DA, or identity document, or identity information, or a combination thereof. [00104] Block 421 : In an example aspect, the data for the eSIM profile includes an activation code. The eSIM provider server or the mobile network operator obtains and sends the activation code for a new eSIM profile. In another example aspect, the data for the eSIM profile also includes a data link for which the LPA can use to connect to the eSIM provider server or the mobile network operator, or both.

[00105] In an example aspect, the activation code and the data link are sent to the user device from the eSIM provider server or the mobile network operator. In another example aspect, this data is sent to the ID server, and the ID server sends this data to the user device.

[00106] Block 422: After receiving the activation code at the user device via WiFi, this activation code is inputted into the LPA.

[00107] Block 423: The user device connects to the cell network of the mobile network operator and sends an LPA request to download the profile package for the user’s eSIM profile.

[00108] In an example aspect, the request sent to the eSIM provider server includes the same session ID established between the ID server and the user device. Other types of data could be sent to by the user device to the eSIM provider server, so as to help the eSIM provider server to associate the request for eSIM provisioning of the user device with the attestation message sent by the ID server regarding the user’s identity and FIDO authentication.

[00109] Block 424: This request is received by the eSIM provider or the mobile network operator, or both, and is verified using the activation code.

[00110] Block 425: After verifying the request, the eSIM provider server or the mobile network operator returns an encrypted profile package (e.g., also called the IPP) to the user device. In an example aspect, this profile package is associated with the ICCID that was previously reserved for the user device’s eUCC.

[00111] Block 426: The LPA receives the encrypted profile package. In an example aspect, the eUICC downloads the encrypted profile package from the LPA and then decrypts the same. In an alternative example, the LPA decrypts the encrypted profile package and then transmits the profile package to the eUICC. The eUICC sends a success status to the LPA after the provisioning of the profile package is complete. At this point, a new operator profile (e.g., a new eSIM profile) is enabled using an enable profile procedure. For example, the LPA and the eUICC enable the new eSIM profile associated with the mobile network operator. [00112] Block 427: The LPA sends a success status to the eSIM provider server or the mobile network operator, or both.

[00113] Block 428: Going forward, the user device can connect to the mobile network operator using the eSIM profile stored within the eUICC.

[00114] In an example aspect, the user device communicates with the mobile network operator to perform FIDO authentication. For example, the user device sends a message signed by the user device DA’s FIDO private key. The mobile network operator verifies the signed message using the corresponding FIDO public key.

[00115] Turning to FIG. 5, an alternative example embodiment is provided for associating a FIDO credential with an existing eSIM profile. In the example embodiment of FIG. 5, the eSIM profile is provisioned first into the eUICC, and then the FIDO registration is executed.

[00116] Block 501 : A user, via user terminal or an in-store mobile network customer service agent, connects to an eSIM profile provider or a mobile network operator, or both, to conduct user authentication using software remote process or using in-person process. For example, a user provides their name, address, and photo identification to a mobile network customer service agent to perform a know-your-client (KYC) process. The user typically also provides payment. The user is then provided a QR code, or a link, or an activation code, or a combination thereof.

[00117] Block 502: The user’s new user device is presented with the QR code, or data link, or activation code, or combination thereof.

[00118] Block 503: The activation code is entered into the LPA of the user device.

[00119] Block 504: The LPA connects to the eSIM provider server to obtain the profile package, which is the software to provision the eUICC.

[00120] Block 505: After the LPA has downloaded the profile package, the eUICC downloads profile package from the LPA. The eUICC then enables eSIM profile. Associated with the eSIM profile is a MNO trusted ID. Examples of a MNO trusted ID include a mobile directory number (MDN), subscriber ID, and international mobile equipment identity (IMEI). Other IDs that are trusted by the MNO are applicable to the principles described herein. In an example embodiment, a combination of two or more different IDs (e.g., MDN, IMEI, etc.) can be used to form the MNO trusted ID.

[00121] It will be appreciated that other currently known and future known processes for provisioning a mobile device with an eSIM profile can be used. [00122] After the eSIM profile has been provisioned so that the user and their user device are considered a subscriber to the mobile network operator, FIDO registration is executed.

In an example aspect, the FIDO registration can take place at a later time (e.g., hours, weeks, etc.) after the eSIM profile has been provisioned.

[00123] Block 506: The user agent on the user device initiates FIDO registration.

[00124] Block 507: The user agent sends the MNO trusted ID to the ID server, and the ID server sends this information to the mobile network operator or the eSIM profile provider, or both, to verify the subscriber. After the mobile network operator or the eSIM profile provider verifies the subscriber, a challenge is sent to the user device.

[00125] Block 508: The user agent receives a challenge that includes the MNO trusted

ID. In an example aspect, the MNO trusted ID is the same MNO trusted ID that was provided or established at the time of provisioning the user device with the eSIM.

[00126] Block 509: The user agent prompts user authentication.

[00127] Block 510: In an example embodiment, the device authenticator obtains user input to authenticate the user. A FIDO authentication, for example, is used, which may use biometric authentication, a password, a pin, a swipe pattern, etc. in other words, alternatives to biometric authentication or biometric scanning can be used for FIDO authentication in an example embodiment, the device authenticator authenticates the user using a biometric scan, and signs and sends a challenge response via the user agent to the ID server. This challenge response, for example is signed using the FIDO private key stored on the device authenticator. The challenge response also includes, for example, the corresponding FIDO public key.

[00128] Block 511 : The user agent receives confirmation from the ID server and associates the FIDO credential with the eSIM identifier.

[00129] Turning to FIG. 6, more detailed example executable instructions are shown for implementing blocks 506 to 511. These instructions in FIG. 6 are executed after the eSIM profile has been provisioned on the user device.

[00130] In FIG. 6, the user agent is preferably a native application 103b, which includes a mobile network operator client application 601 interacting with an ID module 602. For example, the ID module 602 is implemented using a software development kit that is provided by the ID server 111.

[00131] Block 603: The user agent initiates FIDO registration. For example, the MNO client application 601 sends a message to the ID module 602 that there is an intent for FIDO registration. [00132] Block 604: The ID module sends a request to the ID server to request FIDO registration. The request, for example, includes the MNO trusted ID.

[00133] Block 605: The ID server executes a network level verification with the mobile network operator. For example, the ID server sends a request to the mobile network operator for network level verification of the user device, and the request includes the MNO trusted ID.

[00134] Block 606: The mobile network operator ensures the user device information is a subscriber to its mobile network and verifies the MNO trusted ID. After successfully verifying the subscriber, the mobile network operator sends a confirmation message to the ID server indicating the same.

[00135] Block 607: The ID server constructs a challenge using the MNO trusted ID and sends the challenge to the user device. More particularly, the challenge is received by the user agent.

[00136] Block 608: The user agent, in combination with the device authenticator, prompts authentication from the user. For example, a GUI of the user agent request user input (e.g., biometric scanning, a code, a password, a pin, etc.) to execute authentication.

[00137] Block 609: In a preferred example embodiment, the user device scans the user biometrics. For example, this includes scanning a thumbprint or scanning some other biometric feature of the user (e.g., a facial scan).

[00138] In another example embodiment, a GUI is displayed that facilitates a user to input a code, a pin number, a swipe pattern, or a password. The input is used to authenticate the user.

[00139] Block 610: After the authentication has been successfully completed, the device authenticator signs a challenge response using a FIDO credential. In particular, the FIDO private key stored on the device authenticator is used to sign the challenge response. In an example aspect, an existing FIDO credential (e.g., including public and private key pair) is uniquely associated with the mobile network operator and the user’s SIM profile. In another example, a new FIDO credential is created that is specifically and uniquely associated with the mobile network operator and the user’s SIM profile. More generally, the particular FIDO credential is dedicated and associated to the mobile network operator and the user’s SIM profile. In an example aspect, the corresponding FIDO public key of the FIDO credential is included in the challenge response and sent to the ID server.

[00140] Block 611 : The user agent (e.g., the ID module) passes the signed challenge response to the ID server. [00141] Block 612: The ID server verifies the challenge response and stores the FIDO public key.

[00142] Block 613: The ID server sends confirmation of the successful verification to the user agent.

[00143] It will be appreciated that the stored FIDO public key is associated with the MNO trusted ID. In an example aspect, the creation of the FIDO credential is tied to the MNO trusted ID

[00144] In an example aspect, the FIDO public key is also transmitted to the mobile network operator and stored by the mobile network operator in association with the MNO trusted ID.

[00145] It will be appreciated that there are different ways to bind eSIM profile and FIDO credentials. The binding or associating of the eSIM profile and FIDO credentials helps ensure that the eSIM profile is authentic. It also helps facilitate the eSIM profile to be used for executing future actions.

[00146] In an example embodiment, after the eSIM profile and the FIDO credential (e.g., FIDO identity) are associated with each other, then the mobile network operator and the user device can execute actions with strong identity authentication (e.g., FIDO authentication).

[00147] Turning to FIG. 7, example executable instructions are shown for executing an action after the eSIM profile and FIDO credential are associated with each other.

[00148] Block 701 : At least one of a third-party server 113 and the user device initiate an action request. For example, the third-party server is a service provider, or a retailer, or some other company. The action, for example, includes obtaining information, executing a transaction, executing a transfer, executing a download, executing an upload, executing a signature, generating new data, sending a message, controlling another device, etc.

[00149] The action request is transmitted to the mobile network operator, and the mobile network operator transmits the request to the ID server. In an alternative embodiment, the action request is transmitted directly to the ID server.

[00150] Block 702: The ID server constructs a FIDO challenge and sends this challenge to the user device. In an example aspect, the FIDO challenge includes one or more of: user data, user device data, mobile network operator data, and data about the requested action. For example, data about the requested action includes the name of the third-party (e.g., the company that is providing a product or service to the user), or a description of the action, or a combination thereof. [00151] Block 703: The user device receives the FIDO challenge and initiates FIDO authentication through a native app or a browser. The user device receives FIDO user authentication, or more generally, FIDO authentication. In an example aspect, the FIDO authentication includes biometric authentication, which includes, for example, a biometric scan of the user, or some other interaction with the user via the user device.

[00152] Block 704: After the FIDO authentication is successfully completed, the user device transmits the FIDO authentication and user device data to the mobile network operator, or a related login service, or both. For example, this includes data that is signed by the FIDO private key and the user device identity information. For example, the user device identity information includes eSIM identity data. In an example aspect, the user device identity information includes the MNO trusted ID. It will be appreciated that FIDO authentication data includes a FIDO challenge response.

[00153] Block 705: In an example embodiment, the FIDO authentication data is transmitted via the mobile network operator and then to the ID server in another example embodiment, at biock 705, the mobile network operator, or the related login service, or both, authenticates the user device data. For example, the mobile network verifies the MNO trusted ID. If the data is authenticated, then the FIDO authentication data is sent to the ID server.

[00154] Block 706: The ID server verifies the FIDO authentication data and sends confirmation of the verification to the mobile network operator or the related login service, or both. In an example aspect, the ID server uses the corresponding FIDO public key to verify the signed FIDO authentication data from the user device.

[00155] In an alternative example embodiment, the user device sends the FIDO authentication data and user device data directly to the ID server.

[00156] Block 707: The mobile network operator or the related login service, or both, provides attestation of authentication to the user device or to the third-party server, or both.

In an example aspect, the attestation includes user data or eSIM profile data (e.g., the phone number).

[00157] Block 708: The user device receives data to execute the desired action (e.g., login, transaction, access to data, etc.).

[00158] Block 709: in addition or in alternative, the third party server receives data to execute desired action.

[00159] Block 710: The third-party server or the user device, or both, execute the action. [00160] In an example aspect, the action is used to make a payment or a transaction from the user’s mobile network account. For example, the user pays a monthly fee to the mobile network in association with a mobile network account tied to their eSIM profile. A transaction to a third party can be charged to the mobile network account. In this way, the payment is verified by the mobile network operator, and the user can settle payment directly with the mobile network operator, which is a trusted entity.

[00161] In another example aspect, the action is used for passport verification and entry at border crossings or other security checkpoints. The action associates the user’s eSIM profile and strong identity together.

[00162] FIGs. 8A to 8K show example GUIs that generally correspond to the embodiments described in FIG. 3 and FIGs. 4A and 4B.

[00163] In FIG. 8A, an application on the user device (e.g., the user agent) requests the user to enter in their username. In FIG. 8B, the user is prompted to register their FIDO account as part of the process to register their eSIM profile. In FIG. 8C, the user is prompted to authenticate their identity. For example, the GUI display the button “authenticate” or some other button or action and, after the user selects the button, a scanning process is initiated, such as a thumbprint scan, a face scan, an RFID scan, etc. In other words, the scanner is used to scan the person or something as part of the FIDO authentication process.

[00164] After the FIDO authentication is successful, in FIG. 8D, the GUI shows an indication message showing the same.

[00165] The GUI, in FIG. 8E, then shows a message to the user to scan their photolD (e.g. a type of identity document) to register the user’s identity. For example, the photo ID is a driver’s license, a passport, etc. The GUI then receives an input on the “scan now” button.

[00166] The GUI, in FIG. 8F, then activates a camera on the user device to take a picture of the photolD. For example, the rear camera is activated and the user positions their user device to have the driver license in the camera’s field of view. The user device then captures a picture of the driver license (e.g., the scanned image of the identity document).

[00167] The GUI, in FIG. 8G, then shows a cropped photo of the user’s face that is extracted from the driver license. The GUI in FIG. 8G also shows other extracted information, such as name, serial number and address. For example, this information is extracted by executing optical character recognition on the image of the driver license. If the user selects the “rescan” button, then the camera is reactivated and the GUI in FIG. 8F is shown. If the user selects the “next” button, the GUI in FIG. 8H is shown. [00168] In FIG. 8H, the camera is activated on the user device to take a selfie of the user. For example, the front facing camera is activated and a picture of the user’s face is captured. The picture of the user’s face (e.g. the selfie) and the cropped photo from the driver license are compared. If they match, the process proceeds to the GUI in FIG. 8I.

[00169] In FIG. 8I, the message on the GUI shows that the identity verification is complete and that the user agent is now getting the eSIM profile. This includes downloading the profile package from the eSIM provider server or the mobile network operator, or both, and obtaining the activation code. The user agent initiates and waits for the LPA or the eUICC, or both, to confirm that the eSIM profile has been installed and enabled on the eUICC.

[00170] In FIG. 8J, in an example aspect, the GUI shows a button that includes a data link to complete the eSIM provisioning, and the GUI displays the activation code to be inputted into the LPA. It will be appreciated that other user experience flows can be used to complete the eSIM provisioning.

[00171] In FIG. 8K, the GUI shows a message from the mobile network operator, indicating that the eSIM profile and FIDO registration have been completed. The user can choose to logout of the user agent.

[00172] It is also further herein recognized that after a user device has its eSIM profile provisioned and bound to a FIDO identity and FIDO authentication, the user device can be used to help provision eSIM profiles for other devices that are linked to the same user. For example, a user has a first user device 100 that has been provisioned with an eSIM profile and that is linked to strong identity and strong authentication. This has been achieved using the devices and processes described above, including, for example, document verification. The same user wishes to provision a second device (e.g., an loT device or another user mobile device) with a second eSIM profile, which is to be linked with the user’s identity. The same user, however, does not want to or cannot execute document verification using the second device. For example, the second device lacks a scanner (e.g., a camera) and a device authenticator, and so cannot facilitate document verification. Furthermore, establishing strong identity again would be time consuming. Therefore, it is herein recognized that it is desirable to link the user’s strong identity, which has already been established by the MNO 110 and the ID server 111, with the second eSIM profile of the second device.

[00173] Turning to FIG. 9, the user 101 has already provisioned its first user device 100 with a first eSIM profile and has bound it to its user identity, using the document verification process provided above. The user 101 wishes to provision its second device 900 with a second eSIM profile, and have it linked it the user’s identity stored on the MNO 110. The second device 900, for example, is an loT device. The second device’s hardware 102 includes a communications module for communicating over the cell network to the MNO, a processor, and memory. In some embodiments, the hardware 102 also includes a display. The second device also includes an eUICC 107 and LPA 108. Optionally, the second device also includes a user agent 104. In other example embodiments, the second device does not include a user agent. Examples of loT devices include smart cameras, smart home appliances (e.g., refrigerator, home security device, robotic vacuum, washing machine, light controller, HVAC controller, etc.), network devices, machinery, factory equipment, industrial devices, water and wastewater devices, hospital equipment, farming equipment, etc. One or more of these loT devices can have its eSIM provisioned and bound to the user’s strong identity.

[00174] FIG. 10 shows example executable instructions for provisioning the second device with a second eSIM profile and linking the second eSIM profile to the established user identity at the MNO 110.

[00175] Blocks 1001 , 1002, 1003 and 1004 are initial conditions for executing the process in FIG. 10. At the first user device 100, it has already been provisioned with a first eSIM profile that is stored in the first user device’s eUICC, and the first user device connectable to MNO (block 1001 ). At the eSIM provider server 109 or the MNO 110, it stores thereon data for the first eSIM profile, which is associated with FIDO public key of user’s DA of the first user device and the user identity (e.g., a unique ID reference, or identity document, or identity information, or a combination thereof) (block 1002). At the ID server 111 , it stores thereon the verified user identity (e.g., unique ID reference, or identity document, or identity information, or a combination thereof) associated with a FIDO public key of user’s DA for the first user device (block 1003). At the second device 900, the eUICC is ready to be provisioned.

[00176] Continuing with FIG. 10, the operations include creating a trusted sessions (block 1005) and then proceeding with provision the second device with its own eSIM profile (e.g., herein also called the second eSIM profile) (block 1006).

[00177] Different executable processes can be used to create a trusted data communication session (block 1005). In an example embodiment of establishing a trusted data communication session, at block 1007, the first user device authenticates the user and transmits a request for an identity token to the ID server 111 (block 1008). For example, the first user device uses biometric scan or another type of authentication (e.g., passcode, pin code, swipe pattern, etc.) to authenticate the user. For example, the authentication is a FIDO authentication that can be verified by the ID server 111. In another example aspect, the first user device only requests the identity token if the authentication has been successful. At block 1009 the ID server 111 authenticates the request from the user device and, if verified, returns an identity token to the first user device. At block 1008 the first user device contacts the eSIM provider or MNO and provides the same with the identity token. At block 1010, the eSIM provider or MNO authenticates the identity token with the ID server. After authentication, a session ID is created. The operations for provisioning the second device are associated with the session ID.

[00178] After the trusted session has been established, the first user device 100 transmits a second device ID of the second device 900 to the eSIM provider server or MNO, or both (block 1011). In an example embodiment, the second device ID is one or more of a mobile directory number (MDN), subscriber ID, and international mobile equipment identity (IMEI). The user can obtain the second device ID in different ways. For example, the second device ID is labelled on the second device. In another example, the second device ID is obtained by scanning a barcode or QR code on or associated with the second device.

In another example, the second device ID is provided by the seller or company that is selling or offering the second device to the user.

[00179] At block 1012, the eSIM provider server or the MNO, or both, sends a profile package (e.g., IPP) to the second device using the second device ID. The profile package includes the second eSIM profile. At block 1013, the LPA of the second device downloads the profile package to the eUICC. The eUICC is then provisioned with the second eSIM profile. At this point, a new operator profile, which is the second eSIM profile, is enabled on the eUICC of the second device using an enable profile procedure. For example, the LPA and the eUICC enable the new eSIM profile associated with the mobile network operator.

[00180] At block 1014, the LPA sends a success status to the eSIM provider server or the MNO, or both. At block 1015, the second device connects to the MNO 110 using the second eSIM profile.

[00181] At block 1016, the eSIM provider server or the MNO, or both, stores the second eSIM profile in association with the same user identity that is associated with the first eSIM profile. It will also be appreciated that the eSIM provider server or the MNO, or both, also stores the FIDO public key associated with the first eSIM profile.

[00182] In an example embodiment, the eSIM provider server or the MNO, or both, sends the second device ID to the ID server 111 At block 1017 the ID server 111 stores the user identity (e.g., user identity reference, or user identity information, or user identity document, etc.), the FIDO public key of the first user device, the first user device ID, and the second device ID in association with each other.

[00183] In an example aspect, the eSIM provider server or the MNO, or both, transmits a status of the completed provisioning to the first user device (block 1018). For example, this completed status is displayed on the display device (using the user agent) on the first user device 100.

[00184] In an example aspect, the above executed operations are associated with a session ID established at block 1005. In another example embodiment, after the provisioning the second device, then the trusted data communication session is terminated. This includes, for example, terminating the session ID.

[00185] Using the above operations, one or more second devices, such as loT devices, can be provisioned and connected to the MNO in a secure manner, while being linked to the same strong user identity and authentication that is trusted by the MNO. This increases the level of data trust associated with the second device.

[00186] Another example schematic is shown in FIG. 11 , which is similar to the schematic in FIG. 9. In FIG. 11 , a first user device 100, which is already provisioned with a first eSIM profile, is used to facilitate provisioning a third device 1100 with a new eSIM profile (also herein called a third eSIM profile). The third device 1100 includes a device authenticator 105 and, optionally, a scanner 106 (e.g., one or more of the scanners 106a,

106b, 106c, 106d). In other words, the third device can be another user mobile device, such as a laptop, a tablet, a smart phone, a car or other automobile, or the like.

[00187] FIGs. 12a and 12b are example executable instructions for provisioning the third device 1100, which includes a device authenticator 105. The initial conditions 1001, 1002, 1003, 1004 are similar as noted above with respect to FIG. 10.

[00188] As shown in FIG. 12a, the process for the initiating a trusted data communication session (block 1005) is also executed. This followed by provisioning the third device with the third eSIM profile (block 1200) and executing FIDO registration (block

1201) on the third device. In another example embodiment, operations of block 1201 occur before the operations of block 1200.

[00189] In the provisioning operations (block 1200), the first user device transmits the third device ID of the third device to the eSIM provider server or the MNO, or both (block

1202). In an example embodiment, the third device ID is one or more of a mobile directory number (MDN), subscriber ID, and international mobile equipment identity (IMEI), which can be obtained in one or more different ways. [00190] At block 1203, the eSIM provider server or the MNO, or both, sends a profile package (e.g., an IPP), which includes the third eSIM profile, to the third device. The third device is identified over the network using the third device ID.

[00191] The third device 1100 receives the profile package and, at block 1204, the LPA downloads the profile package to the eUICC within the third device. The eUICC enables the third eSIM profile, thereby provisioning the third device with the third eSIM profile.

[00192] At block 1205, the LPA sends the success status to the eSIM provider server or the MNO, or both. The third device connects to the MNO using the third eSIM profile (block 1206).

[00193] Either before or after provisioning the third eSIM profile, associated with the same session is the FIDO registration of the third device. At block 1207, the eSIM provider server or the MNO, or both, initates FIDO registration of the third device. For example, the eSIM provider server or the MNO, or both, sends the third device ID of the third device to the ID server. At block 1208, the ID server creates and sends a challenge to the third device.

At block 1209, the device authenticator of the third device creates a new FIDO public key and new FIDO private key pair that is associated with the user account of the third device.

At block 1210, the device authenticator authenticates the user and signs a challenge using the FIDO private key, and sends a challenge response. The challenge includes the signed challenge and the FIDO public key of the third device.

[00194] At block 1211, the I D server verifies the signed challenge response and stores the FIDO public key of the user’s device authenticator corresponding to the third device. At block 1212, the user identity is associated with the FIDO public key. At block 1213, the ID server generates and sends an attestation message to the eSIM provider server or MNO, or both, that the FIDO registration for the third device is complete. The message includes the FIDO public key.

[00195] At block 1214, the ID server stores the user identity, the FIDO public key of the first user device, the first user device ID, the FIDO public key of the third user device and the third user device ID in association with each other. This same information is also stored at the eSIM provider server or the MNO, or both, and further in associations with the third eSIM profile and the first eSIM profile.

[00196] In other words, the third eSIM profile is bound to the same user identity associated with the first eSIM profile.

[00197] Using the above operations, one or more third devices that include their own data authenticators, can be provisioned and connected to the MNO in a secure manner, while being linked to the same strong user identity and authentication that is trusted by the MNO. This reduces the number of executable operations, including avoiding the identity document verification operations, while still establishing the same level as trust as the first user device.

[00198] Below are general example embodiments and example aspects.

[00199] In an example embodiment, a user device is provided. The user device includes: a camera system, a processor, a first communication module, a second communication module, memory, a display, and an embedded Universal Integrated Circuit Card (eUICC). The processor receives and executes instructions to at least: initiate a strong authentication of the user over a first communication module; activate the camera system to capture a scanned image of an identity document that includes a photo of a user; activate the camera system to capture a picture of a face of the user; initiate an image comparison of the photo of the user from the scanned image of the identity document with the captured picture of the face of the user; transmit, via the first communication module, verification data associated with the identity document and strong authentication data; initiate provisioning of the eUICC, including obtaining a link via the first communication module; initiate communication with the link via the second communication module to download an eSIM profile; and enable the eSIM profile on the eUICC to connect to a mobile network operator.

[00200] In an example aspect, the first communication module facilitates WiFi communication, and the second communication module facilitates wireless cellular network communication.

[00201] In another example aspect, the user device associates the eSIM profile with the identity document, or the strong authentication data, or both.

[00202] In another example aspect, the user device further includes a device authenticator, and the device authenticator executes instructions to at least create a public key associated with a user account and a corresponding private key, wherein the user account is associated with data derived from the identity document, the private key is stored in the device authenticator and the public key is shared with the ID server and used to subsequently verify authentications.

[00203] In another example aspect, the user device further includes a biometric scanner, wherein the strong authentication comprises receiving biometric data from the user.

[00204] In another example aspect, the strong authentication is FIDO authentication, and wherein the public key is a FIDO public key and the private key is a FIDO private key. [00205] In another example aspect, the processor further executes instructions to at least crop the photo of the user from the scanned image of the identity document.

[00206] In another example aspect, the processor further executes instructions to at least extract text data or numeric data, or both, from the scanned image of the identity document using optical character recognition or Near Field Communication (NFC), and the extracted text data or numeric data, or both, is part of the verification data associated with the identity document.

[00207] In another example aspect, the camera system comprises a front camera and a rear camera, and the processor activates the rear camera to capture the scanned image of the identity document, and processor activates the front camera to capture the picture of the face of the user.

[00208] In another example aspect, the processor further executes instructions to at least: initiate an action with a third-party server; initiate a strong authentication process that includes transmitting data comprising or derived from the strong authentication data and the eSIM profile to the mobile network operator; and receive data from the mobile network operator to execute the action with the third party server.

[00209] In another example embodiment, a system is provided, which includes a user device, an eSIM provider server, and an ID server. The user device includes a WiFi communication module to conduct strong user authentication and verification of an identity document verification of a user with the ID server. The eSIM provider server is configured to receive an attestation message originating from the ID server that the user has been authenticated and the identity document has been verified. The user device further includes a cellular network communication module to download an eSIM profile package from the eSIM provider server, and install the eSIM profile package into an embedded Universal Integrated Circuit Card (eUICC) on the user device. The eSIM provider server includes memory to store an eSIM profile of the user device in association with at least one of the identity document and data from the strong user authentication.

[00210] In an example aspect of the system, responsive to the eSIM provider server receiving the attestation message, the eSIM provider server is configured to send an activation code associated with the eSIM profile package to the user device.

[00211] In another example aspect of the system, the user device further comprises a device authenticator, and the device authenticator executes instructions to at least create a public key associated with a user account and a corresponding private key, wherein the user account is associated with data derived from the identity document, the private key is stored in the device authenticator and the public key is shared with the ID server and used to verify subsequent authentications.

[00212] In another example aspect of the system, the strong user authentication is FIDO authentication, and wherein the public key is a FIDO public key and the private key is a FIDO private key.

[00213] In another example aspect of the system, the user device further comprises a biometric scanner, and wherein the strong user authentication comprises receiving biometric data from the user using the biometric scanner.

[00214] In another example aspect of the system, the user device further comprises a camera system configured capture a scanned image of the identity document that includes a photo of the user; the user device is configured to activate the camera system to capture a picture of a face of the user; and the scanned image of the identity document and the picture of the face of the user are transmittable to the ID server via the WiFi communication module.

[00215] In another example aspect of the system, the ID server is configured to compare the picture of the face of the user to the photo of the user in the identity document, to verify the identity document.

[00216] In another example aspect of the system, the system further includes a mobile network operator, wherein the eSIM profile enables the user device to communicate via the cellular network communication module using a service provided by the mobile network operator.

[00217] In another example aspect of the system, the system further includes a third party server. After the user device completes the strong user authentication with intent to execute a desired action, the mobile network operator transmits data to the third party server to execute the desired action.

[00218] In another example aspect of the system, the system further includes a second device comprising a second eUICC, a second device ID, and a second cellular network communication module that is configured to download a second eSIM profile package from the eSIM provider server, and the second device further configured to install the second eSIM profile package into the second eUICC. Furthermore, the memory of the eSIM provider server is further configured to store the second eSIM profile of the second device in association with at least one of the eSIM profile of the user device, the identity document, and the data from the strong user authentication executed with the user device.

[00219] In another example embodiment, a system is provided that includes: a user device, an ID server, and a MNO server, wherein the user device is subscribed to the MNO and identifiable using a MNO trusted ID. The user device in includes a user agent and a hardware-based device authenticator, and the user agent configured to transmit a request to the ID server to initiate FIDO registration, the request comprising the MNO trusted ID. The ID server includes a communication module to communicate with the MNO server to conduct a network level verification of the user device, wherein the MNO server verifies the MNO trusted ID. The ID server further includes a processor to construct a challenge using the MNO trusted ID and the ID server configured to use the communication module to transmit the challenge to the user agent of the user device. The user agent of the user device comprises a GUI to prompt user authentication. The user agent is also configured to initiate scanning a biometric user feature and communicate with the hardware-based device authenticator to generate a challenge response signed using a FIDO private key stored in the hardware-based device authenticator, wherein the challenge response is verifiable using a FIDO public key that corresponds to the FIDO private key. At least one of the ID server and the MNO server store the FIDO public key in association with the MNO trusted ID.

[00220] It will be appreciated that any module or component exemplified herein that executes instructions may include or otherwise have access to non-transitory computer readable media such as storage media, computer storage media, or data storage devices (removable and/or non-removable) such as, for example, memory chips, magnetic disks, optical disks. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, code, processor executable instructions, data structures, program modules, or other data. Examples of computer storage media include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), read-only memory (ROM), solid-state ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, or any other medium which can be used to store the desired information and which can be accessed by an application, module, or both. Any such computer storage media may be part of the servers or computing devices, or accessible or connectable thereto. Any application or module herein described may be implemented using computer readable/executable instructions that may be stored or otherwise held by such computer readable media.

[00221] It will be appreciated that different features of the example embodiments of the system and methods, as described herein, may be combined with each other in different ways. In other words, different devices, modules, operations, functionality and components may be used together according to other example embodiments, although not specifically stated. [00222] The steps or operations in the flow diagrams described herein are just for example. There may be many variations to these steps or operations according to the principles described herein. For instance, the steps may be performed in a differing order, or steps may be added, deleted, or modified.

[00223] The elements and screenshots of the GUIs shown herein are just for example. There may be many variations to these GUI elements or operations according to the principles described herein. For instance, the GUI elements and operations may be performed in a differing order, or GUI elements or operations may be added, deleted, or modified.

[00224] It will also be appreciated that the examples and corresponding system diagrams used herein are for illustrative purposes only. Different configurations and terminology can be used without departing from the principles expressed herein. For instance, components and modules can be added, deleted, modified, or arranged with differing connections without departing from these principles.

[00225] Although the above has been described with reference to certain specific embodiments, various modifications thereof will be apparent to those skilled in the art without departing from the scope of the claims appended hereto.

Claims

Claims:

1. A user device comprising: a camera system, a processor, a first communication module, a second communication module, a memory, a display, and an embedded Universal Integrated Circuit Card (eUICC); and the processor configured to execute instructions to at least: initiate a strong authentication of the user over a first communication module; activate the camera system to capture a scanned image of an identity document that includes a photo of a user; activate the camera system to capture a picture of a face of the user; initiate an image comparison of the photo of the user from the scanned image of the identity document with the captured picture of the face of the user; transmit, via the first communication module, verification data associated with the identity document and strong authentication data; initiate provisioning of the eUICC, including obtaining a link via the first communication module; initiate communication with the link via the second communication module to download an eSIM profile; and enable the eSIM profile on the eUICC to connect to a mobile network operator using the second communication module.

2. The user device of claim 1 wherein the first communication module facilitates WiFi communication and the second communication module facilitates wireless cellular network communication.

3. The user device of claim 1 wherein the user device associates the eSIM profile with at least one of the identity document and the strong authentication data.

4. The user device of claim 1 further comprising a device authenticator, and the device authenticator executes instructions to at least create a public key associated with a user account and a corresponding private key, wherein the user account is associated with data derived from the identity document, the private key is stored in the device authenticator.

5. The user device of claim 1 further comprising a biometric scanner, wherein the strong authentication comprises receiving biometric data from the user.

6. The user device of claim 1 wherein the strong authentication is Fast Identity Online (FIDO) authentication, and wherein the public key is a FIDO public key and the private key is a FIDO private key.

7. The user device of claim 1 , wherein the processor further executes instructions to at least crop the photo of the user from the scanned image of the identity document.

8. The user device of claim 1 , wherein the processor further executes instructions to at least extract text data or numeric data, or both, from the scanned image of the identity document using optical character recognition or Near Field Communication (NFC), and the extracted text data or numeric data, or both, is part of the verification data associated with the identity document.

9. The user device of claim 1 wherein the camera system comprises a front camera and a rear camera, and the processor activates the rear camera to capture the scanned image of the identity document, and processor activates the front camera to capture the picture of the face of the user.

10. The user device of claim 1 wherein the processor further executes instructions to at least: initiate an action with a third party server; initiate a strong authentication process that includes transmitting data comprising or derived from the strong authentication data and the eSIM profile to the mobile network operator; and receive data from the mobile network operator to execute the action with the third party server.

11. A system comprising: a user device, an eSIM provider server, and an ID server; the user device comprising a WiFi communication module to conduct a strong user authentication and a verification of an identity document of a user with the ID server; the eSIM provider server configured to receive an attestation message originating from the ID server that the user has been authenticated and the identity document has been verified; the user device further comprising a cellular network communication module to download an eSIM profile package from the eSIM provider server, and install the eSIM profile package into an embedded Universal Integrated Circuit Card (eUICC) on the user device; and the eSIM provider server comprising memory to store an eSIM profile of the user device in association with at least one of the identity document and data from the strong user authentication.

12. The system of claim 11 wherein, responsive to the eSIM provider server receiving the attestation message, the eSIM provider server is configured to send an activation code associated with the eSIM profile package to the user device.

13. The system of claim 11 wherein the user device further comprises a device authenticator, and the device authenticator executes instructions to at least create a public key associated with a user account and a corresponding private key, wherein the user account is associated with data derived from the identity document, the private key is stored in the device authenticator and the public key is part of the data from the strong user authentication.

14. The system of claim 13 wherein the strong user authentication is Fast Identity Online (FIDO) authentication, and wherein the public key is a FIDO public key and the private key is a FIDO private key.

15. The system of claim 11 wherein the user device further comprises a biometric scanner, and wherein the strong user authentication comprises receiving biometric data from the user using the biometric scanner.

16. The system of claim 11 wherein the user device further comprises a camera system configured capture a scanned image of the identity document that includes a photo of the user; the user device is configured to activate the camera system to capture a picture of a face of the user; and the scanned image of the identity document and the picture of the face of the user are transmittable to the ID server via the WiFi communication module.

17. The system of claim 16 wherein the ID server is configured to compare the picture of the face of the user to the photo of the user in the identity document, to verify the identity document.

18. The system of claim 11 further comprising a mobile network operator, wherein the eSIM profile enables the user device to communicate via the cellular network communication module using a service provided by the mobile network operator.

19. The system of claim 18 further comprising a third party server and, after the user device completes the strong user authentication with intent to execute a desired action, the mobile network operator transmits data to the third party server to execute the desired action.

20. The system of claim 11 further comprising a second device comprising a second eUICC, a second device ID, and a second cellular network communication module that is configured to download a second eSIM profile package from the eSIM provider server, and the second device further configured to install the second eSIM profile package into the second eUICC; and the memory of the eSIM provider server further configured to store the second eSIM profile of the second device in association with at least one of the eSIM profile of the user device, the identity document, and the data from the strong user authentication executed with the user device.

21. A system comprising: a user device, an ID server, and a mobile network operator (MNO) server, wherein the user device is subscribed to the MNO and identifiable using a MNO trusted ID; the user device comprising a user agent and a hardware-based device authenticator, and the user agent configured to transmit a request to the ID server to initiate Fast Identity Online (FIDO) registration, the request comprising the MNO trusted ID; the ID server comprising a communication module to communicate with the MNO server to conduct a network level verification of the user device, wherein the MNO server verifies the MNO trusted ID, and the ID server further comprising a processor to construct a challenge using the MNO trusted ID and the ID server configured to use the communication module to transmit the challenge to the user agent of the user device; the user agent of the user device configured to prompt user authentication, initiate scanning a biometric user feature, and communicate with the hardware-based device authenticator to generate a challenge response signed using a FIDO private key stored in the hardware- based device authenticator, wherein the challenge response is verifiable using a FIDO public key that corresponds to the FIDO private key; and at least one of the ID server and the MNO server store the FIDO public key in association with the MNO trusted ID.