Privacy is extremely important in today’s digital world. Privacy should also be considered in the scope of IoT, since an IoT device may also be a personal device such as a smartwatch or sensor in a car, therefore tracking the IoT device would also allow tracking the user. A good principle for improving privacy is minimising the data shared with other parties. Suppose that a factory has outsourced the maintenance to a subcontractor, which means that a technician working for the subcontractor needs to have (limited) access to the factory and its machinery. When enforcing such access control, the factory does not need to learn the real identity of the technician (or even know that the technician is the same person who accessed the factory last week), it is enough to verify that the technician has been authorised by a trusted subcontractor.<\/p>\n\n\n\n
Traditionally there have been no standard interoperable solutions for digital identifiers, each service has been forced to create their own. More recently, some large companies such as Google, Facebook, and Twitter, have introduced solutions known as social logins<\/em> (implemented with OAuth and similar protocols), where the identifiers for that company’s services can also be used to login to many other services. While this reduces the number of identifiers individuals have to manage, it also means that individuals are dependent on the service (e.g. Facebook) providing the identifiers, and it also puts the service in a position to monitor the individuals\u2019 use of other services, which is detrimental to privacy. Clearly, there is a need for an identity solution that is controlled by the individual and provides sufficient privacy.\u00a0<\/p>\n\n\n\n Currently, an identity technology receiving much attention are the decentralised identifiers (DIDs)1<\/sup><\/a>. A key aspect of DIDs is that they are designed not to be dependent on any central issuing party (Identity Provider or IdP) that creates and controls the identity or monitors their usage. Instead, DIDs are managed by the identity owner (or a guardian on the owners behalf), an approach known as self-sovereign identity<\/em>. The specification defines a DID as a random string that makes it privacy-promoting. Furthermore, if a new DID is allocated for every part<\/em>y one communicates with, correlating one\u2019s activities with different parties would be significantly harder to achieve. This property can be further enhanced by replacing existing DIDs with new ones at suitable intervals or even after just a single use.\u00a0<\/p>\n\n\n\n There are several DID methods available, including Sovrin1<\/sup><\/a>, uPort2<\/sup><\/a> that support DID discovery, and simple ones that do not require additional infrastructure such as did:key3<\/sup><\/a> and did:self4<\/sup><\/a>. In many cases, there is also a need to associate machine-verifiable properties<\/em> to the identifier of an entity. This is accomplished with Verifiable Credentials (VCs)5<\/sup><\/a> which are analogous to traditional authorisation certificates. In a VC, the party issuing the credential (i.e. the issuer) states that according to them, the party about which the credential is made, known as the prover, has those properties. These could be e.g. the person\u2019s name, date of birth, current employer, access rights to certain premises, etc.<\/p>\n\n\n\n In the IoT-NGIN project we have implemented a proof of concept prototype<\/em> to create and manage DIDs and Verifiable Credentials and enforce access control based on them. There, the credential is encoded in the commonly used Json Web Token (JWT)1<\/sup><\/a><\/em> format, while the user also uses Demonstrating Proof-of-Possession<\/em><\/p>\n\n\n\n (DPoP)1<\/sup><\/a><\/em> tokens to prove their ownership of the private key related to the DID present in the credential. The prototype includes a reverse proxy, which will verify these tokens and if everything is in order, will forward the request to the actual IoT device or other kind of resource server. In this approach the IoT devices do need to be aware of the authorisation scheme used. On the other hand, the solution can also be used directly on the IoT device if necessary. We have implemented DPoP and VC verification on the ESP322<\/sup><\/a> device, despite it being a very low cost device (it can be bought for just 2,5\u20ac including shipping), the full verification of tokens on the device takes just 160ms, which is sufficient performance for most of IoT use cases.<\/p>\n\n\n\n References<\/strong><\/p>\n\n\n\n <\/p>\n\n\n\n \n1<\/sup> \n \nhttps:\/\/www.w3.org\/TR\/did-core\/\u00a0\n<\/a>\n Privacy is extremely important in today’s digital world. Privacy should also be considered in the scope of IoT, since an IoT device may also be a personal device such as a smartwatch or sensor in a car, therefore tracking the …<\/p>\n","protected":false},"author":2,"featured_media":2104,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_mi_skip_tracking":false,"footnotes":""},"categories":[17],"tags":[],"yoast_head":"\n
\n\n\n\n
\n2<\/sup> \n \n https:\/\/sovrin.org\/\u00a0\n<\/a>\n
\n4<\/sup> \n \nhttps:\/\/w3c-ccg.github.io\/did-method-key\/\u00a0\n<\/a>\n
\n5<\/sup> \n \n https:\/\/github.com\/mmlab-aueb\/did-self\u00a0\n<\/a>\n
\n6<\/sup> \n \nhttps:\/\/www.w3.org\/TR\/vc-data-model\/\u00a0\n<\/a>\n
\n7<\/sup> \n \nhttps:\/\/datatracker.ietf.org\/doc\/html\/rfc7519\u00a0\n<\/a>\n
\n8<\/sup> \n \nhttps:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-oauth-dpop\u00a0\n<\/a>\n
\n9<\/sup> \n \nhttps:\/\/www.espressif.com\/en\/products\/socs\/esp32\u00a0\n<\/a>\n
\n
\n<\/p>\n\n\n\n