Controlled access to geolocation data in open roaming federation

Abstract

Embodiments herein register asset owners (AOs) and AO applications with a location, aggregation, and insight (LAI) service as part of the same identity federation. When an AO is registered with the LAI service, the AO selects which of a plurality of identity providers (IDPs) it has a relationship with, and then the LAI service can bind those IDPs to the AO application. This binding associates various realms (e.g., domains) corresponding to the selected IDPs to the AO application. Later, when a device owned by the AO roams to a visited network (VN), the LAI service can then use the realm identified from a device ID provided by the device to identify an ID of the AO application. The LAI service then enables the VN to send the location of the device to the AO application. In one embodiment, the VN obtains consent from the AO before sharing location data.

Description

TECHNICAL FIELD

[0001] Embodiments presented in this disclosure relate generally to exchanging location data between domains within identity federation. BACKGROUND

[0002] Given the supply chain that extends across borders and different internet service providers, there is an increasing need to track goods in ports, warehouses, supply chains, and other parts where location data must be accessible to both Asset Owners (AOs) and operators handling the goods, whether in transit or at their final destination. To track a good or package, an AO can attach a wireless device that can communicate with a wireless network such as a Wi-Fi network, a LoRa network, or a cellular network. However, the AO can not operate the wireless network and instead rely on a third-party provider to manage the identity, authentication, and lifecycle of its wireless devices for tracking goods. The AO must rely on a visited network (e.g., a wireless network provided by a sea port, an airport, or a cellular network) to communicate with the wireless device, identify its location, and push these locations to the AO.

[0003] Currently, there is no way to securely provide location data to the AO unless the visited network and the AO have established an agreement or use a common application. The visited network can use hyper-location in Wi-Fi, multilateration in cellular, TDOA / RSSI in LoRa, UWB-based mechanisms, or a combination thereof to identify the location of the AO’s device; however, this data cannot be accessed by a third party (e.g., the AO). Building an ad hoc solution for sharing location data between the visited network and the AO is affected by both scalability and trust issues, as its devices (e.g., tags) can connect to networks in many different ports, warehouses, and countries and the number and variety of AOs that transit through the network (e.g., roam) can be very large. Moreover, privacy requirements dictate that identity and location data should be shared only between entities that have agreed to specific terms and conditions, limiting the scope and extent of such data exchange. Without a solution, the AO often loses track of its devices (and the corresponding goods) when moving from outdoors to indoors (e.g., within a warehouse) or when roaming costs become prohibitive. BRIEF DESCRIPTION OF DRAWINGS

[0004] In order for the above-described features of the present disclosure to be understood in detail, a more particular description of the disclosure, some of which is illustrated in the accompanying drawings, will be rendered by reference to embodiments. It is appreciated that the drawings illustrate typical embodiments and are therefore not to be considered limiting; other equally effective embodiments are contemplated.

[0005] Figure 1 FIGURE illustrates a location sharing system using identity federation, according to one embodiment described herein.

[0006] Figure 2 is a flow diagram for binding an AO application to an identity provider (IDP) in a location, aggregation, and insight (LAI) service, according to one embodiment described herein.

[0007] Figure 3 is a table for binding an AO application to an identity provider, according to one embodiment described herein.

[0008] Figure 4 is a table for binding an AO application to an identity provider, according to one embodiment described herein.

[0009] Figure 5 FIGURE illustrates a LAI service communicating with an identity provider and an AO application, according to one embodiment described herein.

[0010] Figure 6 is a flow diagram for enabling a visited network to share location data with an AO application, according to one embodiment described herein.

[0011] Figure 7 FIGURE illustrates a system for enabling a visited network to share location data with an AO application, according to one embodiment described herein.

[0012] Figure 8 is a flow diagram for obtaining consent to share location data, according to one embodiment described herein.

[0013] For the sake of brevity, common elements of the figures have not been renumbered in each figure. It is contemplated that elements disclosed in one embodiment can be beneficially utilized in other embodiments without specific recitation. DETAILED DESCRIPTION

[0014] SUMMARY

[0015] One embodiment presented in the disclosure is a method that includes registering a plurality of identity providers (IDPs) with a location, aggregation, and insights (LAI) service, where the LAI service, the plurality of IDPs, and an asset owner (AO) are part of an identity federation. The method also includes registering the AO with the LAI service, where registering the AO includes selecting one or more of the IDPs that have been registered with the LAI service and binding the selected IDPs to an AO application of the AO in the LAI service, where the selected IDPs and the AO application have common respective domains. After detecting that a device has roamed to a visited network (VN) in the identity federation, the method includes receiving, at the LAI service from the VN, a domain associated with the device. The method also includes identifying, at the LAI service, the AO application by matching the received domain to one of the respective domains, and enabling the VN to push location information corresponding to the device to the AO application.

[0016] Other embodiments include a computing system and a non-transitory computer- readable medium having program instructions for performing operations that include registering a plurality of IDPs with a LAI service, where the LAI service, the plurality of IDPs, and an AO are part of an identity federation, and registering the AO with the LAI service, where registering the AO includes selecting one or more of the IDPs that have been registered with the LAI service. The method also includes binding the selected IDPs to an AO application of the AO in the LAI service, where the selected IDPs and the AO application have common respective domains, and after detecting that a device has roamed to a VN in the identity federation, receiving, at the LAI service from the VN, a domain associated with the device. The operations include identifying, at the LAI service, the AO application by matching the received domain to one of the respective domains, and enabling the VN to push location information corresponding to the device to the AO application.

[0017] Example Embodiments

[0018] Embodiments herein register an AO and an AO application to a location, aggregation, and insights (LAI) service, both of which are part of the same open roaming federation (or more generally, an identity federation). Gaining access to positioning data is in the interest of both the AO and the enterprise that owns the visited network (VN). Thus, new techniques are needed that allow the VN owner to dynamically discover the AO and share location data with the AO in a controlled, trustworthy, and consented manner, regardless of the access technology used. This is particularly relevant in open roaming scenarios, where the VN relies on dynamically establishing trust not only with an identity provider (IDP) during an authentication phase, but also with the AO.

[0019] A plurality of IDPs (which can be AOs, or separate third party services) are registered to the LAI service. When an AO is registered to the LAI service, the AO selects which of the plurality of IDPs it uses (e.g., has a contract with), and then the LAI service can bind those IDPs to the AO using digital certificates. This binding associates the respective domains (e.g., domains) corresponding to the selected IDPs to the AO application. This binding is stored in the LAI service as a table that links the domains owned by the selected IDPs to the ID of the AO application. Later, when a device owned by the AO roams to a VN (e.g., a network not controlled by the AO or its IDPs), the LAI service can use the table to match the domain associated with the device to one of the domains of the registered IDPs. The LAI service can then use the matching domain to identify the ID of the AO application. The LAI service then enables the VN to start sending location data associated with the device to the AO application using the ID of the AO application. In this way, a device of the AO can roam to any VN that is part of the same identity federation as the AO, and the VN can dynamically (e.g., on the fly) establish a secure and trusted relationship with the AO, such that location data can be pushed to the AO application. Thus, the embodiments herein do not have to rely on a pre-existing relationship between the AO and the potential VN before these networks can share location data of roaming devices to the AO.

[0020] Figure 1 A location sharing system 100 using identity federation is illustrated, according to one embodiment described herein. The system 100 allows a VN 150 (also referred to as an access network (AN)) to dynamically discover the ID of an AO application 105 for a roaming device 135 that has roamed to the VN 150. The embodiments herein are applicable when the AO and the IDP 120 are different entities, although not limited to this case. In addition, the embodiments herein can be used in a multi-RAN scenario, where the AO application 105 is the target for sharing location data for devices 135 owned by the AO. Location data can be fed to the AO application 105 when the devices 135 are connected to their home network (e.g., home network 130) and when they roam to the VN 150, as shown. Figure 1

[0021] ​The following embodiments also describe techniques for automatically binding a set of device ids to a corresponding AO. In one embodiment, the device IDs are provided directly by the IDP 120 on behalf of the AO. Additionally, the owner / operator of the VN 150 can dynamically manage its policies and obtain explicit consent from the AO application 105 to share location data. This ensures that data disclosure is only sent to the AO if explicit consent is obtained from the AO and in compliance with the policies defined by the owner of the VN 150 (e.g., the owner of the VN 150 can choose not to disclose any location data). In other examples, the AO can be able to explicitly consent to the VN 150 sharing location data with third parties (e.g., for data analytics purposes, for logistics, for subcontractors, etc.).

[0022] The VN connectors 140 coupled to the VN 150 interoperate with the IDP connectors 125 associated with the home network 130. These connectors 140, 125 provide a means for dynamic discovery of peers, dynamic establishment of secure tunnels, and carrying of identity and authentication packets, neither requiring prior knowledge nor pre-establishment of a peer-to-peer protocol between the IDP 120 and the VN 150. Each VN 150 can have associated one or more VN connectors 140 (e.g., one for Wi-Fi, one for LoRa, one for PLTE, one for 5G, and so on, or they can all be integrated as a single entity).

[0023] The system 100 includes an open roaming federation 115 that establishes trust between the IDP 120 and the VN 150 so that a roaming device 135 can be authenticated using credentials stored in the IDP 120. However, the embodiments herein can be applied to any identity federation that establishes trust between the VN and the IDP 120 so that a roaming device 135 can be identified. Generally, the open roaming federation 115 allows the VN 150 to authenticate a roaming device 135 so that the device 135 can attach to the VN 150. However, the embodiments herein leverage the open roaming federation 115 to further enable the VN 150 to establish trust with the AO application 105 so that location data (or other metadata) about the roaming device 135 can be shared with the AO application 105 or a third party entity.

[0024] Once the roaming device is authenticated, the VN 150 can track the roaming device (e.g., using Wi-Fi, cellular, or LoRa positioning technology) and determine whether the location of the device 135 should be shared with the AO application 105 (or some other third-party entity). To do so, the VN 150 communicates with the LAI service 110, which can provide the VN 150 with the ID of the AO application 105. The LAI service 110, which is a trusted service from the perspective of the VN 150, can establish trust between the VN 150 and the AO application 105, despite the lack of a prior trust relationship between these entities. Once trust is established, the VN 150 can begin pushing location data about the device 135 to the AO application 105 or a third-party entity indicated by the AO application 105.

[0025] In one embodiment, the LAI service 110 comprises one or more computing systems that include one or more processors and memory. In one embodiment, the LAI service 110 is a software application that executes on one or more computing systems.

[0026] Figure 2 is a flowchart of a method 200 for binding an AO application to an IDP in a LAI service according to one embodiment described herein. In one embodiment, the method 200 is performed prior to a device (e.g., the roaming device 135) roaming to a VN (e.g., the VN 150). In particular, the method 200 can be performed to establish a trusted relationship between the AO, the IDP, and the LAI service. In this way, later when a device owned by the AO roams to a VN that is in the same identity federation as the LAI service, the LAI service can establish a trusted relationship between the VN and the AO (or more specifically, between the VN and the AO application) so that the VN can push location data associated with the device to the AO.

[0027] At block 205, the IDP registers with the LAI service. For example, each IDP can or can not require an IDP connector to interface with the LAI service. For example, a Wi-Fi IDP can use native automation rules to push data directly to the LAI service (i.e., no connector is required between the IDP and the LAI service). However, other IDPs (e.g., LoRa network servers, mobile manufacturers, enterprises, etc.) can use an IDP connector to feed data to the LAI service. In either case, the IDP can interface with the LAI service once registered. Additionally, the IDP can or can not operate its own VN in the open roaming federation.

[0028] Registering an IDP with the LAI service can include a certificate for establishing a trusted connection to the LAI service. The certificate can be issued by a public key infrastructure (PKI) supported by the LAI service itself, by the open roaming federation (as is the case when the IDP is hosted in open roaming), or by a trusted third party infrastructure. In the case where the open roaming federation issues certificates for mutual authentication between the IDP and the VN during the roaming process, the certificates can be re-used for authentication to the LAI service, or new certificates can be issued for the purpose of exchanging identity information.

[0029] At block 210, the AO registers with the LAI service and selects the IDP it uses. That is, the AO selects which of the registered IDPs it has a contractual relationship with. In one embodiment, the AO can be an IDP, in which case it selects itself. Prior to registering with the LAI service, the AO should already have a unique ID and credentials to access its data within each IDP. Thus, the AO will have an ID and credentials to log into its associated IDP and manage its devices. The AO can have a different set of IDs and credentials for each IDP it subscribes to.

[0030] At block 215, the LAI service assigns a tenant ID to the registered AO, assigns a unique token to the registered IDP, and assigns an ID to the AO application. If the AO wishes to register more than one class of identity for the same IDP in the LAI service, the AO selects the IDP as many times as needed, and different tokens are assigned to the IDP by the LAI service. This can occur, for example, when the same entity can act as an IDP for two or more domains on behalf of the AO. In this way, each domain will be associated with only one (token, tenant ID) pair, while multiple tokens can be assigned to the same IDP.

[0031] In one embodiment, the AO application is registered with the LAI service at block 215. As described above, the AO application is the destination of the data stream originating from the selected IDP (e.g., for populating IDs for devices owned by the AO) and the VN (e.g., for receiving location updates for devices owned by the same AO). The AO application has a unique ID within the LAI service (e.g., embedded as a uniform resource identifier (URI) for the AO application). For this purpose, the AO application can also have a certificate issued by a PKI trusted by the identity federation.

[0032] Figure 3is table 300 in the LAI service that stores the tenant ID of the registered ID, the token of the registered IDP, and the AO application ID according to one embodiment described herein. As shown, table 300 includes three columns: a home / domain column, an authorized tenant ID column, and an AO application ID column. After the IDP, AO, and AO application are registered, the domain is not yet linked to the AO application ID, which happens in the next block of method 200. However, the remaining two columns indicate that there are individual tokens assigned to the IDP (i.e., tokens 1-n) and the corresponding tenant ID of the AO (i.e., tenant ID = X) that is, table 300 records each IDP that the AO with tenant ID X has selected. The third column records the ID of the AO application (i.e., URI X) that corresponds to AO X. In this way, the LAI service records which IDPs the AO has selected and the ID of the corresponding AO application.

[0033] In one embodiment, the LAI service has a different table 300 for each AO. Alternatively, the LAI service has a single table for all registered AOs that includes their respective selected IDPs and AO applications.

[0034] In block 220, the LAI service binds the IDPs selected at block 210 to the AO application. In one embodiment, each IDP can represent a pool of AO-managed device IDs (e.g., one IDP manages a pool of LoRa devices, another IDP manages a pool of cellular devices, another IDP manages a pool of LTE devices, etc., which is illustrated in Figure 5 The devices can move freely within their home network or can roam among other VNs using an open roaming federation. The open roaming federation can use dynamic discovery (DNS resolution) of IDPs based on a domain (e.g., a realm). The PKI that the open roaming federation uses issues certificates to attest to the trustworthiness of the domain - that is, to establish an association between a previously registered IDP and a domain. The certificate issued by the PKI to the IDP can be used to prove ownership of a given domain to the LAI service. The LAI service can also proactively collect this information from other subsystems within the open roaming federation (e.g., directly from the PKI).

[0035] When the IDP sends data to the LAI service, it uses the unique (token, tenant ID) pair issued by the LAI service (e.g., the pair illustrated in the second column of table 300 in Figure 3 ). For example, in Figure 3 , IDP 1 can use (token 1, tenant ID = X) and can also send the domain to the LAI service that the AO uses in the context of this IDP.

[0036] At sub-block 225, as part of binding the IDP to the AO application, the LAI service generates a table that links the realm of the selected IDP to the AO application. Figure 4 Figure illustrates updating Figure 3 the table in 400 to include the realms that are bound to the IDP and the AO application. For example, IDP 1 can send the realm "NS1.000008.netids.lora-alliance.org" to the LAI service, which is stored in the left column. The same process applies to other IDPs selected by the AO. That is, IDP n can send the realm "enterprise_X.com", which is also stored in the appropriate entry in the left column. Based on this, the LAI service can verify the ownership of the realm (according to the content of the certificate issued by the federation) and update its status, as shown in table 400. In other words, the LAI service can use the certificate provided to the IDP by the PKI to establish a trusted relationship with the IDP. As a result of this relationship, when the IDP indicates which realm it "owns" for a particular AO, the LAI service trusts the IDP. In the example shown in table 400, the same AO application is bound to two different realms, each associated with a different IDP, i.e., IDP 1 and IDP n.

[0037] Assigning a realm to an IDP also binds the IDP to the AO application. In one embodiment, the realm is included in or derived from the device ID provided by the device. For example, in LoRa, the device ID does not explicitly include the realm. The realm can be dynamically constructed based on the ID, or can be inferred based on the ID. For example, the "netids.lora-alliance.org" part is common to any ID. In summary, the realm can be explicitly included / provided by the device, inferred, or dynamically constructed from the device ID itself. In another example, the device can have an ID DevAddr_x@NS1.000008.netids.lora-alliance.org. As discussed below, the LAI service can use the realm in the device ID (i.e., "NS1.000008.netids.lora-alliance.org") to map to a unique (token, tenant ID) pair in table 400. In turn, the (token, tenant ID) pair maps to a unique entry (e.g., row) in table 400, where there is only one AO application ID authorized by the AO. Thus, any device in that realm maps to the same AO application. In this way, since the realm is owned by the IDP (it has a trusted relationship with the LAI service), the LAI service uses table 400 to bind the realm (and thus the IDP) to the AO application.

[0038] Figure 5 Figure illustrates the LAI service 110 communicating with IDPs 120 and AO applications 105, according to one embodiment described herein. As previously mentioned, the AO applications 105 are consumers of location data sent by VNs and proxied and streamed by the LAI service 110 (where streaming only occurs for AO-owned devices). The following process describes one potential embodiment to ensure trusted ID ownership and data flow across the LAI service 110, which can be used in certain parts of the method 200.

[0039] Device ID ownership can be handled within the LAI service in the following manner. As shown in Figure 5 , device IDs can be directly fed by the source, i.e., directly by the IDP. In this manner, the LAI service 110 does not claim or input identity and / or data proxy messages by the AO. More specifically, device IDs can be automatically fed by the IDP 120 themselves, as the IDP 120 are the source of truth for the device IDs they manage. Thus, the AO does not need to manually input device IDs in the LAI service 110 or claim any device IDs, as this is handled by the IDP 120. This also applies to device IDs provided by entities acting as IDPs on behalf of the AO.

[0040] In one embodiment, based on a root of trust (e.g., by using PKI) and mutually authenticated interfaces, the LAI service 110 enables the binding of device IDs managed by the IDP 120 to a specific AO application 105. This binding is captured in the table 400 in Figure 4 . The data flow for populating the table 400 in Figure 4 and feeding device IDs from the IDP 120 to the AO application 105 can be based on the schema shown in Figure 5 . For example, each IDP 120 uses its own token (assigned by the LAI service 110), and the data is populated using the same tenant ID (i.e., the tenant ID assigned to the AO application 105 by the LAI service). In this manner, the AO application 105 is a passive listener (consumer) of identity data produced by the IDP 120 and proxied by the LAI service 110.

[0041] As discussed below, location data can be received from both the home network and from the VN as the device roams. In the former case, the home network typically also acts as the IDP 120. Thus, when the device is not roaming, certain IDP 120 can feed and update location data to the AO application 105. In the latter case, the location update can come from the VN connector, or directly from the respective IDP 120. In the case where the entity interfacing with the LAI service 110 uses a connector, the connector ID can also be conveyed in the messages sent from the IDP connector or VN connector. The location data can be received by the LAI service 110, processed, and pushed to the AO application 105, regardless of the type of device used and the access technology (e.g., LoRa, Wi-Fi, cellular, etc.). In Figure 5 , the AO uses three different IDP 120, which correspond to three different wireless communication modes (e.g., LoRa, Wi-Fi, and cellular), to enable the LAI service 110 to push location data for the AO's devices to the AO application 105.

[0042] In another embodiment, the AO application 105 can require explicit approval from the IDP 120 before data can be streamed to the AO application 105. This encompasses the scenario of initially populating the AO application 105 with data from a source of truth (i.e., the IDP). This can require explicit approval from the IDP itself (otherwise the ID would not show up in the AO application 105). Obtaining explicit approval can use an SSO process with 2 / MFA support or alternative authentication means, assuming the IDP 120 has already registered with the LAI service 110. The explicit approval process can be toolized compared to implicit (or inferred) binding, in which the IDP 120 grants access to the AO application in the LAI service 110, rather than the other way around.

[0043] Figure 6 is a flowchart of a method 600 for enabling a VN to share location data with an AO application, according to one embodiment described herein. In one embodiment, the method 600 assumes that the method 200 has been performed to populate the table 400 in Figure 4

[0044] At block 605, the VN detects a roaming device. This is illustrated in Figure 1 , where the roaming device 135 has disconnected from its home network 130 and is now attempting to connect to the VN 150.

[0045] ​At block 610, the IDP authenticates the device through identity federation and allows the device to attach to the VN. That is, the VN can authenticate the device using identity federation (e.g., open roaming federation). In one embodiment, as shown in FIG. 1, the VN connector 140 establishes a secure tunnel to the IDP connector 125 that allows the IDP 120 and the VN 150 to exchange data for authenticating the device 135. This secure tunnel can be based on mutual authentication. In the case of Wi-Fi, the connectors can proxy and forward RADIUS messages over the WAN link (using RADSEC). For private cellular networks, the connectors can proxy DIAMETER messages over the WAN link and forward them to the corresponding DRA and HSS. For LoRa, the connectors can proxy and forward passive roaming start requests (PRStartReq) and passive roaming start responses (PRStartAns) over the WAN link. The VN connector can be a separate entity that handles each access technology separately, or can be architected as a single multi-access connector. Figure 1

[0046] Once the device is authenticated using identity federation, subsequent blocks in the method 600 can be used to dynamically identify the AO application ID through the LAI service.

[0047] At block 615, the VN determines that the shared policy allows the VN to share the location of the device. Based on the device ID, the VN determines whether the device is a roaming device or a local device and applies a predefined policy that indicates whether the VN should share location data for the device. This policy can be based on a specific realm provided in the device ID. That is, the VN can identify the realm from the device ID and use this realm to index into a policy to determine whether the policy prohibits or allows the VN to share location data for devices in the realm. That is, it is up to the VN policy to decide whether to check whether the AO wants to receive location data for its device. The VN can also decide whether to send such data to third party entities using the realm in the device ID.

[0048] Assuming the policy allows the VN to reveal the location of the device, at block 620, the VN connector queries the LAI service to determine whether the location data for the device (or realm) is needed. In one embodiment, the VN connector shares the device ID, the realm associated with the device, and other metadata (subject to privacy regulations) with the LAI service.

[0049] Figure 7 ​Figures illustrate a system for enabling a VN 150 to share location data with an AO application, according to one embodiment described herein. Arrows 702 and 700 illustrate a VN 150 and VN connector 140 querying the LAI service 110 to determine if the device's location data is required, where the VN connector 140 provides the device ID, the realm associated with the device, and other metadata to the LAI service. In scenarios where government regulations (e.g., privacy regulations) restrict the use of device IDs as input to query the LAI service, a combination of the realm and second-order factors can be used, as long as they support automated verification. For example, a hash of identifiable billing log entries, a hash of identifiable LoRa MAC frames, etc. For example, in a message sent to the LAI service, the VN connector can include all or a subset of the following parameters (the first two parameters are directed to the LAI service itself, while the latter two parameters should be proxied and forwarded to the AO): VN ID, home network ID, realm, or device ID.

[0050] Returning to the method 600, at block 625, the LAI service uses the realm provided by the device and VN connector to identify the AO application. That is, with the realm, the LAI system can resolve the authorized tenant ID and dynamically determine the ID of the corresponding AO application. Using the table 400 as an example, if the realm in the device ID is "enterprise_X.com", then the LAI service can identify the appropriate row with tenant ID (X) and AO application ID (URI_X).

[0051] At block 630, the LAI service enables the VN to share the device's location with the AO application. The LAI service can proxy the query sent by the VN connector to the AO application, as illustrated by arrow 701 in Figure 7 Generally, the query sent to the AO application 105 determines whether the location data is required for a specific device or for the entire realm. The AO application then replies (this is also shown by arrow 701). The reply is proxied by the LAI service 110 and forwarded back to the VN connector 140, as illustrated by arrow 700. If the query is accepted by the AO application 105, the LAI service 110 can return the AO application ID to the VN connector 140, so that the VN 150 can obtain the explicit consent (digitally signed) of the AO application 105 before sharing any location data with it, Figure 8This is discussed in detail above. The LAI service 110 can also provide the ID of the IDP of the AO to the VN 150 based on the domain sent in the query. The VN 150 can use this ID to verify the AO application ID and bind it to the IDP that authenticated the device during the roaming phase. In this way, the IDP ID bound to the AO application 105 just discovered is provided to the VN 150 by a trusted entity (i.e., the LAI service 110). The VN (or VN connector) can then start pushing location updates corresponding to the roaming device to the AO application 105.

[0052] In one embodiment, the VN pushes location data to the LAI service, which in turn proxies and shares the updates with the corresponding AO application. In other embodiments, the VN can push location data to the AO application without using the LAI service as an intermediary or proxy. The location data can include the device ID as well as latitude and longitude coordinates. The update policy can be decided by the VN (e.g., push every S seconds, every M minutes, every H hours, every time the device changes its location, when the attached VN changes, etc.). The data sharing can be stopped by the VN, the LAI service, or the AO application. For example, when the device leaves the premises, if it behaves abnormally, if the IDP removes the ID from the LAI service, if the AO does not want to continue accumulating data sharing costs, etc.

[0053] In a further enhancement, the AO application can reply to the request from the VN by allowing the VN to share location data with third party entities (e.g., for processing purposes, as part of an automated supply chain, for unmanned operations, etc.). These third party entities should be trusted within the LAI service. That is, these third party entities can have registered with the LAI service and have a unique application ID (e.g., URI) and corresponding entry in the LAI service (e.g., as shown in the table). The LAI service can generate the corresponding (token, tenant ID) pair based on a delegation from a valid AO tenant. Figure 4

[0054] In another enhancement, an incentive model can be used to promote data sharing. For example, the AO can be willing to pay for such information. Likewise, the LAI service can have an incentive to offer and expand such a service. The incentive to the VN can be based on direct monetization or indirect means of generating revenue (e.g., by providing such a service, a port can attract more cargo).

[0055] Additionally, the above techniques apply even to devices that can move within their home network. That is, mobility is considered without necessarily roaming, in which case both the AO and the service provider can benefit from obtaining accurate location data.

[0056] ​Figure 8 is a flowchart of a method 800 for obtaining explicit consent for sharing location data from an AO application, according to one embodiment described herein. In one embodiment, the method 800 is performed after block 625, where the LAI service has indicated to the VN which AO application should receive location information for a roaming device.

[0057] At block 805, the VN first determines whether the AO application has consented to share the device's location. For example, a different device owned by the AO can have previously roamed to the VN where the AO consented to share location data. The VN can have a local policy to authorize and cache the consented exchange for a period of time before querying the LAI service again.

[0058] However, assuming no consent was previously given, the method 800 proceeds to block 810, where the VN requests the AO application to sign a consent. In Figure 7 As an example, arrow 703 illustrates the VN connector 140 sending a request for consent to the LAI service 110, which as a proxy, forwards the request to the AO application 105, as illustrated by arrow 704.

[0059] The signed consent is then sent back to the VN connector, as illustrated by arrow 705. In Figure 7 The exchange of explicit consent is brokered by the LAI service 110 in this example, although other models can be applied, including a direct peer-to-peer exchange or using another system as a proxy.

[0060] At block 815, the VN verifies the received consent. The VN can rely on PKI to verify the AO application's signature and the data provided in block 625 of the method 600. Doing so allows the VN to verify that the IDP ID matches the one that authenticated the device. Alternative options can include WC3 verifiable credentials (e.g., the IDP can vouch for the AO application's verifiable credentials), a token-based mechanism to bind the two, etc.

[0061] If at block 820, the VN is unable to verify the consent, the method 800 proceeds to block 825, where the VN does not share or push out location information related to the roaming device to the AO application or other third party. However, assuming the consent is verified, the method 800 proceeds to block 630 of the method 600, as described above.

[0062] In the present disclosure, reference is made to various embodiments. However, the scope of the present disclosure is not limited to the specific embodiments described. Rather, any combination of described features and elements, whether related to different embodiments or not, is contemplated to implement and practice contemplated embodiments. Furthermore, when an embodiment is described as comprising at least one of A, B, and C, it will be understood by those skilled in the art that the embodiment can include A alone; B alone; C alone; as well as any combination of A, B, and C. Additionally, although some embodiments disclosed herein can achieve advantages over other possible solutions or over the prior art, whether or not a given embodiment achieves advantages over other possible solutions or over the prior art is not a limitation of the scope of the present disclosure. Thus, aspects, features, embodiments, and advantages of the disclosure disclosed herein are merely illustrative and not limiting of the scope of the appended claims, unless otherwise explicitly recited (one or more) claims. Likewise, a recitation of "the invention" should not be interpreted as a generalization of any inventive subject matter disclosed herein, nor should "the invention" be considered to be an element of the scope of the appended claims unless explicitly recited in a claim.

[0063] As will be appreciated by one of skill in the art, embodiments disclosed herein can be implemented as a system, method, or computer program product. Accordingly, embodiments can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.) or an embodiment combining software and hardware aspects that can all generally be referred to herein as a "circuit," "module" or "system." Furthermore, embodiments can take the form of a computer program product on one or more computer readable medium(s) having computer readable program code embodied in the medium.

[0064] Program code embodied on a computer readable medium can be transmitted using any appropriate medium, including but not limited to wireless, wired, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0065] Computer program code for carrying out operations of embodiments of the present disclosure can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0066] The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0067] The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0068] The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0069] The computer program product can have signal recorded thereon in a variety of forms including, but not limited to, radio frequency signals, digital signals, voice signals, and / or other like signals. Computer program product of the present disclosure can be implemented by various high-speed computers and / or computer processors, which will execute the sequences of instructions, and include, but are not limited to, IP networks, ISP networks, Internet, Intranets, Extranets, wide area networks (WAN), local area networks (LAN), magazines, journals, books, broadcast television, pointcast systems, world wide web wireless systems, web server systems, and / or radio broadcast systems. Those skilled in the art will appreciate that any number of computer systems and / or computational platforms can be used to implement the computer program product described and suggested herein.

[0070] In light of the forgoing, the scope of the present disclosure is determined by the appended claims.

Claims

1. A method comprising: Register multiple Identity Providers (IDPs) with the Location, Aggregation, and Insight (LAI) service, wherein the LAI service, the multiple IDPs, and the Asset Owner (AO) are part of an identity federation; Register the AO with the LAI service, wherein registering the AO includes selecting one or more IDPs that have already registered with the LAI service; In the LAI service, the selected IDP is bound to the AO application of the AO, wherein the selected IDP and the AO application share common domains; After detecting that a device has roamed to a visited network (VN) in the identity federation, the domain associated with the device is received from the VN at the LAI service; The AO application is identified at the LAI service by matching the received domain to one of the various domains; and This enables the VN to push location information corresponding to the device to the AO application.

2. The method as described in claim 1, wherein, Receiving the domain and identifying the AO application at the LAI service occurs after the device has been authenticated and attached to the VN.

3. The method as described in claim 1 or 2, wherein, Binding the selected IDP to the AO application further includes: A table is generated for the AO at the LAI service, which links the various domains of the selected IDP to the AO application.

4. The method of claim 3, further comprising: At the LAI service, a tenant ID is assigned to the AO, a unique token is assigned to each of the plurality of IDPs, and an ID is assigned to the AO application, wherein the tenant ID, the unique token, and the ID of the AO application are used to generate the table.

5. The method of claim 4, further comprising: After establishing a trust relationship between the LAI service and the selected IDP, receive instructions from the selected IDP regarding ownership of the various domains by the selected IDP; and The various fields are stored in the table, wherein each field is linked to the ID of the AO application in the table.

6. The method of any of the preceding claims, further comprising, before enabling the VN to push location information corresponding to the device to the AO application: Obtain explicit consent from the AO application so that the VN can provide the location information to the AO application or a third-party entity.

7. The method as described in any of the preceding claims, wherein, Each selected IDP corresponds to a different wireless communication mode.

8. The method as described in any of the preceding claims, wherein, Before the device roams to the VN, the VN has no trust relationship with the AO application, but before the device roams to the VN, the VN has a trust relationship with the LAI.

9. A computing system, comprising: processor; as well as The memory stores the application, which is configured to perform operations including the following actions when executed by the processor: Register multiple Identity Providers (IDPs) with the Location, Aggregation, and Insight (LAI) service, wherein the LAI service, the multiple IDPs, and the Asset Owner (AO) are part of an identity federation; Register the AO with the LAI service, wherein registering the AO includes selecting one or more IDPs that have already registered with the LAI service; In the LAI service, the selected IDP is bound to the AO application of the AO, wherein the selected IDP and the AO application share common domains; After detecting that a device has roamed to a visited network (VN) in the identity federation, the domain associated with the device is received from the VN at the LAI service; The AO application is identified at the LAI service by matching the received domain to one of the various domains; and This enables the VN to push location information corresponding to the device to the AO application.

10. The computing system of claim 9, wherein, Receiving the domain and identifying the AO application at the LAI service occurs after the device has been authenticated and attached to the VN.

11. The computing system as claimed in claim 9 or 10, wherein, The operation also includes: A table is generated for the AO at the LAI service, which links the various domains of the selected IDP to the AO application; At the LAI service, a tenant ID is assigned to the AO, a unique token is assigned to each of the plurality of IDPs, and an ID is assigned to the AO application, wherein the tenant ID, the unique token, and the ID of the AO application are used to generate the table; After establishing a trust relationship between the LAI service and the selected IDP, an instruction is received from the selected IDP indicating ownership of the various domains by the selected IDP; and The various fields are stored in the table, wherein each field is linked to the ID of the AO application in the table.

12. The computing system as described in claim 9, 10, or 11, wherein, The operation also includes, before enabling the VN to push location information corresponding to the device to the AO application: Obtain explicit consent from the AO application so that the VN can provide the location information to the AO application or a third-party entity.

13. The computing system according to any one of claims 9 to 12, wherein, Each selected IDP corresponds to a different wireless communication mode.

14. The computing system according to any one of claims 9 to 13, wherein, Before the device roams to the VN, the VN has no trust relationship with the AO application, but before the device roams to the VN, the VN has a trust relationship with the LAI.

15. A non-transitory computer-readable medium having program instructions executable by a processor to perform operations, the operations including: Register multiple Identity Providers (IDPs) with the Location, Aggregation, and Insight (LAI) service, wherein the LAI service, the multiple IDPs, and the Asset Owner (AO) are part of an identity federation; Register the AO with the LAI service, wherein registering the AO includes selecting one or more IDPs that have already registered with the LAI service; In the LAI service, the selected IDP is bound to the AO application of the AO, wherein the selected IDP and the AO application share common domains; After detecting that a device has roamed to a visited network (VN) in the identity federation, the domain associated with the device is received from the VN at the LAI service; The AO application is identified at the LAI service by matching the received domain to one of the various domains; and This enables the VN to push location information corresponding to the device to the AO application.

16. The non-transitory computer-readable medium of claim 15, wherein, Receiving the domain and identifying the AO application at the LAI service occurs after the device has been authenticated and attached to the VN.

17. The non-transitory computer-readable medium as claimed in claim 15 or 16, wherein, The operation also includes: A table is generated for the AO at the LAI service, which links the various domains of the selected IDP to the AO application; At the LAI service, a tenant ID is assigned to the AO, a unique token is assigned to each of the plurality of IDPs, and an ID is assigned to the AO application, wherein the tenant ID, the unique token, and the ID of the AO application are used to generate the table; After establishing a trust relationship between the LAI service and the selected IDP, an instruction is received from the selected IDP indicating ownership of the various domains by the selected IDP; and The various fields are stored in the table, wherein each field is linked to the ID of the AO application in the table.

18. The non-transitory computer-readable medium as described in claim 15, 16, or 17, wherein, The operation also includes, before enabling the VN to push location information corresponding to the device to the AO application: Obtain explicit consent from the AO application so that the VN can provide the location information to the AO application or a third-party entity.

19. The non-transitory computer-readable medium according to any one of claims 15 to 18, wherein, Each selected IDP corresponds to a different wireless communication mode.

20. The non-transitory computer-readable medium according to any one of claims 15 to 19, wherein, Before the device roams to the VN, the VN has no trust relationship with the AO application, but before the device roams to the VN, the VN has a trust relationship with the LAI.

Images