Device information verification

Abstract

There is provided a method performed by a first network node. The method comprises receiving (302) a first request for verification of a device. The method comprises obtaining (304) at least one first verifiable credential (VC) from the device. The at least one first VC is signed with a first digital signature of an issuer entity. The method comprises determining (306) whether the first digital signature is verified. The method comprises, if the first digital signature is verified, determining (308) whether the at least one first VC is verified. The method comprises, if the at least one first VC is verified, storing (310) a profile of the device. The profile comprises information identifying the device, the at least one first VC, and a plurality of first information elements. Each first information element is indicative of an attribute of the device or an attribute of the issuer entity.

Description

[0001] DEVICE INFORMATION VERIFICATION

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to a method performed by a first network node, and nodes, devices, and systems configured to operate in accordance with said method.

[0004] BACKGROUND

[0005] The European Union Agency for Cybersecurity (ENISA) is an agency of the European Union (EU) that is dedicated to achieving a high common level of cybersecurity across Europe. In 2023, the ENISA published a report with an overview of the most important standards and standardisation organisations which cover Digital Identities, covering policies, services which issue and / or manage identities, formats and protocols, auditing methods, requirements for secure devices, and recommended processes and algorithms. The report highlights related EU legislation, in particular the electronic identification, authentication, and trust services (elDAS) 2.0 regulation which was proposed in June 2021. One important aspect of elDAS 2.0 is the introduction of an EU Digital Identity (EUDI) Wallet, which is designed to allow each EU citizen to be digitally identifiable and give granular control on which information wallet owners want to share. The EUDI Wallet project is ongoing, and the main use case focuses on Digital Travel Credentials (DTCs).

[0006] Although there is ongoing work aimed at achieving a high level of cybersecurity through regulations such as elDAS, obtaining verified information from multiple, known, trusted sources is still a challenge and is not easily realised using existing systems. Moreover, current techniques for information verification from multiple sources typically relies on manual processes, and this is simply not viable for automated scenarios. For example, the process of performing tasks that are location dependent, such as finding relevant automated services based on location, can be challenging for many reasons. Indeed, such processes often require a level of verification, however current mechanisms to verify device identity, device information, and / or device capabilities are mostly manual, based on faith, and require gathering information from multiple sources. Additionally, entities involved in such processes are required to provide at least some level of trust to multiple sources, which may not always be possible.

[0007] The challenges associated with obtaining verified information can be described with reference to the following digital aerospace example. In a digital airspace concept, all(e.g. flight-enabled) drones in an Ell area can be configured to support a (e.g. Third Generation Partnership Project (3GPP) compliant) mobile network connection and be registered in an air flight system. Thus, during service registration of the drone, a communication service provider (CSP) typically requires a mechanism to ensure that the drone is registered in the air flight system and that the capabilities of the drone are identical to those registered. In this example, a verification mechanism is needed in order to avoid deception by the drone (e.g. via manipulation of a subscriber identity module (SIM) card). The absence or misapplication of such a verification mechanism can lead to undesirable incidents including public safety issues.

[0008] SUMMARY

[0009] As mentioned above, there are certain challenges associated with existing techniques for digital verification. Indeed, a single device (e.g. in particular a device with intelligent software) may have multiple roles depending on what tasks the device is configured to perform and / or what responsibilities the device is configured to handle. With regards to the roles that a device performs, a device will typically be associated with an owner, and / or a responsible person(s), however, in some cases, the device may (e.g. temporarily) be associated with a user that is different to that of the owner and / or responsible person(s). For example, in a scenario in which the device corresponds to a rental car, the owner of the device is typically different to the average user of the device. It is therefore a challenge to securely determine (e.g. permanent and temporal) roles that a device assumes. Furthermore, it is also a challenge to provide / obtain such information (i.e., permanent and / or temporal roles that a device assumes) in a controlled and verifiable way.

[0010] It is an object of the disclosure to obviate or eliminate some of the above-mentioned challenges associated with existing techniques.

[0011] Therefore, according to an aspect of the disclosure, there is provided a method performed by a first network node. The method comprises receiving a first request from a device. The first request is a request for verification of the device. The method comprises obtaining at least one first verifiable credential (VC) from the device. The at least one first VC is signed with a first digital signature of an issuer entity of the at least one first VC. The method comprises determining whether the first digital signature is verified using a first public key of the issuer entity. The first public key is obtained from a first database. The method comprises, if the first digital signature isverified, determining whether the at least one first VC is verified. The at least one first VC is determined to be verified if the first database is associated with one or more trusted databases. The method comprises, if the at least one first VC is verified, storing a profile of the device in a verified device database. The profile comprises information identifying the device, the at least one first VC, and a plurality of first information elements. The plurality of first information elements are obtained from the one or more trusted databases, and each first information element of the plurality of first information elements is indicative of an attribute of the device or an attribute of the issuer entity.

[0012] In some examples, the at least one first VC can be signed with a second digital signature of the device. In these examples, the method may comprise determining whether the second digital signature is verified using a second public key of the device. The method may comprise, if each of the first digital signature and the second digital signature is verified, determining whether the at least one first VC is verified. As such, in some examples, both the first digital signature of and the second digital signature of the device (e.g. VC holder) may need to be verified before the at least one first VC is verified. In this way, greater assurance that the device is (or is not) authentic is provided. In some examples, the second public key can be comprised in the at least one first VC. In some examples, the second digital signature may be generated using a private key of the device. In some examples, the first digital signature may be generated using a private key of the issuer entity.

[0013] In some examples, obtaining the at least one first VC from the device may comprise initiating transmission of a second request towards the device, and receiving a first response from the device. The second request can be a request for information associated with the device. The first response can comprise the at least one first VC. As such, the at least one first VC can be provided to the first network node in response to the second request. In this way, the first network node can be provided with greater control over the communication of the at least one first VC, and be assured that the at least one first VC is in fact obtained from the correct device (e.g. and not a fraudulent entity).

[0014] In some examples, the method may comprise receiving a third request from a second network node. The third request can be for information indicative of one or more network entities that meet a first criterion. In these examples, the method may comprise determining whether the device meets the first criterion based on the storedprofile of the device, and, if the device meets the first criterion, initiating transmission of one or more second information elements towards the second network node. The one or more second information elements can be obtained from the profile of the device. As such, the first network node can be configured to act as, and / or provide access to, a trusted registry, and provide verified device information to requesting entities (e.g. the second network node)

[0015] In some examples, the method may comprise, in response to receiving, from the second network node, a request to communicate with the device, operating as a communication proxy between the device and the second network node. In this way, the first network node can establish a secure communication channel between the device and the second network node. Moreover, by providing a proxy service, the first network node can provide greater assurance (e.g. to the device and / or the second network node) that the communication (e.g. involving sensitive information) is legitimate. By the first network node operating as a proxy, the identity of the device (e.g. device internet protocol (IP)) need not be exposed to the second network node. As such, not only is the privacy of the device enhanced, but the device can be protected against malicious (e.g. distributed denial-of-service (DDoS)) attacks. The third request may be received using an application programming interface (API). Alternatively, or in addition, the transmission of the one or more second information elements may be initiated using the API.

[0016] In some examples, the method may comprise obtaining one or more third information elements. The one or more third information elements can be indicative of a capability and / or a functionality of the device. In some examples, the profile of the device may comprise the one or more third information elements. Therefore, in some examples, the profile can comprise information indicative of one or more services and / or functions that the device provides. This is advantageous for requesting entities which can query the first network node for information about one or more devices which can perform a particular function (e.g. task). The one or more third information elements can be received from the device. Alternatively, or in addition, the one or more third information elements can be received from the one or more trusted databases.

[0017] In some examples, obtaining the at least one first VC from the device, as described herein, may comprise initiating transmission of a second request towards the device, and receiving a first response from the device. In these examples, the second requestcan be a request for information associated with the device, the first response may comprise the at least one first VC, and the one or more third information elements can be comprised in the first response. In some examples, obtaining the one or more third elements may comprise obtaining permission information. For each third information element of the one or more third information elements, the permission information can be indicative of whether the first network node is allowed to share the third information element. As such, the first network node can be informed (e.g. by the device) of what information in the device profile can be shared and / or communicated (e.g. with requesting entities, such as the second network node referred to herein), and what information in the device profile is considered private.

[0018] In some examples, the method may comprise obtaining the plurality of first information elements from the one or more trusted databases. Obtaining the plurality of first information elements may comprise initiating transmission of a request for information indicative of the device to the one or more trusted databases, and receiving the plurality of first information elements from the one or more trusted databases.

[0019] In some examples, the method may comprise generating the profile of the device. Generating the profile of the device can comprise creating a new profile of the device, or updating an existing profile of the device. In some examples, the method may comprise, if the at least one first VC is verified, initiating transmission of a first message towards the device. The first message can comprise an indication that the verification of the device is successful. In some examples, the first message can comprise a second VC for the device. The second VC can be issued by the first network node, and the second VC may be associated with information verified by the first network node.

[0020] In some examples, the issuer entity can be an entity of a manufacturer of the device. In some examples, the one or more trusted databases may comprise at least one database of a government agency. In some examples, the attribute of the device may comprise one or more of an identifier of the device, a subscription that the device has to a network, an identifier of the subscription, an attribute of the subscription, a location of the device, an owner of the device, a user of the device, a role of the device, a state of the device, a category of the device, and a type of the device. In some examples, the identifier of the device can comprise an international mobile subscriber identity (I M SI) of the device. In some examples, the attribute of the issuer entity may compriseone or more of an identifier of the issuer entity, a location of the issuer entity, and a database associated with the issuer entity.

[0021] In some examples, the plurality of first information elements can comprise a data schema corresponding to the at least one first VC. In some examples, the data schema can comprise information for verifying the at least one first VC. In some examples, the first network node can be one or more of a node of a service provider of a telecommunications network, a node of a communications service provider of the telecommunications network, and a node of an operator of the telecommunications network. The device, as referred to herein, may be one or more of a wireless device, a user equipment, a vehicle, and a camera.

[0022] According to another aspect of the disclosure, there is provided a first network node comprising processing circuitry configured to operate in accordance with the method described earlier. In some embodiments, the first network node may comprise at least one memory for storing instructions which, when executed by the processing circuitry, cause the first network node to operate in accordance with the method described earlier.

[0023] The first network node is configured to receive a first request from the device. The first request is a request for verification of the device. The first network node is configured to obtain at least one first VC from the device. The at least one first VC is signed with a first digital signature of an issuer entity of the at least one first VC. The first network node is configured to determine whether the first digital signature is verified using a first public key of the issuer entity. The first public key is obtained from a first database. The first network node is configured to, if the first digital signature is verified, determine whether the at least one first VC is verified. The at least one first VC is determined to be verified if the first database is associated with one or more trusted databases. The first network node is configured to, if the at least one first VC is verified, store a profile of the device in a verified device database. The profile comprises information identifying the device, the at least one first VC, and a plurality of first information elements. The plurality of first information elements are obtained from the one or more trusted databases, and each first information element of the plurality of first information elements is indicative of an attribute of the device or an attribute of the issuer entity.In some examples, the at least one first VC can be signed with a second digital signature of the device. In these examples, the first network node can be configured to determine whether the second digital signature is verified using a second public key of the device. The first network node can be configured to, if each of the first digital signature and the second digital signature is verified, determine whether the at least one first VC is verified.

[0024] Obtaining the at least one first VC from the device can comprise the first network node initiating transmission of a second request towards the device, and receiving a first response from the device. The second request can be a request for information associated with the device and the first response may comprise the at least one first VC.

[0025] The first network node can be configured to receive a third request from a second network node. The third request can be for information indicative of one or more network entities that meet a first criterion. The first network node can be configured to determine whether the device meets the first criterion based on the stored profile of the device. The first network node can be configured to, if the device meets the first criterion, initiate transmission of one or more second information elements towards the second network node. The one or more second information elements can be obtained from the profile of the device.

[0026] The first network node can be configured to, in response to receiving, from the second network node, a request to communicate with the device, operate as a communication proxy between the device and the second network node. The first network node can be configured to obtain one or more third information elements. The one or more third information elements are indicative of a capability and / or a functionality of the device. The first network node can be configured to receive the one or more third information elements are received from the device, and / or the one or more trusted databases. The first network node can be configured to initiate transmission of a second request towards the device. The second request can be a request for information associated with the device. The first network node can be configured to receive a first response from the device. The first response may comprise the at least one first VC and the one or more third information elements can be comprised in the first response.The first network node can be configured to obtain the plurality of first information elements from the one or more trusted databases. The first network node can be configured to initiate transmission of a request for information indicative of the device to the one or more trusted databases, and receive the plurality of first information elements from the one or more trusted databases. The first network node can be configured to generate the profile of the device. The first network node can be configured to generate the profile of the device by creating a new profile of the device, or updating an existing profile of the device.

[0027] The first network node can be configured to, if the at least one first VC is verified, initiate transmission of a first message towards the device. The first message can comprise an indication that the verification of the device is successful.

[0028] According to another aspect of the disclosure, there is provided a system. The system comprises the first network node, as described earlier, and at least one device, as described herein.

[0029] According to another aspect of the disclosure, there is provided a computer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the method described earlier.

[0030] According to another aspect of the disclosure, there is provided a computer program product comprising a computer readable storage medium. The computer readable storage medium comprises instructions which are executable by processing circuitry to cause the processing circuitry to perform the method described earlier.

[0031] Thus, in the manner described above, improved techniques for handling information associated with a device are provided. The techniques described herein involve a first network node storing a profile of a device in a verified device database if at least one (e.g. one or more) first VC of the device is verified. The profile comprises information identifying the device and a plurality of first information elements indicative of an attribute of the device or an attribute of an issuer entity of the at least one first VC. As such, the techniques described herein provide for an automated (e.g. digital) mechanism to verify device identity and device information. As described herein, the first network node can gather information from different trusted sources and build a verified device database which can be queried by other entities. In this way, the first network node can operateas a trusted registry (e.g. handling device discovery requests for verified information associated with verified devices).

[0032] BRIEF DESCRIPTION OF THE DRAWINGS

[0033] For a better understanding of the techniques, and to show how they may be put into effect, reference will now be made, by way of example, to the accompanying drawings, in which:

[0034] Figure 1 is a block diagram illustrating a verifiable credential (VC) according to an embodiment;

[0035] Figure 2 is a block diagram illustrating an example system for handling VCs;

[0036] Figure 3 is a block diagram illustrating a first network node according to an embodiment;

[0037] Figure 4 is a block diagram illustrating a method performed by the first network node according to an embodiment;

[0038] Figures 5 and 6 are schematic illustrations of one or more attributes according to some embodiments;

[0039] Figures 7 to 13 are block diagrams illustrating methods performed by the first network node according to some embodiments;

[0040] Figure 14 is a signalling diagram illustrating an exchange of signals in a system according to an embodiment;

[0041] Figure 15 is an example of a system in accordance with some embodiments;

[0042] Figure 16 shows a device in accordance with some embodiments; and

[0043] Figure 17 shows a first network node in accordance with some embodiments.

[0044] DETAILED DESCRIPTION

[0045] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is impliedfrom the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

[0046] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject-matter disclosed herein, the disclosed subject-matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject-matter to those skilled in the art.

[0047] Figure 1 is a block diagram illustrating an example of a verifiable credential (VC) 100. VCs are a standard way of defining credentials (e.g. on the web) which is cryptographically secure, privacy preserving, and machine verifiable.

[0048] As illustrated in Figure 1, in some examples, a VC 100 can include, and / or be associated with, one or more (e.g. tamper-evident) claims 104. The one or more claims 104 can make an assertion. For example, the one or more claims may include a statement about a holder of the VC 100. The holder of the VC 100 may refer to the entity and / or the device to which the VC 100 is assigned and / or issued. In some examples, the one or more claims 104 may include a statement about an issuer of the VC 100. The issuer of the VC 100 may refer to the entity that assigns and / or issues the VC 100 to the VC holder. A single claim of the one or more claims 104 can make one or more assertions (e.g. about the VC holder and / or the VC issuer) according to some examples. For example, a claim may be a statement about the holder of the VC 100. In examples in which the holder of the VC 100 is a hardware device, the one or more claims 104 may comprise a statement corresponding to an identifier of the device, an identity of a manufacturer of the device, and / or a date of manufacture of the device. A claim can bederived. As such, a claim may correspond to information about (e.g. a property of) the VC holder that can be derived by the verifier. For example, a claim may be used to derive whether the holder of the VC 100 is a certain age (e.g. over the age of 18). In such a scenario, the claim enables the verifier to derive information about the age of the holder without the holder having to reveal its date of birth (e.g. to the verifier). In this way, the one or more claims 104 can be used to derive information without having to share private details associated with the holder of the VC 100

[0049] As also illustrated in Figure 1, in some examples, the VC 100 can include, and / or be associated with, metadata 102. As illustrated in Figure 1, the metadata 102 may be referred to herein as credential metadata. The metadata 102 may be configured (e.g. generated) to (e.g. cryptographically) prove who issued the VC 100. For example, the VC issuer may be identified based on the metadata 102. The metadata 102 can comprise information such as an identifier and / or one or more properties. The identifier may be an identifier of the holder of the VC 100. For example, the identifier may be a IMSI, a (e.g. reference to a) public key, a decentralized identifier (DID), and / or an identifier of an embedded subscriber identity module (eSIM). The one or more properties can include information indicative of the issuer, an expiry date and / or expiry time of the VC 100, a public key associated with the VC 100 (e.g. for verification purpose), and / or a status of the VC 100 (e.g. credential status such as revoked, comprised, suspended). The status of the VC 100 may be indicative of a validity of the VC 100. For example, the status of the VC 100 may indicate that a private key used to sign the VC 100 is compromised, and thus the VC 100 is no longer valid.

[0050] As illustrated in Figure 1, a VC 100 can include, and / or be associated with, one or more proofs 106. The one or more proofs 106 may be used to verify the integrity of the VC 100. As such, the one or more proofs 106 can form at least part of the verification process of the VC 100. The one or more proofs 106 may comprise a digital signature. For example, the one or more proofs 106 can comprise a digital signature made with a private key of the issuer of the VC 100, and / or a digital signature made with a private key of the holder of the VC 100.

[0051] The VC 100 (e.g. similar to a public key certificate) can contain a provable identifier (e.g. a public key, a hash of a public key, and / or a DID), information about the holder of the VC 100, and / or be signed by the issuer of the VC 100. When compared to otherverification means, such as a public key certificate, the VC 100 is more dynamic with regards to what can be included (e.g. stored) in it.

[0052] Figure 2 is a block diagram illustrating an example system for handling VCs. As illustrated in Figure 2, the system can comprise an issuer 200 of a VC, a holder 202 of the VC, and a verifier 206 of the VC. As also illustrated in Figure 2, in some examples, the system can comprise a data registry 204 (“Verifiable Data Registry”).

[0053] In some examples, the issuer 200, the holder 202, and / or the verifier 206 may generate (e.g. create) an (e.g. corresponding) identifier. The identifier can identify the entity that generated the identifier. For example, each of the issuer 200, the holder 202, and / or the verifier 206 may cryptographically generate (e.g. create) a decentralized identifier (DID). The DID may be a globally unique and cryptographically verifiable identifier. For example, the DID may be public key based. Although not illustrated in Figure 2, in some examples, the issuer 200, the holder 202, and / or the verifier 206 may associate (e.g. a set of) one or more public keys to their (e.g. corresponding) identifier (e.g. DID). The one or more public keys of the issuer 200 can be made publicly available. For example, the issuer 200 may make the one or more public keys publicly available. As such, the verifier 206 can obtain the one or more public keys of the issuer 200. In this way, the verifier 206 can validate a VC produced (e.g. issued) by the issuer 200.

[0054] As illustrated in Figure 2, the issuer 200 can be described as an entity which issues a VC to the holder 202. In some examples, the issuer 200 can be an entity that generates the (e.g. digitally signed) VC. As such, the holder 202 can obtain (e.g. acquire) the VC from the issuer 200. In some examples, the holder 202 can store the VC. The holder 202, can be a device, such as a user equipment (UE). The verifier 206 can be an entity which verifies the VC held by the holder 202. In some examples, the holder 202 may provide the VC to the verifier 206 in response to a request (e.g. for the VC) from the verifier 206. In a specific example, the issuer 200 can correspond to an entity of a university, the holder 202 can correspond to an entity of a student at the university, and the verifier 206 can correspond to an entity of a company to which the student applies for a job. In this specific example, the issuer 200 may issue a VC to the holder 202 and the VC may be indicative of (e.g. include a claim associated with) a university certificate of the student. The verifier 206 may then verify the VC (as provided by the holder 202) to ensure that the student’s university certificate is authentic.As illustrated in Figure 2, the system can comprise a data registry 204. The data registry 204 can be configured to store (e.g. maintain) data and / or information associated with the system. For example, the data registry 204 may store one or more identifiers (e.g. DI Ds) of one or more entities (e.g. the issuer 200) of the system. In some examples, the data registry 204 can store one or more information elements. The one or more information elements can comprise a data schema corresponding to a VC (e.g. issued by the issuer 200). The data schema can be used to verify the structure and / or content of the corresponding VC. For example, the data schema may be used to map the contents of the VC. In some examples, the data schema can enforce a specific structure on a given collection of data. The data schema can specify data fields, formats, and relationships within the VC. The data schema may be used to ensure that VCs are created, interpreted, and verified across different systems, enabling interoperability (e.g. in DID systems). In some examples, a data schema may comprise information about the VC itself, such as the issuer 200, issuance date of the VC, and / or expiration date of the VC. In some examples, the data schema can comprise information which is associated with the claim(s) of the VC. The data schema can comprise information indicative of the VC holder 202, such as an identifier of the VC holder 202. In examples in which the holder 202 corresponds to a device, the data schema can comprise information indicative of a plurality of characteristics of the device. As such, the information indicative of the holder 202, as comprised in the data schema, can be used to verify a claim(s) of the VC. In some examples, the data schema can comprise information that can be used to verify the authenticity and integrity of the VC. The data schema referred to herein may be a JavaScript Object Notation (JSON) schema. However, it will be understood that this is merely an example and that the data schema referred to herein may correspond to other types of data schema.

[0055] In some examples, the data registry 204 may comprise a secure (e.g. trusted) database. For example, the data registry 204 may comprise a decentralized database, a government (e.g. identifier (ID)) database, a blockchain database, and / or some other secure database. The data registry may comprise a (e.g. motor) vehicle database according to some examples (e.g. when the holder 202 corresponds to an entity associated with a vehicle).

[0056] In response to the verifier 206 obtaining the VC from the holder 202, the verifier 206 can verify the VC structure based on information (e.g. data schemas) stored in the data registry 204. In some examples, the VC may be (e.g. cryptographically) signed (e.g. bythe issuer 200). The verifier 206 may verify the authenticity of the VC based on the signature of the VC. In this way, the verifier 206 can verify the identity of the issuer 200 of the VC. In some examples, the verifier 206 may (e.g. further) verify the identity of the issuer 200 based on information comprised (e.g. stored) in the data registry 204. In some examples, the VC may include (e.g. store), and / or be associated with, an identity (e.g. DID) of the holder 202. The verifier 206 can authenticate the (e.g. identity of the) holder 202 based on the identity stored in the VC.

[0057] The verification scheme (e.g. as described with reference to the system illustrated in Figure 2), can be extended with zero-knowledge proofs. In such a scenario, the verifier 206 can request the holder 202 of the VC to prove that they are in possession of a claim asserting some property. For example, the verifier 206 may request that the holder 202 prove they are a student in a given university. Such a zero-knowledge proof can be constructed so that the holder 202 does not have to reveal the claim itself to the verifier 206. In the case of the university example, this would allow the student to demonstrate their student status at the university without revealing their name (or some other identifier that is traceable to the individual) to the verifier 206.

[0058] Figure 3 illustrates a first network node 10 in accordance with an embodiment. The first network node 10 is for performing the method described herein. In some embodiments, the first network node 10 referred to herein can refer to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with the device (e.g. the device 1404 of Figure 14) referred to herein, and / or with other nodes or equipment to enable and / or to perform the functionality described herein. In some embodiments, the first network node 10 referred to herein can, for example, be a physical node (e.g. a physical machine or server) or a virtual node (e.g. a virtual machine, VM).

[0059] As illustrated in Figure 3, the first network node 10 comprises processing circuitry (or logic) 12. The processing circuitry 12 controls the operation of the first network node 10 and can implement the method described herein in respect of the first network node 10. The processing circuitry 12 can be configured or programmed to control the first network node 10 in the manner described herein. The processing circuitry 12 can comprise one or more hardware components, such as one or more processors, one or more processing units, one or more multi-core processors and / or one or more modules. In particular implementations, each of the one or more hardware components can be configured to perform, or is for performing, individual or multiple steps of the method described hereinin respect of the first network node 10. In some embodiments, the processing circuitry 12 can be configured to run software to perform the method described herein in respect of the first network node 10. The software may be containerised according to some embodiments. Thus, in some embodiments, the processing circuitry 12 may be configured to run a container to perform the method described herein in respect of the first network node 10.

[0060] Briefly, the processing circuitry 12 of the first network node 10 is configured to receive a first request from a device 1404. The first request is a request for verification of the device 1404. The processing circuitry 12 of the first network node 10 is configured to obtain at least one first verifiable credential (VC) from the device 1404. The at least one first VC is signed with a first digital signature of an issuer entity of the at least one first VC. The processing circuitry 12 of the first network node 10 is configured to determine whether the first digital signature is verified using a first public key of the issuer entity. The first public key is obtained from a first database. The processing circuitry 12 of the first network node 10 is configured to, if the first digital signature is verified, determine whether the at least one first VC is verified. The at least one first VC is determined to be verified if the first database is associated with one or more trusted databases. The processing circuitry 12 of the first network node 10 is configured to, if the at least one first VC is verified, store a profile of the device 1404 in a verified device database. The profile comprises information identifying the device 1404, the at least one first VC, and a plurality of first information elements. The plurality of first information elements are obtained from the one or more trusted databases, and each first information element of the plurality of first information elements is indicative of an attribute of the device 1404 or an attribute of the issuer entity.

[0061] As illustrated in Figure 3, in some embodiments, the first network node 10 may optionally comprise a memory 14. The memory 14 of the first network node 10 can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory 14 of the first network node 10 may comprise a non-transitory media. Examples of the memory 14 of the first network node 10 include, but are not limited to, a random access memory (RAM), a read only memory (ROM), a mass storage media such as a hard disk, a removable storage media such as a compact disk (CD) or a digital versatile disk (DVD), and / or any other memory.The processing circuitry 12 of the first network node 10 can be communicatively coupled (e.g. connected) to the memory 14 of the first network node 10. In some embodiments, the memory 14 of the first network node 10 may be for storing program code or instructions which, when executed by the processing circuitry 12 of the first network node 10, cause the first network node 10 to operate in the manner described herein in respect of the first network node 10. For example, in some embodiments, the memory 14 of the first network node 10 may be configured to store program code or instructions that can be executed by the processing circuitry 12 of the first network node 10 to cause the first network node 10 to operate in accordance with the method described herein in respect of the first network node 10. Alternatively or in addition, the memory 14 of the first network node 10 can be configured to store any information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The processing circuitry 12 of the first network node 10 may be configured to control the memory 14 of the first network node 10 to store any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

[0062] In some embodiments, as illustrated in Figure 3, the first network node 10 may optionally comprise a communications interface 16. The communications interface 16 of the first network node 10 can be communicatively coupled (e.g. connected) to the processing circuitry 12 of the first network node 10 and / or the memory 14 of the first network node 10. The communications interface 16 of the first network node 10 may be operable to allow the processing circuitry 12 of the first network node 10 to communicate with the memory 14 of the first network node 10 and / or vice versa. Similarly, the communications interface 16 of the first network node 10 may be operable to allow the processing circuitry 12 of the first network node 10 to communicate with any one or more nodes (e.g. the device 1404) referred to herein and / or any other node. The communications interface 16 of the first network node 10 can be configured to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. In some embodiments, the processing circuitry 12 of the first network node 10 may be configured to control the communications interface 16 of the first network node 10 to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.Although the first network node 10 is illustrated in Figure 3 as comprising a single memory 14, it will be appreciated that the first network node 10 may comprise at least one memory (i.e. a single memory or a plurality of memories) 14 that operate in the manner described herein. Similarly, although the first network node 10 is illustrated in Figure 3 as comprising a single communications interface 16, it will be appreciated that the first network node 10 may comprise at least one communications interface (i.e. a single communications interface or a plurality of communications interfaces) 16 that operate in the manner described herein. It will also be appreciated that Figure 3 only shows the components required to illustrate an embodiment of the first network node 10 and, in practical implementations, the first network node 10 may comprise additional or alternative components to those shown.

[0063] Figure 4 is a block diagram illustrating a method performed by a first network node 10 in accordance with an embodiment. The first network node described earlier with reference to Figure 3 can be configured to operate in accordance with the method of Figure 4. The method can be performed by or under the control of the processing circuitry 12 of the first network node 10 according to some examples. The method can be a method for handling (e.g. verified) information associated with a device 1404. In some examples, the first network node 10 referred to herein may be a node of a provider of a network. For example, the first network node 10 referred to herein may be a communications service provider (CSP) node and / or a node of a CSP.

[0064] With reference to Figure 4, at block 302, a first request is received from a device 1404. The first request is a request for verification of the device 1404. In some examples, the request for verification of the device 1404 may comprise a request for a (e.g. device) verification service provided by the first network node 10. In some examples, the first network node 10 may be a trusted node of the device 1404. In some examples, the first network node 10 may be a trusted node of the device 1404 if the first network node 10 is (e.g. and / or is comprised in a system) configured to provide and / or handle communications for the device 1404. For example, the first network node 10 may correspond to a service provider of the device 1404. In some examples, the first network node 10 may be a mobile network operator node (e.g. that provides network connectivity to the device 1404). As such, the first network node 10 and the device 1404 may establish and / or maintain a trust infrastructure. In some examples, there may be a trust relationship between the first network node 10 and the device 1404 based on the connectivity (e.g. to the network) that the first network node 10 provides to the device1404. In examples in which the first network node 10 is a service provider for the device 1404, the first network node 10 may authenticate the device 1404. For example, providing a service to the device 1404 may comprise determining that the device 1404 is authentic. Therefore, in some examples, the device 1404 may be referred to herein as an authenticated device. In some examples, the first network node 10 may authenticate the device 1404 using a second digital signature, as referred to herein.

[0065] As illustrated at block 304 of Figure 4, at least one first VC is obtained from the device 1404. The at least one first VC may be any type of VC, as defined herein (e.g. as described with reference to Figure 1 and / or Figure 2). The at least one first VC is signed with a first digital signature of an issuer entity of the at least one first VC. Herein, the device 1404 may be referred to as a “holder” of the at least one first VC. The issuer entity may issue the at least one first VC to the device 1404. For example, the issuer entity may generate and / or provide the at least one first VC to the device 1404. In some examples, the device 1404 may (e.g. securely) store the at least one first VC (e.g. in a memory of the device 1404). In some examples, the issuer entity can be an entity of a manufacturer of the device 1404. In these examples, the at least one first VC may be issued during, and / or as a step of, manufacture of the device 1404. For example, the manufacturer of the device 1404 may generate a VC for each device that it manufactures (e.g. via the issuer entity). The at least one first VC may be associated with a manufacturer number of the device 1404. As mentioned above, the at least one first VC is signed with the first digital signature of the issuer entity. As such, in some examples, the at least one first VC may be integrity protected with the first digital signature and / or the at least one first VC may be cryptographically protected with the first digital signature. The first digital signature may be produced via a digital signature scheme.

[0066] As illustrated at block 306 of Figure 4, it is determined whether the first digital signature is verified using a first public key of the issuer entity. The first public key is obtained from a first database. The first database may be an external database (e.g. to the first network node 10). The first private key can correspond to the first public key, as defined herein. Determining whether the first digital signature is verified can comprise using the first public key to identify the identity of the issuer entity based on the first digital signature. In some examples, the identity of the issuer entity can be determined using the first public key. For example, the first public key may act as an identifier of the issuer entity. Information about the issuer may be obtained (e.g. from the one or more trusted databases referred to herein) using the first public key. In some examples, determiningwhether the first digital signature is verified can comprise verifying the first digital signature using the first public key. In some examples, determining whether the first digital signature is verified may comprise using a signature verifying algorithm. For example, the first network node 10 may use the signature verifying algorithm to accept or reject the authenticity of the first digital signature based on the first public key.

[0067] As illustrated at block 308 of Figure 4, if the first digital signature is verified, it is determined whether the at least one first VC is verified. The at least one first VC is determined to be verified if the first database, as referred to herein, is associated with one or more trusted databases. For example, the at least one first VC may be determined to be verified (e.g. authentic) if the first database corresponds (e.g. belongs) to a database of the one or more trusted databases. Since the first public key is obtained from the first database, the first network node 10 can determine that the issuer entity, and thus the at least one first VC, can be trusted. In some examples, the first network node 10 may determine that the one or more trusted databases are verified and / or authentic (e.g. based on a verification procedure). In some examples, the one or more trusted databases can comprise a device registry. The device registry may be a device specific registry (e.g. of a device manufacturer). In some examples, the first database may be a device registry. The first database (e.g. device registry) may comprise a plurality of databases. For example, the first database (e.g. device registry) may be configured based on decentralised ledger technology (DLT). The one or more trusted databases may comprise a plurality of device registries. One or more of the device registries of the plurality of device registries may be configured to exchange information. For example, the one or more device registries may exchange information using interledger technology. In some examples, the one or more trusted databases may comprise at least one database of a government agency. For example, the one or more trusted databases can comprise a database of a government organisation that administers a registration for the device 1404. The at least one database of a government agency may comprise, for example, a database of a department of motor vehicles (DMV).

[0068] As illustrated at block 310 of Figure 4, if the at least one first VC is verified, a profile of the device 1404 is stored in a verified device database. The profile comprises information identifying the device 1404, the at least one first VC, and a plurality of first information elements. The plurality of first information elements is obtained from the one or more trusted databases, as defined herein, and each first information element of the plurality of first information elements is indicative of an attribute of the device 1404 or anattribute of the issuer entity. As such, the first network node may (e.g. upon authentication of the at least one first VC) add the at least one first VC (e.g. as comprised in the device profile) to a verified device database. In some examples, the verified device database may be queried (e.g. by one or more other entities, nodes, and / or devices) for information about (e.g. certain attributes of) the device 1404 referred to herein. The information identifying the device 1404, as referred to herein, may comprise (e.g. network) subscription information associated with the device 1404.

[0069] In some examples, the plurality of first elements may need to meet a particular criterion for the profile of the device 1404 to be stored. For example, the plurality of first information elements may need to be indicative of a minimum set of attributes of the device 1404 and / or the issuer entity, as defined herein, before a profile can be generated and / or stored. By generating and / or storing a profile when a minimum set of information elements are obtained, the first network node 10 can create a set of attributes of the device 1404 and / or the issuer entity that validate the identity and / or trustworthiness of the device 1404 for a specific scenario.

[0070] The verified device database may be a database of the first network node 10. In some examples, the verified device database may comprise information associated with one or more devices that are verified by the first network node 10. For example, the verified device database may comprise information indicative of any device which has (e.g. successfully) requested verification (e.g. to the first network node 10). The verified device database may be accessible via the first network node 10. In some examples, the verified device database may comprise a (e.g. device) directory. For example, the verified device database may comprise a directory that is configured to be searched. The verified device database may enable search of information (e.g. device services and / or consent information) comprised in the verified device database. The verified device database may comprise a device directory that can be accessed publicly and / or through limited access control (e.g. using certain types of devices and / or subscriptions). The verified device database may expose capabilities of devices (e.g. verified by the first network node 10). The verified device database may comprise other information, such as references to device location and / or device service conditions.

[0071] In some examples, the attribute of the device 1404, as referred to herein, may comprise one or more of an identifier of the device 1404, a subscription that the device 1404 has to a network, an identifier of the subscription, an attribute of the subscription, a locationof the device 1404, an owner of the device 1404, a user of the device 1404, a role of the device 1404, a state of the device 1404, a category of the device 1404, and a type of the device 1404. In some examples, the identifier of the device 1404 can comprise an international mobile subscriber identity, IMSI, of the device 1404. In some examples, the identifier of the device 1404 may comprise a subscription permanent identifier (SlIPI) (e.g. in scenarios in which the device 1404 is connected to a fifth generation (5G) network). In some examples, the identifier of the network may comprise a public key of the device 1404, a decentralised identifier (DID) of the device 1404, and / or a manufacturer identity (MID) of the device 1404.

[0072] In some examples, the attribute of the issuer entity, as referred to herein, may comprise one or more of an identifier of the issuer entity, a location of the issuer entity, and a database associated with the issuer entity. The identifier of the issuer entity can comprise for example, a name of the issuer entity, a public key of the issuer entity, a DID of the issuer entity, a business ID associated with the issuer entity, and / or an identifying number associated with the issuer entity (e.g. a value added tax (VAT) ID). In some examples, the plurality of first information elements referred to herein can comprise a data schema corresponding to the at least one first VC. In some examples, the data schema can comprise information for verifying the at least one first VC.

[0073] In some examples, the first network node 10 referred to herein can be one or more of a node of a service provider of a (e.g. 5G) telecommunications network, a node of a communications service provider of the telecommunications network, and a node of an operator of the telecommunications network. The device 1404, as referred to herein, may be one or more of a wireless device, a user equipment (UE), a vehicle (e.g. a drone), and a camera. The device 1404 can have a network subscription (e.g. to the network to which the first network node 10 is associated). For example, in scenarios in which the first network node 10 provides a network service to the device 1404, the device 1404 may have (e.g. store) a network subscription to the network of the first network node 10.

[0074] Therefore, in the manner described above, in response to a request for verification of the device 1404, the first network node 10 can fetch information (e.g. the plurality of first information elements) about the device 1404 from different sources (e.g. the one or more trusted databases). The first network node 10 may then verify the obtained information (e.g. the at least one first VC) and associate the information with the device1404 (e.g. owner of the information) in a profile saved to a verified device database. As such, another entity (e.g. a user of the verified device database) can request the device information and be provided (e.g. by the first network node 10) with verified device information. In this way, the first network node 10 can facilitate trust among different entities by acting as a trust channel (anchor).

[0075] Figures 5 and 6 are block diagrams illustrating attributes associated with a device 1404 according to some embodiments. As illustrated in Figure 5, in some examples, the device 1404 referred to herein may be a device associated with a vehicle, such as a car. For example, the device 1404 referred to herein may be and / or may be comprised in a car. As illustrated in Figure 6, the device 1404 referred to herein may be a UE or wireless device, such as a camera. For example, the device 1404 referred to herein may be and / or may be comprised in a camera. Although the examples illustrated in Figures 5 and 6 describe the device 1404 as a vehicular device and a camera, respectively, it will be understood that these are merely examples, and that the device 1404 may be any other type of device, as defined herein. As described herein (e.g. with reference to Figure 1), a VC may be associated with a property of a holder of the VC. As such, in some examples, the at least one first VC of the device 1404, as referred to herein, may be associated with an attribute of the device 1404. For example, the at least one first VC may be associated with a claim involving an attribute of the device 1404, as defined herein.

[0076] As described herein, the attribute of the device 1404 may comprise an identifier of the device 1404. As illustrated at blocks 500 and 504 of Figure 5, and at blocks 600 and 602 of Figure 6, in some examples, the identifier of the device 1404 may comprise one or more of a subscriber identity module (SIM) identifier, an embedded SIM (eSIM) identifier, an IMSI, and an International Mobile Equipment Identity (IMEI). The device 1404 (e.g. that onboards cellular connectivity) may have a credential comprised (e.g. provided) in a eSIM or SIM card of the device 1404. The credential can be linked (e.g. tied) to a device owner (e.g. who owns an associated network connection). The credential may be used to establish a service where the first network node 10 can provide, to the device owner, possibilities to provide additional data (e.g. related to the device 1404), and / or tie the identity of the device 1404 to verified information (e.g. provided and certified by third parties).As illustrated at block 502 of Figure 5, and at block 620 of Figure 6, in some examples, the identifier of the device 1404 may be an identifier corresponding to (e.g. unique to) the first network node 10 (e.g. CSP). For example, the identifier of the device 1404 may comprise a uniform resource locator (URL) of the first network node 10. In some examples, the attribute of the device 1404 may comprise information indicative of a subscription that the device 1404 has to the network (e.g. of the first network node 10).

[0077] As also described herein, the attribute of the device 1404 may comprise a type of the device 1404 (e.g. device type). As illustrated at block 506 of Figure 5, in some examples, the device type may be a vehicle, such as a car (e.g. with car registration number ZKA-987). As illustrated at block 604 of Figure 6, in some examples, the device type may be a camera (e.g. with a hardware ID (Hwld) 23423-23423-233). The camera may be a security camera according to some examples. In some examples, the attribute of the device 1404 may comprise an owner of the device 1404. As illustrated at block 508 of Figure 5, and at block 616 of Figure 6, in some examples, the owner of the device may correspond to a name of the owner (e.g. “Joe Doe”) and / or an identifier of the owner (e.g. ld:00019192923).

[0078] As illustrated at block 510 of Figure 5, in some examples, the attribute of the device 1404 may comprise information indicative of an entity that provides the device 1404 with an identifier. For example, in the scenario in which the device 1404 is a car, the attribute may be indicative of a traffic registry that provides the car with an ID (e.g. registration number). In some examples, the attribute of the device 1404 may comprise a category of the device 1404. As illustrated at block 512 of Figure 5, and at block 612 of Figure 6, in some examples, the category of the device 1404 can comprise a (e.g. car) brand of the device 1404, and / or one or more specifications of the device 1404. In some examples, the attribute of the device 1404 may comprise a manufacturer of the device 1404. For example, as illustrated at block 514 of Figure 5, and at block 610 of Figure 6, the attribute of the device 1404 may comprise a manufacturer name and / or a uniform resource locator (URL) associated with the manufacturer of the device 1404.

[0079] As described herein, in some examples, the attribute of the device 1404 may comprise a user of the device 1404. As illustrated at block 516 of Figure 5, in some examples, the user of the device 1404 may correspond to a name of the user (e.g. “Jane Doe”) and / or an identifier of the user (e.g. ld:00019152924). As illustrated at block 520 of Figure 5, and at block 618 of Figure 6, the attribute of the device 1404 may be indicative of aregistry which provides and / or stores device user information and / or device owner information. As illustrated at block 518 of Figure 5, in some examples, the attribute of the device 1404 may be indicative of an entity that is responsible for providing the device 1404 to the user. For example, in the scenario in which the device 1404 is a car, the attribute of the device 1404 may be indicative of a leasing company of the car.

[0080] As illustrated at block 606 of Figure 6, in some examples, the attribute of the device 1404 may be indicative of one or more (e.g. connected) services of the device 1404. For example, as illustrated in Figure 6, the attribute of the device 1404 may be indicative that the device 1404 is configured to perform storage (e.g. of data) in a cloud network. As illustrated by block 608 of Figure 6, in some examples, the attribute of the device 1404 may be indicative of an entity associated with the one or more (e.g. connected) services of the device 1404. For example, the attribute may be indicative of an entity that is responsible for providing the one or more services to the device 1404 (e.g. “Hyperscaler”). As illustrated at block 614 of Figure 6, in some examples, the attribute of the device 1404 may comprise a location of the device 1404 (e.g. an address and / or a location of the device 1404).

[0081] As is illustrated by Figures 5 and 6, device information (e.g. device type, device properties, and / or device roles) can vary significantly depending on the device 1404 itself. It is therefore convenient to be able to store multiple information elements in a single profile of the device 1404, as described herein. In this way, the profile of the device 1404 can (e.g. accessibly) store information indicating if the device 1404 is, for example, a car or a camera, and / or if the device 1404 is used by a device owner and / or another user. In some examples, the profile of the device 1404 can also comprise information indicative of a certification chain of an attribute of the device 1404. In this way, the profile of the device 1404 can store information which indicates which entities have vouched for the information that is available in the profile. Therefore, in some examples, the profile of the device 1404 can store a chain of certificates that can be used to electronically provide proof of device attributes (e.g. identities and roles). In this way, greater trust in the verified device database, as defined herein, and in the operation of the first network node 10, is provided.

[0082] Figure 7 is a flow chart illustrating process steps in a further example of a method performed by the first network node 10. The steps of the method of Figure 7 illustrate example ways in which the steps of the method, as described with reference to Figure4, may be implemented and supplemented in order to achieve the above discussed and additional functionality.

[0083] In some examples, the at least one first VC can be (e.g. cryptographically) signed with a second digital signature of the device 1404. The second digital signature may be a digital signature of the device 1404. For example, the second digital signature may be generated using a private key of the device 1404. Although not explicitly illustrated in Figure 7, in some examples, the device 1404 can generate the second digital signature using the private key of the device 1404. The at least one first VC being signed with both the first digital signature, as referred to herein, and the second digital signature, may be referred to as verifiable presentation (VP).

[0084] As illustrated at block 702 of Figure 7, in some examples, the method may comprise determining whether the second digital signature is verified using a second public key of the device 1404. The second public key can be a key that corresponds to (e.g. is paired with) the private key of the device 1404. In general, a private key and a (corresponding) public key may be generated using one or more cryptographic algorithms (e.g. based on one-way functions). For example, the device 1404 referred to herein may generate the private key of the device and the second public key (e.g. using the one or more cryptographic algorithms).

[0085] The second public key may, for example, be comprised in the at least one first VC, as defined herein. In these examples, obtaining the at least one VC can comprise obtaining the second public key from the device 1404. Determining whether the second digital signature is verified may comprise determining whether the entity which provided the at least one first VC to the first network node 10 is the owner of the at least one first VC. Although not illustrated in Figure 7, in some examples, the first network node 10 may provide the device 1404 with a challenge (e.g. a random value). As such, the device 1404 can receive the challenge from the first network node 10. In some examples, the device 1404 may sign the VC and the challenge together (e.g. with the second digital signature). In these examples, obtaining the at least one first VC may comprise obtaining the at least one first VC together with a signed version of the challenge from the device 1404. For example, the first network node 10 may obtain the at least one first VC and the signed version of the challenge in the same message. The challenge may be signed with the second digital signature, as defined herein, to provide additional proof that the device 1404 is in fact the holder of the at least one first VC.As illustrated at block 704 of Figure 7, if each of the first digital signature and the second digital signature are verified, then the method may proceed to block 706 of Figure 7. As illustrated at block 706 of Figure 7, in some examples, the method may comprise determining whether the at least one first VC is verified (e.g. as described with reference to Figure 4). For example, the determination of whether the at least one first VC is verified may only be performed if each of the first digital signature, as defined herein, and the second digital signature, as defined herein, are verified. Thus, in some examples, the at least one first VC may only be verified if both the first and second digital signatures are verified.

[0086] Figure 8 is a flow chart illustrating process steps in a further example of a method performed by the first network node 10. The steps of the method of Figure 8 illustrate example ways in which the steps of the method, as described with reference to Figures 4 and / or 7, may be implemented and supplemented in order to achieve the above discussed and additional functionality.

[0087] As illustrated at block 802 of Figure 8, the first network node 10 obtains the at least one first VC from the device 1404, as defined herein. As illustrated at block 804 of Figure 8, in some examples, obtaining the at least one first VC may comprise initiating transmission of a second request towards the device 1404. Herein, the term “initiate” can mean, for example, cause or establish. Thus, the first network node 10 (e.g. the processing circuitry 12 of the first network node 10) can be configured to itself transmit the second request (e.g. via the communications interface 16 of the first network node 10) or can be configured to cause another entity to transmit the second request. The second request can be a request for information associated with the device 1404. As illustrated at block 806 of Figure 9, in some examples, a first response can be received from the device 1404. The first response can comprise the at least one first VC, as defined herein.

[0088] Figure 9 is a flow chart illustrating process steps in a further example of a method performed by the first network node 10. The steps of the method of Figure 9 illustrate example ways in which the steps of the method, as described with reference to Figures 4, 7, and / or 8, may be implemented and supplemented in order to achieve the above discussed and additional functionality.As illustrated at block 902 of Figure 9, in some examples, one or more third information elements may be obtained (e.g. received by the first network node 10). The one or more third information elements can be indicative of a capability and / or a functionality of the device 1404. For examples, the one or more third information elements can be indicative of a service and / or a function that is provided by the device 1404. In scenarios in which the device 1404 is, and / or is comprised in, a vehicle, the one or more third information elements may be indicative of a function that the vehicle is able to perform, such as ploughing snow. In some examples, the profile of the device 1404 can comprise the one or more third information elements. For example, the first network node 10 may store the one or more third information elements in the profile of the device 1404 (e.g. along with the plurality of first information elements). The one or more third information elements can be received from the device 1404. Alternatively, or in addition, the one or more third information elements can be received from the one or more trusted databases. In some examples, the one or more third information elements can be comprised in the first response, as defined herein (e.g. with respect to Figure 8).

[0089] In some examples, obtaining the one or more third elements may comprise obtaining permission information. The permission information and the one or more third information elements can be obtained simultaneously (e.g. in the first response, as defined herein). For each third information element of the one or more third information elements, the permission information can be indicative of whether the first network node is allowed to share the third information element. For example, each third information element of the one or more third information element can be associated with a corresponding (e.g. sharing) permission. The first network node 10 may use the permission information to determine which of the one or more third information elements it is able to share (e.g. expose via the device profile). The permission information can be indicative of what permission the first network node 10 has to expose the capability and / or functionality of the device 1404 (e.g. to a requesting entity). For example, the one or more third information elements may be indicative that the device 1404 is capable of ploughing snow (e.g. in scenarios in which the device 1404 is a vehicle). In this example, the permission information may indicate that the first network node 10 is, or is not, allowed to provide this capability information to a requesting entity (e.g. of the first network node 10).

[0090] Figure 10 is a flow chart illustrating process steps in a further example of a method performed by the first network node 10. The steps of the method of Figure 10 illustrateexample ways in which the steps of the method, as described with reference to Figures 4, 7, 8, and / or 9, may be implemented and supplemented in order to achieve the above discussed and additional functionality.

[0091] As illustrated with reference to block 1002 of Figure 10, the first network node 10 stores a profile of the device 1404 in a verified device database, as defined herein. As illustrated at block 1004 of Figure 10, in some examples, a third request may be received from a second network node. The second network node can be referred to herein as a requesting entity. The second network node may be comprised in (e.g. connected to) the network of the first network node 10. The third request can be for information indicative of one or more network entities that meet a first criterion. The first criterion may be associated with an attribute, a capability, and / or a functionality of the one or more network entities. For example, a network entity of the one or more network entities may be considered to meet the first criterion if the network entity is located in a particular geographical area (e.g. within a first distance of a first location), and / or is capable of ploughing snow.

[0092] As illustrated at block 1006 of Figure 10, in some examples, the first network node 10 can determine whether the device 1404 meets the first criterion based on the stored profile of the device 1404 (e.g. based on the one or more first information elements, as defined herein, and / or the one or more third information elements, as defined herein). Thus, in some examples, the first network node 10 may use the profile of the device 1404 to determine (e.g. check) whether the device 1404 meets the first criterion. As also illustrated at block 1006 of Figure 10, if the device 1404 meets the first criterion, the method may proceed to block 1008. As illustrated at block 1008 of Figure 10, transmission of one or more second information elements may be initiated towards the second network node. The one or more second information elements may be obtained from the profile of the device 1404, as defined herein. For example, the one or more second information elements may comprise at least one first information element of the one or more first information elements, as defined herein, and / or at least one third information element of the one or more third information elements, as defined herein. The one or more second information elements may be associated with the first criterion, as defined herein. For example, the one or more second information elements may be indicative (e.g. provide proof) that the device 1404 meets the first criterion.As described with reference to blocks 1004 to 1008 of Figure 10, the first network node 10 may be configured to act as a directory for a requesting device (e.g. the second network node). The second network node may utilise the first network node 10 to identify, and / or provide information associated with, devices that meet the first criterion. The device 1404 may meet the first criterion if the device 1404 is associated with a particular combination of attributes / characteristics (e.g. as indicated by the stored profile of the device 1404). For example, in a scenario in which the second network node corresponds to a car stuck in a snowed-in driveway, the first criterion may be met if the device 1404 is capable of ploughing snow and is within 1 mile of the location of the second network node. In this way, the first network node 10 can be configured to perform device identity verification and information gathering from one or more trusted sources (e.g. the one or more trusted databases), and act as a trusted registry (e.g. for requesting entities). As such, the first network node 10 can be configured to provide (e.g. registry) services such as device discovery with certain functional device capabilities (e.g. based on service requests).

[0093] As illustrated at block 1010 of Figure 10, in some examples, the first network node 10 may receive a request to communicate with the device 1404 from the second network node. As illustrated at block 1012, of Figure 10, in response to receiving the request to communicate with the device 1404, the first network node 10 may operate as a communication proxy between the device 1404 and the second network node. In this way, the first network node 10 can not only verify the device 1404, but also provide a secure channel for the device 1404 to establish trust with the second network node (e.g. another device). This manner of operation of the first network node provides secure (e.g. data) communication, as the first network node 10 can utilise the verified device database, as defined herein, to access device information requested by the second network node.

[0094] As an example of the process illustrated in Figure 10, the device 1404 can verify (e.g. register) itself and its attributes with the first network node. In this example, the device 1404 and / or the attributes of the device 1404 can be then made available for querying via the first network node 10. For example, the first network node 10 may provide an interface through which the second network node, as defined herein, can attempt to search (e.g. find) device(s) with suitable attributes to interact with. By operating as a communication proxy the first network node 10 can enhance communication security by not enabling direct interaction between the device 1404 and the second network node.In this way, the first network node 10 can protect certain (e.g. confidential) information associated with the device 1404. The information that the first network node is unable to share (e.g. with the second network node) may be indicated by the permission information, as defined herein. For example, although location information may be present in the profile of the device 1404, the first network node may refuse to reveal the (e.g. topological) location of the device 1404 (e.g. via IP address) based on the permission information. Moreover, by operating as a communication proxy, the first network node 10 can be configured to limit the rate of traffic and / or connection attempts experienced by the device 1404 (e.g. from the second network node). In this way, the first network node can prevent denial-of-service (DoS) attacks targeting the device 1404. By acting as a communication proxy, and in examples in which the first network node 10 provides network connection for the device 1404, the first network node 10 can provide guaranteed communication between the device 1404 and the second network node (e.g. as the first network node 10 is responsible for relaying network traffic to the device 1404).

[0095] Furthermore, the first network node 10 can efficiently access the profile of the device 1404 (e.g. in the verified device database). The second network node can therefore trust that it is indeed communicating with a device with the desired attributes (e.g. meeting the first criterion, as defined herein). In some examples, the first network node 10 can leverage information stored in the profile of the device 1404, such as location, when providing a service to the device 1404, and / or the second network node. In some examples, the device 1404 may (e.g. after initial contact from the second network node via the first network node 10) choose to establish a direct connection to the second network node (e.g. bypassing the proxy provided by the first network node 10). In some examples, the first network node 10 may obtain (e.g. receive) connectivity information from the second network node. The connectivity information may, for example, be used to establish a (e.g. network) connection with the second network node. The first network node 10 may provide (e.g. transmit) the connectivity information to the device 1404. As such, in these examples, the device 1404 can contact the second network node based on the provided connectivity information. Direct contact between the device 1404 and the second network node can enhance communication security, as the communicated data is not shared with an additional (e.g. external) proxy entity (i.e. the first network node 10). In some examples, the first network node 10 may determine whether the connectivity information is verified (e.g. before forwarding it to the device 1404). In this way, the first network node 10 is able to prevent a malicious connecting device redirecting traffic to a victim (e.g. the device).In a specific example, the device 1404 can be, and / or can be comprised in, a snowplough device, and the second network node can be a car. In this example, the car may leave from home to work at the same hour every day. The car may detect that there is too much snow in the way of a parking lot in which the car is parked. The car may then send a third request, as defined herein, towards the first network node 10 to find a snowplough device that is close by and that can provide a cleaning function for the parking lot. The first network node 10 can identify (e.g. find) the snowplough device using the stored profile of the snowplough device, and handle the communication between the car and the snowplough device. As such, the first network node can facilitate trust between the communicating entities. In this way, the snowplough can be assured that the car is making a legitimate (e.g. and not fraudulent) request for provision of a function.

[0096] In some examples, the third request, as referred to herein, can be received using an application programming interface (API). Alternatively, or in addition, transmission of the one or more second information elements, as defined herein, may be initiated using the API. The API may be provided by the first network node 10. For example, the first network node 10 may provide the API as an API that is accessible over-the-top, or embedded in network call functionality. In some examples, the first network node 10 may be one of a plurality of first network nodes. In these examples, the first network node 10 can be configured to host (e.g. together with the other first network nodes of the plurality of first network nodes) a database of relationship data that is accessible through the API. The relationship database can be implemented by decentralized means, for example, using ledger technologies. The API can be configured to allow entities to query relationship data. For example, the entities may be able to query different certifications that are registered in the relationship database and / or allow access to certifications that are provided by other first network nodes of the plurality of first network nodes. The API referred to herein may be a query API.

[0097] Figure 11 is a flow chart illustrating process steps in a further example of a method performed by the first network node 10. The steps of the method of Figure 11 illustrate example ways in which the steps of the method, as described with reference to Figures 4, 7, 8, 9, and / or 10, may be implemented and supplemented in order to achieve the above discussed and additional functionality.As illustrated at block 1102 of Figure 11 , the first network node 10 can obtain the plurality of first information elements, as defined herein, from the one or more trusted databases, as defined herein. As illustrated at block 1104 of Figure 11 , in some examples, obtaining the plurality of first information elements may comprise initiating transmission of a request for information indicative of the device 1404 to the one or more trusted databases. As illustrated at block 1106 of Figure 11, in some examples, obtaining the plurality of first information elements may comprise receiving the plurality of first information elements from the one or more trusted databases. For example, at least one first information element may be received from at least one trusted database.

[0098] Figure 12 is a flow chart illustrating process steps in a further example of a method performed by the first network node 10. The steps of the method of Figure 12 illustrate example ways in which the steps of the method, as described with reference to Figures 4, 7, 8, 9, 10 and / or 11, may be implemented and supplemented in order to achieve the above discussed and additional functionality.

[0099] As illustrated at block 1202 of Figure 12, in some examples, the first network node 10 may generate the profile of the device 1404, as defined herein. Generating the profile of the device 1404 may comprises creating a new profile of the device 1404, or updating an existing profile of the device 1404. Updating the existing profile of the device 1404 may comprise adding, removing, and / or modifying device profile information (e.g. the at least one first VC, the one or more first information elements, and / or one or more third information elements). As illustrated at block 1208 of Figure 12, the (e.g. generated) profile of the device 1404 is stored in a verified device database. The profile of the device 1404 can be generated to comprise information indicative of verified (e.g. device based) attributes of the device 1404 and / or communication network attributes associated with the device 1404. In this way, the generated profile can create a dynamic identity of the device 1404 for a specific scenario and / or purpose.

[0100] Figure 13 is a flow chart illustrating process steps in a further example of a method performed by the first network node 10. The steps of the method of Figure 13 illustrate example ways in which the steps of the method, as described with reference to Figures 4, 7, 8, 9, 11, and / or 12, may be implemented and supplemented in order to achieve the above discussed and additional functionality.As illustrated at block 1302 of Figure 13, the first network node 10 determines whether the at least one first VC is verified (e.g. as described with reference to Figure 4). As illustrated at block 1304 of Figure 13, in some examples, if the at least one first VC is verified, the method may proceed to block 1306 of Figure 13. As illustrated at block 1306 of Figure 13, in some examples, transmission of a first message may be initiated towards the device 1404. The first message can comprise an indication that the verification of the device 1404 is successful. For example, the first message can indicate that the request for verification, as mentioned herein, has been completed successfully. In some examples, the first message may comprise a second VC for the device 1404. The second VC can be issued by the first network node 10. The second VC can be associated with information verified by the first network node 10. For example, the second VC can be associated with information obtained (e.g. by the first network node 10) from the one or more trusted databases, as defined herein.

[0101] Figure 14 is a signaling diagram illustrating an exchange of signals in a system (e.g. network) according to an embodiment. As illustrated in Figure 14, the system comprises a first network node 10 (“CSP”), as described herein, and a device 1404, as described herein. As illustrated in Figure 14, in some examples, the device 1404 can be a car and / or a camera. As also illustrated in Figure 14, the system may comprise an issuer entity 1402 (“Manufacturer”), and one or more trusted databases 1406, 1408. In some examples the issuer entity may be an entity of a manufacturer of the device 1404. As described herein, the device 1404 can be issued with the at least one first VC, as defined herein, by the issuer entity 1402. As also illustrated in Figure 14, the one or more trusted databases 1406, 1408 can comprise a first database 1406. The first database 1406 may be a device registry (“Device Specific Registry”). As also illustrated in Figure 14, in some examples, the one or more trusted databases 1406, 1408 may comprise a database of a government agency (“Government Database”). In some examples, the device 1404 may have a network subscription to the network illustrated in Figure 14. The network subscription may be provided by the first network node 10, according to some examples.

[0102] As illustrated by arrow 1410 of Figure 14, in some examples, the issuer entity 1402 may register at the first database 1406. As such, the issuer entity 1402 (e.g. device manufacturer) may be registered at the first database 1406. For example, the issuer entity 1402 may be a registered device manufacturer. In some examples, the issuer entity 1402 may provide one or more first information elements to the first database 1406. The one or more first information elements can be indicative of an attribute of the issuerentity 1402. The attribute of the issuer entity 1402 can include, for example, an identifier of the issuer entity 1402 (e.g. a DID of the issuer entity 1402), a location (e.g. address) of the issuer entity 1402, a public key of the issuer entity 1402, and / or a database (e.g. the first database 1406) associated with the issuer entity 1402. For example, the attribute of the issuer entity 1402 may be a name of the issuer entity 1402, and / or an identifying number of the issuer entity 1402, such as a business ID and / or a VAT ID. The issuer entity 1402 can provide the first public key, as defined herein, to the first database 1406. Registering at the first database 1406 may comprise providing the first public key to the first database 1406 (e.g. for storage at the first database 1406).

[0103] In some examples, at least some of the information provided to the first database 1406 may be assigned to the issuer entity 1402, and / or verified, by a government registry. In some examples, an issuer entity which does not provide assigned and / or verified information to the first database 1406 may not be permitted to register at the first database 1406.

[0104] As illustrated by arrow 1412 of Figure 14, the issuer entity 1402 may provide (e.g. issue) at least one first VC to the device 1404. The at least one first VC may comprise at least one device VC (D-VC). In the context of VCs, the issuer entity 1402 can be referred to as the issuer of the at least one first VC, and the device 1404 can be referred to as the holder of the at least one first VC. In examples in which the issuer entity 1402 is a manufacturer, the issuer entity 1402 may provide (e.g. issue) at least one VC to each device that it manufactures. The at least one first VC, as defined herein, may be associated with an attribute of the device 1404, as described herein. For example, the at least one first VC may be associated with a type of the device 1404, a category of the device 10, and / or an ID of the device 1404.

[0105] As mentioned herein, the at least one first VC is signed with a first digital signature of the issuer entity 1402. The first digital signature may be generated using a private key of the issuer entity 1402. As such, the information associated with the at least one first VC may be signed using the private key of the issuer entity 1402 (e.g. manufacturer). The first digital signature can form a digital signature of the credential(s) of the at least one first VC. The first public key, as referred to herein (e.g. associated to the first digital signature), can be stored in the first database 1406 (e.g. device specific registry). In this way, the first network node 10 is able to access the first database 1406 in an attempt to verify the authenticity of information associated with the at least one first VC.As mentioned herein, the issuer entity 1402 may provide one or more first information elements to the first database 1406. In some examples, the one or more first information elements can comprise a data schema corresponding to the at least one first VC. As such, in some examples (e.g. following the issuance of the at least one first VC) the issuer entity 1402 may publish a data schema to the first database 1406. Data schemas can vary across different issuer entities (e.g. manufacturers). An example data schema is illustrated below:

[0106] {

[0107] "type": ["VerifiableCredential", "Deviceinfo"],

[0108] "issuer": "https: / / abc.enterprise / issuers / 565049",

[0109] "credentialSubject": {

[0110] "id": "did:abcdevice:offeq1f712ebc6f1c276e12ec21",

[0111] "manufacturer": "abc",

[0112] "category": "transport",

[0113] "type": "truck",

[0114] },

[0115] "proof": {

[0116] "type": "DatalntegrityProof",

[0117] "cryptosuite": "eddsa-2022",

[0118] "created": "2023-09-01 T21:19:10Z",

[0119] "proofPurpose": "assertionMethod",

[0120] "verificationMethod": "https: / / abc.enterprise / issuers / 565049#key-123", "proofValue":

[0121] "zQeVbY4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYV8nQApmEc qaqA3Q1 gVHMrXFkXJeV6doDwLWx"

[0122] }

[0123] }

[0124] As illustrated in the example of the data schema above, the data schema can comprise a plurality of data fields and / or data elements. For example, the data field “type” can comprise information of what the data schema corresponds to. As illustrated in theexample data schema above, the data field “type” is indicative that the data schema relates to a VC (“VerifiableCredential”) and information about a device (“Deviceinfo”).

[0125] As also illustrated in the above example, the data schema can comprise a data field “issuer” indicative of an identity of the issuer entity. In the example data schema above, the identifier of the issuer entity is a URL (“https: / / abc.enterprise / issuers / 565049”). As illustrated in the above example, the data schema can comprise a data field “credentialSubject” indicative of information about the device. For example, as shown above, the information about the device can comprise an identifier (“id”) of the device, an identifier of a manufacturer (“manufacturer”) of the device, a category (“category”) of the device, and a type (“type”) of the device. In the data schema above, the device category is “transport” and the device type is “truck”.

[0126] As illustrated in the above example, the data schema can comprise a data field comprising a proof (“proof”). As described herein (e.g. with reference to Figure 1), the proof can correspond to a digital signature of the issuer of a VC (e.g. the first digital signature referred to herein). As such the proof data field of the data schema can comprise information / data that can be used to verify the authenticity and integrity of a VC.

[0127] As illustrated at block 1414 of Figure 14, the device 1404 may store the at least one first VC. In some examples, the device 1404 may comprise an application supporting VCs (e.g. D-VCs). The application can be deployed on the device 1404 (e.g. prior to receiving the at least one first VC). In some examples, the at least one first VC may be stored on the device 1404 using a Universal Subscriber Identity Module (USIM) Application Toolkit (USAT) (e.g. using a short message service point to point (SMS-PP) data download).

[0128] As also illustrated at block 1414 of Figure 14, in some examples, the device 1404 may store information indicative of one or more attributes of the device 1404. In some examples, the device 1404 may store the second public key of the device, as defined herein. As illustrated by arrow 1416 of Figure 14, in some examples, the device 1404 may register to a database of the one or more trusted databases 1406, 1408. For example, as illustrated in Figure 14, the device 1404 may register to a database of a government agency 1408 (e.g. a DMV database). Registration of the device 1404 may comprise the device 1404 providing information associated with the device 1404, such as a device ID, a device type, a device category, one or more device capabilities, and / orinformation associated with an owner and / or user of the device. For example, in scenarios in which the device 1404 is a vehicle, the information provided by the device 1404 may comprise a vehicle brand, vehicle type, vehicle capability, and / or a vehicle identification number (VIN). The information can be stored in the (e.g. DMV) database of the one or more trusted databases. Depending on the device type and / or device capability, the information registered by the device 1404 may need to be registered to a database of a government agency and / or a database regulator. The information stored in the one or more trusted databases 1406, 1408 can be collected by the first network node 10 and combined with the at least one first VC to generate the profile of the device 1404, as defined herein.

[0129] As illustrated by arrow 1418 of Figure 14, the device 1404 can initiate transmission of a first request, as defined herein, towards the first network node 10. Thus, the first network node 10 receives the first request from the device 1404. The first request is a request for verification of the device 1404. Thus, the device 1404 can request to register to the device verification service of the first network node 10 (e.g. CSP). In some examples, the device 1404 may have a network subscription and / or a mobile subscription. The network subscription and / or mobile subscription may be provided by the issuer entity 1402 (e.g. a manufacturer) or an owner of the device 1404.

[0130] As illustrated by arrow 1420 of Figure 14, the first network node 10 can initiate transmission of a second request, as defined herein, towards the device 1404. Thus, the device 1404 can receive the first request from the first network node 10. In this way, the first network node 10 can request the device for its information and credentials (e.g. VC). As illustrated by arrow 1422 of Figure 14, the device 1404 can initiate transmission of a first response (e.g. to the first request), as defined herein, towards the first network node 10. Thus, the first network node 10 can receive the first response from the device 1404. The first response can comprise the at least one first VC, as defined herein, and / or information associated with the device 1404. In some examples, the device 1404 may present (e.g. transmit) the at least one first VC to the first network node 10 via a SEND SMS function of the LISAT mentioned herein.

[0131] As described herein, in some examples, the first response can comprise one or more third information elements. The one or more third information elements can be indicative of a service and / or a capability associated with the device 1404. As such, the device 1404 can provide service and / or capability context to the first network node 10. The firstnetwork node 10 may determine, based on the one or more third information elements, a purpose of the device 1404. As described herein, obtaining the one or more third information elements can comprise obtaining permission information, as defined herein.

[0132] In a particular example, the device 1404 may be, and / or may be comprised in, a snowplough. To make it possible for other devices (e.g. cars) to contact the device 1404 (e.g. snowplough), the permission information may be indicative that the first network node 10 is allowed to share a third information element associated with a capability (e.g. snow cleaning) of the device 1404. The permission information may also be indicative of whether the first network node 10 is allowed to share (e.g. expose) other information associated with the device 1404. For instance, in the example of the snowplough device, the permission information may indicate that the first network node 10 is allowed to share location information of the device 1404. In some examples, the first network node 10 may use one or more APIs (e.g. a location service API) to obtain the (e.g. location) information associated with the device 1404.

[0133] The permission information, as referred to herein, can be indicative of relevant permissions associated with what information the first network node 10 is allowed to obtain (e.g. current location of the device 1404) and / or what information the first network node 10 is allowed to include in the profile of the device 1404. As such, the permission information can dictate what information is stored in the verified device database (e.g. service directory) and what (e.g. parts of the) information are searchable by other devices (e.g. the second network node referred to herein). In some examples, the permission information may be comprised in (e.g. be part of) the at least one first VC.

[0134] As illustrated by arrow 1424 of Figure 14, the first network node determines whether the at least one first VC is verified, as defined herein. For example, the first network node 10 can verify the credential(s) of the at least one first VC by verifying the first digital signature, as defined herein, using the first public key as defined herein, and / or verifying the second digital signature, as defined herein, using the second public key as defined herein. As illustrated by arrows 1426 to 1432 of Figure 14, the first network node 10 can obtain a plurality of first information elements, as defined herein, from the one or more trusted databases 1406, 1408. For example, as illustrated by arrow 1426 of Figure 14, the first network node 10 may initiate transmission of a request for information indicative of the device to the first database 1406. The request (“Get (lssuer)Manufacturer info”) can be for information about the issuer entity 1402 (e.g. manufacturer) associated withthe device 1404. As illustrated by arrow 1428 of Figure 14, the first network node 10 can receive one or more (e.g. a plurality of) first information elements from the first database 1406. The one or more first information elements received from the first database 1406 may comprise a first information element indicative of an attribute of the issuer entity 1402 (e.g. manufacturer name, country of origin, business ID, VAT ID, public key, and / or issuer entity address). In some examples, the first public key, as defined herein, can be obtained from the first database 1406. The first public key can be used to verify the first digital signature, as described herein. As also described herein, the at least one first VC is determined to be verified if the first database is associated with one or more trusted databases (e.g. as illustrated in Figure 14).

[0135] As illustrated by arrow 1430 of Figure 14, the first network node 10 may initiate transmission of a request for device information to the database of a government agency 1408. The request (“Get device info”) can be for any information associated with the device 1404. As illustrated by arrow 1432 of Figure 14, the first network node 10 can receive one or more (e.g. a plurality of) first information elements from the database of the government agency 1406. The one or more first information elements received from the database of the government agency 1406 may comprise information elements indicative of an attribute of the device 1404, such as device type, device category, device capability, and / or device owner. In the example illustrated in Figure 14, the one or more trusted databases 1406, 1408 comprise two databases. However, it will be understood that this is merely an example, and the one or more trusted databases can comprise any number of (e.g. multiple) databases. For example, the first network node 10 may request information about the device 1404 from other databases (e.g. a subscriber database), according to some examples.

[0136] As illustrated by arrow 1434 of Figure 14, the first network node 10 may combine (e.g. associate) all information elements (e.g. the plurality of first information elements and / or the one or more third information elements) associated with the device. The first network node 10 determines whether the at least one first VC is verified, as defined herein. If the at least one first VC is (e.g. determined to be) verified, the first network node 10 stores a profile of the device 1404 in a verified device database (e.g. of the first network node 10). The first network node 10 may store all information that is has obtained about the device 1404 in the profile of the device 1404. The profile may, for example, comprise information indicative of an eSIM of the device, a device user, and / or a device owner. As described herein, the plurality of first information elements are obtained from the oneor more trusted databases 1406, 1408. As such, the information stored in the profile of the device 1404 can be considered to be from a verifiable source. As mentioned herein, the first network node 10 may obtain permission information that is indicative of whether the first network node 10 is allowed to share one or more third information elements, as defined herein. The permission information may comprise information indicative of one or more of a security policy, a privacy policy, and / or a service agreement. The first network node 10 may determine what information comprised in the profile is searchable (e.g. by the second network node referred to herein) based on the permission information.

[0137] As illustrated by arrow 1436 of Figure 14, the first network node 10 can initiate transmission of a first message towards the device 1404. Thus, the device 1404 can receive the first message. The first message can comprise an indication that the verification of the device is successful. As such, the first network node 10 can send a success message to the device 1404. In some examples, the transmission of the first message may (e.g. only) be initiated if the at least one first VC is verified. In some examples, the first message can comprise a second VC for the device 1404, as defined herein. The second VC can be issued by the first network node 10. The second VC may be a CSP specific Device VC (CSP-D-VC). In some examples, the device 1404 may (e.g. securely) store the second VC (e.g. in a memory of the device 1404). In some examples, the second VC may be stored on the device in the LISAT referred to herein (e.g. using a SMS-PP data download). The second VC (e.g. CSP-D-VC) can be associated with (e.g. comprise) additional information related to network services (e.g. a location service, a geofencing service, and / or an identity verification service). The device 1404 may use the second VC to present verified information (e.g. to other network entities). In some examples, the second VC may be associated with (e.g. comprise) all (e.g. verified) device information that the first network node 10 has obtained (e.g. from trusted source(s)).

[0138] In some examples, the profile of the device may comprise information indicative of a state of the device 1404. The state of the device may, for example, indicate if the device 1404 is in use. for example, the state of the device may indicate that the device 1404 is unavailable (e.g. due to maintenance) and / or has ceased operational service. In this way, the first network node 10 may update the profile of the device with such information (e.g. periodically). In this way, the first network node 10 can maintain an updated verified device database (e.g. service directory). In some examples, the information indicativeof the state of the device 1404 can be provided by the device 1404. In some examples, the first network node 10 may (e.g. periodically) update device location information in the profile of the device 1404. The first network node 10 may perform the update based on determining a change in a location of the device 1404 (e.g. based on its own location services). In some examples, the verifiable device database (e.g. service directory) can operate in parallel with a VC platform to maintain verifiable and up-to-date profile information. The device 1404 may contact the first network node 10 (e.g. directory service) to provide updated information (e.g. through a portal and / or API call).

[0139] Access to the verified device database (e.g. service directory), as defined herein, can be provided (e.g. by the first network node 10) to third parties (e.g. requesting entities) in various ways. For example, the first network node (e.g. CSP) may provide an API. The API may receive verified device database queries. The API may receive the queries via a Layer 0 (L0) network exposure function (NEF), and / or an application layer (e.g. enabled as new 3GPP functionality). In some examples, the API may comprise a Layer 3 (L3) API (e.g. provided by an aggregator). The L3 API may encapsulate multiple (e.g. L0) APIs, thus enabling wider queries.

[0140] As described herein, the first network node 10 may, based on a query (e.g. such as the third request defined herein), provide (e.g. search) results (e.g. the one or more second information elements defined herein) matching the query. The results may comprise information indicative of a (e.g. suitable) subset of one or more devices matching the query, or a pointer to the one or more devices.

[0141] Any (e.g. user) entity wanting to find a device with certain attributes can query the verified device database in the manner described herein and be provided with a suitable (e.g. set of) device data in response. In a specific example in which the device referred to herein is a car, the third request, as defined herein, may correspond to a request to find a car with certain attributes. The third request may be received from a user of the API described herein. The response from the first network node 10 could be information indicative of “2 cars with suitable attributes within 1km of location of requester”. Alternatively, or in addition, the response may be indicative of specific attributes of a specific set of cars.

[0142] As mentioned herein, the device may be provided with a second VC. The second VC (e.g. CSP-D-VC) may be (e.g. issued) based on all device data collected and verified bythe first network node 10. In some examples, the first network node 10 may be associated with (e.g. belong to) a different registry to that of the issuer entity (e.g. device manufacturer), as defined herein. In some examples, the device can present the second VC (CSP-D-VC) to another entity (e.g. network node and / or device) and utilise the selective data disclosure feature of VCs to only reveal parts of the second VC (e.g. that are relevant to the other entity). An advantage of the second VC (e.g. CSP-D-VC) is that a verifier that trusts the verified device database, and / or the first network node 10, would likely trust any device having a second VC, since the second VC is issued by the first network node 10. In some examples, the device 1404 may present the second VC via a SEND SMS function of the LISAT referred to herein.

[0143] As described herein, the first network node 10 can operate as a communication proxy between the device (e.g. potential target) and the second network node (e.g. requester entity). In this way, the first network node 10 can protect the device from tracking, attacks, and / or DoS attacks. In some examples, the second network node and the device can authenticate with each other using (e.g. manufacturer issued or first network node 10 issued) VCs. Advantageously, a second VC, as defined herein, is likely to be associated with (e.g. comprise) more info (e.g. device owner) than a manufacturer issued VC. As such, the use of second VC can be advantageous if there is a desire to associate a request for a capability to additional device information, such as a legal entity and / or person associated with the device.

[0144] In some scenarios, services can be provided in a SIM toolkit and / or through the user of APIs that are (e.g. only) routed to the first network node 10 (e.g. functions) without being exposed to external networks. These services can allow the device 1404 to securely communicate with the first network node 10 to provide and / or obtain a VC. In some examples, a function may be provided that enables the first network node 10 to use an API call to request a VC (e.g. the at least one first VC) from the device and / or information about the device (e.g. the connectivity of the device). The function may be stored in the SIM toolkit. In some examples, another function could enable the device 1404 to query a VC register using a secure channel provided by the first network node 10 (e.g. without necessarily utilising the internet) for resolution of the API call.

[0145] Figure 15 shows an example of a communication system 1500 in accordance with some embodiments. In the example, the communication system 1500 includes a telecommunications network 1502 that includes an access network 1504, such as a radioaccess network (RAN), and a core network 1506, which includes one or more core network nodes 1508. The access network 1504 includes one or more access network nodes or base stations of various types, access network nodes 1510A and 151 OB are depicted (which may be collectively referred to as network nodes 1510), or any other similar 3rdGeneration Partnership Project (3GPP) access nodes or non-3GPP access points (APs). The first network node 10 referred to herein (e.g. as described with reference to Figure 3), and / or the second network node referred to herein, may be a (e.g. access) network node as described with reference to Figure 15. Some embodiments of the access network 1504 may include more than one access network technology. The network nodes 1510 of access network 1504 facilitate direct or indirect connection of wireless devices, also referred to as user equipments (UEs), such as by connecting UEs 1512A, 1512B, 1512C, and 1512D (one or more of which may be generally referred to as UEs 1512) to the core network 1506 over one or more wireless connections. The device 1404 referred to herein may be a wireless device as described with reference to Figure 15.

[0146] Moreover, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunications network 1502 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a network node in the telecommunications network 1502 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other network nodes to implement one or more functionalities of any network node in the telecommunications network 1502, including one or more access network nodes 1510 and / or core network nodes 1508.

[0147] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification).

[0148] The network nodes 1510 facilitate direct or indirect connection of one or more UEs 1512 to the core network 1506 over one or more wireless connections. Example wirelesscommunications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 1500 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 1500 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0149] The UEs 1512 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 1510 and other communication devices. Similarly, the network nodes 1508, 1510 are arranged, capable, configured, and / or operable to communicate directly or indirectly (e.g., via other devices of telecommunications network 1502) with the UEs 1512 and / or with other network nodes or equipment in the telecommunications network 1502 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunications network 1502. More specifically, UEs 1512 may send messages, data, and / or other signals to network nodes 1508, 1510 or other elements of the telecommunications network 1502 by transmitting such signals to the relevant device directly without the signals passing through any intervening devices or by transmitting such signals to the relevant device indirectly through an intervening device (or multiple intervening devices) that then transmit the signal to the relevant device. Similarly, network nodes 1508, 1510 may send messages, data, and other signals to UEs 15122, other network nodes 1508, 1510, and other devices in telecommunications network 1502 directly or indirectly. As one specific example, a core network node 108 may transmit a particular message to a UE 1512 by transmitting the message to an access network node 1510 that will then transmit the message to the intended UE 1512. Similarly, a core network node 108 may receive a particular message from a UE 1512 by receiving the message from an access network node 1510 that itself received the message from the UE 1512.

[0150] In the depicted example, the core network 1506 connects elements of the access network 1504 (e.g., one or more of the network nodes 1510) to one or more host computing systems, such as host 1516. These connections may be direct or indirect viaone or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 1506 includes one or more core network nodes (e.g., core network node 1508) of various types, one or more of which may be generally referred to as network nodes 1508. Network nodes 1508 are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, access network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 1508. Example core network nodes provide functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (ALISF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0151] The host 1516 may be under the ownership or control of a service provider other than an operator or provider of the access network 1504 and / or the telecommunications network 1502. The host 1516 may be operated by the service provider or on behalf of the service provider. The host 1516 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0152] As a whole, the communication system 1500 of Figure 15 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system 1500 may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (Wi-Fi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (Wi-Max), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, Li-Fi, and / or any low-power wide-area network (LPWAN)standards such as LoRa and Sigfox. Moreover, the communication system 1500 may be configured to support multiple different standards, protocols, or other rule sets, with individual components supporting all of the relevant rule sets or with different components or sub-systems within the communication system 1500 supporting different standards, protocols, or rule sets.

[0153] As one example, in certain embodiments, access network 1504 may contain some access network nodes 1510 that support 3GPP radio access technologies (RAT), such as LTE or NR, while other access network nodes 1510 support (or the same access network nodes 1510 additionally support) non-3GPP RATs, such as Wi-Fi or a proprietary RAT. As another example, telecommunications network 1502 may support multiple generations of related communication standards (e.g., 4G and 5G 3GPP communication standards) and, as a result, may include an access network 104 and / or a core network 106 that supports multiple different standard generations or may include multiple access networks 104 and / or multiple core networks 106 with individual networks 104, 106 supporting different standard generations.

[0154] Telecommunications network 1502 may support network slicing to provide different logical networks to different devices that are connected to the telecommunications network 1502. For example, the telecommunications network 1502 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

[0155] In some examples, one or more of the UEs 1512 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 1504 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1504. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multiradio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0156] In the example, the hub 1514 communicates with the access network 1504 to facilitate indirect communication between one or more UEs (e.g., UE 1512C and / or 1512D) andnetwork nodes (e.g., network node 1510B). In some examples, the hub 1514 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 1514 may be a broadband router enabling access to the core network 1506 for the UEs. As another example, the hub 1514 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1510, or by executable code, script, process, or other instructions in the hub 1514.

[0157] As another example, the hub 1514 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 1514 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 1514 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1514 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 1514 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0158] The hub 1514 may have a constant / persistent or intermittent connection to the network node 1510B. The hub 1514 may also allow for a different communication scheme and / or schedule between the hub 1514 and UEs (e.g., UE 1512C and / or 1512D), and between the hub 1514 and the core network 1506. In other examples, the hub 1514 is connected to the core network 1506 and / or one or more UEs via a wired connection. Moreover, the hub 1514 may be configured to connect to an M2M service provider over the access network 1504 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 1510 while still connected via the hub 1514 via a wired or wireless connection. In some embodiments, the hub 1514 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 1510B. In other embodiments, the hub 1514 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1510B, but which is additionally capable of operating as a communication start and / or end point for certain data channels.Figure 16 shows a wireless device 1600, which may be configured to operate in communication system 1500 of Figure 15. The device 1404 referred to herein may comprise a wireless device 1600 as described with reference to Figure 16. The wireless device 1600 may be alternatively referred to as a UE 1600, like a UE 1512 within the context of communication system 1500, in accordance with respective embodiments. As used herein, a wireless device refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other wireless devices. Examples of a wireless device include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, and wireless terminal. Other examples include any type of UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-loT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0159] A wireless device 1600 may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, wireless device 1600 may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, wireless device 1600 may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, wireless device 1600 may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0160] In particular embodiments, wireless device 1600 includes processing circuitry 1602 that is operatively coupled via a bus 1604 to an input / output interface 1606, a power source 1608, a memory 1610, a communication interface 1612, and / or any other component, or any combination thereof. Certain embodiments of wireless device 1600 may include all or a subset of the components shown in Figure 16. The level of integration between the components may vary from one embodiment of wireless device 1600 to another. Ingeneral, in a particular embodiment of wireless device 1600, processing circuitry 1602, input / output interface 1606, power source 1608, memory 1610, and communication interface 1612 may, in whole or in part, represent or include physical components common to or shared by one or more of the other elements of wireless device 1600. Further, certain embodiments of wireless devices 1600 may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0161] The processing circuitry 1602 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 1610. The processing circuitry 1602 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 1602 may include multiple central processing units (CPUs).

[0162] In the example, the input / output interface 1606 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into wireless device 1600. Examples of an input device include a touch-sensitive or presencesensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.In some embodiments, the power source 1608 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used to supply power to circuitry or to charge an associated battery. The power source 1608 may further include power circuitry for delivering power from the power source 1608 itself, and / or an external power source, to the various parts of wireless device 1600 via input circuitry or an interface such as an electrical power cable. Power source 1608 may perform any formatting, converting, or other modification to make accessible power suitable for the respective components of the wireless device 1600 to which power is supplied.

[0163] The memory 1610 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 1610 includes one or more programs 1614, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 1616. The memory 1610 may store, for use by wireless device 1600, any of a variety of various operating systems or combinations of operating systems.

[0164] The memory 1610 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUlCC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 1610 may allow wireless device 1600 to access instructions, programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 1610, which may be or comprise a device-readable storage medium.The processing circuitry 1602 may be configured to communicate with an access network or other network via or using the communication interface 1612. The communication interface 1612 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1622. The communication interface 1612 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another wireless device or a network node in an access network). Each transceiver may include a transmitter 1618 and / or a receiver 1620 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 1618 and receiver 1620 may be coupled to one or more antennas (e.g., antenna 1622) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0165] In the illustrated embodiment, communication functions of the communication interface 1612 may include cellular communication, Wi-Fi communication (e.g., according to an IEEE 802.11 family standard), LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0166] In particular embodiments, wireless device 1600 may provide an output of data captured via a sensor, through its communication interface 1612, via a wireless connection to a network node, and / or in any appropriate manner. Data captured by sensors of a wireless device 1600 can be communicated through a wireless connection to a network node via another wireless device 1600. In particular embodiments, such output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).As another example, wireless device 1600 comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, wireless device 1600 may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0167] Wireless device 1600, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, wearable technology, extended industrial application and healthcare. Nonlimiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. In particular embodiments, wireless device 1600 represents an loT device that comprises circuitry and / or software in dependence of the intended application of the loT device in addition to other components as described in relation to the example embodiment of wireless device 1600 shown in Figure 16.

[0168] As yet another specific example, in an loT scenario, wireless device 1600 may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another wireless device and / or a network node. Wireless device 1600 may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, wireless device 1600 may implement the 3GPP NB-loT standard. In other scenarios, wireless device 1600 may represent a vehicle, such as a car, a bus, a truck, a ship and anairplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0169] In practice, any number of wireless devices 1600 may be used together with respect to a single use case. For example, a first wireless device 1600 might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second wireless device 1600 that is a remote controller operating the drone. When a user makes changes from the remote controller, the first wireless device 1600 may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second wireless device 1600 can also include more than one of the functionalities described above. For example, wireless device 1600 might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0170] Figure 17 shows a network node 1700 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunications network. The first network node 10 referred to herein may be a network node as described with reference to Figure 17. In accordance with respective embodiments, network node 1700 may be configured to operate in communication system 1500 of Figure 15, like network nodes 1508 or 1510. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), O-RAN nodes or components of an O-RAN node (e.g., 0-Rll, O-DU, O-CU).

[0171] Network nodes 1700 may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount ofcoverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. Network node 1700 may be a relay node or a relay donor node controlling a relay. Network nodes 1700 may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of adistributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0172] Other examples of network nodes 1700 include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0173] In particular embodiments, network node 1700 includes a processing circuitry 1702, a memory 1704, a communication interface 1706, and a power source 1708. In general, in a particular embodiment of network node 1700, processing circuitry 1702, memory 1704, communication interface 1706, and power source 1708 may, in whole or in part, represent or include physical components common to or shared by one or more of the other elements of network node 1700.

[0174] The network node 1700 may be composed of multiple distinct network entities (e.g., a NodeB entity and a RNC entity, or a BTS entity and a BSC entity, etc.), which may each have or utilize their own respective physical components. In certain scenarios in which the network node 1700 comprises multiple such entities (e.g., BTS and BSC), one or more of the separate entities may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 1700 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memories 1704 or portions of memory 1704 for different RATs) and some components may be reused (e.g., a same antenna 1710 may be shared by different RATs). The network node 1700 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1700, for example GSM, WCDMA, LTE, NR, Wi-Fi (e.g., according to an IEEE 802.11 family standard), Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologiesmay be integrated into the same or different chip or set of chips and other components within network node 1700.

[0175] The processing circuitry 1702 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other components, such as the memory 1704, to provide network node 1700 functionality.

[0176] In some embodiments, the processing circuitry 1702 includes a system on a chip (SOC). In some embodiments, the processing circuitry 1702 includes one or more of radio frequency (RF) transceiver circuitry 1712 and baseband processing circuitry 1714. In some embodiments, the RF transceiver circuitry 1712 and the baseband processing circuitry 1714 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 1712 and baseband processing circuitry 1714 may be on the same chip or set of chips, boards, or units.

[0177] The memory 1704 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), readonly memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computerexecutable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 1702. The memory 1704 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 1702 and utilized by the network node 1700. The memory 1704 may be used to store any calculations made by the processing circuitry 1702 and / or any data received via the communication interface 1706. In some embodiments, the processing circuitry 1702 and memory 1704 is integrated.

[0178] The communication interface 1706 is used in wired or wireless communication of signaling and / or data with UEs, other network nodes, and / or any other networkequipment. In the illustrated embodiment, communication interface 1706 comprises port(s) / terminal(s) 1716 to send and receive data, for example to and from a network over a wired connection. In particular embodiments, network node 1600 may be capable of wireless communication and communication interface 1706 may also include radio front-end circuitry 1718 that may be coupled to, or in certain embodiments a part of, an antenna 1710. Particular embodiments of radio front-end circuitry 1718 include filter(s) 1720 and amplifier(s) 1722. The radio front-end circuitry 1718 may be connected to an antenna 1710 and processing circuitry 1702. The radio front-end circuitry may be configured to condition signals communicated between antenna 1710 and processing circuitry 1702. The radio front-end circuitry 1718 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 1718 may convert the digital data into a radio signal(s) having the appropriate channel and bandwidth parameters using a combination of filters 1720 and / or amplifiers 1722. The radio signal(s) may then be transmitted via the antenna 1710. Similarly, when receiving data, the antenna 1710 may collect radio signals which are then converted into digital data by the radio front-end circuitry 1718. The digital data may be passed to the processing circuitry 1702. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0179] In certain alternative embodiments, network node 1700 may be capable of wireless communication but does not include separate radio front-end circuitry 1718, instead, the processing circuitry 1702 includes radio front-end circuitry and is connected to the antenna 1710. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1712 is part of the communication interface 1706. In still other embodiments, the communication interface 1706 includes one or more ports or terminals 1716, the radio front-end circuitry 1718, and the RF transceiver circuitry 1712, as part of a radio unit (not shown), and the communication interface 1706 communicates with the baseband processing circuitry 1714, which is part of a digital unit (not shown).

[0180] The antenna 1710 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 1710 may be coupled to the radio front-end circuitry 1718 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 1710 is separate from the network node 1700 and connectable to the network node 1700 through one or more interfaces or ports.The antenna 1710, communication interface 1706, and / or the processing circuitry 1702 may be configured to perform some or all of the receiving operations and / or obtaining operations described herein as being performed by the network node 1700. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 1710, the communication interface 1706, and / or the processing circuitry 1702 may be configured to perform some or all of the transmitting or sending operations described herein as being performed by the network node 1700. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0181] The power source 1708 provides power to the various components of network node 1700 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 1708 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 1700 with power for performing the functionality described herein. For example, the network node 1700 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 1708. As a further example, the power source 1708 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail. Embodiments of the network node 1700 may include additional components beyond those shown in Figure 17 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 1700 may include user interface equipment to allow input of information into the network node 1700 and to allow output of information from the network node 1700. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 1700.

[0182] There is also provided a computer program comprising instructions which, when executed by processing circuitry (such as the processing circuitry 12 of the first network node 10 described herein), cause the processing circuitry to perform at least part of the method described herein. There is provided a computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry (such as the processing circuitry 12 of the first networknode 10 described herein) to cause the processing circuitry to perform at least part of the method described herein. There is provided a computer program product comprising a carrier containing instructions for causing processing circuitry (such as the processing circuitry 12 of the first network node 10 described herein) to perform at least part of the method described herein. In some embodiments, the carrier can be any one of an electronic signal, an optical signal, an electromagnetic signal, an electrical signal, a radio signal, a microwave signal, or a computer-readable storage medium.

[0183] In some embodiments, the first network node 10 functionality described herein can be performed by hardware. Thus, in some embodiments, the first network node 10 described herein can be a hardware entity. However, it will also be understood that optionally at least part or all of the first network node 10 described herein can be virtualised. For example, the functions performed by the first network node 10 described herein can be implemented in software running on generic hardware that is configured to orchestrate the first entity functionality described herein. Thus, in some embodiments, the first network node 10 described herein can be a virtual entity. Virtualised instances of the first network node 10 can be rapidly deployed, scaled, and / or modified according to changing needs of a network environment.

[0184] It should be noted that the above-mentioned embodiments illustrate rather than limit the idea, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

59CLAIMS1. A method performed by a first network node (10), the method comprising:receiving (302, 1418) a first request from a device (1404), wherein the first request is a request for verification of the device (1404);obtaining (304, 802, 1422) at least one first verifiable credential, VC, from the device (1404), wherein the at least one first VC is signed with a first digital signature of an issuer entity (1402) of the at least one first VC;determining (306) whether the first digital signature is verified using a first public key of the issuer entity (1402), wherein the first public key is obtained from a first database (1406); andif the first digital signature is verified, determining (308, 706, 1302) whether the at least one first VC is verified, wherein the at least one first VC is determined to be verified if the first database (1406) is associated with one or more trusted databases (1406, 1408); andif the at least one first VC is verified:storing (310, 1002, 1208, 1434) a profile of the device (1404) in a verified device database, wherein the profile comprises information identifying the device (1404), the at least one first VC, and a plurality of first information elements, wherein the plurality of first information elements are obtained from the one or more trusted databases (1406, 1408), and wherein each first information element of the plurality of first information elements is indicative of an attribute of the device (1404) or an attribute of the issuer entity (1402).

2. The method as claimed in claim 1, wherein the at least one first VC is signed with a second digital signature of the device (1404), and wherein the method comprises: determining (702) whether the second digital signature is verified using a second public key of the device (1404); andif (704) each of the first digital signature and the second digital signature is verified, determining whether the at least one first VC is verified.

3. The method as claimed in claim 2, wherein the second public key is comprised in the at least one first VC.

4. The method as claimed in claim 2 or 3, wherein the second digital signature is generated using a private key of the device (1404).

605. The method as claimed in any of the preceding claims, wherein the first digital signature is generated using a private key of the issuer entity (1402).

6. The method as claimed in any of the preceding claims, wherein obtaining the at least one first VC from the device (1404) comprises:initiating (804) transmission of a second request towards the device (1404), wherein the second request is a request for information associated with the device (1404); andreceiving (806) a first response from the device (1404), wherein the first response comprises the at least one first VC.

7. The method as claimed in any of the preceding claims, comprising:receiving (1004) a third request from a second network node, wherein the third request is for information indicative of one or more network entities that meet a first criterion;determining (1006) whether the device (1404) meets the first criterion based on the stored profile of the device (1404); andif the device (1404) meets the first criterion, initiating (1008) transmission of one or more second information elements towards the second network node, wherein the one or more second information elements are obtained from the profile of the device (1404).

8. The method as claimed in claim 7, comprising:in response to receiving (1010), from the second network node, a request to communicate with the device (1404):operating (1012) as a communication proxy between the device (1404) and the second network node.

9. The method as claimed in claim 7 or 8, wherein:the third request is received using an application programming interface, API; and / orthe transmission of the one or more second information elements isinitiated using the API.

10. The method as claimed in any of the preceding claims, comprising:61obtaining (902) one or more third information elements, wherein theone or more third information elements are indicative of a capability and / or a functionality of the device (1404).

11. The method as claimed in claim 10, wherein the profile of the device (1404) comprises the one or more third information elements.

12. The method as claimed in claim 10 or 11, wherein the one or more third information elements are received from:the device (1404); and / orthe one or more trusted databases (1406, 1408).

13. The method as claimed in claim 12, wherein:obtaining the at least one first VC from the device (1404) comprises:initiating (804) transmission of a second request towards the device (1404), wherein the second request is a request for information associated with the device (1404); andreceiving (806) a first response from the device (1404), wherein the first response comprises the at least one first VC; andthe one or more third information elements are comprised in the first response.

14. The method as claimed in any of claims 10 to 13, wherein obtaining (902) the one or more third elements comprises obtaining permission information, wherein, for each third information element of the one or more third information elements, the permission information is indicative of whether the first network node (10) is allowed to share the third information element.

15. The method as claimed in any of the preceding claims, comprising:obtaining (1102) the plurality of first information elements from the one or more trusted databases (1406, 1408).

16. The method as claimed in claim 15, wherein obtaining the plurality of first information elements comprises:initiating transmission of a request for information indicative of the device (1404) to the one or more trusted databases (1406, 1408); and62receiving the plurality of first information elements from the one or more trusted databases (1406, 1408).

17. The method as claimed in any of the preceding claims, comprising:generating (1202) the profile of the device (1404).

18. The method as claimed in claim 17, wherein generating (1202) the profile of the device (1404) comprises:creating (1204) a new profile of the device (1404); orupdating (1206) an existing profile of the device (1404).

19. The method as claimed in any of the preceding claims, comprising:if the at least one first VC is verified,initiating (1306) transmission of a first message towards the device (1404), wherein the first message comprises an indication that the verification of the device (1404) is successful.

20. The method as claimed in claim 19, wherein the first message comprises a second VC for the device (1404), wherein the second VC is issued by the first network node (10), and wherein the second VC is associated with information verified by the first network node (10).

21. The method as claimed in any of the preceding claims, wherein the issuer entity (1402) is an entity of a manufacturer of the device (1404).

22. The method as claimed in any of the preceding claims, wherein the one or more trusted databases (1406, 1408) comprises at least one database of a government agency.

23. The method as claimed in any of the preceding claims, wherein the attribute of the device (1404) comprises one or more of:an identifier of the device (1404);a subscription that the device (1404) has to a network;an identifier of the subscription;an attribute of the subscription;a location of the device (1404);63an owner of the device (1404);a user of the device (1404);a role of the device (1404);a state of the device (1404);a category of the device (1404); anda type of the device (1404).

24. The method as claimed in claim 23, wherein the identifier of the device (1404) comprises an international mobile subscriber identity, IMSI, of the device (1404).

25. The method as claimed in any of the preceding claims, wherein the attribute of the issuer entity (1402) comprises one or more of:an identifier of the issuer entity (1402);a location of the issuer entity (1402); anda database associated with the issuer entity (1402).

26. The method as claimed in any of the preceding claims, wherein the plurality of first information elements comprises a data schema corresponding to the at least one first VC.

27. The method as claimed in claim 26, wherein the data schema comprises information for verifying the at least one first VC.

28. The method as claimed in any of the preceding claims, wherein the first network node (10) is one or more of:a node of a service provider of a telecommunications network;a node of a communications service provider of the telecommunications network; anda node of an operator of the telecommunications network.

29. The method as claimed in any of the preceding claims, wherein the device (1404) is one or more of:a wireless device;a user equipment;a vehicle; anda camera.

30. A first network node (10) adapted to:receive a first request from a device (1404), wherein the first request is a request for verification of the device (1404);obtain at least one first verifiable credential, VC, from the device (1404), wherein the at least one first VC is signed with a first digital signature of an issuer entity (1402) of the at least one first VC;determine whether the first digital signature is verified using a first public key of the issuer entity (1402), wherein the first public key is obtained from a first database; andif the first digital signature is verified, determine whether the at least one first VC is verified, wherein the at least one first VC is determined to be verified if the first database is associated with one or more trusted databases (1406, 1408); andif the at least one first VC is verified:store a profile of the device (1404) in a verified device database, wherein the profile comprises information identifying the device (1404), the at least one first VC, and a plurality of first information elements, wherein the plurality of first information elements are obtained from the one or more trusted databases (1406, 1408), and wherein each first information element of the plurality of first information elements is indicative of an attribute of the device (1404) or an attribute of the issuer entity (1402).

31. A first network node (10) as claimed in claim 30, wherein the first network node (10) is adapted to perform the method of any of claims 2 to 29.

32. A first network node (10) comprising:processing circuitry (12) configured to cause the first network node (10) to: receive a first request from a device (1404), wherein the first request is a request for verification of the device (1404);obtain at least one first verifiable credential, VC, from the device (1404), wherein the at least one first VC is signed with a first digital signature of an issuer entity (1402) of the at least one first VC;determine whether the first digital signature is verified using a first public key of the issuer entity (1402), wherein the first public key is obtained from a first database; andif the first digital signature is verified, determine whether the at least one first VC is verified, wherein the at least one first VC is determined to be verified if the first database is associated with one or more trusted databases (1406, 1408); andif the at least one first VC is verified:store a profile of the device (1404) in a verified device database, wherein the profile comprises information identifying the device (1404), the at least one first VC, and a plurality of first information elements, wherein the plurality of first information elements are obtained from the one or more trusted databases (1406, 1408), and wherein each first information element of the plurality of first information elements is indicative of an attribute of the device (1404) or an attribute of the issuer entity (1402).

33. A first network node (10) as claimed in claim 32, wherein the processing circuitry (12) is configured to cause the first network node (10) to perform the method of any of claims 2 to 29.

34. A computer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the method according to any of claims 1 to 29.

35. A computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry to cause the processing circuitry to perform the method according to any of claims 1 to 29.

Images