Background

[0001] The Internet of Things (loT) refers to uniquely identifiable objects in an internet-like structure where the objects are data-enabled and may comprise data sources (e.g. they may be capable of reporting data on a regular, event-triggered or on-demand basis) and/or actuators (e.g. they may be capable of receiving a control instruction and taking an action in response to the control instruction). Equipping all objects in the world with minuscule identifying devices or machine-readable identifiers could transform daily life. For instance, it may improve the growth of plants in a greenhouse by enabling collection of multiple data sources (e.g. air quality inside the greenhouse, weather outside the greenhouse, soil temperature, etc.) and control of watering systems based on the sensed data. However there are a large number of practical challenges in the implementation of loT. These challenges include aspects relating to security of the network, the devices and the data streams and aspects relating to authentication and trust between devices (e.g. a device that provides data and a device that consumes that data). As the number of loT devices increases, the challenges in relation to device discovery and interconnection become more complex.

[0002] The embodiments described below are not limited to implementations which solve any or all of the disadvantages of known systems.

Summary

[0003] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0004] Described herein are methods of establishing a mutual trust environment between two virtual assets in a connection brokerage system. Using the methods described herein avoids either virtual asset having to present their own credentials to the other virtual asset. Furthermore, by using third-party verification services, the credentials may be retained in a trusted environment external to the connection brokerage system.

[0005] A method of brokering a trusted connection between two virtual assets in a connection brokerage system is described. The method comprises negotiating a connection between a service requesting virtual asset and a service providing virtual asset using two verification services. A first verification service dynamically verifies if at least one identitybased credential of a controlling entity associated with an external asset represented within the connection brokerage system by the service requesting virtual asset which is received from a component of the registrar computer system matches a corresponding identity-based credential. A second verification service dynamically verifies if at least one credential associated with an external asset represented within the connection brokerage system by the service providing virtual asset which is received from a component of the registrar computer system matches a corresponding credential. Only if both verifications are successful do the two virtual assets establish a trusted connection.

[0006] A first aspect provides a method of brokering a trusted connection between two virtual assets in a connection brokerage system comprising a plurality of service-requesting virtual assets and service-producing virtual assets, the method comprising: receiving, by a registration component of a registration system of the connection brokerage system, a service request from a service requesting virtual asset; determining, based on service descriptors associated with virtual assets held in one or more registration components of the registration system, a service providing virtual asset capable of providing the requested service; and negotiating a connection between the service requesting virtual asset and the determined service providing virtual asset using a first verification service and a second verification service, wherein the first verification service dynamically verifies if at least one identity-based credential of a controlling entity associated with an external asset represented within the connection brokerage system by either one of the service requesting or service providing virtual assets which is received from a component of the registrar computer system matches a corresponding identity-based credential held by a verification service provider, wherein the second verification service dynamically verifies if at least one credential associated with an external asset represented within the connection brokerage system by the service providing virtual asset which is received from a component of the registrar computer system matches a corresponding credential, wherein, if the both verifications are successful and if a connection is successfully negotiated between the two virtual assets by the registrar computer system of the connection brokerage service, the two virtual assets establish the connection as a trusted connection.

[0007] A second aspect provides a system configured to perform any of the methods described herein.

[0008] The methods described herein may be performed by software in machine readable form on a tangible storage medium e.g. in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium. Examples of tangible (or non-transitory) storage media include disks, thumb drives, memory cards etc. and do not include propagated signals. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.

[0009] This acknowledges that firmware and software can be valuable, separately tradable commodities. It is intended to encompass software, which runs on or controls “dumb” or standard hardware, to carry out the desired functions. It is also intended to encompass software which “describes” or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.

[0010] The preferred features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the invention.

Brief Description of the Drawings

[0011] Embodiments of the invention will be described, by way of example, with reference to the following drawings, in which:

[0012] FIG. 1 illustrates schematically the data flows within a connection brokerage system when implementing a method of brokering a mutually trusted connection between two virtual assets;

[0013] FIG. 2 shows a message flow in a first example of brokering a mutually trusted connection between two virtual assets;

[0014] FIG. 3 shows a message flow in a second example of brokering a mutually trusted connection between two virtual assets;

[0015] FIG. 4 shows a message flow in a third example of brokering a mutually trusted connection between two virtual assets; and

[0016] FIG. 5 is a schematic diagram of a computing device that may run the registration component of a connection brokerage system or an agent of a virtual asset.

[0017] Common reference numerals are used throughout the figures to indicate similar features.

Detailed Description

[0018] Embodiments of the present invention are described below by way of example only. These examples represent the best ways of putting the invention into practice that are currently known to the Applicant although they are not the only ways in which this could be achieved. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

[0019] As described above, there are a large number of practical challenges in the implementation of loT. As well as problems relating to security, authentication and trust (e.g. where the ownership of different data sources and/or actuators is diverse and/or there are security I safety concerns regarding the data or the actuator control), configuring and managing the large number of deployed devices is difficult, particularly as a consequence of the scale (i.e. the potential number of loT devices that may be deployed). Furthermore, whilst some loT devices may only provide data (e.g. measurement data or other locally generated data), others may include actuators, or control functionality for connected actuators. This means that there is a huge range of capabilities of the deployed devices (e.g. in terms of generating data and/or receiving controls for local actuators).

[0020] In order for an loT device to serve a useful purpose, other devices need to be able to find the loT device and then receive data from the loT device and/or transmit control data to the loT device. A connection brokerage system may be used to broker such connections and in order to broker connections, the connection brokerage system comprises a registrar functionality (which may be implemented as a centralized entity or in a distributed manner) and a plurality of virtual assets. A virtual asset acts as a proxy for a real device (e.g. a physical device such as an loT device that generates data using one or more sensors), a data source (e.g. where the data is not measurement I sensor data), another virtual asset or a group of real devices and/or other virtual assets. Each virtual asset comprises metadata that describes what it is a proxy for (e.g. the real device, data source, group of devices, etc.) along with information about data streams that can be provided by the virtual asset (e.g. wind speed in m/s) and/or can be received by the virtual asset (e.g. on I off or other control signals). Each virtual asset therefore corresponds to a data entry in the connection brokerage system, referred to as a registry entry, that is created when the virtual asset is created. There is a separate agent that corresponds to a virtual asset which drives (or encodes) the behaviour of the virtual asset. The code resides outside the connection brokerage system and may run anywhere (e.g. on a cloud-based server, on the real device itself, or any other computing device located outside the connection brokerage system) as long as it can connect to the virtual asset (i.e. to the data stored in the registry entry for the virtual asset in the connection brokerage system). In this way, the data and code relating to a virtual asset are separate. The agent may act as a bridge between a virtual asset and its corresponding real device (i.e. between the virtual asset and the physical electronics in the device) and may operate to report the state of the real device to the virtual asset and/or to provide a hardware interface to the real device, if the real device is controllable externally (e.g. it comprises or is connected to an actuator). In various examples, there may be an agent that acts as a bridge between each virtual asset and its corresponding real device, although some agents may act as a bridge for more than one virtual asset and/or real device (e.g. there may be fewer agents than virtual assets and/or real devices).

[0021] An loT device registers with the connection brokerage system in order that it can distribute data it generates or in order that it can receive controls for local actuators and on registration, a corresponding virtual asset, and hence registry entry, is created. Such a virtual asset may be referred to as a service providing virtual asset (SP-VA). A device that wishes to obtain data from the system also registers with the connection brokerage system and on registration, a corresponding virtual asset, and hence registry entry, is created. Such a virtual asset may be referred to as a service requesting virtual asset (SR-VA). A physical device may both provide services and request services (i.e. request data and provide control signals) and so may have two (or more) associated virtual assets. In such examples there may be a single agent that acts as a bridge for all the virtual assets associated with a single real device or there may be more than one agent.

[0022] A registrar functionality within the connection brokerage system, which may be implemented as a central server or in a distributed manner, manages the registration of real devices (including identity management), creation of virtual assets and storing and maintaining (e.g. updating when required) metadata about each of the virtual assets in the system. Example registration sequences are shown and described in the following PCT applications WO2015/052478, WO2015/052479, WO2015/052480, WO2015/052481 , WO2015/052482, WO2015/052483 and WO2015/052512 and registration may involve authentication of the real device and creation of the counterpart virtual asset.

[0023] The registrar functionality also brokering connections between virtual assets (including identity management and global search functionality), i.e. the registrar functionality brokers connections between service requesting virtual assets and service providing virtual assets that are already registered in the system. When a connection is brokered between a service requesting virtual asset and a service providing virtual asset, the service requesting virtual asset subscribes to a data feed or control stream of the service providing virtual asset and dependent upon the nature of the subscription either receives the data stream (i.e. the service requesting virtual asset, or its counterpart real device, receives the data stream from the service providing virtual asset or its counterpart real device) or is enabled to provide control signals (i.e. the service requesting virtual asset, or its counterpart real device, can send control signals to the service providing virtual asset or its counterpart real device). Example methods of brokering connections between virtual assets are shown and described in the referenced PCT applications. Once a connection has been brokered by the registrar functionality, the data (e.g. measurement data or control signals) may be transferred without further involvement of the registrar functionality (i.e. any data transfer does not go via the registrar functionality).

[0024] In a connection brokerage system, such as described above, connections may be brokered between any service requesting virtual asset and any service providing virtual asset. Alternatively, a connection may be brokered if the service requesting virtual asset has permissions as defined in an access control policy of the service providing virtual asset. In some instances, the service requesting virtual asset may also have an access control policy which specifies one or more criteria for the service providing virtual asset to meet before the connection between the two assets is brokered by the registrar functionality. As described above, the registrar functionality may be centralized or distributed. An example of an access control policy includes an access control list, where this might be defined in different ways, e.g. a list of those that can have access or a list of those that cannot have access.

[0025] For example, the registrar may send a request to the service providing virtual asset to confirm it is okay to provide the requested service which includes details of any credential for the requestor presented in the service request it received. The service providing virtual asset is then able to verify if the credentials presented conform with the conditions for accessing its services set out in the access control policy for the particular service or counterpart real device. The service providing virtual device responds to the registrar affirmatively if the conditions set out in the access control list have been met by the service requesting virtual asset. This may be sufficient for the registrar to indicate to the service providing virtual asset that they should connect to the service requesting virtual asset.

[0026] In some scenarios, however, additional verification (and hence more trust) is required, for example, of the identity of the entity controlling or owning the service requesting virtual asset and/or the service providing asset before a trusted connection between the two assets can be brokered by the registrar functionality. In some examples mutual trust is required. For example, if the service providing virtual asset is the counterpart of a real device (e.g. a railway track actuation switch sensor), it may be important (e.g. for safety reasons) that the identity of the entity controlling/owning the service requesting virtual asset as identified within the connection brokerage system (e.g. in the registry entry for the service requesting virtual asset), is in fact the actual entity requesting to actuate the real device (e.g. the railway switch), and not someone pretending to be the owner. It may also be important (e.g. for safety reasons) for the owner of the service requesting virtual asset to know that they are actually brokering a connection to enable actuation of the real device (e.g. a railway track switch in a railway owned by the correct entity) and not an entity pretending to be the owner of the real device.

[0027] Described herein are methods of establishing a mutual trust environment between two virtual assets in a connection brokerage system. The connection brokerage system comprises a plurality of virtual assets and a registrar functionality that brokers connections between virtual assets. The registrar functionality may additionally perform other functions as described above.

[0028] FIG. 1 illustrates schematically the data flows within a connection brokerage system (such as described above) when implementing a method of brokering a mutually trusted connection between two virtual assets 10, 12. In the example shown in FIG. 1 , each virtual asset is a counterpart to a real device (which may also be referred to as a real asset) 14, 16; however in other examples either or both of the virtual assets may not have a counterpart real device. Each real device 14, 16 has an owner which may, for example, be a person or an organisation (e.g. a corporation).

[0029] In the example shown in FIG. 1 , the registrar function 18 (which is shown as a cloud to indicate that it may be centralized or distributed) uses credentials for the owner of the real device counterpart 16 of the service requesting virtual asset 12 (owner A) and credentials associated with the real device counterpart 14 (owner / attribute B) of the service providing virtual asset 10 to perform verification with a third party prior to establishing a brokered connection, i.e. the credentials provided are verified by a third party that is separate from both parties involved in the brokered connection and also separate from the connection brokerage system. Furthermore the credentials provided by each party are verified by a different third party verification service. Additionally, as described below, the nature of the credentials shared by each party may be different (in terms of the entity I attribute being verified) e.g. the credentials shared by one party may relate to the identity of the party (owner A) whereas the credentials shared by the other party may relate to an attribute of the real device (attribute B).

[0030] The credentials for the owner of the real device counterpart 16 of the service requesting virtual asset 12 (owner A) may be requested as part of brokering the connection (as shown in FIG. 1 and described below) and the credentials associated with the real device counterpart 14 of the service providing virtual asset 10 (device B) may be retrieved from the registry entry for the service providing virtual asset 10 (e.g. having been provided previously, such as upon registration of the real device with the connection brokerage system) or may be requested from the service providing virtual asset 10 as part of the connection brokering process. The credentials associated with the real device counterpart 14 of the service providing virtual asset 10 may relate to the owner of the real device (e.g. owner B) and/or to attributes of the real device itself (attribute B e.g. test data, calibration data, etc.).

[0031] In FIG. 1 , the service requesting virtual asset 12 representing an external service requesting entity (i.e. a real device 16) sends a service request to the registrar function (step 101). The registrar function 18 processes the request and identities a potential service providing virtual asset 10 by matching the service descriptors in the request to those of the virtual asset 10 (e.g. to those stored in the registry entry for the virtual asset 10). External verification services 20, 22 are then used to verify both the owner of the real device counterpart 16 of the service requesting virtual asset 12 (owner A) and credentials associated with the real device counterpart 14 of the service providing virtual asset 10 (owner / attribute B). Whilst these external verification services 20, 22 are shown separately in FIG. 1 , in some examples they may be the same external verification service (e.g. where the verification is of owner B rather than attribute B) and in some examples there may be verification of both the owner (owner B) and attributes (attribute B) of the real device counterpart 14 of the service providing virtual asset 10 and this may require two different external verification services (e.g. such that there may be three different external verification services used). An example of a verification service that may be used to verify an attribute is one provided a company performing calibration services or safety checks.

[0032] In FIG. 1 , the verification associated with the service requesting virtual asset 12 (i.e. the verification of owner A) is performed first; however in other examples, the verification associated with the service providing virtual asset 10 (i.e. the verification of owner B and/or attribute B) may be performed first, or they may be performed substantially in parallel. Irrespective of the order in which the verification is performed, the connection brokering process may end without brokering a connection (e.g. be aborted) if any verification fails and the connection is only brokered if all verifications pass.

[0033] As shown in FIG. 1 , the registrar function 18 forwards an identifier for the service requesting virtual asset 12 (or its counterpart real device 16 or the owner of the counterpart real device, owner A) to the requestor verification service 20 (step 102). The external verification service 20 determines whether the service requesting virtual asset 12 is trustworthy or not, and this may involve the requestor verification service 20 communicating directly with the real device 16 which is the counterpart to the service requesting virtual asset 12, or with the service request virtual asset 12 as the delegate for the real device 16, to obtain proof (e.g. credentials) to demonstrate the identity of the service requesting party (owner A) and/or that the service requesting virtual asset 12 is associated with that party (steps 103- 104). The result of the verification of the service requesting virtual asset 12 is communicated back to the registrar (step 105). [0034] Similarly, the registrar function 18 forwards an identifier for the service providing virtual asset 10 (or its counterpart real device 14, or the owner of the counterpart real device, owner B) to the service provider verification service 22 (step 106). The external verification service 22 determines whether the service providing virtual asset 10 is trustworthy or not, and this may involve the service provider verification service 22 checking data (e.g. authentication data, calibration data, etc.). As described above, the data may relate to an attribute of the real device (attribute B). The result of the verification of the service providing virtual asset 10 is communicated back to the registrar function (step 107).

[0035] If both verification operations are performed successfully, the registrar function 18 establishes a brokered connection between the two virtual assets (steps 108). The two virtual assets 10, 12 can then establish a suitable secure and trustworthy connection which enables the service providing virtual asset 10 to provide a data stream to the service requesting virtual asset 12 and/or to receive commands from the service requesting virtual asset 12, depending upon the nature of the service requested (step 109). As previously described, once the connection is brokered by the registrar function 18, the registrar function plays no part in the provision of the service by the service providing virtual asset 104 to the service requesting virtual asset 12. If either of the verification operations is not successful, then the registrar function 18 does not establish a connection between the two virtual assets.

[0036] Using the method of FIG. 1 avoids either or both the service requesting and/or service providing virtual asset having to present their own credentials to the other virtual asset, but instead these may only be provided to the registrar function 18 or they need not be provided to the registrar function either and instead only an ID and data identifying the external verification service may be provided to the registrar function. By using third-party verification services 20, 22 (i.e. verification services which are separate from the connection brokerage system), the credentials may be retained in a trusted environment external to the connection brokerage system associated with the relevant third party verification service provider. For example, the registrar function 18 can be configured to communicate only the GUID for a virtual asset and an identifier for the entity indicated as owning/controlling that asset to the relevant verification service. The verification service provider can then request credentials and establish trust off-line or dynamically whilst the transaction is being brokered with that entity by performing a challenge/response check of the credentials stored by the verification service provider with those provided by the asset owning/controlling entity, and if the credentials are trusted, may respond with a pass/fail or an indication of the level of trust (e.g. a confidence level that owner A is owner A) to the registrar function 18. Where a level of trust is communicated, the registrar function 18 may determine if this is equivalent to a pass or a fail using a threshold level and the threshold may vary depending upon the nature of the service being requested (e.g. where there are safety or privacy concerns, the threshold that is used may be higher than for other services).

[0037] As shown in FIG. 1 , the real device counterpart to the service providing virtual asset (real device 14) is not involved in, and may not be aware of, the verification process. This enables verification of the real device counterpart of the service providing virtual asset (real device 14) to be performed even where the real device does not have network connectivity and hence may be described as a passive (rather than an active) real device.

[0038] Self-identifying credentials may be used in some implementations (for example, of the decentralized registrar system), such as those conforming to the verifiable credentials W3C spec, which also enables trusted connections to be brokered across security domains based on the presented credentials. As described above, the self-identifying credentials may be different (e.g. of a different nature or type) for the two virtual assets (e.g. identity of owner A and attribute of real device B) and as described above, only if both verifications are successful is the brokered connection established.

[0039] The credentials of the service providing virtual asset 10, or its counterpart real device 14, (e.g. attribute B) may be provided in the form of a certificate or some form of metadata for the asset and/or the requested service which enable characteristics such as the identity, condition, operational state, and/or accuracy/quality metrics for performance and/or any information to be provided to be verified.

[0040] In the method shown in FIG. 1 , the verification is performed when a connection is brokered. Where the verification of the service providing virtual asset 10 involves verifying an attribute of the real device 14 (in addition to, or instead of, verifying an identity of owner B), then this may need to be re-checked periodically. This may be enabled by time-limiting the brokered connection, thereby forcing the connection to be re-established (and the verification performed again) after the time-limit has expired. The length of the time-limit may be dependent upon the nature of the attribute that is verified and where multiple attributes are verified it may be set based on the attribute that results in the shortest time-limit.

[0041] For example, one type of verification which is performed on real devices is Portable Appliance Testing (“PAT”). PAT is usually performed by a service technician or a similarly authorized person who tests an appliance against certain safety criteria. Passing the test successfully is indicated with a sticker which is fixed to the appliance. In an loT use context, however, if a person wanted to remotely activate an loT appliance or receive a data feed or similar service from it, they would not have any awareness of its PAT certificate status, which is clearly undesirable. The actual portable appliance, even when configured for being controlled remotely, has no record stored in memory indicating a test was performed or the type of test being performed, the result of the test if the test is even passed and a PAT certificate issued or not, never mind when the certificate expires. However, the test itself can be logged in a database, and associated with the serial number of the appliance. Using the method of FIG. 1 , the service provider verification service 22 may contain or have access to this database and the verification process (between steps 106 and 107) may comprise interrogating the database using the serial number of the appliance (or other identifier provided by the registrar function 18). In this way, as part of the connection brokering operation, it is confirmed that the appliance is safe to use. The same techniques may in addition, or instead, be used to verify that the real device 14 has been calibrated and/or serviced as required by its manufacturer. This data is again unlikely to be known by the real device 14 itself but may be verified by the service provider verification service 22. The brokered connection may, for example, be set to expire when the test certificate or calibration certificate expires.

[0042] The methods described herein may be used to broker a connection with a loT asset such as a real object or device, without that loT asset itself ever becoming aware of what it is or what service functionality it is providing either as an individual loT asset or collectively with one or more other loT assets, as this knowledge is retained only by the counterpart virtual asset associated with that device in the digital environment.

[0043] FIG. 1 shows the verification being performed when a connection is brokered. In addition, or instead, verification may be performed by the service providing and service requesting virtual assets (instead of the registrar function) each time the service requesting virtual asset provides a command to the service providing virtual asset, as shown in FIGs. 2 and 3. This may, for example, be used where there are safety implications of implementing the command. FIGs. 2 and 3 show schematic diagrams of a method of establishing mutual trust within a connection brokerage system (such as described above). They show two virtual assets - a service providing virtual asset B 202 and a service requesting virtual asset A 204 - and two external (i.e. third party) verification services 206, 208.

[0044] FIG. 2 shows a message flow in which the service requesting virtual asset A 204 is verified by the service providing virtual asset B 202 (arrows 211-212) before the service providing virtual asset B 202 performs the requested command (action #1) and then the service requesting virtual asset A 204 verifies the service providing virtual asset B 202 (arrows 214-215) on receipt of data received from service providing virtual asset B 202 (arrow 213) after the action has been performed (e.g. before the data received from service providing virtual asset B 202 is relied upon in a subsequent action). As shown in FIG. 2, service requesting virtual asset A 204 provides information on how the owner of the service requesting virtual asset A (owner A)should be verified (e.g. in the form of an identifier and details of a verification service or a credential) when it provides the command to the service providing virtual asset B 202 (arrow 210). The service providing virtual asset B 202 provides information on how the corresponding real device (owner / attribute B) can be verified at the same time as providing data indicating that the requested action was completed (arrow 213).

[0045] FIG. 3 shows a message flow in which the service requesting virtual asset A 204 verifies the service providing virtual asset B 202, e.g. verifies owner / attribute B (arrows 321- 322) before it sends the command to the service providing virtual asset B 202 (arrow 323). This verification may be performed based on information received from its counterpart real device 306 (arrow 320) or information received from another source (e.g. from the registrar function when the connection was brokered). As in FIG. 2, the service requesting virtual asset A 204 is verified by the service providing virtual asset B 202 (arrows 324-325) before the service providing virtual asset B 202 performs the requested command (action #1) and provides confirmation I data to the service requesting virtual asset A 204 (arrow 326).

[0046] In FIG. 2, the verification of the service providing virtual asset B 202 is shown as determining whether the state of B and/or B’s data from doing the action (action #1) to be trusted. The verification may therefore relate to attributes of B and/or the owner of B. In FIG. 3, as the verification is performed before the action, the verification is alternatively described as determining whether device B is safe to use. This may involve verifying the state of B and/or another attribute of B or the owner of B.

[0047] An example application of the method of FIG. 3 can be described with reference to FIG. 4. In this application, there are two real devices, a sluice gate 400 and a controller 404 which may be remotely located from the sluice gate 400 or may be located proximate to the sluice gate 400 but not directly connected (e.g. via a wire) to the sluice gate 400. Instead, the controller 404 uses a connection brokerage system (as described above) to broker a connection with the sluice gate so that it can operate the sluice gate. Each of these real devices has a counterpart virtual asset 402, 406. As shown in FIG. 4, the controller 404 instructs its counterpart virtual asset 406 to open the sluice gate (arrow 420). The virtual asset for the controller 406 (which is the service requesting virtual asset in this arrangement) performs a verification of the service providing virtual asset (and/or its counterpart, the actual sluice gate) and this verification (arrows 421-422) may involve checking the identity and/or attributes of the sluice gate (e.g. has the sluice gate been serviced according to its manufacturers requirements, is the sluice gate currently operational, etc.). If that verification is passed, the virtual asset for the controller 1406 sends the command to the sluice gate virtual counterpart 402 (arrow 423) and the message sent includes information on how to verify the controller. The sluice gate virtual counterpart 402 uses this information to verify the controller 404 (arrows 424-425) and only performs the action (arrow 426) in response to the verification passing. As shown in FIG. 4, the sluice gate virtual counterpart 420 may receive data from the sluice gate 400 after the action has been performed (e.g. updated status data, confirmation that the action has been performed, etc.) and this may be sent back to the virtual asset for the controller 406 (arrow 428). In this way, the sluice gate is not opened if it is unsafe to do so (i.e. if the verification of the sluice gate fails) or if the controller is not permitted to open it, e.g. because the virtual asset is controlled by a malicious entity, in which case verification of the controller will fail.

[0048] In the examples shown in FIGs. 2-4, the party that is to be verified provides the information about how the verification should be performed. In variations of these examples however, this information may itself be obtained from a third party in order to further increase the security of the system. This third party may be different from any of the verification services used and may act as a repository for verification service information.

[0049] Whilst the methods and systems described above perform two verification operations using two different verification services, in variations of the methods described, more than two verification operations may be performed, each using a different third-party verification service. In such examples, the trusted connection is only established, or the operation performed, if all of the verifications that are performed are successful. Where more than two verification operations are performed the additional verifications (above those described in the examples above) may relate to additional attributes of one of the two entities described above (e.g. a second identity-based credential of the service requesting virtual asset and/or a second credential associated with the external asset represented in the connection brokerage system by the service providing virtual asset). For example, two different attribute-based credentials of the external asset may be verified. These may, for example, relate to two different aspects of the external asset, e.g. its calibration and its safety testing. In other examples, there may be a additional entities involved, e.g. the methods described herein may be used to verify an identity-based credential of the service requesting virtual asset, and both an attributed-based credential and an identity-based credential associated with the external asset represented in the connection brokerage system by the service providing virtual asset.

[0050] The agents of the virtual assets may run on a computing device, with a single computing device running one or more agents. The registration component of the registration function may run on a computing device. Other parts of the connection brokerage system may also be implemented on a computing device. The term ‘computing device’ and 'computer' is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realize that such processing capabilities are incorporated into many different devices and therefore the term 'computer' includes PCs, servers, mobile telephones, personal digital assistants and many other devices. FIG. 5 shows an example computing device 500.

[0051] Computing device 500 comprises one or more processors 502 which may be microprocessors, controllers or any other suitable type of processors for processing computer executable instructions to control the operation of the device in order to implement the methods described herein (e.g. to execute the registration component or a virtual agent). In some examples, for example where a system on a chip architecture is used, the processors 502 may include one or more fixed function blocks (also referred to as accelerators) which implement a part of the method of the registration component or a virtual agent in hardware (rather than software or firmware). Platform software comprising an operating system 504 or any other suitable platform software may be provided at the computing-based device to enable application software 506 to be executed on the device.

[0052] The computer executable instructions may be provided using any computer-readable media that is accessible by computing device 500. Computer-readable media may include, for example, computer storage media such as memory 508 and communications media. Computer storage media, such as memory 508, includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. In contrast, communication media may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transport mechanism. As defined herein, computer storage media does not include communication media. Although the computer storage media (memory 508) is shown within the computing device 508 it will be appreciated that the storage may be distributed or located remotely and accessed via a network or other communication link (e.g. using communication interface 510).

[0053] The computing device 500 also comprises an input/output interface 512 arranged to output display information to a display device 514 which may be separate from or integral to the computing device 500. The display information may provide a graphical user interface. The input/output interface 512 is also arranged to receive and process input from one or more devices, such as a user input device 516 (e.g. a mouse or a keyboard). This user input may be used to provide user input to the registration component or a virtual agent, send trigger signals, etc. In an embodiment the display device 514 may also act as the user input device 516 if it is a touch sensitive display device. The input/output interface 512 may also output data to devices other than the display device, e.g. a locally connected printing device (not shown in FIG. 5).

[0054] Those skilled in the art will realize that storage devices utilized to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program.

Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.

[0055] Any range or device value given herein may be extended or altered without losing the effect sought, as will be apparent to the skilled person.

[0056] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems orthose that have any or all of the stated benefits and advantages.

[0057] Any reference to 'an' item refers to one or more of those items. The term 'comprising' is used herein to mean including the method blocks or elements identified, but that such blocks or elements do not comprise an exclusive list and a method or apparatus may contain additional blocks or elements.

[0058] The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Additionally, individual blocks may be deleted from any of the methods without departing from the spirit and scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought.

[0059] It will be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art. Although various embodiments have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the spirit or scope of this invention.